You might want to try out the https://git.devuan.org/rrq/buster-to-devuan method although it's named badly for this purpose.

This is just a meta level note, that the way to capture bugs and user experience comments is by lodging "bugs", typically by email to the "bugs system".

The expectation is then that the lodger first tries to isolate which package is involved or seemingly involved and then lodge a "bug" against that package. If the package is "pure debian" the email target is "submit" at "bugs.debian.org, and if it's a devuan forked package, the email target is "submit" at "bugs.devuan.org,".

In both cases, the email should be a pure text email with the first two lines styled as

Package: packagename
Version: version

and then the description with details added.

It's of course fine to also note them at this forum, especially when it comes to more opinion based issues. However rather few of the package maintainers are at this forum.

mmm you omitted the -e... the last part of the line should read

-geometry 120x15-300+150 -e mail"

at least that's what the man xterm page says. I don't really know what the significant difference is between nominating a shell at the end (without -e) and nominating a program via the -e option. The man page has some discussion about it, but the authors' idea of clarity is different from mine.

To use double-quotes within a double-quoted string, they must be back-slashed... ie

coolmail -e "xterm -xrm 'XTerm.vt100.allowTitleOps: false' -T \"System mail notification\"" -geometry 120x15-300+150

An alternative is to use single-quotes, as in the -xrm detail.

There's some additional notes about quilt for debian packages in man dpkg-source, line 440++. Esp:

Perhaps that means both that the relative pathname for png file (probably relative the directory containing the debian sub directory) must be mentioned in that included-binaries file, and then that the included-binaries file is maintained via quilt patching.
EDIT: or that the included-binaries file is just updated (without quilt-ing).

Expanded example with some more audio paths, and also that I added "$" for "$RANDOM" just for symmetry (although it shouldn't be needed) and removed the braces for $PICK (also not needed).

#!/bin/bash
AUDIO=( 
    $HOME/folder*/*.{wav,mp3,ogg}
    $HOME/with/some/path/*.mp3
    /usr/share/sounds/alsa/*.wav
)
LENGTH=${#AUDIO[@]}
PICK=$(( $RANDOM % $LENGTH ))
play ${AUDIO[$PICK]}

In detail,

• the AUDIO assignment is the collection of possible audio files, which in this example includes any files with extensions wav, mp3 or ogg in any home folder whose name starts with "folder", plus any mp3 file in the folder path "with/some/path" from the home folder, plus any wav file in (system) folder "/usr/share/sounds/alsa/";

• the LENGTH assignment is the number of pathnames in the AUDIO list;

• the PICK assignment is an integer between 0 and LENGTH-1 picked from a uniform distribution between 0 and 32767, modulo the length (which makes it favour lower numbers); and

• the play command is of the PICK:th pathname of AUDIO list

I'm sure you can edit the audio paths to suit your needs.

But, there's something funny going on if it doesn't pick at random; perhaps a misspelling? But if you used Copy-and-Paste then that wouldn't be the case. The other option is that the audio selection doesn't find more than one file.. You might check that by inserting

echo ${AUDIO[@]}

immediately after the assignment, and review that output....

There's a little bit of mismatch between:

and:

Perhaps it's worth to deal with that first, and then see if the problem remains.

That might be right; and the corresponding linux-headers would be at least in the server and desktop isos.
Though, the chimaera alpha ISOs are rebuilt every Monday and might now hold only the 5.10.0-7 package(s).

You find linux-image-5.10.0-0 in beowulf-backports. That's kernel version 5.10.24 (as opposed to 5.10.40 that is packaged as linux-image-5.10.0-7 and kernel version 5.10.28 that was packaged into linux-image-5.10.0-6)

Links for direct download of the .deb(s) could be:
linux-image-5.10.0-0.bpo.5-amd64=5.10.24-1~bpo10+1
and
linux-headers-5.10.0-0.bpo.5-amd64=5.10.24-1~bpo10+1

Yes it appears to be fully chromium's problem... are you sure it runs with your credentials rather than some "sandbox user" ?

You might try running

fuser -v /dev/snd/*

to see which if any (other) process "owns" the device.

Based on a shallow look-around, it would seem you'll need to get the "st" module loaded.

Perhaps a plain

# modprobe st

is sufficient, or maybe it needs some more intricate incantation.

(Possibly it needs a tape loaded at the time)

Look up Documentation/scsi/st.rst in the kernel source for details of that module.

I would call it Way Too Many.

tomoyo-tools seems to be to be upstreamed from http://tomoyo.osdn.jp/ (and why that is enabled in debian's standard linux-image is unkown to me). Apparently adding security=none to the boot command should disable this one.