Hello,
Some bits from PureOS;
1. Byzantium on all the things 2. End of life for Amber? 3. EFI
1. Due to the fact that there is a new SoC / CPU in the Mini and the Librem 14, we need to move to a new kernel for these new devices. The good news is that the Byzantium kernel appears to fit our needs. The Mini that I have here is a Intel Coffee Lake i7-8565U @ 1.80GHz with 8 Cores.
uname -a; "Linux 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux"
/etc/os-release; VERSION_ID=10.0 VERSION_CODENAME=byzantium
Everything has been working quite smoothly except for some issues around accessing our repos; https://tracker.pureos.net/T960
I have an ISO with the installer that Matthias has fixed up and we hope to have a Go / No Go decision with that image for tomorrow (Wednesday).
2. Amber should likely have a EoL date. I feel like that should be a sort of LTS style approach and say we'll support Amber for two more years. We still sell some products (Librem 15, server) with Amber still on it and enterprises expect longer support so something along those lines seems sensible. Feedback most welcome.
3. Can we deliver an installer that supports EFI? I realize this has been a goal for a while and that there is work still needed to be done for this and we have the usual resource constraints. What more needs to be done?
Thank you!
Hi Jeremiah, On Tue, Nov 24, 2020 at 02:11:02PM -0500, Jeremiah C. Foster wrote:
Hello,
Some bits from PureOS;
Byzantium on all the things
End of life for Amber?
EFI
Due to the fact that there is a new SoC / CPU in the Mini and the
Librem 14, we need to move to a new kernel for these new devices. The good news is that the Byzantium kernel appears to fit our needs. The Mini that I have here is a Intel Coffee Lake i7-8565U @ 1.80GHz with 8 Cores.
uname -a; "Linux 5.9.0-1-amd64 #1 SMP Debian 5.9.1-1 (2020-10-17) x86_64 GNU/Linux"
/etc/os-release; VERSION_ID=10.0 VERSION_CODENAME=byzantium
Everything has been working quite smoothly except for some issues around accessing our repos; https://tracker.pureos.net/T960
Let me add that we (as discussed) started uploading Librem 5 related packages to byzantium. As of now we avoided uploading patched gtk, g-c-c, g-i-s, webkit, epiphany, ... but that is bound to change in the next couple of days. The rule for byzantium there is: - must be a regular (non-sloppy) build - if the software is not adaptive per se it need to figure things out by itself e.g. based on the form factor or the dowstream GTK toggle we have.
This will also lead to some consolidation e.g. on the g-i-s side and the aim is certainly to not break the laptop use case but i just want to bring this up since the automatic testing you mentioned in earlier reports would become even more useful now.
Cheers, -- Guido
I have an ISO with the installer that Matthias has fixed up and we hope to have a Go / No Go decision with that image for tomorrow (Wednesday).
- Amber should likely have a EoL date. I feel like that should be a
sort of LTS style approach and say we'll support Amber for two more years. We still sell some products (Librem 15, server) with Amber still on it and enterprises expect longer support so something along those lines seems sensible. Feedback most welcome.
- Can we deliver an installer that supports EFI? I realize this has
been a goal for a while and that there is work still needed to be done for this and we have the usual resource constraints. What more needs to be done?
Thank you!
PureOS-project mailing list PureOS-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
On Wed, 2020-11-25 at 14:04 +0100, Guido Günther wrote:
Hi Jeremiah, On Tue, Nov 24, 2020 at 02:11:02PM -0500, Jeremiah C. Foster wrote:
Hello,
Some bits from PureOS;
Due to the fact that there is a new SoC / CPU in the Mini and the Librem 14, we need to move to a new kernel for these new devices. The good news is that the Byzantium kernel appears to fit our needs.
Let me add that we (as discussed) started uploading Librem 5 related packages to byzantium.
Do we need to have another version of the "blessed builds" documentation for the new pipelines and build process? I think that documenting the end-to-end process of building a package for the Librem 5 might be useful for third party developers. I'm happy to work on this but will need a bit of guidance.
As of now we avoided uploading patched gtk, g-c-c, g-i-s, webkit, epiphany, ... but that is bound to change in the next couple of days. The rule for byzantium there is:
- must be a regular (non-sloppy) build
- if the software is not adaptive per se it need to figure things out by itself e.g. based on the form factor or the dowstream GTK toggle we have.
This will also lead to some consolidation e.g. on the g-i-s side and the aim is certainly to not break the laptop use case but i just want to bring this up since the automatic testing you mentioned in earlier reports would become even more useful now.
Yes, it seems like now is the time to implement this. Just to be clear, you're looking to test the resulting Librem 5 image? Or just packages in the Byzantium distro? This makes a difference of course in how we run the automated QA.
Regards,
Jeremiah
Hi, On Tue, Dec 01, 2020 at 01:05:23PM -0500, Jeremiah C. Foster wrote:
On Wed, 2020-11-25 at 14:04 +0100, Guido Günther wrote:
Hi Jeremiah, On Tue, Nov 24, 2020 at 02:11:02PM -0500, Jeremiah C. Foster wrote:
Hello,
Some bits from PureOS;
Due to the fact that there is a new SoC / CPU in the Mini and the Librem 14, we need to move to a new kernel for these new devices. The good news is that the Byzantium kernel appears to fit our needs.
Let me add that we (as discussed) started uploading Librem 5 related packages to byzantium.
Do we need to have another version of the "blessed builds" documentation for the new pipelines and build process? I think that
For core apps nothing changes there atm. Except that we're
- building from the `pureos/byzantium` git branch - have `byzantium` in the changelog. - use a slightly different versioning scheme (see separate mail)
documenting the end-to-end process of building a package for the Librem 5 might be useful for third party developers. I'm happy to work on this but will need a bit of guidance.
Since we drop the separate suite for byzantium (to not work around but work *with* laneakia and hence have proper package transitions and updates from Debian not overriding phone versions or have Matthias to force migrations, etc.) there's also no 3rd party maintenance atm since we don't have a suite in the archive for that
So to somewhat rephrase what i raised before: do we want a separate suite for 3rd party software corresponding to amber-phone (name e.g. byzantium-apps or byzantium-l5-apps) bringing back all side effects we're currently trying to get rid off?
These would then come from the /Librem5-apps gitlab space and we'd need indeed more docs.
But my understanding so far was:
- amber: Phone specific packages go to amber-phone (including 3rd party apps)
- byzantium: All packages go to byzantium proper and 3rd party apps use another distribution path (e.g. flatpak).
If that's not correct we'd need to introduce a suite for 3rd party apps first.
As of now we avoided uploading patched gtk, g-c-c, g-i-s, webkit, epiphany, ... but that is bound to change in the next couple of days. The rule for byzantium there is:
- must be a regular (non-sloppy) build
- if the software is not adaptive per se it need to figure things out by itself e.g. based on the form factor or the dowstream GTK toggle we have.
This will also lead to some consolidation e.g. on the g-i-s side and the aim is certainly to not break the laptop use case but i just want to bring this up since the automatic testing you mentioned in earlier reports would become even more useful now.
Yes, it seems like now is the time to implement this. Just to be clear, you're looking to test the resulting Librem 5 image? Or just packages in the Byzantium distro? This makes a difference of course in how we run the automated QA.
I'm mostly after automatic tests for amd64 (which could even happen in a VM). Per device L5 or Laptops testing would go on top later on.
Cheers, -- Guido
Regards,
Jeremiah
PureOS-project mailing list PureOS-project@lists.puri.sm https://lists.puri.sm/listinfo/pureos-project
-
Guido Günther -
Jeremiah C. Foster