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

util-linux v2.42 pre-releases
by Christian Hesse 01 Apr '26

01 Apr '26

Hello everybody, Karel Zak has pushed the first util-linux pre-release for the upcoming v2.42 release. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you are brave and want to have a first look. Happy testing! [0] https://github.com/util-linux/util-linux/blob/stable/v2.42/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/util-linux/-/blob… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 2

HEADS UP: Qt 6.11 in testing
by Antonio Rojas 23 Mar '26

23 Mar '26

As usual, this means the anything compiled against it will automatically depend on it so will have to stay in testing until Qt itself moves. With 6.11, besides the usual private API changes, there is an additional potentially breaking change due to a QWayland native interface version bump. The symptoms may vary from programs not starting to subtle bugs, but the issue can be easily identified by the message "warning: Native interface revision mismatch (requested 1 / available 2) for interface QWaylandApplication" printed in the application's logs. Unfortunately, it is not easy to figure out in advance which applications will be affected. So please test Qt applications thoroughly, and if you notice an affected one, rebuild it with Qt 6.11 in testing and add it to the todo list https://archlinux.org/todo/additional-qt-611-rebuild/[1] to make sure it's moved to stable along with Qt. -------- [1] https://archlinux.org/todo/additional-qt-611-rebuild/

1 0

Removal of remaining packages signed by 86CFFCA918CF3AF47147588051E8B148A9999C34
by David Runge 20 Mar '26

20 Mar '26

Hi all, a rebuild of the remaining packages signed by Evangelos Foutras has been started in January[1]. It unfortunately still has six remaining packages: - dosemu - icoutils - libcdaudio - netperf - tsocks - wipe None of the above are used by other packages (any longer) and fail to build (for various reasons) and are mostly just extremely old/unmaintained pieces of software. To not block the revocation of the certificate [2] further I suggest to remove those remaining packages from the repositories. If you intend to keep any of the above packages in the repositories, please fix and rebuild them before 2026-03-22. I will move any remaining packages to the AUR on that day. Best, David [1] https://archlinux.org/todo/rebuild-packages-signed-by-86cffca918cf3af471475… [2] https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/314

3 2

systemd v260 pre-releases
by Christian Hesse 17 Mar '26

17 Mar '26

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v260 release. Please see the NEWS [0] for details. As announced in the PKGBUILD [1] I have prepared packages and pushed them to my personal testing repository. Have a look at this if you are brave and want to have a first look. Happy testing! [0] https://github.com/systemd/systemd/blob/v260-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}

1 2

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