Are you just complaining or are you looking for a solution?

How do you know that deps are missing and what do you mean by "missing"? To me, it looks like the dependencies are the same for gparted in ceres and excalibur.

Second question for you: Which packages do you think are missing?

Suggestion:  Separate repos for each user's contributions, and name the repo something like DUR_fsmithred/ and if I want someone else to have upload privs to my DUR, I can just add them in my settings. Explore repos with search string "DUR" and they will all be listed (by "DUR_username" which may not be helpful) or search by project name, and all projects by that name will be listed (DUR* or otherwise).

Runit will use sysvinit scripts if there's no runscript for the service. Not all services have runscripts because not all maintainers of service packages are interested in runit. The runit-services package has additional scripts to the ones that come with runit-init.

Bug reports go to bugs.devuan.org or bugs.debian.org depending on if it's a forked package or not. The runit packages are from debian.

Here's a readme that might have some relevant information:
https://salsa.debian.org/runit-team/run … ian/README

I'm running ceres in qemu with openbox and no display manager. I use startx to get a graphical session. It's working normally with elogind 255.17-4 and friends. I notice you didn't list libelogind-compat. That also got upgraded with the others here. I also have seatd and libseat1 installed. If you're missing any of those, maybe adding them would fix it. That's a guess.

tempforever's gpg key is listed on this page:
https://www.devuan.org/os/team

And here if you search for tempforever:
https://keyring.devuan.org/

Which will show you that his key has been signed by another devuan dev:
https://keyring.devuan.org/pks/lookup?o … 4768BE620B

He's one of us, for sure. Unfortunately, his key didn't get added to the devuan-keyring package until a couple days ago. It's currently in ceres (version 2026.01.13)

runit-services has runscripts for lightdm, sddm, xdm and slim. I don't see gdm3 in the list. Also, someone else posted about a problem with gdm3 not working in excalibur.

Devuan has the exact same support for runit that Debian has. The runit maintainer sometimes posts on this forum. You might get a more informative answer.

Oh! They come from the stale versions in the live-sdk build tree. That needs to be re-worked so I don't have to remember to update them.

Same as mine.

lrwxrwxrwx 1 root root 36 Aug 10  2024 /etc/localtime -> /usr/share/zoneinfo/America/New_York

Target file is also owned by root here:

-rw-r--r-- 1 root root 3552 Aug 24 16:12 /usr/share/zoneinfo/America/New_York

Check the size of fcopy, too. I'm running the same version, so it should be the same size.

$ ls -l /usr/lib/x86_64-linux-gnu/firejail/fcopy 
-rwx--x--x 1 root root 30968 Apr 20  2025 /usr/lib/x86_64-linux-gnu/firejail/fcopy

Similar problem solved here:
https://discussion.fedoraproject.org/t/ … tes/161848

Check the sha256sum of the iso to make sure the file wasn't corrupted during download. Refractsnapshot starts from the menu or terminal. There's no dummy "button" in the menu or elsewhere.

Possibly you are thinking of a Refracta iso (as opposed to a Devuan iso with refracta tools) which does have a menu entry for refracta2usb that does not actually start the application - it just throws up a window telling you to start the app from a root terminal. That's not a regression. It's always been like that.

If you get errors running an application, one way to get help with it is to allow potential helpers to read those error messages. They sometimes contain useful information.

To run refractasnapshot-gui from a root terminal, you need to just use 'su' instead of 'su -', or else use 'sudo' if you have it enabled,  so that root will still be able to use the user's xserver.

Most of the packages in devuan come directly from debian and are not altered. This includes busybox, live-boot* and live-tools. Only the live-config* packages are forked by devuan, and that's to add support for runit. All the refracta tools work on debian, too.

1. I always end up at the qemu uefi shell, type exit, then go into the Boot Maintenance and drill down until I find the actual boot file (grubx64.efi or something like that).  It's in EFI/debian.

Since you said you could fix it, I booted and reinstalled the bootloader with

grub-install --bootloader-id=devuan

and it updates the bootloaders in EFI/debian instead of making a devuan directory. That's the first time I've seen that happen, but I've been seeing unexpected behavior in grub for a few years, so I'm not too surprised. And after that, it boots correctly.

I don't know why it doesn't work from the installer. It runs the same commands.

2. Another 'I don't know'. When I've tried it in the past, both language and keyboard settings persisted. When I get a chance, I can try it again.

As root:

dpkg-reconfigure locales
dpkg-reconfigure keyboard-configuration

Then I think you need to reboot. (Log out/in might be enough)

FYI: The 6.0.0 desktop-live iso does not have the untitled blank window or the polkit warning. If it did, it wouldn't have been 6.0.0.