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
Fixes this warning:
warning: The top-level linter settings are deprecated in favour of their counterparts in the `lint` section. Please update the following options in `pyproject.toml`:
- 'ignore' -> 'lint.ignore'
In the process, drop the list of required python packages. This is
only needed for pip, as pmbootstrap checks by itself. This way we
avoid duplicating the minimum required version.
We also don't install the helpers anymore, as modern tooling does not
support installing things outside the python package dir
If there are multiple sections to a subpackage declaration, the middle one
(item 1 in the sequence in this case) is the custom function name which we
should use instead of the deduced one.
For example:
$pkgname-something-separate:something_separate:noarch
Here, the subpackage is called $pkgname-something-separate, but function names
cannot contain hyphens, so it's instead given the custom name
something_separate where the hyphen is replaced by an underscore. At the end,
the architecture of the subpackage is also overriden as noarch instead of
whatever architecture the main package has.
However, it is also possible to only override architecture of a subpackage and
not the function name.
In such cases, we get this:
$pkgname-something::noarch
We still have a "middle section" (item 1 in the sequence), but it will be
empty. As such, we not only need to check whether there are more than 1
subpackage part, but also whether that extra subpackage part is an empty string
or not.
This fixes an issue where pmbootstrap would not end up just setting the
properties of subpackages with a set arch but no custom function as
None instead of giving them proper depends, install, pkgdesc, et cetera
properties.
Highlight messages like the following from pmbootstrap install:
[19:45:59] *** (1/4) PREPARE NATIVE CHROOT ***
[ci:skip-build]: already built successfully in CI
Many have been unable to use pmbootstrap install on kernel versions
between 5.8 and 6.0 as parted was giving the following error:
Error: Partition(s) 1, <...>, 64 on /dev/install have been
written, but we have been unable to inform the kernel
of the change, probably because it/they are in use.
As a result, the old partition(s) will remain in use.
You should reboot now before making further changes.
And pmb couldn't find /dev/loop0p1:
ERROR: Unable to find the first partition of /dev/loop0,
expected it to be at /dev/loop0p1!
Related: pmbootstrap#2309
[ci:skip-build]: no code changes
Signed-off-by: Ferass El Hafidi <funderscore@postmarketos.org>
Newbyte
Oliver Smith
Clayton Craft
Raymond Hackley
methanal
Alexander Martinz
Pablo Correa Gómez
Ferass El Hafidi