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

News draft: varnish renamed to vinyl-cache, action required for users
by Sven-Hendrik Haase 23 May '26

23 May '26

Hey all, Recently, the upstream project Varnish was renamed to Vinyl Cache for legal reasons. There were some internal discussions on what to do here because this rename is very disruptive to users. This is not a drop-in replacement. Everything was renamed and Vinyl Cache doesn't have a compatibility layer with Varnish. It's a bit gnarly, honestly. Here's my draft. Lemme know what you think. --- # Breaking changes for all users of `varnish`, renamed to `vinyl-cache` The Varnish project has [renamed itself to Vinyl Cache][0]. We followed this rename with a [new `vinyl-cache` package][1]. This upgrade results in [breaking changes][2] and users are advised to study these changes and how it affects them before following the replacement. All references to "varnish" have been changed to "vinyl" in all binaries and directories. At minimum, users will have to: - rename `/etc/varnish` to `/etc/vinyl-cache` - rename `/var/lib/varnish` to `/var/lib/vinyl-cache` - fix up ownership of files inside `/var/lib/varnish` - user `varnish` becomes `vinyl` - group `varnish` becomes `vinyl` - user `varnishlog` becomes `vinyllog` - user `vcache` remains the same - disable the old `varnish.service` and `varnishncsa.service` systemd units - enable the new `vinyl-cache.service` and `vinylncsa.service` systemd units The former `varnish` package has been dropped from repos. We're not currently planning to maintain a new "varnish" package as it's a different upstream project. [0]: https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.html#… [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/vinyl-cache [2]: https://vinyl-cache.org/docs/9.0/whats-new/upgrading-9.0.html

2 1

archlinux.org status update
by Jelle van der Waa 17 May '26

17 May '26

Hi all, I've just rolled out a new updated archlinux.org, notable changes are: * Developer reports now contain a link to a list of pkgbases * bumpbuddy out of date data import support The bumpbuddy import has now been deployed and is running. See for example aws-vault being flagged by bumpbbuddy. Note that the automatic import doesn't send any email notification like the manual flagging out of date does. [1] In the future the flag out of date button will be disabled in favor of importing bumpbuddy out of date data. Note that we still lack nvchecker integration in packages in this To-Do. [2] [1] https://archlinux.org/packages/extra/x86_64/aws-vault/ [2] https://archlinux.org/todo/add-nvchecker-integration/

4 5

Rebuilder for Arch Linux images
by Robin Candau 29 Apr '26

29 Apr '26

Hello everyone, As a follow-up to our work on achieving bit-by-bit reproducibility for some Arch Linux images [1][2], I have set up a rebuilder for them, accessible at https://archimgrepro.antiz.fr This page shows the results of verification builds for the official Docker and WSL Arch Linux images. Additional images may be added in the future as progress continues. Rebuilds are currently triggered weekly (on Wednesday mornings) against the latest available images. Source code is available on Arch GitLab [3]. It's very simple in its current state, though the setup should be pretty straightforward and distro agnostic. Note that this rebuilder is not (yet) an official Arch Linux service. It is currently hosted on my own VPS and domain. We will evaluate if and how it might be integrated into the official Arch Linux infrastructure. Happy to share this, hopefully it’s useful to some! :) [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [3] https://gitlab.archlinux.org/antiz/archimgrepro -- Regards, Robin Candau / Antiz

1 0

(optional) AUR helper in archinstall
by Anton Hvornum 24 Apr '26

24 Apr '26

Over the years, one of the most requested features by a long shot (statistics based on memories and conversations) for `archinstall` is having access to AUR helpers. So far, the answer to this has always been no "because the AUR is unsupported". Historically, the previously existing AUR feature was removed in commit [6338e71] as a prerequisite in order for `archinstall` to become adopted as an official package. If I remember correctly, the reasoning back then revolved around the support staff being potentially unhappy/overrun by workload, and also because the "AUR is not officially supported" argument. With [archinstall#4447] we received yet another request with regards to this topic: The chosen approach is to add the (optional) possibility of building and installing paru and/or yay (as two of the most popular AUR helpers) using a dedicated menu entry under "archinstall" -> "Applications" -> "AUR Helpers". The menu entry is accompanied by a warning that the use of the AUR and the AUR helpers is not supported, thus potentially satisfying one of the historical concerns. In my opinion, this placement is good, as it is clearly separated from the remaining installation workflow and warns the user. However, given the previous reasoning for not including AUR helpers directly, I'd like to open up the discussion on this topic. Would now be a good time to allow AUR helpers to be installed via `archinstall`? Not AUR packages, but helpers. It seems like a large portion of users install yay/paru anyway (as of writing this), and it makes sense from a repetitive-task-standpoint to allow users to choose — whether or not they want access to AUR early in the installation process, rather than us saying no and making it less accessible. Aside from apparently being a common repetitive task of setting an AUR helper up, there are also certain drivers[1] users want to pull in during installation, as well as AUR packagers would slightly benefit from this option if they want to try their packages during installation. So with this, I would like to open up the discussion — where both "yes" and "no" are welcome, but I'd appreciate some reasonings behind them as I'm most likely going to reference this mail thread if the consensus is "no". And I hope that "I don't care" people speak up too (we'll count them as leaning towards "sure, go ahead"), so I can get a reliable benchmark of what we think about it. //Torxed [archinstall#4447]: https://github.com/archlinux/archinstall/pull/4447 [1]: https://github.com/archlinux/archinstall/discussions/4075 [6338e71]: https://github.com/archlinux/archinstall/commit/6338e7116ef5405cd9b97f066e4…

6 8

Arch Linux now has a bit-for-bit reproducible Docker image
by Robin Candau 20 Apr '26

20 Apr '26

Hey everyone, As a follow-up to the related milestone achieved for our WSL image a few months ago [1], I'm proud to announce that Arch Linux now has a bit-for-bit reproducible Docker image! This bit-for-bit reproducible image is distributed under a new "repro" tag [2]. This is due to one important caveat: to ensure reproducibility, the pacman keys have to be stripped from the image, meaning that pacman is not usable *out of the box* in this image. Users will need to (re)generate the pacman keyring (by running `pacman-key --init && pacman-key --populate archlinux`) before being able to update the system and install packages via pacman. While waiting to find a suitable solution to this technical constraint, we are therefore providing this reproducible image under a dedicated tag as a first milestone. The bit-for-bit reproducibility of the image is confirmed by digest equality across builds (`podman inspect --format '{{.Digest}}' <image>`) and by running `diffoci` [3] to compare builds. We provide documentation on how to reproduce this Docker image [4] (as we did for the WSL image as well [5]). Building the base rootFS for the Docker image in a deterministic way was the main challenge, but it reuses the same process as for our WSL image [6] (as both share the same rootFS build system). The main Docker-specific adjustments include: - Set `SOURCE_DATE_EPOCH` and honor it in the `org.opencontainers.image.created` LABEL in the Dockerfile - Remove the ldconfig auxiliary cache file (which introduces non-determinism) from the built image in the Dockerfile - Normalize timestamps during `docker build` / `podman build` using the `--source-date-epoch=$SOURCE_DATE_EPOCH` and `--rewrite-timestamp` options. You can check the related change set in our archlinux-docker repository [7] for more details. This represents another meaningful achievement in our "reproducible builds" efforts and we’re already looking forward to the next step! [1] https://lists.archlinux.org/archives/list/arch-dev-public@lists.archlinux.o… [2] https://hub.docker.com/layers/archlinux/archlinux/repro [3] https://github.com/reproducible-containers/diffoci [4] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/blob/master/REPRO… [5] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/blob/main/REPRO.md [6] https://gitlab.archlinux.org/archlinux/archlinux-wsl/-/commit/7c0340e263580… [7] https://gitlab.archlinux.org/archlinux/archlinux-docker/-/merge_requests/96… -- Regards, Robin Candau / Antiz

1 0

postfix-tlspol 1.9.0-1 pulled out of [extra-testing]
by Robin Candau 17 Apr '26

17 Apr '26

Hi all, postfix-tlspol 1.9.0-1 was pulled out of [extra-testing] as the package needs changes to work with the new upstream socket setup. A new version will be pushed to testing once we figured it out. Testing users can downgrade to the postfix-tlspol 1.8.27-1 package currently in [extra]. -- Regards, Robin Candau / Antiz

1 0

Spring cleanup '26
by Antonio Rojas 11 Apr '26

11 Apr '26

It's that time of the year again. Please head to https://archlinux.org/devel/reports/unneeded-orphans/ and adopt packages you want to keep in the repos. For reference, a current list of packages is attached (but this may vary as packages are adopted/disowned). If you adopt a package from the list, make sure to check its dependencies and also adopt them in case they are orphan. This is also a good time to check your out-of-date and/or unmaintained by upstream packages and disown the ones you no longer have interest in/time to maintain, so they can find a maintainer in the official repos or otherwise in AUR. Keeping packages out of date and/or with unfixed issues for months/years is not ideal and can be detrimental to the overall quality of our distro in the long run. I will start dropping packages to AUR in ~ 10 days. archlinux-themes-slim axel b43-fwcutter banner beebeep byobu caja-actions clusterssh coolreader cutefish-screenshot djview dma dnsperf erlang-docs finch focuswriter gcdmaster gephi gobby gtksourceviewmm-docs hepmc hepmc-docs horst inadyn ipv6calc josm lhapdf libbobcat libmemcached-awesome libofa libxml++2.6-docs ls++ ltrace manuskript merkaartor mono-addins nginx-mod-vts nitroshare nrpe openui5 pam-krb5 pencil2d penguin-subtitle-player photoflare php-geoip php-legacy-geoip php-legacy-memcache php-memcache php-memcached polly purple-plugin-pack python-cpplint python-olm python-oset python-sphinxcontrib-bibtex python-sphinxcontrib-spelling python-virtualenvwrapper qjournalctl qnapi quilt radcli reactphysics3d reactphysics3d-docs remind rhino-javadoc rofi-pass slim-themes splix sysdig tinyemu ukui-notification-daemon vim-seti volumeicon wakatime xbindkeys xfce4-artwork xfce4-datetime-plugin xfwm4-themes xplot

4 6

Update on Valve sponsored work in Q1 2026
by Sven-Hendrik Haase 08 Apr '26

08 Apr '26

Hi all, here is a quick progress report on Valve sponsored work in Q1 2026. We figured quarterly reports is a good cadence. ## Signstar - Milestones have been added and adjusted to contain work items for the proposed steps described in [RFC 0059]. - We have split out the mkosi-based image-building setup to the separate [Signstar-OS GitLab] repository. - In a [milestone for YubiHSM2 support] we track the remaining work required to automate the use of a YubiHSM2 as backend with Signstar - In this context we have rewritten the configuration layer, to accommodate several backends and are still busy with a few places to refactor for this larger change. - Improvements to the project's task running integration have been made to simplify this for direct use and CI. - We fixed a couple of bugs in the YubiHSM library (`yubihsm.rs`). - A small proof-of-concept has been designed and implemented for encryption and decryption of Yubico backup format, including parsing and wrapping ed25519 signing keys, AES-128 authorization keys and opaque data. The backup format is compatible with Yubico's own tools. Work is under way to expose these features as a CLI tool. - In a [milestone for a virtualized test setup] we are working towards creating a public environment that can be used by interested developers and package maintainers for test purposes and will at the same time serve as a long-term staging environment for automated updates. Generally, you can follow our work on the [Signstar GitLab] and [Signstar-OS GitLab] projects. ## Buildbtw Following the concessions of the last progress report, we are happy to report that we're now back to full capacity. In the last report, we announced that we had started work on the production version of buildbtw. By now, we have migrated most of the code from the PoC into the new production version and done most of the production-readiness work we set out to do. In contrast to the PoC, all the new production code is reviewed in-depth, documented, and well-tested. - Continuous deployment for review, staging and production environments ([buildbtw-archlinux-org]) - Keycloak roles are automatically mapped to buildbtw roles for permission management - Build graph calculation, diffing, and persistence - GitLab Executor running builds in vmexec and uploads artifacts - vmexec fixes, features, and a lot of testing - Modern responsive web UI - Session management & API keys - Parallel repo updater/cloner Next steps and in-progress work: - Nice bbtw CLI with good developer experience - API docs - Finish up pipeline scheduling - Separate out the repo-updater crate into its own project - Deploy the GitLab Executor As always, you can follow us over at GitLab [gitlab-buildbtw] and specifically the current milestone [buildbtw-milestone]. ## Meeting Notes Meeting notes are available for staff in the [internal-notes] repository. [RFC 0059]: https://rfc.archlinux.page/0059-automated-digital-signing-of-os-artifacts/ [Signstar GitLab]: https://gitlab.archlinux.org/archlinux/signstar [Signstar-OS GitLab]: https://gitlab.archlinux.org/archlinux/signstar-os [buildbtw-archlinux-org]: https://buildbtw.archlinux.org/ [buildbtw-milestone]: https://gitlab.archlinux.org/archlinux/buildbtw/-/milestones/10 [gitlab-buildbtw]: https://gitlab.archlinux.org/archlinux/buildbtw/-/boards/24162 [internal-notes]: https://gitlab.archlinux.org/archlinux/internal-notes/-/tree/main/valve [milestone for a virtualized test setup]: https://gitlab.archlinux.org/archlinux/signstar/-/milestones/6 [milestone for YubiHSM2 support]: https://gitlab.archlinux.org/archlinux/signstar/-/milestones/12

1 0

RFC: Boot standardization and bootchain package
by Morten Linderud 07 Apr '26

07 Apr '26

Yo, A new RFC (request for comment) has been opened here: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/66 Please visit the above link for discussion. Summary: Standardize and unify the Arch Linux boot chain with `kernel-install` and the `bootchain` package. -- Morten Linderud PGP: 9C02FF419FECBE16

1 0

News draft: kea >= 1:3.0.3-2 update requires manual intervention
by Robin Candau 05 Apr '26

05 Apr '26

Hi everyone, Our Kea (ISC's DHCP server) package is moving to a non-root setup to run services for improved security. This implies a manual intervention for users upgrading from an existing installation. See the news draft below (pad available at https://md.archlinux.org/1TykcWc0TPaz3MAuwfm9Fw) --- Starting with `kea 1:3.0.3-2`, all kea services now run as a dedicated non-privileged `kea` user (instead of `root`) for improved security. This change requires a manual intervention for users upgrading from `kea` <= `1:3.0.3-1` to >= `1:3.0.3-2`, in order to update the permissions and ownership of the kea files and directories accordingly. After upgrading, run the following commands to update permissions and ownership of kea files and directories, then restart the affected services (if they are running): ```bash chmod 755 /etc/kea/{,radius} /usr/include/kea/{,asiodns,asiolink,cc,config,config_backend,cryptolink,d2srv,database,dhcp,dhcp_ddns,dhcpsrv,dhcpsrv/parsers,dns,eval,exceptions,hooks,http,log,log/interprocess,mysql,pgsql,process,process/cfgrpt,stats,tcp,util,util/encode,util/io} /usr/lib/kea/{,hooks} /usr/lib/python3.14/site-packages/kea/{,__pycache__/} /usr/share/kea/{,api,meson-info,scripts,scripts/mysql,scripts/pgsql} chmod 644 /etc/kea/*.conf /etc/kea/radius/* chown kea: /var/lib/kea/* /var/log/kea/* /run/lock/kea/logger_lockfile systemctl try-restart kea-ctrl-agent.service kea-dhcp{4,6,-ddns}.service ``` If necessary, you can run `pacman -Qkk kea` to find any other permission deviations and adjust as needed. --- -- Regards, Robin Candau / Antiz

1 1