Failing to move LightBurn from classic to strict confinement

snap
1

Hi all,

While trying to make the snap not require classic confinement, we ran into a number of issues for LightBurn.

The classic confinement has not been approved (yet, or ever, we’re not sure as we’ve had no response).

Currently the snapcraft.yml file contains the data as follows:

name: lightburn # you probably want to 'snapcraft register <name>'
base: core20 # the base snap is the execution environment for this snap
version: '1.4.04' # just for humans, typically '1.2+git' or '1.3.2'
summary: LightBurn is layout, editing, and control software for your laser cutter. # 79 char long summary
description: |
  LightBurn is layout, editing, and control software for your laser cutter.
  Import artwork in a variety of common vector graphic and image formats.
  Arrange, edit, and even create new vector shapes within LightBurn's powerful editor.
  Apply settings like power, speed, number of passes, cut order, brightness & contrast, dithering mode, and many more!
  LightBurn is a native application written for Windows, Mac OS, and Linux.
  LightBurn is not a free application, but you get a 30 day trial to use it with full capabilities (and no watermark) to determine if it's the right software for you before buying a license.

grade: stable # must be 'stable' to release into candidate/stable channels
confinement: strict # use 'strict' once you have the right plugs and slots

apps:
  LightBurn:
    command: LightBurn
    environment:
      SNAP_REVISION: x11
      LD_LIBRARY_PATH: $SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/pulseaudio
      QT_PLUGIN_PATH: $SNAP/lightburn/plugins/
      QT_QPA_PLATFORMTHEME: gtk3
    plugs:
      - desktop-legacy
      - wayland
      - x11
      - raw-usb
      - network
      - desktop
      - home
      - camera
      - serial-port

parts:
  lightburn:
    # See 'snapcraft plugins'
    plugin: dump
    source: .
    stage-packages:
      - libusb-1.0-0
      - libegl1
      - libgl1
      - libasound2
      - libfontconfig1
      - libfreetype6
      - libpulse0
      - libpulse-mainloop-glib0
      - libxcb-xinerama0
      - libxcb-icccm4
      - libxcb-image0
      - libxcb-keysyms1
      - libxcb-render-util0
      - libxcb-xkb1
      - libxcb-randr0
      - libxcb-shape0
      - libxkbcommon-x11-0

A few points of frustration were had with regards to having to manually include all the libxcb-related libraries as stage-packages.

The other problems are as follow:

  1. LightBurn uses Cryptlex for license key validation (no it’s not FOSS software), and the license key data is normally stored in $HOME/.local/data/ but with strict confinement active, the license key data is not saved, and is requested upon each new application startup - a major hassle.
  2. Despite having the camera plug listed, it was not automatically connected during testing, using snap connections lightburn showed it was not there, nor were raw-usb or serial-port. We need all 3 of those for full feature functionality in LightBurn, and searching didn’t really yield any helpful information at all. Why would the plugs not function as expected? What are we missing in the current file definition?

Thank you to any and all input to help us resolve the problems we’re running into.

2

In the snap environment $HOME will be set to something like ~/snap/<snap name>/<revision>, and it should be possible to save to a relative .local/data/ directory. But, depending on your app, you may need to create the directory first.

You can experiment with this environment by using snap run --shell <snap name> which will give you a shell in the same environment your application runs in.

Most interfaces are not connected on installation by default. You will need to get an “autoconnect” request granted on the snap store. While testing you should connect them manually. (You can script a check whether they are connected in your snap package using snapctl is-connected <interface>)

HTH

3

Thanks Alan, this is really helpful.

Because of the amount of time needed to debug this compared to the relatively small number of Linux users at the moment, we decided to just stick to using the currently working AppImage release instead.

Snap would’ve been nice to add to the list, but at the moment we’re more focused on adding code features than packaging in multiple formats for so few of our users.

We’ll definitely come back to it semi-regularly. We’re overhauling parts of the build infrastructure internally, and if we can we’ll definitely package a snap out of it, but in the current state it’s just too much effort to justify it.

4

You’re welcome!

From your description here and in Request classic confinement review for LightBurn it does sound as though “strict” snap packaging could be made to work, but I know there’s a steep learning curve associated with snap packaging and you feel your efforts are better spent elsewhere. (FWIW there is no requirement to use CMake as you assert in the other thread.)

It is unfortunate that distributing on Linux is a fragmented landscape with .deb, .rpm, AppImage, FlatPak and Snap all being options. Visibility in the Snap Store could help visibility to Linux users, but I understand that is unlikely to be the main channel for discovery of your type of software.