Page MenuHomeSolus

Upgrade to latest GNOME Stack (3.28)
Closed, ResolvedPublic


With the release of GNOME 3.28, as always we will defer until the release of a .1. This task serves the purpose of acknowledging that GNOME 3.28 exists and it's on our radar to perform a stack upgrade.

This stack upgrade is not a priority and will need to be done alongside releasing another Budgie release that has GNOME 3.28 compatibility and introduces features like our own desktop icon implementation (given that's been deprecated from Nautilus), as well as accounting for any GNOME Settings Daemon and Mutter changes.

Event Timeline

JoshStrobl renamed this task from Upgrade to latest GNOME Stack to Upgrade to latest GNOME Stack (3.28).Mar 14 2018, 3:37 PM
JoshStrobl claimed this task.
JoshStrobl triaged this task as Low priority.
JoshStrobl created this task.
JoshStrobl changed the edit policy from "All Users" to "Triage Team (Project)".
JoshStrobl updated the task description. (Show Details)
stigarn added a subscriber: stigarn.
pokgak added a subscriber: pokgak.Mar 15 2018, 2:11 AM
JoshStrobl moved this task from Backlog to Improvement on the Software board.Mar 15 2018, 3:33 PM
raindev added a subscriber: raindev.
bwat47 added a subscriber: bwat47.Mar 20 2018, 11:47 AM

No. I want the order with the other items as parent tasks so I know what to validate after the stack upgrade.

JoshStrobl raised the priority of this task from Low to High.EditedApr 13 2018, 7:05 PM

Now that 3.28.1 is released, I will be scheduling next Saturday post-sync as the designated time to perform the GNOME stack upgrade.

JoshStrobl changed the task status from Open to In Progress.Apr 21 2018, 5:15 AM
Jacalz added a subscriber: Jacalz.Apr 21 2018, 10:22 AM
JoshStrobl closed this task as Resolved.Apr 25 2018, 6:13 PM
JoshStrobl added subscribers: DataDrake, ikey.
IMPORTANT: Seriously read this comment.

Marking as resolved with the following notes:

  • Budgie is bork. @ikey will be working on updating Budgie to support latest GNOME Stack.
  • GNOME Builder spell checking has been temporarily disabled. It requires a new version of enchant and gspell, both of which need to be evaluated and a determination be made as to whether we need to keep the current enchant release for backwards compatibility purposes as a new package, create a dedicated enchant 2 package, etc.
  • Epiphany will not function. This is the result of us needing to rollback WebKitGTK from 2.20 back to 2.18.x, as it broke a multitude of apps and more important, GNOME Online Accounts.
  • Pantheon Terminal fails to compile against the latest Vala and GTK, and thus will not function until patched.
  • Nuvola Player will not function. This is because newer versions require DRI2, which does not seem to be included in the repos yet (still need to figure out where it actually comes from) and even if we had it, we need to disable CEF support because it requires Chromium, which we don't have. With CEF disabled, Nuvola Player is more-or-less useless, since a multitude of Nuvola Player "scripts" rely on it.
  • gcab and appstream-glib have intentionally been held back, primarily because appstream-glib patches for eopkg support still need to be rebased.
  • tepl and latexila have been held back. Require gtksourceview-4 and thus we need to evaluate whether the entire suite of software that relies on the current GTKSourceview will be compatible with 4.x
  • @DataDrake told me to ignore the haskell stuff related to GTK3. I wash my hands of it.

Also one last note, special thanks to:

  • @ThanosApostolou for the Metacity patch
  • @kyrios123 and @TingPing for all the flatpak work and improvements
  • @ikey for all the assistance with rebuilds, ypkg fixes, etc.
  • @sunnyflunk for pointing out an obvious issue with 32bit deps that had me stuck on building libgtk-3 for a while
  • @DataDrake for all the company on Discord
kyrios123 added a comment.EditedApr 25 2018, 6:37 PM

Well I guess we all thank you for the hours... days... nights... bah for your hard work on this stack upgrade ! ?

I will try to help with enchant but family will come from abroad to visit us so I don't know if I'll have much time for Solus in the coming days.

  • gtkspell (with patch)
  • gtkspell3 (with patch)
  • gtkhtml
  • gspell (update to 1.8.0)
  • pyenchant (with patch)
  • libwebkit-gtk
  • php (with patch)
  • geary (with patch) --- libwebkit-gtk
  • geany-plugins (with patch)
  • lyx (with patch)
  • bluefish (with patch)
  • hexchat (no rebuild required but I leave it in the list because I updated license & macros)
  • abiword (with patch)
  • lifeograph (with patch)
  • empathy --- libwebkit-gtk
  • claws-mail (with patch)
  • pluma
  • pan
  • evolution (rebuild) --- libwebkit-gtk
  • weechat

You will need both enchant versions but the latest 2.x release doesn't conflict with 1.x.

GtkSourceView 4 is a major API break so nothing else would depend upon it yet.

In terms of GtkSourceView 4, there's a multitude of software that use 3.x (gretl, gedit, various MATE packages, calculator, etc.) and doesn't make a whole lot of sense to have a libgtksourceview4 package at this moment in time (or have current go to libgtksourceview3 and libgtksourceview go to 4.x) given there's only two packages at the moment that require it.

That would make sense since the sourceview maintainer is its maintainer too. I just meant *most* applications have not transitioned and it is unlikely to be a quick unilateral move to it. So at some point (maybe not this cycle as you say) you will probably end up with both.

@JoshStrobl I guess you already are already aware of this, but just in case it seems that some of Gstreamer OpenGL libraries still remains in the -bad package while they have been moved in the -base in v1.14.

Program terminated.
File conflicts:
/usr/lib64/girepository-1.0/GstGL-1.0.typelib from gstreamer-1.0-plugins-bad package
/usr/lib64/gstreamer-1.0/include/gst/gl/gstglconfig.h from gstreamer-1.0-plugins-bad package
/usr/lib64/gstreamer-1.0/ from gstreamer-1.0-plugins-bad package
/usr/lib64/gstreamer-1.0/ from gstreamer-1.0-plugins-bad package
/usr/lib64/ from gstreamer-1.0-plugins-bad package
/usr/share/gir-1.0/GstGL-1.0.gir from gstreamer-1.0-plugins-bad package

I noticed some file conflicts between

I know. You'll get conflicts on upgrade because most of GL support was moved, as I indicated such in the changelog. R1085:34019e676eef8f23329d7a0e619277326f8d80bb

Nothing to do with the GNOME stack anyways.