00:30 <owrt-images-builds> Build [#27](https://buildbot.openwrt.org/images/#/builders/144/builds/27) of `openwrt-23.05_armsr/armv8` failed: failed './scripts/feeds update' (failure)

07:35 <owrt-images-builds> Build [#116](https://buildbot.openwrt.org/images/#/builders/165/builds/116) of `openwrt-24.10_ramips/rt305x` failed: failed './scripts/feeds update' (failure)

09:51 <owrt-images-builds> Build [#117](https://buildbot.openwrt.org/images/#/builders/80/builds/117) of `openwrt-24.10_ramips/rt288x` failed: failed './scripts/feeds update' (failure)

11:05 <russell--> perl build problems, i have a long running lto1 process, pegging a CPU

11:11 <russell--> or, is it python?

11:13 <russell--> aarch64-openwrt-linux-musl-gcc [...] -o libpython3.11.so [...]

11:14 <russell--> trying a make dirclean world

12:12 <russell--> yeah, i'm back down to a single thread, waiting on staging_dir/toolchain-aarch64_cortex-a53_gcc-14.2.0_musl/libexec/gcc/aarch64-openwrt-linux-musl/14.2.0/lto1 for python3

12:18 <russell--> holy crap, that process ran for 15 minutes

12:18 <russell--> but apparently finally finished

12:22 <dwfreed> lto on large programs like python would definitely take a while

12:22 <dwfreed> but if it's pegging a core, that means it's probably doing its job :P

12:22 <russell--> this is abberant. it's never taken anything like this long before to do a dirclean world on this box

12:23 <dwfreed> or things changed?

12:23 <russell--> a dirclean world on my .config takes like 20 minutes total on this box

12:24 <robimarko> We had a regression that caused -O2 to get dropped from host CFLAGS

12:24 <robimarko> https://github.com/openwrt/openwrt/commit/e3bec5692c50ff3b8001d4611c8eb57f54efb6b5

12:24 <robimarko> Fixed it

12:24 <russell--> i just pulled like, maybe 60 minutes ago

12:25 <robimarko> Well, this was pushed also an hour ago

12:25 <russell--> maybe that's in then

12:26 <robimarko> Check git log

12:28 <aiyion_> hey there; might be an offtopic question and I'm totally new to the matter, so I might have missed an obvious solution: But when building OpenWrt under NixOS, there's per design no /bin/bash. I'd like to avoid symlinking it on a systemwide level; is there a suggested way to get around this caveat without "fixing" all occurences of /bin/bash shebangs in openwrt and subsequent

12:28 <aiyion_> packages to e.g. /usr/bin/env bash?

12:28 <russell--> real 74m6.968s

12:28 <russell--> finally finished

12:29 <dwfreed> aiyion: yeah, no, just symlink /bin/bash; that's effectively ABI at this point

12:29 <dwfreed> literally every script in existence expects bash to be in /bin

12:31 <aiyion> That much I do know ^^

12:31 <aiyion> But thanks :)

12:31 <minimal> "#!/bin/sh" scripts don't ;-)

12:35 <dwfreed> minimal: :P

12:51 <aiyion> It looks like I can get quite far in the build process by replacing a small handful of shebangs with #!/usr/bin/env bash. It feels like this'd only shift the problem though, until the next person comes along with a distro, which does not place env at /usr/bin? It looks like POSIX does not enforce its location, does it?

12:53 <aiyion> I'm having trouble though finding unix based systems apart some ancient sun OS's which lack /usr/bin/env or /bin/sh. Maybe 'fixing' would not be as bad as I initially thought.

12:53 <dwfreed> well, everything that has env is going to place it in /usr/bin

12:53 <dwfreed> another one of those things set in stone by convention

12:57 <aiyion> Do you think it would hurt, if I drafted patches to discuss this on the mailinglist?

13:01 <owrt-images-builds> Build [#117](https://buildbot.openwrt.org/images/#/builders/119/builds/117) of `openwrt-24.10_ath79/nand` failed: failed './scripts/feeds update' (failure)

13:16 <gch981213> mrkiko: pong

13:44 <dwfreed> aiyion: honestly I don't think they'd be accepted; bash is in /bin, full stop, and NixOS not doing that is a NixOS problem, not an openwrt problem

13:45 <aiyion> I see, thanks for the warning.

14:36 <slh> there'd be an easy alternative, converting the bash scripts to pure POSIX sh, then the location of bash doesn't matter anymore ;)

14:37 <dwfreed> "easy" they say

14:38 <slh> at least more likely to convince those in charge of potenially merging the results

14:38 <dwfreed> doubtful :P

14:39 <dwfreed> there's several nice things about scripting in bash vs posix sh

14:39 <slh> (and yes, I know the difficulties involved, been there, done that - in many cases bash can be avoided reasonably easily - yes, in quotations)

14:51 <dhewg> far too many ppl are way to used to bash, quite often it's just trivial stuff like [[ -> [

14:52 <slh> yep, there are tons of low hanging fruits there

14:52 <dhewg> and then there's the ash scripts on an openwrt device, so it's not like ppl don't know how to handle it ;)

14:53 <dwfreed> even [[ -> [ has side effects

14:54 <dhewg> it does, but often [ is what ppl want, they're just used to [[

14:54 <slh> it's always a question who's upstream, e.g. I wouldn't accept patches for packages by other upstreams

15:06 <efahl> shear scale sort of prohibits any attempt to get rid of it: rgrep '#!/bin/bash' build_dir/ | wc -l gives 2950 instances

15:06 <efahl> most of them are tests or testing, but that still leaves 500+ used for the build...

15:15 <soxrok2212> merbanan: have any insight to pcie on an7581? we can't get mt76 working

15:15 <soxrok2212> looks like pcie bugz

18:25 <enyc> f00b4r0 nbd_ : R.e. this weird slab-leak thingie, I'm not yet certainl but it appears reducing kernel modules loaded (e.g. loads of usb-network usb-modeswitch etc) and also stopping rpcd+uhttpd has stopped triggering the problem e.g. by changing memory layout or so.

18:43 <f00b4r0> enyc: in my experience it's triggered by specific clients, so it depends on wifi conditions

19:25 <merbanan> soxrok2212: did you run sys serdes on the ref code ?

19:27 <merbanan> the pcie scenarios with regards to how wifi is connected are tricky

19:32 <merbanan> in theory you could get one dual lane pci port

19:32 <merbanan> or 2 ports single lane

19:34 <merbanan> the wifi card is supposed to be able to handle both connection types

19:36 <merbanan> I doubt mt76 and the firmware can handle both scenarios

19:56 <soxrok2212> i did not attempt sys serdes on the reference code

20:37 <russell--> real 40m29.647s

20:38 <russell--> still, longer than i recall for a dirclean world build