@exponentialmatrix
After some experimenting with easydeb I have the following questions:

how do I set the "Section" (like in the debian control file) a package belongs to in the DEBBUILD file?

how do I add a long description of the package in the DEBBUILD file?

I did read the man pages but couldn't find the above info, maybe I missed it.

Also there seems to be a small bug in the generated .dsc file, the lines with the shasums and files aren't indented. When I feed the generated .dsc file into 'sbuild' it throws and error because of this. After manually indenting the lines with one space the error disappears.

sbuild or rather dpkg-source called by sbuild also complains about the format name (easydeb):

dpkg-source: error: source package format '3.0 (easydeb)' is not supported: Can't locate Dpkg/Source/Package/V3/Easydeb.pm in @INC (you may need to install the Dpkg::Source::Package::V3::Easydeb module) (@INC entr
ies checked: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.40.1 /usr/local/share/perl/5.40.1 /usr/lib/x86_64-linux-gnu/perl5/5.40 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/p
erl/5.40 /usr/share/perl/5.40 /usr/local/lib/site_perl) at (eval 16) line 2.

If I change that to 'quilt' I get the following error instead:

dpkg-source: error: cannot write /build/reproducible-path/rssguard-4.8.6/debian/source/format: No such file or directory
E: FAILED [dpkg-source died]

Maybe easydeb needs to also generate the debian/source/format file?

It doesn't work like that, it's not geography but rather peering agreements between network providers and available bandwidth between networks that determine which repo is best.
I.e. in the same exact physical location the "best" repo will likely differ depending on which network provider you use.

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.