05:20 <owrt-images-builds> Build [#419](https://buildbot.openwrt.org/images/#/builders/205/builds/419) of `master_mpc85xx/p1020` failed.

07:32 <linusw> russell--: I applied and pushed the patch now, just being slow because of process...

08:08 <ynezz> its just me or did cmake went crazy?

08:09 <ynezz> https://github.com/doctest/doctest/releases/download/v2.4.11/doctest.h: 22;"HTTP response code said error"

08:09 <ynezz> this is error during tools/cmake compile step from Build [#2](https://buildbot.openwrt.org/images/#/builders/288/builds/2) of `openwrt-24.10_imx/cortexa9` failed.

08:09 <ynezz> seems like they're downloading some stuff during build?

08:11 <ynezz> ah, my bad, sorry cmake :)

08:11 <ynezz> its lzo actually

08:12 <russell--> linusw: thank you!

08:12 <ynezz> err, not lzo, but tools/ccache

08:15 <russell--> linusw: openwrt-24.10 branch should probably cherry-pick it as well?

08:42 <owrt-images-builds> Build [#435](https://buildbot.openwrt.org/images/#/builders/25/builds/435) of `master_realtek/rtl838x` failed.

08:44 <mrkiko> If anyone has some review bandwidth - https://patchwork.ozlabs.org/project/openwrt/patch/20241021214007.46334-1-mrkiko.rs@gmail.com/

08:44 <mrkiko> this is an one-liner to fix media boot type fort mt7981 RFBB

08:46 <mrkiko> Instead this one adds support for a new device in mediatek target, including u-boot - https://patchwork.ozlabs.org/project/openwrt/patch/20241103163039.32823-1-mrkiko.rs@gmail.com/

08:46 <mrkiko> thanks all

08:49 <mrkiko> btw - the last patch - adding support for the device, is supposed to super-seed https://patchwork.ozlabs.org/project/openwrt/patch/20241023173635.63277-1-mrkiko.rs@gmail.com/ which was meant to spark some discussion but didn't.

10:05 <owrt-images-builds> Build [#420](https://buildbot.openwrt.org/images/#/builders/198/builds/420) of `master_ath79/mikrotik` failed.

10:10 <robimarko> aparcar: For some reason all of the docker container actions have been stuck in queued only since yesterday

10:15 <aparcar[m]> Yikes I’ll have a look soonish

10:16 <robimarko> It seems that somehow none of the organisation builders are picking any jobs from that repo

10:16 <robimarko> BTW, ynezz reverted the change to Debian 12 today

10:16 <robimarko> No idea if that is going to cause chaos again

10:33 <ynezz> AFAIK this Debian 11 -> 12 change is only deployed in the staging environment

10:36 <KanjiMonster> wifi card where you need to load a different BDF depending on which band you want to use? perfectly fine, not annoying at all

10:52 <robimarko> KanjiMonster: Its a QCA card for sure, but which one?

10:52 <robimarko> ynezz: Well, we are seeing rather weird GLIBC mismatches in CI and seemengly in x86 buildbots

10:55 <KanjiMonster> robimarko: qcn9074

10:55 <robimarko> KanjiMonster: That sounds about right

10:55 <robimarko> Did the vendor at least fuse the ID right?

10:58 <KanjiMonster> "chip_id 0x0 chip_family 0x0 board_id 0xff soc_id 0xffffffff" says ath11k - I don't think so

10:58 <robimarko> Well, then that is your problem

10:58 <robimarko> Again vendors messing up basic things

10:58 <KanjiMonster> is there a "fix" for that?

10:58 <robimarko> If they fused it properly then you wouldnt have to change the BDF

10:59 <KanjiMonster> e.g. via random dt properties thrown at the wifi/pcie node

10:59 <zorun> robimarko: it seems you are using ubuntu images for the CI? why not use Debian?

11:04 <ynezz> zorun: CI should be using the buildbot worker images as well https://github.com/openwrt/actions-shared-workflows/blob/main/.github/workflows/reusable_build-tools.yml#L16

11:11 <zorun> ah right, the "runs-on: ubuntu-latest" part is probably about the virtual machines on which the container is run

11:27 <robimarko_> Yes, that is the Github actions runner host image

12:04 <owrt-images-builds> Build [#436](https://buildbot.openwrt.org/images/#/builders/25/builds/436) of `master_realtek/rtl838x` completed successfully.

12:24 <owrt-images-builds> Build [#140](https://buildbot.openwrt.org/images/#/builders/192/builds/140) of `openwrt-23.05_bcm27xx/bcm2708` failed.

12:40 <ynezz> just noticed https://downloads.openwrt.org/snapshots/targets/ramips/rt288x/

12:40 <ynezz> is there any reason to keep this subtarget?

12:41 <ynezz> there are no images, so why to waste time on that? even IB is unusable openwrt-24.10-snapshot-r27997-a923d1f9ec-ramips-rt288x-airlink101_ar670w-squashfs-factory.bin is too big: 5242884 > 3932160

12:41 <ynezz> (I'm actually testing 24.10, but it applies to snapshot as well)

12:57 <owrt-images-builds> Build [#136](https://buildbot.openwrt.org/images/#/builders/161/builds/136) of `openwrt-23.05_ath79/generic` completed successfully.

13:00 <KanjiMonster> ynezz: the ToH lists one device with 8 MiB flash (belkin f5d8235-4), the rest has 4 MiB. Ram-wise all have 32 MiB, so I doubt that even the belkin one will be usable in practice

13:20 <ynezz> so making it source-only should be ok, right?

13:28 <KanjiMonster> yeah

13:29 <KanjiMonster> not sure if it is even worth to keep in source. it has a few quirks that are probably easy to break, and noone around to test it (e.g. its memory window doesn't start at 0 like on most platforms)

14:11 <robimarko_> ynezz: I guess we should update the actions to use 3.11.8 v20?

14:19 <ynezz> robimarko_: are you seeing some issues?

14:19 <ynezz> it should be actually v21 (not tagged yet)

14:19 <robimarko_> ynezz: Look at CI builds, a lot of them are failling on GLIBC mismatch

14:19 <ynezz> v20 is Debian 12

14:20 <ynezz> v21 is Debian 11

14:20 <robimarko_> Ok, to me it just makes sense to keep them in sync

14:20 <ynezz> robimarko_: do you've such CI build handy?

14:21 <robimarko_> ynezz: any of the packages PR-s fails with like half of the builds failling

14:21 <robimarko_> Example: https://github.com/openwrt/packages/actions/runs/11657713964/job/32455690903#step:6:4127

14:24 <efahl> First error in that log is: 4001: /builder/staging_dir/host/bin/bash /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /builder/staging_dir/host/lib/libfakeroot.so)

14:25 <robimarko_> Yeah, that is the same error on all that are failing

14:26 <efahl> So once ynezz's revert https://github.com/openwrt/buildbot/commit/aab8a542db9576d8ac8121db084f784897742af9 filters through I assume they're fixed?

14:26 <robimarko_> That is my guess

14:27 <robimarko_> BTW, also: https://github.com/openwrt/gh-action-sdk/issues/43

14:32 <ynezz> IMO its not going to be fixed, that https://github.com/openwrt/docker/commit/ad118a4b0e16e70ddfa5520f2935254ed06a6860 should be reverted

14:33 <ynezz> we didn't switched buildbots to Debian 12, I would like to find out, how this happened, but currently have no clue

14:34 <robimarko_> Its a bit confusing as we have multiple versions in use all over the place

14:34 <robimarko_> Actions are on 3.8.0 v9, this docker repo is on 3.11.8 now

14:40 <ynezz> aparcar[m]: buildworker-v3.11.8:latest is not good idea, not all tags are working/should be used

14:41 <ynezz> aparcar[m]: latest basically means v20 tag = Debian 12 now, probably v21 tag = Debian 11 tomorrow

14:41 <robimarko_> Can we sync all of the buildworker images that are used with the same one?

14:41 <robimarko_> So we avoid this kind of a mess

14:42 <ynezz> well, that mess started somewhere else and continued propagating because of this quick fixes/merging

14:43 <robimarko_> Well, the thing is that this happened before the 3.11.8 bump

14:43 <robimarko_> Since none of the actions to build new images with it have not even started

14:45 <ynezz> could be, maybe it was some stray buildworker having image configured for staging environment (using Debian 12) and connecting to the production environment (using Debian 11)

14:47 <robimarko_> Its most likely openwrt/docker catching the v20 tag couple of days ago

14:47 <aparcar[m]> ynezz: I'm happy to change it to whatever you prefer, the point for Docker is to always use what the buildbots use, so I'd love a stable tag there, even if the underlying Debain version or so changes

14:47 <robimarko_> Last time it built was 3 days ago

14:54 <ynezz> aparcar[m]: simply revert and use pinned version, not the latest :)

14:55 <ynezz> I've not anticipated, that someone is going to use it this way

15:15 <aparcar[m]> ok. well I need to rework this docker stuff anyway, why not now..

15:48 <schmars[m]> unrelated question about source only devices

15:51 <schmars[m]> oops i wanted to type more :-) later

16:43 <owrt-images-builds> Build [#3](https://buildbot.openwrt.org/images/#/builders/288/builds/3) of `openwrt-24.10_imx/cortexa9` completed successfully.

18:39 <Ansuel> ynezz my 2 cent... (maybe already said) it would be sensible to have a less versioned tag for container. something like buildbot:production buildbot:staging and we update the hash as we produce more version. That was we should be able to deploy new buildbot version easier (maybe?) (and for the sake of security we can sign and verify tag signature ?) This way we can have a single tag that will both used by the sdk container, CI actions and the main

18:39 <Ansuel> buildbot runner

18:40 <Ansuel> we can still keep the current version way, but just production tag will be force-updated every time to point to the new release. Any user will point to the production tag instead of a specific version

18:41 <Ansuel> (this is commonly used for github actions to release new major version of an action by updating the tag)

18:44 <ynezz> Ansuel: this is how its being consumed: docker_image_buildmaster: 'ghcr.io/openwrt/buildbot/buildmaster-v3.11.8:v20@sha256:43d435434b5235b256620eaca99cfe6145230d0dc629305170bd2d2995e501be'

18:47 <Ansuel> eh i guess we would lose too much security with ghcr.io/openwrt/buildbot/buildmaster:production ?

18:47 <ynezz> how do you notice it moved?

18:49 <Ansuel> we wouldn't (my compromise idea was verify the signature of the tag)

18:50 <ynezz> having the key stored on github?

18:53 <ynezz> don't take me wrong, we can have those additional tags for CI purposes, but we consider something stable once it passes some tests

18:54 <ynezz> so we would need to add some additional step and do something like release?

18:56 <Ansuel> ynezz just trying to find a way to have an easy way to have synced version and cause less manual intervention from your side

18:58 <Ansuel> we can start using additional tag to sync everything that is not the main buildbot but it would be half the solution

19:18 <Ansuel> ynezz also if we want to be totally detached from github sign system (and still keep automated deploy), their sign tool (cosign) supports HW key and you can insert all kind of info (for example the hash the container targets). Then to sign the image we would trigger it from the action and make the actualy sign externally (on the local server where the key is installed) Probably totally not worth it but something to consider ahahhaha

19:31 <owrt-images-builds> Build [#420](https://buildbot.openwrt.org/images/#/builders/205/builds/420) of `master_mpc85xx/p1020` completed successfully.

19:57 <Mangix> sigh

19:58 <Mangix> amdgpu is broken on older GCN

20:25 <russell--> who is in charge of cherrypicking fixes into the release branch?

21:16 <robimarko_> russell--: I dont think anybody is specially selected

21:23 <russell--> that w25q128 regression-fixing patch should get in, or people upgrading are going to "brick" their devices

21:23 <russell--> ... for some devices

21:50 <russell--> already in openwrt-24.10, so that's a concern allieviated, thanks!

22:51 <schmars[m]> are we deleting 21.02-SNAPSHOT stuff from downloads.openwrt.org at the moment?

22:52 <schmars[m]> kmods feeds for all targets seem to be gone