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>
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.
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.
- Drop the init.d files.
- Remove the socket unit's rate limiting.
Instead of dropping bindist, enable it with the profiles now so it
doesn't need to be modified on future updates.
Imported commit 6c0c1c8806bedcc164e5bd3541ab50b2c21e2498 .
Since containerd 1.5 started to turn on Go module, we need to pass
`-mod=vendor` to the go build command.
Otherwise, go build will fail because it would try to fetch missing
go deps from remote repos. It would not work inside of sandbox.
We cannot set `COREOS_GO_MOD=vendor` because containerd ebuild calls
`emake` instead of `go_build`.
Since coreos-firmware 20210511, `cxgb4/t[4-6]fw*.bin` files have a new
version '1.25.4.0'. We need to update the file name pointed by symlinks.
Otherwise build fails due to broken symlinks.
