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