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

Draft: AUR malicious packages incident
by Campbell Jones 12 Jun '26

12 Jun '26

The draft follows: --- We are currently experiencing a high volume of malicious package adoptions and updates in the Arch User Repository. We are actively working to track down existing malicious commits and attempting to prevent additional malicious commits from being pushed. While this is happening, and while we work to create a more permanent solution, users may see issues with the following: - Creating new accounts on the AUR - Pushing package updates - Adopting or creating new packages We encourage active users of AUR packages to review *all* PKGBUILD changes when updating, especially during this time. If you notice suspicious commits to a package that you use, please reach out to Arch staff via the aur-general mailing list with more information. --- Campbell

1 1

apparmor 5.0.0-1 pulled out of [extra-testing]
by Robin Candau 03 Jun '26

03 Jun '26

Hi everyone, apparmor 5.0.0-1 was pulled out of [extra-testing] as it introduces a fair amount of regressions that cannot be reasonably fixed with patches at the packaging level. We will wait for the next upstream release. Testing users can downgrade to the apparmor 4.1.7-1 package currently in [extra]. -- Regards, Robin Candau / Antiz

1 0

systemd v261 pre-releases
by Christian Hesse 28 May '26

28 May '26

Hello everybody, the systemd development team has started pushing pre-release for the upcoming v261 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. Please note: With an encrypted disk you need at least mkinitcpio 41-4, currently in core-testing. Happy testing! [0] https://github.com/systemd/systemd/blob/v261-rc2/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 0

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