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

Stepping down as Arch Linux Packager
by kgizdov＠archlinux.org 15 Feb '26

15 Feb '26

Dear all, After careful consideration, I have decided to step down from my role as an Arch Linux Packager. Over the past months I have not been able to maintain the level of activity and responsiveness that this role requires. I made several attempts to reorganize my schedule and return to consistent contributions, but it has become clear that I cannot currently dedicate the time and focus that Arch deserves. I believe it is more responsible to step aside. It has been a privilege to contribute to Arch and to work alongside such a competent and principled team. The standards we uphold are something I deeply respect. This is not a farewell to the project itself. I hope to return to an active Packager role in the future when I can commit the time and energy it deserves. Thank you all for the collaboration, the discussions, the memories, and the shared commitment to keeping Arch on the edge. Best regards, Konstantin Gizdov

5 4

glibc 2.43 in testing - moving to stable repos affected
by Frederik Schwan 10 Feb '26

10 Feb '26

I've pushed glibc 2.43 to testing. Do not move packages linked against 2.43 to extra or core until glibc itself moves around Thursday/Friday. Otherwise the package will probably break. Best regards, Frederik

1 0

radicale 3.6.0-1 pulled from extra-testing
by Jakub Klinkovský 09 Feb '26

09 Feb '26

Hi, the radicale 3.6.0-1 package has been pulled from extra-testing. If you have upgraded, downgrade to the version available in extra. The reason is that the new version strictly requires python-bcrypt < 5.0.0 *or* the "libpass" fork of python-passlib. Since we already have python-bcrypt 5.0.0, we need to wait until we can package libpass in our repositories: https://github.com/notypecheck/passlib/issues/11 Jakub

1 0

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