Gentoo Portage Overlays - Gentoo Repository News

Varnish Renamed

Tue, 31 Mar 2026 00:00:00 +0200

# Varnish Renamed to Vinyl-Cache As of version 9.0.0, www-servers/varnish has been renamed to www-servers/vinyl-cache in line with upstream's change of name[0][1][2]. The name change also affects binaries, directories, init scripts, configuration and the user and group used by the server daemon. If you are upgrading from a previous version of www-servers/varnish you will need to update your configuration as described in "Upgrading" below. # Changes All varnish* binaries have been renamed to their vinyl* equivalents: varnishd -> vinyld varnishlog -> vinyllog varnishncsa -> vinylncsa varnishadm -> vinyladm varnishhist -> vinylhist varnishstat -> vinylstat varnishstat_help_gen -> vinylstat_help_gen varnishstatdiff -> vinylstatdiff varnishtest -> vinyltest varnishtop -> vinyltop This name change also affects all related conf.d/* files, init scripts, systemd service files, logrotate etc. The api library has been renamed: libvarnishapi.so -> libvinylapi.so In these conf.d files, all VARNISH* options are now VINYL* and you will need to update your configuration accordingly: /etc/conf.d/varnishd -> /etc/conf.d/vinyld /etc/conf.d/varnishlog -> /etc/conf.d/vinyllog /etc/conf.d/varnishncsa -> /etc/conf.d/vinylncsa The configuration directory has been moved: /etc/varnish/ -> /etc/vinyl-cache/ Other varnish directories have also been renamed: /usr/include/varnish -> /usr/include/vinyl-cache /usr/lib/varnish -> /usr/lib/vinyl-cache /usr/lib64/varnish -> /usr/lib64/vinyl-cache /usr/share/varnish -> /usr/share/vinyl-cache /var/lib/varnish -> /var/lib/vinyl-cache /var/log/varnish -> /var/log/vinyl-cache # Upgrading To upgrade from varnish 8.x to 9.x: 0) Take a backup of your existing configuration files 1) Stop all running varnish services 2) emerge --oneshot www-servers/vinyl-cache 3) Update and install your VCL files in /etc/vinyl-cache/ You can now start the new vinyld, vinyllog and vinylncsa services, remembering to add them to the appropriate runlevels as usual. Ditto systemd services. For more details of the changes, you are encouraged to read the upstream announcement[0]. # Refs [0] https://vinyl-cache.org/docs/9.0/whats-new/upgrading-9.0.html [1] https://vinyl-cache.org/organization/20-years.html [2] https://vinyl-cache.org/organization/new-identity.html

www-client/chromium slotted installation

Sun, 15 Mar 2026 00:00:00 +0100

www-client/chromium is now available as a slotted package, allowing multiple versions to be installed simultaneously. The new slots are: * www-client/chromium:stable - the latest 'stable' channel release * www-client/chromium:beta - the latest 'beta' channel release * www-client/chromium:unstable - the latest 'dev' channel release Upstream are inconsistent with `dev` channel naming, so we've gone with 'unstable' to match www-client/google-chrome* packaging. The biggest change to end-users is that various Chromium versions will no longer share a single profile directory, instead each slot (channel) will have its own profile directory as e.g. the various www-client/google-chrome packages work now. This change is particularly useful for developers who need to test their applications against different versions of Chromium, and protects against incompatible profile downgrades when switching between versions. Users on stable should not expect to see any major change, however any Progressive Web Applications (PWAs) may need to be "reinstalled" after the upgrade to update the desktop files. Users on ~arch may wish to select a specific slot to use, as due to the nature of Chromium releases, the latest ~arch version will switch between the stable and beta slots depending on where we are in the release cycle. The same advice applies to users of the dev/unstable channel (unkeyworded) as well - they may end up unexpectedly upgraded to beta if the dev channel is delayed during a promotion. Impacted users should explicitly select the appropriate slot(s) to use, e.g. by selecting www-client/chromium:stable or www-client/chromium:beta: emerge --deselect www-client/chromium emerge --noreplace www-client/chromium:stable

mail-mta/postfix-3.11.0: Default database change

Sun, 15 Mar 2026 00:00:00 +0100

The default local database type in mail-mta/postfix has been hash for local files and btree for caches and both file types depend on sys-libs/db. However, BerkeleyDB has not been developed sufficiently in recent years and the licensing change in 2013 made using the latest versions of BerkeleyDB problematic. Consequently, we are stuck with using ancient versions of BerkeleyDB and there is a general tendency in the Linux ecosystem to sunset BerkeleyDB support. Postfix made switching database types easier with its latest release. We will be changing the default database type in postfix for both local databases and caches to lmdb starting with mail-mta/postfix-3.11.0. # Timeline: - mail-mta/postfix-3.11.0: March 2026. Both lmdb and berkdb USE flags are on by default. BerkeleyDB is still supported but the default database and cache type changes to lmdb. - mail-mta/postfix-3.12.0: Expected Q1 2027. BerkeleyDB support will be off by default. You will need to turn it on manually if still needed. mail-mta/postfix will continue supporting BerkeleyDB until it is sunsetted in Gentoo. Changing the default database and cache types in postfix-3.11.0 requires migration for the entries in main.cf and master.cf that do not specify a database type. It is almost always a good idea to specify database type in main.cf and master.cf and in your postmap commands. As you are always specifying the database type, the default database and cache type settings do not come into play. Option 1: Accept the new defaults and migrate to lmdb. The default USE flags take effect and lmdb becomes the new default when >=mail-mta/postfix-3.11.0 is installed. All local database files without a specified type and, optionally, caches need to be migrated to lmdb. If your configuration is simple or if you are familiar with Postfix configuration, a few "grep" commands will find all the problems, and a few edits will be easy to make. Read https://www.postfix.org/NON_BERKELEYDB_README.html#manual for a complete walk through and the commands you can run to find instances of BerkeleyDB usage in your postfix configuration. Option 2: If your configuration is too complex for the manual migration step above or if you are not familiar with the details of your postfix configuration, postfix provides enable-redirect[1] and enable-reindex[2] options. Read the documentation for the details and their caveats. They provide valuable help in migration, especially for an operating system that do not have BerkeleyDB support anymore - which is NOT the case for Gentoo. However, these options still help in complex configuration cases. Option 3: Turning off lmdb USE flag is not recommended but is possible. The default stays the same as previous versions of postfix, namely hash for local files and btree for caches. No further action is necessary until BerkeleyDB support is sunsetted in Gentoo when you will have to do the above migration. For more details, please read: https://www.postfix.org/NON_BERKELEYDB_README.html [1] https://www.postfix.org/NON_BERKELEYDB_README.html#enable-redirect [2] https://www.postfix.org/NON_BERKELEYDB_README.html#enable-reindex

sssd to run as a dedicated user

Wed, 11 Feb 2026 00:00:00 +0100

sssd now runs as its own user, rather than root, and uses file capabiltites for its helpers. Although it had this functionalilty for a while, it wasn't completely usable until 2.10. sssd-2.12.0 will be the first keyworded version in Gentoo with this change, made available shortly. Because of the user change, the sssd database, logs, and configuration files must have their ownership changed. == Systemd users == After upgrading sssd to >=2.10, stop the sssd service. Then execute the following commands: chown -R sssd:sssd /var/lib/sss chown -R sssd:sssd /var/log/sssd Then restart the sssd service and verify it launched succesfully. == openrc users === After upgrading sssd, stop the sssd service. Then execute the following commands: chown -R sssd:sssd /var/lib/sss chown -R sssd:sssd /var/log/sssd chown -R root:sssd /etc/sssd Then restart the sssd service and verify it launched succesfully.

Desktop Profile to enable PipeWire support

Thu, 15 Jan 2026 00:00:00 +0100

Reasons ======= Gentoo has had a longstanding complaint that desktop profiles do not enable a suitable working audio setting, which causes confusion for new users. An example of when this is a user can end up compiling Firefox without audio support, meaning the user will have to add the USE flags and then compile Firefox a second time. This not only wastes time for the user, but also increases support workload by the volunteers that provides it. This change will make PipeWire the default sound server for all Gentoo desktop profiles which support it, rather than just KDE Plasma profiles as was the previous norm[1]. PipeWire has been widely adopted by Linux as a whole due to its feature to work with older standards such as PulseAudio, and means Gentoo will be less likely to need users to make any follow-up changes to their system, related to audio. Changes ======= New global USE flags enabled: pulseaudio -> Enables PulseAudio support for packages as a fallback when native PipeWire isn't available. New global USE flags enabled: pipewire New package.use default: media-video/pipewire[sound-server] -> These settings will enable PipeWire by default where available and also tell PipeWire to act as our PulseAudio server where there is no native PipeWire support. New global USE flags enabled: screencast -> In Wayland sessions, the video functionality of PipeWire is not only used for screen sharing but also to take screenshots and recordings or simply to cast window content onto task managers' window previews. As this is basically a free and beneficial addition as it provides things like screenshotting and webcam access under Wayland. Alpha and HPPA =============== Alpha and HPPA currently do not have PipeWire support enabled so only PulseAudio is enabled. These can be requested by users at a later date after confirming they work with the respected projects. Users not wishing to change =========================== For users not wanting to change from the their current desktop profile setup, then all that is required is to set USE="-pipewire -pulseaudio -screencast" in their make.conf file. User Action Required ==================== In order to enact all changes: emerge -avDU @world Follow the post-installation messages printed by emerge to start the needed daemons. If using systemd, to configure the PipeWire daemon(s), run the following commands: $ systemctl --user --now disable pulseaudio.service pulseaudio.socket $ systemctl --user --now disable pipewire-media-session.service $ systemctl --user --now enable pipewire.socket pipewire-pulse.socket $ systemctl --user --force enable wireplumber.service OpenRC users don't need to take any action if using a desktop environment that supports XDG autostart. Afterwards all that should be required is a reboot, however in the unlikely event of issues then check out how to configure PipeWire for your purposes. [1][2]. In order to keep a previously configured PulseAudio only system (i.e. keep using media-sound/pulseaudio-daemon), set USE="-pipewire -screencast" in /etc/portage/make.conf and media-video/pipewire -sound-server in /etc/portage/package.use For an ALSA only system, set USE="-pipewire -pulseaudio -screencast" in /etc/portage/make.conf [1] https://www.gentoo.org/support/news-items/2022-07-29-pipewire-sound-server.html [2] https://wiki.gentoo.org/wiki/PipeWire

net-mail/dovecot-2.4.2 stabilization

Thu, 08 Jan 2026 00:00:00 +0100

net-mail/dovecot-2.4.2 will be stabilized soon[1] and will be the first dovecot-2.4 release that will be stable in Gentoo. Dovecot-2.3 configuration settings will not work with Dovecot-2.4 and manual intervention is required for the upgrade. Please read https://doc.dovecot.org/2.4.2/installation/upgrade/overview.html before upgrading your dovecot instance. We strongly recommend finalizing your Dovecot 2.4 configuration on a test system before upgrading any production systems. The following steps typically make the upgrade process easier: 1. Make a note of your current configuration by running doveconf -nP 2. Stop the dovecot daemon 3. Move ALL your configuration files to a temporary location 4. Upgrade to dovecot-2.4.2 5. Read the new configuration files and uncomment as necessary 6. Compare the new doveconf -n output with the old one and add missing configuration settings one by one while checking that the system works after each change [1]: https://bugs.gentoo.org/967978

FlexiBLAS migration imminent

Sun, 30 Nov 2025 00:00:00 +0100

Gentoo is adopting FlexiBLAS (sci-libs/flexiblas) [0][1] as the primary way of switching BLAS implementations at runtime. The previous eselect-based 'eselect-blas', 'eselect-cblas', and 'eselect-lapack' approach will be phased out in favor of this because of various reliability problems we hit. The defaults in profiles will change shortly for stable users. For ~arch users, the default was changed a little while ago. Action required --------------- Please check your configuration for any stale references to eselect-ldso: $ grep -rsin eselect-ldso /etc/portage and drop any reference to to it in make.conf USE or package.use. Please also deselect the relevant packages from world: $ emerge --deselect app-eselect/eselect-blas app-eselect/eselect-cblas $ emerge --deselect app-eselect/eselect-lapack Then complete a world upgrade and depclean: $ emerge -a -uvDU @world $ emerge -ac Using flexiblas --------------- Most users do not need to worry about this and the defaults will be fine. For users that want to, FlexiBLAS allows both system-wide and per-user configuration and supersedes the functionality from the old setup. Please refer to the flexiblas(1) man page for details. [0] https://public-inbox.gentoo.org/gentoo-dev/db65740b619e7b2413ac2b4b06f94db960f3e46e.camel@gentoo.org/ [1] https://bugs.gentoo.org/963034

Portage to verify git-synced ::gentoo per default

Sat, 01 Nov 2025 00:00:00 +0100

Portage now implicitly enables OpenPGP verification of the "raw" ::gentoo repository when synchronizing using git [1]. That is, >= Portage 3.0.70 will set sync-git-verify-commit-signature = true for the "raw" ::gentoo repository as default. Note that if you have the 'rsync-verify' flag (misleading name) disabled for sys-apps/portage, you will need to enable it, as it pulls in app-portage/gemato which is used for verification for git repositories too. It is enabled by default. This behavior change otherwise only requires action from users who are synchronizing the "raw" ::gentoo git repository, as otherwise synchronization may fail due to verification errors. Users - synchronizing the "sync friendly" ::gentoo git repository, - using rsync as synchronization mechanism - or, using emerge-webrsync are *not* required to take any action. Remotes of the "sync friendly" ::gentoo git repository include: - https://github.com/gentoo-mirror/gentoo - https://anongit.gentoo.org/git/repo/sync/gentoo.git - https://gitweb.gentoo.org/repo/sync/gentoo.git We recommend using those instead of the "raw" repo because the "raw" repo does not include news items, GLSAs, or generated metadata. No action is required when using one of these remotes listed above. For those other sync types/repos, verification is already handled and they are unaffected by this change. This news item is NOT instructing users to start using the raw repo, it is just a necessary change if you are already using it. Please do not start using the "raw" repo as a result of this news item. Stop reading if you aren't using it already! However, advanced users who already use the "raw" ::gentoo remote repository need to adjust the repository configuration to verify against the "gentoo developers" keyfile. Ensure that sec-keys/openpgp-keys-gentoo-developers is installed, as it provides this keyfile. Furthermore, the key refresh method should be set to 'keyserver' because WKD is not supported with the "gentoo developers" keyfile. Remotes of this category include: - https://github.com/gentoo/gentoo - https://gitweb.gentoo.org/repo/gentoo.git/ An typical adjusted configuration may look like the following: [gentoo] location = /var/db/repos/gentoo sync-type = git # This is the raw git repository and it lacks news, GLSAs, and metadata. # We don't recommend using it unless you're an advanced user! # # If using this repository instead of the 'sync' repositories, please make # sure to generate news and friends yourself. sync-uri = https://github.com/gentoo/gentoo.git sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-developers.asc # If you experience hangs or refresh failures, try 'no' instead. sync-openpgp-key-refresh = keyserver 1: https://bugs.gentoo.org/959831

OpenZFS packages merged

Tue, 14 Oct 2025 00:00:00 +0200

To simplify maintenance and system administration, sys-fs/zfs-kmod has been merged into sys-fs/zfs starting from version 2.4.0_rc2-r1. If you are using in-kernel modules from a custom built kernel you should unset the modules USE flag for sys-fs/zfs to not build and install kernel modules via sys-fs/zfs. If you were using sys-fs/zfs-kmod and sys-fs/zfs before, you have not to do anything special while upgrading as the package manager will take care of deinstalling sys-fs/zfs-kmod before upgrading to the new sys-fs/zfs version containing the modules. If you experience a blocker, you may have to remove sys-fs/zfs-kmod from your world file by running emerge --deselect sys-fs/zfs-kmod

Cache-enabled sync mirrors only for official repos

Tue, 07 Oct 2025 00:00:00 +0200

Summary: Removal of all third-party mirrors from https://github.com/gentoo-mirror. Only ::gentoo, ::guru, ::kde, and ::science will remain. Reasoning: Due to increasing maintenance costs and complexities, Gentoo is going to stop providing the cache-enabled git syncing mirrors found in the gentoo-mirror GitHub organization [1], and CI services for third-party repositories. We will continue providing mirrors for a curated set of official repositories, including ::gentoo, ::guru, ::kde, and ::science. The remaining mirrors will be removed on 2025-10-30. This change does not affect users who have not used eselect-repository or users who have not used the gentoo-mirror repositories. It has no impact on syncing the Gentoo repository itself. It does not affect the availability of these repositories via >=app-eselect/eselect-repository-15 and repositories.xml -- the official upstream sync URI will be used instead. What you need to do: Users who have previously added repositories using =app-eselect/eselect-repository-15, in order to update their sync URIs. For example, the following can be used: eselect repository list -i # get list of repositories, and then... eselect repository remove ${repository} eselect repository enable ${repository} Outcome: Once the mirrors are discontinued, we are going to remove them entirely in order to trigger sync errors for the remaining users, and ensure that they are not stuck on non-updated mirrors. This may show up as a 'username/password' prompt as GitHub does this for deleted repositories: if that happens, please follow the above instructions if not done so already! [1] https://github.com/gentoo-mirror/

app-backup/tsm changes to scheduled backups

Wed, 24 Sep 2025 00:00:00 +0200

In version 8.1.27.0 some changes were made to the way the init service scripts for systemd and openrc are distributed by app-backup/tsm. As a result some user intervention may be required. What changed? ==================== Gentoo now uses the init service scripts distributed by IBM as part of the DSM client rpm packages. Previously we used custom versions, which came with a number of drawbacks. Notably, in some configurations certain files could be skipped by the backup client during a scheduled backup operation [1]. To avoid such issues in the future it was decided to avoid straying too far from how upstream intends for this software to be used. A side effect of this is that the "dsmc" service script was removed, and only the (upstream) "dsmcad" service script remains. This affects both systemd and openrc. The DSM Client Acceptor Daemon (dsmcad) is a more lightweight and modern alternative to continuously running a "dsmc sched" process. It can be configured to manage scheduled backup operations as well as the webclient [4]. Note that the localisation option of the dsmcad service is configurable in /etc/tivoli/dsmcad.lang. Users may change this setting, but please note that IBM recommends using a single-byte character set (such as en_US) in order to ensure successful backups of all files regardless of the character set used in the filename [1]. Users who are certain that there systems do not mix filename character sets may wish to configure dsmcad to match this character set to ensure that log files and restore operations display the filenames correctly. User Action Required (systemd) ==================== Users who are using the DSM backup client with systemd and 'dsmc.service' to perform scheduled backups, should migrate to the more modern "dsmcad.service". # Verify the status of dsmc systemctl status dsmc If it is enabled, then first configure dsmcad to run the scheduler in your /etc/tivoli/dsm.sys file [4]. For example: # nano /etc/tivoli/dsm.sys Servername ManagedServices SCHEDULE # Then, disable dsmc and enable dsmcad systemctl disable --now dsmc systemctl enable --now dsmcad Note that a side-effect of this change is that the output of the scheduled backup is no longer written into the systemd journal. Instead the output of the acceptor daemon, as well as the scheduled backup operations that it runs, can be found in /var/log/tsm/. Thus additional adjustments to monitoring scripts may be required. User Action Required (OpenRC) ==================== Users who are using the DSM backup client on OpenRC systems and are currently using '/etc/init.d/dsmc' to perform scheduled backups should migrate to the more modern '/etc/init.d/dsmcad'. # Verify the status of dsmc rc-update show If it is enabled, then first configure dsmcad to run the scheduler in your /etc/tivoli/dsm.sys file [4]. For example: # nano /etc/tivoli/dsm.sys Servername ManagedServices SCHEDULE # Then, disable dsmc and enable dsmcad rc-update stop dsmc default rc-update del dsmc default rc-update start dsmcad default rc-update add dsmcad default Questions or issues? ==================== As usual, please report any issues you find in the 8.1.27.0 version on bugs.gentoo.org. And feel free to contact the author of this news item on IRC (Nowa) should you have any further questions. Further information ==================== For further information, please read the following documentation pages: [1] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=solaris-set-language-environment-variables [2] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=spso-setting-client-scheduler-process-run-as-background-task-start-automatically-startup [3] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=problems-starting-stopping-client-service [4] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=reference-managedservices [5] https://www.ibm.com/docs/en/storage-protect/8.1.27?topic=cs-comparison-between-client-acceptor-managed-services-traditional-scheduler-services

encfs is unmaintained

Tue, 16 Sep 2025 00:00:00 +0200

sys-fs/encfs is effectively unmaintained upstream. Old archives are already hard to read without it crashing [1], and no new bugfixes are expected. Chances are data will become unreadable sooner than later. Upstream recommends migrating to newer alternatives, like app-crypt/gocryptfs [2]. Since migrating large quantities of data can take time, please consider migrating everything while it's still possible. Note: app-crypt/gocryptfs is better than encfs when used with local storage, but it may be extremly slow over sshfs or CIFS [3]. A faster alternative in such a case would be gocryptfs over rclone mount, or using rclone crypt directly. [1] https://github.com/vgough/encfs/issues/651 [2] https://github.com/vgough/encfs/?tab=readme-ov-file#status [3] https://github.com/rfjakob/gocryptfs/issues/764

sys-apps/openrc user services introduction

Thu, 04 Sep 2025 00:00:00 +0200

OpenRC 0.62 (*) introduces user services as a new feature. The functionality is documented on the wiki [0] and has a similar interface to conventional system-wide services. Support for user services is enabled by default via the pam_openrc module in sys-auth/pambase, but it can be disabled via an OpenRC configuration option as described below. Some ebuilds already provide OpenRC user service init scripts, like app-editors/emacs. More will follow, but use of user services is optional. Requirements ============ User services currently require the XDG_RUNTIME_DIR environment variable to be set, which may be done via sys-auth/elogind, sys-apps/systemd, or manually via e.g. pam_env. In the future, pam_xdg may be packaged [1] as another option. If the XDG_RUNTIME_DIR environment variable isn't set and user services have not been disabled, the setup will fail gracefully but will appear in syslog and rc-update. Opting-out of user services =========================== If users wish to disable OpenRC user services, they can set rc_autostart_user="NO" in /etc/rc.conf: ... # Set to "NO" if you don't want pam_openrc autostarting user services. This # effectively disables the pam module, without the need of removing it from # the pam configuration files. rc_autostart_user="NO" ... ~/.profile and friends ====================== After stabilization, some users reported hangs when logging in [2]. None were reported during the extensive period of testing in ~arch or by other distributions who deployed newer versions of OpenRC. User services require that ~/.profile, ~/.bash_profile run safely under a non-interactive shell. Commands in these shell startup files may be executed by a non-interactive shell so commands that require a TTY, reading from stdin, and so on should be guarded with a check for TTY like: if [ -t 0 ] ; then # Interactive commands here ... fi Please make sure to check your shell startup files for suspicious constructs like the following: ... if [ -x /usr/bin/keychain ] ; then # BAD keychain ... fi ... ... replacing them with: ... if [ -t 0 ] && [ -x /usr/bin/keychain ] ; then # GOOD keychain ... fi ... (*) User services were originally in sys-apps/openrc-navi and later as part of >= OpenRC 0.62. The functionality was declared stable with 0.62.6 which was the first version with User Services stabled in Gentoo. [0] https://wiki.gentoo.org/wiki/OpenRC#User_services [1] https://bugs.gentoo.org/908431 [2] https://bugs.gentoo.org/962214

Stable hppa keywords removed

Mon, 01 Sep 2025 00:00:00 +0200

The Gentoo/HPPA team has decided that the time invested in package stabilization is no longer justified by the small number of users on the Hewlett Packard Precision Architecture (hppa). In addition, Gentoo currently lacks a working stable development machine. As a result, all "hppa" keywords will be changed to "~hppa" on 2025-09-01, with the "~hppa" keyword added to ACCEPT_KEYWORDS in the profile. Users need not make any changes to their systems, and the Gentoo/HPPA team does not currently plan to remove support for the architecture.

Stable sparc keywords removed

Mon, 01 Sep 2025 00:00:00 +0200

The Gentoo/SPARC team has decided that the time invested in package stabilization is no longer justified by the small number of users on the SPARC architecture. In addition, Gentoo currently lacks a working stable development machine. As a result, all "sparc" keywords will be changed to "~sparc" on 2025-09-01, with the "~sparc" keyword added to ACCEPT_KEYWORDS in the profile. Users need not make any changes to their systems, and the Gentoo/SPARC team does not currently plan to remove support for the architecture.

Breaking changes in nginx packaging in Gentoo

Sat, 05 Jul 2025 00:00:00 +0200

NGINX is a web server and a reverse proxy. Following a year-long effort, its packaging in Gentoo has undergone a major revamp[1]. Starting from the mainline version 1.29.0 the changes will come into force. On 2025-09-05, the stable version will also have the changes described below in the "What changed?" section. This enables more thorough testing before user-facing changes are applied to the stable NGINX version. If you are reading this NEWS item, the information below is relevant for you. What changed? ==================== There are a few user-facing changes with the updated packaging. 1. Third-party modules. Third-party modules, which were previously part of the NGINX package, www-servers/nginx, are now separate packages in the www-nginx/ category. The Lua, Brotli, headers-more and upload-progress are examples of the modules that are now separate packages. Some of the modules have been removed completely. The following is a list of modules that have been removed. If you rely on any of the modules outlined below, please file a bug on Gentoo Bugzilla[2][3] asking the module to be added. The recommended summary for a bug is "www-servers/nginx: please add module MODULE_NAME", where MODULE_NAME is the name of the module you would like to see added. Removed modules: - ngx_cache_purge/http_cache_purge_module - nginx_ngx_slowfs_cache/http_slowfs_cache_module - ngx_http_auth_pam_module/http_authpam_module - nginx_upstream_check_module/http_upstream_check_module - ngx_metrics/http_metrics_module - naxsi/http_naxsi_module - nginx-rtmp-module/rtmp_module - nginx-push-stream-module/http_push_stream_module - nginx-sticky-module-ng/http_sticky_module - nginx-mogilefs-module/http_mogilefs_module - nginx-auth-ldap/http_auth_ldap_module 2. USE flags. Some USE flags, like "http-cache", "ktls", "pcre", "pcre-jit" and so on, have been removed. They did not have any effect or served no purpose, thus you need not worry about them. The "http2", "http3" use flags have been renamed to nginx_modules_http_v2 and nginx_modules_http_v3 respectively. They correspond to NGINX_MODULES_HTTP "v2" and "v3" USE_EXPAND flags accordingly. "ssl" use flag has been changed into individual "ssl" USE_EXPAND flags for the mail, stream and HTTP servers. Thread pool support[4], previously toggled by the "threads" USE flag, is now enabled unconditionally. Vim syntax files are now provided by the main www-servers/nginx package, instead of app-vim/nginx-syntax. 3. Default log files. Default log filenames are now error.log and access.log, instead of error_log and access_log. User Action Required ==================== To upgrade to the new NGINX version, use the following command. emerge --deselect app-vim/nginx-syntax emerge --oneshot --update --deep www-servers/nginx If you use any third-party modules, install the new separate package. For instance, if you previously enabled the nginx_modules_http_lua USE flag on www-servers/nginx, here is how you install the new Lua module package. emerge www-nginx/ngx-lua-module To list all the available module packages, use emerge --search @www-nginx | less or qlist --installed --tree www-nginx/ If you use the "http2" or "http3" USE flags, enable the corresponding USE_EXPAND flags. To enable http2 only: echo 'www-servers/nginx NGINX_MODULES_HTTP: v2' >> \ /etc/portage/package.use/nginx.use To enable http3: echo 'www-servers/nginx NGINX_MODULES_HTTP: v3' >> \ /etc/portage/package.use/nginx.use To enable both http2 and http3: echo 'www-servers/nginx NGINX_MODULES_HTTP: v2 v3' >> \ /etc/portage/package.use/nginx.use SSL/TLS modules are enabled by default. If you wish to disable them, use the following command. echo www-servers/nginx NGINX_MODULES_HTTP: -ssl \ NGINX_MODULES_STREAM: -ssl \ NGINX_MODULES_MAIL: -ssl >> \ /etc/portage/package.use/nginx.use The updated NGINX comes with a new logrotate file that points to the new log filenames. If any of your scripts rely on the old log files, change them accordingly as needed. [1]: https://github.com/gentoo/gentoo/pull/37590 [2]: https://bugs.gentoo.org/ [3]: https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide [4]: https://nginx.org/en/docs/ngx_core_module.html#thread_pool

nftables systemd service change

Sat, 24 May 2025 00:00:00 +0200

net-firewall/nftables-1.1.1-r1 made some changes to the provided systemd units. Prior to this version, nftables-restore.service was responsible for both loading rules on system startup and for saving them on system shutdown. The service has now been split in two: nftables-load.service is responsible for loading rules at startup. Users who relied on nftables-restore.service to load firewall rules must now enable nftables-load.service instead. nftables-store.service may be used to save the current ruleset by starting it at any time. It may also be enabled to store the ruleset at shutdown. Use of this service is not mandatory if the user chooses to maintain the saved ruleset manually.

net-mail/dovecot-2.4.x may break on upgrade

Fri, 23 May 2025 00:00:00 +0200

Dovecot-2.4 introduced breaking change to its entire configuration system and Dovecot-2.3 configuration files will NOT work after upgrade. Please read https://doc.dovecot.org/2.4.1/installation/upgrade/2.3-to-2.4.html before upgrading. We strongly recommend finalizing your Dovecot 2.4 configuration on a test system before upgrading any production systems. The following steps typically make the upgrade process easier: 1. Make a note of your current configuration by running doveconf -nP 2. Stop the dovecot daemon 3. Move ALL your configuration files to a temporary location 4. Upgrade to dovecot-2.4.x 5. Read the new configuration files and uncomment as necessary 6. Compare the new doveconf -n output with the old one and add missing configuration settings one by one while checking that the system works after each change

Gentoo raises s390x baseline to z10

Mon, 14 Apr 2025 00:00:00 +0200

Since more and more software for s390x assumes the presence of a more recent processor, we will raise the ISA baseline in 64bit s390x profiles for the catalyst stage builds and the published binary packages from z900 to z10 (i.e., -march=z10). * If you are running an installation and emerge locally from source, this does not affect you. * If you are running an installation and use our binary packages, please make sure you have compatibility for z10 or switch to building from source. * The 64bit s390x stages will only work with machines compatible with z10. * This does not affect the 31bit s390 stages or packages. The z10 Enterprise Class (2097 series) was introduced in February 2008 [1], which essentially means everyone except hardware archaeologists should be fine. Note that z10 is still a very conservative setting; on modern machines a newer ISA is strongly recommended. [1] https://en.wikipedia.org/wiki/IBM_Z

SELinux default POLICY_TYPES update

Wed, 26 Mar 2025 00:00:00 +0100

In line with our wiki recommendations, the default SELINUXTYPE set in /etc/selinux/config is now the mcs policy type. Hence, POLICY_TYPES has been updated to build all policy types by default if none are selected in make.conf. If a user does not explicitly have an override set for POLICY_TYPES, a full rebuild of selinux policy packages will be required: emerge --ask --oneshot @selinux-rebuild

Python 3.13 to become the default on 2025-05-01

Mon, 24 Mar 2025 00:00:00 +0100

We are planning to switch the default Python target of Gentoo systems on 2025-05-01, from Python 3.12 to Python 3.13. If you have not changed the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will have immediate effect on your system and the package manager will try to switch automatically on the next upgrade following the change. If you did change the values, prefer a safer approach or have problems with the update, read on. Please note that the default upgrade method switches packages to the new Python versions as they are rebuilt. This means that all interdependent packages have to support the new version for the upgrade to proceed, and that some programs may temporarily fail to find their dependencies throughout the upgrade (although programs that are already started are unlikely to be affected). If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared in make.conf, please remove these declarations as they will interfere with the package.use samples provided below. Using make.conf for Python targets is discouraged as it prevents package defaults from applying when necessary. This news item assumes using /etc/portage/package.use or your package manager's equivalent file for configuration. At this point, you have a few configuration options to choose from: 1. If you wish Python upgrades to apply automatically, you can remove PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When the defaults change, your package manager should handle the upgrade automatically. However, you may still need to run the update commands if any problems arise. 2. If you wish to defer the upgrade for the time being, you can explicitly set the old values in package.use. 3. If you wish to force the upgrade earlier, you can explicitly set the new values and run the upgrade commands. 4. If you wish to use a safer approach (i.e. less likely to temporarily break packages during the upgrade), you can perform a multi-step upgrade as outlined below. 5. Finally, you can use an arbitrary combination of PYTHON_TARGETS and PYTHON_SINGLE_TARGET. Deferring the upgrade ===================== To defer the upgrade, explicitly set the old targets: */* PYTHON_TARGETS: -* python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 This will enforce Python 3.12 and block any future updates. However, please note that this is only a temporary solution and you will eventually need to perform the migration. Forcing the upgrade =================== To force the upgrade earlier, explicitly select the Python 3.13 targets: */* PYTHON_TARGETS: -* python3_13 */* PYTHON_SINGLE_TARGET: -* python3_13 However, it is important to remember to remove this after the defaults change, as it will interfere with the automatic switch to the next Python version in the future. Safer upgrade procedure ======================= A safer approach is to add Python 3.13 support to your system first, and only then remove Python 3.12. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer. First, enable both Python 3.12 and Python 3.13, and then run the upgrade commands: */* PYTHON_TARGETS: -* python3_12 python3_13 */* PYTHON_SINGLE_TARGET: -* python3_12 Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: */* PYTHON_TARGETS: -* python3_12 python3_13 */* PYTHON_SINGLE_TARGET: -* python3_13 Finally, switch to the final version and upgrade: */* PYTHON_TARGETS: -* python3_13 */* PYTHON_SINGLE_TARGET: -* python3_13 You may wish to remove the target overrides after the defaults switch. Alternatively, you can keep them to block the next automatic upgrade to Python 3.14, and upgrade manually then. Upgrade commands ================ The Python 3.12 cleanup requires that Python 3.12 is removed from the complete dependency trees in batch. If some of the installed packages using an older Python version are not triaged for the upgrade, the package manager will throw dependency conflicts. This makes it important that the upgrade is carried via a --deep --changed-use @world upgrade, as well as that any stray packages are removed prior to it, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean Other Python implementations ============================ At the same time, we are also going to remove the target support for Python 3.10 (python3_10) and PyPy 3.10 (pypy3). If you were using the pypy3 target before, now you will need to explicitly enable per-version targets, such as: */* PYTHON_TARGETS: pypy3_11 Note that PyPy support is available only for systems accepting ~arch keywords.

Certbot rework and transition

Fri, 14 Mar 2025 00:00:00 +0100

Certbot and its modules have been reworked into a single package; this should ease maintenance and make delivery faster and more reliable. Starting from app-crypt/certbot-3.2.0-r100, only this package is necessary to install Certbot and its modules thanks to the help of USE flags. Some block statements are enforced for modules packages to avoid collisions. However actions from users are required: @world set and package.use changes. Temporary transition metapackages call for the appropriate USE flags, but users still have to change their package.use and later they must update their @world set to complete the transition before 2025-06-10 (around three months from publication), after which these temporary transition packages will be removed. As a reminder, there is a Wiki page for Certbot: https://wiki.gentoo.org/wiki/Let%27s_Encrypt Step by step: 1. In /etc/portage/package.use: Add an entry for the modules of your choice based on the USE flags of the new unified package. Example: app-crypt/certbot certbot-apache certbot-dns-rfc2136 If you wish to stick with stable you may stop here. The below steps (skipping step 2) will be completed later once the unified package stabilizes. Should you wish to complete the transition now: 2. In /etc/portage/package.accept_keywords: (skip this step and continue with step 3 if completing after the unified package stabilizes): Add a keyword entry for the new unified package. Example: ~app-crypt/certbot-3.2.0 ~amd64 3. Clean the old module packages out of your @world or other sets: emerge --ask --deselect app-crypt/acme app-crypt/certbot-apache \ app-crypt/certbot-dns-cloudflare app-crypt/certbot-dns-desec \ app-crypt/certbot-dns-dnsimple app-crypt/certbot-dns-nsone \ app-crypt/certbot-dns-rfc2136 app-crypt/certbot-nginx 4. Emerge or update app-crypt/certbot if necessary. This should remove previous packages: emerge --verbose --ask --changed-use --noreplace app-crypt/certbot

Dracut changed default for hostonly setting

Mon, 03 Feb 2025 00:00:00 +0100

Dracut is an initramfs generation tool. It may be invoked via the installkernel mechanism in order to automatically generate a new initramfs when the kernel is installed. If you are reading this then sys-kernel/installkernel is configured to use Dracut and the below is relevant for you. What changed? ==================== Starting with version 106 of sys-kernel/dracut the default for the "hostonly" setting has changed from disabled to enabled when Dracut is invoked via installkernel[1]. "hostonly" is a setting for Dracut that controls how much is included in the generated initramfs image. When it is disabled Dracut aims to generate an initramfs image that is bootable on any hardware. On the other hand, when this setting is enabled, Dracut aims to generate an initramfs image containing only what is needed to boot the current system. The advantage is a significantly smaller initramfs images, but this comes with the cost of losing portability. Example: When the "hostonly" setting is disabled, Dracut's drm module will cause all GPU drivers to be included in the initramfs. When it is enabled, only the drivers for GPUs that are currently present in the system are included in the initramfs. Enabling the "hostonly" setting was and is our recommendation for most use cases. This however was not the default behaviour in versions prior to 106. Note, the default value for the "hostonly" setting has changed only when Dracut is invoked via installkernel. Disabled remains the default behaviour when Dracut is invoked directly. User Action Required ==================== If your system is already configured to enable "hostonly" setting via /etc/dracut.conf.d/ then effectively nothing has changed for you. However, if Dracut has previously not been configured to enable the "hostonly" setting, then starting with version 106 the behaviour of Dracut will change for you. Though we do not expect major problems, we recommend ensuring a backup booting option remains available before rebooting the system after the first kernel upgrade following the upgrade of Dracut. This is usually the case unless the old kernels are manually removed by the user. If you do experience a booting problem with the "hostonly" enabled initramfs images, then please report this problem to Dracut[2]. The "hostonly" setting may be disabled via /etc/dracut.conf.d/ configuration snippets. For example: echo "hostonly=no" >> /etc/dracut.conf.d/95-no-hostonly.conf [1] https://github.com/dracut-ng/dracut-ng/pull/1158 [2] https://github.com/dracut-ng/dracut-ng/issues

Haskell destabilization

Sun, 29 Sep 2024 00:00:00 +0200

Packaging Haskell software has proven difficult in Gentoo: many packages are outdated, unstable versions have not been stabilized in nearly a year, and stable versions are rather old. In an effort to reduce the load on the Haskell maintainers, stable keywords will be removed from dev-haskell/* packages and their reverse dependencies on October 1. Users with Haskell packages should add entries to their package.accept_keywords for these packages to avoid issues rebuilding or upgrading them in the future. This change does not preclude stabilizing Haskell packages in the future. Haskell packaging is mostly taking place in the Haskell repository [1]. [1] https://github.com/gentoo-haskell/gentoo-haskell

KDE Plasma 6.1.4 and Gear 24.05.2 Upgrade

Sat, 31 Aug 2024 00:00:00 +0200

Reasons ======= KDE Plasma 5 has reached end of life and is no longer supported by Gentoo. Qt5 upstream OSS support ended on 2020-12-08, and LTS releases - even with considerable effort by KDE community's backports on top - only go so far. It is therefore required for all users to upgrade to KDE Plasma 6[1]. At the same time, KDE Gear 24.05.2 is provided with most applications ported over to KDE Frameworks 6. As long as KF5-based applications are being shipped with the KDE Gear bundle, and other non-KDE Qt5-based applications still common in ::gentoo repository, it is advised *not* to disable USE="qt5". Changes ======= Not many - much like Qt6, this is mostly an evolution of the existing codebase, no disruptive feat. Plasma Wayland support has come a long way and therefore KDE developers have decided to make it the default login session for Plasma 6, even if some known papercuts[2] remain. For users affected too much by those, switching to the still existing X11 session is as easy as selecting it in the display manager of choice. Disabling USE="wayland" is *not* changing this default, it will yield no dependency savings, and we advise against doing so. It does not affect users' X11 sessions. In Gentoo: The 32-bit ~arm/arm keyword was inconsistent across KDE Plasma, KDE Frameworks, and KDE Gear, and has been dropped. The situation for x86 was similar to arm and test failures often blocked stabilization. Stable x86 has been dropped, ~x86 was dropped for KDE PIM, dev-util/kdevelop and any other dev-qt/qtwebengine:6 reverse dependencies. User Action Required ==================== For users of a desktop profile[3], no specific upgrade steps are necessary, although some precautionary measures are advised before and during upgrade: - Switch to a standard (Breeze or Oxygen) theme - Depclean kde-misc/latte-dock, it is unfit for Plasma 6 (and masked already) - Cleanup sets and @world from any SLOT or version pinning of KDE packages - If possible, perform the upgrade not inside a running Plasma session Necessary USE flag changes were already made in desktop profile, therefore only users of other profiles should set USE="kf6compat qt6" globally[4]. Users are recommended to run the following command (pretend-only) to identify packages in @world which have been removed, to help reduce conflicts: emerge -pev @world --backtrack=0 Then for any "no ebuild available" messages, either resolve it by making the needed changes, or emerge --deselect them. Then proceed to the world upgrade below. Once the packages become available on your arch, it should be as simple as update @world: emerge -avuUD @world Run dispatch-conf (preferred) or etc-update to get updated configuration files: dispatch-conf Then depclean: emerge -ac [1] https://kde.org/plasma-desktop/ [2] https://community.kde.org/Plasma/Wayland_Known_Significant_Issues [3] https://wiki.gentoo.org/wiki/KDE#Profile [4] https://wiki.gentoo.org/wiki//etc/portage/package.use

dracut module config changes

Fri, 09 Aug 2024 00:00:00 +0200

Starting with dracut-102, cryptsetup support for systemd has been moved into a separate module "systemd-cryptsetup". Under specific conditions, this change may cause a failure to boot. [1] Users who are not using cryptsetup at all will not be affected. Users who use the "dracutmodules" config option to explicitly name all modules to be included may be affected if they fail to update their dracut configuration to include the new "systemd-cryptsetup" module. Users who have not altered the default config or who are not using the "dracutmodules" option should not be affected. The dracut.conf(5) manual page warns against using "dracutmodules". Instead, "add_dracutmodules" and "omit_dracutmodules" can be used to to alter the default module list with less risk of omiting modules by accident. [1] https://bugs.gentoo.org/937326

Gentoo drops IA-64 support

Wed, 07 Aug 2024 00:00:00 +0200

Following the removal of IA-64 support in the Linux kernel and glibc, and subsequent discussions on our mailing list [1], as well as a vote by the Gentoo Council [2,3], Gentoo will discontinue all ia64 profiles and keywords. The primary reason for this decision is the inability of the Gentoo IA-64 team to support this architecture without kernel support, glibc support, and a functional development box. In one month, all ia64 profiles will be removed, all ia64 keywords will be dropped from all packages, and all IA-64 related Gentoo bugs will be closed. [1] https://public-inbox.gentoo.org/gentoo-dev/75654daa-c5fc-45c8-a104-fae43b9ca490@gentoo.org/T/ [2] https://projects.gentoo.org/council/meeting-logs/20240721.txt [3] https://projects.gentoo.org/council/meeting-logs/20240721-summary.txt

Upgrading to TeX Live 2023

Wed, 05 Jun 2024 00:00:00 +0200

Upgrading to TeX Live 2023 ========================== We will soon start the stabilization of TeX Live 2023 in Gentoo. Since TeX Live 2023 underwent a major overhaul, including TeX Live package moves between the according Gentoo packages, there are file conflicts between Gentoo's TeX Live 2021 and 2023 packages. To avoid those conflicts, it is recommended to uninstall all of dev-texlive prior updating TeX Live to version 2023. Before uninstalling dev-texlive packages, first check if your system has a pending texlive update (1). If this is the case, uninstall the old dev-texlive packages (2) and emerge the update (3). 1. emerge -p '>=app-text/texlive-2023' [only proceed if texlive update is available] 2. emerge --unmerge --deselect=n 'dev-texlive/*' 3. emerge '>=app-text/texlive-2023' The steps above are equivalent to the following bash snippet: if emerge -p '>=app-text/texlive-2023'; then emerge --unmerge --deselect=n 'dev-texlive/*' emerge '>=app-text/texlive-2023' fi

Changes to dracut kernel module/microcode handling

Fri, 17 May 2024 00:00:00 +0200

Impact ==================== Several changes were made regarding out-of-tree kernel modules, CPU microcode, and how these are handled in initial RAM file systems (initramfs) generated by sys-kernel/dracut for distribution kernels. Depending on the local Dracut and USE flag configuration, some configuration adjustments may be required as a result of these changes. Background (the problem) ==================== Previously Dracut implicitly included all out-of-tree kernel modules it could find. This leads to several problems: - It unnecessarily increases the size of the initramfs - It creates a bit of a mess when using distribution kernels, consider the following: 1) Distribution kernel is upgraded 2) Initramfs for the new kernel is generated, it does not include any out-of-tree kernel modules. 3) Portage triggers rebuild of the out-of-tree kernel modules 4) If zfs is installed, its rebuild will trigger an initramfs re-installation. Otherwise no rebuild is triggered. Problem: What is and is not included in the initramfs is now ambiguous. It depends on the emerge order of the kernel modules when zfs is used. And will completely change if at some later stage regeneration of the initramfs is triggered manually via e.g.: emerge --config sys-kernel/gentoo-kernel As a result, Dracut's "--reproducible" setting is not working. And the functionality of the initramfs may change (seemingly) at random. Background (the fix) ==================== Several things have been changed: - Out-of-tree kernel modules installed by portage are explicitly omitted from the initramfs generated by Dracut by default. - Packages that install a kernel module for which it might make sense to have it in the initramfs, have gained the "initramfs" USE flag. When this flag is enabled, Dracut is instructed to include the installed kernel modules. Packages for which it is essential that its kernel modules are included in the initramfs have this new flag enabled by default. - When distribution kernels are used (USE=dist-kernel), and a module that should be in the initramfs is installed (USE=initramfs) the initramfs is always re-generated. - The packages installing CPU microcode (sys-kernel/linux-firmware and sys-firmware/intel-microcode) have been adjusted to mirror the above changes for out-of-tree kernel modules. Both packages have gained the "dist-kernel" USE flag, and the "initramfs" flag is now enabled by default. When both flags are enabled, Dracut is configured to include the installed microcode in the initramfs, and then the initramfs is regenerated. When the "dist-kernel" flag is disabled, the "initramfs" flag behaves as it previously did. User Action Required (Dracut and/or Distribution Kernel users) ==================== Users of sys-kernel/dracut and/or Distribution Kernels should double check two things: 1) Please ensure that you are *not* globally enabling or disabling the "initramfs" USE flag. Enabling it globally might result in an unnecessarily large initramfs. Disabling it globally might result in missing functionality in the initramfs. Which could lead to boot failure if, for example, the zfs module is missing while the root partition is a zfs. 2) Any add_drivers, or omit_drivers lines in /etc/dracut.conf or /etc/dracut.conf.d/* may override the Dracut configuration snippets installed by the kernel module packages in /usr/lib/dracut/dracut.conf.d. Please review your Dracut configuration files to ensure that you are not unintentionally overriding the settings set by Portage. User Action Required (other users) ==================== Other users may wish to disable the "initramfs" USE flag on sys-kernel/linux-firmware and/or sys-firmware/intel-microcode if they already have other mechanisms in place for updating the CPU microcode (such as kernel built-in CPU microcode). Users who do not use sys-kernel/dracut or Distribution Kernels can safely disable the "initramfs" USE flag globally. Frequently Asked Questions ==================== A package installing a kernel module I would like in my initramfs has not gained the "initramfs" USE flag. How do I proceed? Please report a new bug on bugs.gentoo.org, requesting that the package maintainer consider adding support to the package for including the modules in the initramfs. In the meantime you can locally override the configuration provided by the package (see below). Note though that when distribution kernels are used, regeneration of the initramfs must be triggered manually via e.g.: emerge --config sys-kernel/gentoo-kernel How do I override the provided Dracut configuration snippets to include/exclude a custom list of modules? To override the provided configuration snippet, create a new file /etc/dracut.conf.d/10-PACKAGENAME.conf, replacing PACKAGENAME with the name of the package providing the module. Add to this file: omit_drivers+=" my list of drivers to omit " and/or add_drivers+=" my list of drivers to include "

Python 3.12 to become the default on 2024-06-01

Thu, 09 May 2024 00:00:00 +0200

We are planning to switch the default Python target of Gentoo systems on 2024-06-01, from Python 3.11 to Python 3.12. If you have not changed the values of PYTHON_TARGETS or PYTHON_SINGLE_TARGET, the change will have immediate effect on your system and the package manager will try to switch automatically on the next upgrade following the change. If you did change the values, prefer a safer approach or have problems with the update, read on. Please note that the default upgrade method switches packages to the new Python versions as they are rebuilt. This means that all interdependent packages have to support the new version for the upgrade to proceed, and that some programs may temporarily fail to find their dependencies throughout the upgrade (although programs that are already started are unlikely to be affected). If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared in make.conf, please remove these declarations as they will interfere with the package.use samples provided below. Using make.conf for Python targets is discouraged as it prevents package defaults from applying when necessary. This news item assumes using /etc/portage/package.use or your package manager's equivalent file for configuration. At this point, you have a few configuration options to choose from: 1. If you wish Python upgrades to apply automatically, you can remove PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When the defaults change, your package manager should handle the upgrade automatically. However, you may still need to run the update commands if any problems arise. 2. If you wish to defer the upgrade for the time being, you can explicitly set the old values in package.use. 3. If you wish to force the upgrade earlier, you can explicitly set the new values and run the upgrade commands. 4. If you wish to use a safer approach (i.e. less likely to temporarily break packages during the upgrade), you can perform a multi-step upgrade as outlined below. 5. Finally, you can use an arbitrary combination of PYTHON_TARGETS and PYTHON_SINGLE_TARGET. Deferring the upgrade ===================== To defer the upgrade, explicitly set the old targets: */* PYTHON_TARGETS: -* python3_11 */* PYTHON_SINGLE_TARGET: -* python3_11 This will enforce Python 3.11 and block any future updates. However, please note that this is only a temporary solution and you will eventually need to perform the migration. Forcing the upgrade =================== To force the upgrade earlier, explicitly select the Python 3.12 targets: */* PYTHON_TARGETS: -* python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 However, it is important to remember to remove this after the defaults change, as it will interfere with the automatic switch to the next Python version in the future. Safer upgrade procedure ======================= A safer approach is to add Python 3.12 support to your system first, and only then remove Python 3.11. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer. First, enable both Python 3.11 and Python 3.12, and then run the upgrade commands: */* PYTHON_TARGETS: -* python3_11 python3_12 */* PYTHON_SINGLE_TARGET: -* python3_11 Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: */* PYTHON_TARGETS: -* python3_11 python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 Finally, switch to the final version and upgrade: */* PYTHON_TARGETS: -* python3_12 */* PYTHON_SINGLE_TARGET: -* python3_12 You may wish to remove the target overrides after the defaults switch. Alternatively, you can keep them to block the next automatic upgrade to Python 3.13, and upgrade manually then. Upgrade commands ================ The Python 3.11 cleanup requires that Python 3.11 is removed from the complete dependency trees in batch. If some of the installed packages using an older Python version are not triaged for the upgrade, the package manager will throw dependency conflicts. This makes it important that the upgrade is carried via a --deep --changed-use @world upgrade, as well as that any stray packages are removed prior to it, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean