08:43 <rmilecki> i can't get much help on this, I think I'll just push:

08:43 <rmilecki> [PATCH RFC] base-files: execute package's "postinst" after executing uci-defaults

08:43 <rmilecki> https://patchwork.ozlabs.org/project/openwrt/patch/20231126202428.1158-1-zajec5@gmail.com/

08:43 <rmilecki> and wait to see what happens

10:14 <ynezz> f00b4r0: hi, can I get review/ACK https://github.com/openwrt/buildbot/pull/22 ?

10:16 <ynezz> f00b4r0: seems like buildbot 3.9.0 is borken, and instead of backporting fix I've simply decided to bump to 3.10.0

11:12 <ynezz> f00b4r0: so I actually went with the workaround and with v3.9.0 as you've probably tested your changes with that release, prepared the bump in other pull request

11:12 <ynezz> (bump to v3.10.0)

11:30 <f00b4r0> ynezz: hi, ok. I had no idea about that PR anyway so sounds good

13:01 <ynezz> f00b4r0: https://buildbot.openwrt.org/master/packages/#/ buildbot changes deployed

13:04 <ynezz> omg cdn strikes again

13:05 <ynezz> too many if-s in jinja templates

13:14 <f00b4r0> ynezz: afaict it's still running the old factory

13:21 <ynezz> changed=3 should be deployed now

13:23 <f00b4r0> looks better

13:23 <f00b4r0> let's see if it blows up

13:24 <f00b4r0> (let's hope not because I don't have time to deal with it now, and won't till year end)

13:25 <f00b4r0> hmm

13:25 <f00b4r0> make -j6.0

13:25 <f00b4r0> wtf

13:26 <f00b4r0> str(int(props["nproc"]) / max_builds[props["workername"]])

13:27 <f00b4r0> how can this ever be 6.0

13:28 <f00b4r0> ynezz: my impression is that the max_builds property is not used on phase2, can you confirm? If so I'll just push to remove it entirely (as was done on phase1) and hopefully this will fix it

13:29 <ynezz> f00b4r0: ack

13:29 <f00b4r0> ok, cooking a patch

13:35 <f00b4r0> done. prepping PR

13:37 <f00b4r0> #25

13:37 <f00b4r0> untested but aligns the code with phase1 so am fairly confident

13:41 <ynezz> deployed that change manually now

13:41 <f00b4r0> thx, looking at web Ui

13:44 <f00b4r0> make -j3. Looks good

13:45 <f00b4r0> i think we're golden. The next hurdle will be network operations, i'll try to keep an eye out

13:46 <ynezz> great, thanks!

13:51 <dwfreed> f00b4r0: if max_builds[props["workername"]] is a float, that would produce a float

13:51 <f00b4r0> dwfreed: but str(int( ?

13:51 <dwfreed> the int() is only around props["nproc"]

13:51 <f00b4r0> oh damn

13:51 <f00b4r0> good catch

13:51 <f00b4r0> anyway I'm happy to have gotten rid of this legacy garbage^Wcode :)

13:52 <dwfreed> :)

14:09 <ynezz> anyone having something for pushing into master/22.03/23.05? :)

15:42 <Habbie> if uboot printenv tells me

15:42 <Habbie> bootcmd=cp.b 0xbfe00000 0x100000 0x100000; bootelf 0x100000

15:42 <Habbie> how should i set up my image?

15:43 <Habbie> in a 'define Device/x' i mean

15:47 <Habbie> ah, initramfs-kernel.bin is/starts with an ELF thing

17:37 <jetm> About the Ethernet device naming convention that OpenWrt follows. Does OpenWrt guarantee the Ethernet interfaces will use the traditional eth[0-N]?

17:48 <schmars[m]> jetm: with DSA it's usually lan[1-N]

18:59 <sandberm> Does anyone know what's the minimum journal size for ubifs? I have a payload that takes 53 LEBs and 78 LEBS are needed to create that filesystem. Can I take that ratio? I am creating a static volume so I wonder if a journal is needed at all.

19:15 <Habbie> i know this is a bit of a broad question. I have a Juniper SRX210. It's a Cavium CN5020, just like ubnt_unifu-usg (edgerouter lite). bootelf on openwrt-octeon-generic-ubnt_edgerouter-lite-initramfs-kernel.bin (unmodified, just built for ERL) after tftp'ing it into memory gives me U-Boot Exception, Cause: 2

19:15 <Habbie> i do notice things like

19:15 <Habbie> Loading .text @ 0x81100000 (0x7db2c0 bytes)

19:15 <Habbie> that address is just over the 2GB mark

19:16 <Habbie> i'm assuming uboot just handles physical memory, nothing virtual

19:16 <Habbie> could trying to write outside of RAM be the reason? or am i perhaps missing some uboot knowledge?