Gentoo Repository News
setuptools_scm-6.3.0 temporary runtime breakage - 05/09/2021 00:00 GMT
Users who upgraded to =dev-python/setuptools_scm-6.3.0 between 2021-09-03 15:42 UTC and 2021-09-03 19:03 UTC may be affected by a bug [0]. If you have not upgraded to this version or have >=dev-python/setuptools_scm-6.3.0-r1 installed, you are not affected. A missing dependency in the setuptools_scm ebuild meant there was a timeframe in which anyone who installed dev-python/setuptools_scm and dev-python/packaging in the wrong order won't be able to build any Python package using setuptools unless a workaround is applied. Specifically, this affects users with =dev-python/setuptools_scm-6.3.0 installed and where dev-python/packaging is not installed (applies separately for each/any Python target). The bad tree state was between gentoo.git commits 8882e54abf78d3af69faed5844e3ad441482f23e and 0c76b447cd1be9cf611f649970851750304d9ca6. Affected users will see errors similar to the following when installing Python packages: ``` pkg_resources.DistributionNotFound: The 'packaging>=20.0' distribution was not found and is required by the application ``` To fix this manually, you need to fully remove all dev-python/setuptools_scm files by running the following commands: # Necessary to obtain a fixed version of setuptools_scm $ emerge --sync # --unmerge is NOT advised normally, but is required to avoid setuptools picking # up the runtime-broken setuptools_scm version when re-installing setuptools_scm $ emerge --unmerge =dev-python/setuptools_scm-6.3.0 $ emerge --oneshot dev-python/setuptools dev-python/pyparsing dev-python/packaging $ emerge --oneshot ">=dev-python/setuptools_scm-6.3.0-r1" Note that the version specifiers above are not strictly necessary if you have an up-to-date copy of the tree but provide a safety net. [0] https://bugs.gentoo.org/811504
Posted By: Sam James
eudev retirement on 2022-01-01 - 24/08/2021 00:00 GMT
sys-fs/udev is becoming the standard provider of udev on non-systemd (e.g. OpenRC) systems. Users of systemd will continue to use the udev services provided by the sys-apps/systemd package itself. The transition should be uneventful in most cases, but please read this item in full to understand some possible corner cases. eudev will be retired and removed from Gentoo on 2022-01-01. We will start masking eudev on 2021-10-01 and give people 3 months to prepare their transition. You should ensure that sys-fs/eudev is not in your world file by running emerge --deselect sys-fs/eudev in order for Portage to replace eudev with sys-fs/udev once the package.mask is in place. We fully support udev on musl, whereas uclibc will still have to rely on eudev before also being removed on 2022-01-01. **WARNING** If you happen to have an INSTALL_MASK with a blanket "*systemd*" glob, you will inevitably break your system. sys-fs/udev contains "systemd" in some of its filenames, hence a blanket filter rule will likely lead to a non-functional udev installation. Rationale The integration of udev into the systemd git repo introduced numerous problems for non-glibc systems, such as musl and uclibc. Several options were considered, and the one chosen was to fork and maintain udev independent of the rest of systemd. This was meant as a stop-gap solution until such time as the problems with systemd on musl had been resolved. This is now the case with patches provided by openembedded, and my original reason for maintaining eudev is no longer relevant. I am willing to transfer eudev to another umbrella organization or Linux distribution that is willing to continue its maintenance, but maintaining eudev cannot be done purely through proxy-maintaining and requires an understanding of its internals. This is a steep learning curve and must be an earnest effort. For this reason, the Base System project has decided not to support eudev as an option going forward.
Posted By: Anthony G. Basile
>=app-misc/mc-4.8.27 to drop support for ~/.mc - 19/08/2021 00:00 GMT
app-misc/mc versions between 4.8.1 and 4.8.26, inclusive, would look
for their user configuration in two possible places:
* if built with USE=-xdg, only the legacy directory ~/.mc is used;
* if built with USE=xdg, mc uses appropriate XDG user directories
(e.g. ~/.config/mc, ~/.local/share/mc) if present and attempts
to automatically migrate the contents of ~/.mc otherwise.
However, starting with version 4.8.27 Midnight Commander will use _only
XDG user directories_ for its configuration and no longer automatically
migrate the contents of ~/.mc. For more information, see:
https://midnight-commander.org/wiki/NEWS-4.8.27
https://midnight-commander.org/ticket/3682
For everyone who currently uses app-misc/mc[-xdg], or has not started
mc for so long that it hasn't had a chance to migrate its configuration,
upgrading to 4.8.27 or newer will result in Midnight Commander
effectively reverting to default user configuration. In order to prevent
this from happening, make sure automatic migration is available:
echo 'app-misc/mc xdg' >> /etc/portage/package.use
emerge --oneshot
Posted By: Marek Szuba uClibc-ng retirement on 2022-01-01 - 18/08/2021 00:00 GMT
uClibc-ng is mostly abandoned upstream, and since my RFC in Jan 2021, no one has volunteered to step up maintenance or expressed interest in the uClibc-ng profiles. With this announcement we last-rite the "uclibc" profiles, which will be removed on 2022-01-01. For parties interested in an alternative libc, consider moving to musl, which is supported. Gentoo continues to wholeheartedly support musl and is focusing its efforts in that area. Resources: - https://wiki.gentoo.org/wiki/Project:Hardened_musl - https://gitweb.gentoo.org/proj/musl.git/ (overlay for patches) - #gentoo-hardened (IRC channel on irc.libera.chat) for support and discussion
Posted By: Anthony G. Basile
OAuth2 Credentials Removed from Chromium - 11/08/2021 00:00 GMT
In March of this year, Google announced that OAuth2 credentials would be revoked
for distros shipping Chromium. This was covered in multiple places at the time,
such as [1,2,3]. Around that time, with 89.0.4389.82, Gentoo removed OAuth2
credentials from its packages. However, they slipped back in shortly after.
As a result, some users [4] have found that recently Google's SSO does not
persist between browser sessions; e.g. you have to log back into GMail every
time you open your browser. This week's changes [5] restore the old behavior
we had in March, of not shipping Gentoo OAuth2 credentials.
If you find that certain Google services are no longer working, you may wish to
supply OAuth2 credentials manually, obtained by following the instructions at
[6]. However, even without supplying such credentials, Google's SSO should now
be working as expected.
There are now two options for passing these credentials to Chromium via
/etc/chromium/default:
1. GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET environment
variables:
export GOOGLE_DEFAULT_CLIENT_ID=""
export GOOGLE_DEFAULT_CLIENT_SECRET=""
2. --oauth2-client-id and --oauth2-client-secret= command line switches:
CHROMIUM_FLAGS+=" --oauth2-client-id="
CHROMIUM_FLAGS+=" --oauth2-client-secret="
Alternatively these environment variables and command line switches may be given
at the command line for ad-hoc testing.
[1] https://archlinux.org/news/chromium-losing-sync-support-in-early-march/
[2] https://bodhi.fedoraproject.org/updates/FEDORA-2021-48866282e5
[3] https://hackaday.com/2021/01/26/whats-the-deal-with-chromium-on-linux-google-at-odds-with-package-maintainers/
[4] https://bugs.gentoo.org/791871
[5] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fce48ef271bbcaee9afdf0481294da167e665a9b
[6] http://www.chromium.org/developers/how-tos/api-keys
Posted By: Jason A. Donenfeld
USE=tcpd no longer globally enabled - 01/08/2021 00:00 GMT
On 2021-11-01, we will remove USE="tcpd" from the globally default enabled USE flags (https://bugs.gentoo.org/805077). USE="tcpd" usually enables sys-apps/tcp-wrappers for an ad hoc firewall based on /etc/hosts.allow and /etc/hosts.deny. The Base System project has come to the conclusion that 24 years after the last upstream release, tcp-wrappers is not suitable for a default configuration in 2021 anymore. Other distributions have completely removed support at this point. We strongly recommend you switch to more modern packet filters, such as BPF, nftables, or iptables. If you rely on tcp-wrappers, you can re-enable the flag, see https://wiki.gentoo.org/wiki//etc/portage/package.use for package-specific ways to re-enable tcp-wrappers.
Posted By: David Seifert
migrating from glibc[crypt] to libxcrypt in ~arch - 23/07/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, starting with ~arch 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. 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. That is, please take the opportunity to fully upgrade your systems now, before the migration occurs, to simplify matters. This change will occur on 2021-07-14 for ~arch users. Stable users will update at a later date. 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 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 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. In some cases, Portage may schedule a rebuild of certain packages in an incorrect order [2]. If building a package fails, please try upgrading libcrypt and libxcrypt first: # emerge -v1 virtual/libcrypt sys-libs/libxcrypt And then continue the world upgrade with Portage's "--keep-going=y". For more information or troubleshooting tips, please see: * https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation * https://bugs.gentoo.org/699422 [0] https://bugs.gentoo.org/802267 [1] https://bugs.gentoo.org/802807 [2] https://bugs.gentoo.org/802210
Posted By: Sam James
Perl 5.34 upgrade now stable - 20/07/2021 00:00 GMT
The Perl project in Gentoo has begun stabilisation of Perl 5.34 [0] which is the latest stable version released upstream. While the package manager usually handles this upgrade cleanly, there are some bugs [1][2][3] which affect Portage's dependency resolution that sometimes mean rebuilds occur in the wrong order - this is exacerbated by the packaging model used for Perl (but not its fault). We therefore recommend the following procedure for users: 1. Sync your tree: # emerge --sync 2. Perform a full world upgrade, e.g.: # emerge -a -uvDU @world --keep-going=y 3. If any failures occur, please run perl-cleaner --all, then try again: # perl-cleaner --all 4. Perform a world upgrade again. 5. Once complete, depclean: # emerge -a --depclean If the upgrade fails with conflicts, please try --backtrack=1000 or some other large number. Rarely, it may be necessary to perform a one-off installation of a package, but usually `perl-cleaner` will resolve the issue. If an error message occurs after running perl-cleaner, try e.g. for a fictional package dev-perl/foo: # emerge -a --oneshot --verbose dev-perl/foo If you have any issues, please consult the standard support channels [4] (such as our forums or IRC channels) and we will do our best to get your system working well again. [0] https://bugs.gentoo.org/802639 [1] https://bugs.gentoo.org/592880 [2] https://bugs.gentoo.org/793992 [3] https://bugs.gentoo.org/199856 [4] https://www.gentoo.org/support/
Posted By: Sam James
new ppc64 profiles - 17/07/2021 00:00 GMT
A new set of ppc64 profiles has been added to the Gentoo
repository in Jan 2020. These profiles switch to a more standard
'no SYMLINK_LIB' multilib layout, and require explicit migration as
described below. They are considered stable at the moment, and we would
like to request all users to upgrade their systems. The old profiles
will be deprecated in the near future.
In the new profiles, the lib->lib64 compatibility symlink is removed.
64-bit libraries need to be installed directly to lib64. /lib
and /usr/lib become real directories, that are used for cross-arch
and native non-library packages (gcc, clang).
The migration is performed using app-portage/unsymlink-lib tool.
The following steps can be used to upgrade your system:
1. Sync and upgrade your system to the newest package versions
to reduce the risk of issues.
2. Install the tool:
# emerge -1v app-portage/unsymlink-lib
3. Run 'unsymlink-lib --analyze' and check the output for obvious
mistakes. If you need to perform any changes to the system, remember
to run 'unsymlink-lib --analyze' again afterwards.
[past this point do not call emerge or modify /usr manually]
4. This is a very good time to make a backup.
5. Run 'unsymlink-lib --migrate'. You can add '--pretend' first to see
what is going to happen.
6. Reboot your system. Check if important programs work.
In particular, verify that e.g. 'emerge --info' works (but do not
install anything). If you hit any serious problems, you can use
'unsymlink-lib --rollback' to revert the changes and return to
step 4.
7. Run 'unsymlink-lib --finish'. You can add '--pretend' first to see
what is going to happen but note that you're going to see a very long
list of files to remove.
8. Switch the profile, e.g.:
# eselect profile set default/linux/ppc64/17.0
[at this point you can start using emerge again]
9. Rebuild the toolchain:
# emerge -1v sys-devel/gcc:10
[ repeat for other slots you will be using ]
# emerge -1v sys-devel/binutils
# emerge -1v sys-libs/glibc
For known issues, please see bugs #506276 [2] and #640184[3] .
If you have any problems with the new profiles or the migration procedure,
please report a bug and make it block the tracker.
For more information on the layout, please see the wiki article
on AMD64 multilib layouts [4], it applies to PPC64 as well.
[1] https://gentoo.org/support/news-items/2017-11-30-new-17-profiles.html
[2] https://bugs.gentoo.org/506276
[3] https://bugs.gentoo.org/640184
[4] https://wiki.gentoo.org/wiki/Project:AMD64/Multilib_layout
Posted By: Georgy Yakovlev
PulseEffects-5+ are now media-sound/easyeffects - 16/07/2021 00:00 GMT
Since version 5.0.0, media-sound/pulseeffects have explicitly required media-video/pipewire rather than just a PulseAudio client (i.e. either PipeWire or plain media-sound/pulseaudio). Following up on this change, upstream has decided to rename the project to EasyEffects starting with version 6.0.0. Gentoo will follow the upstream renaming but in a slightly different fashion: - versions older than 5.0.0, i.e. ones not depending on media-video/pipewire, will continue to use the name media-sound/pulseeffects; - versions: 5.0.0 and newer, i.e. all requiring media-video/pipewire, will be available as media-sound/easyeffects. media-sound/easyeffects is already available in the tree, and the remaining PipeWire-dependent versions of media-sound/pulseeffects will be removed on 2021-07-23. Therefore, PipeWire users of media-sound/pulseeffects should switch to media-sound/easyeffects by deselecting the old package and installing the new one, e.g. emerge --deselect media-sound/pulseeffects emerge media-sound/easyeffects No action is required of media-sound/pulseeffects users who either use PulseAudio exclusively or wish to retain the ability to use this package with both PulseAudio and PipeWire.
Posted By: Marek Szuba