Search Portage & Overlays:

Gentoo Repository News

USE=tcpd no longer globally enabled - 01/08/2021 00:00 GMT

On 2021-11-01, we will remove USE="tcpd" from the globally default
enabled USE flags ( USE="tcpd" usually
enables sys-apps/tcp-wrappers for an ad hoc firewall based on
/etc/hosts.allow and /etc/hosts.deny.

The Base System project has come to the conclusion that 24 years after
the last upstream release, tcp-wrappers is not suitable for a default
configuration in 2021 anymore. Other distributions have completely
removed support at this point. We strongly recommend you switch to more
modern packet filters, such as BPF, nftables, or iptables. If you rely
on tcp-wrappers, you can re-enable the flag, see

for package-specific ways to re-enable tcp-wrappers.

Posted By: David Seifert

migrating from glibc[crypt] to libxcrypt in ~arch - 23/07/2021 00:00 GMT

The implementation of within glibc has been deprecated
for a long time and will be removed in the near future.

For this reason, we are following other distributions (where
this has been tested for years already) and switching to the 
external libxcrypt implementation, starting with ~arch 

This will be a regular update, and in nearly all cases you
will not have to take any action and not observe any problems.

We do recommend, however, that your system is *fully* up
to date first. This is a standard recommendation but in this
specific case, it is useful to have a simplified depgraph
to ensure that Portage is able to smoothly calculate
an upgrade path.

That is, please take the opportunity to fully upgrade your
systems now, before the migration occurs, to simplify matters.

This change will occur on 2021-07-14 for ~arch users. Stable
users will update at a later date.

If for whatever reason you do *not* wish to switch now -
which is only delaying the inevitable - you
need to take the following steps:
* unmask and enable the crypt USE flag of sys-libs/glibc
* mask the system USE flag of sys-libs/libxcrypt
* mask >=virtual/libcrypt-2

If you wish to manually migrate now, there are a series
of steps described on the wiki (see below), but the outline is:
* unforce the crypt USE flag of sys-libs/glibc and disable it
* unmask the system and split-usr (if applicable) USE flag of sys-libs/libxcrypt
and enable it
* unmask ~virtual/libcrypt-2

Please note that if you last changed your password before ~2008,
it may be using md5crypt or similar other weak mechanisms in /etc/shadow;
a bug in PAM [0][1] may mean that you were unable to login. We recommend
using "passwd" to change/refresh your password so it is using modern
methods. A new version of PAM has been added to the tree to resolve this issue.

In some cases, Portage may schedule a rebuild of certain packages in an
incorrect order [2]. If building a package fails, please try upgrading
libcrypt and libxcrypt first:

# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

And then continue the world upgrade with Portage's "--keep-going=y".

For more information or troubleshooting tips, please see:


Posted By: Sam James

Perl 5.34 upgrade now stable - 20/07/2021 00:00 GMT

The Perl project in Gentoo has begun stabilisation of Perl 5.34 [0]
which is the latest stable version released upstream.

While the package manager usually handles this upgrade cleanly, 
there are some bugs [1][2][3] which affect Portage's dependency resolution
that sometimes mean rebuilds occur in the wrong order - this is
exacerbated by the packaging model used for Perl (but not its fault).

We therefore recommend the following procedure for users:
1. Sync your tree:
# emerge --sync

2. Perform a full world upgrade, e.g.:
# emerge -a -uvDU @world --keep-going=y

3. If any failures occur, please run perl-cleaner --all, then try again:
# perl-cleaner --all

4. Perform a world upgrade again.

5. Once complete, depclean:
# emerge -a --depclean

If the upgrade fails with conflicts, please try --backtrack=1000 or some
other large number.

Rarely, it may be necessary to perform a one-off installation of a package,
but usually `perl-cleaner` will resolve the issue. If an error message occurs
after running perl-cleaner, try e.g. for a fictional package dev-perl/foo:
# emerge -a --oneshot --verbose dev-perl/foo

If you have any issues, please consult the standard support channels [4]
(such as our forums or IRC channels) and we will do our best to get your
system working well again.


Posted By: Sam James

new ppc64 profiles - 17/07/2021 00:00 GMT

A new set of ppc64 profiles has been added to the Gentoo
repository in Jan 2020.  These profiles switch to a more standard
'no SYMLINK_LIB' multilib layout, and require explicit migration as
described below.  They are considered stable at the moment, and we would
like to request all users to upgrade their systems.  The old profiles
will be deprecated in the near future.

In the new profiles, the lib->lib64 compatibility symlink is removed.
64-bit libraries need to be installed directly to lib64.  /lib
and /usr/lib become real directories, that are used for cross-arch
and native non-library packages (gcc, clang).

The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:

1. Sync and upgrade your system to the newest package versions
   to reduce the risk of issues.

2. Install the tool:

     # emerge -1v app-portage/unsymlink-lib

3. Run 'unsymlink-lib --analyze' and check the output for obvious
   mistakes.  If you need to perform any changes to the system, remember
   to run 'unsymlink-lib --analyze' again afterwards.

[past this point do not call emerge or modify /usr manually]

4. This is a very good time to make a backup.

5. Run 'unsymlink-lib --migrate'.  You can add '--pretend' first to see
   what is going to happen.

6. Reboot your system.  Check if important programs work.
   In particular, verify that e.g. 'emerge --info' works (but do not
   install anything).  If you hit any serious problems, you can use
   'unsymlink-lib --rollback' to revert the changes and return to
   step 4.

7. Run 'unsymlink-lib --finish'.  You can add '--pretend' first to see
   what is going to happen but note that you're going to see a very long
   list of files to remove.

8. Switch the profile, e.g.:

     # eselect profile set default/linux/ppc64/17.0

[at this point you can start using emerge again]

9. Rebuild the toolchain:

      # emerge -1v sys-devel/gcc:10
      [ repeat for other slots you will be using ]
      # emerge -1v sys-devel/binutils
      # emerge -1v sys-libs/glibc

For known issues, please see bugs #506276 [2] and #640184[3] .
If you have any problems with the new profiles or the migration procedure,
please report a bug and make it block the tracker.

For more information on the layout, please see the wiki article
on AMD64 multilib layouts [4], it applies to PPC64 as well.


Posted By: Georgy Yakovlev

PulseEffects-5+ are now media-sound/easyeffects - 16/07/2021 00:00 GMT

Since version 5.0.0, media-sound/pulseeffects have explicitly required
media-video/pipewire rather than just a PulseAudio client (i.e. either
PipeWire or plain media-sound/pulseaudio). Following up on this change,
upstream has decided to rename the project to EasyEffects starting with
version 6.0.0.

Gentoo will follow the upstream renaming but in a slightly different
 - versions older than 5.0.0, i.e. ones not depending on
   media-video/pipewire, will continue to use the name
 - versions: 5.0.0 and newer, i.e. all requiring media-video/pipewire,
   will be available as media-sound/easyeffects.

media-sound/easyeffects is already available in the tree, and the
remaining PipeWire-dependent versions of media-sound/pulseeffects will
be removed on 2021-07-23. Therefore, PipeWire users of
media-sound/pulseeffects should switch to media-sound/easyeffects by
deselecting the old package and installing the new one, e.g.

emerge --deselect media-sound/pulseeffects
emerge media-sound/easyeffects

No action is required of media-sound/pulseeffects users who either use
PulseAudio exclusively or wish to retain the ability to use this
package with both PulseAudio and PipeWire.

Posted By: Marek Szuba

systemd-tmpfiles replaces deprecated opentmpfiles - 15/07/2021 00:00 GMT

A tmpfiles [0] implementation provides a generic mechanism to define
the creation of regular files, directories, pipes, and device nodes,
adjustments to their access mode, ownership, attributes, quota
assignments, and contents, and finally their time-based removal.
It is commonly used for volatile and temporary files and directories
such as those located under /run/, /tmp/, /var/tmp/, the API file
systems such as /sys/ or /proc/, as well as some other directories
below /var/. [1]

On 2021-07-06, the sys-apps/opentmpfiles package was initially masked
due to a root privilege escalation vulnerability (CVE-2017-18925 [2],
bug #751415 [3], issue 4 [4] upstream).

The severity of this vulnerability is disputed due to the practical
obstacles to its exploitation in any default or supported configuration.

That said, the use of opentmpfiles is discouraged by its maintainer due
to the unpatched vulnerability and other long-standing bugs [5]. It has
now been declared obsolete in favour of systemd-tmpfiles by opentmpfiles

Users will start seeing their package manager trying to replace
sys-apps/opentmpfiles with sys-apps/systemd-tmpfiles because it is
another provider of virtual/tmpfiles.

Despite the name, 'systemd-tmpfiles' does not depend on systemd, does
not use dbus, and is just a drop-in replacement for opentmpfiles. It is
a small binary built from systemd source code, but works separately,
similarly to eudev or elogind. It is known to work on both glibc and
musl systems.

Note that systemd-tmpfiles is specifically for non-systemd systems. It
is intended to be used on an OpenRC system.

If you wish to selectively test systemd-tmpfiles, follow those steps:

 1. # emerge --oneshot sys-apps/systemd-tmpfiles
 2. # reboot
 3. # rm /etc/runlevels/boot/opentmpfiles-setup
 4. # rm /etc/runlevels/sysinit/opentmpfiles-dev

No other steps required.

If you still wish to use opentmpfiles for the time being, you can unmask [6]
 1. In /etc/portage/package.unmask, add a line:
 2. # emerge --oneshot sys-apps/opentmpfiles

Note that opentmpfiles is likely to be removed from gentoo repository
in the future. You may wish to put it in a local overlay instead [7].


Posted By: Sam James

USE flag 'pax_kernel' to be renamed to 'pax-kernel' - 28/06/2021 00:00 GMT

On 2021-07-01 the USE flag 'pax_kernel' will be renamed to 'pax-kernel'
in order to remove the disallowed underscore character. If you use
a PaX-enabled kernel, update your package-manager configuration
accordingly; failure to do so might result in affected packages no longer
functioning on your system.

Posted By: Marek Szuba

riscv upgrade to 20.0 profiles - 20/06/2021 00:00 GMT

On RISC-V we are switching from two-level library directories (e.g., 
/usr/lib64/lp64d) to a more traditional directory architecture.
This is done via the profile upgrade from 17.0 to 20.0 profiles.

We recommend to re-install from scratch using a 20.0 profile based
stage. 17.0 profiles will be deprecated immediately and removed
in 6 months.

If you want to upgrade an existing installation, the following
steps should be taken. Please read all commands carefully first and
make sure you understand them, since the procedure is risky. The 
commands are given for a lp64d profile; in case of a lp64 profile, 
always replace lp64d with lp64.

# cd /usr/local/lib64
# cp -av lp64d/. .
# rm -rf lp64d
# ln -s . lp64d

# cd /usr/lib64
# cp -av lp64d/. .
# rm -rf lp64d
# ln -s . lp64d

# cd /lib64
# cp -av lp64d/. .
# rm -rf lp64d
# sln . lp64d

Note that the last command uses "sln" instead of "ln -s".

Then switch from your 17.0 profile to the corresponding 20.0 profile,
either by using "eselect profile" or by manually changing the
/etc/portage/make.profile symlink.

Next, rebuild all packages:

# emerge -eav world

As last step, check if portage has removed any of the symlinks created 
above, and if yes, recreate them.

Posted By: Andreas K. Hüttel

sys-libs/db old SLOT removal - 30/05/2021 00:00 GMT

On 2021-07-01, we will mask the following Berkeley DB (aka sys-libs/db)
slots for removal from the tree within 90 days (bug #792222):

- 1
- 3
- 4.2
- 4.3
- 4.4
- 4.5
- 4.6
- 4.7
- 5.1

You should export your data first before rebuilding any applications
against newer slots of sys-libs/db.

Furthermore, the Gentoo Base System Team has decided to consider
sys-libs/db a deprecated database backend. What this means for you is
that we will slowly start deprecating optional use of sys-libs/db in
consumers and mask their USE="berkdb" flags with the goal of eventual
removal of berkdb support from those packages.

Other distros such as Fedora have started a gradual phase-out of
Berkeley DB too, given Oracle's strong-armed approach to community
input and their arguably hostile switch to the AGPLv3
( Furthermore,
Oracle is known for removing critical features from BDB in supposed
patch releases, such as the removal of the client-server architecture
and the SQL API between 18.1.32 and 18.1.40.

To this end, we will also be removing USE="berkdb" from
profiles/default/linux/make.defaults on 2021-07-01. If you implicitly
depend on profiles enabling optional use of sys-libs/db, you will need
to enable this USE flag yourself.

From here on, you should be working under the assumption that the
sys-libs/db package will be gone from the Gentoo repository within
**two years** from the time of this news item. If you depend on BDB in
a production environment, we strongly suggest you move to one of the
modern replacements, such as GDBM, SQLite or LMDB.

Posted By: David Seifert

>=net-p2p/syncthing-1.17.0 incompatibility warning - 18/05/2021 00:00 GMT

Starting with version 1.17.0, net-p2p/syncthing by default only allows
TLS 1.3 for sync connections - making it impossible to sync with devices
not supporting it, i.e. running Syncthing versions older than 1.3.0.

If you do require your Syncthing cluster to support TLS 1.2, you will have to
explicitly allow it by enabling the option "insecureAllowOldTLSVersions".
For details see:

Posted By: Marek Szuba