The tool is deprecated, nothing pulls that in any more and it has a
dependency on dev-perl/XML-Parser, an updated version of which would
want to pull a bunch of new packages through dev-perl/libwww-perl.
Avoid the hassle and drop the tool.
Realmd didn't have dev-util/intltool listed as a dependency, but it
actually required it during build. Apply a patch from upstream that
converts the project from intltool to gettext in order to get rid of
the dependency on the obsolete tool. To apply the patch without
conflicts, apply also another patch from upstream that modernizes the
configure.ac file.
We also disable the i18n through the --disable-nls flag. The disabling
is not complete though, so we still need to point gettext to the ITS
rules we have installed in ROOT.
Our github actions use cork to create an sdk chroot, which pulls down bzipped
archives. The runners have 2 CPUs, so this unpacking could be faster if we
installed lbzip2. Cork transparently uses lbzip2.
The size contains not only of the /usr partition but also the /boot
partition require that we reduce the size of binaries as much as
possible.
Strip all Go binaries by default.
This usually doesn't happen for releases, but for development
dev-containers it might be the case that portage-stable or
coreos-overlay commit is specified as some pull request reference -
these need to be fetched differently, as refs from refs/pull usually
are not fetched by default.
- sys-libs/pam: Make /sbin/unix_chkpwd suid
This is to avoid importing fcaps eclass which adds a dependency on
sys-libs/libcap, which in turn depends on sys-libs/pam. To get out of
this conundrum, we could specify a "-filecaps" use flag for
sys-libs/pam. Problem with this solution would be no capability
override for the binary making it unable to read /etc/shadow. Thus we
make the binary suid. This is strictly less secure than overriding its
capabilities, but I have no idea how to solve it in a less hacky way.
- sys-libs/pam: Install configuration into /usr
Also provide a tmpfiles fragment to bring it back.
- sys-libs/pam: Locked accounts functionality
Signed-off-by: Sayan Chowdhury <schowdhury@microsoft.com>
As sys-apps/shadow has its own su binary, sys-apps/util-linux should
not have its own su binary. Otherwise, build will simply fail.
Disable su USE flag for util-linux.
The lib64/systemd location only happened to work through the used
symlink on Flatcar. The standard location is lib/systemd.
Use the standard location as we now want to split the libs folders.
The split of /usr/lib64 into /usr/lib and /usr/lib64 means that paths
to /usr/lib64/X that worked before now wouldn't.
Therefore, create compatibility symlinks.
The profile Flatcar is on had SYMLINK_LIB set for amd64 which set up
(/usr)/lib as symlink to (/usr)/lib64. This is not the case for arm64
nor common in other recent distributions and causes systemd-sysext
loading to fail.
Disable SYMLINK_LIB for the amd64 board for now, leaving the SDK as is
but we could also set it for the SDK, too. A future profile update will
also bring this change.
The /lib symlink does not point to /usr/lib but instead points to
/usr/lib64 on current releases which have a single /usr/lib64 folder
and a symlink from /usr/lib to it. This means that when they update to
a release with a split lib vs. lib64 setup, the kernel modules are not
found because /lib/modules does not exist (because /lib still points
to /usr/lib64 instead of /usr/lib).
Force link recreation to match the new layout. The system will still be
able to rollback because the link to /usr/lib is still valid because
/usr/lib is itself a link that forwards to /usr/lib64.