In summary: version 1.6.3-3 has been built and will be available in a couple of days with the sources.list reference:

deb http://deb.devuan.org/devuan experimental main

Note that it is "/devuan" rather than "/merged", since the experimental repository is not merged. Further, I should warn that adding such sources.list lines willy-nilly can bring unplanned hair loss.

At the moment only the plugin package 1.6.3-1 is available.

The experimental building pipeline is for "all" architectures: amd64, arm64, armhf, i386, ppc64el and riscv64.

If you have another architecture, you may download the ".dsc", "tar.gz" and "tar.xz" files to a directory, cd into that and use the "debuild" schemata to build, like the following:

dpkg-source -x fftrate_1.6.3-3.dsc
cd fftrate-1.6.3
debuild -k0x12345678

where  "12345678" is replaced by your GPG key ID. That'll leave the build residue in the parent directory and the work tree fftrate-1.6.3 can be removed. Note that you may have to also install build dependencies; ideally it will tell you which to install. If it doesn't then please tell me (because then I have failed to declare that dependency)

Great. Is that github project yours, or something you could add to? As of principle it's best when "upstream material" is added to upstream; otherwise it ends up as packaging patch(es) which is much less accessible for people.

In this case it would also be possible to make an upstream-based fork within the packaging project to include these things (and maybe some of the other good documentations you have written).

Or even better would be that you create your own project at, say, git.devuan.org (or codeberg.org) as a fork of the github upstream, and then add your documentations and man pages to that. My packaging project can track that instead.

Note that "side documentation", including man pages, may well reside at top level or perhaps a "doc" directory,  without particular format constraints. Often it's plain text files or markup files that get gzipped in the packaging. In the packaging it's typically placed in /usr/share/doc/$package/ (except the man pages of course)

Thanks. Yes it's now packaged and added to Devuan experimental.

It's using quilt packaging with a minor source touch-up patch to resolve  compiler complaints, and a separate "packaging" patch that sets it up for gbp-buildpackage. Presently only the plugin package is built since the binaries lack man pages, and I'm looking into making a man page for the plugin.

I'm thoroughly confused by your explanation. It surely would be simpler to assign two different IP addresses to the two NFS servers (whether or not they are connected on the network concurrently), and then have two alternative mount declarations on a client, which could be onto the same mount point if that's your intention.

In my mind, that would be the simple way. Especially compared to whatever is involved in chasing two or a few modules to fit your kernel.

But that may be of no help to you I suppose.

Probably your system does not link together /lib and /usr/lib

If so, the searchable keyword is usrmerge

Not my idea.

Yes I noticed you mentioned that some while ago (and has verified on my system).

I still needed the setup on that (daedalus) system, so thought to mention it. Baybe it rather was the S16_LE setting for the microphone that made the difference, or the 48k sampling (?) I'm not sure.

I've repeated your setup and it fails for me as well.

However, with the variation to use the default type 1.2 metadata for the raids the installation was successful.

Perhaps you can try that, unless you require type 0.90 metadata for some reason?

I don't know enough about it to comment on that difference, but it seems type 1.2 was the default already in chimaera.

No, there can only be one codename on a line. You need a separate line for each codename.

You confuse me. What is the problem, really?
The installer doesn't build any md assemblies by itself. And the raid1 setup seems fine.

However the lack of a bootloader partition for grub on the boot disk is a problem. You should have /dev/sda1 or /dev/sdb1 partitions assigned as BOOT_bios partitions for grub to use (choosing which is the boot disk). So you can't use them in a raid and you can't install a filesystem on them.

I've now set up a VM with 2 disks /dev/sda and /dev/sdb, with some 8 partitions each, to form 7 raid1 assemblies, while /dev/sda1 and /dev/sdb1 are set up as "BIOS boot" partitions for grub. Though only /dev/sd1 is in use for booting.

The key step for making it work is to not install grub via the installer but by hand from the C-A-F2 console, and then bind-mount /run from the installer onto
/target/run before the chroot into /target and the grub installation.

If you missed out on that, you can recover by starting the installer in menu choice 1, and progress that to the hostname dialog; then go to C-A -F2 console for recovery actions, for example:

# mdadm -C -n2 -x0 -lraid1 -v /dev/md0 /dev/sda2 /dev/sdb2
# mount -t ext4 /dev/md0 /mnt
# mount --bind /run /mnt/run
# chroot /mnt /bin/bash -i

and continue in the chroot

# mount -t proc proc /proc
# mount -t devtmpfs dev /dev
# mount -t devpts devpts /dev/pts
# mount -t sysfs sys /sys
# mdadm --assemble --scan
# mount -a
# apt-get install --reinstall grub
# update-grub
# grub-install /dev/sda
# update-initramfs -u
# exit

and then

reboot

The above is on the assumption that md0 has sda2 and sdb2, and contains the root filesystem. Further /etc/mdadm/mdadm.conf must be duly prepared; but the key is still to have md0 assembled in the console and then that /run is bind-mounted into the chroot before you go into that for the further rescue actions.

HTH

Did you actually run that sed command?
I copied and pasted from your post #14 and got a file of 1603 bytes.
That is the size of the file in your post #22
I then ran that sed command and got a file of 1598 bytes.
The differences are in removal of space characters on the blank lines.

Perhaps you have different explanation why your file is 1603 bytes?