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

03:18 <owrt-images-builds> Build [#271](https://buildbot.openwrt.org/images/#/builders/142/builds/271) of `master_bcm27xx/bcm2711` completed successfully.

05:21 <owrt-images-builds> Build [#269](https://buildbot.openwrt.org/images/#/builders/124/builds/269) of `master_bcm27xx/bcm2710` completed successfully.

07:45 <Habbie> can somebody merge https://github.com/openwrt/packages/pull/23790?

08:42 <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.)

10:49 <neocturne> Ansuel: currently having a look at the qca8k patches again, and I have a question regarding the "enable assisted learning on CPU port" change

10:51 <neocturne> I understand why QCA8K_PORT_LOOKUP_LEARN is cleared for the CPU ports, but why is the same clearing removed for user ports, which have this bit controlled by bridge flags when offloaded?

10:51 <Ansuel> new dsa implementationrequire learning to be enabled separately

10:51 <neocturne> The comment reads like the intention was to clear the bit for all ports, both CPU and user

10:53 <Ansuel> also the assisted is for adding the entry for the wifi interface if i'm not wrong

10:54 <neocturne> I'm specifically asking why the learning bit is not initialized for user ports anymore (left at reset value?), that part looks unintended

10:56 <neocturne> I'm talking about the part ll.40-44 here: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/pending-6.6/712-net-dsa-qca8k-enable-assisted-learning-on-CPU-port.patch;h=18afa1c0725170d7e31668865bd400dc2448c18b;hb=HEAD

10:57 <neocturne> The same lines were previously changed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/dsa/qca/qca8k-8xxx.c?id=23cfc7172e5297d0bee49ac6f6f8248d1cf0820d

10:57 <neocturne> Where the bit was changed from enabled to disabled, but now it's not at at all anymore

10:57 <neocturne> *not set

11:12 <neocturne> Maybe the intention was to move the lines into the dsa_switch_for_each_port() loop, rather than the dsa_switch_for_each_cpu_port() loop?

11:16 <Ansuel> neocturne i smell refresh problem and the code got moved to the wrong loop? or totally fkup by my side

11:24 <neocturne> I can push a patch that moves it to the other loop to my staging, but I'm not sure what I should do to test the change, besides verifying that the register value is set as expected

11:28 <Ansuel> well the thing should be learning disabled for cpu port and assisted enabled

11:28 <Ansuel> just check if the reg is correct

11:28 <Ansuel> and maybe we can compare fdb entry with bridge fdb show

16:36 <owrt-images-builds> Build [#274](https://buildbot.openwrt.org/images/#/builders/93/builds/274) of `master_ramips/mt7620` failed.

17:54 <stefanct> ive been trying to use my host toolchain to build openwrt HEAD for a ramips target. i've not investigated the problem at all but the message seems to indicate that the check itself is at least a bit broken/incomplete.

17:54 <stefanct> "Testing external toolchain for softfloat support ... Toolchain directory '--cflags' does not exist."

18:04 <stefanct> seems like CONFIG_TOOLCHAIN_ROOT is not set at that point

18:17 <stefanct> which apparently should come from the kconfig but that's a bit odd... since the setting for that is hidden once you select "Use host's toolchain"

18:21 <stefanct> which is exactly how the kconfig is coded so... i am not sure how this is supposed to ever work :)

20:47 <Mangix> Habbie: on it

20:48 <Mangix> https://github.com/mesonbuild/wrapdb/pull/1555 <-- we need something like this for the packages feed.

21:36 <Habbie> Mangix, don't we have that? i get emails

21:37 <Mangix> it's the autoupdate that we need.

21:38 <Habbie> ah right

21:38 <Habbie> alpine has an 'abump' tool that updates the APKBUILD (like our Makefiles) and starts a build

21:39 <Habbie> but after that you can run on that system so for openwrt it's all slightly trickier

21:39 <Habbie> the meson one can submit PRs, that's a nice middle ground

22:18 <Habbie> Mangix, thanks for the merge!