<neggles>
sounds like eeprom corruption or something
felix has quit []
felix has joined #openwrt-devel
Tapper has joined #openwrt-devel
srslypascal is now known as Guest2186
srslypascal has joined #openwrt-devel
srslypascal is now known as Guest2187
srslypascal has joined #openwrt-devel
Guest2186 has quit [Ping timeout: 480 seconds]
Guest2187 has quit [Ping timeout: 480 seconds]
Borromini has joined #openwrt-devel
danitool has joined #openwrt-devel
Tapper has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
srslypascal has quit [Ping timeout: 480 seconds]
srslypascal has joined #openwrt-devel
hitech95 has joined #openwrt-devel
robimarko has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
Borromini has quit [Quit: leaving]
GNUmoon has quit [Quit: Leaving]
GNUmoon has joined #openwrt-devel
goliath has joined #openwrt-devel
srslypascal is now known as Guest2191
srslypascal has joined #openwrt-devel
GNUmoon2 has joined #openwrt-devel
Guest2191 has quit [Ping timeout: 480 seconds]
GNUmoon has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
ekathva has quit []
<neggles>
is there a trick to using an external kernel tree with the buildsystem?
Tapper has quit [Ping timeout: 480 seconds]
ekathva has joined #openwrt-devel
MAbeeTT5 has quit [Quit: WeeChat 2.3]
MAbeeTT has joined #openwrt-devel
mattytap__ has joined #openwrt-devel
dave14305 has joined #openwrt-devel
mattytap_ has quit [Ping timeout: 480 seconds]
dave14305 has quit [Remote host closed the connection]
GNUmoon2 has quit [Remote host closed the connection]
rua has quit [Quit: Leaving.]
rua has joined #openwrt-devel
shibboleth has joined #openwrt-devel
GNUmoon has joined #openwrt-devel
<robimarko>
neggles: There is a option in menuconfig to use an external tree
<robimarko>
However, make sure to not enable GPIO key hotplug driver
<neggles>
robimarko: ahhhh is THAT the problem?!
<neggles>
whenever I've tried it's thrown a weird error with user_headers or somesuch
Vavooon has joined #openwrt-devel
<robimarko>
It is a problem for sure as OpenWrt uses a hotplug based custom driver instead of the event based one
<robimarko>
Not sure if its your problem
<neggles>
well i've definitely had it turned on every time i've tried so :P
<neggles>
oh god. my embarassment of a DSA driver successfully compiled.
<neggles>
guess it's time to see if it works
<Vavooon>
Hi. I'm having a strange problem with `glib2` on 22.03 branch: when using `g_cond_wait_until` call, it never waits specified amount of time, instead it just returns `FALSE`(which stands for timeout) immediately. It is affecting underlying software which is using this method, `gst-rtsp-server` in my case. I have prepared an example app which reproduces the issue, while it is working completely fine when executed on my PC
<dwfreed>
if you can, try to test on eg alpine linux
<stintel>
often getting things like this: * pkg_hash_check_unresolved: cannot find dependency libucode20220206 for ucode
<stintel>
can we fix that by autorebuild somehow? very annoying
<neggles>
um, glib documentation says this is expected behaviour
<neggles>
i, think? it's not clear, but it does want the mutex to be locked before you go checking it
<Vavooon>
@neggles When I lock the mutex, it does not proceed into the `while` loop
<Vavooon>
@neggles Could you point me to the place where it says it's expected behaviour
<dwfreed>
that's because your mutex nor your cond are initialized
<dwfreed>
because neither*
<dwfreed>
you're allocating them on the stack, so they're random data; they need to be init'ed
<neggles>
yeah i was about to say that
<Vavooon>
Thanks a lot, however I've just added `g_cond_init(&data_cond);` as well as `g_mutex_init(&data_mutex);` and `g_mutex_lock (&data_mutex);` but the issue is still happening
<neggles>
the examples show the GCond and GMutex being declared globally
srslypascal is now known as Guest2209
srslypascal has joined #openwrt-devel
<dwfreed>
after correctly initializing the mutex and cond, and locking the mutex before the loop, what does the timeout report for the new value of g_get_monotonic_time, and how does that compare to the expected end time?
<Vavooon>
start timer: 7063974018 wait until: 7068974664 while timeout: 7063975922
<neggles>
and is basically a carbon copy of the glib example
<neggles>
a mutex declared inside a function isn't very useful...
<neggles>
stintel: which phy did they hook to the physical port?
<Vavooon>
@neggles Just tried your code, still doesn't wait (but works fine on PC too)
<neggles>
interesting. might be a musl bug then like dwfreed suggested
<neggles>
i have an alpine chroot lets see
<stintel>
neggles: dunno, didn't look, just trying to recover asap, only here 2 days + need to meet with a lot of people
<neggles>
...actually it's just past midnight and somehow I've managed to trigger a kernel panic on `mutex_lock_nested(&bus->mdio_lock, MDIO_MUTEX_NESTED);`
<neggles>
but good luck Vavooon
<Vavooon>
Ok, thanks for the help, trying on Alpine too
<neggles>
if it doesn't work on alpine, musl bug
<neggles>
(probably)
arthur_melo has joined #openwrt-devel
<neggles>
stintel: fair enough, mt7621 so shouldn't be too much fuss
<neggles>
tftp recovery it back to unifi fw, ssh in, flash back to openwrt? :P
<stintel>
neggles: had to fix the TTL header, soldering wasn't done properly apparently, running OpenWrt again already
<neggles>
nice :)
<stintel>
but don't find a backup of the config (device has been down for months, 2000+ km away and down due to someone breaking mt7621
<neggles>
ah
<neggles>
(are they held together with just glue like the nanoHDs?)
<stintel>
nah, secondary location, not here for long back then either, lack of proper equipment, rush job basicallt
<stintel>
not amused that I can't find a backup of the config, it was my only working wpa enterprise setup
<neggles>
ouch
srslypascal is now known as Guest2213
srslypascal has joined #openwrt-devel
Guest2213 has quit [Ping timeout: 480 seconds]
srslypascal is now known as Guest2214
srslypascal has joined #openwrt-devel
<Vavooon>
Weird, it works fine on Alpine linux, waits till the timeout
<neggles>
what arch are you running on where it erros
<neggles>
errors*
<Vavooon>
ath79
<neggles>
mipsel hmm
<Vavooon>
mips24 yep
<neggles>
wait is ath79 LE or BE?
<PaulFertser>
BE
<PaulFertser>
ramips is LE
<neggles>
ah
<neggles>
wonder if that's got anything to do with it
Guest2214 has quit [Ping timeout: 480 seconds]
<Vavooon>
Possibly, I probably need to try it on older versions, I was running the same software yet on 19.07 and 21.x without any issues, I'm sure here
<hitech95>
I was folowing te guide: https://openwrt.org/docs/guide-developer/helloworld/chapter4 to create my own repository to test out some changes on an ustream package. feeds update generate the index file but running feeds install -a -p myrepo is not doing what it should (No Installing package 'helloworld' from mypackages message)
<hitech95>
Any idea?
minimal has joined #openwrt-devel
<PaulFertser>
hitech95: installing a package is just creating a symlink in packages/
<PaulFertser>
hitech95: probably a symlink already exists there
<PaulFertser>
hitech95: package/feeds
<hitech95>
yea I know but taht symlink should not exist for the helloworld example. For reference with ctrl+/ I cannot find anything.
<hitech95>
PaulFertser: I'm literally following the tutorial with the exception of the basepath that is different:
<hitech95>
./scripts/feeds install -a -p crowdsec print only Installing all packages from feed crowdsec. and not the installing "helloworld"
<PaulFertser>
hitech95: try reversing the argument order, putting -p first
<PaulFertser>
hitech95: hm, all packages should include yours too. Probably feeds update step is missing something, not creating the index or similar.
<hitech95>
ok reversing the order fixed the issue. dam it was 2 days that I was stuck there!
<neggles>
./scripts/feeds update -a && ./scripts/feeds install -a && ./scripts/feeds install -a
<neggles>
:P
<hitech95>
PaulFertser: thanks a lot!
<hitech95>
neggles: that was also not working, no idea why!
<neggles>
pixies
<neggles>
makefile pixies
<hitech95>
lol!
<hitech95>
The fixeies that I'm facing is with fw4 that broke somehow with some packages requiring reboot and the parsing of the .data field in the net protocol/interface. That is really annoing!
<hitech95>
*pixies
SamantazFox has quit [Ping timeout: 480 seconds]
<Vavooon>
@neggles In case you're still here, I managed to find the root (not completely, but I can work with it) cause: there is some USE_NATIVE_MUTEX identifier defined here https://github.com/GNOME/glib/blob/main/glib/gthread-posix.c#L77 and everything works fine if I disable it
<neggles>
I, for one, blame endianness
<neggles>
and/or musl/glib not getting along
<Vavooon>
If it is defined, then Glib tries to use some futex syscalls
<Vavooon>
Not sure where should I report this issue to: OpenWRT or GLib?
<neggles>
i would go with glib and see if they point you to musl
<Vavooon>
Thx, will do
<neggles>
ah goddamnit i think i worked out where my kernel panic came from
cbeznea1 has joined #openwrt-devel
cbeznea has quit [Ping timeout: 480 seconds]
Tapper has joined #openwrt-devel
ekathva has quit [Remote host closed the connection]
rua has quit [Ping timeout: 480 seconds]
rua has joined #openwrt-devel
grift has quit [Quit: Bye]
grift has joined #openwrt-devel
mattytap_ has joined #openwrt-devel
mattytap__ has quit [Read error: Connection reset by peer]
shibboleth has quit [Quit: shibboleth]
mattytap__ has joined #openwrt-devel
Borromini has joined #openwrt-devel
mattytap_ has quit [Read error: No route to host]
hitech95 has quit [Remote host closed the connection]