07:30 <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.)

09:55 <lu_zero> looks like uboot for bpi-r3 is still broken regarding boot to recovery on eMMC

15:28 <colo> https://github.com/openwrt/openwrt/pull/13149 - if anyone's got a feeling about this PR, one way or another, I'd appreciate broader discussion of the pros and cons

15:49 <robimarko> Like others, I am worried about the size increase

15:49 <robimarko> It should probably be linked with larger storage devices only

16:05 <colo> robimarko: what I don't understand is... how come you think some 20kb image size increase make a difference, when devices <16MB flash are not really considered viable anymore?

16:06 <robimarko> colo: Why wouldnt 16MB devices be viable?

16:07 <colo> < - less than - 16MB

16:07 <colo> https://openwrt.org/supported_devices/432_warning

16:07 <colo> TL;DR

16:07 <colo> Too long; didn't read

16:07 <colo> - For OpenWrt 21.02, we recommend 16/128 devices - at least 16Mbytes Flash and 128MBytes RAM.

16:07 <robimarko> My bad, I misread

16:08 <robimarko> But same argument applies, why waste 20k?

16:08 <robimarko> Just make it configurable in menuconfig

16:11 <colo> all this IS already configurable in menuconfig. the point is to change the defaults, so that more capable devices do not have to be forever constrained by an (unviable) least common denominator. why not put the onus on the devices that lack required resources? their users will have to make _other_ tradeoffs with high probability, too, anyway.

16:25 <colo> I wonder if there is any device/target that would become too small/constrained for the current default image, were these additional busbox features enabled. any ideas how one could quickly check for that? is it enough to compare gzipped image sizes with device ToH data?

16:38 <colo> I guess the IMAGE_SIZE variable in the Makefiles is what matters in the end if a generated image is considered viable?

16:51 <colo> some hacky awk later, I arrived at this list: https://coloss.us.to/imgsizes_per_device.txt - does this seem within the realm of the possible? :) (max. image size to be flashed per device supported)

17:45 <swalker> updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html

18:06 <f00b4r0> robimarko: you can't make this per-device choice, since it's busybox.

18:07 <f00b4r0> remember the telnet client argument :)

18:19 <colo> does IMAGE_SIZE refer to the max. size _before_ the resulting squashfs image is gzipped?

18:21 <robimarko> f00b4r0: I know, its not selectable outside of menuconfig itself

18:21 <robimarko> colo: I think that would be the resulting flashable image size

18:22 <robimarko> Its usually for the single "firmware" partition kind of style

18:23 <colo> robimarko: so I guess the toolchain zero-fills a resulting image to pad it to this size, in case the result is shorter than this value?

18:24 <robimarko> colo: No, there is no need for that

18:24 <robimarko> If there is any padding that needs to happen before the end image

18:24 <colo> ok

18:25 <robimarko> There are slim chances of any of the current devices that arent already disabled getting over the limit currently with those 20k

18:25 <colo> according to the TOH, there's no device supported by 22.03.5 that has less than 8MB of flash. that sounds right to you, doesn't it?

18:26 <colo> yeah, I am trying to work that out :)

18:26 <colo> haven't found any candidates so far

18:26 <robimarko> There shouldnt be any 8MB devices enabled by default currently

18:37 <colo> robimarko: are you sure? I see plenty of 8MB devices from the TOH available in the fw selector

18:38 <colo> (but their image sizes are pretty far below the 8MB boundary. mostly below 6MB. so I would argue +20K would not do any harm)

18:44 <f00b4r0> feel free to add the busybox telnet client to that list :3

18:45 <colo> was that a contested addition in the past? :)

18:45 <f00b4r0> it's an extra ~3-5kB depending on target

18:45 <f00b4r0> and was shot down because "bloat". So good luck with your extra 20k :)

18:46 <colo> heh. shot down by whom, and how/where?

18:46 <colo> I'd appreciate others who share my POV on the matter to chime in on the PR btw ;)

18:47 <f00b4r0> PR#10462

18:48 <f00b4r0> in the end we got a separate bsd-telnet package, which is ~40kB installed

18:48 <f00b4r0> but let's not reopen old wounds ;)

18:48 <colo> in 2022 :X

18:48 <colo> jeez

19:07 <colo> is there even anything telnet-bsd can do that socat can't?

19:16 <KanjiMonster> colo: IMAGE_SIZE is usually the size of the image/firmware partition; trying to flash larger images can brick some devices (so this is more a hard limit. Usable maximum image size is a bit less than that, as you require additional space for the overlay jffs partition, which requires 5 erase blocks (so e.g. 320k with 64k erase blocks)

19:17 <colo> KanjiMonster: thanks for the explanation :)

19:30 <KanjiMonster> colo: and while 20k don't seem much, software size only knows one way, up, so with each release the images already grow without even adding anything new

19:31 <KanjiMonster> so any extra software will shorten the time until the image eventually becomes too large and the device unsupported

19:31 <KanjiMonster> that's why there needs to be a good justification for adding additional programs

19:32 <KanjiMonster> death of a thousand cuts etc

19:32 <colo> KanjiMonster: I am aware of that, but that is the perfect argument/pretext for total (userland) stagnation.

19:35 <KanjiMonster> a good justification is software required to connect to the internet; because without it you'll end in a catch-22. most other things are fine as extra packages, since once you have internet, you can just install it via opkg

19:35 <colo> the better hardware becomes, the less those 20KB are going to matter. when the next batch of devices with ~8M flash has to die away due to everything having grown even more, these 20K are SO TINY when measured against the whole

19:35 <colo> KanjiMonster: I actually cannot install a better busybox via opkg ;)

19:36 <colo> (unless I build it myself first. but then why would I not install a custom image?)

19:36 <KanjiMonster> sure, but usually you can install the full version of the software instead

19:37 <colo> true, but this PR is not dealing with any software, it is dealing with busybox. it has a wealth of great features that come at so tiny a cost, and there is no way to retrofit them after the fact that the image has been built. I'd argue it is a special case.

19:38 <colo> (fwiw, I do build/glue together my own images using the image builder for all my devices, but nothing I can do with that will ever make ash have history search, which makes me really sad whenever I have to use the OpenWrt shell ;))