Gentoo Repository News
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 (https://fedoraproject.org/wiki/Changes/Libdb_deprecated). 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: https://docs.syncthing.net/advanced/option-insecure-allow-old-tls-versions.html
Posted By: Marek Szuba
x86 support to be dropped from media-gfx/darktable - 14/05/2021 00:00 GMT
Since version 3.0.0 media-gfx/darktable officially only supports 64-bit architectures, and we have observed errors while attempting to build these versions on x86 - making media-gfx/darktable-2.6.2 the last version to support this architecture. However the 2.6.x branch of Darktable has not seen any activity since October 2019 and we have just confirmed with upstream that all but the latest release branch (3.4.x at the time of writing this) are not supported. In light of the above we have decided to remove media-gfx/darktable-2.6.2 from the tree, thus dropping x86 support from that package, by 2021-06-15.
Posted By: Marek Szuba
Python 3.9 to become the default on 2021-06-01 - 05/05/2021 00:00 GMT
We are planning to switch the default Python target of Gentoo systems
on 2021-06-01, from Python 3.8 to Python 3.9. 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).
If you have PYTHON_TARGETS or PYTHON_SINGLE_TARGET declared
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
PYTHON_TARGETS and PYTHON_SINGLE_TARGET declarations. When
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
and PYTHON_SINGLE_TARGET.
Deferring the upgrade
=====================
To defer the upgrade, explicitly set the old targets:
*/* PYTHON_TARGETS: -* python3_8
*/* PYTHON_SINGLE_TARGET: -* python3_8
This will enforce Python 3.8 and block any future updates. However,
please note that this solution will only be suitable for a few more
months and you will eventually need to perform the migration.
Forcing the upgrade
===================
To force the upgrade earlier, explicitly set Python 3.9 targets:
*/* PYTHON_TARGETS: -* python3_9
*/* PYTHON_SINGLE_TARGET: -* python3_9
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.9 support to your system first,
and only then remove Python 3.8. However, note that involves two
rebuilds of all the affected packages, so it will take noticeably
longer.
First, enable both Python 3.8 and Python 3.9, and then run the upgrade
commands:
*/* PYTHON_TARGETS: -* python3_8 python3_9
*/* PYTHON_SINGLE_TARGET: -* python3_8
Then switch PYTHON_SINGLE_TARGET and run a second batch of upgrades:
*/* PYTHON_TARGETS: -* python3_8 python3_9
*/* PYTHON_SINGLE_TARGET: -* python3_9
Finally, switch to the final version and upgrade:
*/* PYTHON_TARGETS: -* python3_9
*/* PYTHON_SINGLE_TARGET: -* python3_9
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.10, and upgrade manually then.
Upgrade commands
================
The Python 3.8 cleanup requires that Python 3.8 is removed from 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
Exim>=4.94 transports: tainted not permitted - 04/05/2021 00:00 GMT
The Message Transfer Agent Exim disallows tainted variables in transport configurations since version 4.94. Existing exim.conf configurations in /etc/exim need to be reviewed for breakage prior to upgrading to >=mail-mta/exim-4.94 to avoid error conditions at runtime. Since the release of Exim-4.94, transports refuse to use tainted data in constructing a delivery location. If you use this in your transports, your configuration will break, causing errors and possible downtime. Particularly, the use of $local_part in any transport, should likely be updated with $local_part_data. Check your local_delivery transport, which historically used $local_part. Unfortunately there is not much documentation on "tainted" data for Exim[1], and to resolve this, non-official sources need to be used, such as [2] and [3]. [1] https://lists.exim.org/lurker/message/20201109.222746.24ea3904.en.html [2] https://mox.sh/sysadmin/tainted-filename-errors-in-exim-4.94/ [3] https://jimbobmcgee.wordpress.com/2020/07/29/de-tainting-exim-configuration-variables/
Posted By: Fabian Groffen
New OpenRC Display Manager Initializer Scripts - 30/01/2021 00:00 GMT
There has been a refactoring of the old 'xdm' init script into a new script called 'display-manager', provided by a new package that will be introduced by your @world update routine as a dependency of x11-base/xorg-server-1.20.10-r1: gui-libs/display-manager-init The package is now in ~arch and will be available to stable users starting with 2nd March 2021. [1] Its purpose is to provide the same startup mechanism for your chosen display manager (like GDM, SDDM etc. [2]) as xdm did previously, but without depending on x11-base/xorg-server. This is necessary to support new DMs that no longer depend on Xorg. Existing settings from /etc/conf.d/xdm will be migrated to new /etc/conf.d/display-manager config, however after installation it is vital not to forget to run either `etc-update` or `dispatch-conf`. Afterwards check that /etc/conf.d/display-manager contains the desired value for DISPLAYMANAGER. The old 'xdm' init script is no longer supported and henceforth removed from x11-base/xorg-server-1.20.10-r1, so it is imperative that you switch from xdm to display-manager service in default runlevel: # rc-update del xdm default # rc-update add display-manager default The changes are complete and on the next reboot, 'display-manager' will start your chosen DM. To switch to the new script without rebooting, run the following commands in a tty: # rc-service xdm stop # rc-service display-manager start Finally, the following action is necessary *ONLY* if you are running a) a DM (and rest of system) without Xorg b) a DM from an overlay, to make sure display-manager persists # emerge --noreplace gui-libs/display-manager-init [1] To make this change *now*, and proceed with this news item already, stable users would need to add the following entries to /etc/portage/package.accept_keywords [3] and update @world: ~sys-apps/sysvinit-2.98 ~x11-apps/xinit-1.4.1 ~x11-base/xorg-server-1.20.10 ~gui-libs/display-manager-init-1.0 [2] https://wiki.gentoo.org/wiki/Display_manager [3] https://wiki.gentoo.org/wiki//etc/portage/package.accept_keywords
Posted By: Andreas Sturmlechner
Python preference to follow PYTHON_TARGETS - 30/01/2021 00:00 GMT
On 2021-02-01 stable users will switch to a new method of updating the preferred Python versions that employs the configuration update mechanism in order to follow PYTHON_TARGETS. We will also deprecate app-eselect/eselect-python, and it will stop being installed by default after 2021-07-01. If you wish to use the newest Python version present in your PYTHON_TARGETS, you only have to accept configuration changes. If you wish to customize the behavior, read on. Since 2017, /usr/bin/python and the related non-versioned symlinks are wrapped through dev-lang/python-exec. The list of preferred Python implementations is stored in /etc/python-exec/python-exec.conf and/or per-program /etc/python-exec/.conf configuration files. To preserve backwards compatibility, app-eselect/eselect-python remained a wrapper that updated this file. However, this mechanism alone has proven inconvenient to end users who had to update python-exec.conf whenever the default PYTHON_TARGETS changed. Thanks to the fallback logic, this was not a major problem for software installed via Gentoo packages that always ensure that a supported implementation is used. However, users have reported that whenever the preference for /usr/bin/python mismatched their PYTHON_TARGETS, their custom scripts would break due to unsatisfied dependencies. This does not follow the principle of least surprise. For this reason, we have decided to change the default python-exec configuration to match PYTHON_TARGETS by default, in the eclass preference order, that is from the newest CPython version to oldest, with alternative Python implementations coming afterwards. This change will be propagated via the configuration protection mechanism whenever dev-lang/python-exec-conf is installed or rebuilt due to PYTHON_TARGETS changes. This will permit the users to interactively confirm the updates. If the new default is not correct for you, please use your preferred configuration update tool to discard or edit the new configuration file. Furthermore, dev-lang/python will no longer attempt to automatically update the Python interpreter preference, or pull in eselect-python automatically. If you wish to continue using it, please install/record it explicitly to ensure that it is not unmerged, e.g.: emerge -n app-eselect/eselect-python
Posted By: Michał Górny
LibreSSL support discontinued - 05/01/2021 00:00 GMT
Starting 2021-02-01, Gentoo will discontinue supporting
dev-libs/libressl as an alternative to dev-libs/openssl. While it will
still be possible for expert users to use LibreSSL on their systems,
we are only going to provide support for OpenSSL-based systems. Most
importantly, we are no longer going to maintain downstream patches for
LibreSSL support -- it will rely on either package upstreams merging
such patches themselves, or LibreSSL upstream finally working towards
better OpenSSL compatibility.
On 2021-02-01, we will mask the relevant USE flags and packages. If you
wish to continue using LibreSSL, you will be able to undo these masks
for the time being. However, as packages drop patching for LibreSSL
and the library is eventually removed from ::gentoo, it will become
necessary to use the user-maintained LibreSSL overlay [1]. As long-term
support for LibreSSL is not guaranteed, we recommend switching
to OpenSSL instead. More information on removal can be found
on the relevant bug [2].
To switch before the aforementioned date, remove 'libressl' from your
USE flags and CURL_SSL targets. Afterwards, it is recommended to
prefetch all the necessary distfiles before proceeding with the system
upgrade, in case wget(1) becomes broken in the process:
emerge --fetchonly dev-libs/openssl net-misc/wget
emerge --fetchonly --deep --changed-use @world
A --changed-use @world upgrade should automatically cause LibreSSL
to be replaced by OpenSSL, and all affected packages to be rebuilt:
emerge --deselect dev-libs/libressl
emerge --changed-use --deep @world
LibreSSL has been forked off OpenSSL in 2014 to address a number of
problems with the original package. However, since then OpenSSL
development gained speed and the original reasons for the fork no longer
apply. Furthermore, LibreSSL started to repeatedly fall behind
and cause growing compatibility problems. While initially these
problems were related to packages using old/insecure OpenSSL APIs, today
they are mostly related to LibreSSL missing newer OpenSSL APIs
(yet declaring false compatibility with newer OpenSSL versions).
With the little testing it gets, our developers and users had to put
a significant effort into fixing upstream packages. In some cases
(e.g. Qt), upstream has explicitly refused to support LibreSSL, forcing
us to maintain the patches forever. This in turn means that
security fixes, regular version bumps or end-user system upgrades are
often delayed because of necessary LibreSSL patching. What is even
worse, major runtime issues managed to sneak in that broke production
systems running LibreSSL in the past.
To the best of our knowledge, the only benefit LibreSSL has over OpenSSL
right now is the additional libtls library. For this reason, we have
packaged dev-libs/libretls which is a port of this library that links
to OpenSSL.
All these issues considered, we came to the conclusion that OpenSSL
should remain the only supported production option for Gentoo systems.
While the flexibility of Gentoo should make it possible to keep using
LibreSSL going forward, the effort necessary to provide first-class
official support for LibreSSL has proven to outweigh the benefit.
[1] https://gitweb.gentoo.org/repo/proj/libressl.git/tree/README.md
[2] https://bugs.gentoo.org/762847
Posted By: Michał Górny
Most stable hppa keywords removed - 26/12/2020 00:00 GMT
The Gentoo/HPPA team no longer thinks that the time invested in package stabilization is warranted for the small number of users on HPPA. As a result, we will drop most "hppa" keywords to "~hppa" on 2020-12-31. Around 850 packages will retain their stable keywords. Users need not make any changes to their systems—other than perhaps adding some entries to their package.accept_keywords file. The Gentoo/HPPA team has no plans to remove support for the architecture.
Posted By: Matt Turner