The order is not important, but duplicates might be a bother. I.e., you should remove the top two, because the are duplicates for excalibur/main and excalibur/non-free-firmware.

In addition, you should probably add sources.list lines for excalibur-updates and excalibur-proposed-updates ... also using sections main, contrib, non-free and non-free-firmwares. With that you would be more "future ready".

Have you verified uuid? it's unusual for me to see ":" rather than "-" in uuid, though it may well be an mdadm thing(?)

ls -l /dev/disk/by-uuid

In any case I'll set up a VM trial to see if I can replicate your problem.

It appears your /etc/apt/sources.list.d/devuan.sources have blank lines that are not empty, but each contains a single space character. Therefore that whole file becomes treated as a single block of key: value pairs, where the last one for each key overrides all other.

I don't know which which editor you use to accomplish that single-space-character blank lines, but if you run the following command it will be happier:

sed 's/^\s*$//' -i /etc/apt/sources.list.d/devuan.sources

You can verify that the file is slightly smaller after the command, and if you first copy the file to /tmp/OLD you can compare them with diff or meld to see what I talked about already some posts ago.

Nowadays we also have the pipewire-alsa package that does the same as pulseaudio-alsa but directing to pipewire instead.

Indeed, it seems prepared for random asynchronous bootup when one has configured it so. Though it seems the default setup case is the invocation at line 90, where the hook script is used explicitly.

That blank line between the stanzas, does that contain any spaces or tab?

You could use https://transfer.rrq.au if you like

You might use the following qemu command line arguments for usb passthrough:

-device qemu-xhci,id=usb-bus \
-device usb-host,vendorid=0x0000,productid=0x1111

with of course the right vendor and product ids replacing 0x0000 and 0x1111.

The device must be plugged in when qemu starts. If you want to support removing and reinserting, you'll need to use the first "-device ..." argument only, and then the qemu monitor command line to add the device, with different but near enough similar syntax.

Before then, the user running qemu must have path access to the /dev/bus/usb/*/* devnode for the usb device to access.

To that end you might for example add GROUP="plugdev" appropriately in /lib/udev/rules.d/50-udev-default.rules, and make the user member of the plugdev group, and then the user gains access right whenever the device is blugged in.

It's also possible to refer to the device using the bus and device id.

if you were to use "code" tags around code, then where would they be?
(You should be able to edit your post if you would want to).

maybe it's from https://crunchbangplusplus.org

Perhaps you forget to "submit" it? I.e.
1 go to your profile
2 edit the email address to be the new one
3 scroll down and press "submit"

Note that "validity" of an email address refers to it's format rather than whether emails to the address are deliverable or not. (See e.g. RFC 6530 and details)

Usually rather than fiddling with source via the browser, I would clone the packaging project and review the source from there. This would include using the command

$ dpkg-source --before-build .

within the packaging branch so as to apply any patch series (in case of quilt packaging). Doing so sets up all actual "before build" source in that workarea. (One may undo that by using --after-build instead)

If I then want to compile and prepare a local .deb for testing, I'd use

$ dpkg-checkbuilddeps

to tell which build dependencies need to be installed, and then use the command

$ debian/rules

i.e., execute the debian/rules make script by the shell with working directory at the project top. This typically creates a .deb file somewhere, possibly in the parent directory.