gcalculator is probably a typo, the correct name is galculator without the 'c' after the initial 'g'.

Ok, thanks for the info, I had never heard of this ALSA plugin (libasound2-plugin-equal) before, have to read up about it.

Well said, since it's inception I have almost always only used ALSA directly, PA is one of those things I disable right after installation (except in VMs, as I can't be bothered) and I still haven't understood what the purpose of PA or Pipewire is, i.e. what do they offer that ALSA doesn't offer already.

But ALSA it not without blame, while it works well it has really awful/cryptic documentation which probably is the main reason why most people don't understand all of it's capabilities (myself included).

So I installed opensysusers as suggested by fsmithred instead of systemd-standalone-users and tested it by creating a testuser.conf file and then running opensysusers:

# cat /usr/lib/sysusers.d/test.conf
u testtest99 - "testtest99 user"
# systemd-sysusers test.conf
# grep testtest /etc/passwd /etc/group
/etc/passwd:testtest99:x:498:498:testtest99 user:/:/sbin/nologin
/etc/group:testtest99:x:498:

And we have a winner, opensysusers respects the settings in /etc/login.defs since it's simply a shell script that calls useradd and groupadd to actually create the users (and useradd and groupadd obviously follow the settings in /etc/login.defs ).

So I guess the problem is solved, but I would suggest that Devuan should default to opensysusers even during the initial installation rather than systemd-standalone-users.

opensysusers is an easy to understand shell script that relies on the standard useradd and groupadd binaries, i.e. it's a typical tool following the Unix philosophy unlike systemd-standalone-users, therefore opensysusers seems much better suited as default for Devuan.

systemd-standalone-users should really be blacklisted in Devuan as it ignores the settings in /etc/login.defs and therefore potentially creates users and groups with unwanted UIDs and GIDs.

On the systemd webpage says:

https://systemd.io/UIDS-GIDS/

I checked the debian/rules file of the source package for systemd-standalone-sysusers and didn't find this compile time flag (-Dcompat-mutable-uid-boundaries=true) so it appears an omission of the Debian systemd source package (that generates the binary package systemd-standalone-sysusers).

On the other hand it would be better if the polkitd package didn't use this systemd tool but rather adduser, especially since it seems to be already set up to use adduser but it gives preference to systemd-sysusers if it finds it, see debian/polkitd.postinst (policykit-1-126 source):

        if command -v systemd-sysusers >/dev/null; then
            systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} polkit.conf
        else
            adduser --group --system --quiet --gecos 'polkit' \
                --no-create-home --home /nonexistent polkitd
            addgroup --system --quiet polkitd
        fi

IMHO the above should be changed to always use adduser and since this is a Devuan package it would be easier to fix rather than getting Debian to add the compile time flag to the systemd package.

There is even a 3 year old open bug report about this missing compile flag for systemd in debians bugtracker but nobody seems to have done anything about it:
https://bugs.debian.org/cgi-bin/bugrepo … ug=1029785

Therefore I really think it would be better for Devuan to remove this systemd dependency from the Devuan polkit package (which is forked already) and use exclusively 'adduser' in the postinst script of polkitd.

Thanks, I can confirm the error is gone.

BTW, do I understand this right that I could simply take a pkgbuild file from Arch AUR, rename it to debbuild and adapt the dependencies if necessary and then build it on devuan?
In other words, is the file format specification of the debbuild files 100% compatible with the pkgbuild file format?

@g4sra yes, I find the debian packaging world confusing too (as should have transpired from my previous messages in this thread), but my impression is that for some reason the debian devs find it easier to describe the current process in their own personal blog rather than to go through whatever (presumably complicated) process to update the official debian documentation.

That 'sbuild' is the current "right way" to build debian packages is also stated in this blog by another debian dev (but his how-to is too vague, the one from Stephan Lachnit is much more detailed and therefore easier to follow for a newbie like myself):
https://www.linux.it/~ema/posts/buildin … right-way/

Thanks for the confirmation, that's the impression I got too, the guide from Stephan Lachnit that I linked in my previous message is based on sbuild and is fairly recent and he's an official Debian developer/packager.
pbuilder seems to have been superseded by sbuild, pbuilder seems to be older and no longer state of the art (although probably still usable).

That was my initial way of thinking too, but it appears that a lot of official guides are not kept up-to-date and therefore don't really teach the current best practices.

@golinux thanks for that link, it's a well written guide and there is certainly some interesting info but all those methods described are geared towards someone who just wants to install some not already packaged software on his on PC, not to produce redistributable packages.

If easydeb does a clean chroot build as I hope it does then for me that's far more useful than the methods described in your link.

The far easier way would be to use VMware workstation for Linux which nowadays is totally free (as in beer), but you have to register an account with broadcom to download it (anyone can do it, it's not restricted to businesses, and since you don't have to show proof of the details you provide you can basically write whatever you want...).

What makes the whole deb packaging process so difficult is that there is a bewildering array of packaging tools with overlapping functionality. Also dozens of how-tos that all describe different ways to do it. So as a newbie to deb packaging I don't know which how-to to follow.

For example the one suggested by RedGreen925 says right on top:

So it would seem that this is not the best guide to follow in 2025...

But by following some links on the above page I found a page about a tool called pbuilder that seems interesting:
https://wiki.debian.org/pbuilder

Is pbuilder something like mock that I should familiarize myself with or is that outdated and no longer useful too?

Just to add: I would like to learn to build deb packages good enough for redistribution, just like "mock" allows on RPM based distros, not to only install on the same system where I build them on (in which case getting the dependencies right wouldn't matter much).