[deleted]
evert I am in no hurry. I have faith in the solus team
evert I am in no hurry. I have faith in the solus team
You can watch JoshStrobl build it for us here:
As GNOME 3.34 worked on Nvidia problems, i hope the gaming on GNOME based environments can get better.
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
Well, it's a good thing I'm the developer of Budgie then, right?
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 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.
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...
Yea, 100% an Arch Linux issue
Good job @JoshStrobl
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.
Junglist Love Solus 3,000
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 >.<
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?
crom5 Is there any hope for the Nautilus upgrade anytime soon?
No.
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!
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?
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
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.
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.