I wanted to let folks in this thread know that I’ve added Byzantium to my /etc/apt/sources.list and have done a full upgrade and everything appears to be working well. This is what you can do if you want to test the rolling release;
Edit /etc/apt/sources.list or add an entry to/etc/apt/sources.list.d/
Add these repos;
deb https://repo.puri.sm/pureos byzantium main
deb https://repo.pureos.net/pureos byzantium-updates main
deb https://repo.pureos.net/pureos byzantium-security main
Run sudo apt update && sudo apt full-upgrade
Please note, this is an early release, it is meant for testing, not production.
I have added the Byzantium repos and can confirm that so far things seem to be working. I performed the upgrade and my Librem 13 restarted without a hitch. I’m now running GNOME 3.34. Thanks! I’ve been waiting to update to the latest version of GNOME since receiving the laptop.
I have several dependency issues regarding mutter for example if I’m trying to update.
So I’m waiting a until byzantium is more tested and officially released
I added the sources updates and security, I main I had added lastly. Now I have about 800 packages, which I have to upgrade in batches again. For example freecad makes problems.
Ok, did an upgrade today (removed mutter inbetween) and switched from pureos-gnome to vanilla gnome and apart from a few extension errors etc. - everythings fine!
I just did the update from amber to byzantium after today’s blogpost (Byzantium arrived).
I had to reinstall 2000+ packages, of those were 90 new ones and I had to deinstall some 80 packages afterwards. All was done automatically by apt and worked like a charm.
I now run Linux 5.3.0-3-amd64 with the latest Gnome shell. Looks super nice and feels awesome, too, to be on the cutting edge again.
Thank you for your and your team’s hard work, @jeremiah
Have some well deserved holidays.
Nice! I have done the upgrade as well, it couldn’t have gone smoother (ThinkPad T430). After upgrading the amber installation, rebooting and then changing the apt sources.list to access byzantium repos:
apt update, apt upgrade, apt full-upgrade and finally apt auto-remove
I would like to ask a dumb question: It is my understanding that a “rolling release” means that the system is continually updated and that the idea of “point releases” does not apply. The advantage is supposed to be the absence of disruption in the upgrade to a major point release. The downside is a series of minor incompatibilities and instabilities that motivated point releases in the first place.
OK, so what do you call the difference when every update in PureOS requires a double reboot and every update in MX Linux happens without any reboot, including kernel and init updates?
Whatever we call that (eg, “sans reboot updates”) is what I want.
Yes, you’re understanding is correct. (Or at least similar to my understanding.
I don’t know much about MX Linux except that it appears to be based on Debian Stable. This means that they likely don’t update the kernel to newer major versions. New kernels will need to be booted, at least if you want to use them, otherwise you can just update and keep on working. The same is true for many daemons on the system, they need to be restarted, but you can either do that on the fly with systemctl or you can wait for reboot. The only caveat with waiting to restart system services is that you may have received a bug fix so restarting services might offer greater security.
If you’re looking for high availability, then there are other architecture approaches, like using a container or a Virtual Machine, but even those need reboot occasionally. You can look at Criu if you need something even more robust.
In ArchLinux you always execute pacman -Syu and the whole system gets upgraded. No editing of config files. So in what sense is PureOs rolling ? Does the above addition (of the lines in /etc/apt/sources.list) means that one has to wait for a new announcement from you? Or having the byzantium repos the distribution will roll always without adding more lines to sources.list ?
The editing of config files is a one-off process to change from Amber (stable) to Byzantium (rolling) i.e. change from one repos to another.
In either case, Amber or Byzantium, no further action is required on the part of the user in order to see updates automatically as they become available. Regardless of repos, the same apt commands will apply whatever updates are available using the command line when explicitly requested if the user prefers that.
The difference between Amber and Byzantium will be in
a) the relative timing of updates if both repos get the same update, and
b) the scope of updates - Amber will typically only get bug fixes including security fixes on a day to day basis
Ah, thanks. That is great. So any time I can now upgrade my system. But then how are the names Amber and Byzantium chosen. If they are always the same (Amber=stable
and Byzantium=rolling) the choice of names sounds strange. Why it is not “stable” and “rolling”. This is what confused me. I thought I had to expect another code name in the future.
I’m asking about “sans reboot” updates for PureOS. Why do I have to enter my encryption password twice and my login password once to update an app that isn’t even running?
My comment about MX Linux was simply to indicate that other distros don’t demand instant reboots, even though some updates, such as kernel updates, won’t take effect until a reboot (thanks, Jeremiah).
I shutdown my Purism laptop every couple of days, I can wait for a kernel update, or reboot manually. But don’t force reboots to update a library I don’t even use.
Politely now, I ask “Could we have “sans reboot” updates in PureOS like some other distros do?”
Understanding that this doesn’t require rolling releases. (MX Linux is a point release distro.)
Just go into the terminal and type sudo apt update
and sudo apt upgrade
This will update all packages that can be updated and not force a reboot. It will tell you if a reboot is needed for an update to take effect if needed.
The reason the graphical updater requires a reboot for updates is that it is considered “safer” and/or “cleaner” to update packages in a specific environment designed for updates.
I think you need to refer that question to Purism. I could speculate but in this case I don’t think speculation from me is helpful, particularly as it might relate to whether these names will always remain the same in the future.
