03:37 <yolo> there is lua5.3 under package/utils, no lua5.4 yet, is it nobody-cares or lua5.4 breaks things? I'd like to have 5.4

03:39 <dwfreed> as I understand it, the various lua "point" releases are not particularly compatible

03:40 <yolo> that's true, unfortunately

03:45 <yolo> had a look, about 10 lua files all from luci

03:50 <dwfreed> there are other packages that use lua as well

03:50 <dwfreed> I believe some of the pdns packages are built with lua support

04:00 <yolo> jow: is luci lua-free now? or there are still critical packages need luci-compat?

04:01 <yolo> standard build I only saw one lua file: usr/lib/lua/cjson/util.lua which is from cjson I think? it's lua5.4 safe

04:02 <yolo> lua should be safe to upgrade to 5.4 as long as luci no longer uses it, the popular luarocks openwrt included are all 5.4 ready i think, it's really just the old luci 5.1 stuff I assume

04:03 <yolo> I added cjson myself, without cjson, without luci-compat, the rootfs has no lua file

04:07 <yolo> some external network packages(not in the default build), and luci are where lua files exist

04:20 <yolo> nhandled exception during request dispatching

04:20 <yolo> module 'luci.ucodebridge' not found:

04:21 <yolo> no field package.preload['luci.ucodebridge']

08:54 <oliv3r[m]> How do I properly define a PHY_INTERFACE_MODE_10GBASER | PHY_INTERFACE_MODE_1000BASEX port in the dts's phy-mode node? Since this is an SFP+ port, it depends on what you insert, or does the phy-mode in the dts just set the initial/highest mode and after that, it doesn't matter? (in my case, I must set it to 1000basex as otherwise the driver does some weird shit)

09:03 <Znevna> https://github.com/openwrt/openwrt/commit/77d061167cf8a7edb3ea7cbc9926f25c8ac8fe1e#commitcomment-101107194

09:03 <Znevna> first report from ramips hell :P

09:05 <Znevna> https://github.com/openwrt/openwrt/pull/11220

09:08 <owrt-snap-builds> Build [#749](https://buildbot.openwrt.org/master/images/#builders/71/builds/749) of `bcm4908/generic` failed.

09:08 <owrt-snap-builds> Build [#330](https://buildbot.openwrt.org/master/images/#builders/75/builds/330) of `realtek/rtl930x` failed.

09:24 <Znevna> hmm

09:25 <Znevna> if ubi partition was resized in dts, how do I make the system recognize the change?

09:25 <Znevna> doing a `reset to defaults` seems to retain the old size

09:27 <Znevna> I'm guessing only using sysupgrade -n .. right?

09:44 <stintel> soooo .... https://patchwork.ozlabs.org/project/openwrt/patch/mailman.13941.1675951439.3064139.openwrt-devel@lists.openwrt.org/ is a backport. so even though it is only relevant to ramips, does it not belong in target/linux/generic/backport-* instead, with the kernel version where it was accepted as prefix in the filename ?

09:50 <stintel> hah, it's not even in linux.git yet

09:53 <stintel> also, do we still need target/linux/ramips/patches-5.15/10{1..8} ?

09:55 <stintel> ah wait, some we do

09:56 <stintel> and grabs some ramips hardware from storage

09:56 <Znevna> hmz

09:57 <Znevna> how do I make sysupgrade to not keep the old ubivol ?

09:57 <Znevna> >.>

09:57 <Znevna> without increasing the compat version

10:00 <stintel> ah ok we still need all of that, the driver was moved from staging in 5.15

10:00 <stintel> 5.16*

10:01 <stintel> but same question here then, shouldn't we move it to generic/backports-5.15/xxx-v5.16-yyy

10:22 <Znevna> hmm

10:23 <Znevna> so if the image check fails because of compat version, and you uncheck keep settings, it still requires to force upgrade?

11:24 <Znevna> even trying to flash the image with resized ubi from a normal initramfs fails

11:24 <Znevna> >.>

12:36 <owrt-snap-builds> Build [#460](https://buildbot.openwrt.org/master/images/#builders/72/builds/460) of `imx/cortexa9` failed.

14:01 <owrt-snap-builds> Build [#782](https://buildbot.openwrt.org/master/images/#builders/56/builds/782) of `kirkwood/generic` completed successfully.

14:30 <yolo> error: ext4_allocate_best_fit_partial: failed to allocate 813 blocks, out of space? -- this is odd, caused by a git-pull-from-master then run make, increase rootfs size from 104M to 512M to no help, do I need re-run the one-hour build-from-scratch?

14:31 <yolo> before the git-pull there was no problem, the true size should be like 50MB at most

14:31 <yolo> anyway, rebuilding

16:03 <mrnuke> robimarko: hi

16:23 <robimarko> mrnuke: Hi

16:30 <mrnuke> robimarko: Mi reason for trying to fix the ipq-wifi issue(s), is that once I get WAX218 merged, chances I'll look at it are slim. I need to rebase the entire 6018-devel branch.

16:31 <mrnuke> robimarko: I won't have any motivation to work on ipq-wifi after that, and I think the situation will likely stay in the status quo

16:31 <robimarko> mrnuke: I get what you are trying to achieve

16:31 <robimarko> But, shipping all of the BDF-s if not building for all devices is crazy

16:32 <mrnuke> I'm no longer shipping all BDF-s in the current incarnation

16:33 <robimarko> I asked on the PR about that and got: To answer your question regarding the proposed solution, without selecting CONFIG_TARGET_PER_DEVICE_ROOTFS, all enabled ath11k-wifi* packages are included in the rootfs, the correct one is found by the hotplug script, and wifi works.

16:34 <mrnuke> That's only part of the answer. Without CONFIG_TARGET_PER_DEVICE_ROOTFS, your ipq8074 device's wifi likely won't work becayse it has the wrong board-2.bin

16:35 <mrnuke> I try to boot my WAX218. dnesg says it can't find board-2.bin. I look the file is there. I hexdump it, and it has "Dynalink ..." instead of "Netgear ..." in the header

16:35 <robimarko> Currently no BDF is shipped when CONFIG_TARGET_MULTI_PROFILE and CONFIG_TARGET_PER_DEVICE_ROOTFS are used

16:36 <robimarko> That is by design as buildsystem does not respect DEVICE_PACKAGES for initramfs

16:37 <mrnuke> Then I don't understand how the correct board-2.bin would get into the rootfs (or initramfs for that matter)

16:37 <robimarko> Currently, you get the BDF in initramfs only if building for that device only

16:38 <robimarko> But, for any non-initramfs image you will get the correct BDF

16:38 <robimarko> As DEVICE_PACKAGES is evaluated per device

16:40 <mrnuke> Then why I got the wrong BDF on WAX218 is still a mystery

16:41 <robimarko> Yes, that is not supposed to be even possible to happen

18:49 <mrkiko> robihi!! thanks for your feedback on the patch

18:49 <mrkiko> oops, :D

19:42 <arinc9> testing

19:45 <arinc9> Can a openwrt wiki admin create a new brand called "Huasifei" for this new device?

19:45 <arinc9> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=efbb623debef3c63eebc9b849f6ca57130efa5f4

19:53 <yolo> i'm pretty sure the default CONFIG_TARGET_ROOTFS_PARTSIZE has to change to 160MB otherwise ext4 image will fail for x86_64

19:57 <yolo> default 104 will lead to: error: ext4_allocate_best_fit_partial

22:33 <owrt-snap-builds> Build [#781](https://buildbot.openwrt.org/master/images/#builders/19/builds/781) of `ramips/mt7621` completed successfully.

22:57 <djfe> I wanna help clean up stale/resolved issues on Github, I already got like 2 or 3 of them. Whom can I contact to get them closed? Or is it possible to flag such issues with the bot?