I think a script that parses pkgs.postmarketos.org and checks against edge pkgs.alpinelinux.org is best. I cant find an api for pkgs.postmarketos.org. If you guys have a better way to program this or make it easier for you to support, let me know.
I suggest looking in the pmaports.git / aports.git repositories directly, instead of the pkgs websites. The latter gets generated from the git repositories, after binary packages are built and are sent to the backends that parse them and put the information into a database for these websites. By parsing the git repositories directly, it is more accurate (no delay until packages are built), and you should also be able to checkout a merge request for the service pack and review what packages are in there vs. alpine edge.
I got this after upgrading from 1.5.x to 1.6.0. Apparently this is known:
It was gone after another reboot.
Edge blog post: https://postmarketos.org/edge/2021/10/24/sway-swmo/
if a camera hardware switch in the PinePhone is disabled, Megapixels segfaults because it cannot find the cameras from the device config. It should just ignore this part of the config instead (it's a perfectly valid use case to disable e.g. the front camera and use only the back camera).
This was fixed in 1.0.0.
I gave this some thought and decided to just build the Sxmo images for all devices where we also build Phosh and Plasma Mobile images, for v21.03 and edge. This will probably encourage more people to try it out and contribute patches to fix the few remaining issues with their devices.
Summary of what has been done in pmOS to address this (2021-03-21):
- In postmarketos-mkinitfs, the new initramfs-extra is not generated next to the old one. Instead, it is generated in /tmp. This way it does not run out of space anymore, and prevents the issue here. (The old logic was supposed to do more-or-less an atomic replacement of the old file, more on that below.)
- pmbootstrap has been patched to double the default boot partition size, 256 MiB instead of 128 MiB.
- All new images, including the first images since v21.03 was announced, are now built with the bigger boot partition
- With the bigger boot partition size, in theory it's now possible to do an atomic replacement of all files on the boot partition again. The plan is to update postmarketos-mkinitfs to check available size first, and if there is enough space, generate the new files next to the old one and replace them if they were built successfully. However, the postmarketos-mkinitfs code is pretty much the oldest code in postmarketOS and I'm not happy with the quality of the code anymore (doesn't use
set -efor example). I'll probably just rewrite it and implement this safety feature (replacing the files from same partition) while at it. I've also considered using existing initramfs build scripts, but the postmarketOS mkinitfs is also able to repackage the initfs into boot.img and other formats needed to boot on android devices etc. So I'm leaning towards just rewriting the few LOC we already have. Details: https://gitlab.com/postmarketOS/pmaports/-/issues/1019
=> I think this can be closed.
~begs, can you submit patches to Sxmo/pmaports, so bq-paella works out of the box with Sxmo, and make sure it works in the future? Then I'd be happy to enable automatic building of Sxmo images for bq-paella, edge and v21.03 (the latter once we backport this in a service pack).
Same goes for other devices in main and community categories.
That's not an issue, we can just fork these components from alpine.
Please mention in the sxmo 1.4.0 MR, on which versions of lisgd, svkbd etc. it depends, with a note that this is relevant for backporting.
Forking from alpine is basically:
$ cd pmaports $ git checkout master $ pmbootstrap aportgen --fork-alpine lisgd $ git checkout v21.03 $ nvim temp/lisgd/APKBUILD # edit reason for fork in first line to "edge" $ git add temp/lisgd $ git commit -m "temp/lisgd: fork from alpine edge"
~ollieparanoid let me know if putting this forward in and going this way is good by you
Yep, sounds good.
The workflow ~ollieparanoid proposed looks good to me too. I'm kind of hoping we can squeeze our newest 1.4.0 release in for v21.03, but that may be tight.
Since this branch is supposed to be more stable, it wouldn't be good to do this in the last second. Rather take your time with the release, give it some time for testing on edge, and then we ship it in the first service pack.