This 'setting up a user called pi' would be done on a Devuan RPi installation.
ie: which does not come with a predermined sudo enabled userid set up by default.

The only object in setting up a user pi instead of my usual userid groucho is to see if the roasting software will work, as it seems to expect the Raspbian default.
ie: a predetermined userid pi with the corresponding /pi sub-dir in /home.
Which is obviously not present in Devuan (which would seem to be the proper way to do things).

When the software scripts look for the expected /home/pi/.config files and does not find them, everything goes south.
At least, that is what I think is happening.

Thanks for your input.

Cheers,

A.

If it doesn't work delete it before trying to set up a user called pi. Or "interesting" things might happen.

Chris

I've decided to give up, at least for the time being.
But not on Devuan, it will always be my Linux distribution.

But I really need to get the roasting software running and see if it is worthwhile to use the RPi for that.

The people at raspberry.org have no support for Devuan and the author of the software I need to run on the RPi has no support for Devuan either.
He built and tested it for Raspbian only.
But to the exteme.

eg:

I burned the latest (minimal Buster Lite) Raspbian image on the 2.0Gb SDCard and got the HDD working.
After a rather long update/upgrade cycle I installed the basics (xserver-xorg, slim, openbox, tint2, lxterminal) and then the roasting software.
Worked as expected.

And what did I find?

Confusingly enough (for me), the Raspbian image comes with a default user, already set up with a login password, sudo membership and all.
But no root access which you have to set up yourself.

By sudoing your way along ...  8^7'

And what name would this default user have?
You guessed it: none other than pi.

Which is why (?) the script could not find /home/pi in my Devuan installation.

There is a significant (?) difference between the installations.

While uname -a with the Devuan image gave this output ...

groucho@rpidevuan:~$ uname -a
Linux rpidevuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
groucho@rpidevuan:~$ 

... the Raspbian image gave this one:

pi@grouchopi:~ $ uname -a
Linux grouchopi 4.19.97-v7+ #1294 SMP Thu Jan 30 13:15:58 GMT 2020 armv7l GNU/Linux
pi@grouchopi:~ $ 

ie: v8+ and aarch64 vis-a-vis v7+ and armv7.
Would this have a bearing in all the issues I have found?

I don't have the necessary know-how to change whatever scripts need to be changed in order for the software to run on Devuan.
So for the time being I'll see how it does on Raspbian.

When I have some more time on my hands, I'll try with a Devuan image again.
Maybe setting up a user named pi will make a difference?

In the meanwhile, any further ideas are welcome.
I've run out.

Cheers,

A.

ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory

Try

# apt install libstdc++6:armhf

Right.

I see ...

Must be why, after following ralph.ronnquist's suggestion to install zlib1g:armhf, I now have a whole new can of worms on my hands.
Evidently he was right, I did need to install zlib1g:armhf.

Now, when I run the application as root from /usr/share/artisan I don't get the output I got before installing it ...
ie:

root@rpidevuan:/# /usr/share/artisan/artisan
/usr/share/artisan/artisan: error while loading shared libraries: 
libz.so.1: cannot open shared object file: No such file or directory
root@rpidevuan:/# 

... where the problem was just libz.so.1 not being found.

The output is more populated and there is no mention of libz.so.1:

t@rpidevuan:/home/groucho# /usr/share/artisan/artisan
Traceback (most recent call last):
  File "artisan.py", line 68, in <module>
  File "/home/pi/.local/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py", line 631, in exec_module
  File "artisanlib/main.py", line 86, in <module>
  File "/home/pi/.local/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py", line 714, in load_module
ImportError: libstdc++.so.6: cannot open shared object file: No such file or directory
[1624] Failed to execute script artisan
root@rpidevuan:/home/groucho# 

When I saw python3.5 I remembered having seen that the software needed that version of python which came installed in the Raspbian image.

Sure enough, the version in Devuan ascii was 2.7, so I installed 3.5.

But to no avail, the output was exactly the same.

There is no /pi sub-directory in my /home directory.
Nor are any of the other two files listed ie: artisan.py, main.py in the output present in my system.

libstdc++.so.6 is present but not in the LD_LIBRARY_PATH=:

root@rpidevuan:/home/groucho# locate libstdc++.so.6
/usr/lib/aarch64-linux-gnu/libstdc++.so.6
/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.22
/usr/share/gdb/auto-load/usr/lib/aarch64-linux-gnu/libstdc++.so.6.0.22-gdb.py
root@rpidevuan:/home/groucho# 

It seems that the developer really meant it: the software was build and tested for Raspian.

On one hand, python3.5 is not listed as a dependency (because Raspbian has it built in) and on the other, Raspbian seems to have some rather unique file locations.
eg: /home/pi/.local/lib/python3.5/site-packages/PyInstaller/loader/pyimod03_importers.py

All that python stuff in the /home directory?
I've been through quite a few distributions, can't recall having seen that before.

So ...
Short of just giving up and using Raspbian on my RPi to run the roasting software, any ideas towards making this work?

Thanks for your input.

A.

It is not too clear to me how the path should read and where the library should be.
ie: where does the LD_LIBRARY_PATH= stanza end?

Just before LIBOVERLAY_SCROLLBAR=0, the space is the delimiter.

Not really, LD_LIBRARY_PATH just makes the application search the custom locations first.

A compression library from what I have read.
For some reason adding the armfh architecture did not pull it in.
Shouldn't it have been pulled in?

It installed without issue.
What use will it have?

Is there anything else armfh related that should have been pulled in?

Q1:
Would it be correct to assume that the developer sends everything to /dev/null because his Artisan software for RPi is build and tested for
Raspian Stretch, which is Debian and relies on systemd for taking care of the log?

If so, I'd need to be able to generate one.

Q2:
Would this suffice?

root@rpidevuan:/home/groucho# touch /var/log/artisan.log
root@rpidevuan:/home/groucho#

then ...

--- snip ---
/usr/share/artisan/artisan "$@" 2>/var/log/artisan.log

instead of:

--- snip ---
/usr/share/artisan/artisan "$@" 2>/dev/null

Thanks  for your input.

Cheers,

A.

It could very well be, really can't recall.

I've made some advances with some indications from the developer.
Seems that there is no configured log file, everything goes to /dev/null.

But if I run the application as root from /usr/share/artisan I get some output:

root@rpidevuan:/# /usr/share/artisan/artisan
/usr/share/artisan/artisan: error while loading shared libraries: 
libz.so.1: cannot open shared object file: No such file or directory
root@rpidevuan:/# 

The library libz.so.1 that the executable cannot find *is* present in /lib/aarch64-linux-gnu/:

root@rpidevuan:/# locate libz.so.1
/lib/aarch64-linux-gnu/libz.so.1
/lib/aarch64-linux-gnu/libz.so.1.2.8
root@rpidevuan:/# 

The problem is that the start-up script is telling the application to look for it elsewhere:

root@rpidevuan:/usr/bin# cat artisan
#!/bin/sh

if [ -f /etc/os-release ]; then
    grep Raspbian /etc/os-release >/dev/null
    # Workaround for issue #187
    if [ $? -eq 0 ]; then
 unset XDG_CURRENT_DESKTOP
    fi
fi
exec /usr/bin/env QT_PLUGIN_PATH=/usr/share/artisan/PyQt5/Qt/plugins
LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gtk-3.0/modules:/usr/share/a
rtisan:$LD_LIBRARY_PATH LIBOVERLAY_SCROLLBAR=0
GTK2_RC_FILES="$HOME/.gtkrc-2.0" /usr/share/artisan/artisan "$@" 2>/dev/null
root@rpidevuan:/usr/bin# 

There is no /usr/lib/x86_64-linux-gnu in my system.
But there is a /usr/lib/aarch64-linux-gnu/gtk-3.0.

It is not too clear to me how the path should read and where the library should be.
ie: where does the LD_LIBRARY_PATH= stanza end?

Any suggestions?

Thanks in advance,

A.

Why did I have to use apt install -f to get this right?

That is the same as apt --fix-broken install and it just pulls in any missing dependencies for you. My suggested apt install ./ command should have also done that but I'm guessing that you didn't update your sources immediately after adding the armhf architecture but you have done so subsequently and so APT can now find the foreign architecture packages and install the necessary dependencies.

Not sure about your other problem, I would usually investigate that sort of thing with the systemd journal (which collates all logging to a single source and provides a powerful filtering mechanism) but that's not possible here.

Well ...
Later on came ...
... and went.

And much to my chagrin, the roasting software wouldn't start.   8 ^⁷
Nothing.
No output.

Unless I have missed something, there are no missing dependencies.

To make things worse, I cannot find anything within the logs in RPi's installation.

How can I debug this if I cannot get any data from the logs?

Thanks in advance,

A.

I found a post in an Italian site with a clue to this problem, which was related to some other software.
It said that the fix was apt install -f.

Having nothing much to lose ...

root@rpidevuan:/home/groucho# apt-get -f install
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following additional packages will be installed:
  gcc-6-base:armhf libc6:armhf libgcc1:armhf
Suggested packages:
  glibc-doc:armhf locales:armhf
The following NEW packages will be installed:
  gcc-6-base:armhf libc6:armhf libgcc1:armhf
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
1 not fully installed or removed.
Need to get 2559 kB of archives.
After this operation, 8950 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://pkgmaster.devuan.org/merged ascii/main armhf gcc-6-base armhf 6.3.0-18+deb9u1 [180 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii/main armhf libgcc1 armhf 1:6.3.0-18+deb9u1 [38.5 kB]
Get:3 http://pkgmaster.devuan.org/merged ascii/main armhf libc6 armhf 2.24-11+deb9u4 [2341 kB]
Fetched 2559 kB in 4s (544 kB/s)       
Preconfiguring packages ...
Selecting previously unselected package gcc-6-base:armhf.
(Reading database ... 38598 files and directories currently installed.)
Preparing to unpack .../gcc-6-base_6.3.0-18+deb9u1_armhf.deb ...
Unpacking gcc-6-base:armhf (6.3.0-18+deb9u1) ...
Selecting previously unselected package libgcc1:armhf.
Preparing to unpack .../libgcc1_1%3a6.3.0-18+deb9u1_armhf.deb ...
Unpacking libgcc1:armhf (1:6.3.0-18+deb9u1) ...
Selecting previously unselected package libc6:armhf.
Preparing to unpack .../libc6_2.24-11+deb9u4_armhf.deb ...
Unpacking libc6:armhf (2.24-11+deb9u4) ...
Setting up gcc-6-base:armhf (6.3.0-18+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
Setting up libgcc1:armhf (1:6.3.0-18+deb9u1) ...
Setting up libc6:armhf (2.24-11+deb9u4) ...
Setting up artisan:armhf (2.1.2) ...
Processing triggers for libc-bin (2.24-11+deb9u4) ...
root@rpidevuan:/home/groucho#

Interesting ...
So then I went about seeing what would happen with lxappearance:

root@rpidevuan:/home/groucho# apt-get install lxappearance
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
  gtk2-engines lxde-settings-daemon
The following NEW packages will be installed:
  gtk2-engines lxappearance lxde-settings-daemon
0 upgraded, 3 newly installed, 0 to remove and 1 not upgraded.
Need to get 438 kB of archives.
After this operation, 1900 kB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://pkgmaster.devuan.org/merged ascii/main arm64 gtk2-engines arm64 1:2.20.2-3 [342 kB]
Get:2 http://pkgmaster.devuan.org/merged ascii/main arm64 lxappearance arm64 0.6.3-1 [80.4 kB]
Get:3 http://pkgmaster.devuan.org/merged ascii/main arm64 lxde-settings-daemon arm64 0.5.3-2 [15.7 kB]
Fetched 438 kB in 2s (184 kB/s)            
Selecting previously unselected package gtk2-engines:arm64.
(Reading database ... 38908 files and directories currently installed.)
Preparing to unpack .../gtk2-engines_1%3a2.20.2-3_arm64.deb ...
Unpacking gtk2-engines:arm64 (1:2.20.2-3) ...
Selecting previously unselected package lxappearance.
Preparing to unpack .../lxappearance_0.6.3-1_arm64.deb ...
Unpacking lxappearance (0.6.3-1) ...
Selecting previously unselected package lxde-settings-daemon.
Preparing to unpack .../lxde-settings-daemon_0.5.3-2_arm64.deb ...
Unpacking lxde-settings-daemon (0.5.3-2) ...
Processing triggers for mime-support (3.60) ...
Setting up gtk2-engines:arm64 (1:2.20.2-3) ...
Setting up lxde-settings-daemon (0.5.3-2) ...
Setting up lxappearance (0.6.3-1) ...
root@rpidevuan:/home/groucho# 

Also interesting ...
Now the only thing left to see was what would happen with the roasting software installation, which I understood as installed but not configured:

root@rpidevuan:/home/groucho/Downloads# apt install ./artisan-linux-2.1.2_raspbian-stretch.deb
Reading package lists... Done
Building dependency tree       
Reading state information... Done
--- empty line added ---
Note, selecting 'artisan:armhf' instead of './artisan-linux-2.1.2_raspbian-stretch.deb'        <------------------- what is this about?
artisan:armhf is already the newest version (2.1.2).
--- empty line added ---
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
root@rpidevuan:/home/groucho/Downloads#

It seemed were more upgrades to do:

root@rpidevuan:/home/groucho/Downloads# apt-get update
Hit:1 http://pkgmaster.devuan.org/merged ascii InRelease
Hit:2 http://pkgmaster.devuan.org/merged ascii-updates InRelease
Hit:3 http://pkgmaster.devuan.org/merged ascii-security InRelease
Reading package lists... Done
root@rpidevuan:/home/groucho/Downloads#

root@rpidevuan:/home/groucho/Downloads# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  colord-data
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1340 kB of archives.
After this operation, 33.8 kB disk space will be freed.
Do you want to continue? [Y/n] 
Get:1 http://pkgmaster.devuan.org/merged ascii/main armhf colord-data all 1.3.3-1+devuan1 [1340 kB]
Fetched 1340 kB in 2s (521 kB/s)      
(Reading database ... 39018 files and directories currently installed.)
Preparing to unpack .../colord-data_1.3.3-1+devuan1_all.deb ...
Unpacking colord-data (1.3.3-1+devuan1) over (1.2.1-1+devuan1) ...
Setting up colord-data (1.3.3-1+devuan1) ...
root@rpidevuan:/home/groucho/Downloads# 

Done ...
Running (yes, again) apt-get check, apt-get update and apt-get upgrade showed everything was (should be) in place.

I now have to check and see if the roasting software works.
I'll post back on that later on.

In the meanwhile ...
Could someone with the neccesary know-how explain what happened?

Why did I have to use apt install -f to get this right?

Thanks in advance.

Cheers,

A.

While continuing to set up my RPi, I came across the same problem, albeit not linked to the roasting sofware but to a Devuan package:

root@rpidevuan:/home/groucho# apt-get install lxappearance
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho# 

Rather puzzled by this, I checked on the dependencies for lxappearance:

root@rpidevuan:/home/groucho# apt-cache depends lxappearance
lxappearance
  Depends: libatk1.0-0
  Depends: libc6                               <------------------- here it is
  Depends: libcairo2
  Depends: libdbus-1-3
  Depends: libdbus-glib-1-2
  Depends: libfontconfig1
  Depends: libfreetype6
  Depends: libgdk-pixbuf2.0-0
  Depends: libglib2.0-0
  Depends: libgtk2.0-0
  Depends: libpango-1.0-0
  Depends: libpangocairo-1.0-0
  Depends: libpangoft2-1.0-0
  Depends: libx11-6
  Recommends: gtk2-engines
  Recommends: lxde-settings-daemon
    lxsession
root@rpidevuan:/home/groucho# 

The package libc6 shows up again as a dependency for lxappearance.
But what I don't understand is artisan:armhf being mentioned again but in this context.

Seeing that the problem is also present when installing a regular Devuan package, I think that its being related to the roasting software can be ruled out.

Could it then be something related to the Devuan image I used?

If so, how to fix it?

Thanks in advance,

A.

I posted this issue on the Artisan-user mailing list and got this answer:

Independently of the fact that the develper's answer really leaves much to be desired, a couple of questions come to mind:

1.
As far as I know (others may know better), Raspbian Stretch is based on Debian Stretch which in turn is nothing but Devuan ascii without the hindrances that systemd imposes on it.

Is this so or am I missing something here?

2.
If I am not missing something and my reasoning correct, then the dependency problem I am having is not at all related to Devuan (as expected).
ie: there should be no difference between running the roasting software on Raspbian Stretch or on Devuan ascii, there does not seem to be any systemd related problem.

I successfully run an older version of the roasting software on Devuan ascii 32bit/netbook, so what gives?

3.
Could it be that the use of an image on my RPi 3B+ makes it non-upgradeable?
ie: certain libraries cannot be installed/upgraded, hence the dependency issue.

The image of Ritchie Havens opening at Woodstock in 1969 came to mind this morning:

"Sometimes I feel like a motherless child
A long way from my home"

Any idea as to how I can solve this, short of having to use Raspbian on my RPi3B+?

Thanks in advance,

A.

I'm afraid that won't work.

root@rpidevuan:/home/groucho# apt install libc6:armhf
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 libc6:armhf : Depends: libgcc1:armhf but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho#

No luck either ...

root@rpidevuan:/home/groucho/Downloads# apt install ./artisan-linux-2.1.2_raspbian-stretch.deb
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/home/groucho/Downloads# 

As you can see in both instances the problem of dependecy is the same:

--- snip ---
The following packages have unmet dependencies:
 libc6:armhf : Depends: libgcc1:armhf but it is not going to be installed
--- snip ---

--- snip ---
The following packages have unmet dependencies:
 artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not installed
--- snip ---

Not one to give up, I insisted with the new arrival at the apt rebellion ...

root@rpidevuan:/# apt install libgcc1:armhf
Reading package lists... Done
Building dependency tree       
Reading state information... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 artisan:armhf : Depends: libc6:armhf (>= 2.17) but it is not going to be installed
 libgcc1:armhf : Depends: gcc-6-base:armhf (= 6.3.0-18+deb9u1) but it is not going to be installed
                 Depends: libc6:armhf (>= 2.4) but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
root@rpidevuan:/# 

... but it did not work.

Thanks a lot for your input.

Cheers,

A.