Now EAPI <= 4 are gone, we can update this eclass.
Commit-Ref: 7b01b4e5c717e91eee103485209b12deb985adf3
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
upstream has masked openssl-3 for tracking build failures. Since we are
not impacted by this failures, we can safely unmask openssl-3.
See: https://github.com/flatcar-linux/Flatcar/issues/418 for Flatcar's
dependencies.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
- drop `pkg_postint`
- create `/etc/ssl` with tmpfiles
- remove unecessary files
- mark openssl as stable for arm64 and amd64
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
Update dev-libs/expat to 2.4.3, mainly to address the following
security issues:
CVE-2021-45960, CVE-2021-46143, CVE-2022-22822, CVE-2022-22823,
CVE-2022-22824, CVE-2022-22825, CVE-2022-22826, CVE-2022-22827
We used to keep the package in overlay, because we dropped one Gentoo
patch to avoid some failures when applying updates when updating
payloads. This issue was fixed in bzip2 in a smarter way - we know
this, because we used 1.0.8 version with the fix and we didn't have
any problems so far. No point in keeping the package in overlay then.
source_on_disk() so far relied on the 'sourcePackage' field, which contains the
primary dependency of a torcx packge (app-torcx/docker ->
app-emulation/docker). Now the 'metaPackage' field (app-torcx/docker) is used,
which lets us look at RDEPENDS and figure out all packages that are indirectly
installed when installing a torcx package. torcx_dependencies() does just that,
so move it's definition to torcx_manifest.sh.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
The torcx_manifest.json file currently has a 'sourcePackage' field which is
extracted from the first runtime dependency of the torcx package ebuild. This
is a convention, and causes sourcePackage to hold 'app-emulation/docker' for
the 'app-torcx/docker' package. This does not carry enough information to be
able to figure out what other packages are part of the torcx package.
Store an additional field, 'metaPackage', in the manifest which contains the
name of the torcx package. With the right ebuild it is then possible to figure
out what other packages are part of a given torcx package. This can then be
used to add that information to the image packages list.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Instead of looping over the package list, pass all the packages to a single
emerge call and specify num jobs. This lets emerge build/install all of them in
parallel, shaving some time off the torcx build.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
