Enable kernel config
[CONFIG_IKHEADERS](435faf5c21/init/Kconfig (L610-L617)
),
to make Kernel export kernel headers via `/sys/kernel/kheaders.tar.xz`.
Then bpf-related tools can be used without additional kernel headers in
userspace.
Before, we were relying on the toolchains job to build and upload
packages that were part of the SDK. With this change, all packages that
should be part of the SDK are built and uploaded by the SDK job. The
toolchains job only builds toolchain packages specific for the release.
This change includes several adjustments done to both the SDK and the
toolchains jobs to make this work:
* Make the SDK job build all cross toolchains, including Rust
* Stop building Rust in the toolchains job and use the one in the SDK
instead.
* In toolchain_util.sh: detect when the symlink folder for crossdev
packages is missing and run crossdev to create it during
update_chroot setup.
* Make it possible to build the SDK starting from stage 4 instead of
stage 1, to make the SDK building faster for PR branches / nightlies
(full build should still be done for releases / weeklies).
This reverts commit 517e23ebfe96137f1482ae42f8b29fc2f1b31317.
The new USE flag `ssl` for wget resulted in a strange issue.
`wget` started to pull in `dev-libs/openssl`, which has `bindist` in its
USE flag. The catalyst stages, however, need to install wget without
`bindist`. Such mismatches resulted in errors like:
```
!!! All ebuilds that could satisfy "dev-libs/openssl:0=" for /tmp/stage1root/ have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-libs/openssl-1.0.2u::coreos (masked by: bindist in RESTRICT)
```
So to fix the issue, what needs to be done is basically:
```
ACCEPT_RESTRICT=bindist USE=-bindist emerge -pv openssl openssh
```
Unfortunately it is not possible to set `accept_restrict` configs
under the coreos-overlay repo. We need to have some time to investigate
why it is so.
As a hotfix, we need to revert the `ssl` USE flag for wget.
When catalyst tries to fetch a file via https, wget sometimes fails
to do so, with the following messages:
```
https://www.kernel.org/pub/software/scm/git/git-2.24.1.tar.xz: HTTPS
support not compiled in.
!!! Couldn't download 'git-2.24.1.tar.xz'. Aborting.
```
That probably happens because wget in some catalyst stages are compiled
without `ssl` USE flag. If a catalyst stage is lucky enough to rebuild
wget with `ssl` before actually fetching a file, it would work well.
Though if not, it would fail. It is not deterministic, and hard to
reproduce.
So backport the fix from upstream Gentoo,
https://github.com/gentoo/gentoo/commit/d141380b915d , for both amd64
and arm64. By setting `ssl` for wget in `package.use.force`, it is now
not possible to disable `ssl` for wget.
More details: https://bugs.gentoo.org/611072
Drop pkg_pretend since it breaks build_image if cross-compilers are
not installed yet (e.g. in Jenkins jobs).
Drop the libidn2 runtime dependency since it breaks bootstrapping,
and it's dlopen()ed so the resolver can work without it.
Drop the host /dev/pts checks since the SDK doesn't control it.
Apply our gshadow segfault patch, and adapt into glibc 2.30.
Install nscd.conf in /usr and set up tmpfiles to link it in /etc.
Wipe out /etc files (except for an environment file that is still
needed in the SDK).
Originally comes from eb07324f4de3 ("sys-libs/glibc: Apply CoreOS
changes").
When 788f328dc752a75da08d4c6fc27d094ecb4807d5 introduced pulling from
docker by default, "--insecure-options=image" was added for all
docker registries. However, when the user also needs to set "http" as
in "--insecure-options=image,http" it will not be used because the
other argument is added as last disregarding the option was already
set by the user.
Check if the option was set by the user and only add it if it is not
provided. If the user forgets to add "image" then rkt will simply
fail and tell that this option is needed; thus no complex logic of
appending and detecting only "image" is needed. Do the same for the
"--trust-keys-from-https" option to be consistent in allowing to
overwrite it with "--trust-keys-from-https=false".
- Mask sig 0x000406e3, pf_mask 0xc0, revision=0xd6 [Link 1]
- Mask sig 0x000406e3, pf_mask 0xc0, revision=0xda [Bug 722768]
This will basically downgrade microcode for 0x000406e3 back to rev 0x00d6 from 2019-10-03.
Link1: c1d8ba62ab
Signed-off-by: Sayan Chowdhury <sayan@kinvolk.io>
For some unicode characters in ca-certificates file names "rev" complains
about an "invalid or incomplete multibyte or wide character"
and gives no output.
Filter out any unexpected characters for "rev" and replace them with "?"
so that "ls some?name" will still resolve the original name.
Toolchain utils have installed only `dev-lang/rust`. It could result
in version mismatch between `virtual/rust` and `dev-lang/rust`, because
`dev-lang/rust` does not automatically pull in `virtual/rust`.
So install `virtual/rust` instead of `dev-lang/rust`.
Install `virtual/rust` to avoid version conflicts that happen in case of
rust versions in the SDK being different from those in the new ebuilds.
`/usr/share/catalyst/targets/stage1/stage1-chroot.sh` installs gcc and
its dependencies, including `dev-lang/rust`, while `virtual/rust` does
not get updated. That results in version conflicts between
`virtual/rust` and `dev-lang/rust`. To avoid such an issue, we should
update also `virtual/rust` when building stage1. Since `virtual/rust`
automatically pulls in `dev-lang/rust`, we do not need to explicitly
specify `dev-lang/rust` here.
