05:23 <owrt-images-builds> Build [#55](https://buildbot.openwrt.org/images/#/builders/226/builds/55) of `main_mvebu/cortexa9` completed successfully.

08:18 <owrt-images-builds> Build [#38](https://buildbot.openwrt.org/images/#/builders/260/builds/38) of `main_stm32/stm32mp1` failed: failed GNU tar built and installed (failure)

09:39 <Borromini> Hey guys. I was wondering if there's a way to differentiate between packages to include in ramdisks and in regular factory/sysupgrade images.

09:40 <Borromini> rtl838x has a lot of devices that require ramdisk installations from OEM, but they also have older bootloaders that restrict image size.

09:41 <Borromini> which means once you start adding a few packages, sysupgrade images do get built but initramfs ones don't

09:45 <Borromini> i've been looking through include/image.mk but DEVICE_PACKAGES obviously lumps everything together.

09:45 <robimarko> Not AFAIK

09:46 <robimarko> Detangling that would probably mean more work like what was done for generating per device initramfs

09:47 <robimarko> As rootfs would need to generated per image instead of per device so that separate initramfs and other images can actually have different packages

09:49 <Borromini> thanks robimarko

09:50 <Borromini> i was eyeing the per device setting to abuse that indeed.

11:19 <f00b4r0> also, jow: is there any chance ucode#220 could be included for 24.10.0?

11:23 <owrt-images-builds> Build [#52](https://buildbot.openwrt.org/images/#/builders/218/builds/52) of `main_ipq40xx/generic` completed successfully.

11:29 <nbd> f00b4r0: i think it makes more sense to keep the curl module outside of the ucode repo

11:29 <nbd> since curl is not part of core packages

11:29 <nbd> openwrt already has a few ucode module packages

11:29 <nbd> so you could just add a ucode-mod-curl package to the packages feed

11:31 <f00b4r0> ah ok

11:32 <f00b4r0> didn't think of that

11:33 <f00b4r0> i guess that also means the modules in packages don't get the nice webdoc treatment though :)

11:35 <f00b4r0> nbd: one downside is that any API change (and I suspect there will be, since this ucode is all fresh and new) will be harder to track with module dissemination. Would be nicer imho to have all modules in the main repo, and then build/include as needed

11:38 <nbd> jow is careful to avoid any unncessary ABI breakage in ucode

11:38 <f00b4r0> famous last words :)

11:39 <f00b4r0> this also means that ucode packaged outside of owrt doesn't get said modules, unless the outsider packagers are dedicated enough to handpick them as well

11:39 <f00b4r0> can't say I like this idea

11:41 <f00b4r0> hmm so I tracked down my discrepancy above: network.interface dump and network.interface.wan dump disagree on the value of "up"

11:41 <f00b4r0> isn't that a bug?

11:41 <f00b4r0> 'network.interface.wan status', sorry

13:35 <schmars[m]> i maintain ucode-mod-wireguard which has worked fine without touching it for >1y

13:36 <schmars[m]> i should probably propose it for one of the official feeds

13:43 <schmars[m]> i'm doing it with the netns trick, so the existing stuff (netifd/luci) didnt work for that

15:23 <efahl> f00b4r0: does ucode#220 do something beyond what's offered in ucode-mod-uclient that you need?

15:24 <efahl> I've been using the uclient mod for GET/POST for a while (in owut) and it has worked great for me

15:25 <f00b4r0> it's owrt centric

15:25 <efahl> ah! got it

15:25 <f00b4r0> (i also didn't know about mod-uclient, which goes to show that stuff that's disseminated is less visible)

15:26 <f00b4r0> in any case it would be nice to get some form of feedback about this PR. I started it because there was initial interest (from jow) but I don't know if that's still the case

15:26 <efahl> yes, that's major issue, the out-of-sight mods don't get documented at all

15:27 <f00b4r0> i use ucode inside and outside of openwrt, so I'm interested in things that work either way

15:27 <f00b4r0> work out of the box*

15:36 <f00b4r0> schmars[m]: out of curiosity, what's the peak number of connected clients per phy that you're seeing on your mt7915e devices?

15:37 <schmars[m]> definitely at least 50. i can look for a more precise number if that helps

15:38 <f00b4r0> that's ok thanks, I'm curious what's the max "capacity" of these devices tbh

17:34 <br0ken> any plans for the fritzbox 7530 AX?

18:32 <owrt-images-builds> Build [#50](https://buildbot.openwrt.org/images/#/builders/95/builds/50) of `main_ath79/generic` completed successfully.

20:19 <slh> br0ken: afaik that one is Broadcom based? if so, not going to happen, ever

20:23 <slh> and yes, https://boxmatrix.info/wiki/FRITZ!Box_7530_AX is Broadcom (there is a QCA based 7530AX v2, which may be a different story)

20:26 <slh> apart from that, there are nevery any plans. someone who owns the device has to do the necessary porting work, if you know what you're doing and have a 'simple' case (SOC and everything already having full support) that will take at least an extended long rainy weekend, if not the learning curve is steep and easily takes weeks. so unless you are planning to work on it yourself, it's not all too likely

20:26 <slh> that anyone else will - very regional device availability doesn't necessarily help finding other contributors either

20:35 <Slimey> and you submit something and might it sit in limbo forever..

20:42 <totkeks> Slimey, the PR?

20:44 <SlimeyX> ya

20:44 <slh> having a PR raises the chance of it being merged considerably over there not being any PR at all

20:45 <SlimeyX> oh there is a PR

20:46 <totkeks> he said considerably, not guarantee :)

20:49 <SlimeyX> exactly

20:52 <slh> the safe advice would be to only consider devices that are fully supported, everything else if a betting game, with the odds stacked against you

20:55 <slh> back on topic, for the 7530 AX (bcm63xx), it's game-over from the start. for the 7530 AX v2 (ipq50xx) it wouldn't be impossible, but pending a lot of work (ipq50xx target support not merged yet, no one at all working on 7530 AX v2 device support so far); for either device, FXS ports unsupported, DECT unsupportable, xDSL maybe (for the v2, hard no for the v1)

20:56 <slh> months+ at least

21:13 <schmars[m]> if it's ipq50xx then very low chances - everything is missing, same issue with the mikrotik ipq50xx devices

23:14 <owrt-images-builds> Build [#54](https://buildbot.openwrt.org/images/#/builders/210/builds/54) of `main_mediatek/mt7622` completed successfully.