Search Portage & Overlays:

Gentoo Repository News

MySQL server and library dependency shift - 13/02/2019 00:00 GMT

Due to the complexity of supporting multiple client libraries,
the Gentoo MySQL maintainers have decided to drop dependencies on the
server installation where it is not absolutely necessary.

This will mean that packages might not automatically install the server
as a dependency since it does not have to exist on the local machine.

To ensure uninterrupted service, verify that the server package,
such as dev-db/mariadb, dev-db/mysql, etc, is included in the world file
where it is in operation. This can be accomplished by running emerge
with the --noreplace option.
Eg.: emerge --noreplace dev-db/mariadb

Posted By: Brian Evans

ARM 17.0 profile migration with CHOST change - 07/09/2018 00:00 GMT

The new 17.0 profiles for ARM are now officially available. This not
only features the PIE migration previously announced for other
architectures but also a tuple (CHOST) change for hardfloat systems.

In short, the tuple will change from armv7a-hardfloat-linux-gnueabi to
armv7a-unknown-linux-gnueabihf or similar. This is to fall in line with
what the rest of the Linux community are now using. If the vendor (2nd)
part of your tuple is different or missing then you may keep it as it
is. The hf ending is what matters.

If you are using an unversioned alternative profile such as
hardened/linux/arm/armv7a then the default CHOST will have changed for
you already. Hopefully, you were shielded from the change by having
CHOST explicitly set in your make.conf. In this case, a migration is
still required.

Changing CHOST is never simple and does carry some risk. We encourage
users to migrate but if you do not have sys-devel/llvm on your system
and you do not cross-compile for ARM then you may choose to keep your
existing CHOST. We will continue to support this to some degree
although we cannot promise that other packages will not be affected in

If you choose not to migrate or your system is not hardfloat then you
must ensure that CHOST is explicitly set in make.conf and then proceed
with a regular 17.0 migration to deal with PIE as detailed here:

Otherwise, if you do wish to migrate then we have written a script to
do the necessary steps for you.

Download the raw script here:

View with syntax highlighting and change history here:

It takes a minimal backup of the existing toolchain with quickpkg
before changing anything but we strongly recommend that you take a
full backup first. The script echos each command as it goes along so
that you can keep an eye on what it's doing. You are, of course,
welcome to tinker with the script or perform the migration manually if
you think you know your own system better. It is heavily commented for
this reason.

If the script fails then you can take remedial action before running
it again and it should skip any time-consuming builds that it has
already done. If the migration doesn't go to plan then please do seek
help in #gentoo-arm.

A migration of this kind can justify rebuilding @world but with ARM
typically being very slow, the script does just the minimum
necessary. You are free to rebuild @world yourself after running it.

Posted By: James Le Cuirot

Migration required for OpenSSH with LDAP - 07/08/2018 00:00 GMT

If your sshd authenticates against LDAP, you have to migrate your
current setup to a new one using sshd's "AuthorizedKeysCommand" option and
a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK
patch set is deprecated and no longer applies.

We have created a short migration guide in the Wiki [1] for more details.


Posted By: Thomas Deutschmann

Portage rsync hardlink support - 11/07/2018 00:00 GMT

For users of the rsync tree, beginning with sys-apps/portage-2.3.42,
the default behavior for sync operations will use hardlinks in order
to ensure that a repository remains in a valid state if something
goes wrong [1]. For example, if signature verification fails during a
sync operation, the new hardlink behavior will preserve the previous
state of the repository.

The new behavior may conflict with configurations that restrict the
use of hardlinks, such as overlay filesystems. Therefore, users will
have to set "sync-allow-hardlinks = no" in repos.conf if they have
a configuration that restricts the use of hardlinks, but this should
not be very common:

sync-allow-hardlinks = no

Note that it is possible to sync more efficiently using git [2]
instead of rsync, though git consumes an increasing amount of disk
space over time unless shallow pull is enabled via the sync-depth
option in repos.conf [3] (requires sys-apps/portage-2.3.42 or later).

[1] sys-apps/portage: use rsync
    --link-dest to implement atomic repository updates (and abort if
    signature verification fails)
[3] sys-apps/portage: support shallow
    git pull by setting sync-depth = 1 in repos.conf

Posted By: Zac Medico

Python 3.6 to become the default target - 22/05/2018 00:00 GMT

On 2018-06-22, Python 3.6 will replace Python 3.5 in the default Python
targets for Gentoo systems.  The new default targets will be:

    PYTHON_TARGETS="python2_7 python3_6"

If you have not overriden the value of those variables on your system,
then your package manager will want to use the new targets immediately.
In order to prevent dependency conflicts, please clean stray packages
and rebuild/upgrade all packages with USE flag changes after the change,

    emerge --depclean
    emerge -1vUD @world
    emerge --depclean

Please note that upgrading dependencies in place may cause some
of the package dependencies to be temporarily missing.  While this
should not affect scripts that are already fully loaded, it may cause
ImportErrors while starting Python scripts or loading additional
modules (only scripts running Python 3.5 are affected).

In order to improve stability of the upgrade, you may choose to
temporarily enable both targets, i.e. set in /etc/portage/make.conf
or its equivalent:

    PYTHON_TARGETS="python2_7 python3_5 python3_6"

This will cause the dependencies to include both Python 3.5 and 3.6
support on the next system upgrade.  Once all packages are updated,
you can restart your scripts, remove the custom setting and run another
upgrade to remove support for Python 3.5.

If you would like to postpone the switch to Python 3.6, you can copy
the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET
to /etc/portage/make.conf or its equivalent:

    PYTHON_TARGETS="python2_7 python3_5"

If you would like to migrate your systems earlier, you can do the same
with the new value.

If you are still using Python 3.4, please consider switching to a newer
version as it is reaching its end-of-life.  The end-of-life dates
for the currently used versions are:

  Python 3.4        2019-03-16
  Python 2.7        2020-01-01
  Python 3.5        2020-09-13 [1]


Posted By: Michał Górny

Radicale 2 requires pre-install migration - 02/04/2018 00:00 GMT

Radicale version 2 uses a new storage format and is not able to read
databases created by version 1. Version 1 releases starting from 1.1.3
include a --export-storage option which can be used to export their
databases in a format that Radicale 2 can use; you must do this before
upgrading to version 2.

If you have kept the Gentoo-default database configuration, this will
1. Stop any running instance of Radicale.
2. Run `radicale --export-storage ~/radicale-exported`.
3. Run `chown -R radicale: ~/radicale-exported`
4. Run `mv /var/lib/radicale /var/lib/radicale.old`.
5. Install Radicale version 2.
6. Run `mv ~/radicale-exported /var/lib/radicale/collections`.

For more details, or if you are have a more complex configuration,
please see the migration guide:
If you do a custom migration, please ensure the database is cleaned out
of /var/lib/radicale, including the hidden .props file.

Posted By: Christopher Head

Portage rsync tree verification unstable - 13/03/2018 00:00 GMT

Portage rsync tree verification is being temporarily turned off by
default, starting with sys-apps/portage-2.3.24. This permits
stabilization of sys-apps/portage-2.3.24 while still working on bugs
relating to tree verification [1]: deadlocks [2] & key fetching [3].

If users wish to enable the 'rsync-verify' USE flag for sys-apps/portage,
they need to follow these steps:

1) In order to unmask the 'rsync-verify' USE flag, create a file named
/etc/portage/profile/package.use.mask containing a line like the

    sys-apps/portage -rsync-verify

2) Once the 'rsync-verify' USE flag has been unmasked as described
in step 1, it can be enabled with a line like the following in

    sys-apps/portage rsync-verify

3) After the configuration changes in steps 1 and 2 have been made, run
the following command:

    emerge --oneshot --newuse '>=sys-apps/portage-2.3.24'

After all above steps are successfully completed, a line like the
following should appear in the emerge --info output for the gentoo

    sync-rsync-verify-metamanifest: yes

If you wish to disable it for some reason, you can set
'sync-rsync-verify-metamanifest = no' in your repos.conf.

[1] sys-apps/portage: [TRACKER] issues
    related to 'rsync-verify' USE flag
[2] app-portage/gemato-11.2: deadlock?
[3] sys-apps/portage: gpg key refresh
    needs exponential backoff with jitter

Posted By: Zac Medico

Portage rsync tree verification - 30/01/2018 00:00 GMT

Starting with sys-apps/portage-2.3.21, Portage will verify the Gentoo
repository after rsync by default.

The new verification is intended for users who are syncing via rsync.
Users syncing via git or other methods are not affected, and complete
verification for them will be provided in the future.

The verification is implemented via app-portage/gemato. Currently,
the whole repository is verified after syncing. On systems with slow
hard drives, this could take around 2 minutes. If you wish to disable
it, you can disable the 'rsync-verify' USE flag on sys-apps/portage
or set 'sync-rsync-verify-metamanifest = no' in your repos.conf.

Please note that the verification currently does not prevent Portage
from using the repository after syncing. If 'emerge --sync' fails,
do not install any packages and retry syncing. In case of prolonged
or frequent verification failures, please make sure to report a bug
including the failing mirror addresses (found in emerge.log).

The verification uses information from the binary keyring provided
by the app-crypt/gentoo-keys package. The keys are refreshed
from the keyserver before every use in order to check for revocation.
The post-sync verification ensures that the authenticity of the key
package itself is verified. However, manual verification is required
before the first use.

On Gentoo installations created using installation media that included
portage-2.3.22, the keys will already be covered by the installation
media signatures. On existing installations, you need to manually
compare the primary key fingerprint (reported by gemato on every sync)
against the official Gentoo keys [1]. An example gemato output is:

  INFO:root:Valid OpenPGP signature found:
  INFO:root:- primary key: 1234567890ABCDEF1234567890ABCDEF12345678
  INFO:root:- subkey: FEDCBA0987654321FEDCBA0987654321FEDCBA09

Please note that the above snippet does not include the real key id
on purpose. The primary key actually printed by gemato must match
the 'Gentoo Portage Snapshot Signing Key' on the website. Please make
sure to also check the certificate used for the secure connection
to the site!


Posted By: Michał Górny

systemd sysv-utils blocker resolution - 23/01/2018 00:00 GMT

Starting with systemd-236, the sysv-utils USE flag is enabled by

The sysv-utils USE flag controls installation of symlinks for several
key commands:

    /sbin/halt -> ../bin/systemctl
    /sbin/init -> ../lib/systemd/systemd
    /sbin/reboot -> ../bin/systemctl
    /sbin/poweroff -> ../bin/systemctl
    /sbin/runlevel -> ../bin/systemctl
    /sbin/shutdown -> ../bin/systemctl
    /sbin/telinit -> ../bin/systemctl

These commands are otherwise provided by sys-apps/sysvinit. This package
is blocked by systemd when the sysv-utils USE flag is enabled.

Enabling sysv-utils should cause Portage to un-merge sysvinit and OpenRC
if they are currently installed. emerge may emit a warning message
before doing so; if you are booting with systemd, this message is safe
to ignore.

If you wish to keep sysvinit (and openrc) installed, you may disable the
sysv-utils USE flag locally.

If you run into unresolvable blockers with sysv-utils enabled, ensure
that you do not have any reverse dependencies of sys-apps/sysvinit
selected (in your world file).

Common packages to look for:


The equery command from gentoolkit may help track down installed
packages that depend on openrc.

    equery depends sys-apps/openrc

Posted By: Mike Gilbert

GnuCash 2.7+ Breaking Change - 14/01/2018 00:00 GMT

Along with changes to use modern libraries, GnuCash 2.7+ has changed the
schema [1] it uses for both databases and files. GnuCash will
automatically modify the file or database in place upon open.

Therefore, it is imperative that you back up any files or databases
before using GnuCash 2.7 in case you run into an issue and want or need
to revert back to 2.6.

Close any open session of GnuCash including remote sessions, then
follow the relevant backup instructions as follows:

For XML (plain files):
$ cp /path/to/file.gnucash /path/to/file.gnucash.bak

For MySQL:
$ mysqldump gnucash_db | xz > gnucash-2.6.sql.xz

For PostgreSQL:
$ pg_dump -U gnucash_user -Z 5 gnucash_db > gnucash-2.6.sql.gz

For SQLite:
$ cp /path/to/sqlite.file.gnucash /path/to/sqlite.file.gnucash.bak


Posted By: Aaron W. Swenson