gpo.zugaina.org

Search Portage & Overlays:
RSS

Gentoo Repository News

Migration to sys-apps/systemd-utils - 19/04/2022 00:00 GMT

The sys-apps/systemd-utils package was recently added to the gentoo
repository. This replaces sys-apps/systemd-tmpfiles,
sys-boot/systemd-boot, and sys-fs/udev with a single package. USE flags
are provided to allow each component to be enabled or disabled. This
change was made to significantly ease maintenance of tools split out
from systemd.

When upgrading to sys-apps/systemd-tmpfiles-250,
sys-apps/systemd-utils[tmpfiles] will be pulled in as a dependency.

When upgrading to sys-boot/systemd-boot-250,
sys-apps/systemd-utils[boot] will be pulled in as a dependency.

When upgrading to sys-fs/udev-250, sys-apps/systemd-utils[udev] will be
pulled in as a dependency.

At a later date, sys-apps/systemd-tmpfiles, sys-boot/systemd-boot, and
sys-fs/udev will be masked for removal once a suitable version of
sys-apps/systemd-utils has been marked stable and sufficient time has
been provided for users to migrate.

Possible problems when upgrading:

1. If sys-fs/eudev is present in the world file (@selected), emerge will
   abort the upgrade with a unsolvable blocker error. To resolve this,
   either remove sys-fs/eudev from the world file
   (emerge --deselect sys-fs/eudev), or disable the 'udev' USE flag for
   sys-apps/systemd-utils.

2. The 'boot' USE flag on sys-apps/systemd-utils is disabled by default.
   Users migrating from sys-boot/systemd-boot will need to enable the
   'boot' USE flag (in package.use) to continue receiving updates.


Posted By: Mike Gilbert

sys-apps/systemd-utils update needed - 17/04/2022 00:00 GMT

The currently installed version of sys-apps/systemd-utils may cause
kernel modules to fail to load on boot.

Please upgrade to >=sys-apps/systemd-utils-250.4-r1 as soon as possible,
and certainly before rebooting your system.


Posted By: Mike Gilbert

Sandbox issue with ccache 4.6 - 12/04/2022 00:00 GMT

Users with ccache enabled for the dev-util/ccache package itself may need
to temporarily disable ccache in order to upgrade the package.

Users on an earlier version of ccache (<4.6) or newer (>=4.6-r1) are
unaffected.

For a small window (between 2022-04-09-4:30AM UTC and 2022-04-09-11:27AM UTC),
the ccache ebuild may have caused a sandbox violation [0] in some circumstances.

To resolve this issue, temporarily re-emerge dev-util/ccache with ccache
disabled:
# FEATURES="-ccache" emerge -v1 ">dev-util/ccache-4.6"

The sandbox violations occur when trying to use ccache for any package;
users who do not have ccache enabled globally (or at least not for ccache
itself) should also proactively upgrade ccache as above.

[0] https://bugs.gentoo.org/837362


Posted By: Sam James

Qt 5.15.3 version bump with binary path changes - 30/03/2022 00:00 GMT

Up until Qt 5.15.2 we were using qtchooser to provide unversioned links to Qt
binaries in PATH, like qmake, moc, qmljs etc. Starting with 5.15.3 [1] such
links will be installed by each respective Qt package and '5'-version-suffixed,
e.g. qmake becomes qmake5, qml becomes qml5 etc., mirroring Qt6.

If you develop with Qt5 and rely on unversioned binaries for your workflow,
dev-qt/qtchooser as a tool for quickly switching between multiple Qt
installations (e.g. Qt3, Qt4 and Qt5) can still be manually installed. The
'default' Qt version in PATH is then controlled via config in
/etc/xdg/qtchooser.

Otherwise, dev-qt/qtchooser will be slated for cleanup on your next
emerge --depclean run.

[1] https://archives.gentoo.org/gentoo-dev/message/
5f3681b5b28dabeb5339d44e9585d29f


Posted By: Andreas Sturmlechner

Transition from sys-cluster/singularity to app-containers/apptainer - 05/03/2022 00:00 GMT

In autumn 2021 the Singularity project joined the Linux Foundation
and changed its name to Apptainer [1]. The change has been reflected
in the renaming of files and environment variables, as well as a reset
of version numbers back to 1.0.0.

Apptainer packages include compatibility symlinks to old Singularity
executables, provide bash-completion rules for both the old and the new
name, continue to honour old environment variables, and will upon
the first run import user data from Singularity directories. Therefore,
for most users it will be sufficient to deselect the old package and
install the new one, e.g.:

emerge --deselect sys-cluster/singularity
emerge app-containers/apptainer

However, customisations made to system-wide configuration
in /etc/singularity will have to be applied to /etc/apptainer by hand.

[1] https://apptainer.org/news/community-announcement-20211130/


Posted By: Marek Szuba

Full MariaDB database restore maybe required - 23/11/2021 00:00 GMT

On 2021-11-21, keywords for dev-db/mariadb:10.6 were removed to
address a file collision with dev-db/mariadb-connector-c. This
unintentionally triggered a version downgrade for users who had
successfully upgraded to dev-db/mariadb:10.6 already. [Link 1].

However, downgrades are not supported in MySQL/MariaDB [Link 2].

In case you already fully upgraded to MariaDB 10.6 (which includes
executing mysql_upgrade command) and unintentionally downgraded your
MariaDB instance afterwards during the time window when keywords were
removed, you maybe experiencing different problems:

At best, your unwanted downgraded MariaDB instance prevented startup
so all you have to do is upgrade to MariaDB 10.6 again to resume
services.

In case previous MariaDB version was able to start, you are encouraged
to do a full backup as soon as possible using mysqldump command and
manually restore each database ("logical downgrade") to prevent any
data corruption.

Depending on used feature set and from which version you upgraded,
it is maybe required to do a full restore from a previous backup before
MariaDB 10.6 upgrade to restore services and prevent any data loss or
future runtime errors.

In case you are using MariaDB in a cluster and/or Galera setup you
probably have to rebuild the entire cluster in case the upgrade to
MariaDB 10.6 was already replicated (using pt-table-checksum from
dev-db/percona-toolkit can help you to validate your cluster).

Keep in mind that due to the downgrade, point-in-time recovery may
not be available to the extent that you are used to.

Link 1: https://bugs.gentoo.org/825234

Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/


Posted By: Thomas Deutschmann

net-news/rssguard-4.0 upgrade - 30/10/2021 00:00 GMT

RSS Guard database files created by RSS Guard version 3.9.x are
incompatible with RSS Guard version 4.0 or later [0].

Configuration file (config.ini) is fully backwards compatible according
to the upstream. You can save it (File -> Backup settings) before an
upgrade and restore it later (File -> Restore settings).

There is no reliable way to automate the database format conversion, so
action from the user is required before an upgrade can take place.

The first option would be to export your feeds as an OMPL file
(Accounts -> Export feeds) before an upgrade and import them later
(Account -> Import feeds).

The second option would be to manually update your database.db file to
4.x.x format following a guide by the upstream developer [1].

Keep in mind that application data directory has been renamed from
"~/.config/RSS Guard" to "~/.config/RSS Guard 4".

[0] https://github.com/martinrotter/rssguard/releases/tag/4.0.0
[1] https://github.com/martinrotter/rssguard/blob/master/resources/docs/Documentation.md#migratt


Posted By: Proxy Maintainers

netifrc DHCP client - 24/10/2021 00:00 GMT

The sys-apps/busybox package was recently removed from the system set.
Users of net-misc/netifrc may have unknowingly relied upon this package
to provide a DHCP client.

If you are using netifrc and use DHCP for network connectivity, please
ensure you have a supported DHCP client installed/selected in the
Portage world file.

Supported clients include:

dhcpcd provided by net-misc/dhcpcd
dhclient provided by net-misc/dhcp
udhcpc provided by sys-apps/busybox


Posted By: Mike Gilbert

migrating from glibc[crypt] to libxcrypt in stable - 18/10/2021 00:00 GMT

The implementation of libcrypt.so 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, now also in stable installations.

This will be a regular update, and in nearly all cases you
will not have to take any action and not observe any problems. If
you hit issues, please read on.

## Upgrades before 2021-11-01

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.

Please take the opportunity to fully upgrade your
systems now, before the migration occurs, to simplify matters

This change will occur on 2021-11-01 for stable users.
~arch users by default should already have switched.

## General advice

We also recommend being in a root shell (not via 'sudo'
or similar tools) so that if any issues occur during the upgrade,
you are not locked out of the console. It is not expected
that any such issues will occur but this is a precaution.

It is also recommended that users do _not_ have
FEATURES="collision-protect" enabled because it is
aggressive in protecting even orphaned files. Instead,
use FEATURES="unmerge-orphans" which is almost identical
in behaviour.

## Delaying the migration *or* circular dependencies

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
* unmask virtual/libcrypt:0/1

If hitting circular dependencies involving Python 3.10,
see the wiki for more details [3], but the same steps
listed above must be taken (mask newer libcrypt temporarily,
do a world upgrade, then unmask).

## Migrating early

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

## PAM warning

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.

## Build failures

In some cases, Portage may schedule a rebuild of certain packages in an
incorrect order [2]. If building a package fails, please try upgrading
Python itself to help avoid spurious build failures, and then
libcrypt and libxcrypt first:

# emerge -v1 --ignore-built-slot-operator-deps=y dev-lang/python:3.8 dev-lang/python:3.9
# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

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

## Blockers/conflicts

If you hit blockers/conflicts, please see the wiki page linked below, but
common helpful tips are:
* try more backtracking (e.g. --backtrack=1000)
* try --ignore-built-slot-operator-deps=y temporarily on the world upgrade,
then run a world upgrade again without it.

Do NOT attempt to unmerge glibc at any point.

## More help

For more information or troubleshooting tips, please see:
* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
* https://bugs.gentoo.org/699422
* Reach out to our support channels (https://www.gentoo.org/support/)

[0] https://bugs.gentoo.org/802267
[1] https://bugs.gentoo.org/802807
[2] https://bugs.gentoo.org/802210
[3] https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Circular_dependencies#Python_and_libcrypt


Posted By: Sam James

dev-libs/openssl USE=bindist removal - 17/10/2021 00:00 GMT

On 2021-11-19, the base-system team will remove USE=bindist
behavior from dev-libs/openssl, per bug #762850 [1].

Users should not experience any ABI incompatibilities that
require recompilation when moving from
dev-libs/openssl[bindist] to dev-libs/openssl[-bindist].

However, moving back in future may recompile if any binaries
of their systems depend on the additional symbols available
with USE=-bindist.

USE=bindist on dev-libs/openssl historically applied RedHat
work, called hobble-openssl [2], that was intended to make
OpenSSL "safe" to distribute with regards to various
patents, in the opinion of RedHat's legal counsel. The
hobble-openssl, in it's last iterations, it greatly
restricted which parts of EC (elliptic curve) were available
[3][4]

Debian & Ubuntu do not apply any similar behavior, and
Gentoo intends to follow Debian's lead with regards to
OpenSSL hobble-openssl moving forward.

[1] https://bugs.gentoo.org/762850
[2] Multiple files:
    https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl
	https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/ectest.c
	https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/ec_curve.c
	https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0011-Remove-EC-curves.patch
[3] https://archives.gentoo.org/gentoo-dev/message/f0d16240bb0dd1ff38fb5223bec810ab
[4] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#system-wide-crypto-policies_using-the-system-wide-cryptographic-policies


Posted By: Robin H. Johnson