Hello:

I see ...

Of course.

Now the start-up script read like this:

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/share/artisan:$LD_LIBRARY_PATH LIBOVERLAY_SCROLLBAR=0 GTK2_RC_FILES="$HOME/.gtkrc-2.0" /usr/share/artisan/artisan
root@rpidevuan:/usr/bin# 

As it is not in your stanza, I left out this part:

"$@" 2>/dev/null

When I run the script directly via # /usr/share/artisan/artisan the application starts but I still get the same warning.

I've found posts on the web referring to this in RPis which would seem to indicate that it is something from as back as 2017, related to OpenGL and actually keeps some Qt based applications from running. Fortunately, it is not my case.

See here:

https://www.reddit.com/r/voidlinux/comm … lications/
My system does not have a /usr/share/X11/xorg.conf.d/99-fbturbo.conf to rename, so it is a dead end.

https://raspberrypi.stackexchange.com/q … -to-libegl
This involves more complicated stuff like symlinking libraries.

Tonight there was yet another :armhf issue regarding USB communication between the temperature logger and the software but fortunately I was able to solve it by installing usbutils:armhf which removed usbutils and installed a dependency.

I wonder how many more of these libraries I should install?

Thanks for your input.
Much appreciated.

Cheers,

A.

Hello:

I thought for a while about doing exactly that.
But what I originally saw as an ARM64 dependency issue no longer seemed to be that.

To me, it now looked more like a problem with an application's start-up script.

But you're the one with the know how, I'm just here (stubbornly) poking in the dark.
If you think all this should go as a continuation of the old thread, please let me know and I'll ask fsmithred to move it over. 

No.
How could I have possibly known?
I was chasing the missing xcb Qt plugin, there's a whole lot of that and qt.conf on the web.

Now I do.   8^D

root@rpidevuan:/home/pi# apt-get install libqt5gui5:armhf
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  libglew2.0
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  libbsd0:armhf libdatrie1:armhf libdbus-1-3:armhf libdouble-conversion1:armhf libdrm-amdgpu1:armhf
  libdrm-freedreno1:armhf libdrm-nouveau2:armhf libdrm-radeon1:armhf libedit2:armhf libegl1-mesa:armhf
  libelf1:armhf libeudev1:armhf libevdev2:armhf libexpat1:armhf libfontconfig1:armhf libfreetype6:armhf
  libgbm1:armhf libgcrypt20:armhf libgl1-mesa-dri:armhf libgl1-mesa-glx:armhf libglapi-mesa:armhf
  libgles2-mesa:armhf libglew2.0:armhf libglu1-mesa:armhf libgpg-error0:armhf libgpm2:armhf libgraphite2-3:armhf
  libgudev-1.0-0:armhf libharfbuzz0b:armhf libice6:armhf libicu57:armhf libinput10:armhf libjpeg62-turbo:armhf
  libllvm3.9:armhf libmtdev1:armhf libncurses5:armhf libpcre16-3:armhf libpng16-16:armhf libproxy1v5:armhf
  libqt5core5a:armhf libqt5dbus5:armhf libqt5network5:armhf libqt5svg5:armhf libqt5widgets5:armhf
  libsensors4:armhf libsm6:armhf libssl1.0.2:armhf libthai0:armhf libtinfo5:armhf libtxc-dxtn-s2tc:armhf
  libwacom2:armhf libwayland-client0:armhf libwayland-server0:armhf libx11-6:armhf libx11-xcb1:armhf
  libxau6:armhf libxcb-dri2-0:armhf libxcb-dri3-0:armhf libxcb-glx0:armhf libxcb-icccm4:armhf libxcb-image0:armhf
  libxcb-keysyms1:armhf libxcb-present0:armhf libxcb-randr0:armhf libxcb-render-util0:armhf libxcb-render0:armhf
  libxcb-shape0:armhf libxcb-shm0:armhf libxcb-sync1:armhf libxcb-util0:armhf libxcb-xfixes0:armhf
  libxcb-xinerama0:armhf libxcb-xkb1:armhf libxcb1:armhf libxdamage1:armhf libxdmcp6:armhf libxext6:armhf
  libxfixes3:armhf libxi6:armhf libxkbcommon-x11-0:armhf libxkbcommon0:armhf libxshmfence1:armhf
  libxxf86vm1:armhf mesa-utils:armhf
Suggested packages:
  rng-tools:armhf glew-utils:armhf gpm:armhf qt5-image-formats-plugins:armhf qtwayland5:armhf lm-sensors:armhf
Recommended packages:
  qttranslations5-l10n:armhf qt5-gtk-platformtheme:armhf
The following packages will be REMOVED:
  mesa-utils
The following NEW packages will be installed:
  libbsd0:armhf libdatrie1:armhf libdbus-1-3:armhf libdouble-conversion1:armhf libdrm-amdgpu1:armhf
  libdrm-freedreno1:armhf libdrm-nouveau2:armhf libdrm-radeon1:armhf libedit2:armhf libegl1-mesa:armhf
  libelf1:armhf libeudev1:armhf libevdev2:armhf libexpat1:armhf libfontconfig1:armhf libfreetype6:armhf
  libgbm1:armhf libgcrypt20:armhf libgl1-mesa-dri:armhf libgl1-mesa-glx:armhf libglapi-mesa:armhf
  libgles2-mesa:armhf libglew2.0:armhf libglu1-mesa:armhf libgpg-error0:armhf libgpm2:armhf libgraphite2-3:armhf
  libgudev-1.0-0:armhf libharfbuzz0b:armhf libice6:armhf libicu57:armhf libinput10:armhf libjpeg62-turbo:armhf
  libllvm3.9:armhf libmtdev1:armhf libncurses5:armhf libpcre16-3:armhf libpng16-16:armhf libproxy1v5:armhf
  libqt5core5a:armhf libqt5dbus5:armhf libqt5gui5:armhf libqt5network5:armhf libqt5svg5:armhf
  libqt5widgets5:armhf libsensors4:armhf libsm6:armhf libssl1.0.2:armhf libthai0:armhf libtinfo5:armhf
  libtxc-dxtn-s2tc:armhf libwacom2:armhf libwayland-client0:armhf libwayland-server0:armhf libx11-6:armhf
  libx11-xcb1:armhf libxau6:armhf libxcb-dri2-0:armhf libxcb-dri3-0:armhf libxcb-glx0:armhf libxcb-icccm4:armhf
  libxcb-image0:armhf libxcb-keysyms1:armhf libxcb-present0:armhf libxcb-randr0:armhf libxcb-render-util0:armhf
  libxcb-render0:armhf libxcb-shape0:armhf libxcb-shm0:armhf libxcb-sync1:armhf libxcb-util0:armhf
  libxcb-xfixes0:armhf libxcb-xinerama0:armhf libxcb-xkb1:armhf libxcb1:armhf libxdamage1:armhf libxdmcp6:armhf
  libxext6:armhf libxfixes3:armhf libxi6:armhf libxkbcommon-x11-0:armhf libxkbcommon0:armhf libxshmfence1:armhf
  libxxf86vm1:armhf mesa-utils:armhf
0 upgraded, 85 newly installed, 1 to remove and 0 not upgraded.
Need to get 35.9 MB of archives.
After this operation, 180 MB of additional disk space will be used.
pi@rpidevuan:~$ 

And then ...
... after a whole 180mb of libxwhatever:armhf files, the "#$%& coffee roasting application finally went > live < .  8^D !!!

There's a warning when I start it  directly via # /usr/share/artisan/artisan:

root@rpidevuan:/home/pi# /usr/share/artisan/artisan
libEGL warning: DRI2: failed to authenticate
root@rpidevuan:/home/pi#

I'll have to run some tests to see if it all works, but now things are looking good.

This software now works only because I got help from you and fsmithred and was led to install a huge list of :armhf files missing from Devuan ascii ARM64, even after adding the armhf architecture and making sure there were no unmet dependencies.

Makes me wonder why all these libraries were not pulled in at some time or another, some with the installation of the software and some with the armhf architecture.
It would have saved us all (especially me) a lot of time and hair pulling.  8^7

There are probably quite a few applications that, having been written for armhf RPis, could also run on ARM64 RPis if it were not for this mess I waded into. 
Maybe it would be a good idea to make a sticky with the basics of what happened and why?

I could do that, you guys could previously check it's accuracy.

I'll check to see if the software runs as expected and report back.
In the meanwhile, thank you very much for your help with this matter.

Cheers,

A.

Hello:

An update to confirm this.

Long story short ...
Had to install Raspbian in my RPi3b+ and then do all I did before once again.  8^º
No matter, practise = knowledge.

In any case ...
I set up a new /etc/fstab with a /swap partition on the HDD, without turning off the existing swapfile.

When I did swapon -s, I get this:

pi@grouchopi:/$ swapon -s
Filename				Type		Size	Used	Priority
/dev/sda7                              	partition	2675708	0	-2
/var/swap                              	file    	102396	0	-3
pi@grouchopi:/$ free
              total        used        free      shared  buff/cache   available
Mem:         948296       66928      753336       12356      128032      817596
Swap:       2778104           0     2778104
pi@grouchopi:/$ 

I think that the swapfile in the SDCard has it's priority set somewhere at 2 and as a consequence, the /swap parition gets set at 3.

Now I will turn off the swapfile so there's no swapping on the SDCard and change the priority of the /swap partiton to 1 and see how it goes.
The RPi has just 1Gb. RAM.

Cheers,

A.

Hello:

Sure, be glad to.

But my guess is that you need this run on a Devuan ascii RPi3b+.

I gave up (for the time being) on Devuan ascii on the RPi.
See the thread and the post (#15) with the 'why' here.

Basically, the roasting software I need to use is 'tailored' to how Raspbian is packaged and not supported in Devuan, only Raspbian.

On top of that, I now have the problem of Raspbian not having a root account ...   8^ð !

To be root y have to sudo su.

pi@grouchopi:~ $ sudo su
root@grouchopi:/home/pi# 

No password, save having logged in.

And If I generate a root account (as sudo!) it seems to work but there are issues with /tmp not being there.
eg: if I run mc as root.

I'll ask at the RPi forum first and then here.
Maybe someone will help me sanitize this Raspbian thing enough to make it a bit more comfortable to use.

Cheers,

A.

Hello:

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.

Hello:

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.

Hello:

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.

Hello:

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.

Hello:

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.

Hello:

Indeed ...

I'll take your word for it.  =-)
I have no idea how all that works.

All I know is that if I need a module, that is one way to load it. 

The thing is that vcgencmd is specific to Broadcom chips but we don't have a *.deb for it.
And all the GPIO stuff that the RPi uses for things much more complex than the one I am implementing does not seem (at least I have not found it) to be anywhere but in Raspbian.

It would seem that ARM64, as far as Linux is concerned, is systemd land.
Exclusively.

Thanks for your input.

Cheers,

A.

Hello:

Quite so ...

As you may have read, originally I started powering the HDD from one of the RPi's USB ports.
There was a problem with the SDD not spinning up but it was nothing other than the usual in these cases: the length and gauge of the cable with the micro-USB plug.

I wonder how they say too long / too thin in Chinese?   8^7

So I just got rid of it through some light PS surgery and replaced it with nothing.
The PS has three comfortable USB charging ports on the back and are enough.

Done that, I started powering the RPi with shorter and much better quality power only usb cable (Blackberry phone, I think) from one of the USB ports.
Voltage measurements taken at idle read 5.14V which would seem to be correct.

I also thought as much.
So I switched to powering the HDD from one of the PS's USB ports.

Not being under RPi control, the HDD's shut down timing/scheme would be different.
ie: not as sudden.

Well ...
Turns out that the HDD's shutdown is exactly the same whether the HDD is powered from a USB port on the RPi or a USB port on a separate power supply.
A separate power supply that is not switched off when the RPi is shut down.

Whatever controls this HDD shutdown is within the Devuan image's configuration and evidently does it under the assumption that it is controlling a SD Card and not a HDD.
But I have not been able to figure out what/where it is.

I say this because I have observed that this same HDD does not shut down in the same manner when connected to my Asus 1000HE netbook.

Thanks for your input.

Cheers,

A.