• [deleted]

evert I am in no hurry. I have faith in the solus team 🙂

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 🙂

    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...

      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.

        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.

          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!

          17 days later

          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?

            17 days later

            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.