Call for testing: Tizonia

snap
1

Hi,

For those interested, there is a snap of Tizonia (a command-line cloud music player) in the candidate channel.

snap install --candidate tizonia

So far, I have been able to run the app with strict confinement in Ubuntu 16.04 and 18.04, Manjaro 17.1, openSUSE tumbleweed, and Fedora 27. Barring any existing issues that might already have an entry in the app’s GitHub bug tracker, the snap installation is looking good.

One question I still need to polish is the location of the configuration file. TIzonia expects the user to manually enter cloud service credentials in its config file in the $HOME directory:

$HOME/.config/tizonia/tizonia.conf

With snap, this would go in $HOME/snap/tizonia/<version>/.config/tizonia/tizonia.conf

But (I believe) this file will be wiped out after a refresh?. So what is the current practice to allow persistent edits in these HOME config files? is it to move them somewhere under SNAP_USER_COMMON instead (which would require a small app modification, at least in tizonia’s case)?

2

A refresh will not remove this file-- it will copy it forward to the new revision. This allows for a newer revision to have the config file and to migrate to a new configuration while still supporting rolling the snap back to the old revision with the pre-migrated configuration. Some people will use SNAP_USER_COMMON instead of SNAP_USER_DATA depending on their needs (eg, storing large data files). You are of course free to choose either but I suggest you use SNAP_USER_DATA if the config file format changes incompatibly from time to time so that users can rollback.

3

A refresh will not remove this file-- it will copy it forward to the new revision

Awesome. This detail (contents will be carried forward to the next revision) was not completely clear to me on my initial read of https://docs.snapcraft.io/reference/env

I suggest you use SNAP_USER_DATA if the config file format changes incompatibly from time to time so that users can rollback.

And this other detail also escaped me. The fact that

$SNAP_USER_DATA = $HOME

in the snap world.

Tizonia naturally uses $HOME to locate the user config, so everything seems good.

Thanks @jdstrand!

(P.S.: maybe it is just me, but perhaps it might be useful to make these two ideas more explicit in https://docs.snapcraft.io/reference/env)

1 Like
4

@evan or @davidcalle - perhaps this is something to chase down?

5

Hi, I just found out about the Tizonia snap and I’ve been enjoying using it so far. The only issue I’ve had is that when I try to turn on MPRIS support I get a fatal error due to AppArmor denials:

scott@moya:~$ tizonia --plex-audio-artist "U2"
tizonia 0.15.0. Copyright (C) 2018 Juan A. Rubio
This software is part of the Tizonia project <http://tizonia.org>

terminate called after throwing an instance of 'Tiz::DBus::Error'
  what():  An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1076" (uid=1000 pid=9036 comm="/snap/tizonia/212/usr/bin/tizonia --plex-audio-art" label="snap.tizonia.tizonia (enforce)") interface="org.freedesktop.DBus" member="RequestName" error name="(unset)" requested_reply="0" destination="org.freedesktop.DBus" (bus)
/snap/tizonia/212/bin/tizonia-snap-wrapper.sh: line 22:  9036 Aborted                 $SNAP/usr/bin/tizonia "$@"

I do see the mpris slot for tizonia defined in snap interfaces. snappy-debug doesn’t seem to have any suggestions for this particular error either. When I turn MPRIS off my music plays fine.