snowee then how does Solus ensure that the packages served by the CDN are exactly the same as those served by the main server

The CDN pulls data from our package server directly in the event of cache misses and merely stores them on their edge servers / network closer geographically to the user. We can perform cache invalidation at any point in time. Alongside this, eopkg will validate the shasum from the index. We do not have any security concerns related to the CDN.

snowee To remove all doubt, should users update directly from Solus servers?

Users should use the CDN and once RIT is syncing from us, I'll be pushing a modification to eopkg that will convert existing systems using RIT to the CDN automatically. Intentionally using the non-CDN will mean that not only are you hammering our server more for no reason (when that bandwidth could otherwise be soaked up by the CDN service, to a magnitude of a 97% reduction from the metrics I've seen), but you're doing it at the cost of a worse download experience.

presianbg now using the SerpentOS or a copy of it.

This is not correct. While our infrastructure is no longer hosted by RIT, what we are using is still the previous build infra tech (with various fixes) such as our build management scripts, ferryd, and solbuild. They haven't been replaced with summit and vessel from Serpent OS yet and we're likely quite far out from that as they are coupled closely to moss (Serpent OS package manager).

        Recovered a Solus Plasma backup I made more than a year ago with Clonezilla, with an AMD RX 570.
        Now I have a GeForce 3060 Ti.
        Booted up perfectly (with nouveau), changed repo, upgraded:

        Rebooted, launched DoFlicky and I am on sail again!
        Glad to see you back, @JoshStrobl! (and the rest of the team, ofc)

        Changed to CDN, made the update, went through everything perfectly, except:

        > sudo eopkg check
...
Checking integrity of sudo       Broken
Checking integrity of python3    Broken
...

        Doing:
        > sudo eopkg install --reinstall sudo python3

        That fixed python3, but not sudo. sudo itself seems to work, though.

        Thank you, BTW, for bringing everything back to life. I'm happy again.

        The wonderful folks at RIT are now syncing from our repo! Users that haven't switched to the CDN-based one yet will now be getting updates (4hr delay from main repo server) and this week we will be rolling out an update to swap users to CDN (+ lots of other goodies).

        Solus is one of the very first distros I ever tried since switching to Linux a year ago. I've been watching the drama surrounding the OS with trepidation the past year and a half. I honestly thought it was done for. Extremely pleased to see Josh and his team step in. I also wish Beatrice the very best.

        PS -- Did a fresh install of Budgie today and updated from the new CDN repo. 1.47 GB of data very quickly downloaded and installed. Flawless. Best of luck, Solus Team!

        pulled the trigger and dusted off a fine wd caviar...and nuked everything on it.....4.3 iso plus 532 updates...followed the commands above...I wouldn't call this lightning fast by any stretch but about the same speed after you fixed it the last time and what I expected. about 12-14 minutes basically. 532 is a lot of packages. Not one single complaint. Back in the saddle.

        I'm going to do things different this time and try to build more stuff myself (if not in repo). New adventure ahead. I am so glad this project is rebirthed,

          brent
          I couldn't wait either.
          I installed it Sunday and have been fiddling around with stuff for a couple of days. It's good enough to have me switch back to it for my daily driver. Same minor issues as before - no fwupd, the Mullvad app won't do split tunneling and is out of date, fstrim doesn't work on LUKS encrypted disks by default (yet it is there pretending LOL). I'll let the team do the big stuff before I start raising issues. I might try to build the Mullvad app. I managed that before it was available. I'm just getting lazy. I used to build all sorts of stuff.

            We have just done another sync of updates to our CDN, which RIT will sync in a few hours. This includes an automatic switch for RIT users to the CDN (no user intervention needed), Budgie Desktop updates, WINE, pipewire, a bunch of apps, and a lot more!

            the current make me smile ... i remember when eopkg would hang and crash on fetching a -18mib archive and I had to relaunch the cmd.
            now it pumps 253mib in less than coffee cup cooking time.
            worth the waiting ...

              unclemez today I timed it: 61 packages 11:23:41 in the morning to 11:27:03. If it didn't get hung up on the Papirus package and the mimetype sync I think it would've been done in 2:45 minutes. Indeed the speed is phenomenal...I do remember those old hangs...and command reruns...but they do not make me sentimental🙂

                  The update was successful, great times ahead

                  brent Papirus just has a lot of work to do. There are almost a hundred thousand files in there after all (also counting symlinks)

                      zmaint Sudo is broken if you changed the contents of sudoers; for example sudo visudo and added some lines. In that case you have to set the correct hash of the sudoers file in /var/lib/eopkg/package/sudo-1.9.xxxxx/files.xml.
                      P.S. To check integrity do a sudo eopkg check sudo

                          sHAKaJaada I've never changed it on any of my machines. I think I read it's a known issue and it should be fixed on the next update.

                              sHAKaJaada Given that /etc/sudoers was managed by the package manager your changes to it were always going to be blown away if there was a package update. The new update is stateless in that the default config file is moved to /usr/share/defaults/etc/sudo/sudoers which should make it more obvious that the file is managed by the package manager. We did however add an include statement so that any files in /etc/sudoers.d will be read and appended to the sudo config and this is the recommended way to add additional statements.

                              I'm going to add a patch to ensure that visudo defaults to creating files under that directory.

                              zmaint: @sHAKaJaada is reporting a new issue, the one you're referring to is already fixed and that fix has been synced to stable.

                                    @sHAKaJaada Alright this is sorted now. After the next sync if you run visudo it'll default to creating the file /etc/sudoers.d/visudo and any changes you make will be validated for correctness by visudo upon saving AND will be persisted through all future sudo package updates.

                                    ReillyBrogan In new sudo versions check integrity of sudo reports broken when I add this line to sudoers. On previous versions before the update, it did not report broken after adding a line as shown.