02:13 <SlimeyX> https://paste.ee/p/cwazL :P

05:33 <\x> is there a way to toggle that 2Gbps thingy on MT7621A devices? do I really have to do it like this? https://imgur.com/a/IF2DVTy

09:27 <lu_zero> Hi

09:29 <lu_zero> I'm trying to understand how the kmods are packaged

09:30 <lu_zero> in `include/feeds.mk` it refers to a separate directory

09:30 <robimarko> What do you mean by packaged?

09:30 <robimarko> Like how to package one or?

09:31 <lu_zero> but I see the kmods living in bin/targets/mediatek/filogic/packages

09:31 <robimarko> The end product of a kmod package is just a package like any other

09:32 <lu_zero> while the feed generated would look for them in targets/mediatek/filogic/kmods/5.15.116-1-bdae4679f2f5d20b189bae3e18a6de77

09:33 <lu_zero> I know it is just a package like any other, but I do not see where is a configuration switch to generate a separate dir and its Packages.gz

09:39 <lu_zero> welcome back :)

09:51 <lu_zero> robimarko: do you happen to know where is set the directory the ipkg are placed after they are built?

10:23 <robimarko> lu_zero: No, I dont know the exact place

10:44 <\x> Ansuel: https://oftc.irclog.whitequark.org/openwrt-devel/2023-06-16#32233424;

12:26 <KGB-2> https://tests.reproducible-builds.org/openwrt/openwrt_x86.html has been updated. (100.0% images and 100.0% packages reproducible in our current test framework.)

13:38 <tomn> hi, is there a known way to fix issues with autotools projects picking up host libraries by mistake? specifically i'm having trouble with f2fs-tools linking against /usr/lib/libuuid.so, which goes about as well as you'd expect https://clbin.com/S4ZDU

13:40 <tomn> i've tried setting TARGET_LDFLAGS, but those appear after -luuid in the linker command-line so it doesn't have any effect

13:53 <f00b4r0> jow: I'm trying to catch netdevs going up/down, but there doesn't seem to be a ubus notification for this type of event. Am I missing something?

14:11 <tmn505> tomn: that is strange, it builds fine on my system. Here's my config log: https://clbin.com/NBnCI, and here's compilation output: https://clbin.com/yhNDF for comparison.

14:19 <tomn> tmn505: ah, thanks for giving it a go. do you have /usr/lib/libuuid.so on your system?

14:24 <tmn505> I do lrwxrwxrwx 1 root root 12 06-20 08:56 /usr/lib/libuuid.so -> libuuid.so.1

14:25 <tomn> ok, thanks

14:29 <tmn505> header is also in place /usr/include/uuid/uuid.h

14:29 <mrkiko> robimarko: ny chance, any place I can find reference to what ipq4xx devices are being hit at the moment by the 4MB kernel size limit?

14:31 <mrkiko> Wondering if we could somehow repurpose the small u-booty for the fritz!box 7530 to help us out

14:36 <tomn> tmn505: sorted, thanks, it was my odd build system...

14:36 <SlimeyX> Ansuel ill fix the bsap-192x issues when im *working* from home ;P

14:40 <tmn505> mrkiko: I'm not sure if remember this correctlly, 4MiB problem seem to be an issue with 'bootipq' command implementation in qualcomm U-Boot, it should not affect 'bootm' command. So altering bootcmd variable in U-Boot environment to boot using 'bootm' should fix most devices.

14:40 <tmn505> wait for robimarko to clarify

14:45 <mrkiko> tmn505: thanks a lot for the hint!

15:19 <robimarko> tmn505: There isnt really any kind of a list

15:20 <robimarko> But it seems that most SPI-NOR only devices will hit that limit due to poor implementation by QCA and/or vendors

15:27 <tmn505> thanks, I'll check if this affects my devices

16:48 <tmn505> robimarko: so luma_wrtq-329acn (SPI-NAND uses FitImage recipe) seem to be fine, ubinfo shows 4317184 bytes for kernel (caveat: does not use bootipq). pakedge_wr-1 (SPI-NOR uses FitImageLzma) is also fine, kernel occupies 3145728 bytes. I'll check if pakedge device accepts kernel created with FitImage and FitzImage recipes.

17:24 <robimarko> tmn505: UBI devices wont be affected as they are loading the kernel volume dynamically

17:25 <robimarko> Only SPI-NOR devices

18:17 <lu_zero> hi

21:31 <djfe> mrkiko: tmn505: it might be better to implement lzma-loader instead. It won't require users to modify their bootloader environment variables and make the images smaller at the same time :)

21:34 <djfe> here's the only example so far where it was fixed by asking users to modify their bootcmd https://github.com/openwrt/openwrt/commit/45eb57f12f3a128a1822a20b7e536527ab92ca67

21:36 <djfe> it also shows the error message on serial that users will face when they sysupgrade to an image that is too large (not every device in generic.mk sets KERNEL_SIZE := 4096k to prevent such images from being built)

21:38 <djfe> I know lzma loader is not the most elegant solution but it requires the least changes and allows people to install newer openwrt versions from factory without an intermediate step using openwrt-22.03 or opening the device for serial access.

21:44 <f00b4r0> djfe: it also considerably slows down boot

23:16 <slh> what does consdierable slowdown mean in this regard? 5s, 10s (just guessing for a rough ballpark, no idea how long it really takes)? ipq40xx is a (quad-) ARMv7 running at 716 MHz, it shouldn't be thaaaat bad (as in half a minute or more)