There's also featherpad in the Daedalus repos, similar to mousepad because it has a toolbar, etc.;  more functional than l3afpad and leafpad.
I just wonder why featherpad hangs for roughly a couple of seconds or more everytime you go File/Open.  Any thoughts why?  Maybe some permissions are too permissive and --lo-- some process could be trying to snoop on your file system?
(#vulnerability?)

I second that, on both accounts!  May Gnuinos please offer an ARM64 iso!  ...and HyperbolaBSD is a useful alternative forward although unfortunately it is not Debian-based, but they recognise the drawbacks of Rust in the kernel and other issues - see their 'Philosophy' listing in the left margin!
Genode with its Sculpt OS is another alternative to the loss of privacy, security and licensing use freedom, and  RISC-V is an up-and-coming architecture, already supported by Debian.

Hi AP,

In case it could be useful for you to experiment, there are Devuan netboost installer images for "orangepi_zero_plus2" and for various other ARM models (i.e. a64-olinuxino, firefly-rk3399,nanopi_neo2, pine64_plus, pinebook-pro, pinebook puma-rk3399, rock-pi-4, rock64, rockpro64, teres_i) that would require to be concatinated with its 'model-specific' firmware.  You may know of that image already and may have passed on it as it is not for your model exactly (I don't know how much it could help - I've not tried it), but if it can help anyone I am flagging those images up by name in this post and, for guidance, there is also README page there.

(Of course, there are also ready images for the Orange Pi One Plus, the Rock Pi, Raspberry Pi, etc at the usual community-build ARM images download page.)

You probably mean "command not found", and try ifconfig instead (not ipconfig).

You could try installing lshw:

sudo apt install lshw

Someone else would have to help you with your topic, because that's all I can do.

1. I too have obsoleted packages, all pi-specific, having also installed one of the arm64 .zip images for Daedalus recently (an rpi-4-devuan-daedalus .... .zip for my Pi 400:

$ apt list '?obsolete'
Listing... Done
linux-headers-bcm2711-rpi-4/now 6.1.54-1 arm64 [installed,local]
linux-image-bcm2711-rpi-4/now 6.1.54-1 arm64 [installed,local]
pi-bluetooth/now 0.1.13 all [installed,local]
raspberrypi-sys-mods/now 20220224 arm64 [installed,local]
rpi-eeprom-images/now 16.1-1 arm64 [installed,local]
rpi-eeprom/now 16.1-1 arm64 [installed,local]

Yet I do not recall instructing any specific pi packages to be upgraded unless it was part of the proposed apt updates/upgrades.

I noted earlier, at about the time that some linux headers didn't install/upgrade (although I can't remember whether it was during my previous installation --an attempted upgrade from Devuan Chimaera to Daedalus or during this Daedalus zip installation) that there were one or more failures reported with the initramfs, including at reboot.  So perhaps these images or upgrades don't work fully automatically for Pis?  There is no /boot/cmdline.txt at present in my /boot directory, somehow;  a line in that file is perhaps akin to the kernel line in non-Raspberry Linux systems.  Yet that cmdline.txt has been useful in part to get apparmor activated in the previous installation, when the file was present (adding  lsm="apparmor" in that file, as indicated elsewhere).  Maybe, in part, if the cmdline.txt were present, perhaps the initramfs would help to avoid obsoleted linux-header packages? 

2. Do you need the backports line in the sources.list?  I wonder if that is also impeding some from packages from getting upgraded;  I thought I had read that the backports repo is a more recent addition to the stable Daedalus release.  I suppose however that you might have had to instruct apt to use a backport for some specific packages, anyway --it's just a thought. 

Could anyone else chime in to help vazhnov, please?  Thank you.

Thanks Zapper!

As an update, I got concerned about removing any Xwrapper recently.  The 'tldr' version is: 

- Could it be wiser to keep xserver-xorg-legacy because parts of my system were not responding?
- Perhaps check that /etc/X11/Xwrapper.config states allowed_users=console and add needs_root_rights=auto ?
- Maybe better run dpkg-reconfigure xserver-xorg-legacy (with doas or sudo) afterwards and select the "Console users only" default because that reconfigure command points out, "A good compromise is to permit the X server to be started only by users logged in to one of the virtual consoles."
- Despite the system recommending for the console user to run X, on my Raspberry Pi 400 system, root ends up running Xorg and the console user/user runs xinit.  I'll leave it "as is" unless someone can improve on this.

The long story:  I noticed cwm acting up;  my key bindings for some applications didn't respond, etc, and I found an old Ubuntu Trusty man page (End of Life: "April 2024") for Xwrapper.config advising:

So that got me concerned that maybe an Xwrapper or an Xwrapper.conf file should be kept.  Reconfiguring x11-common also sounded relevant: (a) xserver-xorg-legacy had been purged;  and (b) that man page goes on to point out that the file could set allowed_users to be rootonly, console, or anybody.

$ doas dpkg-reconfigure x11-common
Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.

Seeing how X socket directories were set, or perhaps reset, could reconfiguring x11-common be an important step to take if one were to amend Xwrapper.config or purge xserver-xorg-legacy?

I hadn't checked originally whether /etc/X11/Xwrapper.config was removed after purging xserver-xorg-legacy.  At any rate, yesterday I tried re-installing --and then purging-- the package again, running doas dpkg-reconfigure x11-common after each of those operations. Unfortunately, I had only noticed that Xwrapper.conf was there after each dpkg-reconfigure operation, so I can't determine from those operations whether (a) each dpkg-reconfigure operation generated an Xwrapper.config;  or (b) whether Xwrapper.config remained throughout, despite the provides command reporting that it was related to xserver-xorg-legacy (see above).  In both instances, there was the same relevant last line:

$ cat /etc/X11/Xwrapper.config 
# Xwrapper.config (Debian X Window System server wrapper configuration file)
#
# This file was generated by the post-installation script of the
# xserver-xorg-legacy package using values from the debconf database.
#
# See the Xwrapper.config(5) manual page for more information.
#
# This file is automatically updated on upgrades of the xserver-xorg-legacy
# package *only* if it has not been modified since the last upgrade of that
# package.
#
# If you have edited this file but would like it to be automatically updated
# again, run the following command as root:
#   dpkg-reconfigure xserver-xorg-legacy
allowed_users=console

That console setting sounded ok.  Debian Bookworm's man page for Xwrapper.config explained:

If dpkg-reconfigure placed that "allowed_users=console" setting, perhaps it worked out that that default "console" setting was suitable; that session was not launched "as root" --remember that a display manager is not installed--, but from .xinitrc's exec startx command "as user" (or "as console"?) with success running rootless, as described above when purging xserver-xorg-legacy, but as pointed out now, with concerning artefacts.  On the other hand, why isn't there the line needs_root_rights=auto which is the "default" setting according to that man quote?

Whatever the case may be, if one makes a change to Xwrapper.conf e.g. to set allowed_users=console, the man page then advises running dpkg-reconfigure as root afterwards, to keep it updated. 

There was no mention found of xserver-xorg-legacy in Debian's forums to date, but its Debian Bookworm package page sheds some light:

From the sounds of it, on the one hand maybe the package wouldn't be relevant for installations such as mine: a Raspberry Pi 400 doesn't sound 'legacy' (and doesn't Devuan run a Linux kernel anyway?), plus I am not using a display manager.  On the other hand, I am inclined to keep xserver-xorg-legacy after the alarming change of behaviour with the lack of any observable cwm key binding response and other artefacts.  Might someone have commandeered those bindings remotely without the package or, perhaps more on point, without me having run dpkg-reconfigure originally? 

Having reinstated xserver-xorg-legacy and afterwards run doas dpkg-reconfigure xserver-xorg-legacy, note two different developments:-

(1) After disabling .xinitrc, and having recently started using an .xserverrc file that ends with
exec /usr/bin/Xorg -nolisten tcp "$@" vt$XDG_VTNR , somehow, upon logging into tty1, an xfce session runs (I had launched some earlier sessions from a different tty using startxfce4 before powering off earlier, in case that is relevant, because I was concerned whether my .cwmrc configuration file had been infected at that point):

$ ps -ef | grep X
myusername    2865  2836  0 18:34 tty1     00:00:00 xinit /etc/X11/xinit/xinitrc -- /home/devuan/.xserverrc :0 vt1 -keeptty -auth /tmp/serverauth.gTdAFhFLt4
root      2866  2865 16 18:34 tty1     00:00:10 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.gTdAFhFLt4 vt1
myusername    3067  3053  2 18:34 tty1     00:00:01 /usr/lib/aarch64-linux-gnu/xfce4/panel/wrapper-2.0 /usr/lib/aarch64-linux-gnu/xfce4/panel/plugins/libnotification-plugin.so 10 18874381 notification-plugin Notification Plugin Notification plugin for the Xfce panel
myusername    3869  3634  0 18:35 pts/0    00:00:00 grep --color=auto X

- Root appears to run /usr/lib/xorg/Xorg
- myusername is now involved with xinit, and wrapper-2.0 or libnotification-plugin !
- /etc/X11/Xwrapper.config had one setting: 
allowed_users=console

Why is root taking over when "allowed_users=console"?  So I thought to explicitly state the default needs_root_rights=auto declaration at the end of /etc/X11/Xwrapper.config in case the system needed to do a needs_root_rights check.

This was followed by the reconfigure command above.  Surprise! the reconfigure command then launches an ncurses dialog box for the first time:

Because the X server runs with superuser privileges, it may be unwise to permit any user to start it, for security reasons.  On the other hand, it is even more unwise to run general-purpose X client programs as root, which is what may happen if only root is permitted to start the X server.  A good compromise is to permit the X server to be started only by users logged in to one of the virtual consoles.                                                                                                                                                                                                                         
Users allowed to start the X server:
                                        Root Only
                                        Console Users Only
                                        Anybody  

					< OK >

Console Users Only is highlighted in red as the recommended choice.  By clicking "OK", it returns the following output:

$ doas  dpkg-reconfigure xserver-xorg-legacy
setting xserver-xorg-legacy/xwrapper/allowed_users from configuration file

...and the line order in /etc/X11/Xwrapper.config was somehow rejigged:-

needs_root_rights=auto
allowed_users=console

(2) Next, having by now run clamscan with no infection found, though not having gone through all folders yet;  plus having cwm regenerate a new .cwmrc (which I soon enhanced); and now launching from tty1 having reinstated .xinitrc with its usual line (exec startx /usr/bin/openbsd-cwm -c ~/.config/cwm/.cwmrc -d :0):

$ ps -ef | grep X
root      2845  2844  8 19:39 tty1     00:00:46 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.f4FDEnqlKD vt1
myusername    2987  2855  0 19:39 tty1     00:00:00 xinit /usr/bin/openbsd-cwm -c /home/devuan/.config/cwm/.cwmrc -d :0 -- /home/devuan/.xserverrc :1 vt1 -keeptty -auth /tmp/serverauth.bBS5DQGfXN
root      2990  2987  0 19:39 tty1     00:00:03 /usr/lib/xorg/Xorg -nolisten tcp :1 vt1 -keeptty -auth /tmp/serverauth.bBS5DQGfXN vt1
myusername    3856  3678  0 19:48 pts/0    00:00:00 grep --color=auto X

So with my preferred setup (running cwm), the system decides for root to run Xorg, and for the console user/user to run xinit.  I'll leave that setup unless someone can improve on this.  The 'tldr' version at the beginning summarises this. Thank you.

Thanks a lot for your input, zapper!  It spurred me to get a better grasp on the 'rootless' environment. Devuan's official release announcement for Daedalus stable sounds as it's about startx running 'rootless':

A "devuan-announce" mailing, if I can summarize it adequately, elaborates about libseat1 controlling 'rootless startx', etc, and its ability to use seatd or elogind. There is the default 'autodiscovery' choice, or one can set the LIBSEAT_BACKEND environment variable. The user needs to be in the video group if using seatd as a backend and, "This is only relevant to running startx as a user, xorg run as root by a display manager is unaffected."

So the announcement is applicable, as I had purged my display manager.  My .xinitrc hadn't been launching Xorg with startx:

[...]
# Launching dbus because it seems to help my browsers' videos not to stutter
# Adapted from https://daemonforums.org/showthread.php?t=5502
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then
	eval `dbus-launch --auto-syntax --exit-with-session`
fi

exec openbsd-cwm -c ~/.config/cwm/.cwmrc -d :0

So, to try startx:

Step 1 - With only one window manager (cwm) being used, and a website reporting the need for the path to the window manager to be specified with startx, the line was changed to:

exec startx /usr/bin/openbsd-cwm -c ~/.config/cwm/.cwmrc -d :0

(Other attempts, such as exec startx openbsd-cwm ... or startx openbsd-cwm ...I would bumped off X with 'Connection to the X server was lost'.  A pointer for newcomers, in case it can help: Ctr+Alt+F5 or with most other Function keys except F1 might probably allow you to login and modify your system in an interactive shell without getting bumped out again, in case you ever get bumped off the X server).

Step 2 - Reset /etc/X11/Xwrapper.config without the added new line (mentioned above, "needs_root_rights = no").  This may be a pointless step, with the solution found later on.

Step 3 - Should LIBSEAT_BACKEND be set somewhere? echo $LIBSEAT_BACKEND returned a blank.  The announcement satisfied my earlier query, explaining that libseat1 is useful for determining this backend. elogind (and five additional elogind packages) was already installed, perhaps out-of-the-box, while seatd was not (apt list --installed | grep seatd).   I don't know whether 'autodiscovery' decided to choose elogind, as seatd was not installed at first, but the connection to X server was still lost on each reboot at this point. Even setting LIBSEAT_BACKEND=elogind or =logind or =seatd in /etc/environment didn't help in successive sessions. Note: from my notes, apparently LIBSEAT_BACKEND=logind appeared originally in that file, but some time ago I thought to comment it out, if memory serves me right, as logind maybe was not installed, and my system posed other challenges. 

I then tried installing seatd in case it was relevant to resolving the lost X server connection, although that eventually got solved, as detailed above.

Step 4 - Checked whether the elogind service might run automatically:

$ doas service elogind status
elogind is running.

Step 5 - My user had already been checked to be in the video group (demonstrated above), so seatd should work for a rootless startx if seatd was chosen as the backend, if the announcement above was interpreted correctly.

Step 6 - Reboot.

Yet Xorg would still run as root (the serverauth file names are modified here in case that this is sensitive info):

$ ps -ef | grep X
root      2861  2860 14 00:53 tty1     00:00:07 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.Ss2Hejt3Av vt1
root      2985  2983  2 00:53 tty1     00:00:00 /usr/lib/xorg/Xorg -nolisten tcp :1 vt1 -keeptty -auth /tmp/serverauth.OJ9BbzLd8m vt1
myusername    3622  3618  0 00:54 pts/0    00:00:00 grep --color=auto X

With no success so far, next, gratefully, was to attempt soren's solution.  He was bang on the money, thank you very much!  Xwrapper did get in the way of startx running 'as user' until it was purged!

Note from my earlier reply, before installing seatd, that the output was blank (except for picking up my grep query).  Next, with seatd installed:

$ ps -ef | grep seatd
root      2033     1  0 01:13 ?        00:00:00 /usr/sbin/seatd -g video
myusername    3875  3621  0 01:25 pts/0    00:00:00 grep --color=auto seatd

The Xwrapper package was suspected to be xserver-xorg-legacy:

$ provides Xwrapper.conf

dpgk -S filename works for installed packages only.  Otherwise, use  apt-file but need to do
sudo apt-file update   first and then apt-file search filename

xserver-xorg-legacy: /usr/share/man/man5/Xwrapper.config.5.gz

It didn't pull away any other packages when purging it:

$ doas apt purge xserver-xorg-legacy && doas apt autoremove 

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  xserver-xorg-legacy
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 234 kB disk space will be freed.
Do you want to continue? [Y/n] 

With xserver-xorg-legacy gone; seatd installed; (elogind and seatd services both running, in case that is relevant); and with any LIBSEAT_BACKEND environment setting commented out in /etc/environment, Xorg would run 'rootless' without a display manager!

elogind had best stay:  purging it would have meant removing 252 packages on my system, including calligra, network-manager, okular and udisks2.

So, maybe the apt dist upgrade procedure didn't remove the Xwrapper for those who needed it for some good reason.  A mystery remains as to why the connection to the X server would repeatedly be lost when setting LIBSEAT_BACKEND=logind or =elogind or =seatd in /etc/environment, except when that line was commented out.  Maybe /etc/environment isn't understood correctly as the meant place for the LIBSEAT_BACKEND setting?  According to one post:  "You can see the programs using /etc/environment with grep -l pam_env /etc/pam.d/* "

In my installation:

$ grep -l pam_env /etc/pam.d/*
/etc/pam.d/cron
/etc/pam.d/login
/etc/pam.d/sshd
/etc/pam.d/su  

Or perhaps login in /etc/pam.d/ is related to libseat1?

Anyway, thanks a lot for your help, participants!

Pulseaudio is actually offered to be replaced by pipewire in Devuan's stable version (Daedalus), and although I am occasionally missing sound also, steps such as those reported in this forum helped me: 

1. Remove pulseaudio (but keep pavucontrol, as you can launch that to help set some audio levels):

sudo apt purge pulseaudio && apt autoclean && apt autoremove

2. Make sure that pipewire, wireplumber are running:  systemd uses services for that, but the solution discussed in that post helped me:

- Either set up launcher.sh to launch automatically in Gnome with the contents as described for the 'alpine solution' (the link there leads to pipewire-launcher.sh)
Comment out (put a '#' symbol) at the start of any line containing pipewire-media-session, as that is not used currently in Devuan stable, I believe.

- Or else you could enter its contents (except for the first line: "#!/bin/sh") near the top of ~/.xinitrc if you have that file.

3.  If, after all that, you still don't have sound, for now, you could try launching wireplumber, and then your browser, media, etc, could give you sound after relaunching them.  It's my temporary solution, as I haven't found a long-term solution since reporting a similar problem:  for example, in a terminal (the terminal will close, to get it out of the way):

nohup wireplumber & exit

One amendment: To toggle full screen mode for Calligrasheets, it is Ctr+F11.  I thought that there was some challenge with Calligra's full screen!  Lol    Have a good evening!

Maybe my system got infected, perhaps exploiting, again presumably, a vulnerability elsewhere:  fbpanel was preserved from my original Chimaera installation, persisting through the dist upgrade to Daedalus despite it no longer being offered by Daedalus nor its Debian equivalent, Bookworm, I noticed today.  Maybe the following points to its imminent removal from the repository:  https://lists.debian.org/debian-qt-kde/ … 00131.html

See the reason given in a link there:  "Python2 becomes end-of-live upstream, and Debian aims to remove Python2 from the distribution [...]".

It is not maintained upstream:  https://github.com/aanatoly/fbpanel .

I suspected fbpanel to be compromised more recently, as its menu icons stopped displaying, even after restarting it or firejailing it, etc.  Fbpanel has now been purged and replaced with tint2. Mousepad and the Calligra suite may be again retried at a later date:  perhaps they might not be culprits, although mousepad and calligrasheets were not launched from fbpanel when their artefacts manifested:  they were launched from .xinitrc.

Clock still fails to update until roughly an hour after bootup very occasionally, two weeks later. 

'[SOLVED]' in title cannot seem to be able to be removed.