- Arch-dev-public - lists.archlinux.org

Guidelines for reproducible Go binaries (2026)
by kpcyrd 04 Feb '26

04 Feb '26

hello, I joined as co-maintainer for syft after the recent todo item[1] and modernized the PKGBUILD. Based on the repro-get package[2] (which did reproduce successfully) I've changed the syft build instructions to this: ``` export CGO_CPPFLAGS="${CPPFLAGS}" export CGO_CFLAGS="${CFLAGS}" export CGO_CXXFLAGS="${CXXFLAGS}" export CGO_LDFLAGS="${LDFLAGS}" export CGO_REQUIRED="1" mkdir -p build go build \ -o build/ \ -buildmode=pie \ -mod=readonly \ -ldflags "-compressdwarf=false -linkmode=external -X main.version=${pkgver}" \ ./... ``` This did not reproduce in our verification system however: ``` │ ├── usr/bin/syft │ │┄ File has been modified after NT_GNU_BUILD_ID has been applied. │ │ ├── readelf --wide --notes {} │ │ │ @@ -1,16 +1,16 @@ │ │ │ │ │ │ Displaying notes found in: .note.gnu.property │ │ │ Owner Data size Description │ │ │ GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 Properties: x86 ISA needed: x86-64-baseline │ │ │ │ │ │ Displaying notes found in: .note.gnu.build-id │ │ │ Owner Data size Description │ │ │ - GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 5d4cf47367358962632d3bfd04530c513f897790 │ │ │ + GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: dd9283dbad8ad8c4b742f7ac88f6a0e1f3b9acc1 │ │ │ │ │ │ Displaying notes found in: .note.go.buildid │ │ │ Owner Data size Description │ │ │ - Go 0x00000053 GO BUILDID description data: 42 49 56 6f 41 61 39 67 43 50 4e 49 6e 37 70 49 55 2d 76 64 2f 5f 6b 4a 66 6e 31 37 68 6e 4b 42 65 42 66 62 6f 39 74 4d 4b 2f 59 39 66 41 33 4d 74 7a 69 66 56 71 4b 4a 42 42 68 78 7a 57 2f 42 50 73 44 75 79 76 55 49 4c 37 30 47 37 73 6e 67 6a 55 73 │ │ │ + Go 0x00000053 GO BUILDID description data: 50 44 71 65 63 37 36 71 30 4e 52 69 4b 36 69 57 63 31 73 52 2f 5f 6b 4a 66 6e 31 37 68 6e 4b 42 65 42 66 62 6f 39 74 4d 4b 2f 59 39 66 41 33 4d 74 7a 69 66 56 71 4b 4a 42 42 68 78 7a 57 2f 73 6a 72 50 70 62 38 39 32 41 4c 48 4e 62 6c 4d 72 75 4d 46 │ │ │ │ │ │ Displaying notes found in: .note.ABI-tag │ │ │ Owner Data size Description │ │ │ GNU 0x00000010 NT_GNU_ABI_TAG (ABI version tag) OS: Linux, ABI: 4.4.0 │ │ ├── strings --all --bytes=8 {} │ │ │ @@ -1,8 +1,8 @@ │ │ │ -BIVoAa9gCPNIn7pIU-vd/_kJfn17hnKBeBfbo9tMK/Y9fA3MtzifVqKJBBhxzW/BPsDuyvUIL70G7sngjUs │ │ │ +PDqec76q0NRiK6iWc1sR/_kJfn17hnKBeBfbo9tMK/Y9fA3MtzifVqKJBBhxzW/sjrPpb892ALHNblMruMF │ │ │ /lib64/ld-linux-x86-64.so.2 │ │ │ __libc_start_main │ │ │ __cxa_finalize │ │ │ __vfprintf_chk │ │ │ sigfillset │ │ │ pthread_sigmask │ │ │ pthread_attr_init │ │ ├── readelf --wide --decompress --hex-dump=.gnu_debuglink {} │ │ │ @@ -1,4 +1,4 @@ │ │ │ │ │ │ Hex dump of section '.gnu_debuglink': │ │ │ - 0x00000000 73796674 2e646562 75670000 ca77ec4e syft.debug...w.N │ │ │ + 0x00000000 73796674 2e646562 75670000 6b0247ba syft.debug..k.G. ``` From what I understand both build IDs are hashes over other parts of the binary. Since they are the only difference though, the problem is likely in the debug symbols that get detached after the compile (and also after this hashing is done), but before diffoscope is executed on the final release artifact. Our guidelines for Go[3] mention the -trimpath option (which I forgot to add, but also wasn't necessary for repro-get), but since we have normalized paths in our build containers I'm not sure if the claim about Reproducible Builds applies to non-AUR packages? Using the data from reproducible.archlinux.org, there's currently 371 packages that depend on our Go package and have some kind of status attached to it: % rg -c GOOD resolved-go.txt 240 % rg -c BAD resolved-go.txt 131 Which is about ~65% In comparison, although many packages still use the `rustc --print` approach, our Rust build instructions essentially boil down to: ``` cargo fetch --locked --target host-tuple cargo build --frozen --release ``` Those two commands with no further manually set environment variables gets us: % rg -c GOOD resolved-rust.txt 669 % rg -c BAD resolved-rust.txt 86 Which is ~89% Although 20 percent-points doesn't seem like that much, it's a difference of "every 1 out of 3" vs "every 1 out of 10". Is there anything we can do to improve this overall situation? Both the amount of complexity necessary to compile a simple binary, as well as the reproducible build success ration? Maybe we could have something like /etc/makepkg.conf.d/rust.conf but for Go? cheers, kpcyrd [1]: https://archlinux.org/todo/rebuild-packages-signed-by-anatolik-morganamilo-… [2]: https://gitlab.archlinux.org/archlinux/packaging/packages/repro-get/-/blob/… [3]: https://wiki.archlinux.org/title/Go_package_guidelines

2 5

RFC Final Comment Period: "buildbtw build service"
by Rafael Epplée 03 Feb '26

03 Feb '26

An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/63 Please visit the above link for discussion. Summary: """ This RFC proposes a first vertical slice of a build service to streamline rebuilding packages with many reverse dependencies. It tackles problems like repetitive manual work, blocking staging repositories, missed reverse dependencies and lack of shared context, like build logs. Goals include automating rebuilds and build ordering, enabling unattended builds, and providing isolated repos for parallel work. Builds run in secure virtual machines via a GitLab executor, organized into namespaces with histories and automatic dependency graphs. Interaction happens through CLI (pkgctl) and a web UI with SSO. """

1 1

First step for non-x86_64 contributions
by Levente Polyak 27 Jan '26

27 Jan '26

# First step for non-x86_64 contributions Hey everyone, I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes. There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules. We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/). ## Guidelines ### Protecting x86_64 We do not want to compromise on our primary platform. Clearly do not break or remove x86_64 behavior, functionality or features. Incompatible features or dependencies must be proposed in a way that preserves the functionality of our primary platform. ### Non-intrusive Small, focused changes that are easy to understand at a glance and can be reasoned about even without building and running it on different architectures. ### No downstream wizardry Complex, opaque, or heavy software patching is out of scope. Carrying around massive software patches downstream isn't feasible at this stage, save that for later and work together with upstream instead. ### Merge-request indicator All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others. ### Manageable load Contributors must stick to small merge-request batches max 10 open MRs per person. All proposals must be sent manually, no fire-and-forget scripts. Collaboration is expected. If questions come up, we expect thoughtful responses from people who precisely know the changes they're submitting. ## Out of scope ### arch array No changes to `arch=()` arrays. ### non-x86_64 issues No issues or bug reports for non-x86_64. If something's broken with the `PKGBUILD`, you'll need to sort it out and send a merge-request. Don't file bugs in the tracker for other architectures. --- This approach allows us to slowly build up compatibility and make good progress without burning out our packagers and bug-wranglers or flooding our GitLab with changes and bug reports we can't handle. We can stretch out the work by allowing confined changes and avoid to stack it all for later. It gives us room to prepare without needing full build infrastructure, provide active support or require special hardware in place today. I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community. Cheers, Levente

9 14

Adding Christian Heusel as new main signing key holder
by David Runge 25 Jan '26

25 Jan '26

Hey all, for a while now we are short one active main signing key [1]. Traditionally, we have selected new main signing key holders from the list of developers. During Arch Linux summit 2025 we have been discussing this topic and brought forth the idea of selecting main signing key holders generally from the larger group of active staff instead. After a short discussion on the arch-dev mailing list, we received generally positive responses. As such, we are adding Christian Heusel as new main signing key holder [2] and Robin Candau as his revoker. His certificate has the OpenPGP fingerprint `99B6618472A3B3B814185BAED7D3D823B88BDB9B` and will be added to the archlinux-keyring. Best, David [1]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/269 [2]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/313 -- https://sleepmap.de

1 0

FOSDEM 2026 Dinner
by Robin Candau 24 Jan '26

24 Jan '26

Hi everyone, As usual, a few members of the Arch Linux team will be present at FOSDEM [1] this year. Since a few years now, we have held an "Arch dinner" during the FOSDEM weekend. It has been a great and well received event that we'd like to held again this year! 🙂 It will be held Saturday, January 31 at 20:00. The dinner is sponsored by Arch Linux and should cover a drink and a main course. We will cap the attendees to 20 people. Priority for members of the Arch staff. Any free spots after this can be taken by anyone interested. Please, send an email *offlist* to me [2] and Rafael [3] if you want to attend. The community users requesting spots will get a heads up the week before FOSDEM to give all staff a chance to reply. Please ask me if you have any questions. 🙂 [1] https://fosdem.org/2026/ [2] antiz(a)archlinux.org [3] raffomania(a)archlinux.org -- Regards, Robin Candau / Antiz

1 1

Arch Linux at FOSDEM 2026
by Robin Candau 22 Jan '26

22 Jan '26

Hi everyone, Members of the Arch Linux staff have historically always attended FOSDEM and this year is no different! A few of our staff members will be present at FOSDEM 2026. As always, we will try to settle down somewhere in the cantina so people can meet us (and also get some goodies 🤫). As last year, we will also hold an Arch Linux user meetup / BoF [1]! This BoF session will give a status update on the distribution, adjacent projects and future plans. There will be a short presentation followed by a Q&A session with Arch Linux distribution maintainers and project developers. Some of our staff members are also giving talks: - Rafael Epplée (raffomania): Federated Bookmark Sharing [2] - Robin Candau (Antiz): Relying on more transparent & trustworthy sources for Arch Linux packages [3] Finally, there's a "Reproducible Builds" meetup / BoF [4] to which some of us will participate or attend to as well. We wish everyone a good FOSDEM and we're looking forward to meet some of you there! 🤗 [1] https://fosdem.org/2026/schedule/event/LMBYTE-arch-linux-meetup-bof/ [2] https://fosdem.org/2026/schedule/event/YAMEDX-federated_bookmark_sharing/ [3] https://fosdem.org/2026/schedule/event/FFWA7E-transparent-sources-for-arch-… [4] https://fosdem.org/2026/schedule/event/8ETZS3-reproducible_builds_meetup/ -- Regards, Robin Candau / Antiz

1 0

Please finish the package license todo-list
by Jelle van der Waa 20 Jan '26

20 Jan '26

Hi all, The Python rebuild is off to a bit of a rocky start with ~ 100 packages which fail `pkgctl license check`. Please help complete this todo so we can keep rebuilding. [1] https://archlinux.org/todo/make-packages-license-compliant/

2 1

Changes in pacman-mirrorlist package regarding HTTP mirrors
by pitastrudl 17 Jan '26

17 Jan '26

Hi all, A week ago or so [1] a change in the pacman-mirrorlist package was merged, where we removed listings of HTTP based mirror URLs so only HTTPS based mirrors remain in the newly released pacman-mirrorlist package. To further clarify, this does not translate to making HTTP based mirrors unsupported, they are still available on the mirrorlist[2] endpoint that is used by other mirrorlist fetching tools like reflector. Best regards, Arun Mirrorlist team [1]https://gitlab.archlinux.org/archlinux/packaging/packages/pacman-mirrorli… [2]https://archlinux.org/mirrorlist/

2 1

p11-kit pulled from testing
by Jan Alexander Steffens (heftig) 16 Jan '26

16 Jan '26

I've removed p11-kit 0.26.0-1 from testing as it causes Firefox to distrust all the system CAs, failing to connect. This concerns the following packages: - libp11-kit - p11-kit - p11-kit-docs - lib32-p11-kit Please downgrade these packages to the last release (0.25.10-2) if you've upgraded already.

1 0

Bumpbuddy: New dashboard and features
by Robin Candau 15 Jan '26

15 Jan '26

Hi everyone, Last summer, we introduced bumpbuddy [1], a daemon watching for new upstream releases for our packages. Bumpbuddy offers a centralized and automated way for tracking and reporting new upstream release for our Package Maintainers; also providing a public place (in the form of GitLab issues [2]) for anyone to discuss the state of a pending package update, allowing for more transparency in the process. Since the initial introduction published a few months ago, bumpbuddy got a fair amount of new features & releases, so we thought it might be a good time for a follow-up! ## Dashboard Bumpbuddy's data are now publicly exposed and reported on a dedicated web dashboard [3]. This dashboard allows anyone to visualize and search through the state of monitored packages. Here are the list of the reported parameters: - Package: The package name. - Local version: The current version of the package in our GitLab package repositories. - Upstream version: The latest upstream version for the package reported by bumpbuddy. - Up to date: "Up to date" status of the package. - ✅ = Up to date - ❌ = Out of date - ⚠️ = Bumpbuddy is not able to determine the latest upstream release (due to nvchecker failures) - Issues: Link to the GitLab issue reporting the "out of date" status of a package and / or repeated nvchecker failures. - Last check: Time and date of the last check for the package. ## Report of repeated nvchecker failures As mentioned in the dashboard paragraph, bumpbuddy now also reports repeated nvchecker failures (after a specific threshold) through GitLab issues [4]. This allows to keep track and investigate eventual faulty nvchecker configurations preventing bumpbuddy to properly detect new upstream releases. Once the issue is fixed (and if not done already); such issues are automatically closed by bumpbuddy itself at the next run [5]. ## New dedicated issue labels To allow for more fine grained classification of the opened GitLab issues, the `scope::out-of-date` label was replaced by `package::out-of-date`, so that the reported upstream release can be further classified (e.g. with `scope::security` or `scope::bug`). Following the same pattern, issues for repeated nvchecker failures are labelled with `package::nvchecker` and `scope::bug`. ## General improvements and fixes Various improvements and fixes have been added, including: - Error handling for API calls, avoiding unexpected duplicate issues. - Continious update of the API data, to ensure up to date data for consumers. - Improvements of the pkgbases to GitLab path names conversion (so that e.g. the `bonnie++` pkgbase is correctly converted to `bonnieplusplus` in the GitLab path name). - Update opened GitLab issues on local package version changes (and not only on upstream version changes). - Deletion of the automated comment when updating an opened issue (as it globally ended up as extra "noise"). ## Work in progress We have some work in progress regarding our future goals, most notably: - pkgctl: Automatically close 'out-of-date' issue when releasing a new package version [6], allowing for an instant closing of 'out-of-date' issues when the matching (or a newer) version is being pushed (as compared to today where issues are only closed at the next bumpbuddy run), and generally reducing the extra "noise" cause by the multiple notifications when an issue is being closed by bumpbuddy. - archweb: import bumpbuddy data [7], getting closer to our future goal of replacing the current "Flag Package Out-of-Date" manual button by automated bumpbuddy reports. Further work regarding additional future goals will follow! Huge thanks to klausenbusk, anthraxx and jelle for their amazing work on those new features, improvements and ongoing efforts! [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://gitlab.archlinux.org/archlinux/packaging/packages/python-fastapi/-/… [3] https://bumpbuddy.archlinux.org/ [4] https://gitlab.archlinux.org/archlinux/packaging/packages/schroot/-/issues/1 [5] https://gitlab.archlinux.org/archlinux/packaging/packages/schroot/-/issues/… [6] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/338 [7] https://github.com/archlinux/archweb/pull/598 -- Regards, Robin Candau / Antiz

1 0