Re: Request for snap interface that expose user-space device APIs

[Lorn Potter]

On 15/11/16 08:50, Jian LUO wrote:
> Hi snapcrafters,
> 
> Embedded systems (which are likely called IoT devices these days :)
> sometime need access to peripherals via user-space device APIs, namely
> i2cdev[1], spidev[2] and uio[3]. Snaps of type core and gadget should be
> able to expose these interfaces to other privileged snaps.
> 
> I've opened a bug report for the feature request:
> https://bugs.launchpad.net/snappy/+bug/1641752
> 
> Does it make sense?

Yes.
Comment on that bug.

> 
> Cheers,
> 
> Jian
> 
> 

-- 
Software Engineer
System Enablement, Canonical Ltd
QtSystemInfo, QtSensors maintainer

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cliqz Snap

[Chris]

On Mon, 2016-11-14 at 17:16 -0800, Seth Arnold wrote:
> On Mon, Nov 14, 2016 at 08:13:33AM -0600, Chris wrote:
> > 
> > Hallo Cpollock,
> > 
> > deine Anfrage hat den CLIQZ Support erreicht. Unser Ziel ist es,
> > dir so
> > schnell wie möglich zu antworten. Das wird nicht allzu lange
> > dauern,
> > versprochen.
> > 
> > In der Zwischenzeit kannst du mal in unsere FAQs schauen: https://c
> > liqz
> > .com/support
> > 
> > Und kennst du schon unseren Blog? Schau mal hier: https://cliqz.com
> > /abo
> > utus/blog
> > 
> > Danke für deine Geduld. Wir melden uns bald wieder bei dir!
> > 
> > Der CLIQZ Support
> Here's my shot; perhaps not idiomatic but should convey the idea
> well:
> 
> Hello Cpollack,
> 
> Your question has reached CLIQZ Support. Our goal is to answer you as
> quickly as possible. That will not take long, promise.
> 
> In the meantime, you can look in our FAQs: https://cliqz..com/support
> 
> And do you already know our blog? Look here:
> https://cliqz.com/aboutus/blog
> 
> Thanks for your patience. We'll contact you soon!
> 
> 
Thanks Seth, guess I'll wait and see if I hear back.

> 
-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
19:59:06 up 5 days, 27 min, 1 user, load average: 0.31, 0.31, 0.39
Ubuntu 16.04.1 LTS, kernel 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 
UTC 2016


signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cliqz Snap

[Seth Arnold]

On Mon, Nov 14, 2016 at 08:13:33AM -0600, Chris wrote:
> Hallo Cpollock,
> 
> deine Anfrage hat den CLIQZ Support erreicht. Unser Ziel ist es, dir so
> schnell wie möglich zu antworten. Das wird nicht allzu lange dauern,
> versprochen.
> 
> In der Zwischenzeit kannst du mal in unsere FAQs schauen: https://cliqz
> .com/support
> 
> Und kennst du schon unseren Blog? Schau mal hier: https://cliqz.com/abo
> utus/blog
> 
> Danke für deine Geduld. Wir melden uns bald wieder bei dir!
> 
> Der CLIQZ Support

Here's my shot; perhaps not idiomatic but should convey the idea well:

Hello Cpollack,

Your question has reached CLIQZ Support. Our goal is to answer you as
quickly as possible. That will not take long, promise.

In the meantime, you can look in our FAQs: https://cliqz..com/support

And do you already know our blog? Look here:
https://cliqz.com/aboutus/blog

Thanks for your patience. We'll contact you soon!




signature.asc
Description: PGP signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Request for snap interface that expose user-space device APIs

[Jian LUO]

Hi snapcrafters,

Embedded systems (which are likely called IoT devices these days :)
sometime need access to peripherals via user-space device APIs, namely
i2cdev[1], spidev[2] and uio[3]. Snaps of type core and gadget should be
able to expose these interfaces to other privileged snaps.

I've opened a bug report for the feature request:
https://bugs.launchpad.net/snappy/+bug/1641752

Does it make sense?

Cheers,

Jian
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: configure hook

[Sergio Schvezov]

El 14/11/16 a las 18:35, Boris Rybalkin escribió:
VM has snapd v2.17, is it possible to install this version on desktop 
16.04/16.10 so I can have it for integration tests?


It is in xenial-proposed https://launchpad.net/ubuntu/+source/snapd
If you want the latest and greatest at all times (non production). If 
you do this, follow the pinning process in 
https://wiki.ubuntu.com/Testing/EnableProposed to pin snapd to 
xenial-proposed only and not risk getting more (potentially unstable) 
-proposed software.



Also is there any documentation on how to install snapd on a linux?


These are the installation instructions available for the variety of 
distros around:
http://snapcraft.io/docs/core/install, in case you wonder where I got 
that link from, it is available as a link on the web front of 
http://snapcraft.io


--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: configure hook

[Boris Rybalkin]

Great, on ubuntu core vm hook worked perfectly fine and even was executed
on install with all the issues printed to the output until fixed it!

VM has snapd v2.17, is it possible to install this version on desktop
16.04/16.10 so I can have it for integration tests?
Also is there any documentation on how to install snapd on a linux?

On Mon, Nov 14, 2016 at 9:20 AM, Didier Roche  wrote:

> Le 14/11/2016 à 10:04, Boris Rybalkin a écrit :
>
> Will it help if I upgrade to 16.10?
>
> No, it contains the same version: https://launchpad.net/ubuntu/+
> source/snapd
> Try the ubuntu core vm is the only easy way for you to progress there.
>
> Also what is really relation between snapd and ubuntu core on amd64?
>
>
> snapd is part of the core snap. snapd from the core snap is running on
> ubuntu core, snapd from the ubuntu package is running on the desktop. (the
> REEXEC plan has been disabled some months ago, due to some issues IIRC)
>
> Didier
>
>
>
> On 14 Nov 2016 8:01 am, "Didier Roche"  wrote:
>
>> Le 12/11/2016 à 17:45, Boris Rybalkin a écrit :
>>
>> Still struggling with hooks, they are not executed on install.
>>
>> snap$ snap run --hook=configure syncloud-platform
>> cannot snap-exec: cannot find hook "configure" in "syncloud-platform"
>> and even 'snap run --hook=configure mysnap' silently returns.
>>
>> I am using:
>> Ubuntu 16.04
>> snapd 2.16ubuntu3
>>
>> Does it have hook support?
>>
>>
>> It's supposed to have some, but IIRC, Kyle found some issues with it.
>> Definitively, this version doesn't run the hook on install though.
>>
>> According to this test they should even fail install if broken:
>> https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c
>> 8fc43051500bd6c3fda/tests/main/snap-set/task.yaml
>>
>> As suggested I am copying meta/hooks to prime dir after running snapcraft
>> prime  and then running snapcraft snap.
>>
>> This bug says it is probably not yet available in edge, how do I switch
>> channel?
>>
>> https://bugs.launchpad.net/snappy/+bug/1636931
>>
>>
>> As I said in some email above, the easiest path to test it is to use an
>> ubuntu core VM (until a new snapd release is out for Ubuntu 16.04 desktop,
>> CCing Michael to know when the next snapd hits stable + SRU published).
>> Cheers,
>> Didier
>>
>> Thank you.
>>
>> On 9 Nov 2016 09:21, "Didier Roche"  wrote:
>>
>>> Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>>>
>>> One more question, should I expect a hook to run inside my snap package
>>> and use relative shebang like this?
>>>
>>> #!python/bin/python
>>>
>>> Assuming I am packaging python with my snap.
>>>
>>> hooks are run using the same context than any "commands:" in your snap.
>>>
>>> As long as we don't have snapcraft support, I don't think you will have
>>> the override in PYTHONPATH, PYTHONHOME and such (and I don't know if that's
>>> planned), but I'll give it a try later this week or early new one to have
>>> great python hooks examples.
>>>
>>> If you beat me to it, do not hesitate to report your results here!
>>>
>>> Thank you very much for your replies!
>>>
>>>
>>> My pleasure :)
>>>
>>>
>>>
>>> On 9 Nov 2016 08:58, "Didier Roche"  wrote:
>>>
 Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :

 Sorry, I did not get that.

 I am using snapcraft, are you saying that just creating hooks/configure
 is not enaugh?

 It should be enough if you ensure it's in your final snap in
 meta/hooks/configure. (Look at your prime/ directory).
 Enwei was talking about more advanced snapcraft integration, where you
 point to a file which is then copied for you in meta/hooks.

 Looks like my hook is not executed:
 https://github.com/syncloud/platform/tree/master/snap

 Is it possible to debug the execution of snap install?

 I would like to see the state of the snap after it failed to start
 daemons. The only way to see the problem is to run journalctl and guess by
 startup errors.

 Yeah, hooks are hard to debug, I filed


 *https://bugs.launchpad.net/snappy/+bug/1640114
  yesterday about this.
 Didier *

 --
 Snapcraft mailing list
 Snapcraft@lists.snapcraft.io
 Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
 an/listinfo/snapcraft


>>>
>>>
>>>
>>> --
>>> Snapcraft mailing list
>>> Snapcraft@lists.snapcraft.io
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/snapcraft
>>>
>>>
>>
>>
>>
>> --
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/snapcraft
>>
>>
>
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>


-- 
Boris Rybalkin
ribal...@gmail.com
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 

Re: Nand flash booting.

[Barry Warsaw]

On Nov 14, 2016, at 11:38 AM, Steve Langasek wrote:

>It is an explicit element of the ubuntu-image design that a gadget snap
>should be able to emit multiple images for a given model, so that these can
>be written out separately across e.g. an SD card and a NAND device.  However,
>the current implementation only allows for an image containing a partition
>table, and filesystems within that.
>
>Barry, Gustavo, do we need to extend gadget.yaml semantics here to support
>some sort of 'schema: raw' for a volume, for the NAND case?

There are really two issues here.  One is an implementation problem in that
ubuntu-image currently only supports a single volume (a.k.a. image) entry per
gadget.yaml.  LP: #1641727 tracks this.

Second, as you point out, the gadget.yaml specification only defines a
partitioning schema of mbr or gpt, so yes, the spec would need to add support
for something like a 'raw' schema.  I don't believe we have a tracking bug
(either in u-i or snappy) for this.

Cheers,
-Barry


pgp1ZhYAmgjOm.pgp
Description: OpenPGP digital signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cross platform snap creation?

[Peter Uithoven]

Thanks guys,

I was indeed mostly focused on building snaps. I think some solution with
docker, like https://github.com/chihchun/snapcraft-docker look great.

Some of you have reached out directly to the Electron team, thanks for
that. See:
https://github.com/electron-userland/electron-builder/issues/509
https://github.com/electron-userland/electron-packager/issues/525

Can't wait for all these apps to be easily available:
http://electron.atom.io/apps/

Peter
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Nand flash booting.

[Steve Langasek]

On Mon, Nov 14, 2016 at 03:50:52PM +0100, Oliver Grawert wrote:

> On Mo, 2016-11-14 at 01:21 +, Daniel Toussaint wrote:
> > I am working on a board similar to Beaglebone Black, however instead
> > of SD/eMMC it is booting from NAND flash directly. As far as I can
> > see in the documentation there is no way yet to boot a Snappy image
> > in this fashion, is support for this planned ? Is there anything I
> > can do to help out with that ?

> > Meanwhile, I am considering using the Yocto version of snapcraft to
> > package the apps, so that we can later migrate to from the current
> > Yocto image to Snappy. 

> > Thanks for your comments.

> currently the boot process relies heavily on filesystem labels for
> finding the various (namely system-boot and writable) partitions. 

> do your NAND devices expose labels you set in /dev/disk/by-label ? 

> if thats the case it might work to use ubuntu-image with the --workdir
> option which keeps the different partition images around in the
> specified dir. you could then just grab them from there and flash then
> to the respective NAND pratitions.

> if the labels are not exposed this will need a bunch of changes in the
> code to allow some overrides (i.e. via kernel cmdline options), for
> this we will need a wishlist bug as the first step :)

It is an explicit element of the ubuntu-image design that a gadget snap
should be able to emit multiple images for a given model, so that these can
be written out separately across e.g. an SD card and a NAND device. 
However, the current implementation only allows for an image containing a
partition table, and filesystems within that.

Barry, Gustavo, do we need to extend gadget.yaml semantics here to support
some sort of 'schema: raw' for a volume, for the NAND case?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Spread 2016.11.14

[Gustavo Niemeyer]

Hello all,

The 2016.11.14 release of Spread is now available both as a snap and at
Travis.

There are quite a few interesting changes on this one:

- Support for fetching files generated by the remote tasks:

https://github.com/snapcore/spread#residue

- Support for "manual" tasks/suites/systems/backends, which only run when
explicitly selected:

https://github.com/snapcore/spread#manual

- Repack support which allows the implementation of delta uploads:

https://github.com/snapcore/spread#repacking

- New -shell-after and -shell-before flags.

- Spread now tests spread itself:

https://github.com/snapcore/spread/tree/master/tests

- Print job's position ("N of M"), to have an idea of where things stand.

- New MATCH function oriented at tests that look like:

echo foobar | MATCH foo

  It uses grep underneath, but unlike grep it prints the whole output when
the match fails, making it easier to debug the problem.

- ERROR function is now supported on any script.

- Fixes around handling of environment variables inside debugging shells.

- Define $SPREAD_* early so they may be referenced inside other variables.

- Force use of LXD images from local cache when available, improving
performance and allowing offline use.


-- 
gustavo @ http://niemeyer.net
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Ubuntu Online Summit coming up: 15-16 Nov 2016

[Daniel Holbach]

Hello everybody,

tomorrow Ubuntu kicks off its once-a-cycle Ubuntu Online Summit, which
will feature key developers and contributors both presenting what's new
in Ubuntu 16.10 and discussing upcoming work for 17.04 as well. There's
a Core track as well, which for all snap-related topics will be what you
should look out for.

The schedule can be found here: http://summit.ubuntu.com/

If you want to subscribe to sessions, register here:
http://summit.ubuntu.com/uos-1611/registration/

Looking forward to seeing you there tomorrow and on Wednesday!

Have a great day,
 Daniel

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Feedback and requests from the syncthing snap

[Leo Arias]

Hello dear snapcraft,

I have been working with the syncthing main dev, Jakob Borg, to make a
syncthing snap. If you want to join the early adopters, $ sudo snap install
syncthing --edge

He has been really nice, digging into snaps and providing valuable
feedback. We have something that works, but there are some rough edges.

One small detail that will cause pain to the syncthing users is that $HOME
is assigned to $SNAP_USER_DATA. In a service to sync files, you are usually
synchronizing things from your user home. Wouldn't it make sense to keep
the real user $HOME if the command has the home plug?
There is a section on the syncthing interface where you can type ~, and
that's expanded to your home. It's both unexpected and uncomfortable to get
that expanded to /home/elopio/snap/syncthing/common.

One big detail that I don't know how to solve is that syncthing is usually
autostarted as a user service, not a system wide service running as root.
How are we going to support this use case?

And finally, more like a general roadmap request/question: The home
interfaces is not enough for this application. You might want to
synchronize something in /media, a different partition, or any other file
that's accessible by the user. After talking with Jacob I realized that the
synchronization story is similar to the one for editors, because you might
want to touch any file in your system, including dotfiles. It would be nice
to get an explanation of how we plan to support these stories with snaps.

pura vida.
Let me know if the syncthing snap works for you.
-- 
¡paz y baile!
http://www.ubuntu.com
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Nand flash booting.

[Oliver Grawert]

hi,
On Mo, 2016-11-14 at 01:21 +, Daniel Toussaint wrote:
> I am working on a board similar to Beaglebone Black, however instead
> of SD/eMMC it is booting from NAND flash directly. As far as I can
> see in the documentation there is no way yet to boot a Snappy image
> in this fashion, is support for this planned ? Is there anything I
> can do to help out with that ?
> 
> Meanwhile, I am considering using the Yocto version of snapcraft to
> package the apps, so that we can later migrate to from the current
> Yocto image to Snappy. 
> 
> Thanks for your comments.
> 
currently the boot process relies heavily on filesystem labels for
finding the various (namely system-boot and writable) partitions. 

do your NAND devices expose labels you set in /dev/disk/by-label ? 

if thats the case it might work to use ubuntu-image with the --workdir
option which keeps the different partition images around in the
specified dir. you could then just grab them from there and flash then
to the respective NAND pratitions.

if the labels are not exposed this will need a bunch of changes in the
code to allow some overrides (i.e. via kernel cmdline options), for
this we will need a wishlist bug as the first step :)

ciao
oli



signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Issues installing services in classic mode on Ubuntu core

[Oliver Grawert]

hi,
On Mo, 2016-11-14 at 08:01 -0500, MikeB wrote:
> 
> Are there any special restrictions on systemd services running in
> Classic mode?
> 
yes, by security policy we do not allow any services to run in classic
by default, you should be able to manually start it when doing
development inside the classic dimension but they will never auto-start 
 on boot (if the manual starting does not work this is a bug though)

ciao
oli

signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cliqz Snap

[Didier Roche]

Le 14/11/2016 à 15:13, Chris a écrit :
> On Mon, 2016-11-14 at 09:11 +0100, Didier Roche wrote:
>> Le 13/11/2016 à 19:04, Chris a écrit :
>>> On Sun, 2016-11-13 at 09:17 -0600, Chris wrote:
 On Sun, 2016-11-13 at 10:41 +0800, XiaoGuo Liu wrote:
> Hi Chris,
>
> You may find the tips at https://github.com/snapcore/snapd/wiki
> /Sec
> ur
> ity. You may use the command like:
>
> $ scmp_sys_resolver 983045
> set_tls
> to find out the security violation.
>
> Best regards,
> XiaoGuo
>
 Thank you XiaoGuo, so in my case I have syscall=272. Running 

 chris@localhost:~$ scmp_sys_resolver 272
 unshare

 I've installed snappy-debug but can't seem to get any kind of
 output
 when run. Maybe I'm using the wrong commands?

>>> Replying to my own post. I wasn't running the snap whenever I ran
>>>
>>> sudo snappy-debug.security scanlog --all-entries cliqz
>>>
>>> Once I executed the snap from the menu with the above running I got
>>>
>>> chris@localhost:~$ sudo snappy-debug.security scanlog --all-entries
>>> cliqz
>>> kernel.printk_ratelimit = 0
>>> = Seccomp =
>>> Time: Nov 13 11:49:59
>>> Log: auid=1000 uid=1000 gid=1000 ses=3 pid=29796 comm="cliqz"
>>> exe="/snap/cliqz/6/opt/CLIQZ/CLIQZ" sig=31 arch=c03e
>>> 272(unshare)
>>> compat=0 ip=0x7ffacd899c19 code=0x0
>>> Syscall: unshare
>>>
>>> So, now it seems as there is a seccomp violation stopping the snap
>>> from
>>> running, at least that's what it appears to me to be. Where would I
>>> go
>>> from here? Contact the snap author?
>> Indeed, the snap author didn't set the confinement rules on his app.
>> The
>> snap should then be in devmode (but not published in the stable
>> channel), to not create user frustration executing something which
>> fails.
>>
>> Do you mind contacting upstream so that they work on confinement?
>> Thanks!
>> Didier
>>
> Hello Didier, do you mean to contact the author?
Hey Chris, indeed,

>  I did go to the
> support page and asked about the snap package not working and I
> received the below in reply, not being able to read German I 'think' it
> just points me to a link for support and their blog.
>
> Hallo Cpollock,
>
> deine Anfrage hat den CLIQZ Support erreicht. Unser Ziel ist es, dir so
> schnell wie möglich zu antworten. Das wird nicht allzu lange dauern,
> versprochen.
>
> In der Zwischenzeit kannst du mal in unsere FAQs schauen: https://cliqz
> .com/support
>
> Und kennst du schon unseren Blog? Schau mal hier: https://cliqz.com/abo
> utus/blog
>
> Danke für deine Geduld. Wir melden uns bald wieder bei dir!
>
> Der CLIQZ Support
>
> The support link takes me to the same place where I had said the snap
> doesn't work, I didn't see anything in the blog link about the snap
> package.

Yeah, my little remaining knowledge of German classes leads to the same
conclusion than yours.
Any native speaker here to help us by any chance? :)

Cheers,
Didier

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cliqz Snap

[Chris]

On Mon, 2016-11-14 at 09:11 +0100, Didier Roche wrote:
> Le 13/11/2016 à 19:04, Chris a écrit :
> > 
> > On Sun, 2016-11-13 at 09:17 -0600, Chris wrote:
> > > 
> > > On Sun, 2016-11-13 at 10:41 +0800, XiaoGuo Liu wrote:
> > > > 
> > > > Hi Chris,
> > > > 
> > > > You may find the tips at https://github.com/snapcore/snapd/wiki
> > > > /Sec
> > > > ur
> > > > ity. You may use the command like:
> > > > 
> > > > $ scmp_sys_resolver 983045
> > > > set_tls
> > > > to find out the security violation.
> > > > 
> > > > Best regards,
> > > > XiaoGuo
> > > > 
> > > Thank you XiaoGuo, so in my case I have syscall=272. Running 
> > > 
> > > chris@localhost:~$ scmp_sys_resolver 272
> > > unshare
> > > 
> > > I've installed snappy-debug but can't seem to get any kind of
> > > output
> > > when run. Maybe I'm using the wrong commands?
> > > 
> > Replying to my own post. I wasn't running the snap whenever I ran
> > 
> > sudo snappy-debug.security scanlog --all-entries cliqz
> > 
> > Once I executed the snap from the menu with the above running I got
> > 
> > chris@localhost:~$ sudo snappy-debug.security scanlog --all-entries
> > cliqz
> > kernel.printk_ratelimit = 0
> > = Seccomp =
> > Time: Nov 13 11:49:59
> > Log: auid=1000 uid=1000 gid=1000 ses=3 pid=29796 comm="cliqz"
> > exe="/snap/cliqz/6/opt/CLIQZ/CLIQZ" sig=31 arch=c03e
> > 272(unshare)
> > compat=0 ip=0x7ffacd899c19 code=0x0
> > Syscall: unshare
> > 
> > So, now it seems as there is a seccomp violation stopping the snap
> > from
> > running, at least that's what it appears to me to be. Where would I
> > go
> > from here? Contact the snap author?
> Indeed, the snap author didn't set the confinement rules on his app.
> The
> snap should then be in devmode (but not published in the stable
> channel), to not create user frustration executing something which
> fails.
> 
> Do you mind contacting upstream so that they work on confinement?
> Thanks!
> Didier
> 
Hello Didier, do you mean to contact the author? I did go to the
support page and asked about the snap package not working and I
received the below in reply, not being able to read German I 'think' it
just points me to a link for support and their blog.

Hallo Cpollock,

deine Anfrage hat den CLIQZ Support erreicht. Unser Ziel ist es, dir so
schnell wie möglich zu antworten. Das wird nicht allzu lange dauern,
versprochen.

In der Zwischenzeit kannst du mal in unsere FAQs schauen: https://cliqz
.com/support

Und kennst du schon unseren Blog? Schau mal hier: https://cliqz.com/abo
utus/blog

Danke für deine Geduld. Wir melden uns bald wieder bei dir!

Der CLIQZ Support

The support link takes me to the same place where I had said the snap
doesn't work, I didn't see anything in the blog link about the snap
package.

Chris

-- 
Chris
KeyID 0xE372A7DA98E6705C
31.11972; -97.90167 (Elev. 1092 ft)
08:00:28 up 4 days, 12:28, 1 user, load average: 0.16, 0.25, 0.47
Ubuntu 16.04.1 LTS, kernel 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 
UTC 2016


signature.asc
Description: This is a digitally signed message part
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Is there any guidance/document about how to write App-provided slots

[Enwei Zhang]

Yes, you are right Simon. I am clear now.
Thanks a lot.

Br
Enwei

On Mon, Nov 14, 2016 at 9:29 PM, Simon Fels 
wrote:

> On 14.11.2016 11:56, Enwei Zhang wrote:
> > Thanks David. Did you forget to add Morphis and Zyga? :)
> > Loop Simon.
> > Simon told me here is the latest bluez snap,
> > https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez
> >  snaps/+git/bluez>
> > Simon told me that bluez snap only declares bluez slot in its
> > snapcraft.yaml.
> >
> > IMHO, after the bluez snap declares "bluez" slot in snapcraft.yaml, it
> > will have *bluezPermanentSlotAppArmor* capability defined in
> > https://github.com/snapcore/snapd/blob/master/interfaces/
> builtin/bluez.go#L28
> >  builtin/bluez.go#L28>
> > So it seems to me by defining "bluez" slot, the bluez snap have more
> > power/permissions to do some privileged work,
> > *but* it doesn't *provide* anything to other snaps. From my experiment,
> > if a new snap connects to the bluez slot in bluez snap, the new snap
> > will not get the extra permissions.
>
> The connecting snap (the plug side) will get the bluezConnectedPlug
> snippets from the interface definitions which actually allow the
> application to talk to bluez over dbus. So the bluez snap provides
> something to other services, a dbus service.
>
> If you want to know more in deep things about interfaces and how they
> work have a look at Zygmunds great post about how to write an interface
> at
> http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
> It will tell about all the details and the different snippets you can use.
>
> regards,
> Simon
>
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Is there any guidance/document about how to write App-provided slots

[Simon Fels]

On 14.11.2016 11:56, Enwei Zhang wrote:
> Thanks David. Did you forget to add Morphis and Zyga? :)
> Loop Simon.
> Simon told me here is the latest bluez snap,
> https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez
> 
> Simon told me that bluez snap only declares bluez slot in its
> snapcraft.yaml.
> 
> IMHO, after the bluez snap declares "bluez" slot in snapcraft.yaml, it
> will have *bluezPermanentSlotAppArmor* capability defined in
> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/bluez.go#L28
> 
> So it seems to me by defining "bluez" slot, the bluez snap have more
> power/permissions to do some privileged work,
> *but* it doesn't *provide* anything to other snaps. From my experiment,
> if a new snap connects to the bluez slot in bluez snap, the new snap
> will not get the extra permissions.

The connecting snap (the plug side) will get the bluezConnectedPlug
snippets from the interface definitions which actually allow the
application to talk to bluez over dbus. So the bluez snap provides
something to other services, a dbus service.

If you want to know more in deep things about interfaces and how they
work have a look at Zygmunds great post about how to write an interface
at
http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
It will tell about all the details and the different snippets you can use.

regards,
Simon


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cross platform snap creation?

[Mark Shuttleworth]

Hi Peter

While snaps are currently Linux-only, there is good progress on a range
of related fronts in the Windows Subsystem for Linux ("Ubuntu for
Windows") which makes it plausible that snaps could be built on a future
Windows as easily as on native Linux today.

On Linux, currently most snaps are built on Ubuntu. They don't have to
be - the format doesn't require it, and those snaps can run on other
distributions even if built on Ubuntu - but the main 'snap assembly'
tool is snapcraft which currently assumes Ubuntu. At the most recent
gathering of snap developers we figured out a path to have diverse base
Linuxes (say a Fedora core library set) as well as to have snapcraft
building on a range of Linux distros, but I can't say when that will be
in place.

Electron is *great* and we'd like to have a standard way for folks using
electron to publish a snap. One of the nice things about snaps is that
you have an 'edge' channel into which you can release daily builds from
your CI, and highly engaged / crazy community members and developers can
thus easily run the trunk. Same goes for beta and release candidate, the
channel system is very useful.

Mark

On 13/11/16 14:58, Peter Uithoven wrote:
> Hi folks,
>
> This is a question on behalf of the people behind Electron: Is is
> possible to create snaps from other platforms than Linux? Would this
> be possible through a Docker container? Are there docs on this?
>
> https://github.com/electron-userland/electron-packager/issues/525#issuecomment-260109515
> https://github.com/electron-userland/electron-builder/issues/509
>
> Electron enables the creation of cross platform application using web
> technologies (javascript, css, html, Node.js etc). The Atom editor for
> example is build with it.
> http://electron.atom.io/
>
> Thanks in advance,
> Peter Uithoven
>
>

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Issues installing services in classic mode on Ubuntu core

[MikeB]

I'm trying to install a Debian package that contains a system service
in Classic mode on Ubuntu core.

* I've added a case to /usr/sbin/polivy-rc.d to return 104 for the service.
* The service file is installed at /lib/systemd/system/foo.service.
* There is a dropin file for the service at /etc/systemd/system/foo.d/foo.conf.

I see the following when I install the package using dpkg.

invoke-rc.d: foo.service doesn't exist but the upstart job does.
Nothing to start or stop until a systemd or init job is present.
Failed to get unit file state for foo.service: No such file or directory
foo.service is a disabled or a static unit, not starting it.

Are there any special restrictions on systemd services running in Classic mode?

Regards, Mike

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cross platform snap creation?

[Didier Roche]

Le 14/11/2016 à 13:24, Érico P a écrit :
>
> Didier,
>
> Peter asked about building snaps from other systems, not running them.
> I think the idea would be to automate the building process of an app
> in Electron for multiple platforms. Forgive me if you got right and I
> just didn't understood what you have said.
>

Oh indeed, rereading, that's more than possible I misunderstood the
request this morning :)

I guess using a docker container like didrocks/snapcraft from dockerhub,
which always contain latest released version of snapcraft (based on
16.04 LTS).
Tell me if that suits your need Peter!
Didier
>
> Em 14 de nov de 2016 7:32 AM, "Didier Roche"  > escreveu:
>
> Le 13/11/2016 à 15:58, Peter Uithoven a écrit :
>> Hi folks,
>>
>> This is a question on behalf of the people behind Electron: Is is
>> possible to create snaps from other platforms than Linux? Would
>> this be possible through a Docker container? Are there docs on this?
>>
>> 
>> https://github.com/electron-userland/electron-packager/issues/525#issuecomment-260109515
>> 
>> 
>> https://github.com/electron-userland/electron-builder/issues/509
>> 
>>
>> Electron enables the creation of cross platform application using
>> web technologies (javascript, css, html, Node.js etc). The Atom
>> editor for example is build with it.
>> http://electron.atom.io/
>
> Hey Peter,
>
> I don't think this is planned as of today, however, seeing snaps
> working on the Linux Windows subsystem would be indeed really
> interesting! The issue with elecctron apps is that they touch a
> big part of the technical stack (graphics, access to various
> files, javascript sandboxed engine…). I don't think that will be
> the easiest one.
>
> I think running some lxd ubuntu-core system containers would help
> at least as a first steps on supported platform for web service.
> Cheers,
> Didier
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> 
>
>
>

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cross platform snap creation?

[Érico P]

Didier,

Peter asked about building snaps from other systems, not running them. I
think the idea would be to automate the building process of an app in
Electron for multiple platforms. Forgive me if you got right and I just
didn't understood what you have said.

Em 14 de nov de 2016 7:32 AM, "Didier Roche"  escreveu:

> Le 13/11/2016 à 15:58, Peter Uithoven a écrit :
>
> Hi folks,
>
> This is a question on behalf of the people behind Electron: Is is
> possible to create snaps from other platforms than Linux? Would this be
> possible through a Docker container? Are there docs on this?
>
> https://github.com/electron-userland/electron-packager/
> issues/525#issuecomment-260109515
> https://github.com/electron-userland/electron-builder/issues/509
>
> Electron enables the creation of cross platform application using web
> technologies (javascript, css, html, Node.js etc). The Atom editor for
> example is build with it.
> http://electron.atom.io/
>
>
> Hey Peter,
>
> I don't think this is planned as of today, however, seeing snaps working
> on the Linux Windows subsystem would be indeed really interesting! The
> issue with elecctron apps is that they touch a big part of the technical
> stack (graphics, access to various files, javascript sandboxed engine…). I
> don't think that will be the easiest one.
>
> I think running some lxd ubuntu-core system containers would help at least
> as a first steps on supported platform for web service.
> Cheers,
> Didier
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Packaging nodejs apps

[Didier Roche]

Le 14/11/2016 à 12:19, Stephen Stewart a écrit :
> On Mon, Nov 14, 2016 at 10:34 AM Didier Roche  > wrote:
>
> Le 14/11/2016 à 10:55, Stephen Stewart a écrit :
> > Hi,
> >
> > While looking into a nodejs/yarn plugin I wondered if I could make a
> > yarn snap (not plugin), and simply define nodejs and yarn as parts,
> > use dump plugin and be done, no plugin required:
> >
> > "Parts 'yarn' and 'node' have the following file paths in common
> which
> > have different contents:"
> >
> > https://pastebin.canonical.com/170573/
> >
> > So I am wondering why doesn't this just work?
>
> Hey Stephen,
>
>
> Hi Didier,
>  
>
>
> It doesn't work simply because snapcraft doesn't know which file from
> which part to ship. You have common files between parts with different
> contents (as the error message underline). Which one of yarn's or
> node's
> README.md should be included for instance?
>
>
> Fair enough, but ...
>  
>
> >
> > It seems like name collisions in parts might be a common enough
> thing,
> > and I couldn't quite understand the help docs around filesets and
> > organise to see a nice way to make this work for me across projects.
>
> I guess http://snapcraft.io/docs/build-snaps/advanced-features
> will be a
> better example.
> Basically, you define in one parts a fileset with:
> filesets:
>   exclude:
> - -README.md
> - - LICENSE
> - -lib/constants.js
> (note the - to say to exclude those 3 files).
>
>
> ... sure, but both parts need `lib/constants.js`; I can't exclude
> lib/constants for one part and hope that my snap will work, can I?
>
> I feel like I'm missing something really obvious here :(

Ah, in that case, it means that you need to install both nodejs and yarn
(I don't know the latter) in different install path, and have wrappers
so that they know how to find each other IMHO.

You can use organize to rename a directory in the stage and prime
directory, that would be a good way to install in different path with
the dump plugin.
However, you will need to provide those wrappers scripts/glue code so
that one can know about the other.

Cheers,
Didier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Packaging nodejs apps

[Stephen Stewart]

On Mon, Nov 14, 2016 at 10:34 AM Didier Roche  wrote:

> Le 14/11/2016 à 10:55, Stephen Stewart a écrit :
> > Hi,
> >
> > While looking into a nodejs/yarn plugin I wondered if I could make a
> > yarn snap (not plugin), and simply define nodejs and yarn as parts,
> > use dump plugin and be done, no plugin required:
> >
> > "Parts 'yarn' and 'node' have the following file paths in common which
> > have different contents:"
> >
> > https://pastebin.canonical.com/170573/
> >
> > So I am wondering why doesn't this just work?
>
> Hey Stephen,
>

Hi Didier,


>
> It doesn't work simply because snapcraft doesn't know which file from
> which part to ship. You have common files between parts with different
> contents (as the error message underline). Which one of yarn's or node's
> README.md should be included for instance?
>

Fair enough, but ...


> >
> > It seems like name collisions in parts might be a common enough thing,
> > and I couldn't quite understand the help docs around filesets and
> > organise to see a nice way to make this work for me across projects.
>
> I guess http://snapcraft.io/docs/build-snaps/advanced-features will be a
> better example.
> Basically, you define in one parts a fileset with:
> filesets:
>   exclude:
> - -README.md
> - - LICENSE
> - -lib/constants.js
> (note the - to say to exclude those 3 files).
>

... sure, but both parts need `lib/constants.js`; I can't exclude
lib/constants for one part and hope that my snap will work, can I?

I feel like I'm missing something really obvious here :(


>
> then, in the same part you want to exclude those files:
> stage: [$exclude]
> snap: [$exclude]
>
> And you should be done!
> Didier
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Is there any guidance/document about how to write App-provided slots

[Enwei Zhang]

Thanks David. Did you forget to add Morphis and Zyga? :)
Loop Simon.
Simon told me here is the latest bluez snap,
https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez

Simon told me that bluez snap only declares bluez slot in its
snapcraft.yaml.

IMHO, after the bluez snap declares "bluez" slot in snapcraft.yaml, it will
have *bluezPermanentSlotAppArmor* capability defined in
https://github.com/snapcore/snapd/blob/master/interfaces/
builtin/bluez.go#L28
So it seems to me by defining "bluez" slot, the bluez snap have more
power/permissions to do some privileged work,
*but* it doesn't *provide* anything to other snaps. From my experiment, if
a new snap connects to the bluez slot in bluez snap, the new snap will not
get the extra permissions.

Thanks again.

Br
Enwei
On Thu, Nov 10, 2016 at 1:34 AM, David Callé  wrote:

> On 09/11/2016 10:47, Enwei Zhang wrote:
>
> Hello,
> For now, all slots are provided by ubuntu-core. I saw the concept of
> App-provided slots from
> https://github.com/snapcore/snapd/blob/master/interfaces/bui
> ltin/basedeclaration.go#L72
> But I didn't find any guidance/document about how to do that.
> Could you please help advise?
>
>
> I don't think we have a document for this yet, except the general
> interfaces overview that only mentions it as a possibility (
> http://snapcraft.io/docs/core/interfaces ).
>
> As far as I know, only two snaps are providing their own slots: the core
> snap and bluez.
> If it can help in the meantime, the source code I've found for the bluez
> snap is at: http://bazaar.launchpad.net/~bluetooth/bluez/snap-core-rolli
> ng/files
>
>
CCing Morphis and Zyga for more information.
>
> Cheers,
> David
>
> Thanks so much.
>
> Br
> Enwei
>
>
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
> an/listinfo/snapcraft
>
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Packaging nodejs apps

[Didier Roche]

Le 14/11/2016 à 10:55, Stephen Stewart a écrit :
> Hi,
>
> While looking into a nodejs/yarn plugin I wondered if I could make a
> yarn snap (not plugin), and simply define nodejs and yarn as parts,
> use dump plugin and be done, no plugin required:
>
> "Parts 'yarn' and 'node' have the following file paths in common which
> have different contents:"
>
> https://pastebin.canonical.com/170573/
>
> So I am wondering why doesn't this just work?

Hey Stephen,

It doesn't work simply because snapcraft doesn't know which file from
which part to ship. You have common files between parts with different
contents (as the error message underline). Which one of yarn's or node's
README.md should be included for instance?
>
> It seems like name collisions in parts might be a common enough thing,
> and I couldn't quite understand the help docs around filesets and
> organise to see a nice way to make this work for me across projects.

I guess http://snapcraft.io/docs/build-snaps/advanced-features will be a
better example.
Basically, you define in one parts a fileset with:
filesets:
  exclude:
- -README.md
- - LICENSE
- -lib/constants.js
(note the - to say to exclude those 3 files).

then, in the same part you want to exclude those files:
stage: [$exclude]
snap: [$exclude]

And you should be done!
Didier


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Packaging nodejs apps

[Stephen Stewart]

Hi,

While looking into a nodejs/yarn plugin I wondered if I could make a yarn
snap (not plugin), and simply define nodejs and yarn as parts, use dump
plugin and be done, no plugin required:

"Parts 'yarn' and 'node' have the following file paths in common which have
different contents:"

https://pastebin.canonical.com/170573/

So I am wondering why doesn't this just work?

It seems like name collisions in parts might be a common enough thing, and
I couldn't quite understand the help docs around filesets and organise to
see a nice way to make this work for me across projects.

Many thanks,
Stephen
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Symlink to snapcraft apps no longer working

[Didier Roche]

Le 14/11/2016 à 10:41, Zygmunt Krynicki a écrit :
>> Wiadomość napisana przez Martin Winter  w 
>> dniu 11.11.2016, o godz. 10:54:
>>
>> Not sure when this (recently) changed.
>>
>> All apps as defined by a snap are prefixed with the snap name
>>
>> Ie, I have under apps a “vtysh” defined, which then ends up as
>> quagga.vtysh (for the quagga snap).
>>
>> So far no issue.
>>
>> Now, a few weeks/months back, I was able to create a symlink
>> with “vtysh” pointing to “quagga.vtysh” and then could use the same
>> simple “vtysh” command to call the app. (same as traditional package 
>> installs)
>
> I think this is related to snap-run. You may have noticed that the 
> quagga.vtysh itself is a symlink to /usr/bin/snap. The new „snap run” command 
> understands symlinks and uses this as a hint on what to run.

Oh, good catch! Any way to get that fixed?
Martin, do you mind filing a bug?

Cheers,
Didier

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: snapd-glib 1.3 released

[Zygmunt Krynicki]

> Wiadomość napisana przez Robert Ancell  w dniu 
> 14.11.2016, o godz. 04:30:
> 
> Overview of changes in snapd-glib 1.3

Congratulations :-)

Speaking about releases, we have a dedicated list for announcing releases, the 
snapcraft-relea...@snapcraft.io list.
Could you please cross-send your future release announcements?

Best regards
ZK


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Symlink to snapcraft apps no longer working

[Zygmunt Krynicki]

> Wiadomość napisana przez Martin Winter  w dniu 
> 11.11.2016, o godz. 10:54:
> 
> Not sure when this (recently) changed.
> 
> All apps as defined by a snap are prefixed with the snap name
> 
> Ie, I have under apps a “vtysh” defined, which then ends up as
> quagga.vtysh (for the quagga snap).
> 
> So far no issue.
> 
> Now, a few weeks/months back, I was able to create a symlink
> with “vtysh” pointing to “quagga.vtysh” and then could use the same
> simple “vtysh” command to call the app. (same as traditional package installs)


I think this is related to snap-run. You may have noticed that the quagga.vtysh 
itself is a symlink to /usr/bin/snap. The new „snap run” command understands 
symlinks and uses this as a hint on what to run.


> 
> Link had to be done outside snap, but it allowed to keep all scripts
> unchanged.
> 
> At the current snapd version (2.16ubuntu3), this does no longer work.
> 
> all apps ends up as a symlink to the same /usr/bin/snap binary and somehow the
> binary seems to fail to call the correct app if there is another symlink
> used.
> 
> Is there a way to get symlinks to still work as before?
> 
> - Martin
> 
> 
> -- 
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/snapcraft


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Symlink to snapcraft apps no longer working

[Didier Roche]

Le 11/11/2016 à 10:54, Martin Winter a écrit :
> Not sure when this (recently) changed.
>
> All apps as defined by a snap are prefixed with the snap name
>
> Ie, I have under apps a “vtysh” defined, which then ends up as
> quagga.vtysh (for the quagga snap).
>
> So far no issue.
>
> Now, a few weeks/months back, I was able to create a symlink
> with “vtysh” pointing to “quagga.vtysh” and then could use the same
> simple “vtysh” command to call the app. (same as traditional package
> installs)
>
> Link had to be done outside snap, but it allowed to keep all scripts
> unchanged.
>
> At the current snapd version (2.16ubuntu3), this does no longer work.
>
> all apps ends up as a symlink to the same /usr/bin/snap binary and
> somehow the
> binary seems to fail to call the correct app if there is another symlink
> used.
>
> Is there a way to get symlinks to still work as before?
>
Hey Martin,

I don't see what your issue is, nothing has changed and this isn't
linked at all to snapd but rather a traditional linux feature.

What commands are you running?
$ ln -s /snap/bin/gtk3-demo foo
$ ./foo
works here
$ ls -l foo
lrwxrwxrwx 1 didrocks didrocks 19 nov.  14 10:37 foo -> /snap/bin/gtk3-demo

As well.
Please provide debug output.

Cheers,
Didier

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Provisional snap for DUB (D language package/build manager)

[Didier Roche]

Le 13/11/2016 à 18:09, Joseph Rushton Wakeling a écrit :
> On 13/11/16 10:11, Joseph Rushton Wakeling wrote:
>> On 03/11/16 11:49, Joseph Rushton Wakeling wrote:
>>> On 01/11/16 22:43, Sergio Schvezov wrote:
 If this is the problem and you can patch the software then removing
 the chown
 could work, I am CCing Jamie for other ideas that could come up.
>>
>> Looking at the dub source code, it seems that the actual build --
>> i.e. the
>> compiler call that generates the binary -- writes to a temporary
>> .dub/ directory
>> created in the project tree, and the generated files are then copied
>> to the
>> user-perceived output location, with chown and chmod calls to
>> preserve the
>> permissions:
>> https://github.com/dlang/dub/blob/v1.0.0/source/dub/internal/vibecompat/core/file.d#L126-L128
>>
>
> OK, upstream accepted my patch to deal with this.  The current state
> of my external snap package, described here:
> https://github.com/WebDrake/dub.snap/pull/1
>
> ... now works with some essential basics:
>
>   * it can compile a program that has no dependencies;
>
>   * it can download dub packages from https://code.dlang.org/ and
> incorporate
> them into a project.
>
> The major TODOs would be:
>
>   * ensure the dub plugin downloads an upstream dub rather than
> relying on
> ubuntu packages;
>
>   * separate the D compiler from the snap, allowing dub to use any
> compiler
> available on the host system (whether installed as a system
> package or
> as a snap package);
>
>   * find a way for it to access system libraries so as to build dub
> packages
> that have these as dependencies.
>
> The latter two I presume come down to the known issue about how to
> make host resources available to a snap in a safe manner, but I'd be
> interested in any thoughts on whether the D compiler issue might be
> achieved any more easily.
>

I guess for now, the compiler part (and access to system libraries)
should be part of an interface. I'm CCing Jamie to see if he has any
thoughts on that.

Didier


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cross platform snap creation?

[Didier Roche]

Le 13/11/2016 à 15:58, Peter Uithoven a écrit :
> Hi folks,
>
> This is a question on behalf of the people behind Electron: Is is
> possible to create snaps from other platforms than Linux? Would this
> be possible through a Docker container? Are there docs on this?
>
> https://github.com/electron-userland/electron-packager/issues/525#issuecomment-260109515
> https://github.com/electron-userland/electron-builder/issues/509
>
> Electron enables the creation of cross platform application using web
> technologies (javascript, css, html, Node.js etc). The Atom editor for
> example is build with it.
> http://electron.atom.io/

Hey Peter,

I don't think this is planned as of today, however, seeing snaps working
on the Linux Windows subsystem would be indeed really interesting! The
issue with elecctron apps is that they touch a big part of the technical
stack (graphics, access to various files, javascript sandboxed engine…).
I don't think that will be the easiest one.

I think running some lxd ubuntu-core system containers would help at
least as a first steps on supported platform for web service.
Cheers,
Didier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Provisional snap for DUB (D language package/build manager)

[Zygmunt Krynicki]

> Wiadomość napisana przez Joseph Rushton Wakeling 
>  w dniu 01.11.2016, o godz. 22:31:
> 
> On 27/10/16 22:13, Joseph Rushton Wakeling wrote:
>> On 27/10/16 08:37, Didier Roche wrote:
>>> I would look at /var/log/syslogs. Apparmor and seccomp denials are
>>> listed there. Note that if you didn't already, you should really start
>>> developping your snap in devmode. That way, it will get confinment out
>>> of the equasion to get your relocatable code and dependencies working.
>>> Then, we can turn on confinement and figure out those issues to be able
>>> to publish in the stable channel.
>> 
>> Yea, I probably should have started with devmode.  Thanks for the advice 
>> about
>> syslogs; I'll check it out and see what I can find.
> 
> OK, so it looks like apparmor was indeed responsible.  The loglines in 
> question:
> 
> Oct 30 17:50:50 computername kernel: [ 9532.992875] audit: type=1400 
> audit(1477846250.853:43): apparmor="DENIED" operation="link" 
> profile="snap.dub.dub" 
> name="/home/username/code/D/dgraph/build/dgraph_graphtest" pid=22464 
> comm="dub" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 
> target="/home/username/code/D/dgraph/.dub/build/application-debug-linux.posix-x86_64-ldc_0-B7AFC7F4AA486AA98C5445F91F5653DB/dgraph_graphtest”

This is a link (or symlink, not sure) operation.

> Oct 30 17:50:50 computername kernel: [ 9533.035303] audit: type=1326 
> audit(1477846250.897:44): auid=4294967295 uid=1000 gid=1000 ses=4294967295 
> pid=22464 comm="dub" exe="/snap/dub/x1/bin/dub" sig=31 arch=c03e 
> syscall=92 compat=0 ip=0x7f9b72d13717 code=0x0

This seems to be chown(1)

> 
> I'm not experienced with apparmor, so could someone explain exactly what this 
> means?  (I get the general idea, but the specifics would be useful to 
> understand precisely.)
> 
> In particular, is there an obvious reason why this might be showing up with 
> the dub snap, when the earlier ldc2 snap didn't have this problem?  I would 
> guess because the ldc2 instance used by the snap-packaged dub is internal to 
> the snap and does not benefit from the home-directory interface that dub 
> itself gets?
> 
> Setting the containment to devmode removes the problem, but it would be nice 
> to be able to have strict confinement earlier rather than later.
> 
> -- 
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/snapcraft


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: configure hook

[Didier Roche]

Le 14/11/2016 à 10:04, Boris Rybalkin a écrit :
>
> Will it help if I upgrade to 16.10?
>
No, it contains the same version: https://launchpad.net/ubuntu/+source/snapd
Try the ubuntu core vm is the only easy way for you to progress there.

> Also what is really relation between snapd and ubuntu core on amd64?
>

snapd is part of the core snap. snapd from the core snap is running on
ubuntu core, snapd from the ubuntu package is running on the desktop.
(the REEXEC plan has been disabled some months ago, due to some issues IIRC)

Didier

>
> On 14 Nov 2016 8:01 am, "Didier Roche"  > wrote:
>
> Le 12/11/2016 à 17:45, Boris Rybalkin a écrit :
>>
>> Still struggling with hooks, they are not executed on install.
>>
>> snap$ snap run --hook=configure syncloud-platform
>> cannot snap-exec: cannot find hook "configure" in "syncloud-platform"
>> and even 'snap run --hook=configure mysnap' silently returns.
>>
>> I am using:
>> Ubuntu 16.04
>> snapd 2.16ubuntu3
>>
>> Does it have hook support?
>>
>
> It's supposed to have some, but IIRC, Kyle found some issues with
> it. Definitively, this version doesn't run the hook on install though.
>
>> According to this test they should even fail install if broken:
>> 
>> https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c8fc43051500bd6c3fda/tests/main/snap-set/task.yaml
>> 
>> 
>>
>> As suggested I am copying meta/hooks to prime dir after running
>> snapcraft prime  and then running snapcraft snap.
>>
>> This bug says it is probably not yet available in edge, how do I
>> switch channel?
>>
>> https://bugs.launchpad.net/snappy/+bug/1636931
>> 
>>
>
> As I said in some email above, the easiest path to test it is to
> use an ubuntu core VM (until a new snapd release is out for Ubuntu
> 16.04 desktop, CCing Michael to know when the next snapd hits
> stable + SRU published).
> Cheers,
> Didier
>
>> Thank you.
>>
>>
>> On 9 Nov 2016 09:21, "Didier Roche" > > wrote:
>>
>> Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>>>
>>> One more question, should I expect a hook to run inside my
>>> snap package and use relative shebang like this?
>>>
>>> #!python/bin/python
>>>
>>> Assuming I am packaging python with my snap.
>>>
>> hooks are run using the same context than any "commands:" in
>> your snap.
>>
>> As long as we don't have snapcraft support, I don't think you
>> will have the override in PYTHONPATH, PYTHONHOME and such
>> (and I don't know if that's planned), but I'll give it a try
>> later this week or early new one to have great python hooks
>> examples.
>>
>> If you beat me to it, do not hesitate to report your results
>> here!
>>
>>> Thank you very much for your replies!
>>>
>>
>> My pleasure :)
>>
>>
>>>
>>> On 9 Nov 2016 08:58, "Didier Roche" >> > wrote:
>>>
>>> Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :

 Sorry, I did not get that.

 I am using snapcraft, are you saying that just creating
 hooks/configure is not enaugh?

>>> It should be enough if you ensure it's in your final
>>> snap in meta/hooks/configure. (Look at your prime/
>>> directory).
>>> Enwei was talking about more advanced snapcraft
>>> integration, where you point to a file which is then
>>> copied for you in meta/hooks.
>>>
 Looks like my hook is not executed:
 https://github.com/syncloud/platform/tree/master/snap
 

 Is it possible to debug the execution of snap install?

 I would like to see the state of the snap after it
 failed to start daemons. The only way to see the
 problem is to run journalctl and guess by startup errors.


>>> Yeah, hooks are hard to debug, I filed
>>> *https://bugs.launchpad.net/snappy/+bug/1640114
>>> 
>>> yesterday about this.
>>>
>>> Didier
>>> *
>>>
>>> --
>>> Snapcraft mailing list
>>> Snapcraft@lists.snapcraft.io
>>> 
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>>> 
>>>
>>>
>>>
>>
>>
>> --
>> 

Re: configure hook

[Boris Rybalkin]

Will it help if I upgrade to 16.10?
Also what is really relation between snapd and ubuntu core on amd64?

On 14 Nov 2016 8:01 am, "Didier Roche"  wrote:

> Le 12/11/2016 à 17:45, Boris Rybalkin a écrit :
>
> Still struggling with hooks, they are not executed on install.
>
> snap$ snap run --hook=configure syncloud-platform
> cannot snap-exec: cannot find hook "configure" in "syncloud-platform"
> and even 'snap run --hook=configure mysnap' silently returns.
>
> I am using:
> Ubuntu 16.04
> snapd 2.16ubuntu3
>
> Does it have hook support?
>
>
> It's supposed to have some, but IIRC, Kyle found some issues with it.
> Definitively, this version doesn't run the hook on install though.
>
> According to this test they should even fail install if broken:
> https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c8fc430515
> 00bd6c3fda/tests/main/snap-set/task.yaml
>
> As suggested I am copying meta/hooks to prime dir after running snapcraft
> prime  and then running snapcraft snap.
>
> This bug says it is probably not yet available in edge, how do I switch
> channel?
>
> https://bugs.launchpad.net/snappy/+bug/1636931
>
>
> As I said in some email above, the easiest path to test it is to use an
> ubuntu core VM (until a new snapd release is out for Ubuntu 16.04 desktop,
> CCing Michael to know when the next snapd hits stable + SRU published).
> Cheers,
> Didier
>
> Thank you.
>
> On 9 Nov 2016 09:21, "Didier Roche"  wrote:
>
>> Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>>
>> One more question, should I expect a hook to run inside my snap package
>> and use relative shebang like this?
>>
>> #!python/bin/python
>>
>> Assuming I am packaging python with my snap.
>>
>> hooks are run using the same context than any "commands:" in your snap.
>>
>> As long as we don't have snapcraft support, I don't think you will have
>> the override in PYTHONPATH, PYTHONHOME and such (and I don't know if that's
>> planned), but I'll give it a try later this week or early new one to have
>> great python hooks examples.
>>
>> If you beat me to it, do not hesitate to report your results here!
>>
>> Thank you very much for your replies!
>>
>>
>> My pleasure :)
>>
>>
>>
>> On 9 Nov 2016 08:58, "Didier Roche"  wrote:
>>
>>> Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :
>>>
>>> Sorry, I did not get that.
>>>
>>> I am using snapcraft, are you saying that just creating hooks/configure
>>> is not enaugh?
>>>
>>> It should be enough if you ensure it's in your final snap in
>>> meta/hooks/configure. (Look at your prime/ directory).
>>> Enwei was talking about more advanced snapcraft integration, where you
>>> point to a file which is then copied for you in meta/hooks.
>>>
>>> Looks like my hook is not executed:
>>> https://github.com/syncloud/platform/tree/master/snap
>>>
>>> Is it possible to debug the execution of snap install?
>>>
>>> I would like to see the state of the snap after it failed to start
>>> daemons. The only way to see the problem is to run journalctl and guess by
>>> startup errors.
>>>
>>> Yeah, hooks are hard to debug, I filed
>>>
>>>
>>> *https://bugs.launchpad.net/snappy/+bug/1640114
>>>  yesterday about this.
>>> Didier *
>>>
>>> --
>>> Snapcraft mailing list
>>> Snapcraft@lists.snapcraft.io
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/snapcraft
>>>
>>>
>>
>>
>>
>> --
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/snapcraft
>>
>>
>
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Cliqz Snap

[Didier Roche]

Le 13/11/2016 à 19:04, Chris a écrit :
> On Sun, 2016-11-13 at 09:17 -0600, Chris wrote:
>> On Sun, 2016-11-13 at 10:41 +0800, XiaoGuo Liu wrote:
>>> Hi Chris,
>>>
>>> You may find the tips at https://github.com/snapcore/snapd/wiki/Sec
>>> ur
>>> ity. You may use the command like:
>>>
>>> $ scmp_sys_resolver 983045
>>> set_tls
>>> to find out the security violation.
>>>
>>> Best regards,
>>> XiaoGuo
>>>
>> Thank you XiaoGuo, so in my case I have syscall=272. Running 
>>
>> chris@localhost:~$ scmp_sys_resolver 272
>> unshare
>>
>> I've installed snappy-debug but can't seem to get any kind of output
>> when run. Maybe I'm using the wrong commands?
>>
> Replying to my own post. I wasn't running the snap whenever I ran
>
> sudo snappy-debug.security scanlog --all-entries cliqz
>
> Once I executed the snap from the menu with the above running I got
>
> chris@localhost:~$ sudo snappy-debug.security scanlog --all-entries
> cliqz
> kernel.printk_ratelimit = 0
> = Seccomp =
> Time: Nov 13 11:49:59
> Log: auid=1000 uid=1000 gid=1000 ses=3 pid=29796 comm="cliqz"
> exe="/snap/cliqz/6/opt/CLIQZ/CLIQZ" sig=31 arch=c03e 272(unshare)
> compat=0 ip=0x7ffacd899c19 code=0x0
> Syscall: unshare
>
> So, now it seems as there is a seccomp violation stopping the snap from
> running, at least that's what it appears to me to be. Where would I go
> from here? Contact the snap author?

Indeed, the snap author didn't set the confinement rules on his app. The
snap should then be in devmode (but not published in the stable
channel), to not create user frustration executing something which fails.

Do you mind contacting upstream so that they work on confinement?
Thanks!
Didier

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Nand flash booting.

[Didier Roche]

Le 14/11/2016 à 02:21, Daniel Toussaint a écrit :
> I am working on a board similar to Beaglebone Black, however instead
> of SD/eMMC it is booting from NAND flash directly. As far as I can see
> in the documentation there is no way yet to boot a Snappy image in
> this fashion, is support for this planned ? Is there anything I can do
> to help out with that ?
>
> Meanwhile, I am considering using the Yocto version of snapcraft to
> package the apps, so that we can later migrate to from the current
> Yocto image to Snappy. 
>
> Thanks for your comments.

Oliver (our Bleaglebone Black specialist and image author) should be
able to give some schedule if such feature is planned.
Didier

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: crontab like snaps or interfaces

[Didier Roche]

Le 14/11/2016 à 09:03, Didier Roche a écrit :
> Le 14/11/2016 à 02:29, Enwei Zhang a écrit :
>> Hello,
>> I want to ask if there is any snaps or interfaces that could support
>> crontab or systemd.timer or that kind of timed operations.
>> For example, if my snap uses syslog to save all the logs, how should
>> logrotate work?
>>
>> Thanks so much.
> CCing Gustavo to get some clarification on this.
>
>
Also, please, open a bug on https://launchpad.net/snappy with the exact
use case. I'm unsure if you need an interface for this (interfaces are
between snaps), here it seems you only need systemd timer units and
crontab support (the same way we support services, hooks and such…)


Cheers,

Didier


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: crontab like snaps or interfaces

[Didier Roche]

Le 14/11/2016 à 02:29, Enwei Zhang a écrit :
> Hello,
> I want to ask if there is any snaps or interfaces that could support
> crontab or systemd.timer or that kind of timed operations.
> For example, if my snap uses syslog to save all the logs, how should
> logrotate work?
>
> Thanks so much.

CCing Gustavo to get some clarification on this.


-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: configure hook

[Didier Roche]

Le 12/11/2016 à 17:45, Boris Rybalkin a écrit :
>
> Still struggling with hooks, they are not executed on install.
>
> snap$ snap run --hook=configure syncloud-platform
> cannot snap-exec: cannot find hook "configure" in "syncloud-platform"
> and even 'snap run --hook=configure mysnap' silently returns.
>
> I am using:
> Ubuntu 16.04
> snapd 2.16ubuntu3
>
> Does it have hook support?
>

It's supposed to have some, but IIRC, Kyle found some issues with it.
Definitively, this version doesn't run the hook on install though.

> According to this test they should even fail install if broken:
> https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c8fc43051500bd6c3fda/tests/main/snap-set/task.yaml
>
> As suggested I am copying meta/hooks to prime dir after running
> snapcraft prime  and then running snapcraft snap.
>
> This bug says it is probably not yet available in edge, how do I
> switch channel?
>
> https://bugs.launchpad.net/snappy/+bug/1636931
>

As I said in some email above, the easiest path to test it is to use an
ubuntu core VM (until a new snapd release is out for Ubuntu 16.04
desktop, CCing Michael to know when the next snapd hits stable + SRU
published).
Cheers,
Didier

> Thank you.
>
>
> On 9 Nov 2016 09:21, "Didier Roche"  > wrote:
>
> Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>>
>> One more question, should I expect a hook to run inside my snap
>> package and use relative shebang like this?
>>
>> #!python/bin/python
>>
>> Assuming I am packaging python with my snap.
>>
> hooks are run using the same context than any "commands:" in your
> snap.
>
> As long as we don't have snapcraft support, I don't think you will
> have the override in PYTHONPATH, PYTHONHOME and such (and I don't
> know if that's planned), but I'll give it a try later this week or
> early new one to have great python hooks examples.
>
> If you beat me to it, do not hesitate to report your results here!
>
>> Thank you very much for your replies!
>>
>
> My pleasure :)
>
>
>>
>> On 9 Nov 2016 08:58, "Didier Roche" > > wrote:
>>
>> Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :
>>>
>>> Sorry, I did not get that.
>>>
>>> I am using snapcraft, are you saying that just creating
>>> hooks/configure is not enaugh?
>>>
>> It should be enough if you ensure it's in your final snap in
>> meta/hooks/configure. (Look at your prime/ directory).
>> Enwei was talking about more advanced snapcraft integration,
>> where you point to a file which is then copied for you in
>> meta/hooks.
>>
>>> Looks like my hook is not executed:
>>> https://github.com/syncloud/platform/tree/master/snap
>>> 
>>>
>>> Is it possible to debug the execution of snap install?
>>>
>>> I would like to see the state of the snap after it failed to
>>> start daemons. The only way to see the problem is to run
>>> journalctl and guess by startup errors.
>>>
>>>
>> Yeah, hooks are hard to debug, I filed
>> *https://bugs.launchpad.net/snappy/+bug/1640114
>>  yesterday
>> about this.
>>
>> Didier
>> *
>>
>> --
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> 
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>> 
>>
>>
>>
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> 
>
>
>

-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft