The dev build SDKs are not in $FLATCAR_DEV_BUILDS/sdk but published under
$FLATCAR_DEV_BUILDS/developer/sdk.
Add an environment variable to specify where the SDK is to be found
but default to $FLATCAR_DEV_BUILDS/sdk if it is not specified.
From Jenkins this variable is exported as DOWNLOAD_ROOT_SDK.
The Rust arm64 crossdev toolchain package was uploaded to
toolchain-arm64/rust… instead of toolchain-arm64/dev-lang/rust….
Upload the complete dev-lang folder as only Rust will be fetched
from there anyway.
When the ebuild file changed but not its version nor its cross-workon
commit, the binary package would be used. Also some dependencies are not
encoded to trigger a rebuild of depending packages.
Allow to exclude some binary packages so that we can be sure that they
are rebuilt.
Two Flatcar versions were used in /etc/portage/make.conf both in the SDK
and in the boards.
Use only a single version by default to get the expected results and not
something else when using binary packages.
The Rust crossdev package was never uploaded to /sdk/ and always
had to be compiled again.
Upload it in a separate toolchain-arm64 directory because /Packages in /crossdev/
doesn't refer to the Rust package and its use flags.
This commit adds the wireguard module patch through the
wireguard-linux-compat repo. This also adds the wireguard-tools, the
userspace tool for wireguard
Signed-off-by: Sayan Chowdhury <sayan@kinvolk.io>
The BINHOST was still configured to be the CoreOS CL upstream location
which does not work for independent Flatcar CL releases. This broke
binary package installation in the development container.
Use the correct BINHOST to fix installation of binary packages in the
development container.
The user can only login via SSH if no password was set and can't login
over the serial console in the web UI. To login, the user needs to press
reboot and then append flatcar.autologin to the kernel command line parameters
in GRUB each time. The user may also not know that this option even exists.
Set flatcar.autologin by default in the kernel command line parameters for
Azure so that users don't need to set this themselves.
`dev-lang/rust` has been moved to coreos-overlay since a long time.
However, we have still kept `dev-lang/rust` in portage-stable as well.
As it is not needed at all, let's simply remove it.
Since strace 5.3 or newer is not enabled for `amd64` and `arm64` by
default, we need to add keywords `~amd64` and `~arm64` for newer
versions of strace.
Update strace to 5.6, to make it compatible with recent Kernels.
It does not include a third-party patch `strace-5.5-static.patch`,
which could cause build failures with pkgconfig <= 2.28.
We updated `virtual/rust` to 1.41.1, but have not done so for
`dev-lang/rust`, which remains as 1.36.0. Such a mismatch prevents
the whole build to fail.
For now, let's revert `virtual/rust` back to 1.36.0.
Since `virtual/cargo` does not exist in the recent Rust ebuilds,
dependency on the missing package `virtual/cargo` caused build issues
in the SDK. So we should make it depend on `virtual/rust` to fix the
build issues.
Now that `cross-{x86_64,aarch64}-cros-linux-gnu/gdb` was updated to 9.1,
it needs exactly one of `python_single_target_python3_6` and
`python_single_target_python3_7`. Since python 3.7 is not available yet,
we need to enable 3.6 and disable 3.7, for the SDK profile.
Without the fix, toolchain builds will fail like that:
```
!!! The ebuild selected to satisfy "cross-aarch64-cros-linux-gnu/gdb"
has unmet requirements.
- cross-aarch64-cros-linux-gnu/gdb-9.1-r1::x-crossdev USE="client nls python server -lzma -multitarget -source-highlight -test -vanilla -xml -xxhash"
PYTHON_SINGLE_TARGET="-python3_6 (-python3_7)" PYTHON_TARGETS="python3_6 (-python3_7)"
The following REQUIRED_USE flag constraints are unsatisfied:
python? ( exactly-one-of ( python_single_target_python3_6 python_single_target_python3_7 ) )
The above constraints are a subset of the following complete expression:
python? ( exactly-one-of ( python_single_target_python3_6 python_single_target_python3_7 )
python_single_target_python3_6? ( python_targets_python3_6)
python_single_target_python3_7? ( python_targets_python3_7 ) ) any-of ( client server )
```
