Search Portage & Overlays:

Gentoo Repository News

Plasma Profile to enable PipeWire, Wayland support - 21/05/2023 00:00 GMT


Gentoo's Plasma profile has not had any sound server enabled since the days of 
KDE's own aRts. As the way we output sound has changed dramatically in the years
since - using wireless or often several devices, dynamically connected and 
shared between multiple systems, a modern desktop environment is expected to 
handle this effortlessly by default.

In Wayland sessions, the video functionality of PipeWire is not only used for 
screensharing but also to take screenshots and -recordings or simply to cast 
window content onto task managers' window previews. This is why PipeWire and 
Wayland enablement are happening at the same time.

Plasma Wayland support has come a long way and we consider it stable enough for 
daily use with a lot - if not all - systems, even if some known papercuts 
remain [1]. Therefore it makes sense for Plasma profile to provide sane default 


New global USE flags enabled: pipewire, pulseaudio, screencast, wayland
New package.use default: media-video/pipewire[sound-server]

We want broad sound server support in packages, and these settings will make
PipeWire act as our PulseAudio server where there is no native PipeWire support.

Impact On Happy X Users

Minor. Most dependencies were already required with kde-plasma/plasma-desktop 
and its dependencies. Upcoming stable versions of kde-apps/spectacle and 
kde-apps/krfb will depend on (K)PipeWire unconditionally.

No one will lose their X session, but will have the option to easily log in to 
a working Wayland session at any time.

It is possible to set USE="-wayland" against these changes, but it will amount 
to no dependency savings, just micro-optimisation in affected packages.

User Action Required

In order to enact all changes:

    emerge -1avUD @world
    Check out how to configure PipeWire for your purpose [2][3]

In order to keep a PulseAudio or ALSA-only setup:

    Invert above new USE flag settings as needed, see also [2].

In order to avoid media-video/pipewire completely:

    This can only be achieved by losing basic task manager, screenshot/screen
    recording/sharing functions as provided by Plasma and KDE applications.


Posted By: Andreas Sturmlechner

OpenSSH directory configuration changes - 11/05/2023 00:00 GMT

Gentoo's OpenSSH package will start using the /etc/ssh/sshd_config.d
and /etc/ssh/ssh_config.d directories for both Gentoo default settings
and use by the administrator.

The default /etc/ssh/sshd_config and /etc/ssh/ssh_config files will
respectively include configuration files in /etc/ssh/sshd_config.d/* and
/etc/ssh/ssh_config.d/*, making it possible for all customization and
configuration to be done via 'drop-in' files if desired.

Most users will not need to take any action. The only action required
is if specific Gentoo defaults were overridden in the past, as the new
ebuilds will install them to new files in the new listed directories.

Such admins will need to edit the new files in the new directories or
make overrides in their own files in the new directories using a smaller
number in the filename.

For example, if the system administrator has commented out 'AcceptEnv COLORTERM'
in /etc/ssh/sshd_config, they will need to do the same in the new
/etc/ssh/sshd_config.d/9999999gentoo.conf file.

Posted By: Sam James

Python 3.11 to become the default on 2023-05-01 - 02/04/2023 00:00 GMT

We are planning to switch the default Python target of Gentoo systems
on 2023-05-01, from Python 3.10 to Python 3.11.  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).

At the same time, the support for Python 3.9 target will be removed
from the eclasses.  The interpreter package will remain supported
for as long as feasible though.  PyPy3.9 will remain supported until
PyPy3.10 comes out and becomes stable.

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
   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

Deferring the upgrade
To defer the upgrade, explicitly set the old targets:

    */* PYTHON_TARGETS: -* python3_10
    */* PYTHON_SINGLE_TARGET: -* python3_10

This will enforce Python 3.10 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.11 targets:

    */* PYTHON_TARGETS: -* python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_11

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.11 support to your system first,
and only then remove Python 3.10.  However, note that this involves two
rebuilds of all the affected packages, so it will take noticeably

First, enable both Python 3.10 and Python 3.11, and then run the upgrade

    */* PYTHON_TARGETS: -* python3_10 python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_10

Then switch PYTHON_SINGLE_TARGET and run the second batch of upgrades:

    */* PYTHON_TARGETS: -* python3_10 python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_11

Finally, switch to the final version and upgrade:

    */* PYTHON_TARGETS: -* python3_11
    */* PYTHON_SINGLE_TARGET: -* python3_11

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.12, and upgrade manually then.

Upgrade commands
The Python 3.10 cleanup requires that Python 3.10 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

Posted By: Michał Górny

Breaking changes to the RAP Prefix toolchain - 28/01/2023 00:00 GMT

We are changing the way the toolchain operates on RAP Prefix systems in order to
reduce the number of hacks we need to apply and make cross-compiling easier.

If you using a non-RAP "Prefix Guest" or "Prefix Stack" variant (e.g. macOS)
then this does not apply.

If you're not sure what kind of prefix you have, then check whether the
prefix-guest USE flag is enabled. If the following command returns nothing, then
you have a RAP prefix and this does apply.

  portageq envvar USE | grep prefix-guest

If you are using a libc other than glibc (e.g. musl) then this *does* apply, but
your libc will *not* break, so you should not carry out the following procedure.
The only other package known to be affected is dev-libs/libbsd, which you can
simply update. If you find another package affected by this, then please file a
bug report.

WARNING! It is important that you carry out the following procedure, otherwise
your toolchain will break when you next update your compiler or glibc.

  1. Run the following to create a temporary symlink:

     EPREFIX=$(portageq envvar EPREFIX)
     mkdir -p "$$"
     ln -sn "$" "$$"

  2. Update or rebuild all installed slots of sys-devel/gcc and sys-devel/clang
     (if any). Feel free to remove any you no longer need.

  3. Update or rebuild sys-libs/glibc.

  4. Update sys-devel/binutils to at least 2.40-r2. This package is slotted, so
     ensure at least this version is selected with binutils-config.

  5. Run the following to remove the symlink:

     EPREFIX=$(portageq envvar EPREFIX)
     rm "$$"

  6. If dev-libs/libbsd is installed, then update it to 0.11.7-r2 or later.

If you are reading this having updated glibc first and you are no longer able to
build anything, then don't panic. Simply execute the lines below and then carry
out the regular procedure above.

  EPREFIX=$(portageq envvar EPREFIX)
  portageq contents "$" $(portageq best_version "$" sys-libs/glibc) | xargs grep -lIF -d skip "GNU ld script" | xargs sed -i -r "s: /(usr|lib): $/\1:g"

Posted By: James Le Cuirot

Hardened profiles improvements - 01/01/2023 00:00 GMT

Gentoo's hardened profiles are adopting two new modern toolchain hardening
1. Level 3 fortification (-D_FORTIFY_SOURCE=3) [0]
2. libstdc++ assertions (-D_GLIBCXX_ASSERTIONS) [1]

These will both be enabled by default with USE=hardened on sys-devel/gcc
for >=sys-devel/gcc-12.2.1_p20221231.

To view the existing list of hardening changes applied by the profiles,
see the wiki [2].

Stable users may wish to add sys-devel/gcc-12.2.1_p20221231 into
/etc/portage/package.accept_keywords if they wish to take advantage
of these improvements early, before GCC 12 is marked stable.

## Migration

To fully take advantage of these new settings, GCC must first
be upgraded, and then all packages must be re-emerged:
1. # emerge --sync
2. # emerge --verbose --oneshot ">=sys-devel/gcc-12.2.1_p20221231"
3. # gcc-config latest
4. # emerge --verbose --emptytree @world

## Troubleshooting

In the event that some packages fail at runtime, please file a bug
with the full details. To temporarily workaround the problem,
it should be possible to recompile broken packages with the
following *FLAGS:


Posted By: Sam James

Introduction of app-alternatives ebuilds - 27/12/2022 00:00 GMT

Gentoo is introducing a new category of ebuilds called 'app-alternatives'
to handle cases where a symlink for a common binary may want to be switched
between different packages by a user.

Traditionally, eselect was used for this, and while eselect still has its
place, it's unsuitable for cases like /bin/awk and /bin/sh because it
prevents immutable system directories and (more importantly
from a package management perspective) relies on orphaned symlinks which
means no package owns /bin/awk, /bin/sh, etc. This is not reliable and
can lead to dead symlinks (or no symlink at all) in some edge cases [0].

Systems will be more robust and desired system configuration
can be achieved using the package manager rather than manual steps outside of it.

The initial list of packages which support alternatives is as follows:
- app-alternatives/awk
- app-alternatives/bzip2
- app-alternatives/bc
- app-alternatives/cpio
- app-alternatives/gzip
- app-alternatives/lex
- app-alternatives/sh
- app-alternatives/tar
- app-alternatives/yacc

The stabilization of these new ebuilds and packages depending
on them occurred on 2022-12-27 in bug 886017 [1].

## Pre-upgrade requirements

The default configuration on Gentoo systems is FEATURES="protect-owned"
which works similarly to FEATURES="collision-protect" but it allows
collisions between orphaned files. In this case, a one-off collision
occurs as the app-alternatives/ ebuilds begin to claim once-orphaned

A similar issue occurred during the libxcrypt migration where users
had upgrades interrupted by using the older, more aggressive

It is recommended that users alter their configuration to
remove references to 'collision-protect' in FEATURES and instead either
explicitly enable 'protect-owned' in FEATURES or rely on the default
(equivalent). It is also acceptable to simply disable collision-protect
temporarily for the purposes of this news item.

WARNING: Users with collision-protect enabled must disable FEATURES="collision-protect"
in /etc/portage/make.conf by removing it or setting FEATURES="-collision-protect"
if they have enabled it. collision-protect detects collisions between files including
orphaned files where no package owns the file.

## Migrating

When receiving this news item, please follow the step below as soon
as possible to ensure a smooth transition.

To migrate your system, a standard world upgrade will suffice after
deselecting eselect-awk and eselect-sh:
1. # emerge --deselect app-eselect/eselect-awk app-eselect/eselect-sh
2. # emerge --depclean app-eselect/eselect-awk app-eselect/eselect-sh
3. # emerge --sync
4. # emerge -a -uvDU @world (or other similar standard world upgrade command)
5. # emerge --ask --depclean

It's okay if nothing happens in Step 1 and Step 2 (no atoms to remove).

## Configuration

Users who are not interested in using different implementations for
various tools listed above can ignore this section.

No configuration should be required by default, but users may wish
to configure the new app-alternatives/ ebuilds to their tastes as they
used to do via e.g. eselect-sh and eselect-awk.

Going forward, /etc/portage/package.use will be used for this purpose.

Users should review the USE flags available for the various app-alternatives
ebuilds like app-alternatives/sh and adjust their configuration as desired.

For example, to have /bin/gzip be provided by app-arch/pigz for automatic
parallelization of 'gzip', one would have the following in /etc/portage/package.use:
# Make /bin/gzip be a symlink to pigz for a speedup in compression
app-alternatives/gzip -reference pigz

## Further reading

For more details, please see the technical documentation on the wiki [2].


Posted By: Sam James

/usr merge for systemd users - 01/12/2022 00:00 GMT

In the latter half of 2023, systemd will drop support for
split-usr/unmerged-usr systems [1]. All Gentoo systems running systemd
will need to be migrated to merged-usr.

Migrating to merged-usr will move all data from /bin, /sbin, and /lib
into the /usr/bin and /usr/lib directories. The directories in / are
replaced with symlinks.

To facilitate this, a new set of sub-profiles has been created, and a
script is available to perform the actual migration.

To migrate a system to merged-usr, follow this procedure:

1. Ensure your system backups are up to date. Please also update
   your system fully and depclean before proceeding.

2. Install sys-apps/merge-usr.

3. Run "merge-usr --dryrun" as root to check for conflicts. These will
   appear with the word ERROR at the start of the line.

4. Resolve any conflicts. This may involve deleting duplicate files. If
   in doubt, seek support in a Gentoo support channel.

5. Run the merge-usr script from a root shell. Avoid running it via sudo
   directly to avoid locking yourself out if an unexpected error occurs.

6. Switch to a merged-usr profile.
     eg. eselect profile set default/linux/amd64/17.1/systemd/merged-usr

7. Run emerge with the --newuse or --changed-use option to rebuild
   any packages that have a "split-usr" USE flag.
     eg. emerge -uDN @world

For new installs, new "mergedusr" stage3 tarballs are being produced for
commonly used profiles.


Posted By: Mike Gilbert

systemd-tmpfiles --clean enabled by default - 21/11/2022 00:00 GMT

Starting with sys-apps/systemd-utils-251.8-r1, a script is installed in
/etc/cron.daily to run "systemd-tmpfiles --clean" once per day. This
will remove stale temp files based on settings specified in tmpfiles.d.

This change is meant to mimic the behavior of
systemd-tmpfiles-clean.timer from systemd on systems running OpenRC.

If you wish to opt-out, simply comment out the command in

Posted By: Mike Gilbert

LVM2 default USE flag change - 19/11/2022 00:00 GMT

The Gentoo Base System team has recently switched from the disabling
"device-mapper-only" flag to the enabling "lvm" (bug #718910).

After considering most reverse dependencies of sys-fs/lvm2, the Base System Team
has decided that the majority of Gentoo users are unlikely to use the LVM2
components of sys-fs/lvm2, instead relying solely on it providing device-mapper

To this end, we will disable the default enabled flag "+lvm" on sys-fs/lvm2
on 2023-01-01. If you do not have USE=lvm somehow globally enabled, this means
you will lose LVM2 (but not device-mapper!) functionality, so enable it in your
config if your boot configuration depends on it or if you depend on any of the
lvm2-* daemons.

If you use LVM2 for any partitions, or if you use tools like 'lvchange', you
should enable USE=lvm.

Furthermore, we have considered other default enabled USE flags too, and have
come to the conclusion that USE=+thin makes even less sense than USE=+lvm.
Thin-provisioned LVM volumes are an important use case in certain VM hosting
scenarios, but unlikely to be relevant for the large majority of Gentoo users.

In summary:
- Enable USE="lvm" if you use lvm2 (but not needed for device-mapper) as described above.
  This includes using LVM for any partitions.
- Enable USE="lvm thin" if you use thin as described above.
- If you don't know what LVM2 is, you don't need to take any action.

Posted By: David Seifert

PipeWire sound server migration - 29/07/2022 00:00 GMT

PipeWire has gained a new USE flag "sound-server" for enabling/disabling its
sound server capabilities.

This change is needed to avoid PipeWire and PulseAudio conflicting over control
of audio devices. Before this change, OpenRC users were in some cases
accidentally migrated to PipeWire which was difficult to override without
manually editing launcher files.

For non-audio purposes, PipeWire is installed in many configurations as more
and more software depends on it for e.g. screensharing, sandboxing,
and window previews, so users will need to act based on their preferred
setup rather than simply avoiding installing PipeWire, as it is
increasingly required as a dependency.

Packages needing PulseAudio's APIs will be migrated from the now-meta package
media-sound/pulseaudio to depending on media-libs/libpulse. The runtime
PulseAudio server can be provided by either PipeWire (media-video/pipewire)
or the original PulseAudio (media-sound/pulseaudio-daemon).

The new sound-server USE flag for PipeWire allows easily controlling
this behavior.

There are several options available:

1. To use PipeWire for sound, users should enable USE=sound-server for PipeWire:

  Place the following entries in /etc/portage/package.use:
  media-video/pipewire sound-server
  media-sound/pulseaudio -daemon

  First, sync:
  # emerge --sync

  Deselect media-sound/pulseaudio-daemon:
  # emerge --deselect media-sound/pulseaudio-daemon

  Then perform a world upgrade with PipeWire on the command line to add
  it to the world file:
  # emerge --ask --update --changed-use --deep @world media-video/pipewire

  Then depclean:
  # emerge --ask --depclean

  OpenRC users on an XDG-compliant desktop which respects autostart files
  will not need to take any further action.

  OpenRC users using a minimal desktop which does not respect autostart
  files will need to run `gentoo-pipewire-launcher &` in e.g.

  Users who want to switch to PipeWire providing a PulseAudio daemon
  may need to `emerge --deselect` packages in their world file which
  hard-require media-sound/pulseaudio-daemon. There are only a handful
  of these. A non-exhaustive list:
  * media-sound/paprefs
  * media-sound/pasystray
  * media-sound/pulseaudio-modules-bt (shouldn't be needed anyway)
  * net-misc/pulseaudio-dlna

  If not using any of those packages anymore, please emerge --deselect
  them. If still using these, PipeWire as a PulseAudio is not an
  option at this time.

  (Note that media-libs/libpulse (which PipeWire will be using, don't emerge
  libpulse manually) provides 'pactl' which can be used as a replacement for
  e.g. media-sound/pulseaudio-ctl, so personal scripts can be adapted to this
  if desired.)

  systemd users will also need to run the following commands:
  $ systemctl --user --now disable pulseaudio.service pulseaudio.socket
  $ systemctl --user --now enable pipewire.socket pipewire-pulse.socket
  $ systemctl --user --now disable pipewire-media-session.service
  $ systemctl --user --force enable wireplumber.service
  Root user may replace --user with --global to change system default
  configuration for all of the above commands.

2. To use PulseAudio's daemon for sound, users should disable USE=sound-server
  for PipeWire, enable USE=daemon on media-sound/pulseaudio, and add
  media-sound/pulseaudio-daemon to their world file:

  Place the following entries in /etc/portage/package.use:
  media-video/pipewire -sound-server
  media-sound/pulseaudio daemon

  Add media-sound/pulseaudio-daemon to @world:
  # emerge --noreplace media-sound/pulseaudio-daemon

  Then perform a world upgrade:
  # emerge --ask --update --changed-use --deep @world

  Then depclean:
  # emerge --ask --depclean

  OpenRC users on an XDG-compliant desktop which respects autostart files
  will not need to take any further action.

  OpenRC users using a minimal desktop which does not respect autostart
  files should consider adding `gentoo-pipewire-launcher &` in e.g.
  `~/.xprofile` but it's not strictly required in terms of audio
  handling. It may be required in future for the non-audio usecases
  described above.

  systemd users will also need to run the following commands:
  $ systemctl --user --now enable pulseaudio.service pulseaudio.socket
  $ systemctl --user --now disable pipewire.socket pipewire-pulse.socket

  Alternatively, systemd users can run the following commands as root to change
  the default for all users:
  # systemctl --global enable pulseaudio.service pulseaudio.socket
  # systemctl --global --force disable pipewire.socket pipewire-pulse.socket

  (If taking this option, the services must be started manually as a one-off as
  a user.)

3. For users without sound on their system, those using JACK without
   PipeWire, or those using pure ALSA without PipeWire, the following steps
   are recommended:

   Place the following entries in /etc/portage/package.use:
   media-video/pipewire -sound-server
   media-sound/pulseaudio -daemon

   Then perform a world upgrade:
   # emerge --ask --update --changed-use --deep @world

   Then depclean:
   # emerge --ask --depclean

   OpenRC users on an XDG-compliant desktop which respects autostart files
   will not need to take any further action.

   OpenRC users using a minimal desktop which does not respect autostart
   files will need to run `gentoo-pipewire-launcher &` in e.g.

   systemd users will also likely want to run the following commands as a user, again
   for the purposes of non-audio PipeWire use:
   $ systemctl --user --now enable pipewire.socket
   $ systemctl --user --now --force enable wireplumber.service

   Alternatively, systemd users can run the following commands as root to change
   the default for all users,  again for the purposes of non-audio PipeWire use:
   # systemctl --global enable pipewire.socket
   # systemctl --global --force enable wireplumber.service

   (If taking this option, the services must be started manually as a one-off as
   a user.)

Further resources:

Posted By: Sam James