Yay, I could get it to work :-) The printer driver is 32 bit. So I had to install libc6-i386, and the Gentoo/Artix ported package worked!

The CUPS error log is a bit confusing. Nowhere a hint that the missing 32 bit stuff was causing this …

Does nobody use this or have an idea about this? This actually currently stops me from stopping playing around with Devuan in a virtual machine and really doing the migration … :-(

Well, tbh, I don't really consider myself a n00b after having used Gentoo for quite exactly 18 years now ;-)

That behavior was just plain unexpected (to me as a Devuan newbie). And as it was (from my point of view) a similar problem like the Radicale init script one, I simply supposed the init script to be the problem, not Debian's way how su works. Esp. as Devuan doesn't "really" support OpenRC, because it only lets OpenRC execute the Sysvinit init scripts. And states that OpenRC support would be "experimental".

Of course there's no excuse for the "crime" (as you call it) not to have searched the board for a su problem when Samba won't start, but – and I again beg your pardon – this interconnection was in no way clear to me, esp. facing the fact that I can start other init script with a plain "su" (not "su -") session, beacuse they do include a PATH statement containing "/sbin". May other newbies with this very problem find this thread to avoid such posts in the future.

But I think this issue is now solved, and I learned that Debian's su works in an odd way (if I'm very bored some time, I'll read through the lengthy disussion you linked to find out why Debian acts in another way as other distributions do here. But for now, I simply accept it as a given fact).

So everything is good concerning this … at least for me ;-)

Well, that of course explains it. I would never have thought that this could be the cause though …

Thanks for the information! No hard feelings ;-)

I now simply shipped around this (imo odd) behavior by simply creating a file in /etc/profile.d/ (/etc/profile.d/path.sh) with the following content:

PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Just that I maybe understand this a bit better: What's the point in leaving /sbin out of the PATH? And what's the point of only getting root's PATH when using su - instead of su?!

Okay, I now both wrote to mirrors@devuan.org and (hopefully) to the mirror maintainers. Let's see what happens.

Hey, thanks!

deb mirror://path/to/mirrors.txt chimaera main

looks very promising!

Is there some automated way to check which mirrors are the fastest for my location? Like Artix'/Arch's rankmirrors or Gentoo's mirrorselect?

How would I change sources.list? I tried to download http://pkgmaster.devuan.org/mirror_list.txt to/etc/apt/ and removed the mirror in question. Then I changed the sources.list from

deb http://deb.devuan.org/merged chimaera main contrib non-free
deb http://deb.devuan.org/merged chimaera-updates main contrib non-free
deb http://deb.devuan.org/devuan chimaera-proposed-updates main contrib non-free
deb http://deb.devuan.org/merged chimaera-security main contrib non-free
deb http://deb.devuan.org/merged chimaera-backports main contrib non-free

to

deb mirror://etc/apt/mirror_list.txt chimaera main contrib non-free
deb mirror://etc/apt/mirror_list.txt chimaera-updates main contrib non-free
deb mirror://etc/apt/mirror_list.txt chimaera-proposed-updates main contrib non-free
deb mirror://etc/apt/mirror_list.txt chimaera-security main contrib non-free
deb mirror://etc/apt/mirror_list.txt chimaera-backports main contrib non-free

but it dosn't work: I get

Err:1 http://etc/apt/mirror_list.txt Mirrorlist
  Could not resolve 'etc'
...

With three slashes after mirror:, it's

Err:1 http://etc/apt/mirror_list.txt Mirrorlist
  Could not resolve 'etc'

Okay, then, it would get complicated ;-) Not that I don't have or use local nameservers, but it would really suck to work around this by installing BIND or whatever on my Raspberry Pi just to really exclude this very mirror.

Maybe, this is actually a syncing problem. Seems like they have all kinds of ARM packages – but not the armel one needed by my Raspberry Pi 1. I think I'll contact the mirror admin. Maybe, they can or want to change this. Quasi as an upstream bugfix.

Just in case anybody else runs into this and finds this post: I created a bug report about this: https://github.com/rdiff-backup/rdiff-backup/issues/789

I don't use xattrs. Also, as said, it works when using Gentoo or Artix! So I'm pretty sure this is a Devuan/Debian specific problem …

Using a more verbose output, one can see that the crash happens after already having copied the file, when applying the attributes:

2022-11-21 12:26:22.184387 +0100  <CLIENT-2738>  Copying attributes from (b'bar',) to /nas/backup/test/rdiff-backup.tmp.1