Prepare a new release, so pmbotostrap can be used with Alpine 3.21 /
postmarketOS v24.12. Also the big rewrite is done, so we can do more
frequent releases again.
Related: https://wiki.postmarketos.org/wiki/Pmbootstrap_release
On debian systems in particular special handling is needed for
/usr/sbin. Let's do this once and then provide the host deps we use in a
nice accessible dictionary.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Tweaked-by: Oliver Smith <ollieparanoid@postmarketos.org>
There is a lot of context and state management needed when using
pmbootstrap, sometimes it can be a lot to keep in your head. Let's print
the output of "pmbootstrap status" when stuff goes wrong, this might
help remind people if e.g. their pmaports checkout is on the wrong
branch, or they're building for the wrong device.
Additionally, don't print the "run pmbootstrap log for details" message
if pmbootstrap was called with --details-to-stdout
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
* Use NonBugError instead of RuntimeError so users don't get a stack
trace for this.
* Check for the pmbootstrap <= 3.0.0 config, and print a nice message
asking users to recreate their config.
* Add a separate message if --config was used.
* Reword the generic "no config found" message to suggest 'pmbootstrap
init' first, and only mention --config at the end. Most users will
need to just run 'pmbootstrap init'.
Let pmbootstrap display 3.0.0_alpha on crash, so it's clear when people
are using the new codebase.
Before you report this error, ensure that pmbootstrap is up to date.
Find the latest version here: https://gitlab.com/postmarketOS/pmbootstrap/-/tags
Your version: 3.0.0_alpha
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>
Keeping the Config class in types seemed kinda weird and was just done
as a workaround to some cyclical imports. But now things are more in
shape let's move it to core.
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>
The current mechanism of invoking pmbootstrap actions can be a bit
confusing, and relies heavily on args being a big namespace with lots of
properties (which may or may not be valid depending on the context).
To aid in slowly removing args from the codebase, introduce a new
mechanism for running commands. This works by having a class for each
command, where the arguments are passed in as parameters to the
constructor.
No doubt this won't scale very far, but it's a skeleton we can continue
to build on as we migrate more commands over to not require args in
order to run.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
We can't totally escape the need for some runtime state defined by args.
To make the migration easier, introduce a global "Context" class and
move some of the read-only global options there.
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.
Make the handling of the custom NonBugError and BuildFailedError
exceptions more consistent with the handling of other exceptions, by
printing "ERROR: " infront of the actual error text. Then we don't need
to duplicate that where we raise the errors. pmbootstrap prints "ERROR"
in red.
NonBugError means that the root cause originates from a bug outside of
pmbootstrap's code base. As such, no need to print a stacktrace or ask
the user to update pmbootstrap.
