When is Crimson coming?

let’s make a bet, is Crimson or Trixie coming first? I bet Trixie lol

1 Like

This is important. Although “Buster” says that it is supported until June 2024 … that is LTS support and it is not necessarily supported by the security team anymore. So, for example, Buster has not received any patches for the recent flatpak CVE ( CVE-2024-32462 ). I think the security team stops the coverage when the release moves to LTS. I’ve watched that CVE because the patch is simple (something like 12 lines) and it hasn’t been patched yet in Ubuntu 22.04 (Canonical doesn’t make promises about patching packages in their
“Universe” (non-“Main”) repository).


… which is a bit slack because the Ubuntu 22.04 LTS-to-Ubuntu 24.04 LTS upgrade is not available yet as far as I know. In other words, a customer who uses only the LTS versions, hopping from one to the next, is actually on the latest LTS version with 22.04 (unless the customer wants to wipe everything out, install 24.04 from scratch and then re-establish everything).

I don’t know the exact timing but I expect that the above upgrade will appear in the next few months.


… … which is a bit slack because the Ubuntu 22.04 LTS-to-Ubuntu 24.04 LTS upgrade is not available yet as far as I know. …

It’s available. It’s not recommended. You have to add a flag (-d) to the do-release-upgrade. Of course one always has the choice of doing a fresh install. I suggested that maybe they should release flatpak as a snap.

It is slack. While Canonical said that they haven’t changed anything in regard to facilitating security updates in “Universe” … I think they used to be a bit more on top of high level CVE’s from active community projects.


OK. I should clarify that I mean: At a certain point in time, in the next few months, the Ubuntu GUI software updater will notice that the LTS upgrade becomes recommended, and it will offer it to everyone who has not taken either of the alternative steps that you mention (and who has configured to install only LTS versions). So it will happen automatically with a click of a button, rather than having to take special steps.

As Canonical is intentionally making it the case that we have not yet reached that “certain point in time”, they should consider that everyone in this situation is missing out on some security updates (in this case, a high severity one).

I guess ultimately they want you using snaps, not flatpaks.


PureOS development is slowly ramping up again after Purism revamped its cashflow and inventory financing and is now better living within its means. Better cashflow and recently increased sales are dissolving much of the debt that had become a blocker for most ongoing development efforts. Despite it being paramount in a tech company, R&D is ultimately a cost center; weight had to temporarily shift toward profit centers - marketing, sales, etc - for long-term survivability. Finances are now looking more promising and we’ll proceed with an internal PureOS development crowdfunding campaign (timeline TBD but expecting within a month or two, pending planning+infrastructure+webdev efforts) then keep the momentum to increase hours of contractor staff toward full-time. I can provide more concrete answers once several unknowns are resolved.


The Debian Security team is all volunteers too and they’re doing a great job.


it will be available in October, I tried upgrading distribution from 23.10 and experienced tons of issues always ending up with a broken system due to the install failing in various ways, package dependency issues and screen even shutting down during package install

1 Like

I’ve never had a problem. However, I only run LTS and always wait for the first point release.


So what? i.e. Your statement proves nothing.

I agree that the Debian Security team does a great job. But note that nobody has patched the LTS release for this pretty high CVE for a highly used package (flatpak) CVE-2024-32462. To be clear: The security team did patch what they are responsible for … but the LTS release (currently Buster) is still unpatched. That’s cause for concern that the volunteers from the non-security team might not be up to the task, right?


@kms said it would give him concerns that the LTS team is volunteers (LTS isn’t all volunteers btw). I made the point that “all volunteer teams” can work fine and that it doesn’t give indication about the quality of the work done.

Your statement proves nothing.

I don’t have to proof anything to you.


I’ve given evidence that the LTS team is not addressing CVE’s as well as the security team. In other words @kms absolutely has cause for concern.

And while I agree it has nothing to do with “volunteer” or “not volunteer”, it’s a concern.

That’s “prove” not “proof”. And, no, you don’t. I didn’t ask you to prove anything. My statement was simply pointing out that you didn’t prove anything. We wouldn’t want anybody confused on whether you are asserting that the LTS team is as good as the Security Team in providing security patches.

[Edit: I was reading about another vulnerability from January 2024. CVE-2024-1086 . I thought
I would check this one too. Again the Security Team has patched it in their distros. Not true for the LTS Team. CVE-2024-1086 ]


I’m still walking around with Byzantium L5 in my pocket. If I go around with a Crimson install instead, what types of issues would I expect to face? Or where should I read about that?


“Red” flags? (Duck)

1 Like

Can one just upgrade to crimson? like a normal debian dist-upgrade changing sources.list?

1 Like

No. It has to be a reflash (if you want to work).


I disagree, and say that volunteer does matter in this case. Sure you can have a volunteer which is ate up and totally dedicated to giving all of their time to development, but this is extremely rare and not the norm in any way. Rather what happens is strong energy and then life happens, burn out happens, project stall, projects die.

On the other hand, paid development does not follow this trend. When you are paid to develop you have a commitment to complete the tasks. You can’t just walk away without more serious consequences.

The Librem 5 needs paid developers with reliance on them primarily.


Burn out can still happen. :slight_smile:

Projects do also stall and die.

However this is all generalisation, that may not be useful as it applies to one specific project.

It may also be overtaken by events, as the wheels, apparently, are starting to turn again on crimson.