To be able to distinguish changelog entries from each other, we should
write a specific project name, e.g. portage-stable, instead of `PR`.
Changelog entries with a simple `PR` usually cause so much additional
rework when doing actual releases.
To be able to distinguish changelog entries from each other, we should
write a specific project name, e.g. scripts, instead of `PR`.
Changelog entries with a simple `PR` usually cause so much additional
rework when doing actual releases.
To be able to distinguish changelog entries from each other, we should
write a specific project name, e.g. coreos-overlay, instead of `PR`.
Changelog entries with a simple `PR` usually cause so much additional
rework when doing actual releases.
This change temporarily disables the Gentoo sandbox when updating the
SDK to work around sandbox permission errors some pakage builds (like
e.g. GO) run into.
Fixes e.g.
```
Building Go cmd/dist using /usr/lib/go-bootstrap. (go1.5.3 linux/amd64)
* /var/tmp/portage/sys-apps/sandbox-2.12/work/sandbox-2.12/libsandbox/trace.c:do_peekstr():125: failure (Operation not permitted):
* ISE:do_peekstr:process_vm_readv(6863, 0x00007ffe4a502180{0x00007f01abd3e010, 0x570}, 1, 0x00007ffe4a502190{0x000000c820012a90, 0x570}, 1, 0) failed: Operation not permitted
* ERROR: dev-lang/go-1.17.8::coreos failed (compile phase):
```
Signed-off-by: Thilo Fromm <thilo@kinvolk.io>
Update net-misc/rsync to v3.2.4-r1, mainly to address CVE-2018-25032.
The CVE is actually a zlib issue, but we need to update rsync and its
bundled zlib as well, because the USE flag `system-zlib` is disabled
in Flatcar.
With the limit of 2 parallel tests, meaning 6 machines, the test time
is ~10 hours which is longer than the GC time. It seems that the
regional capacity is not so limited at the moment and we can try to
increase the number of machines.
Adjust the timeout to reflect the GC time and increase the parallel
tests to 3, meaning 9 machines.
The GitHub Actions were defined for the LTS stream directly but we can
now follow the approach used for the other channels. This means that
in the future we could decide to create new Actions for 2022 by copying
the current one and modifying it when 2023 gets the new current LTS -
anyway some manual work would be required to set up Actions for both
old and new at the same time (we have no "previous" symlink on Origin).
We could retire the old LTS Actions immediately because the releases
don't occur on a fixed schedule but I think the automation is nice to
keep.
