* always use http for apt repos
* pass possible proxy arguments to docker
* populate lower-case env variables with upper-case ones if not set otherwise
Use all parameters to display_alert()
```
[🐳|🌱] Running in container [ Adding provisions for container building ]
[🐳|🌱] Adding package to 'host_dependencies' [ python3-setuptools ]
[🐳|🌱] Python2 not available on host release 'noble' [ ancient u-boot versions might/will fail to build ]
```
- aimed at nanopi-r2s and nanopineo3
- impacts:
- boards (re)using 'nanopi-r2s-rk3328_defconfig' (rk3328)
and:
- boards using U-Boot v2022.04 or
- boards using U-Boot v2022.07
- added explicit dependency on python3-setuptools as (at least) U-Boot
v2022.04 and v2022.07 fail building due to missing 'distutils' for
boards that use U-Boot v2022.04 or v2022.07
- 7s+ -> 3s
- by using `enable_extensions_with_hostdeps_builtin_and_user "add_host_dependencies" "host_dependencies_known"` instead of `enable_all_extensions_builtin_and_user`
I don't know. This doesn't feel right. The package exists in Jammy, Noble and Bookworm in both amd64 and arm64 variants so should be good...though it is probably not needed in all constellations.
Still it is part of the toolchain and not generic packages. If this gets merged as it is this should be revisited.
- python3-pip implies a very old setuptools (which is system-wide and takes precedence)
- python3-dev implies python3-distutils (which is long deprecated)
- get-pip.py allows us to version pip in requirements.txt just like everything else
- in the end this fixes the conundrum with pylibfdt / dtschema on Jammy
- and, finally, the setuptools we specify in requirements.txt will be actually used
- refactor `prepare_host_binfmt_qemu()` out of `prepare_host_noninteractive()` and into `rootfs/qemu-static.sh`
- further split into more functions and return early to avoid deep nesting
- implement force import and load of qemu-arm for non-armhf capable arm64 hosts (incl magic numbers)
- enhance `deploy_qemu_binary_to_chroot()` & `undeploy_qemu_binary_from_chroot()`;
- add 2nd param "caller" for better logging/tracking
- does sanity-check and preserve existing binary if it exists
- explicitly deploy/undeploy for the 3 cases:
- image: moved undeploy from `post_debootstrap_tweaks()` into image build proper for consistency
- rootfs: was leaving trash behind (since post_debootstrap_tweaks never ran for rootfs), now properly undeploys
- initrd: was already fine, just added caller info
- added `arch-test` host dependency
- ensure `arch-test ${ARCH}` works during prepare-host
- > tl,dr: "can build 32-bit armv7 armhf using Apple silicon; can use rootfs cache cross-arch reliably"
Instead of having to add every new release to the list that does not support python2, inverse this if statement and only check if the build host is Debian bullseye or ubuntu jammy. Every release newer than those do not have python2. Older build hosts are unsupported.
Different build hosts have vastly different versions of setuptools and pyelftools depending on the host OS, e.g. Ubuntu 22.04 has setuptools v59 while the latest version at the time of this commit is setuptools v71.
Using Pip instead of APT to download these packages assures that all build hosts use the same version, removing some points of failures and inconsistencies.
doas is not compatible with sudo flags. The codebase was checked for
sudo-specific uses of this function, but none were found, all cases were
in the form of `sudo <command>`. Replacing it with `doas <command>`
yields the same result.
doas is not compatible with sudo flags. The codebase was checked for
sudo-specific uses of this function, but none were found, all cases were
in the form of `sudo <command>`. Replacing it with `doas <command>`
yields the same result.
This fixes the readability of colorized output of compile.sh when
running on a terminal with a light background. It uses the COLORFGBG
environment variable similarly to how the ip(8) command does.
Signed-off-by: Darsey Litzenberger <dlitz@dlitz.net>
