@exponentialmatrix
Those two lines came from the Arch PKGBUILD ( https://gitlab.archlinux.org/archlinux/ … n/PKGBUILD ), I wasn't sure how to interpret them (optional build dependencies? is there such a thing in debian? how would optional build dependencies work anyway?) but I left them in there (commented out) just in case.

One run-time dependency was missing (now added) and I have done some other minor improvements, here is the latest version:

# Maintainer: LinuxTECH.NET <deb-packager{at}linuxtech.net>

pkgbase=rssguard
pkgname=(rssguard{,-lite})
pkgver=4.8.6
pkgrel=1.1
pkgdesc='simple, light and easy-to-use RSS/ATOM feed aggregator
 RSS Guard is simple, light and easy-to-use RSS/ATOM feed aggregator
 developed using Qt framework which supports online feed synchronization
 with these services:
  - [Tiny Tiny RSS](https://tt-rss.org)
  - [Inoreader](https://www.inoreader.com)
  - [Nextcloud News](https://apps.nextcloud.com/apps/news)
  - [Gmail API](https://developers.google.com/gmail/api)
 .
 .'
arch=(any)
control_fields+=('Section: contrib/web')
control_fields+=('Priority: optional')
url='https://github.com/martinrotter/rssguard'
license=(GPL-3.0-only)
depends=(libqt6widgets6
         libqt6gui6
         libqt6core6t64
         libqt6sql6
         libqt6sql6-sqlite
         libqt6xml6
         libqt6concurrent6
         libqt6core5compat6
         libqt6multimedia6
         libqt6multimediawidgets6
         libqt6qml6
         libqt6network6
         libqt6dbus6
         libstdc++6
         libgcc-s1
         libc6
         libsqlite3-0)
builddepends=(qt6-5compat-dev
              qt6-declarative-dev
              qt6-multimedia-dev
              qt6-tools-dev
              qt6-base-dev
              linguist-qt6
              qt6-webengine-dev
              libsqlite3-dev
              'cmake>=3.14.0')
#suggests=('clang: Support for beautification of message filter scripts'
#            'mariadb-libs: Support for MariaDB-based data storage')
source=(${pkgbase}_${pkgver}.orig.tar.gz::https://github.com/martinrotter/rssguard/archive/refs/tags/${pkgver}.tar.gz)
sha256sums=('c29bdda08ece8de113dbdb87e8e23491221ba9ddbacd26141d6a00e04888972e')

prepare(){
  cd "${srcdir}"
  mv ${pkgbase}-${pkgver} rssguard
}

build() {
  cmake -B build -S $pkgname \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DREVISION_FROM_GIT=OFF \
    -DNO_UPDATE_CHECK=ON \
    -DENABLE_MEDIAPLAYER_QTMULTIMEDIA=ON \
    -DENABLE_MEDIAPLAYER_LIBMPV=OFF
  cmake --build build

  cmake -B build-lite -S $pkgname \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DREVISION_FROM_GIT=OFF \
    -DNO_UPDATE_CHECK=ON \
    -DENABLE_MEDIAPLAYER_QTMULTIMEDIA=ON \
    -DENABLE_MEDIAPLAYER_LIBMPV=OFF \
    -DNO_LITE=OFF
  cmake --build build-lite
}

package_rssguard() {
  depends+=(libqt6webenginecore6
            libqt6webenginewidgets6)

  DESTDIR="$pkgdir" cmake --install build
}

package_rssguard-lite() {
  pkgdesc+=' This package contains RSS Guard without the WebEngine support.'
  conflicts=(rssguard)
  provides=(rssguard=$pkgver)
  replaces=(rssguard-nowebengine)

  DESTDIR="$pkgdir" cmake --install build-lite
}

It is actually very easy with easydeb too, I like the concept behind it, that you can simply share a debbuild file (which is essentially a recipe for anyone to automatically replicate your build, basically instead of sharing binary packages that could be many megabytes you just share a text file, which you can even share in a forum post like I just did, it's just text)  and how it has been implemented (that it's shell scripts).

Easydeb is 80%-90% there, it only needs a few more improvements (like the chroot build thing as already mentioned, in order to be able to get the build dependencies right) to become the best way to create packages for debian derived distros, I mean for anyone who is not planning to become an official debian dev (they have no choice but to package according to the debian rules).

Yes openntp is the best one, I have been using it for decades, it's from OpenBSD, one of the few FOSS projects that still uses common sense (Devuan obviously is one of them too ).

Thanks, I think adding both "Section" and also "Priority" would be quite useful as these two are used and displayed by the Synaptic Package Manager for each package ("Section" to categorize the package and "Priority" is displayed in the Common tab of each package).
But yes, in the meantime the control_fields are good enough.

How in practice do you do that with easydeb in an easy semi-automated way?

To explain what I mean by "easy semi-automated way":
When you have a standard debian source package it's very easy to do a semi-automated build in a chroot.
It's basically just two commands, one for updating the chroot tarball of the base system (if it hasn't been updated recently already) and then launch 'sbuild' which will take care of creating the initial chroot, downloading the dependencies, building the binary packages and then cleaning up everything again.

To set up such a semi-automated chroot build environment I followed this guide which only needed a couple minor adaptations to work with Devuan:
https://stephan.lachnit.xyz/posts/2023- … cacher-ng/

As far as I see it there are two types of people to whom easydeb is aimed at:

- the simple user who just downloads a DEBBUILD file and then uses easydeb to build the package on his local machine with the aim to install and use it. This person has no need for a chroot build environment.

- the developer who want to create a DEBBUILD file that he wants to share with other users (for example via your git repo or the future DUR). When creating a DEBBUILD file meant to be shared with others the main issue (like with every package creation for any distro) is to ensure that the list of dependencies is correct and complete.

To make sure that the list of build dependencies is correct and complete AFAIK there really only is one way: by building the binary packages in a clean chroot freshly set up for each build with a minimal base system.

So IMHO it would be very useful for easydeb to create a standard deb source package in order to be able to take advantage of the mostly automated chroot build process that already exists for deb packaging.

Of course if there is an alternative similarly automated way to do such a chroot build directly with DEBBUILD files then there would be no need for easydeb to be able to create a standard deb source package, but if this doesn't exist yet then IMHO it would be easier to use the already existing sbuild chroot process rather than reinventing the wheel for easydeb.

@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.