Reimplement "pmbootstrap status" to be just a simple and useful status
overview. The previous version ran a bunch of checks every time, and
would fail on these even if pmaports was used for normal development:
* "non-official" branch checked out in pmaports
* pmaports.git is not clean
The information about aports.git was also considered not so useful upon
revisiting this command, since it is only used for "pmbootstrap
aportgen". Most users don't need this, and if the user runs this
command, it will tell if aports.git is outdated.
All of the above made the previous version unpleasant to use and I
suspect most people stopped using the command after trying it out a few
times and seeing the irrelevant but loud NOK complaints.
New version:
$ pmbootstrap status
Channel: edge (pmaports: master_staging_systemd)
Device: qemu-amd64 (x86_64, kernel: virt)
UI: console
systemd: no (default for selected UI)
Old version (without --details it only shows NOK checks):
$ pmbootstrap status --details
[00:55:20] *** CONFIG ***
[00:55:20] Device: qemu-amd64 (x86_64, "QEMU amd64")
[00:55:20] Kernel: virt
[00:55:20] User Interface: console
[00:55:20]
[00:55:20] *** GIT REPOS ***
[00:55:20] Path: /home/user/.local/var/pmbootstrap/cache_git
[00:55:20] - aports_upstream (master)
[00:55:20] - pmaports (master)
[00:55:20]
[00:55:20] *** CHECKS ***
[00:55:20] [OK ] Chroots zapped recently (or non-existing)
[00:55:20] [OK ] aports_upstream: on official channel branch
[00:55:20] [OK ] aports_upstream: workdir is clean
[00:55:20] [OK ] aports_upstream: tracking proper remote branch 'origin/master'
[00:55:20] [OK ] aports_upstream: up to date with remote branch
[00:55:20] [OK ] aports_upstream: remote information updated recently (via git fetch/pull)
[00:55:20] [OK ] pmaports: on official channel branch
[00:55:20] [OK ] pmaports: workdir is clean
[00:55:20] [OK ] pmaports: tracking proper remote branch 'origin/master'
[00:55:20] [OK ] pmaports: up to date with remote branch
[00:55:20] [OK ] pmaports: remote information updated recently (via git fetch/pull)
[00:55:20]
[00:55:20] NOTE: chroot is still active (use 'pmbootstrap shutdown' as necessary)
[00:55:20] DONE!
Make sure that we build depends of subpackages, to avoid errors like the
following:
* postmarketos-base has a subpackage postmarketos-base-nftables, which
depends on postmarketos-config-nftables
* when pmbootstrap builds postmarketos-base with all its dependencies,
it did not realize it depends on postmarketos-config-nftables through
the subpackage, but it built it anyway
* when trying to install postmarketos-base-nftables, apk complains that
there is no postmarketos-config-nftables:
ERROR: unable to select packages:
postmarketos-config-nftables (no such package):
required by: postmarketos-base-nftables-32-r2[postmarketos-config-nftables]
This also adds the missing depenendencies to "pmbootstrap repo_missing",
which bpo uses to resolve dependencies.
Fixes: issue 2084
Prepare to remove the outdated chroot check from "pmbootstrap status".
Display it when the user enters a stale chroot instead. This way the
user is more likely to see it, and we can make "pmbootstrap status" more
minimal (by removing all checks, in future patches).
Related: issue 1903
With the !pmb:crossdirect option, the crossdirect compilation method
gets disabled. This means there is no /native directory mounted inside
the foreign arch chroot, all binaries inside the foreign arch chroot are
supposed to run in QEMU. Handle this in the apk_wrapper.sh script that
we use to redirect abuild-apk to /native/usr/bin/abuild-apk.
Fix for (currently with master_staging_systemd branch):
>>> upower: Analyzing dependencies...
/usr/local/bin/abuild-apk: line 11: /native/usr/bin/abuild-apk: not found
When the user attempts to build a package with systemd enabled,
pmbootstrap checks first if the postmarketos-base-systemd package is in
any of the APKINDEX files. Fetch the APKINDEXes before trying to find
the package in them.
I'm running into this currently with bpo, when attempting to build any
package from the master_staging_systemd branch.
Previously, if this was the first time you were connecting to a device,
the output of the ssh command would contain a warning about that the
host was added to the list of trusted hosts. This causes problems as
this gets included in the output where the code previously expected the
string-representation of the architecture to be.
As such, remove the irrelevant output by splitting it into lines and
only using the last line as we assume ssh won't print anything after the
actual output of the invoked command.
Closes https://gitlab.com/postmarketOS/pmbootstrap/-/issues/2335
[ci:skip-build]: already built successfully in CI
I have Nushell set up on my Librem 5, and it is not a POSIX-compatible
shell. As such, the rc=$? variable assignment in this snippet fails.
Running this in a sh subshell works around this problems and will likely
fix it for other non-POSIX shells as well given that /bin/sh should at
least be POSIX-compatible on any sensible system.
This works around an issue where some armhf apps are compiled with
instructions that are not compatible with aarch64, for example apk uses
MCR, and that does not exist on aarch64 causing apk to fail in a chroot
with SIGILL. It's impossible to build armhf images on aarch64 hosts, and
this also fixes a crash when running `pmbootstrap zap -a`, since pmb zap
will init an armhf chroot and blow up with apk generates a SIGILL.
For reference, here's how I arrived at the conclusion that apk (and gdb,
and probably others...) are executing invalid instructions on aarch64
when not using binfmt+qemu emulation:
$ uname -m
aarch64
$ file sbin/apk.static
sbin/apk.static: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=997a8ef97b17cb4951a6220b7807a66fed67bc10, stripped
$ gdb sbin/apk.static
(gdb) r
Starting program: /run/user/10000/foo/sbin/apk.static
Program received signal SIGILL, Illegal instruction.
0x0012843c in ?? ()
(gdb) x /1i $pc
=> 0x12843c: mcr 15, 0, r0, cr7, cr10, {5}
I'm not sure why pmb.parse.arch is being imported here given that it's
the module we already are in. Replace it with pmb.config which this
module actually needs.
Instead of assuming the architecture of the foreign device to be what
the user selected in pmbootstrap init, actually query the architecture
from the device and use that.
This does mean that one extra ssh connection is necessary, which does
slow down the procedure somewhat. However, I think that is worth the
user experience improvement this brings.
Also, the deduction process can be skipped by manually specifying
--arch in the sideload invocation should it fail, or if one really wants
to skip that extra ssh roundtrip.
Related: https://gitlab.com/postmarketOS/pmbootstrap/-/issues/2317
Sometimes it's useful to map an arbitrary machine type to an Alpine
architecture. alpine_native only lets you get the Alpine architecture
mapped to the machine type of the system pmbootstrap is running on. As
such, break out this functionality into a new function that takes the
machine type as a parameter.
The intent of 9a74848f19 was to not print
a stacktrace when this happened. However, I still opted to raise an
exception, so you still get a stacktrace, just with a more helpful
message. There's no need to give the user a big stacktrace here, so
raise a NonBugError instead of a RuntimeError.
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.
Initially I thought of putting this in pmb/helpers/other.py, but this
resulted in a circular import, so I thought the easiest way to work
around that was to just create a new file.
Implement a function to verify the type of QCDT image by comparing the
first four bytes of the file. This is represented in a deviceinfo
variable, used by boot-deploy for dt.img generation.
Often I find myself confused and subsequently frustrated by the
behaviour of --fork-alpine as usually I apply whatever changes I want to
the aports package before forking. This is due to that in the proper
aports repo I can leverage the full power of git and apply patches or
revert commits, whereas after the package has been forked to pmaports
the context git needs to do this is lost.
To fix that, this commit introduces --fork-alpine-retain-branch which
works the same way as --fork-alpine except it doesn't change the aports
branch to match the current channel.
Fix a regression from my recent patch that made text like the following
green:
*** text ****
We also have log messages that only start with ***, but do not end with
***, coming from "pmbootstrap aportgen". They indicate that a new aport
has been generated, but are not a headline for the coming commands.
Fix that the aportgen messages don't reset the colors at the end of the
line, and so the next line would start with the color.
Fixes: 6ba138b6 ("logging: print text between *** in green (MR 2263)")
Make sure users don't set systemd to "true" or other not allowed values
(allowed are "always", "default", "never").
Check for it:
* after loading the config
* when using 'pmbootstrap config systemd <newvalue>'
For UI packages that have pmb:systemd-never set:
* do not ask in "pmbootstrap init" whether to use systemd or not
* do not install systemd, even if the systemd option is set to "always"
The point of this is to not add maintenance burden to Sxmo (and possibly
other UIs who not wish to support systemd with postmarketOS), so users
don't install with this unsupported use case and report issues with it.
Upgrade packages in the chroot, in case alpine-base, apk etc. have been
built from source with pmbootstrap. We build it from source for systemd
currently, and sometimes it is useful to do that to debug apk.
Add this argument, so we can disable the pmOS repository during
"pmbootstrap repo_bootstrap" for the chroot we build in.
If building natively, it will be disabled in the "native" chroot.
If building for a foreign arch, it will be disabled in the
"buildroot_$arch" chroot, but still be enabled in the native chroot so
we have the cross compilers available.
The name of the argument is a bit long, but it is consistent with the
argument of the same name in pmb.helpers.repo.urls() (to which it gets
passed).
Add the following question to "pmbootstrap init":
[22:12:57] Based on your UI selection, 'default' will result in installing systemd.
[22:12:57] Install systemd? (default/always/never) [default]:
Determine whether the UI prefers to have systemd or not, based on
"pmb:systemd" in the UI package's APKBUILD.
Determine whether the currently selected branch supports systemd, by
checking for a "[repo:systemd]" section in pmaports.cfg. This section
will also contain bootstrap information, to be used in future patches.
We have been discussing making device package versioning more
consistent and ended up settling on using integer versioning for device
packages[1]. As such, let's start by tackling this at the source and
start generating new device packages with 1 as the starting pkgver
instead of 0.1.
[1]: https://gitlab.com/postmarketOS/pmaports/-/issues/2610#note_1796178414
Clayton Craft
Oliver Smith
Newbyte
Raymond Hackley
methanal
Alexander Martinz