Regardless of that, any updates will likely be too late. I just copy the yt-dlp script to my user's bin/ so I don't have to be root to update it, and I update it whenever I use it. (run: yt-dlp -U)
From here: https://github.com/yt-dlp/yt-dlp

this aligns with "next-testing" and "testing" from the reportbug-window in gui-mode.

have included reference to the 3 packages, but the rest is up to the responsible persones.
if the program is included int the repos, it should be able to run - no questions asked - that is maybe universally agreeable.

thank you again for letting  know of the program and proposing a "fix".

zk is not available in the official Debian repositories, which is the reason for it not being in the Devuan repositories.

If and when it gets included in the Debian repositories and has no 'unfixable' dependencies on systemd, you will find it after a few days in the Devuan repositories.

Until then, you (most probably) have the option of building it from source.

Best,

A.

Recompiling a debian package for devuan makes no sense. For 99% of the packages in the repository, that's like saying you want to recompile a debian package for debian. They are the exact same packages. Whenever you install something in devuan, if it's not one of our forked packages, apt pulls it from the debian repository. Amprolla stands between you and the debian repo to filter out the banned packages.

Certainly, if you want to change something in the package, then yeah, you can recompile it with your changes.

That's what we do with the packages we fork. We recompile them to remove the systemd dependency.
Here's some documentation about that: https://git.devuan.org/devuan/documenta … ngGuide.md

What a terrible idea. IOW, probably what they are doing.

Note it is still available for "bleeding edge" Debian sid, so there must be some other die-hards out there.

I've installed debfoster, and I'll play around with it.
It didn't show up o google searches, or in a synaptic search, so something new learned.
I'll mark this "closed".

Sorry, I thought I'd answered to the "did you update" question above, but apparently I forgot to post or did something wrong :-/

Then, typically, a version code without "devuan" in it indicates that the package is directly a Debian package, whereas a package with "devuan" in it is a Devuan package; i.e., forked typically from Debian packaging sources, modified and built in the Devuan build pipeline and published in the Devuan specific repository overlay.

After boot:

$ sudo ./ps_mem.py -p "`pgrep -f -d, 'wicd|NetworkManager|nm-applet'`"
 Private  +   Shared  =  RAM used	Program
 16.0 KiB + 843.5 KiB = 859.5 KiB	wicd-client
984.0 KiB + 513.5 KiB =   1.5 MiB	python3.13
  1.9 MiB + 642.5 KiB =   2.5 MiB	nm-applet
  2.8 MiB + 661.5 KiB =   3.5 MiB	wicd
  4.0 MiB + 762.5 KiB =   4.7 MiB	NetworkManager

After some time:

984.0 KiB + 429.5 KiB =   1.4 MiB	python3.13
  1.3 MiB + 843.5 KiB =   2.1 MiB	wicd-client
  2.0 MiB + 583.5 KiB =   2.5 MiB	nm-applet
  2.8 MiB + 576.5 KiB =   3.3 MiB	wicd
  3.3 MiB + 307.5 KiB =   3.6 MiB	NetworkManager

With Wicd GUI window open and Wifi networks shown:

  1.6 MiB + 815.5 KiB =   2.4 MiB	python3.13
  2.2 MiB + 597.5 KiB =   2.8 MiB	nm-applet
  2.5 MiB + 346.5 KiB =   2.9 MiB	NetworkManager
  5.9 MiB +   1.0 MiB =   6.9 MiB	wicd
 37.3 MiB +   5.9 MiB =  43.2 MiB	wicd-client

Wicd GUI closed (hidden), nm-applet showing Available networks->

  1.6 MiB + 815.5 KiB =   2.4 MiB	python3.13
  2.8 MiB + 346.5 KiB =   3.2 MiB	NetworkManager
  5.9 MiB +   1.0 MiB =   6.9 MiB	wicd
  5.7 MiB +   2.7 MiB =   8.5 MiB	nm-applet
 36.7 MiB +   4.9 MiB =  41.6 MiB	wicd-client

(After a while...) Wicd GUI closed (hidden), nm-applet showing Available networks->

  1.6 MiB + 814.5 KiB =   2.4 MiB	python3.13
  2.8 MiB + 346.5 KiB =   3.2 MiB	NetworkManager
  6.0 MiB +   1.0 MiB =   7.0 MiB	wicd
  5.9 MiB +   2.7 MiB =   8.7 MiB	nm-applet
 36.7 MiB +   4.9 MiB =  41.6 MiB	wicd-client

Running wicd-curses:

  1.5 MiB + 673.5 KiB =   2.2 MiB	python3.13
  2.8 MiB + 337.5 KiB =   3.1 MiB	NetworkManager
  7.1 MiB + 881.5 KiB =   7.9 MiB	wicd
  5.9 MiB +   2.7 MiB =   8.6 MiB	nm-applet
 27.5 MiB +   2.4 MiB =  29.9 MiB	wicd-curses
 34.8 MiB +   4.6 MiB =  39.4 MiB	wicd-client

(30 minutes later...) wicd-curses is running:

  1.5 MiB + 437.5 KiB =   1.9 MiB	python3.13
 44.0 KiB +   2.0 MiB =   2.0 MiB	wicd-client
  2.4 MiB + 905.5 KiB =   3.3 MiB	nm-applet
  4.0 MiB + 201.5 KiB =   4.2 MiB	NetworkManager
  6.0 MiB + 859.5 KiB =   6.8 MiB	wicd
  5.6 MiB +   1.8 MiB =   7.4 MiB	wicd-curses

This might be irrelevant, but it is part of the NM-suite.

400.0 KiB + 115.5 KiB = 515.5 KiB    ModemManager

PS. I don't know how to memory test ephemeral process like wicd-cli.

I use this interactive script so I don't have to type as much. Run it from the directory that contains the iso files. Code is mostly lifted from refracta2usb which can make a multi-boot live-usb and is a lot bigger than this.

You need hwinfo and pv installed for this to work.

That would be nifty to make a right-click file-manager extension.

I've encountered an issue with the minidlna (ReadyMedia) init script on Devuan (SysVinit). The service fails to rebuild the database when the -R or -r flag is used, resulting in the following error:

minidlna.c:944: fatal: Failed to clean old file cache /var/cache/minidlna. EXITING

The Cause: The /etc/init.d/minidlna script correctly handles permissions for the LOGFILE and PIDFILE directories in the do_start() function, but it fails to do the same for the db_dir (default: /var/cache/minidlna). If the directory is owned by root (which happens during some installation scenarios or manual cleanups), the minidlna user cannot delete the old files.db.

Proposed Fix: In /etc/init.d/minidlna, within the do_start() function, we should ensure the database directory exists and has the correct ownership.

Currently, it only does:

mkdir -p "$(dirname "$LOGFILE")" && chown $USER:$GROUP "$(dirname "$LOGFILE")" || return 2
mkdir -p "$(dirname "$PIDFILE")" && chown $USER:$GROUP "$(dirname "$PIDFILE")" || return 2

It should also include something like:

mkdir -p /var/cache/minidlna && chown -R $USER:$GROUP /var/cache/minidlna || return 2

(Note: A more robust approach would be to parse db_dir from /etc/minidlna.conf, but ensuring the default path at least would solve most cases.)

Without this, any attempt to refresh the library after deleting files (which requires rebuilding the cache) fails silently or crashes the daemon.

Best regards,

balena etcher was able to clone sd-card to a bigger sized one with no issues;
(maybe the read-command functions only with drives that have no-multi-partition, not with ones like contains libreelec)

It's KDE bro, lol.

Some folks just want a system that's a good tool to accomplish various tasks. (that's me)

But some folks want a complete immersive cinematic-style experience with lots of animations and transitions

Discover was one of the reasons I gave up kde (ceasing to allow different backgrounds for different desktops was another). So it was a package manager? I never did find out because although it kept popping up that it had updates for me, behaving like an annoying phone app, when I tried responding to it out of exasperation nothing happened. Couldn't find a way to uninstall it either, must have been baked in.

what happened do gnome-hearts?

It was removed in 2018.

https://tracker.debian.org/pkg/gnome-hearts