The SDK now includes a Rust version with the aarch64 cross-compilation
libraries and the toolchain job doesn't build it anymore. Yet it was
still recompiled because the path had changed.
Remove the adjustment of the download URL and any automatic building
of Rust. Just issue a warning so that any problem can be spotted easily.
This change does not affect the SDK bootstrapping (full or just stage4)
but affects ./build_packages and the toolchains job. For the toolchains
job the crossdev setup is missing anyway and rebuilding wouldn't help
but only downloading, yet since in stage4 there are no binary package
URLs at all, it's best to remove this step and if it is needed later,
the warning will help.
The folder /var/log/journal/remote used to be part of the inital rootfs
through a keepdir directive in the build. However, any paths except
/usr are ephemeral and can be deleted at any time and should be recreated
with tmpfile directives. When upstream Gentoo removed the line
"keepdir /var/log/journal/remote" our tests started to fail but in fact
they could have failed earlier if they had tested with Ignition creating
a new root filesystem which lacks the /var/log/journal/remote folder.
Add a directive to create /var/log/journal/remote at runtime in any case.
app-misc/ca-certificates|sys-apps/baselayout: Run flatcar-tmpfiles|clean-ca-certificates only once, sys-fs/lvm2: Run lvm2-activation(-early).service only once
Increase the revision and apply a new lvm2-2.02.145-oneshot.patch:
The lvm2-activation(-early).service was triggered multiple times which
if done too quickly leads to a failure like this:
systemd[1]: Finished Activation of LVM2 logical volumes.
systemd[1]: lvm2-activation-early.service: Start request repeated too quickly.
systemd[1]: lvm2-activation-early.service: Failed with result 'start-limit-hit'.
Set RemainAfterExit=yes as done for the other oneshot services to
prevent the unit from running multiple times in a row and hitting the
restart limit.
The patch was sent to upstream lvm-devel@redhat.com
The flatcar-tmpfiles and clean-ca-certificates services were run
many times and finally failed to run because they were spawned too
often during the allowed time period.
Mark them as active after they ran once. Also ensure that when they
run all mounts are ready.
Pulls in https://github.com/flatcar-linux/baselayout/pull/4
pkg-config 0.29 or newer introduced a macro `PKG_CHECK_MODULES_STATIC`,
which is needed by ebuilds like dev-util/strace >= 5.5.
So we should update pkg-config to 0.29.2, to avoid such issues.
(see 0efb668bd5)
```
***** autoconf *****
***** PWD: /build/amd64-usr/var/tmp/portage/dev-util/strace-5.6/work/strace-5.6
***** autoconf --force -I /build/amd64-usr/usr/share/aclocal
configure:17585: error: possibly undefined macro: PKG_CHECK_MODULES_STATIC
```
The baselayout ebuild file calls systemd-tmpfiles but despite that
the systemd ebuild file depends on libidn2 through a use flag, it was
not built early enough.
Ensure that libidn2 is built before baselayout wants to use it.
The metadata/md5-cache is not required and we stop using it because
this machine-generated content is a common cause for merge conflicts
and has no benefits.
The default update seed command does only specify gcc which leads to
an error because »The short ebuild name "gcc" is ambiguous«.
Choose the standard package name instead of the cross compiler packages
which are only known to emerge because we build them as part of an SDK
release now.
The metadata/md5-cache folder is machine-generated based on the
other files in the repository. It causes merge conflicts when at
one time they were not regernated in a commit and then later a
commit does it and includes cache changes which are incompatible
with later or newer states.
Remove the folder as it is not necessary to have it and was removed
in upstream Gentoo, too.
The metadata/md5-cache folder is machine-generated based on the
other files in the repository. It causes merge conflicts when at
one time they were not regernated in a commit and then later a
commit does it and includes cache changes which are incompatible
with later or newer states.
Remove the folder as it is not necessary to have it and was removed
in upstream Gentoo, too.
The new main branch is the only branch that should get new software
updates with the exception of the maintenance branches that get kernel
updates.
Only target the main branch with GitHub Actions until we add discovery
for all active channel maintenance branches.
Whenever a new upstream Rust release appears, a Github workflow in
`coreos-overlay` creates a new pull request for `dev-lang/rust`.
At the same time, it sends a repository dispatch event to
portage-stable, so it also creates a pull request for `virtual/rust`.
So far Github actions have not changed existing `COMMIT_ID` variable in
runc ebuilds. As a result, the result PRs have correct versions with wrong
commit hashes.
We need to replace `COMMIT_ID` with one that matches with the new version.
To do that, clone the repo completely, since it is not possible to get
the commit hash by running `git rev-parse` on a shallow cloned repo.
Parse commit from a tag with an original version with `-` as its
delimiter, e.g. `v1.0.0-rc91`, because a transformed
tag like `v1.0.0_rc91` does not exist in the upstream repo.
We need to update rust versions also in multiple files in profiles,
e.g. `package.accept_keywords`. Otherwise `emerge rust` will fail,
due to mismatches between rust versions, in profiles and the actual
ebuilds.
docker-runc ebuild has lines of runc versions with not only underscore
(`_`) but also hyphen (`-`). So when we replace the runc version, we
need to also care about versions with hyphen, for example, `1.0.0-rc10`.
`exit` command will simply fail the whole script, so it would not be
possible to check for status of `checkout_branches`. Instead, we need to
use `return` for the error checks.
In case the target branch already exists, `checkout_branch()` needs to
simply `exit 0`, so the subsequent steps could be skipped.
In that case, it has to set `UPDATE_NEEDED` to 0, so the Github action
could avoiding creating another PR.
It resolves occasional issues that happen when subsequent PRs overwrite
existing open PRs made on the very same version. It would be no problem
if there was no change in the PR. However, if there was any manual
change in the previous open PR, the change will be simply overwritten.
That would be very unfortunate.
When checking out into a branch name, append `-${CHANNEL}` to the name,
so the branch can be distinguished from each other. To do that, make
every Github actions yaml file pass in its corresponding `CHANNEL`
variable.
We do not need to specify each version from each workflow yaml file.
Make *-apply.patch scripts instead generate `$VERSION_SHORT` from the
input version value.
We do not need to specify a cork version from each Github action.
Simply detect the latest version in `setup-flatcar-sdk.sh`, before
downloading cork binary file from Github.
Also remove the env variable for cork version from each Github action.
To get containerd in sync with upstream, we need to schedule weekly
Github actions. It runs on Friday every week, only for Alpha and Edge.
Similar to those for Docker, we need to deal with torcx ebuilds as well,
as they contain containerd versions.
