This is to make sure that the directory layout wrt. lib directories in
stage1 is correctly set up from the beginning, because it gets
propagated all the way to the final SDK image. It's easier to do it
that way, rather than following the steps described in the deprecation
notice of the 17.0 profile.
Pull in a new version of baselayout to have a proper setup of lib
directories in stage1. The proper setup means that the `lib` entry is
now a directory instead of a symlink to `lib64`.
Honestly, when rewording this commit, I realized that this hook is not
really needed, as the updated baselayout ebuild just drops code that
became dead after the profile update that the other hook does. But I
decided to keep it as is, because the CI build with this hook has
passed, and this hook will be needed anyway by the weekly updates.
We have moved away from it already in production images already. With
the change of profile from 17.0 to 17.1, SYMLINK_LIB is always "no",
so some code will never be executed. Drop it.
Elfutils is already part of the usr partition, but currently not enabled in
systemd-coredump. Systemd-coredump therefore fails with:
elfutils disabled, parsing ELF objects not supported.
Enable the elfutils flag for systemd to make this work.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
- install curl before baselayout
Now that Github rejects access to an unauthenticated URL with
`git://`, we have to make git and libcurl work with
`https://`. However, during the SDK stage2, curl is not explicitly
installed, but just inherited from the stage1. As a result, curl is
built without the `ssl` USE flag. So installation of baselayout
fails with:
```
git fetch https://github.com/flatcar-linux/baselayout.git --prune +HEAD:refs/git-r3/HEAD
fatal: unable to access 'https://github.com/flatcar-linux/baselayout.git/':
Protocol "https" not supported or disabled in libcurl
```
To resolve the issue, we need to install curl with `BOOTSTRAP_USE=ssl`
before trying to install baselayout.
- update openssl before stage3
Right now our bootstrap flow is different then gentoo's - we don't
update the seed when building stage1 and use a different ebuilds
snapshot for stage1 compared to stage2 and stage3. This is causing
us trouble now, because we introduced openssl-3, but seed/stage1
still contains openssl-1.1. During `emerge -e @system` in stage3,
some packages that depend on openssl may build against the stage1
version, which results in an error during depcleaning (they would
need to be rebuilt instead). Stage3 is not extensible, so instead,
explicitly update openssl in stage2. This workaround can be removed
as soon as we release a seed with openssl-3.
Co-authored-by: Dongsu Park <dpark@linux.microsoft.com>
Co-authored-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
Co-authored-by: Krzesimir Nowak <knowak@microsoft.com>
