artisan-roaster-scope / artisan

artisan: visual scope for coffee roasters
https://artisan-scope.org
GNU General Public License v3.0
938 stars 254 forks source link

Deploy as AppImage #557

Closed FilePhil closed 3 years ago

FilePhil commented 3 years ago

Please extend the release packages of Artsian with an AppImages version. AppImages can be run on all common Linux distributions and made the usage very easy.

I tried to create a AppImage by using the pkg2appimage Tool.

But I can't get it to run.

In the process a "AppDir" folder is created with a unpacked version of the deb-package. \ I can launch Artisan by executing the artisan file in the folder "./artisan.AppDir/usr/share/artisan/".

To build the Appimage I used the snipped provided by pkg2appimage.

wget -c https://github.com/$(wget -q https://github.com/AppImage/pkg2appimage/releases -O - | grep "pkg2appimage-.*-x86_64.AppImage" | head -n 1 | cut -d '"' -f 2)
chmod +x ./pkg2appimage-*.AppImage
./pkg2appimage-*.AppImage artisan.yml

To create the AppImage you need a yml file to specify the needed packages and modifications. I have adopted one of the example recipes. It pulls the latest release version of the deb-package and converts it into a AppImage.

artisan.yml

app: artisan

ingredients:
  dist: trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  script:
    - DEB=$(wget -q https://github.com/artisan-roaster-scope/artisan/releases/ -O - | grep deb | grep href |  head -n 2 | tail -n 1 | cut -d '"' -f 2)
    - wget -c "https://github.com/$DEB"
    - VER1=$(ls artisan-linux-*.deb | cut -d '-' -f 3 | sed -e 's|.deb||g')
    - mv "artisan-linux-${VER1}.deb" "artisan_linux_${VER1}_amd64.deb"

script:
  - cp ./usr/share/applications/artisan.desktop artisan.desktop
  - sed -i -e 's|^Exec=.*|Exec=artisan|g' artisan.desktop
MAKOMO commented 3 years ago

I have no experience with AppImages and actually not developing on Linux. Any idea why it does not run? Any log messages?

FilePhil commented 3 years ago

I think I found something. In the "AppRun" File are some errors.

 Error: No .desktop files found
 Error: Could not scan directory %s
     Error: Executable not found, make sure there is a line starting with 'Exec='
   WARNING: Desktop file field code %%%c is not currently supported
       WARNING: Invalid desktop file field code %%%c
  PATH=%s/usr/bin/:%s/usr/sbin/:%s/usr/games/:%s/bin/:%s/sbin/:%s LD_LIBRARY_PATH=%s/usr/lib/:%s/usr/lib/i386-linux-gnu/:%s/usr/lib/x86_64-linux-gnu/:%s/usr/lib32/:%s/usr/lib64/:%s/lib/:%s/lib/i386-linux-gnu/:%s/lib/x86_64-linux-gnu/:%s/lib32/:%s/lib64/:%s  PYTHONPATH=%s/usr/share/pyshared/:%s    XDG_DATA_DIRS=%s/usr/share/:%s  PERLLIB=%s/usr/share/perl5/:%s/usr/lib/perl5/:%s        GSETTINGS_SCHEMA_DIR=%s/usr/share/glib-2.0/schemas/:%s  QT_PLUGIN_PATH=%s/usr/lib/qt4/plugins/:%s/usr/lib/i386-linux-gnu/qt4/plugins/:%s/usr/lib/x86_64-linux-gnu/qt4/plugins/:%s/usr/lib32/qt4/plugins/:%s/usr/lib64/qt4/plugins/:%s/usr/lib/qt5/plugins/:%s/usr/lib/i386-linux-gnu/qt5/plugins/:%s/usr/lib/x86_64-linux-gnu/qt5/plugins/:%s/usr/lib32/qt5/plugins/:%s/usr/lib64/qt5/plugins/:%s       GST_PLUGIN_SYSTEM_PATH=%s/usr/lib/gstreamer:%s  GST_PLUGIN_SYSTEM_PATH_1_0=%s/usr/lib/gstreamer-1.0:%s  Error: Error executing '%s': %s

The problem seems be the "artisan" file which is located in "/usr/bin/"

I tired to copy the folder "/usr/share/artisan" to "/usr/bin" and the AppImage Works now!

app: artisan

ingredients:
  dist: trusty
  sources:
    - deb http://archive.ubuntu.com/ubuntu/ trusty main universe
  script:
    - DEB=$(wget -q https://github.com/artisan-roaster-scope/artisan/releases/ -O - | grep deb | grep href |  head -n 2 | tail -n 1 | cut -d '"' -f 2)
    - wget -c "https://github.com/$DEB"
    - VER1=$(ls artisan-linux-*.deb | cut -d '-' -f 3 | sed -e 's|.deb||g')
    - mv "artisan-linux-${VER1}.deb" "artisan_linux_${VER1}_amd64.deb"

script:
  - rm -rf "./usr/bin"
  - mv "./usr/share/artisan" "./usr/bin"
MAKOMO commented 3 years ago

Splendid! Would it help to name the linux builds directly *_amd64.deb to simplify that script?

By deleting ./usr/bin you delete the main artisan startup script which among others sets the QT_PLUGIN path and the LD_LIBRARY_PATH. Doesn't that break things? Any idea why the variant with the script ./usr/bin/artisan does not work?

I read https://docs.appimage.org/packaging-guide/converting-binary-packages/pkg2appimage.html

For example, if app: myapp is set, and there is usr/bin/myapp, usr/share/applications/myapp.desktop, and usr/share/icons/*/myapp.png, then the myapp.desktop and myapp.png files are automatically copied into the top-level directory of the AppDir.

Isn't this all given for the Artisan Linux package?

So moving just the desktop file, as in your first script, should do it, right? Maybe the fixed path /usr/share/artisan/artisan in the script /usr/bin/artisan is a problem.

I am still somewhat lost with this AppImage thing...

FilePhil commented 3 years ago

Would it help to name the linux builds directly *_amd64.deb to simplify that script?

No, I figured out, that the renaming is not needed to get a working AppImage. I'm only added it, because it was in the example script i used as a base.

Isn't this all given for the Artisan Linux package?So moving just the desktop file, as in your first script, should do it, right?

Yes the package is in spec, the pkg2appimage tool finds the .Desktop file by itself and the "manual" copy is not necessary.

Maybe the fixed path /usr/share/artisan/artisan in the script /usr/bin/artisan is a problem.

I agree, the hard coded paths seems to be a problem. By using the "binpatch: true " tag, I could force the AppImage to function with fixed paths, without moving the artisan folder. But there is a oblivious bug: The mouse cursor is changed to a low res basic cursor while using the application. image

Also I found a strange issue, when the "LCDs" should show "-1.0". The numbers are cut in half. (binpatch tag is does not effect the issue) image

MAKOMO commented 3 years ago

Would it help to name the linux builds directly *_amd64.deb to simplify that script?

No, I figured out, that the renaming is not needed to get a working AppImage. I'm only added it, because it was in the example script i used as a base.

Isn't this all given for the Artisan Linux package?So moving just the desktop file, as in your first script, should do it, right?

Yes the package is in spec, the pkg2appimage tool finds the .Desktop file by itself and the "manual" copy is not necessary.

Maybe the fixed path /usr/share/artisan/artisan in the script /usr/bin/artisan is a problem.

I agree, the hard coded paths seems to be a problem. By using the "binpatch: true " tag, I could force the AppImage to function with fixed paths, without moving the artisan folder. But there is a oblivious bug: The mouse cursor is changed to a low res basic cursor while using the application. image

I cannot verify this and it might also depend on your platform. Could it result from the use of the following startup from the /usr/bin/artisan script which is used in this case.

exec /usr/bin/env GDK_BACKEND=x11 PATH=/usr/share/artisan:$PATH QT_PLUGIN_PATH=/usr/share/artisan/PyQt5/Qt/plugins LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gtk-3.0/modules:/usr/share/artisan:$LD_LIBRARY_PATH LIBOVERLAY_SCROLLBAR=0 GTK2_RC_FILES="$HOME/.gtkrc-2.0" /usr/share/artisan/artisan "$@" 2>/dev/null

I assume that only the QT_PLUGIN_PATH part is essential here. The other things were added to workaround reported issues on some Linux distributions and might not needed any longer. Could you test to remove some of those and see if this improves the situation on your setup?

Also I found a strange issue, when the "LCDs" should show "-1.0". The numbers are cut in half. (binpatch tag is does not effect the issue) image

Well, the uu is just the way Artisan v2.4.2 is now indicating on its LCDs that it did not has any valid numbers to show to avoid the recurring confusion of wrong temperatures -1C being displayed.

MAKOMO commented 3 years ago

What would then be the final script to be used to build a valid AppImage? We would love to add this to our CI setup.

FilePhil commented 3 years ago

I cannot verify this and it might also depend on your platform. Could it result from the use of the following startup from the /usr/bin/artisan script which is used in this case.

I have tried some Virtual Machines with Ubuntu, Fedora, Elementary OS, Opensuse, always the same cursor Issue.

I assume that only the QT_PLUGIN_PATH part is essential here. The other things were added to workaround reported issues on some Linux distributions and might not needed any longer. Could you test to remove some of those and see if this improves the situation on your setup?

I have tried to strip the exec line one by one, but i cant get it to run from the startup script.

/usr/bin/env GDK_BACKEND=x11

This should fix a bug with the "QFileDialog::getOpenFileName" on GTK Deskop Environment Machines. I have found a workaround by forcing qt to use the Qt internal FileDialog.

PATH=/usr/share/artisan:$PATH

The "/bin" is always in the PATH variable. So it is not needed in this case.

QT_PLUGIN_PATH=/usr/share/artisan/PyQt5/Qt/plugins

The QT Plugins will be found if the artisan folder is moved to "/bin".

LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/gtk-3.0/modules:/usr/share/artisan:$LD_LIBRARY_PATH

According to #305 there were Issues with the libglib on openSuse (Tubleweed), but as AppImage it starts fine. And I have not seen any issue while tinkering around.

LIBOVERLAY_SCROLLBAR=0 GTK2_RC_FILES="$HOME/.gtkrc-2.0" ..... "$@" 2>/dev/null

I don't now for what these are for.

What would then be the final script to be used to build a valid AppImage? We would love to add this to our CI setup.

See pull-request #559 :)

MAKOMO commented 3 years ago

Thanks Phil for the suggestion and all your contribution on this one! The AppImage is now build by the CI and we will add it to the next release.