Hey there, i need some help packaging audacious-snap, the snap has been built successfully but audacious has a core component audacious plugins available as a separate source package, i have successfully added it as another part in YAML, but the ./configure of it option needs audacious already installed, how do i achieve this in a single snapcraft yaml ?? Here is my YAML --:
You can declare after: [audacious]
in the plugins parts, so that Audacious will be built and staged in $CRAFT_STAGE
before the plugins part is built. You may need to adjust some build options in the plugins part to look for the application in the staging area.
thanks for replying,will using --> ./configure --enable-gtk3 --disable-qt --PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$CRAFT_STAGE ??, work
Snapcraft already sets PKG_CONFIG_PATH
to some standard locations so it may just work without having to set it manually. Otherwise you can change it accordingly, or see if there are options to the configure script that can help to tweak development component locations. (Note that PKG_CONFIG_PATH
is an environment variable and not an option to the configure script.)
Hey there as you said, snapcraft has automatically fixed such issues and audacious plugins have been successfully built but when running the snap it cant detect and use the audacious plugins and libs it always gives the following error --:
âââ error while loading shared libraries: libaudcore.so.5 âââ
and if i try to violate sandbox by running the snap from the snap directory it says audacious plugins not found eventhough it has been successfully packaged along audcore in snap/audacious-snap/usr/lib, how do i make audacious use these libraries and read them properly ?
Hey there,The New problem is that as per my findings the plugins part gets successfully buit and installed but not in the /usr of the first part instead it exists in a different directory and concerned subdirectories called build, that is to make the snap work i will have to get i installed in the /usr but its installed in /build, any solution ??..
If the shared libs are located in a nonstandard location inside the snap payload tree youâll need to tell the linker where it should look for libraries at runtime (e.g. by setting the LD_LIBRARY_PATH
in the app environment:
entry). In my mpg123 snap I do something like this:
apps:
mpg123:
...
environment:
LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/usr/lib/$CRAFT_ARCH_TRIPLET/pulseaudio
MPG123_MODDIR: $SNAP/lib/mpg123
Note that if the plugins themselves are not found you need to tell the application where the plugins are. These are typically dlopened there could be an application-specific way to configure that.
Files that will be part of the final snap should exist in the prime
directory. One part wonât write files to the build
or install
directory of another part, but they should all be consolidated in the stage
directory, and later in prime
after filters are applied (if any).
If something exists in the partâs build
directory but not in the partâs install
directory, you need to install it if you want it to be inside the final snap. This is usually done as part of the packageâs normal make install
process in the build step.
thanks for the reply,the problem being is that all the things needed to install are already installed but the components like output etc. are left out in the build directory, audacious part is installed with a executable but the libraries are not in the /usr directory, even if i specify it properly, it remains in the build directory
Here is the screenshot of contents of the directory, there is nothing that can be installed with make etc.
Ah, thatâs odd, you ended up with the build
directory inside the final snap payload! Could you post the current yaml youâre using so we can see whatâs happening there?
Ok,
I have recently changed the wrong executable path to /usr/bin/audacious wont affect the rest of the snap
Youâre doing a couple of strange things there: in both parts you already declared the git repository as the partâs source
, so you donât need to clone it manually in override-pull
. You also donât need to do things manually in override-build
if you use the autotools plugin instead of the nil plugin. Custom configuration options can be declared as autotools-configure-parameters
.
Itâs not immediately obvious to me why a âbuildâ directory appeared in the snap payload. I can try to build it locally later today to see whatâs happening there, but in the meantime using the autotools plugin and removing manual git cloning can make things easier.
bit more details in adding parameters to autotools please ??, got it, i will implent your suggestions, thanks
This is what I do in my mpg123 snap:
parts:
mpg123:
plugin: autotools
source: ...
autotools-configure-parameters:
- --prefix=
- --with-default-audio=pulse
- --enable-network=yes
- --enable-ipv6=yes
....
thanks
After all your implementations its still brokenâŚ
Whatâs causing the plugins to be installed under a weird path is the staged audacious pkgconfig file, audacious.pc
. Snapcraft patches the file to point to the correct build time locations under stage
, but audacious also uses it to set the runtime directory for plugins. To address that, we can for example change plugins_dir
back to something more reasonable:
parts:
audacious-snap:
source: https://github.com/audacious-media-player/audacious.git
plugin: autotools
....
override-stage: |
craftctl default
sed -i -e '/^plugin_dir=/s/\${exec_prefix}/\/usr/' usr/lib/pkgconfig/audacious.pc
This should fix the plugin location inside the snap (so there will be no /root/stage
paths there), but you still need to find a way to tell audacious where to find the plugins â you could use an environment variable (if it exists), or use a layout
entry to point /usr/lib/audacious
to $SNAP/usr/lib/audacious
.
(Itâs also interesting that your example also triggered @bugraaydogarâs version setting bug and I finally found a simple way to reproduce it!)
Thanks for checking out, i will implement your suggestions, meantime also thanks to clear my doubt regarding layouts i thought they are only used for connecting to external system folders etc. but glad to know we can also do internally, i will create a symlink for the current useâŚ