From my perspective as a XFCE user who has no interest in Wayland and who doesn't have any insight into the details of how XFCE is developed it seems good because it keeps the wayland code (xfwl4) separate from the X11 part (xfwm4) so if in future they drop the X11 part it should be relatively easy for someone to for fork xfwm4 and continue maintaining it.

But if my assessment is wrong then please enlighten me.

@exponentialmatrix
I think you will have more success if you contact the real devs on #devuan-dev at libera.chat like suggested by ralph.ronnquist in his earlier post, this forum doesn't seem to be where the real devs hang out.

@exponentialmatrix ralph.ronnquist suggestion seems sensible, proceed step by step, DUR requires 'easydeb', so first get 'easydeb' into Devuan, that way the fundamental requirement is available in the Devuan repos, after that it's only a matter of making the DUR repo an official part of Devuan.

I support this proposal, I tested easydeb last autumn (as documented in another thread here on this forum) and I found it easy to understand and very usable (not perfect, but no software is perfect).
The only reason I haven't used it again since, is lack of time, but if I have a need to package something again and find the time for it I will use it again.

@camtaf greenjeans is probably saying that the best Debian devs where the ones that left Debian because of systemd and they moved on to create Devuan instead.

There is probably some truth to it, no experienced and self respecting dev with Unix background would put up with such an abomination that systemd is.

Ladybird looks very promising so far  and I hope I will be able to use it instead of Firefox in the future.

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