Highlight messages like the following from pmbootstrap install:
[19:45:59] *** (1/4) PREPARE NATIVE CHROOT ***
[ci:skip-build]: already built successfully in CI
If the device name does not make a valid hostname, fall back to some
simple valid hostname. Some device names (e.g. 'generic-x86_64') are
valid names for apk packages and such, but are not valid host names. It
assumes that the user (real, or CI) doesn't care if it's unset and just
expects pmb to work and not conditionally crash based on the device they
selected.
Situations where the user sets an invalid hostname are still validated
separately and cause an exception so that they know their config was
wrong and to fit it.
This fixes an issue that came up in CI when doing `pmb config device
generic-x86_64` followed by `pmb install`.
I considered trying to convert invalid host names into valid ones, but I
didn't feel like it was worth the trouble of adding stuff to convert and
re-validate when we can just set a static, boring, but definitely valid
default if the device name is not valid.
Due to that logging.verbose is "monkeypatched" into logging and not
present by default in the module, Mypy isn't able to pick up that it
exists. As such, just disable the check altogether in this file for
now.
The return value of this function is never used. Additionally, the type
hint for it was incorrect as it may return None. As such, don't bother
returning anything both to appease Mypy and also to remove unused
and consequently presumably untested functionality.
Repurposing argcomplete as a boolean telling whether the module
argcomplete was found results in a variable with two distinct purposes
and types, which is bad practice and confuses Mypy. As such, don't
assign False to argcomplete if the module is not found and instead just
check for whether it exists in sys.modules to determine whether it was
imported successfully.
This drops the prompt for using non-free firmware in images. The logic
for searching/installing non-free fw subpackages for devices is kept,
and will always be installed. This is to support the many device
packages in pmaports that still have nonfree-firmware subpackages. Going
forward, device packages can list firmware in `depends=` (for required
fw) or `pmb_recommends` (for optional fw).
nonfree-userland wasn't used in pmaports as far as I could find.
Sometimes dependencies of packages we are explicitly adding to world
define selected providers that we should account for. This improves
get_selected_providers to discover/add these selected providers in
dependencies too, recursively.
Fixes#2306
Only install the abuild-apk wrapper if cpu emulation is required. This
fixes building for x86 on x86_64.
Fix for:
>>> postmarketos-base-ui-gnome: Analyzing dependencies...
/usr/local/bin/abuild-apk: line 11: /native/usr/bin/abuild-apk: not found
Fixes: c5ca06d5 ("pmb: only enable abuild-apk wrapper for buildroot (MR 2246)")
we're not in the nftables only world yet, things like docker and
tailscale only work with the `iptables` command. those programs
expect iptable-modules, which we make available to nftables over
the nftables/iptables compat layer.
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>
When running build --force, if a later package is a dependency of an
earlier package, it will be "visited" by the dependency resolver,
erroneously causing it to be skipped when later in the session it's
visited to force build. This is because previously visited packages are
marked as such in a hashmap, but skip_already_built() assumes that a
package which has been visited would have already been built.
Fix this by overriding skip_already_built() if doing a force build. This
works because package dependencies are only built if the APKBUILD
version is newer than the binary repo, even when --force is specified.
So there is no risk of an infinite loop here.
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Some packages like kernels are cross compiled from the native chroot.
the apk_wrapper won't work here! So only enable it for buildroot chroots
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Why
Btrfs has some goodness (snapshots, switching between different rw snapshot)
which plays particularly well with certain "subvolume layouts".
What
This MR seeks to implement such a layout, namely a flat btrfs layout,
where the top level subvolume (i.e. the btrfs filesystem/partition itself)
remains unmounted in all situations,
except when making changes to direct child subvolumes of the filesystem.
- rename all subvols to follow the common @* btrfs subvol naming scheme.
- add subvol @root, because roots home directory shouldn't be rolled back.
- make subvol @var not Copy-on-Write (nodatacow) to avoid write
- multiplication on logs, VMs, databases, containers and flatpaks.
- add subvol @snapshots because that lets us change the root subvol to a
read-write snapshot of @ without affecting snapshots.
- add subvol @srv because it contains data for Web and FTP servers,
which shouldn't roll back together with root subvol.
- add subvol @tmp because we don't want to snapshot temporary files.
This subvol remains unmounted on the device,
unless conditions as laid out in pmaports!4737 are met.
- add check and error for btrfs when using rsync installation.
Speed up using abuild to install build dependencies by introducing a
wrapper which invokes abuild-apk in the native chroot with
LD_PRELOAD_PATH
Signed-off-by: Caleb Connolly <caleb@postmarketos.org>
Fix "pmbootstrap chroot" and others not passing the proxy environment
variables correctly. Thanks to notfound405 for pointing this out!
Instead of only preserving proxy environment variables in
pmb.helpers.run_core, which should never be called directly, do it in
the calling functions:
* pmb.helpers.run.user
* pmb.helpers.run.root
* pmb.chroot.root
* pmb.chroot.user
This fixes that the environment variables were only really passed by
pmb.helpers.run.user, because the other functions would result in
something like:
HTTP_PROXY=mytestproxy sudo env -i /usr/bin/sh -c '…'
This is needed to either elevate to root, or to elevate to root first
and then enter the chroot as root or user. Due to the "env -i", the
environment intentionally gets cleaned, but unintentionally also removes
the proxy environment variables that were explicitly set.
By adjusting the functions, they now run a variant of:
sudo env -i /usr/bin/sh -c 'HTTP_PROXY=mytestproxy …'
The escaping is simplified in this example, run "pmbootstrap -v" to see
the not very readable, but proper escaping with shutil.quote().
Remove the previous test for preserving the environment variables in
pmb.helpers.run_core (as it should never be called directly), and test
instead the new behavior.
Fixes: issue 2299
Fixes: 13c4ac42 ("pmb.helpers.run_core: fix proxy env var logic")
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.
Without this, pmbootstrap will give an error if you have a nonexistent
device selected when trying to checksum a package. This can be annoying
when switching between different branches where devices may or may not
exist, and I don't think these initialisation steps are necessary for
the checksum action anyway.
When running pmbootstrap install --android-recovery-zip it tries to
access pmb.flasher.variables but args.no_reboot and args.resume are
only defined when running pmbootstap flasher.
I zap chroots a lot, since I've found that it often "fixes" a lot of
weird issues that come about if you have stale chroots laying around.
So a common pattern I do is "pmb zap && pmb install ...". Having an
option to pmb install let's me simplify this.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231214234051.4673-1-clayton@craftyguy.net%3E
Make sure the user has at least 256 MiB set as their installation size,
refuse to start the installation otherwise. The default was changed in
2021, 03e9fb05 ("pmb.config.init.boot_size: set to 256 MiB (MR 2037)").
If the user ran "pmbootstrap init" before that commit, the pmbootstrap
config will have the old default set. It is very annoying when you do an
installation with it and only realize it when you run into errors, e.g.
while upgrading. I had that when testing the upgrade to the v23.12
release and also adjusted postmarketos-release-upgrade to warn if the
boot partition is smaller than expected.
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231208222714.4601-1-ollieparanoid@postmarketos.org%3E
Sometimes I want to build an older version of a package from Alpine, and
since package upgrades can involve things like patches and other
externalities just changing the pkgver and running checksum in pmaports
may not be enough. As such, it tends to be easier to revert the change
in the local aports repo and then fork than forking and then trying to
manually revert the changes yourself (since you can't have git do that
for you given that they are distinct repositories).
Prior to this patch, that was not possible since pmbootstrap would
assume older aport version equals outdated aports in general and as such
cancel the whole operation. Instead, just print a warning and helpful
information to make this workflow possible while also warning users that
they may want to update their local aports.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231209111813.37756-1-newbyte@postmarketos.org%3E
Having AppStream data is great for installation that make use of GNOME
Software or KDE Discover, however it's not a must. The generation of
AppStream data in alpine (which we maintain) is still certainly
improvable, and we have bumped into problems, unreliabilities and such
from time to time. Installations without AppStream data are
totally functional, even if the first experience on those apps is not
the best. Still, users are one refresh away on Software or Discover
from getting such data downloaded. So failing to generate installations
for this reason is unnecessarily breaking.
Signed-off-by: Pablo Correa Gómez <ablocorrea@hotmail.com>
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231205160205.13916-1-pabloyoyoista@postmarketos.org%3E
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
