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

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

systemd v258 pre-releases
by Christian Hesse 07 Aug '25

07 Aug '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 1

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

glibc 2.42 in testing - moving to stable repos affected
by Frederik Schwan 29 Jul '25

29 Jul '25

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

1 0

Arch Linux devblog
by David Runge 24 Jul '25

24 Jul '25

Hi all, during and since last Arch Summit some of us have been discussing a dedicated blog focused on Arch Linux development topics. This blog is now live at https://devblog.archlinux.page and is also available through the Arch Planet feed aggregator [1]. The devblog is meant for all Arch Linux staff to highlight work on Arch Linux projects. Topics may include (but are not limited to) - providing an overview of recent/current/future developments (e.g. contextualizing our existing tech stack with new tools) - explaining more intricate or complex topics of our projects to a wider audience (e.g. the use of tools with code examples, etc.) Here, the audience may range from Arch Linux staff to anyone interested in the technical developments of the distribution. While this blog is probably a good place to highlight new work, it may also serve as an avenue to reduce our tribal knowledge a bit and give in-depth insights. As a side effect of producing technical posts generally increasing the knowledge about our projects, we also hope to attract new contributors. If you are interested in writing something, head on over to the repository for the blog [2] and open a merge request. In case you are interested in helping review posts, please reach out to the current developers of the project [3]. Happy writing! Best, David [1]: https://archlinux.org/planet/ [2]: https://gitlab.archlinux.org/archlinux/devblog [3]: https://gitlab.archlinux.org/archlinux/devblog/-/project_members -- https://sleepmap.de

1 0

Licensing changes in package sources (implementing RFC40 and RFC52)
by Sven-Hendrik Haase 23 Jul '25

23 Jul '25

Hey all, With [RFC40][0] and [RFC52][1] merged, we're now going full steam to make sure the changes outlined in those RFCs are soon implemented. If you are a packager and only care about how this concerns you without the nitty gritty details, here's what you need to know in short: 1. PKGBUILDs and auxiliary files (e.g. config files, etc.) that Arch Linux contributors provided will be licensed under 0BSD. Full current list [here][3]. 2. Licensing information will be documented in a `REUSE.toml` file per repository and will be maintained by package maintainers going forward. 3. We will generate a `REUSE.toml` (using `pkgctl license setup`) for most packages. 4. You may have to make changes to your packages (details below)! 5. When moving package source repositories from the AUR, either contact past contributors and ask for consent to license under 0BSD, or rewrite the package sources. The changes introduced in [RFC40][0] and [RFC52][1] have a general impact on packaging work. To clearly document which licenses apply to which files, we are introducing REUSE [2], which provides a structured configuration file format (`REUSE.toml`) for mapping files to concrete licenses. In the near future, we will add these files to package source repos in an automated fashion using `pkgctl license setup`. While doing so, we will exclude some packages added after 2024-11-01, see [this issue][4] for further details. In some cases (around 750 out of 12462 repos), packager maintainers will need to manually perform some changes, as adding a `REUSE.toml` will not work out of the box. There will be a todo list on Arch web for those packages where manual action is required. The most common reasons for this are: 1. The package's license isn't specified in an SPDX conforming fashion (e.g. `GPL2` instead of `GPL-2.0-or-later`). There are open MRs on GitLab to make some packages SPDX conforming [5]. We will go through these and we'll try to merge all of these. 2. Multiple license identifiers are specified in the PKGBUILD and SRCINFO files and patch files are present in the package source repository. In this case, we can't automatically pick a suitable upstream license. By default, all files in package source repos must be licensed under 0BSD. 0BSD is very permissive and files licensed under its terms can be contributed upstream under their desired license. For some files, 0BSD might not be suitable, and contributors need to choose a different license depending on the situation. Here are some common cases: - Included files originating from contributors that have not agreed to the 0BSD license. If the files are available under a FOSS license, mark the files under that particular license in the `REUSE.toml`. If no license is provided, the files need to be rewritten or removed. - Patches taken from upstream and committed to the repository need to be annotated with the correct upstream license. `pkgctl license` will be available from devtools v1.4.0 onwards. After this release, you will encounter a warning when running `pkgctl release` if your package source repository isn't compliant. If there are any open questions with existing packages and the new reuse setup, reach out over the mailing list or in the packaging channel. Cheers, Rafael and Sven [0]: https://rfc.archlinux.page/0040-license-package-sources/ [1]: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/52 [2]: https://reuse.software/ [3]: https://gitlab.archlinux.org/archlinux/devtools/-/blob/b8c475b3f402809fc65b… [4]: https://gitlab.archlinux.org/archlinux/packaging/licensing-package-sources/… [5]: https://gitlab.archlinux.org/search?scope=merge_requests&search=spdx&state=…

1 0

Scheduled maintenance for gitlab.archlinux.org
by gromit 09 Jul '25

09 Jul '25

Hello everyone, our hosting provider Hetzner has just informed us that there will be a scheduled downtime window on the 9th July 2025 starting on 10:00 GMT+2 until 14:00 GMT+2 [to replace the mainboard of our Gitlab server][0]. During this time period the service will be offline for up to 40 minutes + however long it takes us to fix potentially resulting issues with the booloader, network configuration and so on. This will effect the following services/components of our distribution ecosystem: - Packaging: No packages can be updated during the downtime (as the source repositories for it will be offline) - Project Maintainers: The other projects (pacman, aurweb, buildbtw, signstar, mirrors repo etc.) will be unavailable - Bugtracker: No bugs can be reported during this timeframe - Static sites as served via Gitlab Pages (Arch Linux WKD, project pages etc.) will not be available We can not really circumvent the downtime and think it's an acceptable timeframe to not warrant any further action from us as a team. Let us know if you have any questions or additions to the above! Cheers, Christian for the DevOps Team [0]: https://docs.hetzner.com/robot/dedicated-server/general-information/mainboa…

1 1

Orphaning phosh
by Jelle van der Waa 06 Jul '25

06 Jul '25

Hi All, Lately I have noticed I haven't gotten around to updating phosh to the latest version. As this is a returning issue and I don't use phosh anymore as GNOME is good enough for tablets I decided to orphan it. Maintenance should be fairly trivial, the only issue is that it requires a revert on top of wlroots and of course needs to catch up to wlroots from time to time. [1] Upstream is very friendly and nice. [2] The packages in question which are now orphan: * phoc * phosh * phosh-mobile-settings * libgmobile * feedbackd If no one picks it up I will drop the packages to the AUR in one month so someone there can maintain it. [1] https://gitlab.archlinux.org/archlinux/packaging/packages/wlroots0.19/-/blo… [2] https://phosh.mobi/

1 0

First step for non-x86_64 contributions
by Levente Polyak 03 Jul '25

03 Jul '25

# 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 13