As gdb 11 or newer requires gmp libs as dependency, a cross build of
gdb 11.2 started to fail when its configure scripts try to detect if
gmp exists. The failure occurs mainly because the build still passes
'-L/usr/lib64` to LDFLAGS. Let's say, for example, host toolchains
outside of sysroot have amd64 libs, while the target inside of
sysroot should have arm64 libs. However, configure scripts of gdb 11.2
still try to find its libs outside of sysroot, /usr/lib64, although it
should find its libs inside of sysroot, e.g. /build/arm64/usr/lib64.
To fix the cross build issues, pass --with-sysroot as well as --libdir,
correctly with ${ESYSROOT}.
As a side note, for some reason, upstream gdb configure scripts are not
able to correctly make use of its gmp-specific options like --with-gmp
or --with-gmp-lib. Passing those options does not bring anything.
Also configure must have both --with-sysroot and --libdir, to make the
build work.
To fix build issues that happen in adcli 0.9 with glibc 2.34, we should
sync adcli with upstream Gentoo, where the build issue is already fixed.
As Gentoo has the ebuild under the category `app-crypt`, we simply move
from adcli from coreos-overlay to portage-stable, move adcli to the
app-crypt category, and update the version to 0.9.1-r2.
To fix build issues that happen in adcli 0.9 with glibc 2.34, we should
sync adcli with upstream Gentoo, where the build issue is already fixed.
As Gentoo has the ebuild under the category `app-crypt`, we simply move
from adcli from coreos-overlay to portage-stable, move adcli to the
app-crypt category, and update the version to 0.9.1-r2.
`docker.service` has a dependency to `containerd.service`:
```
$ systemctl list-dependencies docker.service
docker.service
containerd.service
...
```
If `docker.service` is not started (explicitly or via socket activation)
`containerd.service` won't start.
To ensure a seamless transition to kubernetes-1.24 let's enable by
default `containerd.service`.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
We add `sys-apps/ignition` as a `coreos-base/coreos` dependency to get
`/usr/libexec/ignition-rmcfg` available on the _real_ root.
Now we want `/usr/bin/ignition` to be in the chroot until it's being copied
to the initramfs but we don't want it on the actual root.
With `PKG_INSTALL_MASK`, we'll prevent `/usr/bin/ignition` to be added
to the image in the `./build_image` - at this time, initramfs is already
created and `sys-apps/ignition` is a binary package.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
this helper removes config from VMWare and Virtualbox and should not be
directly used by the user.
Signed-off-by: Mathieu Tortuyaux <mtortuyaux@microsoft.com>
