Gentoo Repository News
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
kubernetes Split Packages Returning - 06/10/2020 00:00 GMT
In order to fix the ability to upgrade kubernetes components separately, the kubernetes split packages are returning [1]. Starting with kubernetes 1.17.12, 1.18.9 and 1.19.2, you will need to install the following packages in the appropriate configuration for your cluster. sys-cluster/kubeadm sys-cluster/kube-apiserver sys-cluster/kube-controller-manager sys-cluster/kubectl sys-cluster/kubelet sys-cluster/kube-proxy sys-cluster/kube-scheduler Once the split packages are stabilized, sys-cluster/kubernetes will be masked and removed. [1] https://bugs.gentoo.org/741572
Posted By: William Hubbs
Python 2.7 cleanup is progressing - 28/09/2020 00:00 GMT
Python 2.7 has reached its end-of-life by 2019-12-31, and many projects
have removed Python 2 support since. During the last few months we have
been working hard to migrate Gentoo to Python 3, and we have finally
reached the point making it possible for the vast majority of our users
to run a system free of Python 2.7 packages (except for the interpreter
itself).
The few remaining high profile packages (e.g. dev-python/cython)
are preserving Python 2.7 only for a very few uncommon packages.
For this reason, we have decided to create new revisions of them having
Python 2.7 removed. If you do not need Python 2.7 there, your package
manager should upgrade these packages to the new revisions.
Please note that you may need to manually uninstall any Python 2.7
packages installed from third-party repositories and/or run `emerge
--depclean` first to remove orphan packages. The recommended process
for Portage users is:
emerge --depclean
emerge -vDuU @world
emerge --depclean
Please note that the Python 2.7 interpreter (without additional Python
packages) remains necessary to build a few high profile packages,
in particular Chromium, Mozilla software and PyPy. If you build either
of these packages from source, you will not be able to permanently
remove Python 2.7 from your system.
We are going to preserve CPython 2.7 (and PyPy2.7) for as long
as necessary and provide security fixes to the best of our ability.
However, please note that we are not able to dedicate resources to
auditing Python 2.7's code and with little community interest in that,
it should be considered potentially vulnerable.
If your projects still rely on Python 2.7, we would like to once again
encourage you to migrate them to Python 3. However, if you really need
to run them, we suggest using a virtualenv. To create a new Python 2.7
environment, install dev-python/virtualenv and use the following option:
virtualenv -p /usr/bin/python2.7 ...
To create a PyPy2.7 environment:
virtualenv -p /usr/bin/pypy ...
Modern versions of pip should be able to automatically select older
versions of packages that still support Python 2.7. Please note that
these versions are generally no longer supported. They can be buggy,
vulnerable or simply incompatible with one another.
Please do not forget to add dev-lang/python:2.7 to your @world set
or it may get depcleaned once all package dependencies are gone.
Posted By: Michał Górny
riscv multilib profile is going away - 06/09/2020 00:00 GMT
The Gentoo RISC-V team is discontinuing the riscv64 multilib stages and
profile. The main reason for this is that with the upcoming introduction
of riscv32 a multilib stage would contain both 32bit and 64bit binaries,
and so far no hardware exists that is able to run both and thus update
the stage or installation (unless you use qemu).
Please switch to the rv64gc/lp64d profile. This is done by
* selecting default/linux/riscv/17.0/rv64gc/lp64d with eselect profile
* rebuilding gcc
emerge -1 sys-devel/gcc
* and then rebuilding your system
emerge -ev @world
The default/linux/riscv/17.0/rv64gc profile will stop functioning soon.
Posted By: Andreas K. Hüttel
xorg-server dropping default suid - 24/06/2020 00:00 GMT
Starting 2020-07-15, stable keyworded x11-base/xorg-server will default to using the logind interface instead of suid by default. resulting in better security by default through running the server as a regular user instead of root. However, this will require our users to use a logind provider such as elogind or systemd. The systemd users and those who are not using systemd but use desktop profiles can stop reading here, as they already have a logind provider enabled. Others, who have neither systemd or desktop profiles enabled will be required to globally enable 'elogind' USE flag and update the system # emerge --newuse @world Afterwards, one will need to re-login, so the PAM can assign a seat. One can confirm that a seat has been assigned upon login by running: $ loginctl user-status Users who do not wish to use logind interface or have rare hardware that does not use KMS and because of that, require root privileges to operate, can manually re-enable 'suid' and disable 'elogind' USE flags in order to preserve the previous behavior. However, please note that this is heavily discouraged to run X server as root due to security reasons. The 'suid' USE flag will remain as optional opt-in for the need of legacy hardware.
Posted By: Piotr Karbowski
sys-libs/pam-1.4.0 upgrade - 23/06/2020 00:00 GMT
Starting with the 1.4.0 release [1], we don't offer these modules anymore: * pam_tally and pam_tally2 have been deprecated and replaced by the pam_faillock module * pam_cracklib has been deprecated and replaced by the pam_passwdqc module These changes affected our basic PAM stack configuration. You only need to take action if: * you made manual changes to the PAM stack, or * you use FEATURES="-config-protect-if-modified" option If this applies to you, please make sure to either run the etc-update or dispatch-conf command in order to sync your configuration. Failure to do this may result in your system becoming inaccessible. [1] - https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0
Posted By: Mikle Kolyada
Potential file collisions during OpenCL upgrade - 22/04/2020 00:00 GMT
OpenCL support in Gentoo is now being migrated to having all implementations
operate through an ICD loader (dev-libs/ocl-icd or dev-libs/opencl-icd-loader)
installed directly into /usr rather than using eselect-opencl to switch
between implementations, with updated loader ebuilds having just been released
to the public. Unfortunately although the upgrade process will automatically
uninstall app-eselect/eselect-opencl, it will not remove the symbolic links to
libOpenCL.so created by this tool in library directories because those links
are not owned by the package in question.
For everyone using the default Gentoo configuration of collision protection
(FEATURES='-collision-protect protect-owned'), this should cause no trouble
because this configuration allows the overwriting of orphaned files.
Obviously, systems with collision protection completely disabled (not
recommended but technically possible) will not be affected either. However,
if your system is configured for full collision protection
(FEATURES=collision-protect), it will be necessary to manually remove those
links
rm -i /usr/lib/libOpenCL.so*
before running the upgrade.
Posted By: Marek Szuba