Gentoo news

GLEP 42 news items from the ::gentoo tree — the same ones eselect news read shows. Newest 30 items.

• 2026-06-28 32-bit s390 support dropped Andreas K. Hüttel <[email protected]>

  The legacy 32bit ABI support for IBM S390 mainframes is on the way out just
  about everywhere:
  * Pure 32bit hardware is by now nonexistent (64bit support exists since 2002).
  * Full 32bit kernel support is gone since 2014.
  * The 32bit ABI userspace emulation layer has been dropped in the kernel since
    version 6.19.
  * glibc will drop 32bit ABI support in version 2.44.
  * gcc will drop 32bit ABI support in version 17.
  As a consequence, Gentoo will also drop support for it, effective immediately.
  There will be no stage builds anymore. The 32bit profiles will be marked
  deprecated and experimental, no longer receive any testing, and be removed
  in the next profile version. Corresponding bug reports may get ignored or
  closed immediately. If you are still using this configuration, we urge you to
  find an alternative.
  
  This does *not* affect the 64bit code ("s390x", CHOST=s390x-ibm-linux-gnu)
  with its profiles and stages.

• 2026-05-23 KDE PIM 26.04.1 default backend changes to sqlite Andreas Sturmlechner <[email protected]>

  KDE PIM's centralised Akonadi subsystem uses a database for cached data.
  Three different database backends have been supported for a long time.
  When multiple USE flags are enabled, kde-apps/akonadi-config ebuild picks
  the one with the highest priority (see the table under Changes below)
  as default DB backend in akonadiserverrc.
  
  This means that prior to KDE PIM 26.04.1 (with kde-apps/akonadi-config-0),
  mysql, when enabled, took precedence for new KDE PIM setups.
  
  
  Changes
  =======
  
  With kde-apps/akonadi-config-1 we are making sqlite the highest priority
  instead. Existing Akonadi instance settings, which are kept in home
  directories, will not be changed automatically.
  
  ---------!--------------------------------!-----------!-----------
   Backend ! kde-apps/akonadi-config[<use>] ! <=26.04.0 ! >=26.04.1
  ---------!--------------------------------!-----------!-----------
           !                                !  (priority, 1 = best)
   QSQLITE ! sqlite                         !     2     !     1
   QMYSQL  ! mysql                          !     1     !     2
   QPSQL   ! postgres                       !     3     !     3
  
  
  Reasons
  =======
  
  Running a daemon brings its own set of problems and switching to the
  QSQLITE backends lets us avoid those. Also, SQLite is unavoidable on
  most systems, while MariaDB, MySQL, or PostgreSQL may often be installed
  purely for Akonadi, so it saves a large package being installed.
  
  Historically[1], the QSQLITE backend was fundamentally broken for KMail's
  workload, which is why QMYSQL was picked as default early on. Over the years
  this has come with its own share of (mostly DB upgrade handling) bugs, but
  QSQLITE has only in recent years become viable again through upstream's
  efforts, which we have been tracking[2]. Recently, the default was finally
  changed upstream[3].
  
  
  User Action Required
  ====================
  
  In order to implement any backend change on your users' akonadi DB config,
  a manual migration step is necessary - in this example, from mysql to sqlite.
  It is necessary to have support for both database drivers enabled in
  dev-qt/qtbase for this to succeed.
  
      1) Find out which backend is currently in use:
  
          grep "^Driver" ~/.config/akonadi/akonadiserverrc
  
      2) A quick check that both DB drivers are supported by Qt:
  
          USE="mysql sqlite" emerge -p1 dev-qt/qtbase
  
          If this command indicates a USE flag change, you must at least
          temporarily rebuild dev-qt/qtbase with both old and new enabled.
  
      3) Migration:
  
          akonadi-db-migrator --newengine sqlite
  
      The last command will not just migrate the database but also adapt
      akonadiserverrc accordingly.
  
  ---
  
  In order to keep using QMYSQL backend for users' existing Akonadi instances,
  ensure that USE=mysql is permanently[4] enabled for kde-apps/akonadi-config
  [and dev-qt/qtbase respectively].
  
  ---
  
  In order to keep QMYSQL backend as default choice for new Akonadi instances,
  make sure that USE=sqlite is disabled for kde-apps/akonadi-config.
  
  
  [1] https://bugs.gentoo.org/441596
  [2] https://bugs.gentoo.org/936102
  [3] https://invent.kde.org/pim/akonadi/-/merge_requests/311
  [4] https://wiki.gentoo.org/wiki//etc/portage/package.use

• 2026-05-08 Dracut changed default for hostonly_cmdline setting Nowa Ammerlaan <[email protected]>

  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:
    <snip>
    Command line:
    quiet
    splash
    root=PARTUUID=7ae430c6-07e8-3b4e-a796-b2a28706b3fb
    <snip>
    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:
    <snip>
    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:
    <snip>
    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:
    <snip>
    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

• 2026-05-03 Portage binpkg changes Sam James <[email protected]>

  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".
  
  To sign already-created binpkgs, Portage's `gpkg-sign` tool can be used.
  
  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

• 2026-04-26 SELinux Policy EAPI 8 Migration Rahul Sandhu <[email protected]>

  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.

• 2026-04-16 Python 3.14 to become the default on 2026-06-01 Michał Górny <[email protected]>

  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.

• 2026-03-31 Varnish Renamed Brett A C Sheffield <[email protected]>

  # 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

• 2026-03-15 mail-mta/postfix-3.11.0: Default database change Eray Aslan <[email protected]>

  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

• 2026-03-15 www-client/chromium slotted installation Matt Jolly <[email protected]>

  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

• 2026-01-15 Desktop Profile to enable PipeWire support Ian Jordan <[email protected]>

  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

• 2025-11-30 FlexiBLAS migration imminent Sam James <[email protected]>

  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/[email protected]/
  [1] https://bugs.gentoo.org/963034

• 2025-11-01 Portage to verify git-synced ::gentoo per default Florian Schmaus <[email protected]>

  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

• 2025-09-24 app-backup/tsm changes to scheduled backups Nowa Ammerlaan <[email protected]>

  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 <MY-SERVER>
  	<snip>
  	ManagedServices  SCHEDULE
  	<snip>
  
  # 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 <MY-SERVER>
  	<snip>
  	ManagedServices  SCHEDULE
  	<snip>
  
  # 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

• 2025-10-14 OpenZFS packages merged Marc Schiffbauer <[email protected]>

  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

• 2025-10-07 Cache-enabled sync mirrors only for official repos Michał Górny <[email protected]>

  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 will need to re-add these repositories
  with >=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/

• 2025-09-16 encfs is unmaintained Viorel Munteanu <[email protected]>

  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

• 2025-09-04 sys-apps/openrc user services introduction Sam James <[email protected]>

  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

• 2025-09-01 Stable sparc keywords removed Arthur Zamarin <[email protected]>

  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.

• 2025-09-01 Stable hppa keywords removed Arthur Zamarin <[email protected]>

  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.

• 2025-07-05 Breaking changes in nginx packaging in Gentoo Zurab Kvachadze <[email protected]>

  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

• 2025-05-24 nftables systemd service change Mike Gilbert <[email protected]>

  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.

• 2025-04-14 Gentoo raises s390x baseline to z10 Andreas K. Hüttel <[email protected]>

  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

• 2025-03-26 SELinux default POLICY_TYPES update Rahul Sandhu <[email protected]>

  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

• 2025-03-24 Python 3.13 to become the default on 2025-05-01 Michał Górny <[email protected]>

  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.

• 2025-03-14 Certbot rework and transition Thibaud CANALE <[email protected]>

  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

• 2025-02-03 Dracut changed default for hostonly setting Nowa Ammerlaan <[email protected]>

  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

• 2024-09-29 Haskell destabilization Matt Turner <[email protected]>

  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

• 2024-08-31 KDE Plasma 6.1.4 and Gear 24.05.2 Upgrade Andreas Sturmlechner <[email protected]>

  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

• 2024-08-09 dracut module config changes Mike Gilbert <[email protected]>

  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

• 2024-08-07 Gentoo drops IA-64 support Arthur Zamarin <[email protected]>

  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/[email protected]/T/
  [2] https://projects.gentoo.org/council/meeting-logs/20240721.txt
  [3] https://projects.gentoo.org/council/meeting-logs/20240721-summary.txt