Feedback on new snap

Looking to share and get feedback on my first successful snap application, https://snapcraft.io/openaudible

I made the snapcraft.yaml project available here: https://github.com/openaudible/oa_snap if anyone wants to follow along or see a real-world example.

But I’m also not sure if I did it correctly. I’m not sure about which plugs/extensions I need to use. Wayland? X11? Unity? I’m not a linux expert but want to provide a linux app for my users. How do I test on all the platforms that snap runs on?

I’m also not sure the best way to run this java based gui application. Currently using a launch.sh that calls:

./jre/bin/java -Duser.home=$SNAP_USER_COMMON -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8 -jar openaudible_gtk_x86_64.jar > /dev/null 2>&1 &

But I didn’t see any other example apps using the trailing & to run the app in the background and pipe the output to dev/null. But it launches fine using the desktop icon, so perhaps it is fine.

What doesn’t work:

  • x11 via a terminal. I develop on windows and run very few linux desktop apps myself, but when I do, they usually come up on my windows box through my MobaXterm. Some snaps work fine, others, including mine, don’t come up at all and report an invalid authorization. Not sure how to fix.
  • Revealing a file in the default file manager doesn’t work. My app has a few places (like in the prefs) when you can click on a button and reveal a file path in the system folder. I tried multiple methods-- nautalis --select, xdg-open, dbus-send, gdbus call, etc. xdg-open gives an error message, but dbus-send at least opens the file manager and gives an error that opening the file path is “operation not supported” This is not a deal breaker, but spent many hours trying different approaches.
  • When starting the installed snap from terminal, the user sees 6 concerning warning schema messages.
Warning: Schema “org.gnome.system.locale” has path “/system/locale/”.  Paths starting with “/apps/”, “/desktop/” or “/system/” are deprecated.

Any suggestions for the above issues would be appreciated!

Here are a few suggestions for making life easier on new snapcraft developers:

Ability to override yaml values from command line OR set environment variables. Using a docker style -e format seems the easiest: snapcraft -e VERS=1.2.3 (and have version: $VERS in the yaml)

A big bug I encountered was that I was trying to build my snapcraft outside of my home directory. This apparently is not allowed, and the error message could use improvement: (Source path “/data/dev/oa_snap” does not exist)

So when I couldn’t build, I spent a day trying to get it working on stable.Dockerfile (getting python3 errors), running on VMWare/Virtualbox (no can do), and trying with LDX (also no luck.)

A few other gripes

  • Setting the license to “shareware”,“commercial”, “trialware” did not work. The web site for chosing a license also didn’t have anything like those listed as options. Ended up using Proprietary. But a reasonable error message would be nice or note on snapcraft-top-level-metadata.
  • Setting a top level yaml "website: " in the yaml caused the build to fail the snap checks with an error message about an invalid “links” yaml argument.

Sorry for the long post… but thought a little feedback give might be helpful.

Thanks for all the hard work that went into this ambitious project!

1 Like
environment:
  XAUTHORITY: ${SNAP_REAL_HOME}/.Xauthority

Can you clarify this please? I’m getting the impression that you’re wanting a folder path to appear in the file manager, in which case xdg-open would be expected to work for this. What’s the error message being given?

Snaps should inherit any exports done, except those that are overridden by the snap itself. You might find if you run snap run --shell $SNAPNAME, which will drop you into the container environment just prior to actually executing your snap, you’re able to override any environment variables set there because if you run export in this environment, it takes place after the variables have been rewritten in most snaps.

Admittedly it’s not great for the user experience, but it might help you out for development cases.

The licenses come from the SPDX license set, apart from “Proprietary” which is an exception. I guess it doesn’t fix the problem, but it might explain why the list is as it is.

It seems the store hasn’t been updated to actually use this metadata properly so the review tools reject it, I’m not savvy as to when this might be fixed, but it’s hopefully something that will be looked at in due course. (Relatively, that metadata is quite new).

Hey, thanks for the feedback.

The XAUTHORITY worked great! Maybe that should be on by default if one of the plugins is set to desktop? Anyway, no idea how I would have found that on my own.

Yes, I’d like to reveal a folder (or file) and I’d like to use xdg-open. Example: xdg-open /tmp which works in the terminal when using the snap’s xdg-open.

When running from inside the snap, the error message is:

cmd:xdg-open /tmp 
error code:3(3)+
stdout:
stderr:xdg-mime: mimetype argument missing
Try 'xdg-mime --help' for more information.
Can't locate Encode.pm in @INC (you may need to install the Encode module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.1 /usr/local/share/perl/5.26.1 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/bin/run-mailcap line 12.
BEGIN failed--compilation aborted at /usr/bin/run-mailcap line 12.
/snap/openaudible/x1/usr/bin/xdg-open: 851: /snap/openaudible/x1/usr/bin/xdg-open: x-www-browser: not found
/snap/openaudible/x1/usr/bin/xdg-open: 851: /snap/openaudible/x1/usr/bin/xdg-open: firefox: not found
[.... deleted similar messages....]
/snap/openaudible/x1/usr/bin/xdg-open: 851: /snap/openaudible/x1/usr/bin/xdg-open: w3m: not found
xdg-open: no method available for opening '/tmp'

Was able to run xdg-open with -x tracing and I think xdg-open depends on $DISPLAY being set, and it isn’t within the snap.

All other items are pretty minor.

Thanks again.

The core snap ships with xdg-open at /bin/xdg-open, the implementation differs significantly from the xdg-open on a normal system though. It acts as a wrapper for the XDG Desktop Portals service (or alternatively snap’s own Launcherd if the xdg-portals aren’t used for whatever reason).

If you’re shipping xdg-open as a stage package, I’d suggest removing it and just using the default. Otherwise, try specifying the path /bin/xdg-open specifically, or calling snapctl user-open $FILE; which is what /bin/xdg-open does.

You might still find some errors related specifically to using the /tmp folder though, I’m unsure how this’d resolve and the answer might vary depending on the host system. /tmp in your snap is actually something like /tmp/snap.mysnap/ on the real system. If you find /tmp has errors specifically, try setting

environment:
  TMPDIR: ${XDG_RUNTIME_DIR}

$XDG_RUNTIME_DIR has the same semantics as /tmp regarding files being cleared, but the absolute file path should be consistent between snap and host, so it fixes some niche errors. (All of this might not even be relevant for you, but if it is, hopefully it helps).

Ah! I had xdg-utils in my stage-packages. Removing that seems to have fixed everything. Thanks so much!

Hi openaudible,

congratulations on sucessfully publishing a JAVA based snap!

My single published snap (photonotebook) is using OpenJFX-11 and OpenJDK-11 (shortly to be upgraded to OpenJFX-17 and OpenJDK-17).

I chose OpenJFX for a couple of reasons, firstly the java support and third-party libraries can built into the app image, so the is no requirement any seperate platform-resident Java installation.

Secondly, I can use exactly the same code base (there is some OS detection required for when the OS in use needs specifics, but it isn’t very much ), third party libs and build toolchain for the Linux and Windows versions of the App (published on the Microsoft App store).

I use the Intellij Idea Community Edition (Linux and Windows versions) which produces run-ready code according to the OS platform version it is sitting on, using the jlink command provided. I use gradle to manage both the builds and third party library downloads from maven central.

The resulting build image just needs snapping or turning into a Windows .msix as required, and the IDE even produces a basic launch script for both platforms. The java launch script did need modifying to set the data home directory to SNAP_USER_COMMON.

My snap.yaml is about 22 lines long, and my IDE produced startup script is needs a small modification for use with the snap data environment, but it is only two active lines.

snap.yaml:

name: photonotebook
title: PhotoNoteBook
version: "2.0.0"
summary: A digital photography library manager and notebook 
license: Proprietary
description: PhotoNoteBook is a digital photograph library manager enabling collections of images and the making of notes and memo's for the collections and the photographs. 
icon: photonotebook.png 

confinement: strict
grade: stable
base: core20 

# this line enables LZO compression for the snap and speed up first start time - hopefully!
compression: lzo
 
apps:
  photonotebook:
    command: bin/photonotebook
    extensions:
      - gnome-3-38
    plugs: [home, unity7,  opengl, network, removable-media, optical-drive ,desktop, desktop-legacy, gsettings, x11, wayland]
     
parts:
  photonotebook:
    plugin: dump
    source: ./photonotebook/
    stage-packages: [libgif7, liblcms2-2]

The gnome-3-38 handles most of the screen interfacing dependencies, and I add a few plugs for things it doesnt handle (although I could be wrong here, the plugs may be duplicating capability in the extension).

start script

#!/bin/sh  
DIR="${0%/*}"
"$DIR/java" -Dprism.fontdir=$SNAP/etc/fonts -Duser.home=$SNAP_USER_COMMON -p "$DIR/../app" -m PhotoNoteBook/com.dryjointproductions.photonotebook.PhotoNoteBook  "$@"

I’m very happy to share these as I received a lot of help from Snapcraft people when developing my snap.

A word of caution. OpenJFX 11 and 12 work perfectly with my app, but OpenJFX 13 to 17 had a bug in the screen handling when changing complete “scenes” on a stage. However I reported the bug and a workaround to the openjdk bugtrack, and the workaround I have included in my OpenJFX-17 version of the App. (https://bugs.openjdk.java.net/browse/JDK-8258601?jql=key%20%3D%20JDK-8258601)

cheers Alan

2 Likes