Gentoo Repository News
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
Python 3.7 to become the default target - 22/04/2020 00:00 GMT
On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one of the default Python targets for Gentoo systems. The new default values will be: PYTHON_TARGETS="python2_7 python3_7" PYTHON_SINGLE_TARGET="python3_7" If you have not overriden these variables on your system, then your package manager will switch to the new targets immediately. In order to avoid dependency conflicts, please clean stray packages up and rebuild/upgrade all packages with USE flag changes after the change, e.g.: emerge --depclean emerge -1vUD @world emerge --depclean Please note that during the system upgrade some of the package dependencies may temporarily become missing. While this should not affect programs that are already fully loaded, it may cause ImportErrors when starting Python scripts or loading additional modules (only scripts running Python 3.6 are affected). In order to improve stability of the upgrade, you may choose to temporarily enable both targets, i.e. set in /etc/portage/package.use or its equivalent: */* PYTHON_TARGETS: python3_6 python3_7 */* PYTHON_SINGLE_TARGET: -* python3_6 This will cause the dependencies to include both Python 3.6 and 3.7 support whenever possible, throughout the next system upgrade. Once all packages are updated, you can restart your scripts, remove the setting and start another upgrade in order to cleanly remove Python 3.6. There are still some Gentoo packages that do not support Python 3.7. We will be pushing updates to these packages as time permits. However, some of them will probably be removed instead. If you would like to postpone the switch to Python 3.7, you can copy the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET to /etc/portage/package.use or its equivalent: */* PYTHON_TARGETS: -python3_7 python3_6 */* PYTHON_SINGLE_TARGET: -* python3_6 If you would like to migrate your systems earlier, you can do the opposite. Note that if you are running ~arch, you may want to go straight for Python 3.8 at this point. Please note that this switch is long overdue. Python 3.6 is no longer receiving bug fixes. Its planned end-of-life is 2021-12-23 but we will probably remove it earlier than that. [1] All above snippets assume using package.use to control USE flags. If you still have make.conf entries for these targets, you need to remove them. While using make.conf is possible, it is strongly discouraged as it does not respect package defaults. The latter can help you keep some of Python 3.6 packages without the need to explicitly toggle flags per-package. [1] https://devguide.python.org/#status-of-python-branches
Posted By: Michał Górny
Desktop profile switching USE default to elogind - 14/04/2020 00:00 GMT
Modern desktop environments make use of PAM session tracking for users, login sessions and seats. [1] The most user-visible part of that is device and file permissions management and reboot/shutdown handling without superuser rights. Users with systemd can stop reading here and continue with their daily routine. ConsoleKit2 is unmaintained upstream for more than two years [2]. There are many longstanding bugs and papercuts with consumers that aren't being fixed, not least because these code paths receive very little testing. Enter the elogind project [3], which is a standalone logind implementation based on systemd code, currently maintained by a fellow Gentoo user. We have had sys-auth/elogind available in Gentoo since the beginning of 2017, and meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE and Xfce, as well as most other former consolekit consumers. Consequently, the desktop profile is switching away from consolekit to elogind. Users of sys-auth/consolekit who selected a different profile should consider doing the same. A guide is available [6]. Migration is easy, but any existing consolekit session will be broken, and elogind will only begin to work on relogin. Rely either on the profile, or set USE="elogind -consolekit" in make.conf yourself. Make sure there is no consolekit debris in /etc/portage/package.use: # grep -R consolekit /etc/portage/package.use Rebuild all affected consumers and remove sys-auth/consolekit: # emerge --ask --changed-use --deep @world # emerge --depclean consolekit Optional, but recommended in case of trouble such as missing reboot/shutdown capabilities in the display manager: # rc-update add elogind boot For users of ~/.xinitrc instead of one of the supported DMs, do not forget to update accordingly (ck-launch-session is gone without replacement). PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7] which is dead even longer than the original ConsoleKit(1) project. KDE Plasma users sticking with sys-auth/consolekit are then going to lose suspend from GUI without superuser rights. [1] https://wiki.gentoo.org/wiki/ConsoleKit [2] https://github.com/ConsoleKit2/ConsoleKit2 [3] https://github.com/elogind/elogind/blob/master/README.md [4] https://bugs.gentoo.org/show_bug.cgi?id=elogind-support [5] https://blogs.gentoo.org/leio/2019/03/26/gnome-3-30/ [6] https://wiki.gentoo.org/wiki/Elogind [7] https://bugs.gentoo.org/659616
Posted By: Andreas Sturmlechner