Problem:
There seems to be a mismatch between the devuan supplied Python3 and the HPLIP supplied python3 script. Hence the hplip-3.22.10-plugin.run will fail to install the plugin for the scanner.

Solution:
1. Make a backup of the files we change!

2. Change temporarily the content of "/etc/os-release" to:

PRETTY_NAME="Debian GNU/Linux bookworm/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Also change temporarily in the file "/usr/share/hplip/base/password.py" the following:

On line 119 and 322
distro_name = get_distro_std_name(os_name)
to
distro_name = get_distro_name()

3. The command $ ./hplip-3.22.10-plugin.run will now install the plugin.

4. After the plugin has been installed reverse the changes.

Distro: Devuan-Testing (chimaera) soon to be the next stable release.

Ever tried to install this plugin on a pure sysv-init-system and you never got it to work as advertised? Maybe this HOWTO might come in handy.

You want to see a proof, here it is (a snippet from /var/log/syslog):

• Oct  9 12:35:12 mars dbus-daemon[6220]: [session uid=1002 pid=6218] Activating service name='com.canonical.AppMenu.Registrar' requested by ':1.15' (uid=1002 pid=6338 comm="/usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-2.0 ")
  Oct  9 12:35:12 mars dbus-daemon[6220]: [session uid=1002 pid=6218] Successfully activated service 'com.canonical.AppMenu.Registrar'

and

• ~$ env | grep GTK_M
  GTK_MODULES=appmenu-gtk-module

The solution, bases on the motto "if you can't make it - fake it" and a still reasonably sane Lightdm and Xfce4-Core, is actually fairly simple. A purist might bark at it - but it does work flawlessly and should be "futureproof" for the whole of Chimaera's live-cicle.

On my box it does now take about 2 seconds longer to get from the login to the desktop. I am not too thrilled about that. Any feedback is welcome especially a better but tested solution. Please share. I would like to see this HOWTO to be the standard goto for devuan users experiencing problems with this plugin.

OK, here we go....in 4 easy steps.

Step 1

Packages required:

• [INSTALL, DEPENDENCIES] appmenu-gtk-module-common:amd64 0.7.6-2
  [INSTALL, DEPENDENCIES] appmenu-gtk2-module:amd64 0.7.6-2
  [INSTALL, DEPENDENCIES] appmenu-gtk3-module:amd64 0.7.6-2
  [INSTALL, DEPENDENCIES] appmenu-registrar:amd64 0.7.6-2
  [INSTALL, DEPENDENCIES] libappmenu-gtk2-parser0:amd64 0.7.6-2
  [INSTALL, DEPENDENCIES] libappmenu-gtk3-parser0:amd64 0.7.6-2
  [INSTALL, DEPENDENCIES] libdbusmenu-gtk4:amd64 18.10.20180917~bzr492+repack1-2
  [INSTALL, DEPENDENCIES] vala-panel-appmenu-common:amd64 0.7.6+dfsg1-3
  [INSTALL] xfce4-appmenu-plugin:amd64 0.7.6+dfsg1-3

and add the plugin to the panel.

Step 2

As user:

$ cp /etc/xdg/xfce4/xinitrc ~/.config/xfce4/
$ nano ~/.config/xfce4/xinitrc

and paste the following snippet into the file....

...just before the following line (near the end of the file)

and save and exit nano

Step 3

As root:

# nano /etc/lightdm/lightdm.conf

Under the section

change

to

save and exit nano

then

# mkdir /etc/lightdm/scripts
# nano /etc/lightdm/scripts/activate-appmenu-bus

and paste the following into the file:

save and exit nano and make the file executable (-rwxr-xr-x)!

Step 4 (Final)

A '/etc/init.d/lightdm restart' might be good enough but I recommend a shutdown because 'dbus' is involved.

Enjoy your global-menu.

-------------------

Side-Note:
After you got it working you will see in ~/.xsession-errors
or after a 'xfce4-panel -r' in the terminal the following:

Ignore it, it is not relevant for the xfce4-appmenu-plugin to work properly in the Devuan-Environment. I think it is an Ubuntu/Kubuntu thingy because the appmenu-registrar gets registered under: 'com.canonical.AppMenu.Registrar' although it seems to expect to be registered under 'org.valapanel.AppMenu,Registrar' when invoked directly as a USER. Just another mystery (at least for me) in the changed linux-landscape of obfuscations.

The DE is:

lightdm with libpam-elogind, a partial xfce4-desktop  and the exim4-light-daemon

Warning:

If you are in a hurry - don't do it! Read any output from 'aptitude' very carefully when it presents you with alternatives to work around dependency problems.

IMPORTANT: You have to be familiar with a testing-branch but a degree in rocket science is not required.

My Motivation for doing it:

Using Debian-testing for *many* years I suddenly had that "bee in the bonnet" to move a Devuan-stable to the testing branch. My present Debian-testing (with sysv-init) is actually my main OS but I started feeling a bit uncomfortable since consolkit-1 got dropped by the Debian-Team and with no elogind and friends in sight to replace it.

Preamble:

This is not a HowTo Document rather a collection of comments and tips to get the job done in one way or another (makeshift aproach). Moving a DE from stable (ascii) to testing (beowulf) is presently a *fairly* clumsy business. The emphasis is on *moving* a DE.

Now lets get this out of our way. Right now, merged/beowulf and merged/ceres is not functioning the same way as the Debian buster and sid branches. It seems that Devuan specific packages are not trickling down fast enough from experimental to unstable to testing. I can well imagine that the Devuan-Project just simply does not have the resources and manpower to do it any faster.

For that very reason one can't just do an apt-get dist-upgrade! For a DE you need devuan-branded 'policykit-1' and 'consolekit and friends' or 'libpam-elogind and friends'. These packages are presently simply *not* available in beowulf or ceres.

Now let's start.

The tools I used are aptitude (ncurses bases package manager which in IMHO is a bit cleverer in working out dependeny-problems as apt-get) and orphaner (an alternative for finding unused packages) from the deborphan package.

I reduced the DE (in my case, xfce4) but left lightdm and the mailserver (apt-listchanges) installed.

I recommend to make a backup of the root-partition.

Changed in the /etc/apt/sources.list the word 'ascii' to 'beowulf' and created a file /etc/apt/preferences.d/avoid_some_beo with the following content:

  Package: policykit-1
  Pin: release a=beowulf
  Pin-Priority: -1

  Package: libpolkit-agent-1-0
  Pin: release a=beowulf
  Pin-Priority: -1 

  Package: libpolkit-backend-1-0
  Pin: release a=beowulf
  Pin-Priority: -1

  Package: libpolkit-gobject-1-0
  Pin: release a=beowulf
  Pin-Priority: -1

and then I issued the command: apt-get update

Remember "apt-get dist-upgrade" does give you a hosed system. If you don't believe me try it with the -s switch and then you will notice that the new debian-branded policykit-1 will be installed which in turn uninstalls the devuan-branded vital stuff (ie libpolkit-backend-elogind-1-0).

Now I started from the terminal (as root) the application aptitude and then I pressed: U for Upgrade.

aptitude then told me that it has got a dependency problem. In response to it, press: e and cycle through the 2 or 3 different solutions to the dependency-problem.

Accept the one where policykit-1 will not be upgraded and libpolkit-backend-elogind-1-0 and friends will be left in place (not wiped out).

Press: g and inspect the displayed list for correctness and confirm the correctness by pressing g again otherwise cancel pending action.

After completion of the upgrade under the heading "Obsolete and Locally Created Packages", I did find libpam-elogind and friends. This confirms that apparently all went well, in other words the vital ascii based devuan-branded packages did make the migration.

Then I closed aptitude and used orphaner to tell me which packages orphaner thinks are obsolete and I recorded the name of these packages on a piece of paper.

After closing orphaner and starting aptitude again I then carefully removed the *truly* obsolete packages and landed with the following list in aptitude:

elogind, eudev, libpam-elogind, clearlook-phenix-darkpurpy-themes, gnome-icon-theme-extras,
linux-image-4.9.0.7-amd64, libelogind0, libeudev1, libpolkit-backend-elogind-1-0,
libpolkit-gobject-elogind-1-0, libuper-glib1 and darkpurpy-icon-theme.

Then I closed aptitude again.

In order to reflect the fact that this is a Devuan and not a Debian-Distro make changes to the following files in the /etc directory: devuan_verson, issue, issue.net and os-release. 

I issued the command: update-grub

and then rebooted the OS - and all worked!!! Mind you, the command su behaves differently (had to read the mail which apt-listchange generated for me). BTW, gksu is gone because Debian ditched it but pkexec works

I reinstalled the print-server (no problem during the install and is fully functional) and then pulseaudio. There is however a slight initial problem with pulseaudio! I had to edit the file /etc/pulse/client.conf.d/00-disable-autospawn.conf as per instruction inside that file and pulseaudio works now perfectly.

Note: As I use eth0, I can't tell you if the wifi-packages will function properly. Personally, ignoring network-manager, I don't see a reason why they should not work.

My final ramblings:

My beowulf-system seems to run fine. I know, its early days but I must admit I expected it to be worse. My "Beowulf Desktop Environment" has 11 Devuan packages from ascii, 6 from beowulf and the rest is *pure* Debian buster.

Will I keep this installation? Most probably I will but let's wait and see if the beowulf-branch develops towards a more functional state of affairs, in other words in a less makeshift migration setup. I personally do not like the idea to have *vital* packages borrowed from the ascii-branch but with a bit of pinning etc it can be controlled. BTW, I re-activated the ascii-branch but gave it a very low preference except for the presently vital ascii-packages.

My  thanks to the Devuan devs, testers and bug-reporters for providing a good OS without the systemd octopus. I tip my hat!