brent Theme problems with Gnome 43, on the one hand, and Nautilis and other apps, on the other, have been reported on the web recently.

As Staudley explained, "The GNOME project keeps moving more and more apps to libadwaita theming, the latest being, among others, the file manager Nautilus. This means that it no longer respects the system GTK widget theme (as set in e.g. Budgie Desktop Settings), and also might not adjust to dark themes correctly."

While the problem surfaces in Solus DE's that are Gnome-based, as reported in this thread, the problems do not appear to be confined to Solus. That doesn't surprise me. Upstream/downstream problems are common in Linux, and take a while to resolve, given the large number of interlocking pieces and the lack of coordination between the developers of the various pieces.

It is almost inevitable that when a major upstream component changes, problems will need to ironed out downstream. No magic wand.

    tomscharbach many gnome-linked web sources I'm reading are distinctly advocating for magic and/or a magic wand to be employed in this stack update, but I'm more inclined to believe your version.

      brent Many gnome-linked web sources I'm reading are distinctly advocating for magic and/or a magic wand to be employed in this stack update, but I'm more inclined to believe your version.

      Gnome is forcing a change in the direction of libadwaita, and that is a given that all Gnome downstream distros and apps are going to have to work out.

      It is too bad that Solus Budgie got caught in the mess, but other Budgie-based distros are also caught, as I know from other forums relating to those distros. I haven't been following BuddiesOfBudgie lately, but I expect that Budgie 11 will have adjusted one way or another. In the long run, Budge might be best served by moving away from Gnome. Along with my magic wand, my crystal ball has disappeared, so I have no idea whether that is going to happen, in whole or in part.

      I've been aware of the potential issues for several months from another forum, and I was worried about how Budgie would have to change in order to make the adjustment. I involuntarily dodged the bullet because hardware changes in my Solus setup (the fractional scaling issue) forced me to move from Solus Budgie to Solus Plasma a few months ago, so I'm not directly affected.

      I've seen dislocations like this happen over and over again. It is a consequence of the way in which the Linux community works -- with the exception of a small number of enterprise-focused desktops (where upstream/downstream planning is more centralized and tighter standards enforced), dislocations like this happen because upstream/downstream coordination is spotty, at best.

        Another issue for me this morning, can't drag anymore a file to extract it from the archive manager to nautilus.
        No drama but a little bit annoying.

        I just updated, and got this. Forcing reinstall of the package doesn't fix it.

        $ sudo eopkg check gdk-pixbuf
        Checking integrity of gdk-pixbuf Broken
        Corrupted file: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

        UPDATE: Oddly enough I --reinstall'd it for a third time and now it's fine. Weirdness

        sudo eopkg check gdk-pixbuf
        Checking integrity of gdk-pixbuf OK

        Side note, THANK YOU for EOPKG, the best package manager ever. I wouldn't even have known I had a broken package if it weren't for eopkg check.

          Ok more weirdness. Just updated my laptop, same broken package gdk-pixbuf. It took --reinstall on it twice before it reported as OK.

          Something wrong with this package in the repo?

          zmaint $ sudo eopkg check gdk-pixbuf
          Checking integrity of gdk-pixbuf Broken
          Corrupted file: /usr/lib64/gdk-pixbuf-2.0/2.10.0/loaders.cache

          This was discussed in another thread, and it is a non-issue that can safely be ignored:

          From @joebonrichie

          Ah the broken gdk-pixbuf package is due to the pre-compiled loaders.cache file getting overridden by the new usysconf trigger for gdk-pixbuf. I'll remove the pre-compiled loaders.cache file and let usysconf handle it exclusively. It is nothing to worry about in the mean while.

          From @Staudey

          You can safely ignore this issue for now. Will disappear with the next update. As Joey and I explained above that's just a consequence of the automatic way in which we handle the gdk-pixbuf loader cache now. Starting with the next update, the loaders.cache will be completely dynamically generated on the user system and therefore no longer tracked (and complained about) by eopkg check.

          If you encounter the error again before the next update, you can run the general troubleshooting command from the terminal: sudo eopkg check | grep Broken | awk '{print $4}' | xargs sudo eopkg it --reinstall and that will fix it. But the best advice is to ignore it for now.

            tomscharbach If you encounter the error again before the next update, run the general troubleshooting command from the terminal: sudo eopkg check | grep Broken | awk '{print $4}' | xargs sudo eopkg it --reinstall But the best advice is to ignore it for now.

            In fact it's actually even better to ignore it than to run the repair, as the loaders.cache file needs to be updated (if you for example install the webp loader), while the reinstall will reset it back to the old version. So my recommendation is to leave it alone until the next update.

              alfisya now, this is embarassing to say but all of those problem mostly my own fault.

              1. Theming problem caused by already using patched gtk3 theme and libadwaita viaGradience. I forget that i used it, decide not to like it, patched it to default. After it is patced via Gradience, normal means of light and dark mode settings via gnome-control-center doesn't work anymore except Flatpak apps (Gradience warns me before every time).
              2. Enabled extensions crashes gnome-shellcaused by one extension called Pano (Clipboarding tool). Journalctl says it is related to libsoup as there is two version of it confilcted or just Pano doesn't like it.

                alfisya Enabled extensions crashes gnome-shellcaused by one extension called Pano (Clipboarding tool). Journalctl says it is related to libsoup as there is two version of it confilcted or just Pano doesn't like it.

                Both versions of libsoup can be installed together fine, but programs can only use one version or the other. This also means that all the dependencies of a program must also use the same version of libsoup, else you get the segfault error you mentioned.

                Where do you get Pano from? Most likely one of the libraries it depends on now uses libsoup-3 but Pano itself wants libsoup-2.

                  Silversurfer I have that one, along with a bright "garish looking white" on other backgrounds.

                  I like Budgie, but might give Solus KDE Plasma distro a spin.

                    PC-TECH I like Budgie, but might give Solus KDE Plasma distro a spin.

                    I used Budgie from 2017 until a couple of months ago. I moved to Plasma because fractional scaling became a critical requirement, and Budgie didn't cut it in that regard. It took me a few weeks to get used to Plasma, but the Solus implementation is excellent. I'm hooked.

                      tomscharbach I moved to Plasma because fractional scaling became a critical requirement

                      I got 4K monitor to avoid fractional scaling issues on Budgie! 😛
                      Budgie for life!

                        tomscharbach In the long run, Budge might be best served by moving away from Gnome.

                        It seems to mike that if a DE is gonna use Gnome stuff, it is gonna need to use Libadwaita or suffer side effects such as we've been facing for months.