ok thank you, so to be clear, staying on amber is recommended for stability, and byzantium for bleeding edge? So at some point in the future, will there be a stable release based on byzantium, or will the next pureos be based on debian stable? I apologize for the questions, but its pretty interesting and slightly confusing.
2 Likes
This discussion could become confusing because Purism has not yet said what the naming convention will be when the opportunity is there to move to a new stable release, at least as far as I know.
In principle, Amber could remain forever stable and Byzantium could remain forever rolling - even though both jump to new releases.
Or, as hinted at with the naming, and probably safer and more consistent with other distro practice, Purism could move to C* and D* colors - so that Byzantium remains a rolling release but is in fact relatively stable and dormant (perhaps only receiving required security updates for a period of time) and all Amber users should upgrade to C* while all Byzantium users should upgrade to D*.
Then the distro itself will be release-based but the name will be rolling (alias). It’s the same as if you call debian-stable and debian-testing to be rolling releases but they are not, they are merely pointers to current release snapshot. It is stabilisation (freeze) phase which differs true rolling from release-based distribution. Freeze means release stops receiving new packages, only patches, thus diverging further and further from the upstream.
I was trying to use once pointing to the alias rather than specific release, but in the essence it doesn’t solve anything - you still have dist-upgrade hassle on each release cycle.
1 Like
I did a fresh install of PureOS Amber in order to have a working system. Now I’m wondering how I can know when I can upgrade to Byzantium without bricking my system again? Does this dependency problem effect everyone on Byzantium doing the update? It seems not many people are effected by this.
I probably haven’t been affected thanks to reports from Linuxnoob and you, so I stopped applying updates daily, as my Librem with PureOS is the only machine I can currently use for working from home. 
I looked again at Byzantium updates for my system a couple of hours ago, but I haven’t been able to infer from version numbers changes and Debian error report mentioned in Gnomeshell crashes after update from 25/26th of april - byzantium whether it has been fixed in Byzantium.
1 Like
If you require greater stability please wait for Byzantium to become stable. Since Byzantium is a rolling release you will face the occasional issue, like this one.
1 Like
I can confirm issue on my machine and am working on finding a fix.
1 Like
I was also hit by this issue over the weekend. I tried installing xfce and kde Plasma with no luck. Since I have most of my data backed up and stored separately from my OS, my quickest solution was to start over with a different distro, since the version of GNOME in Pure OS Amber is older than I like. But if I had not already isolated by data, I could have been screwed.
I was under the impression that while PureOS Byzantium was less tested than Amber and more likely to have bugs, that there was still someone checking the updates before they went out to users (as in the system may crash more than usual, but it will at least boot). Was that an inaccurate assumption?
Byzantium is less tested. Updates from Debian are imported directly as binaries for a couple of reasons, not least our effort towards convergence. Since they are binaries imported directly from Debian testing they are not manually checked and a GNOME transition has snuck in causing a bit of havoc. I think it is resolvable but I’m hoping to provide a quick way to fix the system in lieu of having to wait for automatic updates.
I’m running both Amber and Byzantium here on two different Librem. Byzantium is broken for me too, trying to find a fix. This should not affect Amber.
Here is our naming scheme;
Amber = Stable = Security fixes and other updates from Debian Stable
Byzantium = rolling release = New software, new updates, new bugs
4 Likes
Getting this output on apt dist-upgrade now:
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages were automatically installed and are no longer required:
apg apt-file cups-pk-helper flatpak gir1.2-appstream-1.0 gir1.2-packagekitglib-1.0
gnome-control-center-data gnome-getting-started-docs gnome-online-accounts gnome-software-common
libappstream-glib8 libapt-pkg-perl libcolord-gtk1 libexporter-tiny-perl libflatpak0
libgoa-backend-1.0-1 libgspell-1-1 liblist-moreutils-perl libnss-myhostname libostree-1-1
libpipewire-0.2-1 libpython3.7 libregexp-assemble-perl librygel-core-2.6-2 librygel-db-2.6-2
librygel-renderer-2.6-2 librygel-server-2.6-2 pureos-init-disk-crypto python-apt-common python3-cups
python3-cupshelpers python3-distro-info python3-pycurl python3-smbc realmd rygel
system-config-printer-common system-config-printer-udev xdg-desktop-portal xdg-desktop-portal-gtk
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
command-not-found gnome-contacts gnome-control-center gnome-initial-setup gnome-software
gnome-software-plugin-flatpak isenkram-cli libgnome-desktop-3-18 libmutter-5-0 libphobos2-ldc-shared88
pureos-gnome python3-apt python3-software-properties software-properties-common
software-properties-gtk unattended-upgrades
The following NEW packages will be installed:
liborcus-parser-0.15-0 libphobos2-ldc-shared90 linux-image-5.6.0-1-amd64
The following packages have been kept back:
fwupd-amd64-signed
I… think I’ll hold off the upgrade for now. Auto-removing some of those things doesn’t sound too great.
I got such a small dependency hell as well, and, always using aptitude, selected manually a bunch of packages pureos-gnome and pureos-desktop implied as dependencies and that I wanted to keep, as I wanted to see if these updates could help avoid frequent libreoffice crashes I had and also some printing issues.
Fortunately, GDM and Gnome shell issues reported a couple of weeks ago are solved now, even if some non-core Gnome packages cannot be updated yet because of conflicts or missing dependencies.
I will also still hold back with upgrading back to byzantium until all issues are resolved.
It says “no longer required.” If, for instance, you updated gnome, all the old gnome stuff would no longer be required.
I’m missing the context of your upgrade situation, though, so I can’t say for sure what you should do.
1 Like
you can make a snapshot if you’re worried before commiting to auto-remove …
It looks like the reason that fwupd-amd64-signed is held back is that libflashrom1, a dependency of fwupd is missing from the repository.
That’s correct. However it’s not old stuff it’s removing in this case, but half my system.
I suppose you didn’t disabled Amber from sources list (including amber-proposed-updates main as well) which I find all right. Next, you wrote you added Byzantium as @jeremiah described. But second step: sudo apt update && sudo apt full-upgrade is not an option for you, for your system. How about: sudo apt update && sudo apt upgrade as apt man page defines: upgrade is used to install available upgrades of all packages currently installed on the system from the sources configured via sources.list. New packages will be installed if required to satisfy dependencies, but existing packages will never be removed. If an upgrade for a package requires the removal of an installed package the upgrade for this package isn’t performed.
After running sudo apt upgrade command and if choosing: Yes, reboot and run: sudo apt autoremove --purge just to proof if above satisfies your expectations from Byzantium repository.
I moved to Byzantium a few months ago, and I didn’t leave anything of Amber in apt sources lists, but I had the same problem as @vmedea. I think this results from an incompatibility or conflict in current Byzantium repositories between versions of dependencies of some packages, which lead apt to propose deleting base meta-packages. I didn’t want to remove “half my system” either, but I definitely wanted to upgrade certain packages, so I chose to remove those base packages and manually select packages to keep for a working OS; this may require more massaging of package selections in updates until these conflicts are solved.
After recent Gnome updates in Byzantium, I still experience frequent crashes of gnome-shell, especially after unlocking the screen; I suspect the extensions set I use (a mix of a dozen of Gnome extensions installed from either Byzantium repositories or extensions.gnome.org web site) to contribute to this instability, so I started using KDE Plasma.