Re: Desktop snaps are not working in KDE

[Simon Fels]

On 29.03.2017 18:40, Simon Fels wrote:
> Hey everyone,
> 
> we currently see bug reports (e.g.
> https://bugzilla.opensuse.org/show_bug.cgi?id=1031501) that certain
> snaps are not working in KDE on openSUSE (42.2 / Tumbleweed). On the
> same distribution, when I run the snaps within Gnome, everything works
> as it should and the applications are starting up.
> 
> I didn't looked much into the details yet. keepassxc is one of the snaps
> which fail to start:
> 
> simon@linux-82h5:~> keepassxc
> No protocol specified
> QXcbConnection: Could not connect to display :0
> Aborted
> 
> As those snaps include Qt/GTK libraries from Ubuntu I can only guess
> that there are some incompatibilities between KDE on openSUSE and the
> libraries we ship. Also there is no wayland in the game. I verified both
> Gnome and KDE are running under X11.
> 
> Anyone has a good idea what could be wrong here?

I've found the reason for this now. See
https://bugs.launchpad.net/snapd/+bug/1677513 for a summary. In the end
the problem is that XAUTHORITY refers to a xauth file in /tmp which
isn't accessible within the snap environment.

I will create a fix for this as part of my cross-distro work.

regards,
Simon


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

Desktop snaps are not working in KDE

[Simon Fels]

Hey everyone,

we currently see bug reports (e.g.
https://bugzilla.opensuse.org/show_bug.cgi?id=1031501) that certain
snaps are not working in KDE on openSUSE (42.2 / Tumbleweed). On the
same distribution, when I run the snaps within Gnome, everything works
as it should and the applications are starting up.

I didn't looked much into the details yet. keepassxc is one of the snaps
which fail to start:

simon@linux-82h5:~> keepassxc
No protocol specified
QXcbConnection: Could not connect to display :0
Aborted

As those snaps include Qt/GTK libraries from Ubuntu I can only guess
that there are some incompatibilities between KDE on openSUSE and the
libraries we ship. Also there is no wayland in the game. I verified both
Gnome and KDE are running under X11.

Anyone has a good idea what could be wrong here?

regards,
Simon

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

Re: content interface, DENIED mounting $SNAP/mydir

[Simon Fels]

On 03.03.2017 01:06, Michi Henning wrote:
> 
>> On 3 Mar 2017, at 4:33 , knitzsche > > wrote:
>>
>> Hi,
>>
>> I am trying to use the wifi-ap content sharing interface.
>>
>> It is DENIED (see below) when I try to use a $SNAP directory.
>>
>> It works when I instead use $SNAP_DATA directory for the content
>> sharing. But, I have to create that directory at run time: I can't
>> figure out so far how to create (from snapcraft.yaml) an empty dir in
>> $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve
>> my problem.)
> 
> 
> We do this to create a directory:
> 
> install: |
>   # Make sure we have a mount point for ubuntu-app-platform
>   mkdir -p $SNAPCRAFT_PART_INSTALL/ubuntu-app-platform

That doesn't help much here as we're bind-mounting read/write data and
that seems to be not possible to go into somewhere below $SNAP.

I fear the only answer to this problem are interface hooks which would
allow us to create the relevant directory before the bind-mount happens
inside $SNAP_DATA.

regards,
Simon


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

Re: chroot into a snap

[Simon Fels]

On 09.02.2017 17:08, Thomas Voß wrote:
> On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón 
>  wrote:
>> Because this will use nextcloud documents, and they are internal to
>> nextcloud snap
>>
> 
> In that case, content-sharing would help, yes.

Is that always the case? I thought we talked a while back about using
the removable-media interface also as an option in the nextcloud snap to
allow users placing their data on an external hardware driver or
different partition. Not sure if this was ever implemented.

regards,
Simon


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

Re: a little script: snapdiff

[Simon Fels]

On 10.02.2017 01:44, Michael Hudson-Doyle wrote:
> Very much inspired by debdiff, I wrote a little script to compare two
> snaps. It looks like this:
> 
> (master)mwhudson@aeglos:/opt/opensource/snaps/go$ snapdiff
> go-17-mwhudson_1.snap go-17-mwhudson_2.snap 
> Only in second snap, go-17-mwhudson_2.snap:
> 
> -rw-rw-r-- root/root   839 2017-02-03 11:14
> test/fixedbugs/issue16331.go
> -rw-rw-r-- root/root   686 2017-02-03 11:14
> test/fixedbugs/issue18410.go
> 
> Differences in meta directory:
> 
> diff -Nur meta1/snap.yaml meta2/snap.yaml
> --- meta1/snap.yaml2017-01-11 11:49:30.0 +1300
> +++ meta2/snap.yaml2017-02-03 11:16:07.0 +1300
> @@ -13,4 +13,4 @@
>  grade: devel
>  name: go-17-mwhudson
>  summary: Go programming language compiler, linker, stdlib
> -version: 1.7.4
> +version: 1.7.5
> 
> It's implemented in perl (for no very good reason) and you can get it
> here: http://paste.ubuntu.com/23963902/

That is really nice!

Having a classic snap for it would be awesome :-)

regards,
Simon


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

Re: IPC between snaps

[Simon Fels]

On 09.02.2017 11:36, Roberto Mier Escandón  wrote:
> Thanks Löic.
> I'll take a look
> 
> On 09/02/17 11:18, Loïc Minier wrote:
>> Hi,
>>
>> Yes, this is typically how you allow a snap to talk to snapd or docker
>> daemon or lxd. You need a new interface to grant access to this socket
>> path. If you'd like some examples or look at existing ones, grep for socket
>> under github.com/snapcore/snapd/interfaces.
>>
>> Cheers,
>> - Loïc
>>
>> On Thu, Feb 9, 2017 at 10:27 AM, Roberto Mier Escandón  <
>> roberto.escan...@canonical.com> wrote:
>>
>>> Hi,
>>>
>>> Is there any way to communicate processes in different snaps using
>>> pipes?. How can it be done in this or other way?


If you want to use a unix domain socket you can easily share the socket
file via the content interface between too snaps. Tony created two
really good example snaps to showcase this:

 * https://github.com/tonyespy/unix-domain-server
 * https://github.com/tonyespy/unix-domain-client

Server side uses the network-bind and client side uses just the network
interface. Also have a look at
https://github.com/snapcore/snapd/wiki/Content-Interface which explains
the details a bit more.

For named pipes I am not sure if both interfaces already allow the
relevant things but its worth a try and otherwise we can easily add the
necessary things.

I hope that helps.

regards,
Simon


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

Re: [System Enablement] New releases Feb 2017

[Simon Fels]

On 07.02.2017 15:40, Simon Fels wrote:
> Hey everyone,
> 
> new releases of the alsa-utils, network-manager, upower and wifi-ap
> snaps were pushed into the candidate channel.
> 
> alsa-utils 1.1.2-2:
> 
> * First official release supported by Canonical
> * Aliases for all exported commands are available
> * Set of automated and manual test cases guarantee quality of each release
> 
> network-manager 1.2.2-11:
> 
> * Wake-on-WLAN can be configured via snap confiration / nmcli
> * Automatic reconfiguration of network devices when devices wakes up
> * Alias support for nmcli command
> * WiFi powersave is now configurable via snap configuration
> * Network-Manager tests are using tests-extras repository to fetch the
> image creating scripts rather than embed them.
> 
> upower 0.99.4-2:
> 
> * First release
> * Integration with systemd to suspend the system on low battery events

We found a problem with upower which causes its plugs/slots not
correctly connected/specified. This is now fixed and new revisions are
uploaded into the candidate channel. The following revisions are now
available for testing:

22 (amd64)
25 (arm64)
24 (armhf)
23 (i386)

regards,
Simon


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

[System Enablement] New releases Feb 2017

[Simon Fels]

Hey everyone,

new releases of the alsa-utils, network-manager, upower and wifi-ap
snaps were pushed into the candidate channel.

alsa-utils 1.1.2-2:

* First official release supported by Canonical
* Aliases for all exported commands are available
* Set of automated and manual test cases guarantee quality of each release

network-manager 1.2.2-11:

* Wake-on-WLAN can be configured via snap confiration / nmcli
* Automatic reconfiguration of network devices when devices wakes up
* Alias support for nmcli command
* WiFi powersave is now configurable via snap configuration
* Network-Manager tests are using tests-extras repository to fetch the
image creating scripts rather than embed them.

upower 0.99.4-2:

* First release
* Integration with systemd to suspend the system on low battery events

wifi-ap 13:

* Configuration command accepts multiple key/value pairs
* AP can be disabled on installation via configuration option

---

An overview of which revisions / versions of the particular snaps are
available in which channel is available at
https://docs.google.com/document/d/1-rKAjr6FLUzt7oOtR_xcAEHJpntUPGpmixU6PV8K2KU/edit#

The snaps have passed our engineering QA and will now be tested by the
platform and commercial QA teams before the new versions are pushed to
the stable channel.

Bileto requests are:

- alsa-utils: https://bileto.ubuntu.com/#/ticket/2441
- network-manager: https://bileto.ubuntu.com/#/ticket/2442
- upower: https://bileto.ubuntu.com/#/ticket/2445
- wifi-ap: https://bileto.ubuntu.com/#/ticket/2444

If you have any questions feel free to ping me.

regards,
Simon

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

Re: the ppp interface (and general renaming/transitioning of interfaces)

[Simon Fels]

On 06.02.2017 15:48, Simon Fels wrote:
> On 06.02.2017 14:36, Oliver Grawert wrote:
>> hi,
>>
>> on the core images we currently provide a ppp interface that used to be
>> used for pppd access in 15.04 images and also gives access to
>> /dev/tty[0-9].
>>
>> with series 16 the pppd binary was dropped from the core snap and a
>> pppd snap was added to the store which provides all the ppp
>> functionality, but the interface persisted in the core snap. 
> 
> When was pppd dropped from the core snap? We have a dependency on it
> from the modem-manager snap which is why we added the ppp interface. It
> also does a few more things like ensuring that the right kernel modules
> are loaded etc.
> 
>> i recently got a question from a customer about an interface providing
>> access to /dev/tty0 for certain console messages ... 
> 
> That would be more the serial-port interface where we need a slot on the
> gadget/core snap for.
> 
>> this made me wonder if we have any forward plans for renaming
>> interfaces in cases like the above ...
> 
> Please don't do this. The modem-manager snap defines a plug with this
> interface so we can't easily remove or rename it.
> 
>> i.e. it would make sense to rename the ppp interface to "console-
>> access" or "tty-access" and drop the execution bits for the non-
>> existing pppd binary from it... do we have any implementation plans,
>> rules, policies etc for such use-cases yet ?
> 
> Actually we're in a broken state now. When the ppp interface was
> implemented the idea was that ppp remains in the core snap. Long term I
> agree that there are better ways to express portions of the ppp
> interface (like via serial-port) but the interface itself needs to stay
> as it triggers loading of the right kernel modules needed for ppp.

I've just checked this and all pppd things are still in core. See
https://paste.ubuntu.com/23941360/

regards,
Simon


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

Re: the ppp interface (and general renaming/transitioning of interfaces)

[Simon Fels]

On 06.02.2017 14:36, Oliver Grawert wrote:
> hi,
> 
> on the core images we currently provide a ppp interface that used to be
> used for pppd access in 15.04 images and also gives access to
> /dev/tty[0-9].
> 
> with series 16 the pppd binary was dropped from the core snap and a
> pppd snap was added to the store which provides all the ppp
> functionality, but the interface persisted in the core snap. 

When was pppd dropped from the core snap? We have a dependency on it
from the modem-manager snap which is why we added the ppp interface. It
also does a few more things like ensuring that the right kernel modules
are loaded etc.

> i recently got a question from a customer about an interface providing
> access to /dev/tty0 for certain console messages ... 

That would be more the serial-port interface where we need a slot on the
gadget/core snap for.

> this made me wonder if we have any forward plans for renaming
> interfaces in cases like the above ...

Please don't do this. The modem-manager snap defines a plug with this
interface so we can't easily remove or rename it.

> i.e. it would make sense to rename the ppp interface to "console-
> access" or "tty-access" and drop the execution bits for the non-
> existing pppd binary from it... do we have any implementation plans,
> rules, policies etc for such use-cases yet ?

Actually we're in a broken state now. When the ppp interface was
implemented the idea was that ppp remains in the core snap. Long term I
agree that there are better ways to express portions of the ppp
interface (like via serial-port) but the interface itself needs to stay
as it triggers loading of the right kernel modules needed for ppp.

regards,
Simon


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

Re: Which snap interface allows accessing /dev/rfkill?

[Simon Fels]

On 19.01.2017 10:41, Tonny Tzeng wrote:
> Hi,
> 
> I'd like to unblock the Bluetooth interface on Ubuntu Core, so I use
> 'stage-packages' keyword to install 'rfkill' package to my snap. If I
> install the snap in devmode, the rfkill command works as expected. But
> if the snap is installed in confined mode, I always get 'Permission
> denied', and the /var/log/syslog shows below message:
> 
> Jan 19 09:17:42 localhost kernel: [177262.419927] audit: type=1400
> audit(1484817462.015:2031): apparmor="DENIED" operation="open"
> profile="snap.iotivity-smarthome-demo.rfkill" name="/dev/rfkill"
> pid=14430 comm="rfkill" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0
> 
> Would anyone help me which interface should I declare with the plugs
> keyword?  I've tried hardware-observe and bluetooth-control interfaces
> but no success. Any pointers would be appreciated, thanks in advance.

The 'network-control' interface should do the job for you. See
https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go#L94

regards,
Simon


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

Re: DHCP and /etc/resolv.conf

[Simon Fels]

On 17.01.2017 17:46, Joe Coates wrote:
> The 'network-manager' slot interface does not show up in my Ubuntu-core 
> interface list.   I'm running 2.21 on a Virtualbox VM.

It's not a slot you can put on your snap or one which is provided by the
core snap. It's a slot which only the network-manager snap can own and
no other one and its not a one which allows arbitrary snaps to access
the resolvconf configuration. For that we still need a different
interface or add support for resolvconf access to the network-control
interface.

If you look at the code for the network-manager interface the
responsible part for resolveconf is at
https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_manager.go#L86
I guess it would be ok to get those bits added to the network-control
interface at
https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go

If you want you can easily submit a PR to get those bits added there. A
short introduction into snapd hacking is available at
https://github.com/snapcore/snapd/blob/master/HACKING.md

regards,
Simon


> -Original Message-
> From: snapcraft-boun...@lists.snapcraft.io 
> [mailto:snapcraft-boun...@lists.snapcraft.io] On Behalf Of Simon Fels
> Sent: Tuesday, January 17, 2017 11:05 AM
> To: snapcraft@lists.snapcraft.io
> Subject: Re: DHCP and /etc/resolv.conf
> 
> On 17.01.2017 14:18, Zygmunt Krynicki wrote:
>> Quick grep tells me that no interface currently relates to
>> "resolv.conf" file
> 
> Actually you shouldn't allow access to /etc/resolv.conf but to 
> /run/resolvconf/ which the network-manager interface allows as the only one 
> so far.
> 
> regards,
> Simon
> 
>> On Tue, Jan 17, 2017 at 12:01 AM, Joe Coates
>> <jcoa...@extremenetworks.com> wrote:
>>> Is there a current slot interface which allows write access to 
>>> /etc/resolv.conf?
>>>
>>> Thanks,
>>> Joe Coates
>>>
>>> 
>>> From: snapcraft-boun...@lists.snapcraft.io
>>> <snapcraft-boun...@lists.snapcraft.io> on behalf of Mark Shuttleworth
>>> <m...@ubuntu.com>
>>> Sent: Monday, January 16, 2017 4:58:45 PM
>>> To: Snapcraft
>>> Subject: Re: DHCP and /etc/resolv.conf
>>>
>>> On 16/01/17 16:39, Joe Coates wrote:
>>>
>>> I'm snapping an app which includes a DHCP client replacement.   Ultimately 
>>> it wants to update/replace /etc/resolv.conf. My snap is connected to 
>>> all the "network" interfaces available in my ubuntu-core, but none seem to 
>>> allow write access to this file.  Shouldn't an interface like 
>>> "network-control" allow write access to /etc/resolv.conf ?
>>>
>>> I think /etc/resolv.conf is generated from a number of sources, but yes, it 
>>> should be possible to influence it.
>>>
>>> Mark
>>>
>>> 
>>>
>>> DISCLAIMER:
>>> This e-mail and any attachments to it may contain confidential and 
>>> proprietary material and is solely for the use of the intended recipient. 
>>> Any review, use, disclosure, distribution or copying of this transmittal is 
>>> prohibited except by or on behalf of the intended recipient. If you have 
>>> received this transmittal in error, please notify the sender and destroy 
>>> this e-mail and any attachments and all copies, whether electronic or 
>>> printed.
>>>
>>>
>>> --
>>> 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
> 
> 
> 
> 
> DISCLAIMER:
> This e-mail and any attachments to it may contain confidential and 
> proprietary material and is solely for the use of the intended recipient. Any 
> review, use, disclosure, distribution or copying of this transmittal is 
> prohibited except by or on behalf of the intended recipient. If you have 
> received this transmittal in error, please notify the sender and destroy this 
> e-mail and any attachments and all copies, whether electronic or printed.
> 
> 


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

Re: DHCP and /etc/resolv.conf

[Simon Fels]

On 17.01.2017 14:18, Zygmunt Krynicki wrote:
> Quick grep tells me that no interface currently relates to "resolv.conf" file

Actually you shouldn't allow access to /etc/resolv.conf but to
/run/resolvconf/ which the network-manager interface allows as the only
one so far.

regards,
Simon

> On Tue, Jan 17, 2017 at 12:01 AM, Joe Coates
>  wrote:
>> Is there a current slot interface which allows write access to 
>> /etc/resolv.conf?
>>
>> Thanks,
>> Joe Coates
>>
>> 
>> From: snapcraft-boun...@lists.snapcraft.io 
>>  on behalf of Mark Shuttleworth 
>> 
>> Sent: Monday, January 16, 2017 4:58:45 PM
>> To: Snapcraft
>> Subject: Re: DHCP and /etc/resolv.conf
>>
>> On 16/01/17 16:39, Joe Coates wrote:
>>
>> I'm snapping an app which includes a DHCP client replacement.   Ultimately 
>> it wants to update/replace /etc/resolv.conf. My snap is connected to all 
>> the "network" interfaces available in my ubuntu-core, but none seem to allow 
>> write access to this file.  Shouldn't an interface like "network-control" 
>> allow write access to /etc/resolv.conf ?
>>
>> I think /etc/resolv.conf is generated from a number of sources, but yes, it 
>> should be possible to influence it.
>>
>> Mark
>>
>> 
>>
>> DISCLAIMER:
>> This e-mail and any attachments to it may contain confidential and 
>> proprietary material and is solely for the use of the intended recipient. 
>> Any review, use, disclosure, distribution or copying of this transmittal is 
>> prohibited except by or on behalf of the intended recipient. If you have 
>> received this transmittal in error, please notify the sender and destroy 
>> this e-mail and any attachments and all copies, whether electronic or 
>> printed.
>>
>>
>> --
>> 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: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

[Simon Fels]

As both platform and commercial QA have approved the new snaps I would like
to go ahead with both snaps earlier than waiting for next Wednesday and
publishing them to stable.

Any objections from anyone?

regards,
Simon

On Wed, Jan 4, 2017 at 2:51 PM, Simon Fels <simon.f...@canonical.com> wrote:

> Hey everyone,
>
> A new release of the wifi-ap and pulseaudio snaps were pushed into the
> candidate channel. This release includes several improvements for both
> snaps.
>
> wifi-ap:
>
> * Switched to a unix domain socket instead of a local TCP endpoint to
> provide secure access to the management service REST API endpoint via a
> content interface based slot.
>
> * The management service now controls the access point process directly
> instead of both being two independent systemd service units. This makes
> coordination and application of configuration changes a lot easier.
>
> * New wifi-ap.status command is now available which shows the current
> status of the AP.
>
> * Improve configuration wizard which now has an auto mode as well which is
> executed directly after the installation of the snap to provide an
> out-of-the-box experience and directly spawn up an access point users can
> connect to. Wizard can be manually invoked too and guides the user through
> the configuration of the access point.
>
> * Added extensive testing of the whole snap via spread
>
> pulseaudio:
>
> This is the first release of the snap. We currently only support running
> pulseaudio in system mode and with that only support Ubuntu Core devices.
> Installing on classic desktop devices is possible but not yet supported.
>
> Please note that we require a kernel with ALSA support enabled which is
> not yet the case for all reference devices like the Raspberry Pi 2 or 3.
>
> ---
>
> An overview of which revisions / versions of the particular snaps are
> available in which channel is available at https://docs.google.com/spr
> eadsheets/d/1q2dmjPQ0Bam3p3frmmrX2WI3d1r8iusE0JTc0wm2jKM/edit#gid=0
>
> The snaps have passed our engineering QA and will now be tested by the
> platform and commercial QA teams before the new versions are pushed to the
> stable channel.
>
> Bileto requests are:
> - wifi-ap: https://bileto.ubuntu.com/#/ticket/2333
> - pulseaudio: https://bileto.ubuntu.com/#/ticket/2327
>
> If you have any questions feel free to ping me.
>
> regards,
> Simon
>
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557)

[Simon Fels]

You can add a serial port slot to a gadget snap.yaml like this:

ttyS4:
  interface: serial-port
  path: /dev/ttyS4

This only applies to static serial port nodes. If you have one provided by
an USB device you have to user a slightly different slot definition which
refers the USB product/vendor id of your USB device:

my-usb-serial:
  interface: serial-port
  usb-product: 0x
  usb-vendor: 0x
  path: /dev/my-usb-serial-port

With the path attribute you can select a static path for the serial port
node which your snap then gets access to once you connected the plug and
the slot. The path needs to start with /dev/ and afterwards you're free to
select a free node name. Internally the interface implementation will link
the right /dev/ttyUSB* node to the specified path.

Please note that you can define such a slot only on a gadget snap! So if
you don't have your own gadget snap today, you need to create one for your
device in order to get access to the serial port.

I hope that helps.

regards,
Simon


On Wed, Jan 11, 2017 at 7:37 PM, Oliver Grawert  wrote:

> hi,
> Am Mittwoch, den 11.01.2017, 17:59 + schrieb Mritunjai Singh:
> > Hi All,
> >
> > Kindly refer to: https://github.com/snapcore/snapd/issues/2557
> >
> > We are trying to get a head start on Core Snappy working with our RF
> > Mesh network card. It connects over serial and needs to be available
> > at boot. We first tried this using snap approach but due to missing
> > hotplugging serial-interface in current(latest) version of snapcraft,
> > serial i/o requests are being denied even if the snap has the
> > permission to use serial port.
> >
> > We have been suggested the gadget snap approach in order to expose
> > /dev/ttyS0 to the serial port interface for tunnccd snap to access
> > it. It would be very helpful if someone can point me to the working
> > example of a gadget snap with access to serial interface or any end
> > to end gadget snap example and its build steps.
>
> note that all our gadgets offer a console on serial by default, if you
> drive some external device via serial you might want to drop this
> console tty option.
>
> all our official gadgets are under https://github.com/snapcore/ ..
> namely the pi2-gadget, pi3-gadget, pc-gadget and dragonboard-gadget
> sub-trees if you want to take a look ...
>
> ciao
> oli
> --
> 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: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

[Simon Fels]

On 04.01.2017 17:10, Jon Melamut wrote:
> 
> 
> On Wednesday, January 4, 2017, Simon Fels <simon.f...@canonical.com
> <mailto:simon.f...@canonical.com>> wrote:
> 
> Hey everyone,
> 
> A new release of the wifi-ap and pulseaudio snaps were pushed into
> the candidate channel. This release includes several improvements
> for both snaps.
> 
> wifi-ap:
> 
> * Switched to a unix domain socket instead of a local TCP endpoint
> to provide secure access to the management service REST API endpoint
> via a content interface based slot.
> 
> * The management service now controls the access point process
> directly instead of both being two independent systemd service
> units. This makes coordination and application of configuration
> changes a lot easier.
> 
> * New wifi-ap.status command is now available which shows the
> current status of the AP.
> 
> * Improve configuration wizard which now has an auto mode as well
> which is executed directly after the installation of the snap to
> provide an out-of-the-box experience and directly spawn up an access
> point users can connect to. Wizard can be manually invoked too and
> guides the user through the configuration of the access point.
> 
> Does the snap contain a wizard itself or is this support for a wizard to
> be written by another party to drive the setup & configuration process? 

The snap provides a command line based wizard which can be run in either
manual or auto mode. The manual mode will ask the user a few questions
to set everything up and the auto mode will examine the system to take
the right decision on which interfaces, IP configuration to use
automatically. In the end the wizard uses the same REST API as every
other client can use as well. So a 3rd party snap can create its own
wizard implementation too.

In the future (once snapcraft has support for hooks) we will add
configuration to the snap itself as well to provide the ability for
users to customize the configuration of the AP from the gadget snap
(custom SSID, ...)

Hope that helps.

regards,
Simon



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

Re: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

[Simon Fels]

On 04.01.2017 15:16, Jamie Bennett wrote:
> On Wed, Jan 4, 2017 at 1:51 PM, Simon Fels <simon.f...@canonical.com> wrote:
>> Hey everyone,
>>
>> A new release of the wifi-ap and pulseaudio snaps were pushed into the
>> candidate channel. This release includes several improvements for both
>> snaps.
>>
>> wifi-ap:
>>
>> * Switched to a unix domain socket instead of a local TCP endpoint to
>> provide secure access to the management service REST API endpoint via a
>> content interface based slot.
>>
>> * The management service now controls the access point process directly
>> instead of both being two independent systemd service units. This makes
>> coordination and application of configuration changes a lot easier.
>>
>> * New wifi-ap.status command is now available which shows the current status
>> of the AP.
>>
>> * Improve configuration wizard which now has an auto mode as well which is
>> executed directly after the installation of the snap to provide an
>> out-of-the-box experience and directly spawn up an access point users can
>> connect to. Wizard can be manually invoked too and guides the user through
>> the configuration of the access point.
>>
>> * Added extensive testing of the whole snap via spread
> 
> This is great for initial configuration of a device and is what we are
> looking to use for SnapWeb, thanks.
> 
>> pulseaudio:
>>
>> This is the first release of the snap. We currently only support running
>> pulseaudio in system mode and with that only support Ubuntu Core devices.
>> Installing on classic desktop devices is possible but not yet supported.
>>
>> Please note that we require a kernel with ALSA support enabled which is not
>> yet the case for all reference devices like the Raspberry Pi 2 or 3.
> 
> Is there a reason why we do not have ALSA support enabled for these platforms?

I don't know but it simply looks like we're missing a few kernel modules
to get it properly working. Still have the item on my list to file a bug
for this.

regards,
Simon


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

[System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3

[Simon Fels]

Hey everyone,

A new release of the wifi-ap and pulseaudio snaps were pushed into the
candidate channel. This release includes several improvements for both
snaps.

wifi-ap:

* Switched to a unix domain socket instead of a local TCP endpoint to
provide secure access to the management service REST API endpoint via a
content interface based slot.

* The management service now controls the access point process directly
instead of both being two independent systemd service units. This makes
coordination and application of configuration changes a lot easier.

* New wifi-ap.status command is now available which shows the current
status of the AP.

* Improve configuration wizard which now has an auto mode as well which is
executed directly after the installation of the snap to provide an
out-of-the-box experience and directly spawn up an access point users can
connect to. Wizard can be manually invoked too and guides the user through
the configuration of the access point.

* Added extensive testing of the whole snap via spread

pulseaudio:

This is the first release of the snap. We currently only support running
pulseaudio in system mode and with that only support Ubuntu Core devices.
Installing on classic desktop devices is possible but not yet supported.

Please note that we require a kernel with ALSA support enabled which is not
yet the case for all reference devices like the Raspberry Pi 2 or 3.

---

An overview of which revisions / versions of the particular snaps are
available in which channel is available at https://docs.google.com/
spreadsheets/d/1q2dmjPQ0Bam3p3frmmrX2WI3d1r8iusE0JTc0wm2jKM/edit#gid=0

The snaps have passed our engineering QA and will now be tested by the
platform and commercial QA teams before the new versions are pushed to the
stable channel.

Bileto requests are:
- wifi-ap: https://bileto.ubuntu.com/#/ticket/2333
- pulseaudio: https://bileto.ubuntu.com/#/ticket/2327

If you have any questions feel free to ping me.

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

Re: Source of ssh key for first login

[Simon Fels]

Take
https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/tests/image
as an example of how to generate such an image which includes a predefined
user (user: test, password: test in this case). This comes with some
implications (like if you're not the brand the assertion is only valid for
a year, etc.).

Hope that helps.

regards,
Simon

On Wed, Dec 21, 2016 at 10:39 PM, Michael Hudson-Doyle <
michael.hud...@canonical.com> wrote:

>
> On 21 December 2016 at 22:51, Luther Goh Lu Feng  wrote:
>
>> During setup, console-conf will download the SSH key registered with your
>> Store account, The ssh key is used for first login.
>>
>> Is there a way to configure Ubuntu Core such that the source of the ssh
>> key can be from elsewhere? eg for cases whereby the device cant go online
>> and can only access a private network. Thanks
>>
>
> If you are the brand for the image you are using (i.e., you make your own
> image), you can provide a system-user assertion that will be processed
> during first boot to allow you to log in with user and password. The
> process for doing this is not documented anywhere that I know about though
> :(
>
> Cheers,
> mwh
>
> --
> 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: Wifi setup problem on Bubblegum 96board ubuntu core snappy

[Simon Fels]

Why are you calling

$ sudo netplan ifupdown-migrate

?

The correct steps to apply the netplan configuration is

$ sudo netplan generate
$ sudo netplan apply

regards,
Simon

On Tue, Nov 29, 2016 at 9:08 AM, Zechao Wang  wrote:

> hello, luo
>
> The yaml file is set as below:
>
> -
> $ cat /etc/netplan/00-config.yaml
> network:
>   wifis:
> wlan0:
>   access-points:
> "BhuWiFi-WX":
>   password: "12345678"
>   version: 2
>
> Then, run the netplan tool.
>
> -
> $ sudo netplan apply
> $ sudo netplan ifupdown-migrate
> Unsupported method ppp
>
>
> where am i wrong ?  How to make the netplan works ?
>
>
>
>
>
>
> 2016-11-28 21:39 GMT+08:00 Jian LUO :
>
>> Hi,
>>
>> Ubuntu Core now uses netplan[1] for network configuration. You can find a
>> good example in the repository[2].
>>
>> [1] https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039464.html
>> [2] https://git.launchpad.net/netplan/tree/doc/example-config
>>
>> Jian
>>
>> On Nov 28, 2016 14:19, "Zechao Wang"  wrote:
>>
>>> Hi,
>>>
>>> I'm working on Bubblegum 96board platform to support ubuntu snappy core.
>>> Everything is ok, and usb2eth is works well.
>>>
>>> But Wifi can not work, because snappy core use READ-ONLY file system, i
>>> cannot edit the file
>>> /etc/network/interfaces. (wifi device driver is modprobed, and wlan0 is
>>> displayed. )
>>>
>>> And the READ-ONLY file system is generated by ubuntu-image tool, it's a
>>> black box to us.
>>>
>>> So, could someone give me some advice how to fix the problem.
>>>
>>> Thx.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 王泽超
>>> TEL: 13718389475
>>> 北京威控睿博科技有限公司 
>>>
>>>
>>> --
>>> 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
>>
>>
>
>
> --
> 王泽超
> TEL: 13718389475
> 北京威控睿博科技有限公司 
>
>
> --
> 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

[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: Snap hangs when accessing a special /dev/file (/dev/vcio) [ubuntu-core 16 / RaspberryPi2]

[Simon Fels]

On 09.11.2016 21:25, Jacques Supcik wrote:
> Thank you Oliver for your constructive feedback.
> 
> I like the idea of a "mailbox-device" and I will open a bug in the
> whishlist of snappy.
> 
> My snap needs also write access to "/dev/mem":
> 
> = AppArmor =
> Time: Nov  9 19:09:52
> Log: apparmor="ALLOWED" operation="open"
> profile="snap.telecom-tower.daemon" name="/dev/mem" pid=3643
> comm="tower" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
> File: /dev/mem (write)
> 
> Should this also be addressed by the "mailbox-device" interface or
> should I fill another bug for a "physical-memory" interface? Or do you
> have an idea for a better name? Or is there already something available
> for accessing /dev/mem?

This would be definitely a different interface but the more interesting
question is why your app needs access to /dev/mem. That would give blind
access to the whole system memory space which is a highly privileged
operation I would say not many applications will need or even get
because of the obvious access to everything on the system.

Can you elaborate a bit more on what your application is doing with
/dev/mem and why it needs access to the full system memory?

regards,
Simon




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

Re: questions about connecting bluez interface

[Simon Fels]

Hey Robert,

the bluez plug and slot are now auto-connected as we put a snap-declaration
for it on the store side in place. That assertion tells snapd that the
bluez snap should get its slots/plugs automatically connected. But this
only applies for the bluez snap coming from the store. If you install one
you built locally you don't have the signed assertion from the store which
would tell snapd to auto-connect the relevant plugs and slots.

However I am not sure why the interface connection is denied when you do it
manually. @Samuele, Jamie: Any idea?

regards,
Simon

On Thu, Oct 27, 2016 at 6:54 AM, Robert Liu 
wrote:

> Hi list,
>
> I have 2 questions about connecting bluez interface.
> In Interfaces reference [1], it said the bluez is not auto-connected. But
> after I installed the bluez snap, the bluez interface is connected. Do I
> misunderstnad the definition?
>
> root@localhost:/tmp# snap install --edge bluez
> bluez (edge) 5.37-2 from 'canonical' installed
> root@localhost:/tmp# snap interfaces
> SlotPlug
> bluez:service   bluez:client
>
>
> The other question is that I cannot connect the interface when using my
> own bluez snap. Should I sign my snap to make this work?
>
> root@localhost:/tmp# snap install --dangerous bluez_5.37-2_amd64.snap
> bluez 5.37-2 installed
> root@localhost:/tmp# snap interfaces
> SlotPlug
> bluez:service   -
>   [snipped]
> -   bluez:client
> root@localhost:/tmp# snap connect bluez:client bluez:service
> error: cannot perform the following tasks:
> - Connect bluez:client to bluez:service (connection denied by slot rule of
> interface "bluez")
>
> [1] http://snapcraft.io/docs/reference/interfaces
>
> BR,
> Robert
>
> --
> 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: CLI UX for plugs with parameters?

[Simon Fels]

You wont set the attribute of the slot/plug in the command line you use to
connect slot and plug. Every attribute as to be set in the definition of
the plug/slot. Like

plugs:
  my-plug:
interface: really-awesome-interface
attribute1: value1
...

Then you simply connect via

$ snap connect my-snap:my-plug ..

without specifying  any attributes.

regards,
Simon


On Tue, Sep 20, 2016 at 9:52 AM, Stuart Bishop 
wrote:

> Hi.
>
> I believe that slots will have support for arguments, for example allowing
> a snap to connect to the 'home' slot and provide an argument requesting
> access to hidden files.
>
> Does anyone know what the command line interface will look like?
>
> In the snap layer for Juju, I need to define the data structure to declare
> what additional connections need to be made after installation of the snap.
> I'd like to get this right the first time since I'm going to be stuck with
> it.
>
>
> --
> Stuart Bishop 
>
> --
> 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: Access denied to /dev/ttyUSB0

[Simon Fels]

On 07.09.2016 15:05, Loïc Minier wrote:
> Hi,
> 
> You need to use:
> 
> plugs: [serial-port]
> 
> In your snapcraft.yaml; then you also have to connect your snap to that
> interface manually as it's not autoconnected; check "snap interfaces" to
> see which plugs and slots are connected.

That doesn't work anymore. There is no implicit slot for serial-port.
Right now the only option to get access to serial ports is via defining
a slot on a gadget snap with either a USB product/vendor id pair or a
absolute path to the serial node which then the snap can connect to and
it will only get access to that particular serial port.

You can put something like

slots:
  my-usb-serial-device:
interface: serial-port
product-id: 0x0
vendor-id: 0x0

into your gadget snap and then connect both the snap and gadget together
so your app gets access to that serial node.

In a system where no gadget exists you currently don't get access to
serial nodes. We need to implement hotplut support to make this slots
automatically exported for those devices. Not sure for when this is on
the list.

regards,
Simon

> 
> 
> On Wed, Sep 7, 2016 at 4:00 PM, Jenny Murphy  > wrote:
> 
> Hi,
>  I solved the previous issue regarding the use of the RXTX java
> library and the application is loading and running without errors. 
> However my java code isn't detecting the port, it should be able to
> see /dev/ttyUSB0.
> 
> In the dmesg log I see the following errors :
> 
> [101043.875139] usb 1-2: new full-speed USB device number 7 using
> xhci_hcd
> [101044.006418] usb 1-2: New USB device found, idVendor=10c4,
> idProduct=ea60
> [101044.006441] usb 1-2: New USB device strings: Mfr=1, Product=2,
> SerialNumber=3
> [101044.006456] usb 1-2: Product: CP2102 USB to UART Bridge Controller
> [101044.006470] usb 1-2: Manufacturer: Silicon Labs
> [101044.006482] usb 1-2: SerialNumber: 0001
> [101044.011589] cp210x 1-2:1.0: cp210x converter detected
> [101044.012037] usb 1-2: cp210x converter now attached to ttyUSB0
> 
> [101098.191960] audit_printk_skb: 258 callbacks suppressed
> 
> [101098.191979] audit: type=1400 audit(1473254849.416:69078):
> apparmor="DENIED" operation="open"
> profile="gateway.sideload_main_IdNRFcRcGPGe" name="/dev/ttyUSB0"
> pid=4875 comm="java" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
> 
> 
> Is there anyway to solve this. I am working on a Ubuntu 15.04 platform.
> 
> Thanks again.
> 
> -- 
> *Jenny Murphy*
> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland*
> jenny.mur...@episensor.com   t |
> +353 (0) 61 512 511   w |
> http://www.episensor.com 
> 
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> 
> 
> 
> 
> 
> -- 
> - Loïc
> 
> 


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

Re: Snappy on OpenSwitch

[Simon Fels]

Hey Mike,

>> I'm very interested in adding Snappy support to OpenSwitch
>> (www.openswitch.net ).
>>
>> OpenSwitch is a Network Operating System for network switches build upon
>> OpenEmbedded/Yocto/Poky.
> 
> Pretty nice idea!
> 
>> I'm using a branch of OpenSwitch in which they've upgraded to Yocto 2.1
>> - https://github.com/open-switch/ops-build
>>  branch
>> "feature/yocto_2.1".
>>
>> I've added meta-snappy to the bblayers.conf file used to build
>> OpenSwitch and I was able to successfully 'bitbake snappy-demo-image' so
>> that I at least know your meta-snappy layer is compatible with the
>> OpenSwitch layers.
>>
>> My knowledge of OE/bitbake is limited and I'm hoping someone could
>> provide some pointers or guidance to integrating Snappy onto an existing
>> OE/Yocto distribution such as OpenSwitch.
> 
> You already did the first step and verified the build of the relevant
> components (snapd and snap-confine) works well in OpenSwitch.
> 
> The next step is to get the different config options for the kernel into
> your kernel defconfig. We have various sample kernel trees at [1] which
> you can use as reference. In meta-snappy I extended the default
> linux-yocto defconfig with the bits listed in [2]. I suspect OpenSwitch
> may use a different kernel tree so you have to apply the different
> options for it as well. You don't need any AppArmor related patches if
> you want just unconfined snaps working for a first step.
> 
> As next thing you have to add snapd and snap-confine to the content of
> the OpenSwitch image. Adding snap-confine and snapd in [3] is ok to get
> it things working. Later you want to add a packagegroup especially for
> snappy which I am planing to add to meta-snappy which then will
> automatically pull in all necessary dependencies for you.
> 
> Once that is done you should be able to build a regular OpenSwitch
> image, flash it on a device or boot it in an emulator and should have
> snapd running and being able to install snaps and run their applications.
> 
> If you need further help or have questions, just ask here or ping me
> (nick morphis) on IRC in #snappy on FreeNode.

You already had a chance to try my suggestions?

regards,
Simon


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

Re: Need LXD for Ubuntu Core 16 image

[Simon Fels]

On 02.09.2016 11:43, Omer Akram wrote:
> Hi!
> 
> I am working with Ubuntu Core 16 image[1] on a Raspberry Pi. I am
> wondering if I there is a LXD snap that I can install on that image ? I
> found this snap[2] but it seems its not available for Ubuntu Core 16.
> 
> Is there a place where I can download the LXD snap from ?

The snap is AFIAK currently only available in the edge channel. You
should be able to install it with

$ snap install --edge --devmode lxd.stgraber

An interface should have landed in snapd too but I can't comment if that
is already in use by the lxd snap.

regards,
Simon


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

Re: New ubuntu-device-flash cannot use own gadget snap?

[Simon Fels]

On 31.08.2016 12:16, Loïc Minier wrote:
> Works for me:
> 
> $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1
> /snap/bin/ubuntu-device-flash --verbose core 16 -o snappy.img --channel
> edge  --gadget pc --kernel pc-kernel --os ubuntu-core

Yann is trying to use a gadget snap which isn't in the store but placed
on the local disk. So I suspect he is running something like

$ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1
/snap/bin/ubuntu-device-flash ... --gadget /home/user/my-gadget.snap ...

regards,
Simon

> Determining gadget configuration
> 
>  836.00 KB / 836.00 KB [==] 100.00%
> 12.77 MB/s 0
> 
> Partitioning...
> 
> Formatting...
> 
> Mounting...
> 
> Provisioning...
> 
>  74.40 MB / 74.40 MB [===] 100.00% 24.02
> MB/s 3s
> 
>  74.40 MB / 74.40 MB [===] 100.00% 59.46
> MB/s 1s
> 
>  110.54 MB / 110.54 MB [=] 100.00% 23.19
> MB/s 4s
> 
>  836.00 KB / 836.00 KB [==] 100.00%
> 68.23 MB/s 0
> 
> Unmounting...
> 
> New image complete
> 
> Summary:
> 
>  Output: snappy.img
> 
>  Architecture: amd64
> 
>  Channel: edge
> 
>  Version: 0
> 
> 
> On Wed, Aug 31, 2016 at 11:11 AM, Yann Sionneau
> <yann.sionn...@parrot.com <mailto:yann.sionn...@parrot.com>> wrote:
> 
> 
> 
> Le 08/31/2016 à 10:56 AM, Simon Fels a écrit :
> > On 31.08.2016 10:49, Yann Sionneau wrote:
> >> Hello,
> >>
> >> It seems the new (snapp'ed) ubuntu-device-flash cannot use my own 
> gadget
> >> snap anymore.
> >>
> >> yann@imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16
> >> -o snappy.img --channel edge  --gadget $PWD/../../../xxx_2.0_all.snap
> >> --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os
> >> ubuntu-core --developer-mode --enable-ssh
> >> cannot use
> >> 
> "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../../xxx_2.0_all.snap",
> >> must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2"
> >> "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" 
> "plano-amd64"]
> >>
> >> Is porting Snappy on non official devices not supported anymore?
> > No, that is not the case.
> >
> >> How is it supposed to work now? I must confess that I am blocked in my
> >> work because of this change, I cannot generate nor flash images anymore
> >> and my project is thus stalled :/
> > We're currently in a phase where ubuntu-device-flash is still being used
> > but the future will be a new tool called ubuntu-image which will allow
> > you to create images in a much better way.
> Yes I've heard of the new ubuntu-image tool. It's a good idea to make
> this new tool!
> It's just important I think that the old tools stay functional until the
> new ones are ready.
> >
> > From what I got from Michael a lot things are currently hard coded
> > inside ubuntu-device-flash. See [1] for the relevant code bits.
> >
> > You can override the sanity check for the gadget names with setting
> > UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the command
> > line you're executing. Didn't tested this but maybe Michael can comment
> > how this should work.
> Ok, the environment variable works, thanks a lot!
> Now I get this:
> 
> error while executing external command mkfs.ext4 -F -L writable
> /dev/mapper/loop3p2: mke2fs 1.42.13 (17-May-2015)
> Invalid filesystem option set:
> 
> has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize
> 
> any idea?
> 
> >
> > regards,
> > Simon
> >
> > [1]:
> >
> 
> https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image/view/head:/ubuntu-device-flash/snappy.go#L116
> 
> <https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image/view/head:/ubuntu-device-flash/snappy.go#L116>
> >
> 
> 
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io <mailto:Snapcraft@lists.snapcraft.io>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> <https://lists.ubuntu.com/mailman/listinfo/snapcraft>
> 
> 
> 
> 
> -- 
> - Loïc
> 
> 


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

Re: New ubuntu-device-flash cannot use own gadget snap?

[Simon Fels]

On 31.08.2016 10:49, Yann Sionneau wrote:
> Hello,
> 
> It seems the new (snapp'ed) ubuntu-device-flash cannot use my own gadget
> snap anymore.
> 
> yann@imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16
> -o snappy.img --channel edge  --gadget $PWD/../../../xxx_2.0_all.snap
> --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os
> ubuntu-core --developer-mode --enable-ssh
> cannot use
> "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../../xxx_2.0_all.snap",
> must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2"
> "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"]
> 
> Is porting Snappy on non official devices not supported anymore?

No, that is not the case.

> How is it supposed to work now? I must confess that I am blocked in my
> work because of this change, I cannot generate nor flash images anymore
> and my project is thus stalled :/

We're currently in a phase where ubuntu-device-flash is still being used
but the future will be a new tool called ubuntu-image which will allow
you to create images in a much better way.

>From what I got from Michael a lot things are currently hard coded
inside ubuntu-device-flash. See [1] for the relevant code bits.

You can override the sanity check for the gadget names with setting
UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the command
line you're executing. Didn't tested this but maybe Michael can comment
how this should work.

regards,
Simon

[1]:
https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image/view/head:/ubuntu-device-flash/snappy.go#L116

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

Re: Snappy on OpenSwitch

[Simon Fels]

Hey Mike,

> I'm very interested in adding Snappy support to OpenSwitch
> (www.openswitch.net ).
> 
> OpenSwitch is a Network Operating System for network switches build upon
> OpenEmbedded/Yocto/Poky.

Pretty nice idea!

> I'm using a branch of OpenSwitch in which they've upgraded to Yocto 2.1
> - https://github.com/open-switch/ops-build
>  branch
> "feature/yocto_2.1".
> 
> I've added meta-snappy to the bblayers.conf file used to build
> OpenSwitch and I was able to successfully 'bitbake snappy-demo-image' so
> that I at least know your meta-snappy layer is compatible with the
> OpenSwitch layers.
> 
> My knowledge of OE/bitbake is limited and I'm hoping someone could
> provide some pointers or guidance to integrating Snappy onto an existing
> OE/Yocto distribution such as OpenSwitch.

You already did the first step and verified the build of the relevant
components (snapd and snap-confine) works well in OpenSwitch.

The next step is to get the different config options for the kernel into
your kernel defconfig. We have various sample kernel trees at [1] which
you can use as reference. In meta-snappy I extended the default
linux-yocto defconfig with the bits listed in [2]. I suspect OpenSwitch
may use a different kernel tree so you have to apply the different
options for it as well. You don't need any AppArmor related patches if
you want just unconfined snaps working for a first step.

As next thing you have to add snapd and snap-confine to the content of
the OpenSwitch image. Adding snap-confine and snapd in [3] is ok to get
it things working. Later you want to add a packagegroup especially for
snappy which I am planing to add to meta-snappy which then will
automatically pull in all necessary dependencies for you.

Once that is done you should be able to build a regular OpenSwitch
image, flash it on a device or boot it in an emulator and should have
snapd running and being able to install snaps and run their applications.

If you need further help or have questions, just ask here or ping me
(nick morphis) on IRC in #snappy on FreeNode.

regards,
Simon

[1]: https://github.com/snapcore/sample-kernels
[2]:
https://github.com/morphis/meta-snappy/blob/master/recipes-kernel/linux/files/snappy.cfg
[3]:
https://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/meta-distro-openswitch/recipes-core/packagegroups/packagegroup-openswitch.bb?h=feature/yocto_2.1


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

Re: Using sudo from within a snap

[Simon Fels]

On 06.08.2016 15:54, Chris Wayne wrote:
> Hi guys,
> 
> I seem to be having some issues while running anything as sudo from within a 
> snap (namely bug 
> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292).  

If you package sudo within your snap snapcraft will strip the necessary
suid bit from it so it wont work anymore. Only way to use sudo is to use
the one from the core snap.

> Is this something that's expected to work, or is this out of scope (it does 
> work 
> if you run the snap itself with sudo, although then it's a bit annoying as 
> you're hit with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558).

We should fix this so that a sudo  works rather than
putting sudo in a snap or use it from there. You could also check in
your binary if its started as root and if not abort.

regards,
Simon


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

Snaps on Yocto/OpenEmbedded

[Simon Fels]

Hey everyone,

after an idea during the sprint in Heidelberg I've quickly created a
meta-snappy layer for Yocto/OpenEmbedded which now brings snaps to any
Yocto/OpenEmbedded based operating system (assuming it runs systemd).

The relevant git repository and instructions how to get started are
available at

https://github.com/morphis/meta-snappy

If you find any problems I am happy to review and accept pull-requests!

Happy hacking!

regards,
Simon

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

Re: Overriding seccomp policy: shm_open

[Simon Fels]

On 01.08.2016 06:55, Jacob Zimmermann wrote:
> Hi
> 
> I'm trying to get my hands on snapcraft by building a snap of "Hatari"
> (Atari ST emulator). I got it working nicely in devmode but it won't run
> under strict confinement, specifically it gets killed when attempting to
> execute shm_open().
> 
> Based on whatever little information I could gather I tried to override
> the default policy like so:
> 
> apps:
>   hatari:
> command: hatari
> plugs: [home, unity7, hatari-permissions]
> 
> ...
> 
> plugs:
>   hatari-permissions:
> type: old-security
> security-override:
>   syscalls: [shm_open]

The old-security interface is not available any more. To be able to
further comment on the problem you hit here it will be good to know for
what the Hatari emulator wants to use the shm_open syscall.

> But no avail, it just won't let it use this syscall. I couldn't find
> anything in the docs about how is it supposed to be done.

To allow your snap to use the syscall shm_open it needs to use an
interface which allows this. Its very likely that in this case there is
no appropriate interface yet. As stated above we need to first find out
what the emulator tries to do with shm_open here before we can judge
further what kind of interface it would need.

regards,
Simon


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