Very small issue, I had to re-pin Alacritty icon to the Budgie panel after reboot because it's gone.

EbonJaeger

I just processed 54 updates (246.37 MiB) and nothing to report yet.

In fact, gnome-software-center is already the application used by Ubuntu users to process their updates.

I am a Budgie desktop user (just like our friend @brent and others), I guess this is the application we will have to use when the time comes.
Until then, we will have to continue using Solus SC and wait for your green light to migrate? unless the migration is automatic?

      I got this at the end.

      [✗] Updating clr-boot-manager failed

      A copy of the command output follows:

      [FATAL] cbm (../src/bootman/bootman.c:L520): Cannot determine boot device

      I'ts a fresh Solus Budgie install from last week.

      edit
      System did boot.

      Minor glitch with rofi update.

      The rofi-pass script had an issue: it was showing "“Rofi is unsure what to show.” instead of the usual password selection dialogue.

      A fix was found here: Rofi error prompt

      1. Edit rofi-pass script as follows
      2. At around line 843, replace: if [[ $help_color == "" ]]; then
      3. With: if [[ $help_color == "#4872FF" ]]; then

      Apparently it doesn't like an empty help_color value.

      Noted here in case any one is using rofi-pass and comes across the same issue.

      penny-farthing I guess this is the application we will have to use when the time comes.
      Until then, we will have to continue using Solus SC and wait for your green light to migrate? unless the migration is automatic?

      I don't like gnome-software; he was floating another SC for budgie/xfce last week but doesn't appear to be now.
      My own biggest fear is having terminal/cli updates all migrated to GUI (gnome-software etc) and no more terminal. we will see. I am also curious about the migration when it is moss-time. I think, which means I'm guessing, is this is all in 'we'll cross that bridge when we get there' phase because this is new territory for everyone it seems. Certainly is exciting though

          brent My own biggest fear is having terminal/cli updates all migrated to GUI (gnome-software etc) and no more terminal. we will see.

          There are no such plans. The terminal commands for the package manager will continue working as normal for the foreseeable future (and most likely for as long as Solus exists). Nobody wants to get rid of the CLI. If anything it would be more likely that the GUI applications disappear (which they also won't, there will always be a GUI way to update for a distro that isn't exclusively targeted at hardcore nerds).

            penny-farthing Until then, we will have to continue using Solus SC and wait for your green light to migrate? unless the migration is automatic?

            Please test it. Either Gnome Software or Discover is fine. You can use it side by side with Solus-sc. You can already install, uninstall, and update packages using those software centers. It can handle flatpak and even firmware update. We hope users start using those and when the time comes solus-sc will be automatically removed from your system.

            As mentioned in the post, there are still >300 packages (that provide desktop file(s)) that needs AppStream metainfo added. This means those >300 packages ( and many if not all cli packages and libraries) will not be visible in those software centers. This will be gradual process that takes time. Untill we decided that the AppStream metainfo condition is adequate for those software centers, Solus-sc will still be available. We really need new contributor to help speed those up. So, if you have spare time and have the inclination, please join the packaging room!

              Updates downloaded through gnome-software and rebooting for offline upgrades went without a hitch.

              brent My own biggest fear is having terminal/cli updates all migrated to GUI (gnome-software etc) and no more terminal. we will see.

              I swear I've addressed this before but if I did I was clearly not my usual blunt self:

              There are no plans to do that. No team member has ever suggested doing that. There would be no value add in doing that. You do not tie a package manager to a GUI, that would be stupid.

              We are working on providing eopkg 4.0 (python3 port) as a fully self contained static binary in order to lower breakage potential for when python3 and other dependencies are updated. This increases the binary size for eopkg but makes it much more resilient to stack updates and bad user practices.

              Making it GUI only would drastically increase its complexity. Slow down our ability to update things. Requiring a fully working graphical environment for package management would essentially make some issues unrecoverable. The package manager would become extremely brittle while providing literally zero benefits to developers, package maintainers or users.

              Additionally it is much easier to give users commands to copy & paste vs steps for navigating the GUI or explaining what a hamburger menu is.

              These new software centers use packagekit which is:

              A D-BUS abstraction layer that allows the user to manage packages in a secure way using a cross-distro, cross-architecture API.

              That is how these new SC's can work on so many distributions. https://github.com/getsolus/PackageKit/tree/eopkg4/backends - I know, I too am disappointed it isn't magic.

              eopkg will be eventually replaced with moss from Serpent OS, which is a CLI tool. It will need to have its own packagekit backend to work with Discover, Gnome Software, Cosmic Store.

              Which is a lot of words to say that there will always be a CLI interface for package management. It is not up for debate.

                  Whats up with nghttp3? I got that installed when I updated my system?

                    I did the sync, all went well except for something strange.

                    After all the sync was done, i.e. after "applying udev rules ... ... ... successful", I waited for 2 minutes and typed reboot

                    CLI says

                    bash: reboot: command not found.

                    My heart skipped a beat.
                    What happened?

                    I usually do a reboot after each weekly sync, this error message never happened before in 5 years.

                    UPDATE : sudo reboot does work, but I wanna just execute a reboot, did the last few syncs changed something in my bash?

                      snowee I did the sync, all went well except for something strange.

                      I noticed this as well, only I was working as root, updating my Solus VMs. So I don't understand why sudo should have made a difference.) If I have no need for a VM after it's been updated, I simply use shutdown now when I'm finished with the update. Then the update is completed the next time I start that VM. (No need to reboot it if I'm not gonna use it.) I've done that for years with every VM, Solus or not.

                      But recently that command has resulted in an error message like the one you mentioned. And, as I remember, it happens with every current GNOME-based VM except the Xfce one. (Not with my Xfce laptop, either.) In every case, the VMs still understand the restart and shutdown commands from the menu, but not from the CLI, so it's not really a big deal - just a curiosity.

                      Just one of those things that makes me go, "Hmmm."

                          Apparently the VPN stopped working after this update (I don't know if the cause is the update at the moment,but I didn't touch the settings and on the smartphone the same VPN works), zed still doesn't work (KDE Xorg), opentabletdriver seems to be showing signs of life, but I still have to figure it out...

                            snowee
                            WetGeek

                            Check to see if you have /usr/sbin in your shell's PATH. I noticed this a little while back when I tried to run ip and it couldn't find it. I assume it was because of the merge from a couple updates ago. I would assume that using sudo made it work because /usr/sbin is in the root user's PATH.

                                  FAb7D The bluetooth mouse and keyboard also lost connection...

                                  
~ $ journalctl | grep blue
.......
giu 22 22:25:07 solus systemd[1198]: Started app-blueman@autostart.service - Blueman Applet.
giu 22 22:25:08 solus blueman-applet[1499]: blueman-applet 22.25.08 WARNING  PluginManager:150 __load_plugin: Not loading PPPSupport because its conflict has higher priority
giu 22 22:25:08 solus blueman-applet[1499]: blueman-applet 22.25.08 WARNING  PluginManager:150 __load_plugin: Not loading DhcpClient because its conflict has higher priority
giu 22 22:25:08 solus kded6[1311]: kf.bluezqt: PendingCall Error: "Agent already exists"
giu 22 22:25:08 solus kded6[1311]: org.kde.plasma.bluedevil.kded: Error registering ObexAgent "Agent already exists"
giu 22 22:25:16 solus systemd[1198]: Starting blueman-manager.service - Bluetooth Manager...
giu 22 22:25:16 solus systemd[1198]: Started blueman-manager.service - Bluetooth Manager.
giu 22 22:25:38 solus blueman-manager[2098]: blueman-manager 22.25.38 ERROR    Manager:253 error_handler:  Authentication Failed
giu 22 22:25:38 solus blueman-manager[2098]: Traceback (most recent call last):
giu 22 22:25:38 solus blueman-manager[2098]:   File "/usr/lib/python3.11/site-packages/blueman/bluez/Base.py", line 86, in callback
giu 22 22:25:38 solus blueman-manager[2098]:     value = proxy.call_finish(result).unpack()
giu 22 22:25:38 solus blueman-manager[2098]:             ^^^^^^^^^^^^^^^^^^^^^^^^^
giu 22 22:25:38 solus blueman-manager[2098]: gi.repository.GLib.GError: g-io-error-quark: GDBus.Error:org.bluez.Error.AuthenticationFailed: Authentication Failed (36)
giu 22 22:25:59 solus blueman-manager[2098]: blueman-manager 22.25.59 WARNING  ManagerDeviceMenu:145 fail      : fail g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Failed: blueman.bluez.errors.DBusFailedError:  le-connection-abort-by-local
giu 22 22:25:59 solus blueman-manager[2098]:  (0)
giu 22 22:26:55 solus blueman-manager[2098]: blueman-manager 22.26.55 ERROR    Manager:253 error_handler:  Software caused connection abort
giu 22 22:26:55 solus blueman-manager[2098]: Traceback (most recent call last):
giu 22 22:26:55 solus blueman-manager[2098]:   File "/usr/lib/python3.11/site-packages/blueman/bluez/Base.py", line 86, in callback
giu 22 22:26:55 solus blueman-manager[2098]:     value = proxy.call_finish(result).unpack()
giu 22 22:26:55 solus blueman-manager[2098]:             ^^^^^^^^^^^^^^^^^^^^^^^^^
giu 22 22:26:55 solus blueman-manager[2098]: gi.repository.GLib.GError: g-io-error-quark: GDBus.Error:org.bluez.Error.Failed: Software caused connection abort (36)
giu 22 22:26:55 solus blueman-manager[2098]: blueman-manager 22.26.55 WARNING  ManagerDeviceMenu:145 fail      : fail g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.Failed: blueman.bluez.errors.DBusFailedError:  le-connection-abort-by-local
giu 22 22:26:55 solus blueman-manager[2098]:  (0)

                                  I then (just now) rolled back and nothing changed for either Bluetooth or VPN, I assume this means that the problem isn't the update.

                                  Addendum from the next day, after many reboots, now without doing anything, the Bluetooth has started working well again, I can't really explain it, but just the same.

                                  So, in the hope of giving a useful feedbeck,, the only remaining problems are OpenVPN which stopped working (but maybe I solved it differently...and problably it's not correlatated to the update ) and ZED which I don't use, but it still doesn't work (x @joebonrichie : I just read it today, I didn't realize the answer.... I use KDE in Xorg, never even tried wayland for a calibration issue of the screen).