State of documentation, troubleshooting

I’ve used VmWare Thinapp and App-V a lot in the Windows world.
I’ve done Linux administration and AIX administration for maybe a decade.

Snap seems like a really cool concept, it is better than docker for local apps.

I’ve spent several days messing around trying to package qemu + libvirt + virt-manager

  1. Debugging snapcraft package building, you can use snapcraft --debug if a step fails. It’ll give you a shell. What about getting into a shell if it’s not failing, but you just want to visually see what has been staged or primed? snap run multipass list \ snap run multipass shell will get you there. Is there a better way? This probably should be on the front page of documentation for building a package.

  2. It’s not clear how to clean from a specific step, like build or stage? There at one point was a -s option, but it’s gone in 3.6. snapcraft clean partname will keep downloading the source and recompiling, adding a lot of time for troubleshooting?

  3. snap run --shell seems broken. Yes, it gives you a shell. $LD_LIBRARY_PATH is not set making it worthless for troubleshooting. I built bash into my snap pack so I can actually troubleshoot it, which seems silly. This should be again a front page document. How do you troubleshoot a snap “in the sandbox?”

I’m seeing a lot of threads go unanswered, and the IRC channel is mostly dead. The community hasn’t reached a level where it can self-sustain support, yet…

It would be cool to see this go from a niche thing to a de-facto way to deliver software on Linux - and maybe it could even help binary repo managers of various distributions by making software packaging cross-distro…distro-specific package repositories could be shrunk.

1 Like

This is really quite janky. libvirt puts all sorts of build-time discoveries compiled in in the form of C macros. As such, it’s really not designed for the build time and run time configurations to be different. It’s really fighting with snapcraft which builds stuff in /root…And, like, LD_LIBRARY_PATH in the sandbox isn’t set to include pulseaudio, so apps dependent on it seem to fail unless you specify it in the environment for an app. It’s actually working, I can run libvirtd, but I don’t know if I should continue with this.

snap run --shell seems broken. Yes, it gives you a shell. $LD_LIBRARY_PATH is not set making it worthless for troubleshooting.

snap run --shell seems broken. Yes, it gives you a shell. $LD_LIBRARY_PATH is not set making it worthless for troubleshooting.

That smells like a bug, or at least something the devs can implement. Please file a bug against the Snapcraft project on Launchpad.

You can also set the environment variable manually:

https://docs.snapcraft.io/environment-variables-snapcraft-exposes

You might find the implementation of the qemu-virgil snap helpful:

2 Likes

QEmu packaged fine. It’s libvirt and virt-manager that are causing all sorts of problems, because the build environment and execution environment differ with snap - paths change once you run a snap - ie from /root/parts/etc to $SNAP, a dir in /snap

“layout” isn’t always enough to work around that.

I kind of wish snapcraft would install stuff to normal prefix, /usr, /usr/local, etc, and that snap would just overlay the filesystem so the build and run environments don’t differ. For people packaging up their own software, this is a non issue…they wouldn’t ever hardcode compile-time path discovery information into code as macros…it seems insane…thats what config files are for…

I’m giving up
Here’s what I have, libvirtd, virsh, qemu, etc function. At the bottom I started pasting together a script to build a python venv since the python plugin won’t work for this. I’d have to probably use the dump plugin and manual build scripts. Even if I get it working, it’s going to be days of fighting with virt-manager, the same fight I had with libvirt, because it expects that the build and run environments are identical.

If anyone else wants to pick it up, feel free! It pains me to drop this, it would have been really cool to be able to easily install the latest versions of the libvirt + qemu + virtmanager suite across different distros.

Edit: I made one more push

It’s all building. The python plugin gets negatively impacted if parts prior pull in python dependencies. Complains about not being able to find pip, coreutils, etc. So I did it with dump and script overrides, set up a venv.

Ultimately, virt-manager fails to run

ylanetaft@dylanetaft-Z170X-UD5:~/virtpackage$ snap run virtpackage.virt-manager --debug
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (cli:205) Launched with command line: /opt/virtmanager/share/virt-manager/virt-manager --debug
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (virt-manager:223) virt-manager version: 2.2.0
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (virt-manager:224) virtManager import: <module ‘virtManager’ from ‘/opt/virtmanager/share/virt-manager/virtManager/init.py’>

(virt-manager:21148): Gtk-WARNING **: 00:42:15.104: Locale not supported by C library.
Using the fallback ‘C’ locale.
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (virt-manager:274) PyGObject version: 3.32.2
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (virt-manager:278) GTK version: 3.22.30
GLib-GIO-Message: 00:42:15.141: Using the ‘memory’ GSettings backend. Your settings will not be saved or shared with other applications.

(virt-manager:21148): GdkPixbuf-WARNING **: 00:42:15.141: Cannot open pixbuf loader module file ‘/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache’: No such file or directory

This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (systray:213) Showing systray: False
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (inspection:41) python guestfs is not installed
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (engine:113) No stored URIs found.
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (engine:537) processing cli command uri= show_window=manager domain=
[Mon, 01 Jul 2019 00:42:15 virt-manager 21148] DEBUG (engine:539) No cli action requested, launching default window
Fontconfig warning: “/etc/fonts/fonts.conf”, line 5: unknown element “its:rules”
Fontconfig warning: “/etc/fonts/fonts.conf”, line 6: unknown element “its:translateRule”
Fontconfig error: “/etc/fonts/fonts.conf”, line 6: invalid attribute ‘translate’

(virt-manager:21148): GdkPixbuf-WARNING **: 00:42:15.209: Cannot open pixbuf loader module file ‘/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache’: No such file or directory

This likely means that your installation is broken.
Try running the command
gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache
to make things work again for the time being.

(virt-manager:21148): Gtk-WARNING **: 00:42:15.209: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.

Surprise surprise…more compiled apps expecting things in /usr/lib and not $SNAP/usr/lib
You can’t really use layout to redirect /usr/lib without breaking snappy too.

Even if I get this working…it’s ugly.
MAYBE I could avoid using the autotools plugin for at least libvirt, feed the configure script a prefix of /opt and redirect the subdirectory there, to make the later things dependent on it less hacky…that mount -o bind…wow.

Fontconfig and GTK-related libs aren’t happy with me though.

1 Like

You can use snapcraft --shell to get a shell instead of the specified sub-command or snapcraft --shell-after to get a shell after the specified sub-command finishes. It is a bit confusing because the documentation for those two options is actually underneath the help for snapcraft build --help or snapcraft snap --help even though you can use the options with just snapcraft without a sub-command. I filed a LP bug to improve this here

This was recently fixed … but only if the snap you’re developing uses adapter: full, adapter: none and command-chain. There’s a bit of a history here, but basically snapcraft 2.X used to create full shell scripts which setup these environment variables and exec’d the binary you specify under command in your app from that script, while snapd would simply just exec a shell ignoring that wrapper script that snapcraft generated. Instead, snapd now understands command-chain in the snap.yaml as a way to setup environment variables and things like that in a separate section from the binary that is exec’d, so if your snap is built with a command-chain (which should be partly auto-generated for you by snapcraft if you use adpater: full or adapter: none), doing snap run --shell will execute the command-chain scripts and then a shell, stopping before executing the app itself.

All of that however requires you to build your snap (or others to build their snap) with adapter: none or adapter: full.

This may just be a problem with IRC in general since you may not see much activity if you don’t use a bouncer or happen to be online at the same time as the devs which for snapd is usually Europe workday timezones and for snapcraft is Europe/Americas.

This is of course a more general problem than just libvirt, but there has been discussion before of having a “rootfs” style application snap where the snap doesn’t use a base snap at all and instead chroot’s or pivot_root’s into $SNAP so it looks like it’s in the same run-time environment as the build-time environment. This is like what docker and other container runtimes do, however has it’s own disadvantages and I don’t know of any active work to support this in snapd/snapcraft.

2 Likes

I am down to one error.


If I try the fix here I get an error -
Failed to get part information: Cannot find the definition for part ‘desktop-gtk3’, required by part ‘virtmanager’.
Remote parts are not supported with bases, so make sure that this part is defined in the snapcraft.yaml.

The only app error I am getting now is
**
Gtk:ERROR:…/…/…/…/gtk/gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Failed to load /org/gtk/libgtk/icons/24x24/status/image-missing.png: Unrecognized image file format (gdk-pixbuf-error-quark, 3)
Aborted (core dumped)

Looking for instructions on desktop apps using bases.

Edit:
Aye, documentation is all over
Found this. Will do some reading and try it.

The folks building the multipass snap had a workaround that I borrowed for the microstack snap (both projects use libvirt). You can set --prefix to /snap/$SNAPCRAFT_PROJECT_NAME/current when you’re building libvirt, then move everything in snap/<your snap name>/currentt to ./ in the organize step.

You’d wind up with something like this in your app:

libvirt:
    ....
    configflags:
      ...
      - --prefix=/snap/$SNAPCRAFT_PROJECT_NAME/current
    organize:
      snap/<snapname>/current: ./

Combine that with additional config flags that override some of the discovery macros that libvirt runs, and you wind up with a working snap. It’s not the prettiest workaround in the world, but it is effective.

Did you get the GTK part of this working yet? Check out this snapcraft.yaml for my GTK app. It’s a simple-ish example of what you need to get desktop-gtk3 desktop helper working with bases.

name: draftman
version: 1.0.5
summary: Draft management for writers
description: |
    Draftman is a draft-management system for writers.
grade: stable # must be 'stable' to release into candidate/stable channels
confinement: classic
base: core18

apps:
  draftman:
    command: bin/desktop-launch $SNAP/usr/bin/draftman
parts:
  draftman:
    source-type: local
    source: .
    plugin: make
    build-packages:
      - desktop-file-utils
      - gettext
      - gnome-common
      - appstream-util
      - gnome-pkg-tools
      - intltool
      - libglib2.0-dev
      - libgtk-3-dev
      - libxml2-dev
    after:
      - desktop-gtk3
  desktop-gtk3:
    source: https://github.com/ubuntu/snapcraft-desktop-helpers.git
    source-subdir: gtk
    plugin: make
    make-parameters: ["FLAVOR=gtk3"]
    build-packages:
      - build-essential
      - libgtk-3-dev
    stage-packages:
      - libxkbcommon0  # XKB_CONFIG_ROOT
      - ttf-ubuntu-font-family
      - dmz-cursor-theme
      - light-themes
      - adwaita-icon-theme
      - gnome-themes-standard
      - shared-mime-info
      - libgtk-3-0
      - libgdk-pixbuf2.0-0
      - libglib2.0-bin
      - libgtk-3-bin
      - unity-gtk3-module
      - libappindicator3-1
      - locales-all
      - xdg-user-dirs
      - ibus-gtk3
      - libibus-1.0-5