Try to do it with in a proper Gentoo way - with PYTHON_TARGETS and
PYTHON_SINGLE_TARGET variables in make.defaults. Still need to disable
all other versions of python, otherwise our settings gets merged with
settings from base Gentoo profiles, which currently enable python 3.13.
We are not bumping to 3.13, because sec-policy/selinux-base
PYTHON_COMPAT is still on at most 3.12.
Note that this change still allows python 3.11 in PYTHON_TARGETS for a
transition period. Otherwise the SDK builds do not go past stage1.
Signed-off-by: Krzesimir Nowak <knowak@microsoft.com>
I have submitted a PR upstream so that they can automatically create a
vendor tarball with each release. In the meantime, I have hosted one in
my Gentoo dev space.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Setting an absolute list was preventing newer options from being
enabled, leading to this scary error message from newer clients.
$ ssh flatcar
Warning: Permanently added '[127.0.0.1]:2222' (ED25519) to the list of known hosts.
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
Last login: Wed Oct 15 10:05:46 UTC 2025 from 10.0.2.2 on pts/0
Flatcar Container Linux by Kinvolk beta 4426.1.0 for QEMU
After going through each of the options, the only ones we were adding
above the current 10.2p1 defaults were the diffie-hellman-group KEX
algorithms. These were dropped upstream in 2024 because they are slower
while providing no benefit over other options. The continued presence of
ecdh-sha2-nistp256 ensures compatibility with default clients at least
as far back as 2016.
I think we should just continue to follow the upstream defaults unless
some significant client breakage is reported. They're usually quite
forgiving.
The order of these is significant, and our order did differ from
upstream's slightly, but I trust their order over ours.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
It's essentially a standalone userspace project that happens to live
within the kernel sources. It should not be built like the kernel.
hv_fcopy_daemon was dropped upstream.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
Having too many variables is confusing, so use the ones already provided
by upstream. linux-info.eclass uses KERNEL_DIR (if set) as the kernel
sources directory and sets KV_DIR to that for use elsewhere. If
KERNEL_DIR is unset, it checks the /usr/src/linux symlink. While we
could rely on the symlink, we want to be sure that coreos-modules and
coreos-kernel are built against the matching kernel version.
KV_OUT_DIR is the kernel output directory. It is automatically set by
linux-info.eclass, and it will never leave it empty.
Signed-off-by: James Le Cuirot <jlecuirot@microsoft.com>
