gpo.zugaina.org

Search Portage & Overlays:
RSS

Gentoo Repository News

Full MariaDB database restore maybe required - 23/11/2021 00:00 GMT

On 2021-11-21, keywords for dev-db/mariadb:10.6 were removed to
address a file collision with dev-db/mariadb-connector-c. This
unintentionally triggered a version downgrade for users who had
successfully upgraded to dev-db/mariadb:10.6 already. [Link 1].

However, downgrades are not supported in MySQL/MariaDB [Link 2].

In case you already fully upgraded to MariaDB 10.6 (which includes
executing mysql_upgrade command) and unintentionally downgraded your
MariaDB instance afterwards during the time window when keywords were
removed, you maybe experiencing different problems:

At best, your unwanted downgraded MariaDB instance prevented startup
so all you have to do is upgrade to MariaDB 10.6 again to resume
services.

In case previous MariaDB version was able to start, you are encouraged
to do a full backup as soon as possible using mysqldump command and
manually restore each database ("logical downgrade") to prevent any
data corruption.

Depending on used feature set and from which version you upgraded,
it is maybe required to do a full restore from a previous backup before
MariaDB 10.6 upgrade to restore services and prevent any data loss or
future runtime errors.

In case you are using MariaDB in a cluster and/or Galera setup you
probably have to rebuild the entire cluster in case the upgrade to
MariaDB 10.6 was already replicated (using pt-table-checksum from
dev-db/percona-toolkit can help you to validate your cluster).

Keep in mind that due to the downgrade, point-in-time recovery may
not be available to the extent that you are used to.

Link 1: https://bugs.gentoo.org/825234

Link 2: https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/


Posted By: Thomas Deutschmann

net-news/rssguard-4.0 upgrade - 30/10/2021 00:00 GMT

RSS Guard database files created by RSS Guard version 3.9.x are
incompatible with RSS Guard version 4.0 or later [0].

Configuration file (config.ini) is fully backwards compatible according
to the upstream. You can save it (File -> Backup settings) before an
upgrade and restore it later (File -> Restore settings).

There is no reliable way to automate the database format conversion, so
action from the user is required before an upgrade can take place.

The first option would be to export your feeds as an OMPL file
(Accounts -> Export feeds) before an upgrade and import them later
(Account -> Import feeds).

The second option would be to manually update your database.db file to
4.x.x format following a guide by the upstream developer [1].

Keep in mind that application data directory has been renamed from
"~/.config/RSS Guard" to "~/.config/RSS Guard 4".

[0] https://github.com/martinrotter/rssguard/releases/tag/4.0.0
[1] https://github.com/martinrotter/rssguard/blob/master/resources/docs/Documentation.md#migratt


Posted By: Proxy Maintainers

netifrc DHCP client - 24/10/2021 00:00 GMT

The sys-apps/busybox package was recently removed from the system set.
Users of net-misc/netifrc may have unknowingly relied upon this package
to provide a DHCP client.

If you are using netifrc and use DHCP for network connectivity, please
ensure you have a supported DHCP client installed/selected in the
Portage world file.

Supported clients include:

dhcpcd provided by net-misc/dhcpcd
dhclient provided by net-misc/dhcp
udhcpc provided by sys-apps/busybox


Posted By: Mike Gilbert

migrating from glibc[crypt] to libxcrypt in stable - 18/10/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, now also in stable 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.

We also recommend being in a root shell (not via 'sudo'
or similar tools) so that if any issues occur during the upgrade,
you are not locked out of the console. It is not expected
that any such issues will occur but this is a precaution.

It is also recommended that users do _not_ have
FEATURES="collision-protect" enabled because it is
aggressive in protecting even orphaned files. Instead,
use FEATURES="unmerge-orphans" which is almost identical
in behaviour.

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-11-01 for stable users.
~arch users by default should already have switched.

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
* unmask virtual/libcrypt:0/1

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
Python itself to help avoid spurious build failures, and then
libcrypt and libxcrypt first:

# emerge -v1 --ignore-built-slot-operator-deps=y dev-lang/python:3.8 dev-lang/python:3.9
# emerge -v1 virtual/libcrypt sys-libs/libxcrypt

And then continue the world upgrade with Portage's "--keep-going=y".

If you hit conflicts, please see the wiki page linked below, but
common helpful tips are:
* try more backtracking (e.g. --backtrack=1000)
* try --ignore-built-slot-operator-deps=y temporarily on the world upgrade,
then run a world upgrade again without it.

Do NOT attempt to unmerge glibc at any point.

For more information or troubleshooting tips, please see:
* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation
* https://bugs.gentoo.org/699422
* Reach out to our support channels (https://www.gentoo.org/support/)

[0] https://bugs.gentoo.org/802267
[1] https://bugs.gentoo.org/802807
[2] https://bugs.gentoo.org/802210


Posted By: Sam James

dev-libs/openssl USE=bindist removal - 17/10/2021 00:00 GMT

On 2021-11-19, the base-system team will remove USE=bindist
behavior from dev-libs/openssl, per bug #762850 [1].

Users should not experience any ABI incompatibilities that
require recompilation when moving from
dev-libs/openssl[bindist] to dev-libs/openssl[-bindist].

However, moving back in future may recompile if any binaries
of their systems depend on the additional symbols available
with USE=-bindist.

USE=bindist on dev-libs/openssl historically applied RedHat
work, called hobble-openssl [2], that was intended to make
OpenSSL "safe" to distribute with regards to various
patents, in the opinion of RedHat's legal counsel. The
hobble-openssl, in it's last iterations, it greatly
restricted which parts of EC (elliptic curve) were available
[3][4]

Debian & Ubuntu do not apply any similar behavior, and
Gentoo intends to follow Debian's lead with regards to
OpenSSL hobble-openssl moving forward.

[1] https://bugs.gentoo.org/762850
[2] Multiple files:
    https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/hobble-openssl
	https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/ectest.c
	https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/ec_curve.c
	https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0011-Remove-EC-curves.patch
[3] https://archives.gentoo.org/gentoo-dev/message/f0d16240bb0dd1ff38fb5223bec810ab
[4] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#system-wide-crypto-policies_using-the-system-wide-cryptographic-policies


Posted By: Robin H. Johnson

OpenSSH RSA SHA-1 signatures - 08/10/2021 00:00 GMT

As of version 8.8, OpenSSH disables RSA signatures using the SHA-1
hash algorithm by default. This change affects both the client and
server components.

After upgrading to this version, you may have trouble connecting to
older SSH servers that do not support the newer RSA/SHA-256/SHA-512
signatures. Support for these signatures was added in OpenSSH 7.2.

As well, you may have trouble using older SSH clients to connect to a
server running OpenSSH 8.8 or higher. Some older clients do not
automatically utilize the newer hashes. For example, PuTTY before
version 0.75 is affected.

To resolve these problems, please upgrade your SSH client/server
whereever possible. If this is not feasible, support for the SHA-1
hashes may be re-enabled using the following config options:

HostkeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa


Posted By: Mike Gilbert

Possible failure to preserve libraries - 29/09/2021 00:00 GMT

We have observed in some cases corruption of Portage's internal database
(VDB), where the libraries provided by a package are not recorded. This
can break the "preserve-libs" functionality, and thus in rare cases
break your system during much later updates (even if you do not use
"preseved-libs" now, but decide to switch it on later).

The underlying problem occurs usually when glibc has been upgraded to a
new major version, but pax-utils has not yet been upgraded to a version
compatible with it (but at that moment stays undetected).

The full technical details and investigation can be found on a Wiki page
[0] and on Bugzilla [1]. Changes have been made to prevent this happening
again both within Portage [7] (with possibly more to come [2]) and within the
glibc and pax-utils ebuilds [3][4].

To detect whether a system is affected, emerge the
app-portage/recover-broken-vdb package:
```
$ emerge --ask --verbose --oneshot app-portage/recover-broken-vdb
```
which provides two tools: recover-broken-vdb-find-broken.sh and
recover-broken-vdb.

Then run recover-broken-vdb-find-broken.sh:
```
$ recover-broken-vdb-find-broken.sh | tee broken_vdb_packages
```

This check should be run on all Gentoo systems. It is only necessary
to run this as a one-off, as changes have been made to prevent such
problems occurring in future.

If you have any output, read on.

Fixing a broken system is not always straightforward. It is strongly
recommended to take a backup of your full system before proceeding,
as well as a copy of /var/db/pkg (the VDB):

Step 1. A tool has been developed [5] to attempt to fix the consistency
  of the Portage database. Using this tool to modify the VDB is NOT
  mandatory (read the full news item before proceeding) - you can skip
  to Step 2 if you wish, but fixing the integrity of the VDB
  makes it as safe as reasonably possible to proceed with
  rebuilding packages.

  Run:
  ```
  # Take a backup of /var/db/pkg before proceeding, such as by doing:
  $ cp -a /var/db/pkg /var/db/pkg.orig

  # And then:
  $ emerge --ask --verbose --oneshot --noreplace \
  	app-portage/recover-broken-vdb

  $ recover-broken-vdb

  # The tool will output to a random temporary directory.
  # Inspect the results, and then update the real /var/db/pkg/
  # by doing either:

  $ recover-broken-vdb --output /var/db/pkg

  # Or, manually copying the new files from the temporary directory tree
  # into your real /var/db/pkg/ directory tree.
  ```

Step 2. Attempt to rebuild the affected packages, first upgrading
  app-misc/pax-utils to the latest version:
  ```
  $ emerge --ask --verbose --oneshot ">=app-misc/pax-utils-1.3.3"
  $ emerge --ask --verbose --oneshot --usepkg=n $(grep -v '#' broken_vdb_packages)
  ```

  It's possible that the relevant versions have disappeared from the tree, so
  if the emerge command fails, please attempt a normal world upgrade.

Step 3. Given that there are possible other side-effects of the corruption/bug,
  it is strongly recommended that if any corruption is detected, all
  packages on the system should be rebuilt, after following the above
  steps:
  ```
  $ emerge --ask --emptytree --usepkg=n @world
  ```

  Note that binary packages may need to be discarded given they may
  contain corrupt metadata.

  If no libraries were broken, it is likely safe to skip this step. It
  should be sufficient, for resource-constrained machines, to simply
  rebuild any broken libraries and their consumers (reverse-dependencies):
  revdep-rebuild may help you do this.

  (If you do not know what that means, please proceed with Step 3.)

Please see the wiki [0] for a full description of the background
of this problem and handling corner cases such as e.g. already
being affected by system breakage [6] as a result of the bug.

[0] https://wiki.gentoo.org/wiki/Project:Toolchain/Corrupt_VDB_ELF_files
[1] https://bugs.gentoo.org/811462
[2] https://github.com/gentoo/portage/pull/744
[3] https://bugs.gentoo.org/811462#c6
[4] https://bugs.gentoo.org/811462#c7
[5] https://github.com/thesamesam/recover-broken-vdb
[6] https://wiki.gentoo.org/wiki/Fix_my_Gentoo
[7] https://gitweb.gentoo.org/proj/portage.git/commit/?id=83af7270fafbd7b1eed0031a5e06836ad1edf06d


Posted By: Hank Leininger

busybox removal from system set - 24/09/2021 00:00 GMT

The sys-apps/busybox package has been removed from the system
set (@system) in Linux profiles. It was decided that this package is not
necessary for a basic system install.

If you would like to keep this package installed, please ensure it is
present in your Portage world file.

  emerge --select --noreplace sys-apps/busybox

As well, the "static" USE flag has been disabled by default. It may be
re-enabled locally via package.use if so desired.

UPDATE: busybox includes a DHCP client (udhcpc). Some users of netifrc
unknowingly rely on this client. If your networking configuration uses
DHCP, please ensure that you have a DHCP client selected in the Portage
world file.


Posted By: Mike Gilbert

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