We currently always build kernel packages for the primary channel, which
will usually be systemd-edge. This will cause sideload to fail since it
correctly only looks in the edge repo.
Update envkernel to get the proper channel name and put the kernel
there, so they will always be in the local edge repo and not the
systemd-edge one.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2572
* Make CrossCompile a proper enum type rather than a string literal,
* Introduce methods to get the correct host/build chroots depending on the
cross compile type and target architecture.
* Remove autodetect.chroot() since it doesn't do what we expect, adjust
all users to use cross.build_chroot() instead.
* Refactor package building to correctly use cross.host_chroot() and
cross.build_chroot().
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Part-of: https://gitlab.postmarketos.org/postmarketOS/pmbootstrap/-/merge_requests/2568
Set things up so that we can run abuild on the native chroot and use
it's cross compilation features rather than running it and the build
system through QEMU. This massively speeds up building when it works.
cross-native used to be quite limited in functionality and didn't
integrate into abuild itself, this commit fixes that.
Packages can opt-in to this by adding pmb:cross-native2 to their options
and configuring makedepends_host and makedepends_build.
This also speeds up building packages like postmarketos-initramfs since
it entirely avoids running commands through QEMU (usually abuild itself
would be run through QEMU).
Lastly, we preserve the old pmb:cross-kernel options, this can be used to
enable the old cross compiler behaviour which is used for cross
compiling kernels in pmaports. This allows them to keep being supporting
while we adapt them to the new cross-native2.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
the kernel has pending patches in -next which adjust the generated
Makefile in the output directory to include the source tree makefile
with an absolute path, this breaks envkernel which relies on it being a
relative path.
Fix this by mounting our own Makefile instead using the relative path.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
recent changes to the kernels build infra in -next seem to have exposed
some issues with "pmbootstrap build --envkernel", specifically in the
case where the APKBUILD doesn't build out-of-tree.
We used to rely on the fact that the kernel output directory contains a
Makefile which points to the source directory, however this Makefile
now(?) contains an absolute path on the host, which won't match what's
in the chroot.
As a result, it's now necessary to build with the same output directory
as the APKBUILD.
We probably need some smarter code here... and/or more consistent
APKBUILDs.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
To support multiple aports we changed how we configure
/home/pmos/packages in the buildroot so it now points to whichever local
binary repo makes sense for the package being built.
Copy over the code to envkernel run_abuild() so the packages actually
get installed to $WORK/packages
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Move pmb/parse/arch.py over to core and refactor it as an Arch type,
similar to how Chroot was done. Fix all the uses (that I can find) of
arch in the codebase that need adjusting.
The new Arch type is an Enum, making it clear what architectures can be
represented and making it much easier to reason about. Since we support
~5 (kinda) different representations of an Architecture (Alpine, Kernel,
target triple, platform, and QEMU), we now formalise that the Alpine
format is what we represent internally, with methods to convert to any
of the others as-needed.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Introduce a Deviceinfo class and use it rather than the dictionary. This
gives us sweet sweet autocomplete, and lays the foundation for having a
proper deviceinfo validator in the future.
Additionally, continue refactoring out args...
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
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>
With the new chroot type, we can now write fancy paths in the pythonic
way. Convert most of the codebase over, as well as adding various other
type hints.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
We use a custom verbose log level in pmbootstrap, unfortunately it isn't
possible to correctly type this due to some limitations in the logging
library [1], [2].
Given that our usecase is fairly simple, we can just wrap the module
with our own so we only have to tell mypy to ignore the error once
instead of at every callsite.
[1]: https://github.com/cryptax/droidlysis/issues/15
[2]: https://github.com/python/typing/discussions/980
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.
Drop the weird flag file stuff for state management, and just always
mount the source code in, and always unmount it on exit - including in
the error path.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
find_kbuild_output_dir() searches for certain path patterns, which
won't be in the APKBUILD if it uses downstreamkernel_package. Guess
the default kbuild out dir in that case.
Theoretically this might break if some APKBUILD passes weird paths to
downstreamkernel_package, but no kernel package in pmaports today does
that.
At the moment the "envkernel.sh hasn't run, assuming the kernel was
cross compiled on host and using current dir as source" code path
triggers even when using envkernel.sh, which works somewhat but
requires sourcing envkernel.sh again after each invocation of
"pmbootstrap build --envkernel ...".
The reason is that os.path.ismount() does not work for bind mounts
(see https://bugs.python.org/issue29707). There is a workaround for
that already in pmbootstrap but it is not used here for some reason.
Add support for packaging a kernel that was compiled outside of
envkernel. The envkernel.sh wrapper is great for someone new to kernel
development, but it makes it difficult to do things like "make
dt_binding_check". This lets you avoid the wrapper and build on your
host machine but still use pmbootstrap to package your kernel for easier
testing.
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.
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.
Currently, building with envkernel.sh entirely ignores the
makedepends listed in the kernel APKBUILD. Common dependencies
needed by most kernels are hardcoded in envkernel.sh.
However, some kernels may need extra dependencies either during
the build process or when the kernel is packaged.
Installing the makedepends when the build environment is initialized
is difficult because "source helpers/envkernel.sh" is not aware
of the exact kernel package that is going to be built later.
However, we can easily modify the packaging step
(i.e. pmbootstrap build --envkernel linux-...)
to install the required makedepends.
This fixes building "linux-postmarketos-qcom-msm8916" using envkernel,
since it requires "dtbTool" and "installkernel" to be installed when
the APKBUILD package() function is executed.
abuild depends on the gcc binary in order to define a default CBUILD value.
When using an alternative gcc version (e.g. envkernel.sh with gcc6), the
gcc binary is not installed by the envkernel.sh script.
This change sets the CBUILD env variable so that abuild doesn't need to
depend on the gcc package.
Provides a quick way to incrementally compile a kernel and push it to
device.
Example usage.
Compile the kernel:
$ cd /src/linux/
$ source /src/pmbootstrap/helpers/envkernel.sh
$ make tegra_postmarketos_defconfig
$ make -jX
Package kernel and flash to device:
$ pmbootstrap build --envkernel linux-samsung-p4wifi
$ pmbootstrap flasher flash_kernel
Modify kernel source then incremental compile, package, and flash:
$ make -jX
$ pmbootstrap build --envkernel linux-samsung-p4wifi
$ pmbootstrap flasher flash_kernel
