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.

Firstly, you should rather use "update-alternatives" for that job, just to tee up with that particular subsystem; the "alternatives" subsystem. I would suggest you read the man pages about it.

If you rather go your own way (and "break" that subsystem), then you would do well checking out the man page for "ln"... "ln -sf A B" creates a link (file), where A is the content of that link (file), and B is the pathname for the link (file) with that content. I.e., it looks like the order of arguments is the opposite to what you tried.

EDIT: always check the man pages; you cannot go wrong with that. It's really one of the most useful skills to have.

Check out https://wiki.debian.org/SourcesList

But luckily for us the traditional format still works well. For some reason the "old" format is tagged as "less readable", which is peak nonsense of course.

Perhaps you have it on a windows filesystem that have added ^M characters to the lines?

The Devuan imperative has always been: do not use stable, oldstable. or oldoldstable as release codenames!

Those codenames have individual meanings for the forked packages and the Debian packages., so there is always this period of time when Debian has "moved" its meanings (e.g. it's stbale packages are in the trixie release) while the Devuan forked packages have note so "moved" (e.g., its "stable" packages are still in the "daedalus" release).

The reason may be of some complexity to digest, but the rule is simple:
do not use stable, oldstable. or oldoldstable as release codenames!

@sun skin only, you got your own thread. If you want to pursue any one of the range of issues you voice (or maybe all at once), you may continue on this thread.