We have updated pythong and the related eclasses some time ago, so I
think this ebuild should be working fine now. Also, it needs updating,
because net-fs/samba started to require a newer version of it.
- Add a minimal USE flag for only installing libraries
- Change the Perl run-time dep to build-time only
- Disable building libraries requiring Python
- Limit the size of bundled libraries
Since linux-firmware 20220509, intel/ice/ddp/ice-1.3.26.0.pkg was
updated to ice-1.3.28.0.pkg. As a result the symlink ice.pkg needs to be
also updated so it points to the correct version of the file.
Create a variable for the ICE DDP version for better maintenance.
Use Go 1.18 instead of 1.17 by default in all ebuilds.
Note, we still keep building app-emulation/docker{,-cli} with Go 1.17,
to be consistent with upstream Docker 20.10.x, which still builds with
Go 1.17. That should avoid potential unexpected regressions that
happened in the past.
Update the default version of dev-lang/go to 1.18.2.
Keep go1.17 as well to build docker{,-cli} with Go 1.17.
Use EAPI=7 for all versions.
See also https://go.dev/doc/go1.18.
We should update EAPI from 6 to 7, to deprecate old EAPIs in general.
To make it work with EAPI=7, replace get_version_component_range with
ver_cut, as get_version_component_range does not work any more with EAPI
7. As a result, the versionator eclass is not needed any more.
There was a kernel regression on Xen HVM with regard to MSI interrupts that
affected certain AWS instances (m4 and similar). We reverted the patch that
broke networking, but in the meantime upstream found the actual cause and
provided a proper fix which is part of 5.15.38. Remove the obsolete patch.
Link: https://lore.kernel.org/all/20220504153056.686401990@linuxfoundation.org/
To be able to distinguish changelog entries from each other, we should
write a specific project name, e.g. coreos-overlay, instead of `PR`.
Changelog entries with a simple `PR` usually cause so much additional
rework when doing actual releases.
The GitHub Actions were defined for the LTS stream directly but we can
now follow the approach used for the other channels. This means that
in the future we could decide to create new Actions for 2022 by copying
the current one and modifying it when 2023 gets the new current LTS -
anyway some manual work would be required to set up Actions for both
old and new at the same time (we have no "previous" symlink on Origin).
We could retire the old LTS Actions immediately because the releases
don't occur on a fixed schedule but I think the automation is nice to
keep.
