Because deb.devuan.org failed to update due to an expired GPG key.
See this topic regarding expired keys, or the 50 bazillion general search hits regarding this kind of error on any number of Debian-based distros. This is why we read the "new and announcements" section, no?
You're running unstable with a bunch of third-party repos enabled, so surely you can read those errors and warings from apt just as well as I can too...

You also appear to have a number of duplicates and errors in your sources in general, but that's another matter.

apt install gpm

Used to have scrollback, removed recently (Grrr) because "nobody was using it" (which is bollocks).
Patches exist to restore this functionality, but Debian/Devuan does not include them.

Psuedo-terminal virtual filesystem, used by GUI terminal emulators. Predates systemd by about a decade.

Oh FFS. Just when I decide to let it cook for a bit...

Ignore dovecot for the minute, that's behaving itself right now. smbd and nmbd on the other hand:
Are running right now, and working fine.
Have a PID file...
But that PID file is empty. I know it contained a valid PID ~2 days ago, because I checked after I had to restart it.
The smbd and nmbd processes are ~2 days old (Jun  8 17:26), but the modification date on the PID file is 'Jun 10 17:49'.
Grepping the logs for that time and date (and an hour before) reveals... Nothing of any interest.
Sure enough, the init scripts can't stop those services.
Killing them manually and restarting with the init scripts writes out the correct PID, and all is well again.

And it gets better, it's not just dovecot and samba, they're only the canaries:

What the? Seriously? How did I miss that?

So it's not the init scripts at fault, It's been aliens all along.
I think it's also safe to say my initial statement that /var/run/dovecot/master.pid was missing is incorrect. I expect I looked after I had already run the dovecot init script, which of course fell through to that rm -rf on account of having no PID to work with.
I can't exactly prove it right now, but I bet you a cookie the pidfile was present but empty like all the others.

I'm still none the wiser as to what's fingering my files behind my back, and it's high time I went to sleep right now. But hey, data point is data point.

If you have any idea what that data point points to... I'm all ears.

I just sicced fnotifystat onto /var/run/, so let's see if it catches anyone...

I really can't think of any reason /var/run/dovecot would be a problem, and it's working that way just perfectly at the moment - stopping and starting (both via the init script and doveadm) does what it should WRT master.pid.
I guess it wouldn't hurt to try though.

/var/run -> /run
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=6593300k,mode=755)

Pretty sure that's a default config from the Debian init scripts... somewhere, sometime. This install has been a rolling upgrade since at least as far back as Squeeze.

I'll give that a poke and see how it goes (will involve much patient waiting OFC). At least there's no 'rm -f $PIDFILE' in it anyway...

Frankly I'm wondering why anyone would ship an init script that does rm -f on a pidfile without checking to see if the relevant process is really gone to begin with, but presumably this one has been working for people for some time, right?
I mean, at least the smbd init script does a basic 'ps $PID' check, but here there's nothing.
Unless I'm missing something obvious, it looks like it will remove the pidfile even if start-stop-daemon returns non-zero (i.e. returns early only on "2"). That isn't even half-arse fail-safe.
This looks like some generic template script TBH, one intended to be tweaked for things like dovecot that fork a bunch of processes.
And yes, I checked, it's the one shipped in the Debian package.

Then again, I guess I should probably shut up about the fragile init script untill I know it's really the problem.

Not sure what you're getting at here, I have no systemd anything anywhere socket activated or otherwise.

The only reason for 8.3 filenames is compatibility with operating systems and legacy software that lack LFN support... Those all went the way of the dinosaur in 1995.
Do you really have a need to read your files with 35+ year old DOS software?

I don't know about NTFS, but on VFAT at any rate these alternate filenames are autogenerated, so there's nothing to loose.

Probably, but I doubt it will be very useful as it depends on the native Windows drivers to access the hardware.

If fan and clock controls are what you're after, IIRC (I don't have any nvidia cards any more) that stuff is available in the GNU/Linux native nvidia control panel after setting the appropriate "coolbits" values. Check the arch wiki and/or the documentation that comes with the driver for details.

I'm sure your pet bats just love it.

Sarcasm and HiFi religious wars aside (though I think Harry would like a word), sure. If you just want to chuck the PCM stream at something else to make sense of, ALSAs default conversions are probably unhelpful.

In this case though, it appears we're dealing with a motherboard codec, and a realtek one at that. This is precisely the kind of device the ALSA defaults are aimed at.

That realtek chip has considerably worse SNR and frequency response than the last amp I built... And that one was based on a design from the early '80s.
Direct hardware access and high sample-rates would be completely pointless here even if the chipset supported hardware mixing, which it doesn't.

The notes I left myself in my asound.conf suggest that I have had problems in the past with Firefox (and apulse) using a default device that isn't a plug. I don't remember exactly why, but it gels with FF working if the OP removes that direct hw: routing.
The other problem, i.e. not using dmix with motherboard audio, should be pretty obvious.

It is indeed, but it's probably worth noting that the old soundcard-shuffle can also be prevented by passing the 'index' option to the module, e.g. in /etc/modprobe.d/alsa.conf.

It has nothing to do with systemd.
Many windows applications (especially games) like to use zillions of mutexes for synchronisation, this is not particularly well supported or performant on GNU/Linux, largely because native applications tend to use other methods.
Wine has three approaches for dealing with this: Internal emulation, which is slow, esync, which fakes it using filesystem calls but requires you to raise the maximum number of open file handles in /etc/security/limits.conf, or kernel futex support (fsync), which requires patches as I mentioned some posts back but provides near-native performance.

You don't strictly need esync or fsync, but IIRC lutris defaults to enabling esync for performance reasons. Failing to either turn this off in lutris or raise the open files limit will likely result in the kernel summarily killing your wine application.

Probably because it doesn't fit Debian's packaging requirements. It's documented in the wiki and readily available though. vOv

You have DXVK enabled for this game in lutris, but DXVK can't find the vulkan extensions it requires.
My guess (assuming you have GPU drivers installed and functioning correctly), is that the game you are trying to run is 32bit, your wine prefix is 32bit, and you are missing the 32bit vulkan libraries.

Maybe missing 32bit libgnutls, maybe missing .NET or other dependencies within wine...
Was this using the lutris install script?
I've never had any interest in the series in general, so I can't offer any specific advice for that game. The lutris script looks like it installs a bunch of stuff with winetricks to get the Epic Launcher (crapware I have no time for TBH) to run though.

In any case, you'd probably be better served by the lutris board and / or winehq for problems like this, they have far more to do with wine than Devuan. If this board had an "Unsupported Software" sub (kinda surprised it doesn't TBH), that's where Windows applications would belong.
Personally, I make a point of checking winehq and the lutris script repo to see if anyone has managed to get a particular game working before spending (and potentially wasting) any time on it.

FWIW, when setting up RAID systems I always keep /boot (and usually root as well) on a small RAID1.
A software RAID1 (mirror) is indistinguishable from a pair of identical partitions as far as the BIOS, bootloader and initrd is concerned, so even a rescue disk with no RAID support whatsoever can still get you into your boot/root FS.
One can even set up the two drives as alternate BIOS boot disks, so as to have bootloader redundancy as well.

As for the problem at hand, there seems to be some confusion as to whether this is a fakeraid or mdraid setup. If it's the former, you'll likely want to use dmraid and access your disks under /dev/mapper/. Mdadm has nothing to do with sata/fake/dmraid.
I have no experience with this personally, I've never used it, and I probably never will. The only time it has any benefit over software (md)RAID is when you're sharing an array with Winblows... And that's a dodgy proposition to begin with IMO.
There is a Debian wiki page on the matter though. Might be worth a read if you haven't already, looks like there are some traps regarding GRUB installation and UUIDs.

If this is actually an mdraid array, (much mention of mdadm in this thread)... I know Devuan can boot from RAID1 just fine, and I've set it up that way many times. I have no experience with RAID0 though, IMO an array that reduces reliability is an oxymoron, especially for the root filesystem.
One has followed the steps in the Debian wiki WRT to generating mdadm.conf and updating the initrd, no? IME that's all it should need.

Good to know sanity (and simplicity) still prevails.

It's kinda hard to keep up with this constant reinventing of the sound-server wheel TBH, I stopped paying attention years ago.
Didn't pulseaudio only recently graduate from buggy, CPU hungry, latency-inducing mess to something somewhat usable? And we're replacing it again already?

Maybe we can do pipewire-pulse-esd-arts-alsa-oss as well? I mean it's only frickin' audio, everyone needs more layers of confusion in their lives, right?

Well, if you can see the disk but booting from it fails to find the rootfs, that suggests that either your bootloader and/or fstab is incorrectly configured, or there are drivers missing from the initrd (but available and loaded later).
Either way, I'm having quite some difficulty understanding your posts.

Aside, I don't know why you keep mentioning PAE, it's completely irrelevant here.

In aid of ruling out PCMCIA issues (itself a very old standard not widely used any more), the docs for that board indicate it has a standard IDE port. Again I suggest trying to boot from that, passive adapters for CF cards are cheap, readily available, and should require no special driver or configuration.
Your PCMCIA-CF adapter almost certainly includes an IDE controller of it's own, and that's only going to complicate matters.