The mirror-calico workflow has been failing because it currently determines
version=v3.22.0-0.dev-typha, which is not the tag used by the individual
container images. Rewrite the version logic to determine the version based on
what is in the tigera operator manifest. This is the same manifest that we use
to deploy calico in mantle.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
The entries added in changelog/security/ do not follow our existing
security section in the release notes:
https://www.flatcar.org/releases/#release-3033.2.0
Document the structure and an example to use the right format that we
need for release note generation.
The entries added in changelog/security/ do not follow our existing
security section in the release notes:
https://www.flatcar.org/releases/#release-3033.2.0
Document the structure and an example to use the right format that we
need for release note generation.
The entries added in changelog/security/ do not follow our existing
security section in the release notes:
https://www.flatcar.org/releases/#release-3033.2.0
Document the structure and an example to use the right format that we
need for release note generation.
The net-misc/iputils package never provided the traceroute binary,
only traceroute6, which is probably why the use flag got renamed to
traceroute6 too.
The default image group is already encoded in
/usr/share/flatcar/update.conf but it was written to
/etc/flatcar/update.conf as well. This can cause problems when the user
switches channels by forcing an update to a specific release from the
different channel (e.g., through the flatcar-update tool) as it leaves
the file under /etc/flatcar/update.conf out of sync with the new
channel version in /usr/share/flatcar/update.conf.
Since we don't really need to write a specific channel to /etc on new
images as we can rely on the value from /usr, we now leave any possible
overwriting of the value in /etc entirely to the user.
It was removed from Gentoo and with updated profiles, the build
started to fail with:
USE flag 'elibc_uclibc' referenced in conditional 'elibc_uclibc?' is
not in IUSE
Since the update of dev-python/certifi, running the command
`./image_to_vm.sh --format gce --board=amd64-usr` fails due to a
dangling symlink. This symlink is located in
/usr/lib64/python3.9/site-packages and is not supposed to be installed
in the first place because of this INSTALL_MASK entry in
coreos-overlay/profiles/coreos/targets/generic/oem-aci/make.defaults:
INSTALL_MASK="${INSTALL_MASK}
/usr/*/python3*
"
There is an open upstream bug that INSTALL_MASK doesn't work correctly on
symlinks (https://bugs.gentoo.org/678462).
The best we can do at this time is to ignore the dangling symlink.
Signed-off-by: Jeremi Piotrowski <jpiotrowski@microsoft.com>
The original intention of the "binpkg" prefix in the CI binary package
cache URL was to separate packages from other build artifacts like
containers, images, and SDK tarballs. Motivation was to separate
developer content (binary packages) from CI automation artifacts
(everything else); since binary packages are not used by the CI.
This broke assumptions in scripts which use the binary host URL for
other things than packages - e.g. SDK tarballs or images. These
scripts would get a bincache URL with "binpkg/" prepended, while CI
automation would *not* use that prefix.
This change removes the use of "binpkg/" altogether since it would not
work as intended without more significant changes to build scripts.
