Is Devuan a legal entity? If yes in which country? If not, who are those countries making these laws supposed to hold responsible? Certainly not individual devs located all over the world and often not even easily identifiable.

In practice these local laws only have relevance for companies or legal entities who have some kind of presence in the territories affected by these laws.

but I guess some kind of disclaimer such as "Not for use in Brazil/California/whatever" doesn't hurt and is easily done but IMHO that's not really necessary as the standard FOSS licenses disclaimer ("THIS PROGRAM IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.") should already cover that.

With operating systems that don't come preinstalled on a device it is ultimately the user who decides to download and install it who is responsible for it, not the creators, as the creators cannot know where it will be installed and how it will be used.

This is nothing new really, for example there has always been the issue of software patents which apply to the US but not to many other parts of the world and non-commercial non-US based distros have always ignored these local US laws, as they don't apply to them.

Same here, my router is actually a small custom built PC that doesn't even have wifi.

A router provided by the ISP (or even a self-bought off-the-shelf router) is another gaping security hole that I would never allow in my home.

Thanks for that, what I find particularly annoying is when people post LLM slop without even declaring it (and therefore pretending they wrote it themselves), people should at least have the decency to put it in quotes and declare which LLM/chatbot they got it from, just like when quoting from a website or any other source.

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