The officially official Devuan Forum!

You are not logged in.

#1 Re: Devuan » APT source.list for Devuan 5.0.1 » 2024-02-16 21:55:26

Thanks for your feedback, The-Amnesiac-Philosopher , it made me reconsider my setup.  I also get a 2-3 second hang for File/Save as... or when I click on either of those problematic file operations' toolbar buttons.  Those hangs seem to be due to the fact that featherpad was being launched with an QT_... environment variable for theming, as I just noticed that it doesn't hang from a plain cli launch;  I had also built it from source.  So, something encouraging! 
I like featherpad too, and it's much smaller than mousepad!

#2 Re: Devuan » APT source.list for Devuan 5.0.1 » 2024-02-16 10:13:58

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?

#3 Re: Other Issues » [SOLVED] Can't connect to repos » 2024-02-09 20:57:50

The same problem began occurring to me roughly two days before this thread began on 7th February, so I am yet another user reporting this problem recently, in case it could help anyone at Devuan to consider whether there is some misconfiguration of any server that ought to be addressed.
The solution used by entropyagent, which included changing the nameserver e.g. to, did solve the problem for me when it was implemented about two days ago, followed by chattr +i /etc/resolv.conf as also suggested.
Moments ago, when I tried to revert the nameserver to my original [IP?] nameserver (beginning 192.16x),  $ ping hung, so the original problem persists when using the original nameserver.

#4 Re: Devuan Derivatives » GNUinOS - Libre » 2023-12-26 15:10:32

zapper wrote:

Tell me if you support ARM64 in the future. I would love to use this on my pocket mnt reform. it will be a while till other options, HyperbolaBSD for example... show up.

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.

#5 Re: Installation » KDE Desktop » 2023-12-26 01:53:24

sisqonrw wrote:

ok i wanted to try and test


but after boot there is black terminal screen and askin login and passwort.

is that normal?

The desktop live iso may have been sufficient to launch a desktop environment, but you can always install one.  Setup your timezone and other useful settings with menu-config, update your system, and then run tasksel:

sudo menu-config
sudo apt update && sudo apt upgrade
sudo tasksel

In tasksel, you can choose to install "Devuan desktop environment" and various different desktop environments, including KDE.
You might have to fix something with debconf, in my experience, if there is a failure with tasksel.  Maybe someone reading this could explain why the following instruction might help. This tended to maybe just happen if I hadn't updated the system first, in my experience, and if I recall correctly:

sudo ./usr/share/debconf/


sudo dpkg-reconfigure keyboard-configuration
sudo reboot

That could save you or others from trying to reinstall a system.  Tasksel is useful for netinstalls, and I suppose it shouldn't be necessary for Desktop live isos like yours unless one wants to use it to perform a quick, handy installation of additional desktop environments.

#6 Re: ARM Builds » Orange Pi Zero 3 » 2023-12-05 21:11:44

Hi AP,

AP wrote:

I've just got an Orange Pi Zero 3.

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

#7 Re: Devuan Derivatives » how to add freely PPA's for firefox or seamonkey-mozilla-build? » 2023-11-13 20:01:30

Hey oui,

If you want an early Firefox fork, why not help test and suggest improvements on the UXP-based Basilisk browser?  It doesn't use Rust, a code with proprietary implications!  "Most XUL extensions compatible with Firefox 52 should work", according to that link.

Once you download the .tar file, say, in the ~/bin folder that you might have, untar the file, check its sha256sum, and then you can launch the basilisk-bin file in a terminal by doing:

$ ~/bin/basilisk/basilisk-bin

You can also put a link to it in ~/bin so that your system will find it quickly:

$ ln -s ~/bin/basilisk/basilisk-bin ~/bin/basilisk-bin

Then, if ~/bin is in your system's path, then your system could probably display a Basilisk shortcut in any system-refreshed menu that you might have, or in dmenu or rofi, or you could also launch it easily from a terminal:

$ basilisk-bin

Videos play ok in the browser, in my experience, although you might find like me that, at least for now, while in development, pages don't load as fast as in other GTK browsers, especially at first.

By the way, Seamonkey doesn't have one good report for privacy.   If an early FF browser is what you want, help out to use and test Basilisk for a good Rust-free experience.

#8 Re: Hardware & System Configuration » LAN without conection - RTL810XE PCI Express Driver r8169 » 2023-10-19 23:59:52

I cannot provide information regardin "ipconfig" or "lshw" (terminal says: order not found)

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.

#9 Re: ARM Builds » Obsolete packages in Raspberry Pi image » 2023-10-12 04:18:10

Thanks also for the additional insights on eeprom, pi-bluetooth and sys-mods, c0rnelius, they are appreciated.

#10 Re: ARM Builds » Obsolete packages in Raspberry Pi image » 2023-10-10 22:14:09

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.

#11 Re: Other Issues » [SOLVED] /.config and /.cache with Daedalus » 2023-10-05 04:20:03

To install pipewire for X11, the first step, from Debian Pipewire's Github (a Wayland arrangement is mentioned in that link), would be to add their repo, but, you might be better off just tracking Devuan's repos.  You can use doas preferably over sudo, but we'll have to omit pipewire-locales, as it is not in Devuan Daedalus' repo at the moment, so instead of...

doas apt install gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,bin,jack,alsa,v4l2,libcamera,locales,tests}}

...leave out the locales package if you can do without it, and instead do:

doas apt install gstreamer1.0-pipewire libpipewire-0.3-{0,dev,modules} libspa-0.2-{bluetooth,dev,jack,modules} pipewire{,-{audio-client-libraries,pulse,bin,jack,alsa,v4l2,libcamera,tests}}

You might have some of the above packages already installed in Devuan Daedalus, but apt should pass on those.

Install some 'recommends':

doas apt install libcamera-ipa pipewire-doc

Useful also, including pavucontrol to control audio levels:

doas apt install libpipewire-0.3-modules-x11 pavucontrol
doas apt-get install wireplumber{,-doc} gir1.2-wp-0.4 libwireplumber-0.4-{0,dev}

Make sure that apt responds to the following by saying that xdg-desktop-portal is installed:

apt list --installed | grep xdg-desktop-portal

If not, install it.  In my experience, at least in my gtk environment, to avoid some muted videos in a browser for example, it is good to also install a portal backend for xdg-desktop-portal.  So depending on whether your desktop environment is Gnome, gtk, KDE, etc, one of the following could be helpful to install:

$ apt-cache search xdg-desktop-portal
xdg-desktop-portal - desktop integration portal for Flatpak and Snap
xdg-desktop-portal-dev - desktop integration portal - development files
xdg-desktop-portal-gnome - GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-gtk - GTK+/GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-kde - backend implementation for xdg-desktop-portal using Qt
xdg-desktop-portal-tests - desktop integration portal - automated tests
xdg-desktop-portal-wlr - xdg-desktop-portal backend for wlroots

Get rid of some material, which, in my experience, might not have been purged by apt:

doas apt purge libkf5pulseaudioqt3 libpulsedsp pulseaudio-utils
doas apt autoclean && doas apt autoremove

Next, make pipewire and wireplumber start properly, say, by using the so-called 'Alpine solution' mentioned in post No. 4 above.  At the moment, Devuan users might have to prepare scripts, whereas Debian uses systemd services instead.  The Alpine solution script, as an autostart file or using a similar text in your ~/.xinitrc file if you have one, might not be the appropriate solution, however, so you might have to investigate.  Other similar scripts appear in this forum.

A good tip from Altoid could be to avoid having some other package dragging pulseaudio back on your system.  So pin the package off by opening an editor and starting a new file like so:

doas rnano -w /etc/apt/preferences.d/avoid_pulseaudio

Enter the following text in that file.  Ctr+S to save and Ctr+x to exit that rnano editor.

Package: pulseaudio:*
Pin: version *
Pin-Priority: -1

Reboot.  I hope this helps.  If anyone can improve on this, please let us know.  Thank you.

EDIT:  This upstream Debian pipewire github page may not mention any configuration;  pipewire currently seems to fail for me without any.  Note that I am only a user, but I am trying to share my successes.  So, we'll continue by following Debian 12's wiki section and adapting it to Devuan Daedalus;  note particularly:

A notable change compared to Debian 11 is that the configuration directory has been moved from /etc/pipewire/ to /usr/share/pipewire/: you may want to get rid of the former to avoid confusion.

Debian 12's wiki section otherwise tracks the section for Debian 11, so we will update any such references in Debian's 11's wiki section to /usr/share/pipewire/ .

Also, instead of applying the systemd or perhaps also pactl directives, we'll rely as stated earlier on running pipewire and wireplumber either from .xinitrc or in autostart batch files (or perhaps in .xsessionrc).  The wiki also uses systemctl commands (a "daemonless "systemctl" command to manage services without systemd", according to apt), but in my experience, perhaps one might be able to do without installing that.

The wiki recommends applying instructions of "all" three sections, yet somehow there is also a fourth section -- PulseAudio ("replacing PulseAudio completely"), Alsa, JACK and bluetooth:

The three instructional sections below are independent of each other, but you are still highly recommended to use PipeWire to replace all of them if you intend to replace any of it, for the best integration between different applications.

At any rate, bluetooth seems to take care of itself, as no configuration action is mentioned; we had already installed libspa-0.2-bluetooth earlier.

For PulseAudio, which is being replaced:

doas mkdir /usr/share/pipewire/media-session.d
doas touch /usr/share/pipewire/media-session.d/with-pulseaudio

As mentioned earlier, we'll pass over the commands to create services ("Create a pipewire-pulse service by copying the example files"); we'll also pass over the guide to run wireplumber as root.

Next, for Alsa:

doas touch /usr/share/pipewire/media-session.d/with-alsa

Our master guide (Debian 11 as a guide for Debian 12) then instructs: # cp /usr/share/doc/pipewire/examples/alsa.conf.d/99-pipewire-default.conf /etc/alsa/conf.d/ .  As there appears to be no Alsa configuration example folder in Daedalus (/usr/share/doc/pipewire/examples/alsa.conf.d/), hopefully there is no Alsa configuration file needed.

Next, for JACK, and remembering to use /usr/share/pipewire instead of /etc/pipewire:

doas touch /usr/share/pipewire/media-session.d/with-jack

There is one example configuration file for JACK, and it's not yet at the target folder (/etc/, so try copying it over:

doas cp /usr/share/doc/pipewire/examples/*.conf /etc/

Create links and cache:

doas ldconfig

Now launch pavucontrol aka PulseAudio Volume Control (although it is hardly dependent on PulseAudio in Devuan), and under 'Configuration', set one or more profiles to 'Pro audio'.  Pipewire runs fine now for me.

Note:  As an alternative to being inspired by the 'Alpine solution' above, I am now starting up packages in .xinitrc as suggested elsewhere in this forum, but adding 2-4 second delays.  Try placing the instructions high up in .xinitrc (or perhaps .xsessionrc), before any audio package command such as amixer;  perhaps those may need to be delayed similarly.

pipewire &
( sleep 2 ; pipewire-pulse) &
( sleep 4 ; wireplumber) &

I hope this helps.

#12 Re: ARM Builds » [SOLVED] X server / X11 / Xorg / X not running rootless by default? » 2023-09-28 03:20:17

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:

       /etc/X11/Xwrapper.config  contains  a  set of flags that determine some of the behavior of
       Debian's X server wrapper, which is installed on the system as /usr/bin/X.  The purpose of
       the wrapper, and of this configuration file, is twofold.

       Firstly,  it  is  intended  to  implement  sound  security  practices.  Since the X server
       requires superuser privileges, it may be unwise to permit just any user on the  system  to
       execute  it.   Even if the X server is not exploitable in the sense of permitting ordinary
       users to gain elevated privileges,  a  poorly-written  or  insufficiently-tested  hardware
       driver  for  the  X  server  may  cause  bus  lockups and freeze the system, an unpleasant
       experience for anyone using it at the time.

       Secondly, a wrapper is a convenient place to set up an execution  environment  for  the  X
       server distinct from the configurable parameters of the X server itself.

       Xwrapper.config  may be edited by hand, but it is typically configured via debconf(7), the
       Debian configuration tool.  The X server wrapper is part of the x11-common Debian package;
       therefore, the parameters of Xwrapper.config may be changed with the command
              dpkg-reconfigure x11-common.

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

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

allowed_users = rootonly|console|anybody
    Specify  which users may start the X server through the wrapper. Use rootonly to only allow root, use console to only allow users logged into a physical console, and use anybody to allow anybody.  The default is console.

needs_root_rights = yes|no|auto
    Configure if the wrapper should drop its elevated (root) rights before starting the X server. Use yes to force execution as root, no to force execution with all suid rights dropped, and auto to let the wrapper auto-detect. The default is auto.

When auto-detecting the wrapper will drop rights if kms graphics are available and not drop them if no kms graphics are detected. If a system has multiple graphics cards and some are not kms capable auto-detection may fail, in this case manual configuration should be used.

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:

setuid root Xorg server wrapper
This package provides a wrapper for the Xorg X server, which is necessary for legacy drivers and non-Linux kernels.

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/ 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: 

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

					< 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:-


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

#13 Re: Other Issues » [ Sound problem ] Flakey1Lamp » 2023-09-26 03:18:40

Hi Flakey1Lamp, Latety, I found a post stating that xdg-desktop-portal-gtk helped to improve their sound with pipewire.  I recently installed that, and it seems to be giving me more consistent audio in my browser also.
In your case, because you run Gnome, however, I think that having xdg-desktop-portal-gnome might be more appropriate.  Make sure that you have it installed.  For those who don't have Gnome or a gtk desktop installed, perhaps check out what's available for your system:

$ apt-cache search xdg-desktop-portal    
xdg-desktop-portal - desktop integration portal for Flatpak and Snap
xdg-desktop-portal-dev - desktop integration portal - development files
xdg-desktop-portal-gnome - GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-gtk - GTK+/GNOME portal backend for xdg-desktop-portal
xdg-desktop-portal-kde - backend implementation for xdg-desktop-portal using Qt
xdg-desktop-portal-tests - desktop integration portal - automated tests
xdg-desktop-portal-wlr - xdg-desktop-portal backend for wlroots

...and then make sure that the relevant package for their desktop environment is reported as being "installed";  in my case, with a gtk setup:

$ apt list --installed | grep xdg-desktop-portal-gtk

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

xdg-desktop-portal-gtk/stable,now 1.14.1-1 arm64 [installed]

If it's not installed, try installing it (using doas or sudo):

$ doas apt install xdg-desktop-portal-gtk

So make sure that you have pipewire and its related packages installed in the first place, and then some scripts like the ones I wrote about, plus this kind of xdg package.  I hope this helps, although I am trying to get things right myself.  If someone has a good working audio setup, please chime in, thanks!

#14 Re: ARM Builds » [SOLVED] X server / X11 / Xorg / X not running rootless by default? » 2023-09-25 08:32:15

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':

Rootless startx uses libseat1

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
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]; then
	eval `dbus-launch --auto-syntax --exit-with-session`

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!

soren wrote:

what is the output of below command, you should not need xorg wrapper.

ps -ef | grep seatd

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:
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/*

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

Anyway, thanks a lot for your help, participants!

#15 Re: Desktop and Multimedia » Files disappearing » 2023-09-24 18:32:08

Maybe would you be 'missing' hidden files and hidden folders?  Those are files and folders with a dot in front of the file name.

They will display on and off in your file manager (thunar, spacefm, etc) by hiting Ctr+h.

Or you can see them if you navigate to that folder in a terminal.  For example, go to your home page (cd ~), and do:

ls -a

Usually, if you just list files without the -a option, hidden files and hidden folders won't display.  For an illustration, in the terminal at your home page, you will notice that hidden files and hidden folders don't get listed if you just do:


Also, your file manager might arrange icons in 'detailed view' or an 'icons view'.  So the list can look shorter then. That can vary for each folder, unless you set that view for all folders.  Does anyone else know of other possibilities?

#16 Re: Other Issues » [ Sound problem ] Flakey1Lamp » 2023-09-24 14:16:07

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 to launch automatically in Gnome with the contents as described for the 'alpine solution' (the link there leads to
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

#17 Re: ARM Builds » [SOLVED] X server / X11 / Xorg / X not running rootless by default? » 2023-09-24 12:48:11

Thank you.

$ ps -ef | grep seatd
myusername    3903  3899  0 08:18 pts/0    00:00:00 grep --color=auto seatd

I had been wondering about some seat messages;  to update (again, changing my username to 'myusername':

seatd is not installed but libseat1 is, yet if I understand correctly, seat would be relevant in systems like mine whose display manager was removed, for interactions with the display.

$ apt list --installed | grep seat 

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libseat1/stable,now 0.7.0-6 arm64 [installed,automatic]

Notice seatd_libseat errors in Xorg.0.log, among other errors; note that some messages may relate to the use of a PS/2 converter cable and old keyboard and mouse PS/2 devices that hopefully use a lower amperage, for health reasons:

 $ cat Xorg.0.log  | grep "(EE)" -1
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    67.585] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Sep 21 22:00:22 2023
[    71.899] (II) seatd_libseat try close /dev/input/mouse0 (-1:-1)
[    71.899] (EE) seatd_libseat device not open (/dev/input/mouse0)
[    71.901] (II) config/udev: Adding input device CHESEN PS2 to USB Converter System Control (/dev/input/event2)
[    72.048] (II) seatd_libseat try open /dev/input/event7
[    72.050] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[    72.050] (EE) seatd_libseat open /dev/input/event7 (-1) failed: -11
[    72.050] (**) vc4: always reports core events
[    72.052] (II) seatd_libseat try open /dev/input/event8
[    72.053] (EE) [libseat/backend/logind.c:137] Could not take device: Device already taken
[    72.053] (EE) seatd_libseat open /dev/input/event8 (-1) failed: -11
[    72.054] (**) vc4: always reports core events
[    75.916] (II) modeset(0): Disabling kernel dirty updates, not required.
[   853.977] (EE) event1  - CHESEN PS2 to USB Converter Mouse: client bug: event processing lagging behind by 21ms, your system is too slow
[  1362.632] (EE) event0  - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 36ms, your system is too slow
[  1518.837] (EE) event0  - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 25ms, your system is too slow
[  9311.158] (EE) event0  - CHESEN PS2 to USB Converter: client bug: event processing lagging behind by 33ms, your system is too slow
[ 10544.041] (II) event1  - CHESEN PS2 to USB Converter Mouse: device removed
[ 10544.305] (II) seatd_libseat try close /dev/input/event8 (40:40)
[ 10544.339] (EE) [libseat/backend/logind.c:199] Could not close device: Interrupted system call
[ 10544.339] (EE) seatd_libseat close failed 0
[ 10544.356] (II) UnloadModule: "libinput"
[ 10544.356] (II) seatd_libseat try close /dev/input/event7 (39:39)
[ 10544.749] (II) seatd_libseat try close /dev/input/event4 (30:30)
[ 10544.753] (EE) [libseat/backend/logind.c:199] Could not close device: Interrupted system call
[ 10544.753] (EE) seatd_libseat close failed 0
[ 10544.894] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error
[ 10544.894] (II) seatd_libseat finish
[ 10544.898] (EE) [libseat/backend/logind.c:365] Could not release control of session: Interrupted system call
[ 10544.898] (II) Server terminated successfully (0). Closing log file.

Note also interesting security concerns expressed elsewhere about whether the user should be in the 'video' or 'seat' groups (in Gentoo anyway): .  I am not in the seat group:

$ id
uid=1000(myusername) gid=1000(myusername) groups=1000(myusername),5(tty),6(disk),20(dialout),27(sudo),29(audio),44(video),46(plugdev),102(netdev),104(input),106(render),109(bluetooth),110(i2c),1001(gpio),1002(spi)

So, if this type of installation does not need an xorg wrapper, how does one remove it?

#18 ARM Builds » [SOLVED] X server / X11 / Xorg / X not running rootless by default? » 2023-09-24 02:19:15

Devuan Chimaera was upgraded to Daedalus using standard bash instructions recently (on a Raspberry pi 400 arm64 architecture), and the X server was noted to not be running rootless despite this being a safer mode and a new feature of Daedalus/Debian Bookworm;  as demonstrated by a test used in Debian:

$ ps -ef | grep X
root      2906  2905 10 Sep21 tty1     00:16:45 /usr/lib/xorg/Xorg -nolisten tcp :0 vt1 -keeptty -auth /tmp/serverauth.Sv2CPp0SVI vt1
myusername   17812 17235  0 00:45 pts/0    00:00:00 grep --color=auto X

Would the following implementation to run Xorg 'as user' indeed be appropriate, adding a line to /etc/X11/Xwrapper.config, as per an entry in the webpage cited above (using doas or sudo)?  I couldn't find a relevant Debian wiki page.

$ doas rnano -w /etc/X11/Xwrapper.config 
# Adding following line to ensure that Xorg runs as user
needs_root_rights = no

Followed by a reboot.  It appears to work for me.

Note that the display manager had previously been purged while in Chimaera to replace it with the system's interactive text login using an .xinitrc file (plus .bash_profile, .profile, and a soft link from .xsession to .xinitrc).

Is Daedalus/Bookworm not implementing this out-of-the-box because it could break some systems' setups, say, in case their GPU driver requires X server to run as root, or is there something missing?

#19 Re: Desktop and Multimedia » use Bluetooth » 2023-09-23 12:52:56

There were a variety of different working solutions reported in Archlinux by different users for you to try, if you can just remember or lookup (or ask) for the equivalence of any service handling between systemd and your Devuan init.  Would pulseaudio-bluetooth in Arch correspond to pulseaudio-module-bluetooth in Devuan?
There were also solutions reportedly working on previous pages of that thread.  If something works for you, please let us know, thanks!

#20 Re: ARM Builds » [SOLVED] Vulnerability in Mousepad? Unable to drag, resize, or lower in cwm » 2023-09-23 03:22:41

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  smile  Have a good evening!

#21 Re: ARM Builds » [SOLVED] Vulnerability in Mousepad? Unable to drag, resize, or lower in cwm » 2023-09-22 22:37:44

The artefacts recently were found to be due to these applications apparently starting in full screen mode;  the solution was to strike the F11 to toggle full screen off, as that thankfully appears to be a relevant key-binding in common for all these applications, although calligrasheets had to be toyed with a bit:  the calligra suite had been later reinstalled, and I think F11 would only respond by closing the calligra worksheet and applying F11 with the calligra startup application that appeared.

Note that Featherpad also had developed similar artefacts, turned off also with F11Featherpad could not be dragged or resized with the default mouse bindings;  the default 'lower window' binding had since been modified by choice to 'maximize window', and that wouldn't respond either.

These artefacts had persisted even when blackbox, a different window manager, was installed, including (a) with Mousepad when it was reinstalled;  and (b) more recently, with xfce4-terminal.

That 'full screen' suspicion and F11 solution were proposed in 2013 for a similar situation with some LXDE application(s).  One argument brought up for applications possibly starting in full screen mode was that it might be related somehow to some new theme(s) being applied.  In my case, some themes from Devuan's official repos had indeed been installed earlier and, for what it's worth, later applied with an excellent LXDE theme manager:  lxappearance.

Therefore, I could not identify any vulnerability, and this thread has been closed although, in case it could be 'remotely' relevant, a 'dlm' error was also noted on logout, but I can't find it in any current /var/log file. Why would there be need for a 'distributed lock manager' on my standalone pc?  How could a lone dlm package - libdlm3, a 'Distributed Lock Manager library' - have appeared on my system? After a bit of research, I decided to remove it without any noticeable knock-on effect, except the error occasionally was noted to persist on logout.

#22 Re: ARM Builds » [SOLVED] Vulnerability in Mousepad? Unable to drag, resize, or lower in cwm » 2023-09-18 00:19:32

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: … 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: .

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.

#23 Re: ARM Builds » [SOLVED] Vulnerability in Mousepad? Unable to drag, resize, or lower in cwm » 2023-09-15 22:29:37

I have now noticed, days later, that Calligrasheets also cannot be dragged, resized or lowered despite using the default key bindings either.  It was also launched from .xinitrc with a file as an argument while firejailed e.g.:

/usr/bin/firejail  --net=none /usr/bin/calligrasheets '/home/someusername/Documents/Somefile.ods' &

Note that mousepad had also been launched from .xinitrc, but with a check for the latest version of three files, each having slightly different suffixes before the .txt extension:

/usr/bin/mousepad -- "$(ls -t /home/$USER/Documents/SomeFolder/SomeFileVersion*.txt | head -n 1)" "$(ls -t /home/$USER/Downloads/SomeFolder/SomeOtherFileVersion*.txt | head -n 1)" "$(ls -t /home/$USER/Downloads//SomeFolder/SomeOtherFileVersion*.txt | head -n 1)" &

calligra* packages have been now been purged accordingly for now, to be on the safe side, although it is a great suite.  I do not see a way to update the thread title to include this suite.

#24 Re: ARM Builds » [SOLVED] Clock does not update. Daedalus, arm64 Rasp Pi. NTP server not running » 2023-09-14 19:43:55

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.

#25 Re: Other Issues » no update » 2023-09-14 19:39:57

English/Inglés:  Daedalus occasionally is still giving me wrong system time despite some efforts that I thought were final - see my earlier report
You can update your system clock by doing:
sudo service ntpsec restart
(or if you have doas, doas service ntpsec restart )
Then reenter your password when updating your system, as your sudo time limit for your password will have expired with the clock update.

Español/Spanish:  Daedalus occasionalmente aún me da una hora incorrecta, a pesar de mis esfuerzos en corregirlos.  Véase mi reportaje anterior
Puedes actualizar tu reloj así:
sudo service ntpsec restart
(o si tienes doas, doas service ntpsec restart )
Luego, mete tu palabra de pase de nuevo para actualizar tu sistema, puesto que el tiempo limite para tu palabra de pase habrá expirado con la hora actualizada.

Board footer

Forum Software