Gnome 3.34

TarsolyGer

On Arch Linux, installing the updates to Gnome 3.34 breaks the Budgie DE really bad, it crashes with 'oops something gone wrong' on a white screen when logging in.
So be careful when implementing 🙂

kyrios

TarsolyGer This also shows the difference between bleeding edge and curated rolling releases.
Personally, I would advise to prefer using the DE at the source (Budgie on Solus, Cinammon on LinuxMint, Pantheon on ElementaryOS, ...). If you don't, then use them on Fixed point release distros to make sure it's properly tested.

Running after new versions is always a risk, unless you stick to the main Arch repo, avoid Community and AUR, you'll always have to refrain updating, checking carefully what's going to be updated and waiting for community bug reports.

That's one of the reason ArchLinux isn't targeted for anyone.

Regarding Budgie, you should follow this: https://bugs.archlinux.org/task/63849?project=5&string=budgie-desktop

JoshStrobl

Well, it's a good thing I'm the developer of Budgie then, right? 🤔

TarsolyGer

JoshStrobl That's why I thought to give you a heads-up on the issue that's going on 😛

kyrios Thanks, I'm on the bug report and also following up the forum discussions. The beauty of Arch Linux is that I could just roll back my stuff to a date when everything worked even without a system backup (silly me), so I don't lose productivity while these issues are ironed out. I understand that Arch's assumption that "all software should always work with the newest version of its dependencies" is not something that is easy to follow or would ever be followed with all the software that's out, so these issues are to be expected there I guess.

JoshStrobl

From the report:

Sep 19 16:06:55 arch-laptop gnome-session[919]: gnome-session-binary[919]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Clipboard'
Sep 19 16:06:55 arch-laptop gnome-session-binary[919]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Clipboard'
Sep 19 16:06:55 arch-laptop gnome-session[919]: gnome-session-binary[919]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Mouse'
Sep 19 16:06:55 arch-laptop gnome-session-binary[919]: WARNING: Unable to find required component 'org.gnome.SettingsDaemon.Mouse'

These were moved out of GSD in 3.33.90+ and Budgie is already patched to not require those: https://github.com/solus-project/budgie-desktop/blob/master/src/session/meson.build#L57 Furthermore, gnome-session was already updated to reflect the GSD changes.

Not to mention we don't actually need those, we never utilize them in Budgie. Someone is reporting the same issue but on GNOME, so very much not a Budgie issue but rather something on Arch Linux's end. Not my problem, use Solus 🤷‍♂️

The beauty of Arch Linux is that I could just roll back my stuff to a date when everything worked

The beauty of Solus is this update wouldn't ever get to you in a broken state in the first place...

JoshStrobl

Yea, 100% an Arch Linux issue

ruskofd

Good job @JoshStrobl 😃

Junglist

This thread really makes me appreciate that I switched to Solus from an Arch base (the previous distro I've used the longest was Antergos) even more 😁

[feelsgoodman]

I'm looking forward to when it's finally available.

Your work is greatly appreciated @JoshStrobl

That's the beauty of a curated rolling release. You get to use mostly new stuff, but without the headache of bleeding out on the edge like on something Arch-based.

It's VERY nice to feel safe when performing updates.

Tbh before I had found Solus, I never would've even guessed I could be so happy with a distro. Even then I had been using Linux for a while and I was happy with it, but it was Solus that somehow miraculously managed to push it to over 9000.

Scotty-Trees

Junglist Love Solus 3,000 😉

TarsolyGer

Junglist

Yeah unfortunatelly the folks packaging the community package for Arch seems to have made a mistake 🙁 Luckily the budgie-desktop-git from the AUR works like charm. Except for the tray icon bug, that was not present previously, but as I see has already been reported here on the bug tracker, so I'm not gonna give you extra complaint on that one 😉

Keep up the good work!

JoshStrobl

Upgrade is now available for those on unstable. see this task on our development tracker.

Now I shall wait a bit for someone on unstable to update, report back, then I'll be off to bed. Just pushing the packages took 14 hours (not to mention the days of actually working on the package updates, testing, etc.) and I'm tired >.<

crom5

Very thanks to all the Solus Team for your hard work 🙂

One question: after almost 2 years I'm still experiencing this annoying 'gedit/LibreOffice' bug on both Asus and Lenovo laptop:
https://dev.getsol.us/T4946
video:

If I remember well, during all that time everything has been upgraded (even more than once) except Nautilus. Is there any hope for the Nautilus upgrade anytime soon?

JoshStrobl

crom5 Is there any hope for the Nautilus upgrade anytime soon?

No.

emersoncavalcanti1972

Firstly, excellent work by the Solus team in making Gnome 3.34 packages available. Actually the performance improvements are significant and the system is fluid and without apparent bugs. I just noticed the absence of the "Application Folders" feature that in this release come as native. Does anyone know what happened?

JoshStrobl

emersoncavalcanti1972 I just noticed the absence of the "Application Folders" feature that in this release come as native. Does anyone know what happened?

It's an upstream issue. https://discuss.getsol.us/d/2847-gnome-desktop

emersoncavalcanti1972

I found out what you need. Have a key that needs to be modified using gsettings:

gsettings set org.gnome.desktop.app-folders folder-children "['Misc']"

It is now working correctly. This key is apparently coming incorrectly in the Solus installation itself, as I did a clean install.

Anyway, thank you for your attention.

JoshStrobl

emersoncavalcanti1972 This key is apparently coming incorrectly in the Solus installation itself

No it isn't. Otherwise it wouldn't be an issue in Arch and literally reported upstream to GNOME Shell. Just because we don't configure it doesn't mean upstream shouldn't be (or handling cases where it isn't set).

Closing to prevent further necroing.

« Previous Page