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
If we found an APKBUILD already, with the exact name of the package we
are looking for, then don't also guess what other package could contain
the package as subpackage.
The guess was thrown away with the previous logic, but it caused
misleading verbose logs like:
lomiri-history-service: guessed to be a subpackage of lomiri
Also this is slightly faster. While at it, tweak the related comments
to make this easier to understand.
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231121222457.2871-1-ollieparanoid@postmarketos.org%3E
Fix that APKBUILDs mentioning other packages with an operator could not
be found. As we are building the initial branch of v23.12, this
currently happens with postmarketos-mkinitfs: it depends on
devicepkg-utils>=0.2.0 and currently pmbootstrap will only remove the
>=0.2.0 when looking for the pkgname in the APKINDEX of binary packages
(which is why it works on master). But it does not yet do that when
looking for the pkgname in pmaports.
Move the code for stripping the operator to a common place and use it
for getting packages from pmaports too.
Change the order of operators while at it, try to find <= before =, as
otherwise it would cut off example<=1.2.3 as "example<" instead of
"example".
Reviewed-by: Caleb Connolly <kc@postmarketos.org> (via chat)
If a package had _pmb_select set and an appropriate provider configured
in pmb's cfg, it was not being used when providers were being resolved.
With this change, those are now being considered. The order is also
important, we want a selected provider to be chosen before it tries to
make a decision based on provider_priority later in step #6.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231122081214.11872-2-clayton@craftyguy.net%3E
The sdcard option can not only be used to write to SD cards, but also
for writing to USB sticks. Or even to write to internal storage if
pmbootstrap runs on a system booted from a live disk / seconds storage.
Drop the check. Thanks to Raymond Hackley for pointing out that this
check is not useful.
Reviewed-by: Anton Bambura <jenneron@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231101193702.2223-1-ollieparanoid@postmarketos.org%3E
This fixes an issue when pmb is run on an Alpine/pmOS host and apk.static sees
that /etc/apk/interactive is set on the host. It's really annoying to have the
build pause so apk can prompt when building chroots, so this uses a flag to apk
to disable interactive mode. I can't think of any situations where we would
actually want to prompt users when building chroots, by then all user
configuration should have been completed via pmb init/config.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Co-developed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231110185320.8358-1-clayton@craftyguy.net%3E
Currently, pmbootstrap checks if either the kernel or the ramdisk in a boot.img
contains the MediaTek header, and if one does, it assumes both do. It hardcodes
the label KERNEL for the kernel and ROOTFS for the ramdisk.
My Amazon Echo Dot (gen 2) has a boot.img where only the kernel has the header,
but not the ramdisk. These changes (as well as those in my new boot-deploy MR)
account for that situation (and any possible label an image has) by splitting
bootimg_mtk_mkimage into two variables for the kernel and the ramdisk labels.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/patches/46351
It can be quite useful to check the configs for a list of packages, so
adjust the argument parsing code to support that.
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Tested-by: Oliver Smith <ollieparanoid@postmarketos.org>
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231028085901.35205-1-luca@z3ntu.xyz%3E
This is required for being able to boot compressed kernels via EFI stub
on aarch64.
As far as I can tell, EFI_ZBOOT was added in a050910972bb2, and
available in 6.1.0 or later. I'm not sure if it was backported to other
older LTS versions or not...
Reviewed-by: Anton Bambura <jenneron@postmarketos.org>
Reviewed-by: Oliver Smith <ollieparanoid@postmarketos.org>
Tested-by: Oliver Smith <ollieparanoid@postmarketos.org>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20231011212433.17131-1-clayton@craftyguy.net%3E
Remove test_crossdirect_rust, the only test in test_crossdirect.py. The
behavior that was tested here with all the "mv /usr/bin/rustc" commands
was specific to version 4 and isn't valid anymore since version 5
(pmaports MR 4234).
The previous behavior was that crossdirect always tried to run rustc
from /native, and if it failed, it would fall back to using qemu. The
new behavior is that it runs rustc from /native only when it expects it
to succeed, and runs rustc via qemu otherwise, without attempting
/native first. As the logic to decide whether to use native rustc or not
is now done beforehand, it does not do the fallback to qemu if native
fails.
Note that the test hasn't been failing because we switch to the v23.06
channel and therefore use the older crossdirect version.
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230806184729.4891-6-ollieparanoid@postmarketos.org%3E
Cache the compiler output of rust code with sccache, like we use ccache
for c code.
I've considered using sccache to completely replace ccache since it can
cache output of C/C++ code too. But let's not do it for now since ccache
doesn't need to run a daemon in the background that needs to be stopped
when shutting down / zapping. Also it would need more refactoring.
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230806184729.4891-5-ollieparanoid@postmarketos.org%3E
Shorten this message:
> NOTE: 6 user interfaces are not available. If device supports GPU
> acceleration, set "deviceinfo_gpu_accelerated" to make UIs available.
> See: <https://wiki.postmarketos.org/wiki/Deviceinfo_reference
to:
> NOTE: 6 UIs are hidden because "deviceinfo_gpu_accelerated" is not set
> (see https://postmarketos.org/deviceinfo).
This also fixes the non-closed angle bracket by simply removing it. I
used to put angle brackets around all URLs printed in pmbootstrap
initially, but have been moving away from that when touching related
code as it doesn't add anything useful.
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230802172542.4861-3-ollieparanoid@postmarketos.org%3E
Change the defaults in the new device port wizard:
* arch: armv7 -> aarch64
New devices are more likely to be aarch64.
* flash method: 0xffff -> none
The only device that uses 0xffff is the N900, it's extremely unlikely
that it will get used for a new port. Use the neutral "none" instead.
Reviewed-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230802172542.4861-2-ollieparanoid@postmarketos.org%3E
Add the "args" fixture to test_skip_already_built, so it correctly
initializes logging (and indirectly pmb.helpers.other.cache). With this
it becomes possible to run the test file on its own. See "def args" on
top of the file for implementation of the "args" fixture.
Fix for:
$ pytest -xvv test/test_build_package.py
…
> assert pmb.helpers.other.cache["built"] == {} E TypeError: 'NoneType' object is not subscriptable
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230724070509.1885-2-ollieparanoid@postmarketos.org%3E
Fix that the list "cmd" was turned into a string if one of the proxy
vars was set in the environment. Add a test for this code path. Before
this patch:
$ FTP_PROXY=test pmbootstrap -v --details-to-stdout status
…
% cd /home/user/.local/var/pmbootstrap/cache_git/pmaports; git remote -v
run: FTP_PROXY=test ['git', 'remote', '-v']
ERROR: [Errno 2] No such file or directory: "FTP_PROXY=test ['git', 'remote', '-v']"
Fixes: 1a00c04f ("pmb.helpers.run_core: always configure proxy vars if set in environment")
Reviewed-by: Clayton Craft <clayton@craftyguy.net>
Link: https://lists.sr.ht/~postmarketos/pmbootstrap-devel/%3C20230713182337.6185-3-ollieparanoid@postmarketos.org%3E
