`ebuild audit-2.8.5-r1.ebuild manifest` fails like that:
```
>>> Downloading
'017e6c6ab9.patch'
--2021-09-29 04:05:09--
017e6c6ab9.patch
Resolving github.com... 140.82.121.3
Connecting to github.com|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 854 [text/plain]
Saving to: /mnt/host/source/.cache/distfiles/audit-017e6c6ab95df55f34e339d2139def83e5dada1f.patch.__download__
2021-09-29 04:05:09 (57.3 MB/s) -
/mnt/host/source/.cache/distfiles/audit-017e6c6ab95df55f34e339d2139def83e5dada1f.patch.__download__ saved [854/854]
!!! Fetched file:
audit-017e6c6ab95df55f34e339d2139def83e5dada1f.patch VERIFY FAILED!
!!! Reason: Filesize does not match recorded size
!!! Got: 854
!!! Expected: 852
Refetching... File renamed to
'/mnt/host/source/.cache/distfiles/audit-017e6c6ab95df55f34e339d2139def83e5dada1f.patch._checksum_failure_.o2889wwd'
!!! Couldn't download 'audit-017e6c6ab95df55f34e339d2139def83e5dada1f.patch'. Aborting.
```
That happens because the upstream audit patch
017e6c6ab9.patch
silently changed, so it could have a git commit of 8-bytes instead 7.
Fix the hash in Manifest for now, until we could update
sys-process/audit to 3.0. Upstream Gentoo already has 3.0, dropped 2.8.
However, updating to 3.0 might not so trivial due to Flatcar changes in
audit.
The Linux 5.10 stable kernel introduced a regression that we didn't
catch because we only run kola on one hardware type in Equinix Metal.
Validate that a simple network test works on various instance types of
the current hardware generation.
The subshell was printing the error backtrace, but apparently it was
of no consequences. Just assume that listing may fail, so we don't get
any confusing backtraces.
The documentation says it always returns zero, which is not true -
portageq could return a non-zero return value and that would be the
return value of the function. Fix the function to actually follow the
documentation - apparently the function should just return an empty
string in case of failure (like package not found).
It's from gentoo commit 38b155fa1bf907617067c98eb4ba3a5d0790eb1a.
kernel-2 eclass dropped support for old EAPIs, so the linux-headers
package needs refreshing.
The bug fix https://github.com/flatcar-linux/coreos-overlay/pull/1129
caused a regression that Github Actions cannot determine a correct
$VERSION_OLD if the old ebuild file has a suffix like `-r1`.
We need to create a function to get a correct ebuild file name, by
falling back to the most similar name, in case the expected ebuild
file does not exist.
It has some weird semantics that seem to trip us up after updating
bash to 5.1. We tried to use it inside functions to clean up some
stuff after function returns. This can be emulated with an EXIT trap
within a subshell. Fortunately all the users of the RETURN trap were
not setting any global variables - modifications of such variables are
local to the subshell and are lost when the subshell exits.
When the GnuPG keyserver is set to `keys.openpgp.org`, `gpg --recv-keys`
occasionally fails with the following error:
```
gpg: key E52F0DB391453C45: no user ID
```
We need to make GnuPG accept keys even without UIDs.
Original patches come from
f292beac11/debian/patches/import-merge-without-userid .
See also https://dev.gnupg.org/T4393 .
Based on commit 3d9a9c9c3654c6b8c073e306636bf8dc64cfb657 .
Update app-crypt/gnupg to 2.2.29.
One of the key purposes for the update is to be able to use the new
default keyserver `keyserver.ubuntu.com`, which is provided by default
since 2.2.29. It is due to the shutdown of the SKS keyserver pools.
See also https://bugs.gentoo.org/811828 .
This comes from gentoo commit
3e3fc100e5298bae3ef766d10144dac5c46218c3, so it's a bit older than the
version in overlay, but the differences are small: the newer version
dropped "multilib" from inherit and has more stable keywords. We will
need to add accept_keywords to overlay for this package.
It's backported from gentoo, some newer packages in gentoo started to
use python_gen_cond_dep with one parameter only, so when we updated
them in portage stable, we don't want them to fail to build.
That way, we will stop getting errors about invalid python
implementation after updating some package that declares compatibility
with a python version we haven't yet packaged.
This could also be done by simply taking the updated version of the
eclass files from gentoo, but they also drop support for older EAPIs
that we unfortunately still use in some places.
I think we still prefer to keep packages in portage-stable and
sometimes add an entry to the accept_keywords file instead of moving
the package to overlay just to edit a keyword. Or a PYTHON_COMPAT
field.
This changes comes together with the change made in portage-stable to
one of the python eclasses where we add support for python3 version
from 3.8 to 3.10. To make this change complete, we need to mask those
new versions, so building packages will not try to depend on python
version we haven't yet packaged.
