Connexion
PHP versions prior to 8.5.12 and 8.3.36 are affected by CVE-2026-109618 and CVE-2026-109619, which allow for remote code execution.
For any system publicly exposing a PHP application with the help of a prior version of PHP, we urge users to upgrade those systems to the latest available version of PHP (php ≥ 8.5.12 and php-legacy ≥ 8.3.36) immediately.
Edit: For further details and instructions, please refer to the Arch Linux Security Advisories ASA-202610-1 and ASA-202610-2.
On 2026-10-20 it was revealed, that several certificates of the eMudhra intermediate Certificate Authority have been compromised.
The compromised certificates have been removed/invalidated with ca-certificates-mozilla ≥ 3.131.1-1.
Without an update to this central certificate bundle, systems are susceptible to man-in-the-middle attacks. As such, we urge everyone to upgrade their systems immediately.
Starting with package version 42-1, the mkinitcpio systemd hook now includes systemd-pcrosseparator.service (as intended by systemd v261).
This affects the measurements of PCR values 0-7, 9 and 12-14.
If you configured the systemd hook and unlock LUKS partitions, that depend on these values, you need to re-enroll the TPM2 in use.
For guidance, please refer to systemd-cryptenroll(1), or the ArchWiki article on systemd-cryptenroll, when using pinned values.
Refer to systemd-pcrlock(8), when relying on custom policies and a disabled systemd-pcrlock-make-policy.service.
Previously, we installed its contents in a way that made pacman not
aware of the files (using VBoxManage extpack install ... from an
install script). To mitigate issues during upgrade, you can use one of
the following methods:
Lateo.net - Flux RSS en pagaille (pour en ajouter : @ moi) virtualbox-ext-vnc before upgrading the system, then
installing it again.VBoxManage extpack uninstall 'VNC' as root before upgrading the
system.pacman once to overwrite the existing files:pacman -Syu --overwrite '/usr/lib/virtualbox/ExtensionPacks/VNC/*'
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:
We continue to encourage all users of AUR packages to review all PKGBUILD and install script 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.
Recently we held our leader elections and after a lively discussion period on the (internal) mailing lists and voting phase with two candidates Levente "anthraxx" Polyák was re-elected as Arch Linux Project Lead.
As per our election rules he is re-elected with the term lasting two years.
The role of of the project lead within Arch Linux is connected to a bunch of responsibilities regarding decision making (when no consensus can be reached), community leadership, Code of Conduct enforcement, handling financial matters with SPI and overall project management tasks.
Congratulations to Levente, thank you for stepping up to serve this community and all the best wishes for another successful term! 🥳
The Varnish project has renamed itself to Vinyl Cache.
We followed this rename with a new vinyl-cache package.
This upgrade results in breaking changes 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:
/etc/varnish to /etc/vinyl-cache/var/lib/varnish to /var/lib/vinyl-cache/var/lib/varnishvarnish becomes vinylvarnish becomes vinylvarnishlog becomes vinyllogvcache remains the samevarnish.service and varnishncsa.service systemd unitsvinyl-cache.service and vinylncsa.service systemd unitsMeanwhile, the varnish package has been dropped from [extra].
We're not currently planning to maintain a new varnish package as it's a different upstream project.
The kea package has moved all services to run as a dedicated kea user (instead of root) for improved security. This change requires permission updates to the runtime files created by the kea services.
Users upgrading from an existing kea installation should therefore run the following commands after the upgrade:
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
Accounts that need to interact with kea services files (e.g. lease files under /var/lib/kea, log files under /var/log/kea or configuration files under /etc/kea) should be added to the kea group.
The old iptables-nft package name is replaced by iptables, and the legacy backend is available as iptables-legacy.
When switching packages (among iptables-nft, iptables, iptables-legacy), check for .pacsave files in /etc/iptables/ and restore your rules if needed:
Most setups should work unchanged, but users relying on uncommon xtables extensions or legacy-only behavior should test carefully and use iptables-legacy if required.
With the update to driver version 590, the NVIDIA driver no longer supports Pascal (GTX 10xx) GPUs or older. We will replace the nvidia package with nvidia-open, nvidia-dkms with nvidia-open-dkms, and nvidia-lts with nvidia-lts-open.
Impact: Updating the NVIDIA packages on systems with Pascal, Maxwell, or older cards will fail to load the driver, which may result in a broken graphical environment.
Intervention required for Pascal/older users: Users with GTX 10xx series and older cards must switch to the legacy proprietary branch to maintain support:
nvidia, nvidia-lts, or nvidia-dkms packages.nvidia-580xx-dkms from the AURUsers with Turing (20xx and GTX 1650 series) and newer GPUs will automatically transition to the open kernel modules on upgrade and require no manual intervention.
The following packages may require manual intervention due to the upgrade from 9.0 to 10.0:
pacman may display the following error failed to prepare transaction (could not satisfy dependencies) for the affected packages.
If you are affected by this and require the 9.0 packages, the following commands will update e.g. aspnet-runtime to aspnet-runtime-9.0:
pacman -Syu aspnet-runtime-9.0
pacman -Rs aspnet-runtime
The waydroid package prior to version 1.5.4-2 (including aur/waydroid) creates Python byte-code files (.pyc) at runtime which were untracked by pacman. This issue has been fixed in 1.5.4-3, where byte-compiling these files is now done during the packaging process.
As a result, the upgrade may conflict with the unowned files created in previous versions. If you encounter errors like the following during the update:
error: failed to commit transaction (conflicting files)
waydroid: /usr/lib/waydroid/tools/__pycache__/__init__.cpython-313.pyc exists in filesystem
waydroid: /usr/lib/waydroid/tools/actions/__pycache__/__init__.cpython-313.pyc exists in filesystem
waydroid: /usr/lib/waydroid/tools/actions/__pycache__/app_manager.cpython-313.pyc exists in filesystem
You can safely overwrite these files by running the following command:
pacman -Syu --overwrite /usr/lib/waydroid/tools/\*__pycache__/\*
The dovecot 2.4 release branch has made breaking changes which result in it being incompatible with any <= 2.3 configuration file.
Thus, the dovecot service will no longer be able to start until the configuration file was migrated, requiring manual intervention.
For guidance on the 2.3-to-2.4 migration, please refer to the following upstream documentation: Upgrading Dovecot CE from 2.3 to 2.4
Furthermore, the dovecot 2.4 branch no longer supports their replication feature, it was removed.
For users relying on the replication feature or who are unable to perform the 2.4 migration right now, we provide alternative packages available in [extra]:
The dovecot 2.3 release branch is going to receive critical security fixes from upstream until stated otherwise.
We want to provide an update on the recent service outages affecting our infrastructure. The Arch Linux Project is currently experiencing an ongoing denial of service attack that primarily impacts our main webpage, the Arch User Repository (AUR), and the Forums.
We are aware of the problems that this creates for our end users and will continue to actively work with our hosting provider to mitigate the attack. We are also evaluating DDoS protection providers while carefully considering factors including cost, security, and ethical standards.
To improve the communication around this issue we will provide regular updates on our service status page going forward.
As a volunteer-driven project, we appreciate the community's patience as our DevOps team works to resolve these issues. Please bear with us and thank you for all the support you have shown so far.
reflector is hosted on this site. Please default to the mirrors listed in the pacman-mirrorlist package during an outage.0x3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C (or other trusted keys that may be used in the future).$ git clone --branch <package_name> --single-branch https://github.com/archlinux/aur.git <package_name>arch-wiki-docs and arch-wiki-lite contain recent snapshots of the articles as hosted on the Arch Linux wiki.Our services may send an initial connection reset due to the TCP SYN authentication performed by our hosting provider, but subsequent requests should work as expected.
We are keeping technical details about the attack, its origin and our mitigation tactics internal while the attack is still ongoing.
Starting with 7.4.1-2, the following Zabbix system user accounts (previously shipped by their related packages) will no longer be used. Instead, all Zabbix components will now rely on a shared zabbix user account (as originally intended by upstream and done by other distributions):
zabbix-agent2 package)This shared zabbix user account is provided by the newly introduced zabbix-common split package, which is now a dependency for all relevant zabbix-* packages.
The switch to the new user account is handled automatically for the corresponding main configuration files and systemd service units.
However, manual intervention may be required if you created custom files or configurations referencing to and / or being owned by the above deprecated users accounts, for example:
PSK files used for encrypted communicationsudoers rules for metrics requiring elevated privileges to be collectedThose should therefore be updated to refer to and / or be owned by the new zabbix user account, otherwise some services or user parameters may fail to work properly, or not at all.
Once migrated, you may remove the obsolete user accounts from your system.
With 20250613.12fe085f-5, we split our firmware into several vendor-focused packages. linux-firmware is now an empty package depending on our default set of firmware.
Unfortunately, this coincided with upstream reorganizing the symlink layout of the NVIDIA firmware, resulting in a situation that Pacman cannot handle. When attempting to upgrade from 20250508.788aadc8-2 or earlier, you will see the following errors:
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem
linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem
To progress with the system upgrade, first remove linux-firmware, then reinstall it as part of the upgrade:
# pacman -Rdd linux-firmware
# pacman -Syu linux-firmware
On Plasma 6.4 the wayland session will be the only one installed when the users does not manually specify kwin-x11.
With the recent split of kwin into kwin-wayland and kwin-x11, users running the old X11 session needs to manually install plasma-x11-session, or they will not be able to login. Currently pacman is not able to figure out your personal setup, and it wouldn't be ok to install plasma-x11-session and kwin-x11 for every one using Plasma.
We are transitioning the wine and wine-staging package to a pure wow64 build. This change removes the dependency on the multilib repository for wine and wine-staging.
The main reason for this is to align with upstream Wine development, which simplifies packaging and the dependency chain.
Potential Issues:
If you are facing issues with 32 bit prefixes, please recreate these and reinstall the application.
Valkey, a high-performance key/value datastore, will be replacing redis in the [extra] repository. This change is due to Redis modifying its license from BSD-3-Clause to RSALv2 and SSPLv1 on March 20th, 2024.
Arch Linux Package Maintainers intend to support the availability of the redis package for roughly 14 days from the day of this post, to enable a smooth transition to valkey. After the 14 day transition period has ended, the redis package will be moved to the AUR. Also, from this point forward, the redis package will not receive any additional updates and should be considered deprecated until it is removed.
Users are recommended to begin transitioning their use of Redis to Valkey as soon as possible to avoid possible complications after the 14 day transition window closes.
Around two years ago, we've merged the [community] repository into [extra] as part of the git migration.
In order to not break user setups,
we kept these repositories around in an unused and empty state.
We're going to clean up these old repositories on 2025-03-01.
On systems where /etc/pacman.conf still references the old
[community] repository, pacman -Sy will return an error on trying to
sync repository metadata.
The following deprecated repositories will be removed: [community],
[community-testing], [testing], [testing-debug], [staging],
[staging-debug].
Please make sure to remove all use of the aforementioned repositories from your /etc/pacman.conf (for which a .pacnew was shipped with pacman>=6.0.2-7)!
We plan to move glibc and its friends to stable later today, Feb 3. After installing the update, the Discord client will show a red warning that the installation is corrupt.
This issue has been fixed in the Discord canary build. If you rely on audio connectivity, please use the canary build, login via browser or the flatpak version until the fix hits the stable Discord release.
There have been no reports that (written) chat connectivity is affected.
UPDATE: The issue has been fixed in Discord 0.0.84-1.
We'd like to raise awareness about the rsync security release version 3.4.0-1 as described in our advisory ASA-202501-1.
An attacker only requires anonymous read access to a vulnerable rsync server, such as a public mirror, to execute arbitrary code on the machine the server is running on.
Additionally, attackers can take control of an affected server and read/write arbitrary files of any connected client.
Sensitive data can be extracted, such as OpenPGP and SSH keys, and malicious code can be executed by overwriting files such as ~/.bashrc or ~/.popt.
We highly advise anyone who runs an rsync daemon or client prior to version 3.4.0-1 to upgrade and reboot their systems immediately.
As Arch Linux mirrors are mostly synchronized using rsync, we highly advise any mirror administrator to act immediately, even though the hosted package files themselves are cryptographically signed.
All infrastructure servers and mirrors maintained by Arch Linux have already been updated.
Arch Linux hasn't had a license for any package sources (such as PKGBUILD files) in the past, which is potentially problematic. Providing a license will preempt that uncertainty.
In RFC 40 we agreed to change all package sources to be licensed under the very liberal 0BSD license. This change will not limit what you can do with package sources. Check out the RFC for more on the rationale and prior discussion.
Before we make this change, we will provide contributors with a way to voice any objections they might have. Starting on 2024-11-19, over the course of a week, contributors will receive a single notification email listing all their contributions.
If you contributed to Arch Linux packages before but didn't receive an email, please contact us at package-sources-licensing@archlinux.org.
With the release of version 7.0.0 pacman has added support for downloading packages as a separate user with dropped privileges.
For users with local repos however this might imply that the download
user does not have access to the files in question, which can be fixed
by assigning the files and folder to the alpm group and ensuring the
executable bit (+x) is set on the folders in question.
$ chown :alpm -R /path/to/local/repo
Remember to merge the .pacnew files to apply the new default.
Pacman also introduced a change to improve checksum stability for
git repos that utilize .gitattributes files. This might require a
one-time checksum change for PKGBUILDs that use git sources.
After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections (see https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5).
When upgrading remote hosts, please make sure to restart the sshd service
using systemctl try-restart sshd right after upgrading.
We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.
Recently we held our leader election, and the previous Project Leader Levente "anthraxx" Polyák ran again while no other people were nominated for the role.
As per our election rules he is re-elected for a new term.
The role of of the project lead within Arch Linux is connected to a few responsibilities regarding decision making (when no consensus can be reached), handling financial matters with SPI and overall project management tasks.
Congratulations to Levente and all the best wishes for another successful term! 🥳
The vm.max_map_count parameter will be increased from the default 65530 value to 1048576.
This change should help address performance, crash or start-up issues for a number of memory intensive applications, particularly for (but not limited to) some Windows games played through Wine/Steam Proton. Overall, end users should have a smoother experience out of the box with no expressed concerns about potential downsides in the related proposal on arch-dev-public mailing list.
This vm.max_map_count increase is introduced in the 2024.04.07-1 release of the filesystem package and will be effective right after the upgrade.
Before upgrading, in case you are already setting your own value for that parameter in a sysctl.d configuration file, either remove it (to switch to the new default value) or make sure your configuration file will be read with a higher priority than the /usr/lib/sysctl.d/10-arch.conf file (to supersede the new default value).
Update: To our knowledge the malicious code which was distributed via the release tarball never made it into the Arch Linux provided binaries, as the build script was configured to only inject the bad code in Debian/Fedora based package build environments. The news item below can therefore mostly be ignored.
We are closely monitoring the situation and will update the package and news as neccesary.
TL;DR: Upgrade your systems and container images now!
As many of you may have already read (one), the upstream release tarballs for xz in version 5.6.0 and 5.6.1 contain malicious code which adds a backdoor.
This vulnerability is tracked in the Arch Linux security tracker (two).
The xz packages prior to version 5.6.1-2 (specifically 5.6.0-1 and 5.6.1-1) contain this backdoor.
The following release artifacts contain the compromised xz:
2024.03.0120240301.218094 and 20240315.221711The affected release artifacts have been removed from our mirrors.
We strongly advise against using affected release artifacts and instead downloading what is currently available as latest version!
It is strongly advised to do a full system upgrade right away if your system currently has xz version 5.6.0-1 or 5.6.1-1 installed:
pacman -Syu
To figure out if you are using an affected container image, use either
podman image history archlinux/archlinux
or
docker image history archlinux/archlinux
depending on whether you use podman or docker.
Any Arch Linux container image older than 2024-03-29 and younger than 2024-02-24 is affected.
Run either
podman image pull archlinux/archlinux
or
docker image pull archlinux/archlinux
to upgrade affected container images to the most recent version.
Afterwards make sure to rebuild any container images based on the affected versions and also inspect any running containers!
From the upstream report (one):
openssh does not directly use liblzma. However debian and several other distributions patch openssh to support systemd notification, and libsystemd does depend on lzma.
Arch does not directly link openssh to liblzma, and thus this attack vector is not possible. You can confirm this by issuing the following command:
ldd "$(command -v sshd)"
However, out of an abundance of caution, we advise users to remove the malicious code from their system by upgrading either way. This is because other yet-to-be discovered methods to exploit the backdoor could exist.
With the release of mkinitcpio v38, several hooks previously provided by Arch packages have been moved to the mkinitcpio upstream project. The hooks are: systemd, udev, encrypt, sd-encrypt, lvm2 and mdadm_udev.
To ensure no breakage of users' setup occurs, temporary conflicts have been introduced into the respective packages to prevent installing packages that are no longer compatible.
The following packages needs to be upgraded together:
Please note that the mkinitcpio flag --microcode, and the microcode option in the preset files, has been deprecated in favour of
a new microcode hook. This also allows you to drop the microcode initrd
lines from your boot configuration as they are now packed together with the main initramfs image.
We are making dbus-broker our default implementation of D-Bus, for
improved performance, reliability and integration with systemd.
For the foreseeable future we will still support the use of dbus-daemon,
the previous implementation. Pacman will ask you whether to install
dbus-broker-units or dbus-daemon-units. We recommend picking the
default.
For a more detailed rationale, please see our RFC 25.
We are happy to announce that the migration of the bugtracker to GitLab is done! 🥳
Thanks to everyone who has helped during the migration!
This means the issue tracker and merge requests on the GitLab package repos are now enabled.
The old bugtracker will subsequently be closed down. For archiving reasons there will be a static copy so that links (for example the randomly picked Task #56716) are still stable, migrated bugs have a closing comment pointing to the new URL on GitLab.
Packaging bugs are now opened on the repo hosting the corresponding packaging sources, the "Add a new Bug" button on the package page on archlinux.org will automatically direct you to the correct place to open the issue. The workflow afterwards is mostly the same, first our Bug Wranglers will have a look at the issues and triage them, and then they will be handed over to the respective Package Maintainers to fix. A list of all issues can be found here.
If you do not have an account for GitLab already (which authenticates against our SSO service), please write us a mail with your desired username to accountsupport@archlinux.org as advised in the banner.
We are introducing a change in JDK/JRE packages of our distro. This is triggered from the way a JRE is build in modern versions of Java (>9). We are introducing this change in Java 21.
To sum it up instead of having JDK and JRE packages coexist in the same system we will be making them conflict. The JDK variant package includes the runtime environment to execute Java applications so if one needs compilation and runtime of Java they need only the JDK package in the future. If, on the other hand, they need just runtime of Java then JRE (or jre-headless) will work.
This will (potentially) require a manual user action during upgrade:
pacman -Sy jdk-openjdk && pacman -Su and this removes the JRE related packages.At the moment this is only valid for the upcoming JDK 21 release, with other versions to follow.
With shadow >= 4.14.0, Arch Linux's default password hashing algorithm changed from SHA512 to yescrypt.
Furthermore, the umask settings are now configured in /etc/login.defs instead of /etc/profile.
This should not require any manual intervention.
The password-based key derivation function (KDF) and password hashing scheme yescrypt has been chosen due to its adoption (readily available in libxcrypt, which is used by pam) and its stronger resilience towards password cracking attempts over SHA512.
Although the winner of the Password Hashing Competition has been argon2, this algorithm is not yet available in libxcrypt (attempt one, attempt two).
The YESCRYPT_COST_FACTOR setting in /etc/login.defs is currently without effect, until pam implements reading its value. If a YESCRYPT_COST_FACTOR higher (or lower) than the default (5) is needed, it can be set using the rounds option of the pam_unix module (i.e. in /etc/pam.d/system-auth).
ENCRYPT_METHOD in /etc/login.defs and does not override the chosen method anymore2023.09.18) and pambase (>= 20230918) packages ensure, that umask is set centrally in /etc/login.defs instead of /etc/profileAs of ansible-core 2.15.3, upstream moved documentation and examples to a separate dedicated repository (see the related changelogs).
This means that, starting from version 2.15.3 the ansible-core package will stop shipping documentation and a default configuration example under /etc/ansible/ansible.cfg.
Regarding the documentation, it is available online: https://docs.ansible.com/
As for the configuration file, as explained in the wiki, a base config can be generated with the following command:
ansible-config init --disabled > ansible.cfg
After updating from ansible-core <= 2.15.2-1 to >= 2.15.3-1, everyone using a custom global Ansible configuration file stored under /etc/ansible/ansible.cfg will have their configuration saved as a pacsave file.
To restore it, run the following command:
mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg
When upgrading from budgie-desktop 10.7.2-5 to 10.7.2-6, the package mutter43 must be replaced with magpie-wm, which currently depends on mutter. As mutter43 conflicts with mutter, manual intervention is required to complete the upgrade.
First remove mutter43, then immediately perform the upgrade. Do not relog or reboot between these steps.
pacman -Rdd mutter43
pacman -Syu
Starting from version 2023.66594-9, TeX Live packages have been reorganized to mirror upstream collections. Even though the new texlive-basic replaces the old texlive-core, many of the texlive-core contents (including language specific files) are now split between different packages. To find out which Arch package contains a specific CTAN package, you can use the tlmgr utility, eg.
$ tlmgr info euler | grep collection
collection: collection-latexrecommended
which means the euler CTAN package is contained in texlive-latexrecommended. You may also use pacman -F to query for specific files.
A new metapackage texlive-meta is available to install all subpackages (except for language specific ones), and the new texlive-doc package provides the full documentation for offline use.
The openblas package prior to version 0.3.23-2 doesn't ship optimized LAPACK routine and CBLAS/LAPACKE interfaces for compatibility. This decision has been reverted now, and the ability to choose a different default system BLAS/LAPACK implementation while keeping openblas installed is now provided to allow future co-installation of BLIS, ATLAS, etc.
The default BLAS implementation will be used for most packages like NumPy or R. Please install "blas-openblas" and "blas64-openblas" to make OpenBLAS the default BLAS implementation, just like the old behavior.
Unfortunately you will get errors on updating if you currently have OpenBLAS installed as the default BLAS implementation:
error: failed to prepare transaction (could not satisfy dependencies) :: installing openblas (0.3.23-2) breaks dependency 'blas' required by cblas :: installing openblas (0.3.23-2) breaks dependency 'blas' required by lapack
Please append your preferred default BLAS implementation to the regular -Syu command line to get around it. For example:
pacman -Syu blas-openblas
or
pacman -Syu blas
We are proud to announce that the migration to Git packaging succeeded! 🥳
Thanks to everyone who has helped during the migration!
Package sources are now available on GitLab. Note that the bugtracker is still flyspray and that merge requests are not accepted as of now. We intend to open the issue tracker and merge requests on the Gitlab package repos in the near future.
Mirrors are syncing again, but it may take a bit of time until your mirror of choice has caught up.
Update your system and merge the pacman pacnew /etc/pacman.conf.pacnew file. This is required as we have moved the [community] repository into [extra].
$ pacman -Syu "pacman>=6.0.2-7"
For users of the now deprecated asp tool, you will need to switch to pkgctl:
$ pacman -Syu "devtools>=1:1.0.0-1"
$ pkgctl repo clone linux
For some more detailed instructions on how to obtain PKGBUILDs see the corresponding wiki article.
Before starting, first uninstall devtools-git-poc and remove any repos from your filesystem that you cloned during the git proof-of-concept testing.
Make sure you have both, an updated devtools and pacman on your system:
$ pacman -Syu "devtools>=1:1.0.0-1" "pacman>=6.0.2-7"
Additionally clean up old chroots in /var/lib/archbuild/
$ rm -rf /var/lib/archbuild/
# or optionally, use the --clean option for pkgctl build *ONCE*
$ pkgctl build --clean
For instruction on how to use pkgctl, please take a look at the "How to be a packager" wiki article and also consult the man page of each subcommand for further information:
$ man pkgctl-build
$ man pkgctl-repo-clone
This Friday morning (2023-05-19) the Git packaging migration will start until Sunday (2023-05-21). The Arch Linux packaging team will not be able to update packages in any of the repositories during this period.
Notification when the migration starts, and when it is completed, will be published on the [arch-dev-public] mailing list.
The [testing] repository will be split into [core-testing] and [extra-testing], the [staging] repository will be split into [core-staging] and [extra-staging]. The [community] repository will be merged into [extra] and will therefore be empty after the migration.
All affected repositories will be provided as empty repositories for a transition period after the migration. For regular users, this means that everything works as before.
Note: After the migration is done, users that have the testing repositories enabled need to include the new repositories ([core-testing] and [extra-testing] instead of [testing]) in their pacman.conf before updating their system.
Other changes:
asp, which relies on the svn2git mirror, will stop working. It is replaced by pkgctl repo clone.During the migration rsync and HTTP access will be shut down. We will send an email notification to arch-mirrors once everything has been finished.
Packagers will not be able to patch and update their packages. The internal Tier 0 mirror is also going to be disabled for the duration of this migration.
On February 2nd, the base-devel package group has been replaced by a meta package of the same name.
If you installed the base-devel package group prior to this date, explicitly re-install it to get the new base-devel package installed on the system:
pacman -Syu base-devel
The php packages have been updated to the latest version 8.2. In
addition to this, a new set of php-legacy packages have been
introduced. These will follow the oldest but still actively supported
PHP branch. This enables users to install the latest version but also
introduces the option to use third party applications that might rely
on an older version. Both branches will be kept up to date following
our rolling release model. php and php-legacy can be installed at the
same time as the latter uses a -legacy suffix for its binaries and
configuration files.
In addition to this, the php7 packages have been removed as they
reached end of life. The imap extension will no longer be provided as
it relies on the c-client library which has been abandoned for many
years.
Arch Linux mourns the sudden loss of Jonathon Fernyhough, known in our community as jonathon, who passed away on Saturday night.
Jonathon was an active participant and contributor to Arch Linux, several derived distributions, the AUR and through personal repositories. He was enthusiastic, helpful and eager to contribute towards improving the free and open source software community as a whole.
On behalf of the wider Arch Linux community, our condolences go out to his family and friends.
Python 2 went end of life January 2020. Since then we have been actively cutting down the number of projects depending on python2 in our repositories, and we have finally been able to drop it from our distribution. If you still have python2 installed on your system consider removing it and any python2 package.
If you still require the python2 package you can keep it around, but please be aware that there will be no security updates. If you need a patched package please consult the AUR, or use an unofficial user repository.
As part of dropping Python 2 which is EOL, we have migrated our mailing lists from mailman2 to mailman3.
Rewriting of the "From" header and subject (to prepend the list name) have been disabled to keep the DKIM signature intact. This means "reply to mailing list" must be used when replying to the list and you may need to update your filters and rules matching the "From" header.
All existing subscriptions are migrated and you do not need to re-subscribe. For managing your subscriptions a new mailman3 account must be registered.
Recent changes in grub added a new command option to fwsetup and changed the
way the command is invoked in the generated boot configuration. Depending on
your system hardware and setup this could cause an unbootable system due to
incompatibilities between the installed bootloader and configuration. After a
grub package update it is advised to run both, installation and regeneration
of configuration:
grub-install ...
grub-mkconfig -o /boot/grub/grub.cfg
For more specific information on grub-install, please refer to the wiki:
GRUB - ArchWiki
wxWidgets 3.2 provides a Qt frontend in addition to the GTK3 one, so packages have been renamed from wxgtk- to wxwidgets-. The GTK2 frontend is no longer provided. If you have wxgtk2 installed, the upgrade will fail with
error: failed to prepare transaction (could not satisfy dependencies) :: removing wxgtk-common breaks dependency 'wxgtk-common' required by wxgtk2
In such case, uninstall wxgtk2 first and then proceed with the upgrade.
Two days ago the wireplumber package was made to replace pipewire-media-session as the latter session manager for PipeWire is considered dead upstream and will see no more releases. Unfortunately, this step was premature.
Our pipewire audio packages (pipewire-alsa, pipewire-jack and pipewire-pulse) ship configuration that prompt media-session to activate PipeWire's audio features. When these packages are not installed and the configuration is missing, PipeWire can be used for screen recording without interfering with ALSA or PulseAudio.
WirePlumber disregards this mechanism and always configures PipeWire to grab audio devices, meaning users of PulseAudio or bare ALSA experience broken audio.
The replacement has been reverted while we attempt to look for a better solution switching to WirePlumber. If you are currently not using PipeWire for audio and wireplumber got installed on your system, please reinstall pipewire-media-session and reboot to restore audio functionality.
pacman -Syu pipewire-media-session
With the update to qemu 7.0.0 the package has been turned into a more fine grained split package utilizing meta packages.
qemu package is now virtually provided by the meta packages
qemu-base, qemu-desktop and qemu-full.qemu prior to 7.0.0 is replaced by
qemu-desktopqemu-headless is replaced by
qemu-baseqemu-arch-extra and qemu-headless-arch-extra
is replaced by qemu-emulators-fullqemu-full provides all QEMU related
packages (excluding qemu-guest-agent)The keycloak package prior to version 17.0.1-2 was running with WildFly server. Since upstream officially moved to Quarkus distribution, Arch Linux follows this approach. This means some manual intervention is required for the upgrade.
The configuration needs to be adjusted from the old .xml format to the new /etc/keycloak/keycloak.conf.
Prior to the upgrade, stop the keycloak service, upgrade the package and migrate the configuration before starting:
systemctl stop keycloak.service
pacman -Syu keycloak
# migrate configuration /etc/keycloak/keycloak.conf
systemctl start keycloak.service
See Keycloak migration docs and Keycloak Quarkus server docs
This month we held our leader election, and our current leader Levente Polyák ran unopposed. As per our election rules he is re-elected for a new term.
Congratulations to Levente Polyak on a new term!
