Update dev-libs/libverto to 0.3.1-r1, to avoid failures like below:
```
!!! All ebuilds that could satisfy "=dev-libs/libverto-0.3.1-r1" for
/usr/aarch64-cros-linux-gnu/ have been masked.
!!! One of the following masked packages is required to complete your
request:
- dev-libs/libverto-0.3.1-r1::portage-stable (masked by: ~arm64 keyword)
```
2.33
- unmask amd64 and arm64
- remove tmpfiles from ebuild inherit so we don't run into a circular
dep with systemd, use systemd_tmpfilesd instead
- take care of nscd.conf via systemd_tmpfilesd,
add files/nscd-conf.tmpfiles.
- Don't run sanity checks in pkg_pretend to prevent gcc checks when
only the binary package is installed.
- comment out 'dostrip -x' to force the OS image binaries to be stripped
- remove everything glibc wants to put under /etc since we use
baselayout to provide that
2.32
sys-libs/glibc-2.32,targets/sdk: backport to EAPI6, add Flatcar changes
Backport the glibc recipe to EAPI6 to work around BDEPEND emerge
issue, add flatcar specific changes to the build recipe.
Move PYTHON_DEPS to DEPEND so things can build.
Don't run sanity checks in pkg_pretend
(similar change as in glibc-2.29) to prevent
gcc checks when only the binary package is installed.
Also, force the "crypt" use flag for all builds so libcrypt is built.
(Upstream gentoo does the same)
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
This change syncs pax-utils to 1.3.1, bringin it on par with Gentoo
upstream. A minor change is incuded in the ebuild (commented on in the
file) to work around a build issue with our (outdated)
python-single-r1.eclass.
The workaround may be removed after we updated to a python version
supported by upstream, and updated our eclasses respectively.
The update fixes an issue with scanelf and glibc-2.33:
/usr/lib/portage/python3.6/estrip: line 393: 1628751 Bad system call (core dumped) scanelf -yqRBF '#k%F' -k '.symtab' "$@"
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
We experience an issue with glibc-2.33 which causes all binaries in the
OS image to end up not stripped, which would increase the size of the OS
image threefold.
The change masks glibc-2.33 for all architectures, so the build will
default on glibc-2.32 until we have fixed the issue.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
Sync with Gentoo to update intel-microcode to 20210608,
mainly to address CVE-2020-24489, CVE-2020-24511, CVE-2020-24513.
Gentoo ref: 66c8a60ea74e8ed2391c9fdff749c65eb0f398ff
2.33
- unmask amd64 and arm64
- remove tmpfiles from ebuild inherit so we don't run into a circular
dep with systemd
- take care of nscd.conf via tmpfiles, add files/nscd-conf.tmpfiles.
- Don't run sanity checks in pkg_pretend to prevent gcc checks when
only the binary package is installed.
- comment out 'dostrip -x' to force the OS image binaries to be stripped
- remove everything glibc wants to put under /etc since we use
baselayout to provide that
2.32
sys-libs/glibc-2.32,targets/sdk: backport to EAPI6, add Flatcar changes
Backport the glibc recipe to EAPI6 to work around BDEPEND emerge
issue, add flatcar specific changes to the build recipe.
Move PYTHON_DEPS to DEPEND so things can build.
Don't run sanity checks in pkg_pretend
(similar change as in glibc-2.29) to prevent
gcc checks when only the binary package is installed.
Also, force the "crypt" use flag for all builds so libcrypt is built.
(Upstream gentoo does the same)
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
To un-break the toolchain build for arm64 for the glibc-2.33 update, a
few packages require un-masking for arm64.
This change unmasks arm64 for
* app-misc/pax-utils
* dev-libs/libev, libverto
* virtual/acl
Unmasking this here instead of overriding the masks in
package.accept_keywords because our ebuild versions are outdated, newer
upstream versions are unmasked for arm64 already. I.e. when we update to
current upstream these packages will remain available on ARM64, no need
to use custom overrides via package.accept_keywords.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
Now that lz4 was updated to 1.9.3-r1, systemd has to depend on
lz4 >= 1.9.3-r1, so that its dependency graph during the SDK stage3
could be generated correctly.
Without that change, the preclean of SDK stage3 could fail because of
an inverted dependency order between systemd and lz4, like following:
```
emerge --depclean --with-bdeps=y
...
* Dependencies could not be completely resolved due to
* the following required packages not being installed:
*
* >=app-arch/lz4-0_p131:0/r131=[abi_x86_64(-)] pulled in by:
* sys-apps/systemd-247.6
```
Stage3 first runs `emerge --quiet --usepkg --buildpkg
--binpkg-respect-use=y --newuse -e --update --deep --with-bdeps=y @system`,
which works well.
After that, only the stage3 (no other stages) runs preclean, which in fact
runs `emerge --depclean --with-bdeps=y` to clean up unnecessary ebuilds.
That's where it fails.
That happens because systemd still depends on lz4 0_p131. As a result, the
main installation step of stage3 seems to first install systemd 247, and
after that it updates lz4 to 1.9.3-r1. Then systemd thinks it still depends
on 0_p131. When doing it the other way around, the dependency graph is
correctly generated, first lz4 1.9.3-r1, then systemd 247.
This one-line change pulls the gentoo-functions source tarball from
github instead from gentoo's own gitweb, to stabilise the build process.
We assume github to have higher availability than gentoo gitweb.
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
the version stays the same (0.12.20) but we add some patches
to fix compatibility issues with autoconf.
See: https://bugs.gentoo.org/685696
Signed-off-by: Mathieu Tortuyaux <mathieu@kinvolk.io>
We disable SELinux because Flatcar doesn't properly support it and it
was causing labeling problems when running runc containers with
NoNewPrivileges or seccomp.
These were included as a workaround for SELinux issues on Flatcar.
However, they also disable NoNewPrivileges and seccomp support, which
reduces security.
Instead, we'll disable SELinux support in the Docker daemon in the next
commit.
Go import path of torcx has changed from coreos to flatcar-linux,
aef371c76b
So we need to fix the import path also in torcx ebuilds.
Otherwise build will simply fail due to wrong import paths.
