When is Crimson coming?

… 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.


I think you are missing the point. Volunteers are under no contractual obligation to do anything. This is the weakness in this sense.

On the other hand if you are paid to do something, you are under a contractual obligation to complete the thing you were paid for. You getting burned out, or whatever else can still happen, but you are accountable to this obligation. Furthermore there is generally a mechanism is place that will fire you and hire someone else who is not burned out, or otherwise not performing. Sounds cold but is true.

Furthermore, professional products die, because of a lack of funding, not because of a lack of work.

Volunteer products die from all of the above. There is no insolation. We can sit here and kum by ya all day long about the virtues of volunteer efforts, but history tells us repeatedly in the OSS world just how far those good wishes and feelings actually go. It is paid development in the form of Red Hat and Canonical that is moving this effort forward by and large. Paid development across wine / and Proton via Valve, as another point. Paid development sees progress.

That is my point.

1 Like

I don’t disagree with what you said in general. That said, I think it missed the specific point of the conversation.

My comment was specifically in regard to Debian and their ability to provide support to their distributions. Gunther made the point that the “Debian Security Team” was a volunteer team (which I knew) so one shouldn’t be concerned about “volunteer or not” in regard to the “Debian LTS Team”. [Aside: Gunther also made the point that the “Debian LTS Team” was not a completely volunteer team (which I didn’t know; it has volunteers and there are companies such as Freexian, credativ, and others that provide money for their devs to commit some specified number of hours on LTS support).]

My point was that, regardless of “volunteer” or “not volunteer”, there is cause for concern when Bullseye moves from updates by the “Debian Security Team” to updates by the “Debian LTS Team”. I’ve now shown two important CVE’s that have not been patched by the LTS Team for Buster. At this point I actually trust the “Security Team” (which is “all volunteer”) more than the “LTS Team” (which is not “all volunteer”).