gpo.zugaina.org

Search Portage & Overlays:
RSS

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