Alpine edge should not be used as a daily driver according to the alpine wiki.
Sometimes megapixels stops working and there are other bugs like: #208.
Switching to postmarketos stable when it is available for sxmo by the end of this month should fix most of these issues.
yes this is very much needed. After every upgrade had issues related to libraries in applications like kodi, evolution, surf and megapixels. It is really time consuming to identify libraries which break after every upgrade.
Good to see that this is on your radar, I was just about to create an issue to communicate this.
I've just upgraded Sxmo in the WIP branch of the next release, v21.03 (as written above, to be released at the end of this month), to the latest commits from pmOS master: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2055
Please do test installs with postmarketOS v21.03 (select that channel in
pmbootstrap init) + Sxmo, and verify that everything is working as it is supposed to.Relevant for Sxmo, we also plan to make this available in the v21.03 release (-> will be merged soon to master and get backported to v21.03): https://gitlab.com/postmarketOS/pmaports/-/merge_requests/1931
Regarding workflow:
- we will create pre-built postmarketOS images with Sxmo from the v21.03 branch for the PinePhone roughly every week (just like for edge)
- we can do it for more devices too if there is interest (though right now Sxmo seems still to be very pinephone centric, see #169?)
- these come as live image, and with the installer to do FDE etc.
- feature changes go into postmarketOS edge first, and get backported to the stable branch every month or so, bundled in so-called service packs
- bug fixes can be backported directly to v21.03 if needed
- (if the workflow doesn't work for you, it's not all set in stone, just talk to us)
Once the release is announced, this will be the recommended branch to install postmarketOS, and we will have a download page on the homepage. From there, people will be able to download pre-built images for all devices in main and community.
https://gitlab.com/postmarketOS/postmarketos.org/-/merge_requests/99#download
yes this is very much needed. After every upgrade had issues related to libraries in applications like kodi, evolution, surf and megapixels. It is really time consuming to identify libraries which break after every upgrade.
Yes, unfortunately there was quite a lot of breakage recently :\ ( https://postmarketos.org/edge )
While we're discussing this, where should users download v21.03 images with Sxmo? Right now, there are two places where Sxmo images are available.
b) https://images.postmarketos.org/bpo/edge/pine64-pinephone/sxmo/
I wonder if we should remove one of them, so it's clear for users where they can get their images and we don't have duplicate effort.
Sxmo developers have control over a) and can generate new images right after a release (whereas b) only generates them weekly), so I think it makes sense to keep a) and get rid of b), once both have the same feature sets. We can then link the sxmo directory of images.postmarketos.org to images.lrdu.org.
The images from b) are generated like this (see manifest, generated from here): https://builds.sr.ht/~postmarketos/job/461622 Notable differences:
- the generated image gets packed into a second image with the on-device installer, which can be used to create an encrypted installation, install from the SD card to eMMC, set a user and sshd password (and in the future, choose the filesystem). Users can then download either the "regular" image (like a live CD) or the installer image.
pmbootstrap installis called with--no-sshd, so the SSH server is disabledThoughts?
CC: ~mil
In principal I think having BPO generate images and deprecating (and even removing images.lrdu.org) is probably the right move. This provides consistency since (I think) we are the only UI to generate our own images and this is more of a 'distro' task.
The only things we'd loose two things by going with BPO fully are:
Weekly duration - historically I had published new Sxmo images on the (day) we tagged the release number in git / had things accepted upstream for APKBUILDs.
Historical images - it seems like BPO only has some history so we loose the timeline.
For (1), I don't think that's a major issue as image users are likely to be "end-consumers" and can wait a little while, if they want things up to date they can always
apk update/upgrade. For (2), I kind of liked the ability to go back in time to track regressions on an image basis, but I don't think it's entirely necessary.I think I'll take a todo to put a forward on images.lrdu.org to images.postmarketos.org and update the docs for the new username password unless anyone has any objections (~ollieparanoid let me know if putting this forward in and going this way is good by you).
On 21-03-22 03:33, ~mil wrote:
In principal I think having BPO generate images and deprecating (and even removing images.lrdu.org) is probably the right move. This provides consistency since (I think) we are the only UI to generate our own images and this is more of a 'distro' task.
I agree, removing our image infrastructure and relying on postmarketos would make most sense.
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.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
~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.
@ ~ollieparanoid: I've got a question about the backporting procedure. Is the fact that we have certain components (lisgd, svkbd) upstream in Alpine Linux an obstacle? When we release sxmo 1.4.0 and it is deemed stable enough we'll want to backport it to v21.03, but that also relies on these upstream components.
--
Maarten van Gompel (proycon) https://proycon.anaproy.nl
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"
Added a deprecation notice to http://images.lrdu.org/ and updated install guide to point to bpo.
We might want to change out the link on all the pages that links to images too.
I have updated the docs to remove all mentions of http://images.lrdu.org/ . https://git.sr.ht/~mil/sxmo-docs/commit/cd7d1638d4ae54c84a3975bb6137c93db24aa98d
Thank you for all your work maintaining the build system for sxmo ~mil!