Missing uboot env variables "snap_kernel" & "snap_core" for building an armhf image

[Woodrow Shen]

Hi,

I'm working on port of roseapple-pi (
https://github.com/xapp-le/SnappyUbuntuCore), and after building an image
via ubuntu-image, the new uboot.env modified by snapd can't find the snap
related variables "snap_kernel" & "snap_core". I check the image's content
and then confirm the kernel snap files are included under /var/lib/snapd/
(writable) and system-boot file system. Right now I don't have any idea
about this, anyone can give me a clue ? Thanks.

Woodrow

--
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: Qt 5.7 cloud part now available

[Timo Jyrinki]

Qt 5.8 was easy enough to add so that's now also available with after:
[qt58]. Note that Qt 5.8 is still under active development. The next
planned step for these upstream Qt cloud parts would be offering
prebuilt binaries to cut down the awful build times. Of course if
you're compiling your app snaps in Launchpad you wouldn't notice that
much, but it's still very much a wanted feature.

In other news since people are curious, there is also a shared runtime
of Qt 5.6.1 + Ubuntu libraries like UI Toolkit to be used by apps for
space savings in certain use cases like devices with space
constraints, currently called "ubuntu-qt-runtime" (name TBD). I have
enough testers already so I don't recommend reaching out for it yet :)
But if you are curious, it is installable from
https://code.launchpad.net/~timo-jyrinki/+snap/ubuntu-qt-runtime/+build/8971
and it works by cutting eg a test application's size from 100MB to
10MB. The current idea is that it would be primarily be used via a
cloud part helper to be created.

-Timo


2016-10-10 17:21 GMT+03:00 Timo Jyrinki :
> Hi!
>
> I started experimenting with bringing upstream Qt as is as a cloud
> part. I can happily announce an early let's say "alpha" version of it
> is working and available with "after: [qt57]".
>
> This is not the "qt-ubuntu" I've a vision of as being available via
> content interface, but rather building upstream Qt as part of your
> app. This is only worth considering if you absolutely require a newer
> Qt than what is available in Ubuntu (5.5 in Ubuntu 16.04, 5.6 in
> Ubuntu 16.10, 5.7 somewhere Jan-Feb in Ubuntu 17.04).
>
> For fun, you can try out a dummy QML test app (C++ backend included though) 
> by:
>
> sudo snap install --edge timostestapp2
> timostestapp2
>
> Mind the missing font for Chinese characters, it's not a bug, just a
> font not staged :) What it's really about is that it is a simple
> application that happens to bundle and uses upstream's to-be-released
> Qt 5.7.1 built with the cloud part.
>
> Included Qt modules: Qt 3D, Qt Bluetooth, Qt Base (Core, Gui etc), Qt
> Declarative, Qt Tools, Qt Web Channel, ... and a lot more, but _not_:
> qtwebengine, qtwebview, qtwebkit. Also no Ubuntu UI Toolkit yet, we
> haven't started testing it with Qt 5.7 yet.
>
> You can use the snapcraft.yaml, launcher and modified parts/plugins
> from https://github.com/tjyrinki/timostestapp2. Modified autotools
> plugin is for building Qt (it doesn't seem to fetch that from the
> cloud part, that would be nice), and modified qmake plugin is for
> building your app. No CMake plugin or such yet, this is very much
> "yay, it runs now!!" first version done in-between all my other tasks.
>
> -Timo

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

Re: Missing uboot env variables "snap_kernel" & "snap_core" for building an armhf image

[Steve Langasek]

Hi Woodrow,

On Thu, Nov 03, 2016 at 03:40:39PM +0800, Woodrow Shen wrote:

> I'm working on port of roseapple-pi (
> https://github.com/xapp-le/SnappyUbuntuCore), and after building an image
> via ubuntu-image, the new uboot.env modified by snapd can't find the snap
> related variables "snap_kernel" & "snap_core". I check the image's content
> and then confirm the kernel snap files are included under /var/lib/snapd/
> (writable) and system-boot file system. Right now I don't have any idea
> about this, anyone can give me a clue ? Thanks.

Please make sure your gadget.yaml does not specify uboot.env as contents for
your partition.  It is /not/ content, it is handled specially by snapd.  If
you also specify it as content, what happens is that snapd first extracts it
from the gadget, modifies it internally, and writes it to the boot
directory; then ubuntu-image, following the instructions in your
gadget.yaml, clobbers that snapd-provided uboot.env with the unmodified one.

ubuntu-image should be more defensive about this, and refuse to allow the
snapd-special files as content.  Barry, can you please get this onto the
roadmap for ubuntu-image?

Thanks,
-- 
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

Re: Missing uboot env variables "snap_kernel" & "snap_core" for building an armhf image

[Oliver Grawert]

Am Donnerstag, den 03.11.2016, 15:40 +0800 schrieb Woodrow Shen:
> Hi,
> 
> I'm working on port of roseapple-pi (https://github.com/xapp-le/Snapp
> yUbuntuCore), and after building an image via ubuntu-image, the new
> uboot.env modified by snapd can't find the snap related
> variables "snap_kernel" & "snap_core". I check the image's content
> and then confirm the kernel snap files are included under
> /var/lib/snapd/ (writable) and system-boot file system. Right now I
> don't have any idea about this, anyone can give me a clue ? Thanks.
> 

you are missing a link called "uboot.conf" in that dir:
https://github.com/xapp-le/SnappyUbuntuCore/tree/master/builder/gadget

it needs to point to the binary uboot.env file
(make sure uboot.env exists in your gadget before building and run:
ln -s uboot.conf uboot.env 
in that dir before snapping up your gadget)

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: Provisional snap for DUB (D language package/build manager)

[Joseph Rushton Wakeling]

On 01/11/16 22:43, Sergio Schvezov wrote:

If this is x86_64, everything is aligned with the world, syscall 92 is chown. A
useful tool here can help you out, and luckily there is one, run `snap install
snappy-debug` and it will do some nice things to figure out what is going on wth
these apparmor and seccomp blockers.


Cheers, I'll try that out.  Will probably be a little while before I follow up 
-- I'm going to be away from computer for the next couple of weeks.



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.


In principle might be possible.

Thanks very much for the help & advice :-)


--
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)

[Jamie Bennett]

Regards,
Jamie.

> On 1 Nov 2016, at 23:43, Sergio Schvezov  
> wrote:
> 
> 
> 
>> El 01/11/16 a las 23:31, Joseph Rushton Wakeling escribió:
>>> 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"
>> 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
>> 
>> 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.)
> 
> If this is x86_64, everything is aligned with the world, syscall 92 is chown. 
> A useful tool here can help you out, and luckily there is one, run `snap 
> install snappy-debug` and it will do some nice things to figure out what is 
> going on wth these apparmor and seccomp blockers.
> 
>> 
>> 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?
> It seems to be just a dub problem.
> 
>> 
>> Setting the containment to devmode removes the problem, but it would be nice 
>> to be able to have strict confinement earlier rather than later.
>> 
> 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.
> 
> -- 
> 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: Missing uboot env variables "snap_kernel" & "snap_core" for building an armhf image

[Woodrow Shen]

Hi Steve & Ogra,

Thanks your explanation, I think the thing of snapd-special files is
probably not clear for developers, and maybe we can update the porting
guide (https://developer.ubuntu.com/en/snappy/guides/porting/) for the
brand new uc16 on it. After all, it's the old-fashioned and can not be
useful for uc16. Finally, the roseapple-pi board works on uc16, bravo !!
Thank you,

Rejoice,
Woodrow

On Thu, Nov 3, 2016 at 6:41 PM, Oliver Grawert  wrote:

> Am Donnerstag, den 03.11.2016, 15:40 +0800 schrieb Woodrow Shen:
> > Hi,
> >
> > I'm working on port of roseapple-pi (https://github.com/xapp-le/Snapp
> > yUbuntuCore), and after building an image via ubuntu-image, the new
> > uboot.env modified by snapd can't find the snap related
> > variables "snap_kernel" & "snap_core". I check the image's content
> > and then confirm the kernel snap files are included under
> > /var/lib/snapd/ (writable) and system-boot file system. Right now I
> > don't have any idea about this, anyone can give me a clue ? Thanks.
> >
>
> you are missing a link called "uboot.conf" in that dir:
> https://github.com/xapp-le/SnappyUbuntuCore/tree/master/builder/gadget
>
> it needs to point to the binary uboot.env file
> (make sure uboot.env exists in your gadget before building and run:
> ln -s uboot.conf uboot.env
> in that dir before snapping up your gadget)
>
> ciao
> oli
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>
>


-- 
Woodrow Shen
Software Engineer, Canonical ltd.
UES | CE | PC & Core, Taipei
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Ubuntu Core 16 Final!

[Michael Vogt]

Hi,

The Snappy team is happy to announce the release of Ubuntu Core 16.

Ubuntu Core is an operating system entirely based on snaps, including
its foundation. Applications, kernel, core operating system, and
gadget components are all managed as snaps and are installed and
refreshed by snapd, the daemon and tooling responsible for making it
all dance.

The images are available currently for PC (amd64, i386) and
for Pi2/Pi3 and Dragonboard. These images can be downloaded from:

http://releases.ubuntu.com/ubuntu-core/16/

Once unpacked, the images are bootable, the PC image can be booted
directly in qemu-kvm, virtualbox or on real hardware. When running the
images in qemu-kvm it is helpful to use the "-redir" feature of
qemu-kvm. e.g.:

$ kvm -smp 2 -m 1500 -redir tcp:10022::22 ubuntu-core-16-amd64.img

The message from console-conf is a bit misleading in this setup. It
will say "ssh USER@10.0.2.15". However due to the way that the
qemu-kvm user networking behaves, you will actually have to run the
following to ssh into the images:

$ ssh -p 10022 USER@localhost

or if you have the following snippet in ~/.ssh/config

Host kvm.snappy
 Hostname localhost
 Port 10022
 User USER
 UserKnownHostsFile /dev/null
 StrictHostKeyChecking no

then you can just

$ ssh kvm.snappy

into it.

The Pi2/Pi3/Dragonboard image can be written to a sdcard via dd. An
alternative way to write the image is to use "go-dd", e.g. on Ubuntu
16.04:

 $ sudo snap install --devmode --beta godd
 $ sudo /snap/bin/godd ubuntu-core-16-pi2.img.xz
 [this will print a message showing what devices are removable]
 $ xzcat ubuntu-core-16-pi2-rc2.img.xz | sudo /snap/bin/godd - /dev/sdXX

After booting the image you can enter your Ubuntu One email and it
will automatically create a matching user with the right ssh keys. If
you do not have an Ubuntu SSO account yet please create one at:

https://login.ubuntu.com/

(don't forget to add your public ssh keys to that account).

Known issues:
- pi3 wlan can not be initially configured, wired network needs to be
  used for the initial setup (you can re-run "sudo console-conf" at
  any later point to re-configure the device for wlan only
  operation).

Bug references for the pi3 known issues:
- http://pad.lv/1637153
  plugging in network cable during configuration can cause a traceback
  on pi3
- http://pav.lv/1624322
  no wlan0 device at all on first boot on pi3
- http://pad.lv/1632387
  wifi setup times out on pi3 devices on first boot

These images follow the "stable" channel. If you find any issues,
please let us know via:

https://bugs.launchpad.net/snappy/

Ubuntu Core 16 follows a rolling release model, security updates and
bug fixes will come to you via regular over the air updates for the
lifetime of the release.

Enjoy this release!

Cheers,
 Michael Vogt (on behalf of the Snappy team)


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

Re: Ubuntu Core 16 Final!

[Jeff Biehle]

Congrats team!  Well done!

Jeff

On Thu, Nov 3, 2016 at 10:47 AM, Michael Vogt 
wrote:

> Hi,
>
> The Snappy team is happy to announce the release of Ubuntu Core 16.
>
> Ubuntu Core is an operating system entirely based on snaps, including
> its foundation. Applications, kernel, core operating system, and
> gadget components are all managed as snaps and are installed and
> refreshed by snapd, the daemon and tooling responsible for making it
> all dance.
>
> The images are available currently for PC (amd64, i386) and
> for Pi2/Pi3 and Dragonboard. These images can be downloaded from:
>
> http://releases.ubuntu.com/ubuntu-core/16/
>
> Once unpacked, the images are bootable, the PC image can be booted
> directly in qemu-kvm, virtualbox or on real hardware. When running the
> images in qemu-kvm it is helpful to use the "-redir" feature of
> qemu-kvm. e.g.:
>
> $ kvm -smp 2 -m 1500 -redir tcp:10022::22 ubuntu-core-16-amd64.img
>
> The message from console-conf is a bit misleading in this setup. It
> will say "ssh USER@10.0.2.15". However due to the way that the
> qemu-kvm user networking behaves, you will actually have to run the
> following to ssh into the images:
>
> $ ssh -p 10022 USER@localhost
>
> or if you have the following snippet in ~/.ssh/config
>
> Host kvm.snappy
>  Hostname localhost
>  Port 10022
>  User USER
>  UserKnownHostsFile /dev/null
>  StrictHostKeyChecking no
>
> then you can just
>
> $ ssh kvm.snappy
>
> into it.
>
> The Pi2/Pi3/Dragonboard image can be written to a sdcard via dd. An
> alternative way to write the image is to use "go-dd", e.g. on Ubuntu
> 16.04:
>
>  $ sudo snap install --devmode --beta godd
>  $ sudo /snap/bin/godd ubuntu-core-16-pi2.img.xz
>  [this will print a message showing what devices are removable]
>  $ xzcat ubuntu-core-16-pi2-rc2.img.xz | sudo /snap/bin/godd -
> /dev/sdXX
>
> After booting the image you can enter your Ubuntu One email and it
> will automatically create a matching user with the right ssh keys. If
> you do not have an Ubuntu SSO account yet please create one at:
>
> https://login.ubuntu.com/
>
> (don't forget to add your public ssh keys to that account).
>
> Known issues:
> - pi3 wlan can not be initially configured, wired network needs to be
>   used for the initial setup (you can re-run "sudo console-conf" at
>   any later point to re-configure the device for wlan only
>   operation).
>
> Bug references for the pi3 known issues:
> - http://pad.lv/1637153
>   plugging in network cable during configuration can cause a traceback
>   on pi3
> - http://pav.lv/1624322
>   no wlan0 device at all on first boot on pi3
> - http://pad.lv/1632387
>   wifi setup times out on pi3 devices on first boot
>
> These images follow the "stable" channel. If you find any issues,
> please let us know via:
>
> https://bugs.launchpad.net/snappy/
>
> Ubuntu Core 16 follows a rolling release model, security updates and
> bug fixes will come to you via regular over the air updates for the
> lifetime of the release.
>
> Enjoy this release!
>
> Cheers,
>  Michael Vogt (on behalf of the Snappy team)
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>



-- 
Jeff Biehle | Sales & Alliances Manager | Canonical | +1 512.636.8321
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Should Syncloud migrate to snappy?

[Boris Rybalkin]

Hello,

I am developing Syncloud (syncloud.org) and our goal is to have an app
store of popular services (file storage, social network, mail, messaging
...). We prepare images for a set of popular single board computers.
Images a simply minimal debian + board specific kernels (taken from images
provided by vendors).

Currently we package self contained server apps (using systemd) as simple
archives and have a tool to install/upgrade/remove them.

Another key component is app store UI which runs on a device and simplifies
app installation with the intention that a non technical person can use it
the same way he or she uses iPhone App Store.

My question is: do you think it is worth considering ubuntu core and its
snap mechanism as a platform for our solution?
More specific questions:

1. Can we continue to regular board kernels as is or we need to have custom
builds for snap mode?
2. Can we use our own snap store location (lets say we have converted our
archives to snaps)?
3. Can we use systemd?
4. As it sounds a lot of work and we do not really have resources, should
we start just by taking snapd and add support for syncloud packages (store
format, install location, app format, hooks)?

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

Re: Should Syncloud migrate to snappy?

[Michael Hall]

Hi Boris,

Syncloud is an exciting project, and it sounds like there's a lot of
benefit you can derive from snaps. I'll try and give you some high-level
answers to your questions here to point you in the right direction,
others can give you more detail from there.

> 1. Can we continue to regular board kernels as is or we need to have
> custom builds for snap mode?

Snaps can provide more than just apps, we use snaps to deliver kernels
and device enablement too. While you could add snap support on top of
your existing work, you will probably benefit more from moving that work
into snaps too.

See https://developer.ubuntu.com/en/snappy/guides/gadget/ for more

> 2. Can we use our own snap store location (lets say we have converted
> our archives to snaps)?

You could, yes. The API used by snapd is open, and we even provided a
very simple example store to demonstrate it. But here again we can do
even better and let you curate your own curated store built on top of
our own. This will give you access to all of the apps in our public
store, but with the ability to pick which ones to display in your own.
Lime SDR wrote up a nice post about their use of this feature:
https://developer.ubuntu.com/en/snappy/guides/gadget/

> 3. Can we use systemd?

Yes, in fact service snaps already use it. If a snap declares a daemon,
it will automatically generate the appropriate systemd service file to
manage it.

> 4. As it sounds a lot of work and we do not really have resources,
> should we start just by taking snapd and add support for syncloud
> packages (store format, install location, app format, hooks)?

It sounds like Snaps can do a lot of what you want, letting you focus
your resources on the features of your product rather than the plumbing.
Adopting Snap apps means you benefit from all the work we're already
doing to encourage ISVs to provide software in that format, and if you
use our store you get a ready list of software to choose for yours.

I hope this is enough to get you started. Keep asking questions here and
others will chime in with more detailed answers for you.

Michael Hall
mhall...@ubuntu.com

On 11/03/2016 06:25 PM, Boris Rybalkin wrote:
> Hello,
> 
> I am developing Syncloud (syncloud.org ) and our
> goal is to have an app store of popular services (file storage, social
> network, mail, messaging ...). We prepare images for a set of popular
> single board computers.
> Images a simply minimal debian + board specific kernels (taken from
> images provided by vendors).
> 
> Currently we package self contained server apps (using systemd) as
> simple archives and have a tool to install/upgrade/remove them.
> 
> Another key component is app store UI which runs on a device and
> simplifies app installation with the intention that a non technical
> person can use it the same way he or she uses iPhone App Store.
> 
> My question is: do you think it is worth considering ubuntu core and its
> snap mechanism as a platform for our solution?
> 
> More specific questions:
> 
> 1. Can we continue to regular board kernels as is or we need to have
> custom builds for snap mode?
> 2. Can we use our own snap store location (lets say we have converted
> our archives to snaps)?
> 3. Can we use systemd?
> 4. As it sounds a lot of work and we do not really have resources,
> should we start just by taking snapd and add support for syncloud
> packages (store format, install location, app format, hooks)?
> 
> Thank you,
> Boris Rybalkin
> 
> 

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

[NEWS] Ubuntu built with Qt

[Zoltán Balogh]

Hi,

nice news about the synergy between Qt and Ubuntu: 
https://www.qt.io/case-built-with-qt-ubuntu-open-source-software-platform/


Many considers Qt only as the UI development framework but in fact Qt's 
IoT offering is very strong. Since the 5.7 version their main focus is 
to offer toolkit and adaptation layer for IoT devices


Some reading on the topic:

https://blog.qt.io/blog/2016/09/15/internet-of-things-why-tools-matter/
https://blog.qt.io/blog/2016/08/29/embedded-systems-are-the-backbone-of-iot-but-its-software-that-brings-it-all-together/
http://www.ics.com/blog/qt-and-internet-things-part-1

cheers,

bzoltan


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