Gentoo Portage Overlays - Gentoo Repository News

Dracut changed default for hostonly_cmdline setting

Fri, 08 May 2026 00:00:00 +0200

Dracut is an initramfs generation tool. It may be invoked via the installkernel mechanism or manually after building custom kernels. What changed? ============= In version 111 of sys-kernel/dracut the default for the hostonly_cmdline setting changed from enabled to disabled. When enabled, this setting causes Dracut to attempt to detect which parameters are required on the kernel command line to boot the system. Examples are the root= parameter or parameters controlling partition decryption. These parameters are then included in the generated initramfs and appended to the kernel command line during boot. Why has this setting been changed? ================================== When enabled, Dracut's hostonly_cmdline setting may use the kernel command line of the running kernel (/proc/cmdline) to construct the kernel command line that will be embedded in the initramfs. This can cause problems when Dracut is being executed from a live or rescue environment. In such cases an incorrect root= could be included in the embedded kernel command line which could lead to boot failure. To prevent this behaviour from causing such unpleasant surprises, a check was added to sys-kernel/installkernel to detect whether the kernel was being installed from chroot and if Dracut was configured to include an embedded kernel command line (hostonly_cmdline=yes). While this check prevents boot failures, it also has the unfortunate side effect of creating a hard error that is triggered by default on new Gentoo installs. This has proven to be a significant stumbling block that new users often trip over. For this reason it was decided to disable the hostonly_cmdline setting in Gentoo's default settings for Dracut. User Action Required (all users) ================================ With >=sys-kernel/dracut-111, users need to perform a sanity check described in this news item. This sanity check will ensure that kernel parameters required to boot successfully are still present in the kernel command line. When in doubt, ensure system rescue media is close at hand. More specific instructions for various setups follow below, ordered from the specific to the more general as listed here: * Systemd GPT Auto Generator * Generic Unified Kernel Image * Unified Kernel Image with Secure Boot * GRUB * systemd-boot * rEFInd * other/general For each option a summarised list of relevant files that should be double checked is provided first. In general the 'lsinitrd' tool provided by sys-kernel/dracut can be used to obtain the current embedded kernel command line, these kernel parameters will be absent after (re)generating an initramfs with version 111 of dracut. As always, do not hesitate to use our support channels to ask for clarification or assistance. > User Action Required (Systemd GPT Auto Generator) ================================================= Files to double check: - /dev/gpt-auto-root (symlink must be valid) - If absent then the auto generator is not being used. Systems that utilise the systemd GPT Auto Generator mechanism to automatically detect and find the root partition at boot should not require any manual intervention. Though, before rebooting, users should verify that the auto generator is actually being used and is working properly. To do so, check that /dev/gpt-auto-root currently exists and points to your root partition. For example: $ ls -l /dev/gpt-auto-root Should produce an output similar to the below if /dev/nvme0n1p1 is the root partition: """Output: lrwxrwxrwx 1 root root 4 May 2 10:33 /dev/gpt-auto-root -> nvme0n1p1 """ If this is not the case then proceed with the instructions below that best match the setup to ensure that the root partition is set on the kernel command line using an alternative method. > User Action Required (Generic Unified Kernel Image: "generic-uki") ================================================================== Files to double check: - none Users booting with the generic Unified Kernel Image (USE=generic-uki) functionality provided by the distribution kernels (dist-kernel) do not have to take any action as the hostonly_cmdline is already disabled in these builds: - sys-kernel/vanilla-kernel[generic-uki] - sys-kernel/gentoo-kernel[generic-uki] - sys-kernel/gentoo-kernel-bin[generic-uki] > User Action Required (Unified Kernel Image with Secure Boot) ============================================================ Files to double check: - /etc/kernel/cmdline and/or /etc/kernel/uki.conf (ukify) - /etc/dracut.conf and/or /etc/dracut.conf.d/*.conf (dracut) Booting a Unified Kernel Image (UKI) with Secure Boot enabled is a special case because in this situation the kernel command line supplied by the bootloader or the firmware is ignored and the built-in UKI command line, along with the parameters embedded in the initramfs, take precedence. The instructions below are also relevant if no kernel command line is set by the bootloader or the firmware. Verify whether Secure Boot is enabled with dmesg, for example: $ dmesg | grep -i secure """Output: [ 0.012418] Secure boot enabled """ An easy way to check the built-in kernel command line of an UKI is to use the lsinitrd tool provided by sys-kernel/dracut. For example: $ lsinitrd /efi/EFI/Linux/gentoo-x.y.z-gentoo-dist.efi This command will produce an output that could contain for example: """Output: Command line: quiet splash root=PARTUUID=7ae430c6-07e8-3b4e-a796-b2a28706b3fb dracut cmdline: ro """ Showing that the built-in kernel command line for this UKI contains "quiet", "splash" and sets the root partition to the partition that has the partition UUID "7ae430c6-07e8-3b4e-a796-b2a28706b3fb". Additionally, the kernel command line embedded in the initramfs contains "ro". If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in the "Command line" section then user intervention is required. In that case please adjust the configuration of the UKI generator to include the appropriate kernel parameters in the built-in UKI command line. If Ukify (sys-apps/systemd[ukify] or sys-apps/systemd-utils[ukify]) is generating the UKI then adjust the "Cmdline=" setting in /etc/kernel/uki.conf. If that setting is not present in the uki.conf then adjust the kernel command line in /etc/kernel/cmdline. If Dracut itself is generating the UKI then please set or adjust the "kernel_cmdline=" setting in a dracut configuration file in /etc/dracut.conf.d/. If unsure which tool is generating the UKI then please inspect the current value of "uki_generator" in /usr/lib/kernel/install.conf and /etc/kernel/cmdline. > User Action Required (GRUB) =========================== Files to double check: - /etc/default/grub Users booting with GRUB should compare the GRUB_CMDLINE_LINUX setting in /etc/default/grub against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI). The lsinitrd utility provided by sys-kernel/dracut can be used for this purpose. For example, in the case of a plain initramfs: $ lsinitrd /boot/initramfs-x.y.z-gentoo-dist.img Or, in the case of an Unified Kernel Image: $ lsinitrd /boot/vmlinuz-x.y.z-gentoo-dist.efi The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example: """Output: dracut cmdline: ro """ If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in /etc/default/grub then user intervention is required. In that case please adjust the GRUB_CMDLINE_LINUX setting in /etc/default/grub to include the missing kernel parameters. After adjustments don't forget to update the grub.cfg. For example: $ grub-mkconfig -o /boot/grub/grub.cfg Note that when Secure Boot is enabled the grub.cfg might reside in a different directory, for example: /efi/EFI/Gentoo/grub.cfg. > User Action Required (systemd-boot) =================================== Files to double check: - /etc/kernel/cmdline Users booting with systemd-boot should compare the contents of /etc/kernel/cmdline against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI). If Unified Kernel Images are used and the /etc/kernel/cmdline file is empty or missing then no kernel command line is set by systemd-boot, in this case please refer to the "Unified Kernel Image with Secure Boot" section above, even if Secure Boot is not enabled. The lsinitrd utility provided by sys-kernel/dracut can be used to inspect the kernel parameters embedded in an initramfs or UKI. For example, in the case of a plain initramfs: $ lsinitrd /efi/gentoo/x.y.z-gentoo-dist/initrd Or, in the case of an Unified Kernel Image: $ lsinitrd /efi/EFI/Linux/gentoo-x.y.z-gentoo-dist.efi The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example: """Output: dracut cmdline: ro """ If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in /etc/kernel/cmdline then user intervention is required. In that case please adjust /etc/kernel/cmdline to include the missing kernel parameters. > User Action Required (rEFInd) ============================= Files to double check: - refind_linux.conf Users booting with rEFInd should compare kernel command line set in the refind_linux.conf file against the kernel command line embedded in the initramfs or Unified Kernel Image (UKI). The refind_linux.conf configuration file usually resides in /boot but may also be found elsewhere. If Unified Kernel Images are used and the refind_linux.conf configuration file is empty or missing then no kernel command line is set by rEFInd, in this case please refer to the "Unified Kernel Image with Secure Boot" section above, even if Secure Boot is not enabled. The lsinitrd utility provided by sys-kernel/dracut can be used to inspect the kernel parameters embedded in an initramfs or UKI. For example, in the case of a plain initramfs: $ lsinitrd /boot/initramfs-x.y.z-gentoo-dist.img Or, in the case of an Unified Kernel Image: $ lsinitrd /boot/vmlinuz-x.y.z-gentoo-dist.efi The final lines of the output of these commands show which kernel parameters are embedded in the Dracut initramfs. For example: """Output: dracut cmdline: ro """ If kernel parameters that are essential for successfully booting the system (such as root=) are present in the "dracut cmdline" section but not in the refind_linux.conf then user intervention is required. In that case please adjust refind_linux.conf to include the missing kernel parameters. > User Action Required (other/general) ==================================== For other setups please refer to the wiki page or manual of your bootloader and find where the kernel command line is set. Then compare this setting with the kernel parameters embedded in the initramfs. If essential parameters are present in the later but not in the former, then please move those parameters to your bootloader's configuration. When Unified Kernel Images are used then also consider the built-in UKI command line set by the UKI generator. Note that when Secure Boot is disabled, the bootloader may override the built-in UKI command line. However, when Secure Boot is enabled then any parameters set by the bootloader are ignored and the built-in UKI command line is always used. See Also ======== [1] https://github.com/dracut-ng/dracut-ng/pull/2399 [2] https://bugs.gentoo.org/971572

Portage binpkg changes

Sun, 03 May 2026 00:00:00 +0200

Newer versions of Portage are making two changes to how binary packages work: 1) binary package signatures are now verified by default [0]; 2) fetched binary packages are stored separately from locally-built binaries (this change is already in a recent Portage release) [1]. Remote binary packages are now cached in /var/cache/binhost/NAME where NAME is given by the configuration item in /etc/portage/binrepos.conf. This allows clean separation of locally built binary packages vs. those with remote provenance, and to allow verification of fetched packages without forcing signing to be set up for local binpkgs. The cache location can be customised by setting `location` in binrepos.conf. gentoolkit has been updated to handle these cache locations too. This news item only applies if you use or produce binary packages. Official binhost users ====================== Fetched binary packages are now stored at /var/cache/binhost/gentoo (or a similar path, depending on contents of /etc/portage/binrepos.conf/*). No action is required, for two reasons: 1) all of the documentation included FEATURES="binpkg-request-signature", and 2) attempts to install a binpkg that is signed without any configuration would fail early. The only impact is that future binary package installs will need less setup. Setting FEATURES="binpkg-request-signature" is no longer needed for this case. Users may need to run `eclean-pkg` to cleanup old binary packages in the old, mixed location. Users of just the official binary host can stop reading at this point. Custom binhosts =============== Users who host their own binary packages and redistribute them to their machines will need to either: 1) start signing their binpkgs [2], or 2) set `verify-signature = false` in /etc/portage/binrepos.conf/* for the relevant configuration file for your binhost. Otherwise, fetched binpkgs will fail verification. To set up signing for binpkgs, a signing keyring must reside (by default) at /root/.gnupg and a verification keyring must reside (by default) at /etc/portage/gnupg. The verification keyring must mark the signing key as trusted. Signing is toggled by FEATURES="binpkg-signing". You can opt-in to this change early by setting `verify-signature = true` in /etc/portage/binrepos.conf/* for each binary repository configured, or under the special '[DEFAULT]' section. Users may need to run `eclean-pkg` to cleanup old binary packages in the old, mixed location. This does not apply if your binhost uses the old XPAK binary package format, but we encourage switching to BINPKG_FORMAT="gpkg" if that is the case. [0] https://bugs.gentoo.org/945384 [1] https://bugs.gentoo.org/945385 [2] https://wiki.gentoo.org/wiki/Binary_package_guide#Binary_package_OpenPGP_signing

SELinux Policy EAPI 8 Migration

Sun, 26 Apr 2026 00:00:00 +0200

What Changed ============ The SELinux policy packages have all been bumped to EAPI 8. POLICY_TYPES, which used to be an environment variable, is now a USE expand named SELINUX_POLICY_TYPES. The use of USE_EXPAND fixes some longstanding bugs and allows users to switch policy types more easily. Whilst the POLICY_TYPES environment variable is considered deprecated going forward, it is still necessary to keep it set (and in sync with SELINUX_POLICY_TYPES) until you are certain that all installed policy packages on your system have been updated. Please read on for further instructions. For Users ========= Set SELINUX_POLICY_TYPES in your package.use to match what POLICY_TYPES is currently set to. To get the current value of POLICY_TYPES: $ portageq envvar POLICY_TYPES And to set SELINUX_POLICY_TYPES: # echo 'SELINUX_POLICY_TYPES="mcs"' >>/etc/portage/make.conf OR # echo "sec-policy/* SELINUX_POLICY_TYPES: mcs" >>/etc/portage/package.use/selinux-policy Then, update the system to install the updated policy packages: # emerge --verbose --ask --update --deep --newuse @world DO NOT unset POLICY_TYPES until you are certain that all of the policy packages installed have been updated to use EAPI 8 (or above). You can use this command to find all outdated installed policy packages that have not been updated yet: $ qgrep -eNJ 'EAPI="\?7"\?' 'sec-policy/*' If the above command returns an empty list, then it is safe to remove the POLICY_TYPES variable. For Overlay Maintainers ======================= In your SELinux policy packages, bump the EAPI variable to EAPI=8. If your packages have any form of dependency on another policy package, it is neccessary to constrain their USE flags with the new eclass variable SELINUX_POLICY_USEDEP. See selinux-policy-2.eclass(5) for more details.

Python 3.14 to become the default on 2026-06-01

Thu, 16 Apr 2026 00:00:00 +0200

We are planning to switch the default Python target of Gentoo systems on 2026-06-01, from Python 3.13 to Python 3.14. 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. Most users do not need to do anything and it is best to wait until the switch date, as packages are still being ported. If you did change the values, prefer to have more control over when the switch occurs, 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_13 */* PYTHON_SINGLE_TARGET: -* python3_13 This will enforce Python 3.13 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.14 targets: */* PYTHON_TARGETS: -* python3_14 */* PYTHON_SINGLE_TARGET: -* python3_14 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.14 support to your system first, and only then remove Python 3.13. However, note that this involves two rebuilds of all the affected packages, so it will take noticeably longer. First, enable both Python 3.13 and Python 3.14, and then run the upgrade commands: */* PYTHON_TARGETS: -* python3_13 python3_14 */* PYTHON_SINGLE_TARGET: -* python3_13 Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades: */* PYTHON_TARGETS: -* python3_13 python3_14 */* PYTHON_SINGLE_TARGET: -* python3_14 Finally, switch to the final version and upgrade: */* PYTHON_TARGETS: -* python3_14 */* PYTHON_SINGLE_TARGET: -* python3_14 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.15, and upgrade manually then. Upgrade commands ================ The Python 3.13 cleanup requires that Python 3.13 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.11 (python3_11) and PyPy 3.11 (pypy3_11). Since there are no plans to release a Python 3.12-compatible PyPy version yet, Gentoo will be removing PyPy support for the time being.

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][3]. 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 [3] https://vinyl-cache.org/organization/on_vinyl_cache_and_varnish_cache.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