08:45 <goetz> HI

09:07 <Mangix> hello

10:58 <jow> Jimbot_: regarding your gpl dump hosting question, did you consider simply imnporting it into a git repository and pushing it to github.com ?

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

10:59 <Habbie> excellent place for it

11:32 <Jimbot_> thanks jow, good plan. I was wondering if there was a convention since I'd seen a mix of dead links looking around the forum

11:58 <mrkiko> So, I noticed latest snapshot are no longer respecting TARGET_ROOTFS_PARTSIZE - at least mediatek/filogic/gl-mt2500 and I was wondering if this comes from last fstools bump. Now the overlay expands to the entire available space on a partition. I do like this but I wonder if this is expected or not, and if expected wwould like to know what commit is causing it, I suspect the fstools driver priority

11:58 <mrkiko> change. Any advice or help apreciated.

13:20 <rmilecki> sysupgrade changes pushed

13:20 <rmilecki> test & report :)

13:22 <mrkiko> rmilecki: well, you implemented one of the most requested features ever :D :D

13:25 <rmilecki> surely not

13:25 <rmilecki> but hopefully something useful :)

13:28 <mrkiko> rmilecki: would it make sense for you to report a list of services that willbe disabled on sysupgrade when using the -l flag ?

13:30 <mrkiko> robimarko: svanheule was talking about the aqr patch I submitted some time ago

13:30 <robimarko> mrkiko: I remeber that AQR temperature one

13:30 <rmilecki> mrkiko: sysupgrade -l may be a bad idea as it's output is just a list of files

13:30 <rmilecki> who know if some custom solution doesn\t parse its output

13:30 <mrkiko> robimarko: and svanheule was suggesting me to try again, but looking again at the thread I am sure the right way to go is to implement DT reading of limits

13:31 <rmilecki> maybe add a new option for listing backup files and disabled services and packages to reinstall

13:31 <mrkiko> rmilecki: yes, to have a way to easily tell what's going to happen during sysupgrade

13:32 <rmilecki> i like that

13:32 <rmilecki> [OpenWrt-Devel] How to keep disabled services disabled after sysupgrade https://openwrt-devel.openwrt.narkive.com/phfNcKUH/how-to-keep-disabled-services-disabled-after-sysupgrade

13:32 <rmilecki> 9 years ago :)

13:34 <mrkiko> rmilecki: may be you can add a warning for scripts to not use this output for parsing, so that we can extend this if further features are implemented ?

13:35 <mrkiko> rmilecki: but I am under the impression that if this gets complex enough, at some point luci will need a way to present those informations to the user somehow

14:07 <jow> rmilecki: mrkiko: if at all you should probably introduce a new kind of status/information output

14:08 <jow> not reuse the file listing mode which is indeed intended for scripting

14:08 <rmilecki> yeah, if we're talking about involving LuCI then some ubus method probably?

14:13 <jow> not sure if it is really needed in LuCI

14:13 <jow> it's not as if the user can change anything about it at this point

14:15 <mrkiko> jow: infact, not directly. They need to go back and disable /reenable servies as they see fit

16:14 <Borromini> robimarko: sorry, was offline when you responded yesterday. How did you boot OpenWrt off the RB5009UG before, if you say you just switched it to the AUX loader?

16:30 <robimarko> Borromini: I ported U-Boot and used it to boot from NAND directly

16:31 <Borromini> ah, yes I forgot

16:32 <robimarko> This device is a major pain in the ass

16:32 <robimarko> Because I need to use U-Boot to be able to boot FIT images so I can test upstream kernels

16:32 <Borromini> :)

16:33 <robimarko> Since its probably time to upstream those mv88e6xxx fixes

16:33 <Borromini> :)

16:33 <Borromini> does RouterBOOT do any network initialisation? I forgot.

16:33 <robimarko> Yes

16:33 <robimarko> It for sure is setting LED-s at least

16:33 <robimarko> Other stuff is reinited by kernel anyway

16:34 <robimarko> BTW, I have no idea why 2.5G is not being advertised

16:36 <Borromini> no, I saw on the forum

16:43 <Borromini> robimarko: is your U-Boot port functional enough to be integrated into OpenWrt? Because that would mean RB5009 support could be merged as well, no?

16:44 <robimarko> Borrromini: There was an issue if you used U-Boot to write on NAND, but other than that it worked fine to boot

16:44 <Borromini> ok

16:45 <robimarko> There is an issue that you cannot really update U-Boot

16:45 <robimarko> Because it sits in YAFFS and you can only write it from jailbroken RouterOS

16:46 <robimarko> We could probably use Yafut to boot from YAFFS directly

16:47 <robimarko> But we cannot append DTB to ARM64 images

16:51 <Borromini> yeah it's coming back to me now.

16:52 <robimarko> Yeah, and its reminding me why I dont want to touch MikroTik devices

17:08 <rmilecki> what's the problem with MikroTik & OpenWrt? i only keep hearing about YAFFS

17:08 <rmilecki> why is that an issue?

17:08 <rmilecki> can't we have OpenWrt use UBI?

17:08 <robimarko> Nope

17:08 <robimarko> Because MikroTik uses their RouterBoot bootloader

17:08 <rmilecki> it just loads kernel, right?

17:09 <robimarko> Yes, usually

17:09 <robimarko> But, it only supports ELF binaries

17:09 <rmilecki> so does RouterBoot matter?

17:09 <robimarko> Yes

17:09 <Borromini> RouterBoot has been crippling a lot of MikroTik stuff when it comes to OpenWrt, from what I read

17:09 <robimarko> Because we have hacked around its limitations for years

17:10 <robimarko> It can only load ELF images

17:10 <rmilecki> is that bad? i never tried generading ELF kernel

17:10 <robimarko> And it will always pass the stupid broken DTB from flash they use

17:10 <rmilecki> ah

17:10 <robimarko> For MIPS and ARM we work around that by patching in a DTB to the kernel

17:11 <rmilecki> could we have intermediate u-boot between RouterBoot & OpenWrt kernel?

17:11 <robimarko> But for ARM64 kernel has no support for doing stuff like that

17:11 <robimarko> Yes, it can load U-Boot

17:11 <robimarko> But for most boards there is no public U-Boot for the SoC

17:11 <robimarko> Not to mention that they disable UART by default

17:12 <rmilecki> oh, fun

17:12 <robimarko> Now even to the point where they ignore their features in NOR

17:12 <robimarko> Which usually allowed to enable UART

17:12 <robimarko> For RB5009 they quite literaly disabled UART in RouterBoot so we have a binary patched RouterBoot that enables UART

17:13 <rmilecki> oh crap

17:14 <robimarko> So we have been trying to workaround their crap for years

17:14 <robimarko> But every time there is progress they quickly change stuff in new boards

17:17 <goetz> reading your exchange about mirkotik, do you know why the hinder that work?

17:23 <Borromini> because they can, probably

17:25 <robimarko> Most likely, other than than no idea why they care if you are not running ROS since its not paid extra.

19:59 <jow> did we recently update our toolchain?

19:59 <jow> or parts of it?

19:59 <jow> some weird bug reports lately

20:00 <jow> https://github.com/openwrt/openwrt/issues/14681

20:00 <jow> https://github.com/openwrt/openwrt/issues/14573

20:00 <robimarko> I can only remember cmake, expat and ccache being updated

20:22 <Ansuel> jow i bet it's mold

20:36 <Borromini> Ansuel: a question about the PHY package API - is it weird to see just two PHY driver needing an update for the base_addr? Or is that just me and are there that few package PHYs supported upstream?

20:36 <robimarko> It wasnt used a lot upstream

20:37 <Ansuel> Borromini only a few used them and across them only 1-2 used those api to write something

20:44 <Borromini> ok thank you both

21:46 <hauke> jow: The user activated GCC 13