Cease merging pmbootstrap.cfg into args, implement a Context type to let
us pull globals out of thin air (as an intermediate workaround) and rip
args out of a lot of the codebase.
This is just a first pass, after this we can split all the state that
leaked over into Context into types with narrower scopes (like a
BuildContext(), etc).
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Introduce a new module: pmb.core to contain explicitly typed pmbootstrap
API. The first component being Suffix and SuffixType. This explicitly
defines what suffixes are possible, future changes should aim to further
constrain this API (e.g. by validating against available device
codenames or architectures for buildroot suffixes).
Additionally, migrate the entire codebase over to using pathlib.Path.
This is a relatively new part of the Python standard library that uses a
more object oriented model for path handling. It also uses strong type
hinting and has other features that make it much cleaner and easier to
work with than pure f-strings. The Chroot class overloads the "/"
operator the same way the Path object does, allowing one to write paths
relative to a given chroot as:
builddir = chroot / "home/pmos/build"
The Chroot class also has a string representation ("native", or
"rootfs_valve-jupiter"), and a .path property for directly accessing the
absolute path (as a Path object).
The general idea here is to encapsulate common patterns into type hinted
code, and gradually reduce the amount of assumptions made around the
codebase so that future changes are easier to implement.
As the chroot suffixes are now part of the Chroot class, we also
implement validation for them, this encodes the rules on suffix naming
and will cause a runtime exception if a suffix doesn't follow the rules.
Instead of building cross packages for the native architecture, add a
new get_cross_packages_arches() function that returns the desired
architectures no matter what the current native architecture is.
So gcc-x86_64 will always have arch="aarch64", and gcc-aarch64 will
always have arch="x86_64".
We can tweak the function in the future if e.g. it becomes viable to
cross compile from riscv64. Or even better, remove this and the cross
compile packages upstreamed into alpine (see pmb#551).
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231126104823.3723-1-ollieparanoid@postmarketos.org%3E
abuild traces shared library dependencies for binaries in built
packages, and adds all of them to depends. This is needed for the cross
gcc builds, as otherwise it will not add the isl dependency (currently
isl25).
With the crossdirect compilation method we mount the cross-gcc from the
native chroot in the foreign arch chroot. Due to the missing dependency,
isl was not installed in the native chroot, and so when attempting to
use that native cross gcc from the foreign arch chroot, it would try to
load the foreign arch isl instead of the native one. Resulting in lots
of the following errors (and of course not a working gcc):
Error relocating /usr/lib/libisl.so.23: unsupported relocation type 1026
I had probably added '!tracedeps' because abuild complains about it
otherwise... but as noted in [1] these complaints are safe to ignore.
Keep !strip for now even though it's not in Alpine's APKBUILD. I've
tried to build without and the build fails with:
strip: Unable to recognise the format of the input file `./usr/aarch64-alpine-linux-musl/lib/libgcc_s.so.1'
[1]: 0415ebf6f9
Related: pmaports issue 1732
Add the subpackage, because g++-$arch depends on it since
12.1.1_git20220630-r6. This fix was already applied to pmaports, thanks
to ungeskriptet! Adjust the aportgen code to make sure this is added in
the future as well.
Related: pmaports MR 3464
Related: f1044b1dae
Do not build the foreign arch libgcc. We are using the one provided by
Alpine's binary repository instead, and when building it here and trying
to use it, we actually run into a conflict.
I tried setting BOOTSTRAP="nolibc" first since there is already logic to
then disable libgcc in the APKBUILD. But that also disables g++ which we
do want to build, so we can't use this.
Fixes: issue 2168
Remove it from depends, as the package has been removed in Alpine and
since quite some time we shouldn't have depended on it anyway.
Related: issue 2167
Replace "args.arch_native" with the direct function call in order to
avoid passing "args" to all functions. This is a step to get rid of this
args-passed-to-all-functions pattern in pmbootstrap.
Previously it always used native (x84_64) arch for apkindex
version check.
As pmb.aportgen.core.alpine_apkindex_path() already has arch
parameter, use it to look up correct APKINDEX.
Also fixup test.
Packages like binutils-*, busybox-static-*, gcc-*, grub-efi-*, musl-*
are only needed for the native architecture during cross compilation.
Don't bother with trying to build them for other arches to save time and
to avoid getting stuck frequently at "armv7/binutils-aarch64" etc.
A few people like to use pmbootstrap on aarch64 hosts (e.g. PineBook
Pro), so let's make it available for aarch64 again when we can build
aarch64 packages natively in CI and bpo. (They do get stuck there right
now, because of qemu user emulation.)
Related: https://gitlab.com/postmarketOS/build.postmarketos.org/-/issues/75
While at it, also remove unnecessary "#!/usr/bin/env python3" in files
that only get imported, and adjust other empty/comment lines in the
beginnings of the files for consistency.
This makes files easier to read, and makes the pmbootstrap codebase more
consistent with the build.postmarketos.org codebase.
Explicitly depend on mpc1. Our generated gcc aports use the !tracedeps
option, so we need to explicitly set the libraries it depends on.
This has mostly not been an issue, as we are installing our gcc
packages together with Alpine's gcc package, which causes the libraries
to get installed anyway.
Related: pmaports#236
This covers most use cases and saves a lot of build time. Can be
changed on demand. Again, this simplifies package building as part of
the new build infrastructure effort.
* aportgen: modify code to allow generating gcc6-armhf and other gcc6
cross compiler packages
* package: when 'gcc6' is in the depends of a package, and the cross
compiling mode is "native" (as we do it with kernels), install the
gcc6 cross compiler instead of the usual one (gcc8)
Related: pmaports#103
Due to changes in abuild, our `gcc-armhf` etc. packages did not build
when using strict mode (i.e. `pmbootstrap build --strict gcc-armhf`)
anymore.
Changes:
* Set `CBUILDDIR=/`, so apk can read a valid package index from there
* Directly set `_cross_configure`, so it does not use CBUILDDIR anymore
* Set `BOOTSTRAP="nobuildbase"` to prevent apk from installing
`build-base-armhf` etc. (these don't exist in pmOS)
* Remove legacy code for lazy reproducible builds that wrapped
`package()`
In order to get cross-compilers, we generate a few aports (e.g.
binutils-armhf, gcc-armhf) automatically from Alpine's aports.
pmbootstrap was already able to perform a git checkout of Alpine's
aports repository. But it needed to be manually updated. Otherwise
the `pmbootstrap aportgen` command could actually downgrade the aport
instead of updating it to the current version.
After thinking about adding a dedicated pmbootstrap command for
updating git repositories, I thought it would be better to not open
that can of worms (pmbootstrap as general git wrapper? no thanks).
The solution implemented here compares the upstream aport version of
the git checkout of a certain package (e.g. gcc for gcc-armhf) with the
version in Alpine's binary package APKINDEX. When the aport version is
lower than the binary package version, it shows the user how to update
the git repository with just one command:
pmbootstrap chroot --add=git --user -- \
git -C /mnt/pmbootstrap-git/aports_upstream pull
Changes:
* `pmb.aportgen.core.get_upstream_aport()`: new function, that returns
the absolute path to the upstream aport on disk, after checking the
version of the aport against the binary package.
* Use that new function in pmb.aportgen.gcc and pmb.aportgen.binutils
* New function `pmb.helpers.repo.alpine_apkindex_path()`: updates the
APKINDEX if necessary and returns the absolute path to the APKINDEX.
This code was basically present already, but not as function, so now
we have a bit less overhead there.
* `pmbootstrap chroot`: new `--user` argument
* `pmb.parse.apkbuild`: make pkgname check optional, as it fails with
the official gcc APKBUILD before we modify it (the current APKBUILD
parser is not meant to be perfect, as this would require a full shell
parsing implementation).
* Extended `test_aportgen.py` and enabled it by default in
`testcases_fast.sh`. Previously it was disabled due to traffic
concerns (cloning the aports repo, but then again we do a full KDE
plasma mobile installation in Travis now, so that shouldn't matter
too much).
* `testcases_fast.sh`: With "test_aport_in_sync_with_git" removed
from the disabled-by-default list (left over from timestamp based
rebuilds), there were no more test cases disabled by default. I've
changed it, so now the qemu_running_processes test case is disabled,
and added an `--all` parameter to the script to disable no test
cases. Travis runs with the `--all` parameter while it's useful to
do a quick local test without `--all` in roughly 2 minutes instead of
10.
* `aports/cross/binutils-*`: Fix `_mirror` variable to point to current
default Alpine mirror (so the aportgen testcase runs through).
Example: Building gcc-armhf for armhf does not make sense, so this
commit changes arch="all" to arch="aarch64 x86_64". This helps to
simplify the repository scripts (#970).
* pmbootstrap init: Generate new port device- and linux-package
* adds `pmbootstrap aportgen device-*` and
`pmbootstrap aportgen linux-*`
* ask for confirmation when selecting a non-existing device
* generate the packages directly from init
* refactor aportgen code
* fixed some easy things in the linux- APKBUILD (more to come in
follow-up PRs!)
Testing:
* Test all questions to the user from pmb.config.init and pmb.aportgen.device
(except for the timezone question, because we would need to monkeypatch the
os.path.exists() function, which messes up pytest, so we'd need to refactor
the timezone function to be more testsuite friendly first)
* Run the device wizard in a testcase a few times and check the output, that
pmbootstrap.aportgen.device and pmbootstrap.aportgen.linux create by parsing
the resulting APKBUILDs and deviceinfo and checking its contents.
* Build the generated device package once in the same testcase
Thanks a lot to @drebrez for all the help with this one:
<https://github.com/postmarketOS/pmbootstrap/pull/821>
See also the updated porting guide:
<https://wiki.postmarketos.org/wiki/Porting_to_a_new_device>
This fixes https://github.com/postmarketOS/binary-package-repo/issues/1
GCC generates hardlinks between files `A` and `B` in its `make install` step. The problem is, that `tar` randomly packages `A` as full binary, and links `B` to `A`, or the other way around! I was able to reproduce this issue consistently when re-building `gcc-aarch64` on Travis CI (interestingly, this did not appear for `gcc-armhf`).
The fix is, to delete `B` and create a symlink `B` that points to `A` instead.
libstdc++.a from gcc-armhf was not reproducible on Travis (it was, when built locally!). These .a files are just archives of object files .o, and in this case it was caused by a random order of the .o files in the archive.
This PR patches the package() function of the APKBUILD when running pmbootstrap aportgen gcc-armhf (same for aarch64 of course), to extract all .a files, and repack them to be reproducible (by sorting the files before packing them).
As usually, we can still inherit everything from the upstream gcc aport from Alpine, and apply our changes on top of that.
Travis without the patch:
https://api.travis-ci.org/jobs/260402679/log.txt?deansi=true
> CHALLENGE FAILED for usr/armv6-alpine-linux-muslgnueabihf/lib/libstdc++.a:File 'usr/armv6-alpine-linux-muslgnueabihf/lib/libstdc++.a' is different!
Travis with the patch (I've instructed Travis to run off this branch to test it):
https://api.travis-ci.org/jobs/260806203/log.txt?deansi=true
> Done. Your build exited with 0.
100% tested. Assuming that you don't need to test an obvious change,
because it only changes one line is dangerous. I will learn from this,
sorry for the inconvenience.
`gcc-armhf` compiles fine again with that change, and it is able to
cross-compile packages as it used to.
