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

systemd v258 pre-releases
by Christian Hesse 05 Sep '25

05 Sep '25

Hello everybody, the systemd development team has pushed the first pre-release for the upcoming v258 release. It is a massive feature release, with a huge amount of new functionality and goodies. 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 ware brave and want to have a first look. The comes with an updated mkinitcpio package, cherry-picking systemd-related changes. We should merge these before v258 release. Happy testing! [0] https://github.com/systemd/systemd/blob/v258-rc1/NEWS [1] https://gitlab.archlinux.org/archlinux/packaging/packages/systemd/-/blob/ma… [2] https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/merge_reques… -- 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 3

Standardize on running autoreconf in prepare()
by Jelle van der Waa 01 Sep '25

01 Sep '25

Hi All, After all the recent RISC-V news I went ahead and checked out the existing effort to get Arch Linux supported on RISC-V. Felix maintains an overlay of PKGBUILDs which require customization to be be able to build on RISC-V. A lot of these PKGBUILD's patch autotools projects to run `autoreconf -fiv` in prepare(), this re-generates `configure` to understand RISC-V. Since these patches are simple enough and I don't see them harming Arch Linux, I would argue that we want these patches applied in our packages. Re-generating configure should not break, and if it does we should not accept the patch and get a bug filled upstream. Re-creating configure and thus not using the provided `configure` could arguably also be a good thing regarding supply chain security. And this also should help with other architecture ports. As a follow up we can discuss providing our own "/usr/share/config.site" and then ./configure --prefix=/usr would automatically configure localstatedir, libexecdir, etc. [1] https://github.com/felixonmars/archriscv-packages [2] https://github.com/felixonmars/archriscv-packages/blob/master/libafterimage…

8 8

namcap 3.6.0 released
by Jelle van der Waa 24 Aug '25

24 Aug '25

Hi, Seen a long hiatus, finally a new namcap release has entered [extra-testing] Release notes: - Allow rules to be disabled by default - Allow namcap-devel to be run from any directory - Support '+' in license expressions - New unreproducible sphinx cache file rule - New dbus services improperly installed in /etc rule - Introduce typechecking using mypy and extend ruff linting rules - Don't crash on missing description, only throw error lint - Remove python-six from tests - Fix safeguards against false positives for QML dependency check - Limit shadow stack check to x86_64 binaries - Change from getopt to argparse Please report issues on GitLab [1] Thanks! Jelle [1] https://gitlab.archlinux.org/pacman/namcap/-/issues/

1 0

RFC Final Comment Period: "Automated digital signing of OS artifacts"
by David Runge 19 Aug '25

19 Aug '25

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/59 Please visit the above link for discussion. Summary: """ Introduce a centralized, hardware backed solution for the digital signing of OS artifacts. Gradually replace the need for manual signing of artifacts throughout the distribution. The stepwise plan in this document will eventually lead to changes for the following existing roles within Arch Linux staff: - _Package maintainers_ will no longer sign packages using their individual OpenPGP private key. - The amount of OpenPGP certificates for _main signing key holders_ to care for will be drastically reduced. - The _DevOps team_ will have to monitor and administrate additional physical machines. New groups of people within Arch Linux staff will - collectively take care of the administrative credentials for the described system as _holders of shares of a shared secret_, - provide software upgrades for components of the system as _developers of Signstar_ - and create releases for a central, image-based OS as _developers of Signstar OS_. For details refer to the section **changes for users and staff**. """

1 0

PKGBUILD SPDX License array RFC status
by Jelle van der Waa 18 Aug '25

18 Aug '25

Hi All, Some time ago we decided to adopt SPDX license identifiers in the license array of PKGBUILD's. Without having progress reports its hard to know what the current status is, so I made a little script with some borrowed logic from namcap. [1] This uses expac to extract the licenses array from the local package sync db (/var/lib/pacman/sync). The unknown / invalid entries are emitted on stderr and stdout contains JSON data to be consumed by whatever tool you might suit you :-) A test run on my machine gave the following output, in summary: [2] * invalid: 62 * unknown: 4743 I hope having an easy script to collect statistics will move the conversion process forward. But do note that the original RFC does not yet tackle the `custom` license question. [3] [1] https://github.com/jelly/Dotfiles/blob/master/bin/arch-spdx-statistics [2] https://gist.githubusercontent.com/jelly/c5b790c3b1223f91362d956d50401e93/r… [3] https://rfc.archlinux.page/0016-spdx-license-identifiers/#unresolved-questi…

2 2

Removing port 222 for git on gitlab.archlinux.org
by Kristian Klausen 09 Aug '25

09 Aug '25

Hi all, the git migration happened more than two years ago[1] and as part of that the SSH port for git was changed from port 222 to the default SSH port 22[2]. A port redirect was added at the time to avoid disrupting existing local git repositories using the old port. Time has now come to removing said port redirect, which will happen one week from now. So if you have local git repositories using the old port, please change them to use the standard SSH port. See below for an example. $ git remote -v origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (fetch) origin ssh://git@gitlab.archlinux.org:222/archlinux/infrastructure.git (push) $ git remote set-url origin git@gitlab.archlinux.org:archlinux/infrastructure.git $ git remote -v origin git@gitlab.archlinux.org:archlinux/infrastructure.git (fetch) origin git@gitlab.archlinux.org:archlinux/infrastructure.git (push) [1] https://archlinux.org/news/git-migration-completed/ [2] https://gitlab.archlinux.org/archlinux/infrastructure/-/commit/bc1e7f777283… Cheers, Kristian Klausen DevOps

1 1

Introducing bumpbuddy
by Robin Candau 07 Aug '25

07 Aug '25

Hi everyone, We are very happy to announce the addition of a new member to the "buddy" family: bumpbuddy! [1] Initially introduced to Arch staff during last year's Arch Summit as the "nvchecker-poc" [2], bumpbuddy is now (a)live and ready to assist our package maintainers and users in monitoring new upstream releases for our packages. ## What is bumpbuddy? Bumpbuddy is a daemon watching for new upstream releases for our packages. It automatically opens GitLab issues for out of date packages [3], keep them updated if needed (e.g. if a newer upstream release supersedes the initially reported one) [4] and closes them once the matching version has been pushed [5]. It intends to fill the gaps in current methods for new upstream release tracking and reporting by proposing a centralized and automated solution. ## Benefits for package maintainers Bumpbuddy takes advantage of the `.nvchecker.toml` file from GitLab's packages repo to perform automated tracking of new upstream releases. Therefore, Package Maintainers won't need to rely on manual `pkgctl version check` runs or "homemade" solutions to track new upstream releases for their packages anymore. The reporting of new upstream releases being done via GitLab issues offers a (public) place to discuss and collaborate around eventual problems or blocking points preventing a new release from being packaged [6]. Assignment to those "out of date" issues is opt-in and can be enabled by reacting with the "package" emoji from bugbuddy's user settings [7]. Note that such issues are automatically opened as "confirmed", so bug-wranglers will not get assigned. ## Benefits for users Thanks to bumpbuddy automated tracking and reporting, our package maintainers should now be aware of new upstream releases without requiring users to manually flag packages out of date via the dedicated button on Archweb (which we actually intend to get rid of at some point, more on that in the next chapter). Another benefit for users is that, as opposed to the current "flag out of date" feature, GitLab issues offer a public place to look for (or ask for) the state of a pending update. This should hopefully allow for more transparency towards users wondering why a specific update is taking some time to be packaged. ## Current specifications and future work Bumpbuddy currently runs every 3 hours, which means that it may take up to 3 hours for new releases to be reported and for the associated GitLab issue to be automatically close once the matching version has been pushed. It's also worth reminding that the version tracking is based on the `.nvchecker.toml` configuration file of packages repo, meaning that an erroneous configuration file may result in erroneous version reporting and that packages that miss a configuration file will not be monitored. Here are a few mid / long term goals we have for bumpbuddy: - Provide a web overview for reports [9]. - Provide an API endpoint for `pkgctl version check` (to produce faster results). - Manage "out of date" status for packages on Archweb and get rid of the "flag out of date" button; which is manual (and therefore error prone), may be used wrongly/abusively (e.g. to report bugs or send some spam), is highly dependent on packages popularity and lacks transparency (as it doesn't provide a public place to discuss eventual blocking points). - Open merge requests rather than (or in addition of) GitLab issues, including the result of `pkgctl version upgrade` (regarding our future goal to adopt a gitops workflow for packaging). - And more... [10]. ## Conclusion This is the first iteration of bumpbuddy and things are still at a fairly early stage, so bear with us and don't hesitate to open issues [10] to submit bug reports or suggesting improvements. I would like to thank everyone who helped us improving bumpbuddy so far by opening issues, sharing opinions and opening merge requests. I would also like to give a special thank to Segaja, mh4ckt3mh4ckt1c4s and yan12125, who have been (beta) testing bumpbuddy for the past few months, as well as a huge thanks to klausenbusk & gromit for their amazing work and precious help on that project! [1] https://gitlab.archlinux.org/archlinux/bumpbuddy [2] https://pkgbuild.com/~antiz/presentations/Nvchecker_PoC/ [3] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [4] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [5] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [6] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issue… [7] https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1 [8] https://archlinux.org/packages/extra/x86_64/timeshift/flag/ [9] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/10 [10] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/ -- Regards, Robin Candau / Antiz

3 3

News draft: zabbix >= 7.4.1-2 may requires manual intervention
by Robin Candau 04 Aug '25

04 Aug '25

Hi, I've been working on a significant rework of the zabbix split package [1] over the past few days, introducing a fair amount of changes and improvements. One key change consists of replacing the multiple sysusers historically created for each zabbix components with a single shared "zabbix" user: - It aligns better with the intended upstream standard and the way other distributions does this (see [2] for more details). - The previous historical approach was somewhat *hacky*, e.g. relying on unnecessarily static UID:GID for each user and running some `chown` during `package()` rather than relying on systemd sysusers.d / tmpfiles.d. That said, this change *may* require manual intervention from users. While I'm aware that Zabbix component usage on Arch Linux might be relatively low, I believe that monitoring components are critical enough to warrant a news entry about this change and the potential impact it implies. Of course, feel free to let me know if you think otherwise. News draft below. Pad available at [3]. ---------- # zabbix >= 7.4.1-2 may requires manual intervention Starting withi `7.4.1-2`, the following Zabbix system users (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared `zabbix` user (as originally [intended by upstream](https://www.zabbix.com/documentation/current/en/manual/installati… and done by other distributions): - zabbix-server - zabbix-proxy - zabbix-agent *(also used by the `zabbix-agent2` package)* - zabbix-web-service This shared `zabbix` user is provided by the newly introduced `zabbix-common` *split* package, which is a now a dependency for all relevant `zabbix-*` packages. The switch to the new user is handled automatically in the corresponding `systemd` service units. However, **manual intervention may be required** if you have custom files or configurations referencing / being owned by the above deprecated users, for example: - `PSK` files used for encrypted communication - Custom scripts for metrics collections / report generations - `sudoers` rules to metrics requiring elevated privileges to be collected - ... Those should therefore be updated to refer to / be owned by the new `zabbix` user, otherwise some services may fail to start properly (if not at all). Once migrated, you may optionally remove the obsolete users and their primary groups from your system (see the [related Arch Wiki page](https://wiki.archlinux.org/title/Users_and_groups) for details). ---------- [1] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix [2] https://gitlab.archlinux.org/archlinux/packaging/packages/zabbix/-/issues/1… [3] https://md.archlinux.org/YjsLnkzRRoeMa7BP3gxYKw# -- Regards, Robin Candau / Antiz

2 4