That fixed the font and data issues, tnx! But now the application crashes after a few seconds. A strace shows a lot of errors, mostly this part repeating:
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libnsl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libnsl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libnsl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libnsl", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
munmap(0x7f123e74b000, 85648) = 0
open("/var/lib/snapd/lib/gl/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/var/lib/snapd/lib/gl32/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/var/lib/snapd/void/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/x86_64/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("tls/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("x86_64/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/lib/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/usr/lib/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/lib/x86_64-linux-gnu/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/usr/lib/x86_64-linux-gnu/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/usr/lib/x86_64-linux-gnu/mesa/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/usr/lib/x86_64-linux-gnu/mesa-egl/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/usr/lib/x86_64-linux-gnu/dri/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/snap/brouwhulp/x2/usr/lib/x86_64-linux-gnu/qt4/libnsl.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
fstat(9, {st_mode=S_IFREG|0644, st_size=85648, ...}) = 0
mmap(NULL, 85648, PROT_READ, MAP_PRIVATE, 9, 0) = 0x7f123e74b000
close(9) = 0
That solved a lot of errors, but the GUI still crashes after a few seconds with the strace endlessly filling with these kind of messages every couple of seconds:
Do you have all of the interfaces connected? See snap connections <your snap name> and then run snap connect for any that aren’t connected. Some interfaces don’t auto-connect by default (but can be made to do so with a request as per Process for aliases, auto-connections and tracks)
For this file, you could try using a layout to a writable version of the config file somewhere in $SNAP_DATA, initially populating that file in the writable directory with one that is in $SNAP:
and then have your snap install hook copy the file from $SNAP (which is read-only) to $SNAP_DATA (which is writable):
#!/bin/sh -e
# check if the file is empty (snapd will create the empty file for us setting up a layout)
if [ -z "$(cat $SNAP_DATA/etc/openal/alsoft.conf)" ]; then
cat $SNAP/etc/openal/alsoft.conf > $SNAP_DATA/etc/openal/alsoft.conf
fi
Note the ‘operation’ is mknod, not the command. It is not unusual for the syscall to be used to create regular files. I suspect this denial is coming from a snap refresh/install happening while brouwhulp is still running since the profile is updated to allow read-only access for the prior revision.
I have given up on snapping BrouwHulp, but man, the snap documentation is completely worthless.
I have another app I tried to package, which proved a total nightmare too.
/usr/share/[data] is missing again; seems that only the ‘command’ and ‘desktop’ files are copied?
Should I compile with a prefix other than /usr? Should I use a prefix like /snap/[package]/current/usr instead?
Layouts are for precompiled binaries where you can’t control the location of libraries, so I have to use ‘filesets’ and’ prime’, but then point 1 rises again.
I am facing the same challenges. There is literally no real documentation for snapcraft. I am trying to do a classic snap for an application called Maitreya8, it is an astrology application, It throws errors that the directory /usr/share/maitreya or anything underneath does not exist. This is crazy…Does this problem really have no solution. Should I give up on snaps like everyone else.
is there any particular reason to make an astrology application classic instead of using strict confinement (in which case you can use layouts similar to how @ijohnson described it above but with whole directories)
yes, It needs to launch a pdf reader to view the astrological report that it generates. by default strictly confined snap does not allow for a second process thread from within the same snap, ( my understanding may be wrong). Hence packaging say evince withing the snap had no impact. With classic snap it can access evince but it fails to see the /usr/share/maitreya8 directory within the snap file structure. the snap uses autotools plugin…Layouts were used in strictly confined snap and it worked elegantly. for now I am using it without the pdf viewer fearure, Any help in getting the classic snap to see the file system within the snap will be much appreciated.
If the aim is to open a pdf in strict confinement, you can open evince by using xdg-desktop-portals functionality, the easiest way to do this would be to simply make a call to xdg-open <path.pdf> in the apps code.
You can give it a quick try with
snap run --shell maitreya8
xdg-open <path-to-pdf>
to see how it would roughly work. It should open up a GUI where the user can select their preferred viewer to open the file.
yes, your understanding is definitely wrong
snaps allow you to package and run as many apps as you want in one snap, there are no limits here (apart from … well, ram and cpu of the host)
note that “launching a pdf viewer” is not enough to get permissions to upload your snap as classic … what james describes is the corrct way, make the app use xdg-open and it should just work with any modern desktop.
snaps allow you to package and run as many apps as you want in one snap, there are no limits here (apart from … well, ram and cpu of the host)