Re: ANN: snapcraft 2.28 has been released

[Mark Shuttleworth]

What a great release, thank you! Only one request:

On 30/03/17 20:54, Sergio Schvezov wrote:
> ### sources
>
> Sources, thanks to an external contributor, can now make use of a new entry, 
> `source-checksum` which can be added to sources that can be hashed, the 
> format is the following: `source-checksum: /`. These are 
> the supported algorithms:
>
> - `md5`
> - `sha1`
> - `sha224`
> - `sha256`

Please cull those from the acceptable digests, they are the Fake News of
cryptographic reassurance ;)

Mark

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

Re: is it the gadget snap upgradable?

[Mark Shuttleworth]

On 24/03/17 21:13, Nicolino Curalli wrote:
> I have a doubt.

That is my third favourite line in my favourite movie :)

> It seem that a gadget can't be upgraded during the lifetime of a
> supported board.
>
> I don't find anything in the snap framework for making it in a
> transational manner: is my mindset wrong?
>
> Thank in advance for any clarification.

All snaps are just snaps, they can all be upgraded. That is the vision,
but there may be bugs :)

The gadget snap is of course special which means we may need additional
logic in snapd during upgrades. But it is very definitely our intent
that you can upgrade the gadget snap for your device just as easily as
any app on the device.

Note though that it is the *kernel* snap that I would associate with the
*board*. The gadget snap is more for the specific device in question.

As an example, you might see a robot, and a drone, and a switch, and a
GPS all using an Intel Joule board or a Raspberry Pi. They could all
have the same *kernel* snap because they are all the same board. But
they would have different gadget snaps which describe for example the
pattern of GPIO breakouts or the specific usage of particular serial
ports. The gadget snap would know for example "there is a GPS on ttyS1"
but the kernel snap doesn't because the board is general but the device
is specific.

Mark


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

Re: Handling versioning of platform snaps

[Mark Shuttleworth]

Snaps have a much stronger sense of identity. They *own* /snap/foo and
that means you can build a much more predictable and reliable view of
their behavior. Versioning is a key part of the snap story, it gives the
user and the publiisher of the software a really *great* way to describe
what they are releasing or what they are conuming on any particular
device. The upstreams and the users that I have talked to generally say
they *love* it.

The fact that we know exactly where a snap is allows for rich interplay
between snaps, like the way snaps can use the core snap, or other snaps
through content interfaces.

However, all of these things also required that we choose not to mount
snaps in arbitrary locations. That ends up driving the requirement that
you have administrative rights on a device if you want to change the set
of installed snaps, and also that you can only have one active version
at a time.

In the case of libraries and frameworks, you don't have to worry about
persistent data that can or cannot be shared between the two versions.
You would need to know the two paths of the two versions *anyway* in
order to use them. THere is no semantic difference in your code between
/snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be
more complex one way or the other.

Mark

On 07/03/17 10:07, Tim Süberkrüb wrote:
> Hey Sergio and Mark,
>
> thanks very much for your help.
>
> After discussing different possible solutions in the team and the
> conversation on rocket chat I think that this is probably the best
> solution currently possible. We also considered other ways like
> placing different library versions in the platform snap but that would
> be in the end much more hassle and much more hacky than separating them.
>
> Nevertheless, I still think there could be a better and more
> convenient solution for this use case though - at least in theory.
> Sergio explained to me that it is not possible to have different
> versions of the same snap active, which is - I assume - the main
> reason why it's impossible to use different versions of the same
> runtime/platform snap, while Flatpak offers this functionality.
>
> I'm not familiar with the technical details of snap. There might be
> technical or other reasons why this is not something snap should
> offer. But if it is possible, I think it would be very reasonable to
> allow snaps to specify a specific version for a content interface plus
> being able to have separate versions of the same snap installed as
> long as another app depends on it.
>
> This would - if implemented flexible enough - not only benefit our
> specific use case but anyone who would like to control versioning of
> snaps connecting with the content interface (e.g. a snap that supports
> specific plugin versions of some sort of extension).
>
> Again, this is just a suggestion, that I as a user without much
> knowledge about the internals find reasonable. This might not fit in
> the concept of snaps for a good reason.
>
> Thanks for bearing with me!
>
> > [...] garbage collect all the liriosX-1 snaps that are not connected
> to anything (or whatever number makes sense with rollbacks and current
> garbage collection rules
>
> I think that would be good to have!
>
> Have a nice day,
>
> Tim
>
> On 07.03.2017 14:55, Sergio Schvezov wrote:
>> On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote:
>>> Hi Tim
>>>
>>> Welcome aboard, and thank you, this is exactly the type of question we
>>> want to be solving together on this list.
>>>
>>> The simplest approach would be to insert a major version/ABI indcation
>>> in the platform snap name. Something like lirios3 and lirios4 would
>>> be a
>>> very explicit way to provided different versions of your libraries. It
>>> would have the major benefit that both platform snaps could be
>>> installed
>>> at the same time, too, enabling a more natural app transition (each app
>>> can choose when to hop from 3 to 4) rather than a big-bang flag day for
>>> each device. The downside would be the incremental size of having both
>>> installed at once during that transition, but we continually see that
>>> 'time is more precious than disk space' so giving users a low-friction
>>> way to 'just work' is more useful than saving 0.2 GB of their 1 TB
>>> disk.
>>>
>>> It might be worth looking into the linking of apps to particular
>>> tracks,
>>> but this raises a lot of tricky questions that I suspect would be a
>>> swamp with more problems than solutions.
>>>
>>> Does that sound like a reasonable starting point?
>> This is what I suggested during the rocket chat conv

Re: workaround for connect no autoconnect interfaces without login on system

[Mark Shuttleworth]

On 07/03/17 07:05, Nicolino Curalli wrote:
> A question for go ahead from my side:
> how can I request the store to add an auto connection statement to the
> snap declaration assertion ?

On this list, just outline:

 * the top-level binary name you think should be claimed
 * why that is unlikely to conflict with other potential snaps

As an example, something like 'etcdctl' is very unlikely to conflict
with anything other than a snap of etcd. And something like 'vi' is very
likely to have a LOT of people thinking hard about how to manage
conflicts. If in doubt, snap.command is still the best way to avoid
conflicts altogether.

Mark

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

Re: Handling versioning of platform snaps

[Mark Shuttleworth]

Hi Tim

Welcome aboard, and thank you, this is exactly the type of question we
want to be solving together on this list.

The simplest approach would be to insert a major version/ABI indcation
in the platform snap name. Something like lirios3 and lirios4 would be a
very explicit way to provided different versions of your libraries. It
would have the major benefit that both platform snaps could be installed
at the same time, too, enabling a more natural app transition (each app
can choose when to hop from 3 to 4) rather than a big-bang flag day for
each device. The downside would be the incremental size of having both
installed at once during that transition, but we continually see that
'time is more precious than disk space' so giving users a low-friction
way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk.

It might be worth looking into the linking of apps to particular tracks,
but this raises a lot of tricky questions that I suspect would be a
swamp with more problems than solutions.

Does that sound like a reasonable starting point?

Mark

On 06/03/17 10:01, Tim Süberkrüb wrote:
> Hey everyone,
>
> as a member of the Liri OS project  I'm
> working with our team towards providing our applications as snap
> packages. All our apps depend Qt and our custom UI framework (Fluid).
> Because of that we considered creating a platform snap similar to the
> ubuntu-app-platform
> 
> as a good way to bundle our dependencies and minimize disk space
> usage. To archive this we're using the content interface (see
> snapcraft.yaml
> ).
>
>
> However, while evaluating this option, we considered the following: It
> is inevitable that we will at some point have to break compatibility
> of the libraries present in our platform snap. Because of different
> release schedules it is unlikely though that we would update all apps
> at the same which would result in breaking them as soon as the user
> downloads an incompatible update of the platform snap.
>
> As discussed on rocket chat
> , we are looking for ways
> to solve this problem. Our initial assumption was that the content
> interface would allow having separate versions of the platform snap
> installed as long as one installed app requires it. But this appears
> to be not possible by design.
>
> However, it seems possible that tracks and channels
>  could provide a
> solution to this problem. This would allow us to use a separate track
> for incompatible platform snap versions if there is a way to specify
> for the individual app snaps which track they expect for the content
> interface (like it is possible to set the "default-provider"). Is
> there such an option? If not, would this be a possible addition to
> snap in order to allow use cases like this? Or is there a better way
> to solve the detailed issue?
>
> Thanks in advance for your help!
>
> All the best,
>
> Tim
>



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

Request for etcdctl alias autoconnect

[Mark Shuttleworth]

Hi folks

The etcd database includes a client utility, etcdctl, which is included
in the etcd snap as etcd.etcdctl.

I'm writing to the list to proposed that be aliased to the top-level
etcdctl on installation of etcd by default. The name of the utility is
very distinctive and highly unlikely to conflict with any other use of
the name.

Thank you,

Mark



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

Re: First Snap ktouch - no success

[Mark Shuttleworth]

On 03/03/17 16:56, Harald Nikolisin wrote:
> However - my naive expectation on snaps is that I install only(!) the
> application without bothering which other SW is needed to run it. Am I
> wrong with that?

Snaps allow for completely self-contained apps, yes. But they also allow
the publisher of the app to CHOOSE if they want to consume some
libraries from the core snap (common) or from another snap (less common).

The benefits in snap size are very substantial when you have a large and
very well maintained piece of infrastructure like KDE, but it does mean
you have to trust that upstream to do the maintenance very well.

The use of such a dependency is a choice we leave to the respective
communities. Since this capability is new we have not added the code to
bring in such frameworks automatically, but once we understand the
patterns of behaviour for both users and publishers then I think we will
do so.

One last thing - there is a mechanism for publishers to *validate* a
framework, which means that you will know the app has been tested with
that version of the framework.

Mark


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

Re: pro tip: use scriptlets instead of custom plugins

[Mark Shuttleworth]

On 20/02/17 15:22, Olivier Tilloy wrote:
> One thing that bit me is that I was expecting the 'install' scriptlet
> to replace the `make install` step when using the make plugin, but it
> doesn't. It runs `make`, `make install`, and then the install
> scriptlet. Note that the documentation is reasonably clear about it,
> but it looks a bit counterintuitive to me.

Right, it seems the scriptlet names should rather be of the form
"pre-install" and "post-install" etc, since the plugins still seem to
get invoked. When you look at it that way the current scriptlet names
are quite misleading. Super-useful, just awkwardly named.

It also seems, in that light, that we could have just been been rigorous
about giving you the ability to stick a scriptlet before and after each
step in the pipeline. Instead it's a bit of ad-hocness.

Mark

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

Re: Determining the set of snapd capabilities

[Mark Shuttleworth]

On 19/02/17 12:07, Joseph Rushton Wakeling wrote:
> This would be super-useful.  Conversely, to what extent might it be
> possible to guide the package developer to a clear understanding of
> what capabilities a particular snap package assumes?

Hmm... that's a Turing-complete problem :)

However, a useful approach would be to run the snap through an automated
test process using a range of supported platforms. For example, spinning
up VMs of snapd-supporting distros, and testing the snap there.

As a precursor to that we would want to have health mechanism which
provide a standard way to know if a snap considers itself healthy. Then
we could run a service for developers which screens a snap for health
across a wide range of devices and VMs, including the commonly used
versions of snapd in those environments, to pick up potential problems
and make such recommendations.

Mark


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

Determining the set of snapd capabilities

[Mark Shuttleworth]

We have a nice mechanism to ensure that snaps which use newer
capabilities don't end up on systems with older snapd's that don't
support those capabilities, which is the 'assumes' keyword. This email
is a proposal to make that usable.

The mechanism is mentioned in the snapcraft docs at
https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md
which is published at https://snapcraft.io/docs/build-snaps/syntax but
not clarified anywhere else that I can see. I have been unable to find a
list of the available capabilities that can be assumed. Whatever else is
true, the fact that I couldn't find it despite the help of the AIs at
Google suggests that we can improve the discoverability and usefulness
of this potentially very useful capability :)


Step 1, show what capabilities a snapd offers.
https://bugs.launchpad.net/snapd/+bug/1665995

'snap --version' is a nice way to know what versions are relevant for a
particular system. That would be a good place to show the capabilities
that can be assume'd for snaps being installed on that system. It
doesn't require a new command and it is in many ways more relevant to
developers than the particular version. At least, the intent of
capabilities is to have fewer version-specific dependencies, and more
capability-specific dependencies!


Step 2, reference 'snap version' in the docs

The existing docs for snapcraft.yaml and snap.yaml should both make
clear reference to 'snap version' as a way to discover these
capabilities. Also, there should be express documentation on each of
them, organized as such. So the docs should say "use 'snap version' to
see what a particular system supports, and see  for documentation
about each of those capabilities". That documentation should explain any
constraints or usage of the capabilities.


Step 3, introduce capabilities as 'beta-capability'

When we land new features, there are often rough edges. For example,
there is a new capability to support direct setting of environment
variables in snap.yaml which is super useful (many snaps have wrappers
just to do this, so that's one less layer needed in the common case :)).
However, there is a bug in the implementation which means you sometimes
get a newline on the environment variable, which is unhelpful. I think
this should be a beta-capability till we know it is fully fleshed out.


Step 4, announce new capabilities on the list

In many cases, the existence of a new capability is meaningful for a
large number of snapcrafters, lets share the beta documentation on the
list when the capability lands in a --proposed or --candidate release of
snapd+snapcraft.


Step 5, nobody expects the Spanish Inquisition.


Mark



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

Re: Is there a way to prompt users to connect a non-auto-connect interface during installation?

[Mark Shuttleworth]

On 12/02/17 09:30, Aaron Hampton wrote:
> I am working on snapping a desktop application that needs access to
> hardware-observe. Is there a way to prompt the user to connect the
> interface during the installation of the snap? Or is the only way to
> have the user run snap connect?
>
> I found this comment:
>
> "
> Just to state the plan of record, we intend that store assertions can
> pre-approve some auto-connection, or cue up a prompt for interactive
> installations where the user is asked if they want to connect.
> So in your case, the experience should become something like:
>
>   $ sudo snap install handbrake
>   Allow 'handbrake' to access DVDs? (Y/N) Y
>   handbrake 1.3.2 installed
> "
> In this thread:
> https://lists.ubuntu.com/archives/snapcraft/2016-October/001281.html
> That's exactly the type of interaction I'm looking to implement, but I 
> haven't been able to find any more information about it. 
> If that's not available yet, is there any other recommended method for 
> connecting interfaces that might be a little easier for less knowledgeable 
> end users? 

OK, there are three pieces you need, one of which is now in place.

We already have a way for the store to tell a device to auto-connect
some interfaces. We don't afaik yet have a way for the store to prompt
the user (i.e. offer the user a pre-defined CHOICE of connections). That
will require some thinking about UX, to define how the interfaces should
be offered, what language to use, where the appropriate descriptions of
the interfaces should be stored, how we will handle translation etc.
This is an interesting problem because we are determined to avoid
techno-choices ("connect core:db-access to flubber:funkyjohn?") that
don't mean things to end users. That means we need a way to offer the
choice which provides a reasonable basis for a correct decision by
less-than-average-insightful users. And finally, we need to design and
implement how that get expressed in the desktop GUI from a store like
GNOME Software or the KDE equivalent. That latter piece will probably
use all the hard thinking about UX from the CLI version, but obviously
it's a separate bit of work to express it in the GUI.

I would look to the core team to lead the CLI UX work, which can be done
in a shared google doc.

It would be up to the desktop GUI folks to figure out the expression in
the desktop.

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

Re: Git commit+

[Mark Shuttleworth]

OK, glad it's a known issue.

The 'source-type: git' piece didn't fix anything for me, though, I still
see the dirty-commit version number.

snap/snapcraft.yaml contains this:

parts:
  keepalived:
plugin: autotools
source: .
source-type: git

What am I missing?

Mark

On 11/02/17 16:34, Leo Arias wrote:
> Hello!
>
> This is bug: https://bugs.launchpad.net/snapcraft/+bug/1662388
> We will discuss if removing the yaml is needed at all. But in the
> meantime, add source-type: git.
>
> pura vida.
>



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

Git commit+

[Mark Shuttleworth]

Hi folks

In a branch with a snap/snapcraft.yaml I am seeing that git reports a
version with a dirty commit (suffix+) for snaps built from the branch.
Is there a way to prevent this, or is snapcraft doing something during
the snapping process which will cause git to think the checkout is dirty?

Mark


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

Re: Is there any way to list all of the configure options for a snap application?

[Mark Shuttleworth]

I think the intent is that a snap has a config schema which can be used
for both validation and self-documentation of config items.

Doing that tastefully is worth the wait :)

Mark



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

Re: launchpad snap recipe fails with classic confinement

[Mark Shuttleworth]

On 09/02/17 19:43, Sergio Schvezov wrote:
>> Oh, in fact, that looks just about perfect for us.  With that patch I
>> think LP could just export SNAPCRAFT_SETUP_CORE=1 when building snaps,
>> right?
>
> Absolutely correct. If you enable this in staging I can give it some
> test runs.
>

Somehow I think this will rock :)

Mark


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

Re: snapd available in Trusty Tahr

[Mark Shuttleworth]

On 07/02/17 21:31, Manik Taneja wrote:
>
>
> On Tue, Feb 7, 2017 at 12:36 PM, Mark Shuttleworth <m...@ubuntu.com
> <mailto:m...@ubuntu.com>> wrote:
>
> On 07/02/17 20:17, Thomas Voß wrote:
> >
> 
> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724
> 
> <https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724>
> > was released to the updates pocket today.
>
> Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems,
> cloud or desktop, would be welcome. Pick a favorite snap and take
> it for
> a spin.
>
> The experience is very clean now. I just tried on AWS and have
> RocketChat up and
> running-
>
> Inline image 1
> Kudos to everyone involved in delivering this!
>

Also my favorite snap :)

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

Re: snapd available in Trusty Tahr

[Mark Shuttleworth]

On 07/02/17 20:17, Thomas Voß wrote:
> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724
> was released to the updates pocket today.

Congrats! Quick feedback from folks with Trusty (14.04 LTS) systems,
cloud or desktop, would be welcome. Pick a favorite snap and take it for
a spin.

Mark

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

Re: connecting a non-auto interface, automatically

[Mark Shuttleworth]

On 07/02/17 14:43, Simon Fels wrote:
> On 07.02.2017 15:36, knitzsche wrote:
>> What is the approach to connect interfaces that are not auto-connecting
>> without user intervention?
>>
>> That is, there's a snap (built into an image) that declares the
>> log-observe plug. Log-observe interface does not auto-connect [1]. In
>> this product, the user does not have a console, so they cannot connect
>> the snap plug/interface.
>>
>> So, how does one configure the system to connect sthis? Via the gadget
>> snap prepare-device hook script perhaps?
> You can ask at the store level to get a snap-declaration for the snap
> which allows auto-connection of particular plugs just for your snap.
>
> I am not sure if this can be store/brand/model specific.

...and IIRC the intent is that the gadget snap should allow you to
specify this behavior on your own device, regardless of store policy.

In short:

 * if you made the device, you decide
 * if you own the device (you have root), you decide
 * otherwise, the store sets default behavior

Mark

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

Re: dlopen cannot load shared library

[Mark Shuttleworth]

On 03/02/17 12:41, Loïc Minier wrote:
> Hi,
>
> On Fri, Feb 3, 2017 at 11:20 AM, Roberto Mier Escandón 
>  > wrote:
>
> I'm having a problem with a snap which start certain daemon when
> installed. This daemon tries to load certain shared library but
> it's not
> able to do it even in devmode [1]. However it loads it well in classic
> mode. The library is in a rw path, provided directly to a dlopen
> method
> [1]. Have anybody hit this kind of issue before?
>
>
> In classic mode, you see libraries from your classic Ubuntu system
> including X11; in devmode/confined mode, you only see system libraries
> from the core snap which doesn't contain X11.
>
> I suggest you embed X11 and other libs that your dlopen-ed library
> depends on.

Loic is correct, but let me give a slightly less compressed answer :)

The snap sees a filesystem that is constructed specially for it, out of
a bunch of other filesystems. Just like you can mount a set of disks at
particular paths, for the snap, a set of "disks" are mounted at
particular locations. So what the snap processes "see" as their disk is
specially constructed just for that snap.

In the case of a devmode or strictly confined snap, the root of the
filesystem ("/") is the core snap. That is a tiny heart of Ubuntu (in
future could be Fedora or Debian too) that just has the very core
libraries and binaries. It does not have X11 or any desktop libraries.

So when you switched to devode, your snap processes stop seeing your
"normal hard disk" at / and start seeing the minimal core snap at /.

If you 'ls -l /snap/core/current' on a classic desktop you will see the
filesystem that your snap sees at /. There are no X libraries there :)

That's why you need either:

 * to bundle your X libraries. snapcraft will try to do this for you
automatically. if you are handcrafting your snap then you need to pay
attention to the files in the snap and the loading paths that the linker
uses.

 * to use libraries from another snap which might have shared content
that lots of snaps reuse, in which case if that other snap changes you
might break

Hope that's clearer,
Mark
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Creating system users and system groups

[Mark Shuttleworth]

On 02/02/17 14:52, Colin Watson wrote:
> You might like to use
> https://anonscm.debian.org/cgit/d-i/user-setup.git/tree/reserved-usernames
> as part of this; d-i and ubiquity both use that as a way of saying "you
> can't use that username because it'll conflict with well-known system
> users".  It doubtless won't be complete (it doesn't currently contain
> avahi, for instance), but it should be a useful starting point.
>

Let's definitely use that as a definitive reference, thanks Colin.

I think we may want to go further and assign specific UIDs, too.

Mark


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

Re: Testing a snap for lnav (log file navigator), publishing

[Mark Shuttleworth]

In general, strict confinement is better. In this case, if you are
confident that the logs which matter will be in /var/log, then yes it
would be better to have strict confinement with an interface that allows
reading from that location.

Mark

On 02/02/17 13:11, Simos Xenitellis wrote:
> Hi All,
>
> I created a snap for lnav and I attach the snapcraft.yaml file.
>
> I plan to use the "classic" confinement in the final version.
> Would that be advisable or should I change to permit only to open log
> files from /var/log/?
>
> According to the documentation, I am asking here for comments (so as
> to appear later in the  stable channel).
>
> Simos
>
>

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

Re: Currernt config hook implementation scales very badly

[Mark Shuttleworth]

On 02/02/17 10:23, Oliver Grawert wrote:
> just as a side note, this works for all basic python stuff
> (wrappers/config etc), but not if you use any complex modules. 
> in that case you should indeed ship python in your snap using a python
> plugin in snapcraft.yaml and include the necessary modules in your
> snap.

Yes, my primary point was that if we are going to offer some standard
helper modules, I would suggest those be in Python3 using only the
pieces available in the core which is always available. That way, with
minimal overhead, config capabilities can be improving constantly for
all snapcrafters.

Mark



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

Re: Creating system users and system groups

[Mark Shuttleworth]

Our general thinking is that we will maintain a standard list of those,
and approve user creation for specific snaps. Would you be willing to go
with _avahi and _lp and _lpadmin? Backward-looking names might get
grandfathered, but we'd prefer newer software to use a qualifier like _
to disambiguate such system users from end users.

Mark

On 02/02/17 08:36, Simon Fels wrote:
> Hey Till,
>
> That is (as far as I know) not possible today. Those groups and users
> have to exist beforehand. A similar problem also exists for LXD. There
> is a bug at https://bugs.launchpad.net/snappy/+bug/1606510 which has a
> few more details.
>
> regards,
> Simon
>
> On Wed, Feb 1, 2017 at 9:56 PM, Till Kamppeter
> > wrote:
>
> Hi,
>
> I want to snap CUPS and for that also to snap avahi-daemon.
>
> A problem I am running into is that these services use special
> system users and groups. avahi-daemon uses the user "avahi" and
> CUPS uses the user "lp", and the groups "lp" and "lpadmin".
>
> How can I make my snap create such users and groups on install and
> remove them on uninstall?
>
>Till
>
> -- 
> 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: ERROR cannot deliver device serial request: unexpected status 400

[Mark Shuttleworth]

On 02/02/17 10:27, Oliver Grawert wrote:
> hi,
> Am Donnerstag, den 02.02.2017, 10:01 +0100 schrieb Ara Pulido:
>>  
>> Your device is trying to get a serial assertion from the Ubuntu
>> servers, but your model is not one of the Ubuntu official ones, so
>> that is not possible.
> AFAIK it is possible if both, gadget and kernel snaps are in the store
> and signed by the same key that was used by the model assertion (i.e.
> owned by the same user). at least that is my experience with the
> beaglebone black image that i produce.

Am not sure what's causing the specific issue you see, but Ogra is
describing the expected behaviour, which is that you can push a kernel
and gadget snap and then your own model assertion which binds those
together and is the basis for the image builder.

We are working with the hardware companies to ensure that building a
kernel snap is trivial for their hardware. Certified board will have
official kernel snaps that anybody can "just use". Of course, if you
want to modify the kernel for an official board you can also just build
your own kernel snap.

I know there is some work outstanding to get all of those pieces
working. There are some tricky corner cases (for example, what if you
want to change kernel snap entirely by issuing a new revision of your
model-assertion?) but it shouldn't be long before everything is in place
to enable all of that for straightforward cases.

Mark



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

Re: Currernt config hook implementation scales very badly

[Mark Shuttleworth]

We definitely want some sort of "dry-run" capability, where you could
present a snippet of YAML covering a subset of config and learn whether
that would result in a healthy config, and what changes it would
actually imply.

Mark



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

Re: snapd available in Trusty Tahr

[Mark Shuttleworth]

On 31/01/17 13:01, Jamie Bennett wrote:
> The team are pleased to announce that, after extensive testing in proposed, 
> snapd is officially available in the Trusty Tahr updates archive [1]. If you 
> are running a 14.04 system we encourage you to give it a try and report any 
> issues [2]. Thanks to all involved in making this happen.

The work involved in getting snapd onto 14.04 will also help enable
snapd on non-systemd distros, so testing a range of snaps would be very
useful. Thanks!

Mark

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

Re: Snap package licenses

[Mark Shuttleworth]

On 26/01/17 23:58, Neal Gompa wrote:
> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth <m...@ubuntu.com> wrote:
>> We should allow a plaintext field there for this situation. Yes, go
>> ahead with "Other open source".
>>
> It would probably make sense to support SPDX license tags and
> expressions[1].
>
> [1]: https://spdx.org/licenses/
> [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List


+1


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

Re: Snap package licenses

[Mark Shuttleworth]

We should allow a plaintext field there for this situation. Yes, go
ahead with "Other open source".

On 26/01/17 22:14, Joseph Rushton Wakeling wrote:
> Hello all,
>
> I'm just about to upload the ldc2 snap, but have one last question
> first.  LDC itself is released under the terms of the BSD license, but
> some components it links to are released under other licenses (Boost,
> Artistic License and LGPL). All of this is covered under the
> setup/license.txt file.
>
> However, the submission form wants a specific license.  Would BSD be
> adequate in this case or is it better to specify 'Other open source'
> ... ?
>
> Thanks & best wishes,
>
> -- Joe
>



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

Re: Classic confinement success for LDC D compiler

[Mark Shuttleworth]

On 26/01/17 21:04, Joseph Rushton Wakeling wrote:
> Question about setting up a developer account to start publishing: is
> it possible to create a 'group' account with multiple members to act
> in the name of the LDC project?  Or should I just create a single
> developer account and add the email addresses of others who are
> interested in having account access?


The plan is that there will be a mechanism for the publisher to list
accounts that can push and release revisions.

For now I would suggest you use your own account until we have that,
then we can move to something more representative.

Congrats! This will be lovely for the D crowd.

Mark


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

Re: Relationship between snaps and containers, if any

[Mark Shuttleworth]

The best way to think of this is to know that snaps are GREAT when you
have a precise 1:1 relationship between "machines" and "running
instances". And Docker is GREAT when you want an elastic relationship.
So for example, if you want a MySQL "appliance" on a device, there will
only ever be 1 MySQL instance on that device, you want a snap. If you
want a cluster where there may be 1-many instances of MySQl on each
actual machine or VM, then you want Docker.

The reason for this is that Docker gives each running process its own IP
address. That's perfect for the hyper-elastic case - each extra MySQSL
is just another IP address to talk to. But if you have a machine where
you already have an IP address and all you want is a MySQL there then a
snap will be easier.

This is why a snap of the Docker daemon makes such sense - in your
cluster, you want exactly one copy of Docker itself running on each
machine, and that is best pulled in as  a snap. That docker process then
manages an arbitrary number of docker processes on each machine.

Make sense?
Mark




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

Re: Snap install apparmor error: 'profile has merged rule with conflicting x modifiers'

[Mark Shuttleworth]

On 20/01/17 15:36, Joseph Rushton Wakeling wrote:
> Does this mean that classic snaps automatically have network access? 
> In any case it looks like requesting it explicitly causes a problem in
> generating the appropriate apparmor profile.


Yes, we're untangling the confinement logic at the moment, so for now
drop plugs and slots from classic snaps. The intent, though, is that you
can add them safely and test with --jailmode as part of your journey to
strict confinement.

--jailmode is the opposite of --devmode, it lets you impose the
confinement with plugs and slots in cases (like --classic) where that
confinement would not automatically be imposed.

Mark


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

Re: Ubuntu Core: how the file-system works

[Mark Shuttleworth]

On 20/01/17 08:03, Luca Dionisi wrote:
> If I understand it correctly, an unconfined app will be able in the
> system
> to do whatever my standard user would be able to. For instance, if I
> log into my ubucore16 (the name of my KVM instance) and issue:
>  sudo sysctl net.ipv4.ip_forward=1
> -or-
>  sudo ip address add 10.0.0.10 dev eth0
> it reports success. Thus, if I run an unconfined app which tries to do the
> same it will succeed. Whilst a strictly confined app would not, if it is
> not hooked to a certain capability.
> So far, so good?

Ubuntu Core is confined-snaps-only. Ubuntu Classic allows less confined
snaps.

The commands you're wanting to run should be fine, though, with the
right interfaces in place for your confined snap on Ubuntu Core. I think
you meant that when you said 'hooked for a certain capability'. The
devmode confinement should also be a useful workaround in your
development process.

Mark

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

Re: Ubuntu Core: how the file-system works

[Mark Shuttleworth]

On 20/01/17 06:33, Luca Dionisi wrote:
> Since my "thingy" is going to sport an experimental routing protocol,
> I need
> to change some files on the fly. For instance /etc/iproute/rt_tables. Which
> I already see that is not writeable in my Ubuntu Core install.
>
> Also I am going to use some commands that I haven't yet tested on Ubuntu
> Core. Mostly "ip" and "iptables", also in non-default network namespaces.
> And I don't know if they need internally write-access to some file.
>
> Do you see anything about it that would be infeasible in a Ubuntu Core as
> it currently stands?

That all sounds like stuff we would want to be doable. There are a
number of folks using Ubuntu Core for networking kit, so we are adding
capabilities for that domain all the time. We just recently added
network namespace control.

Generally, you want to think about how best to express config in a way
that easily survives upgrades. Editing something like rt_tables should
be fine. But where you have something that multiple pieces want to edit,
or a set of things which need to line up, we need to design a config
item which drives those things consistently so the device can *never*
end up in a broken state, by design. Make sense?

Mark




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

Re: Ubuntu Core: how the file-system works

[Mark Shuttleworth]

On 20/01/17 05:59, Luca Dionisi wrote:
> First of all I need to understand how the file-system works. Because I
> need to edit some system files.

Ubuntu Core is designed to offer a super-reliable and predictable
upgrade experience, so core system files are often fixed ("immutable").
It will be interesting to know what you need at the base level so we can
expose it as a standard config element.

> My first question to the list is: why don't I see two partitions on
> the disk? I recall having read that Ubuntu Core was able to rollback to
> the previous version of "core" snap thanks to a second partition.
> Do I miss something?

In 15.04 we had an A/B partition system. Now we have evolved to
something much better, which is mountable compressed filesystems. The
A/B filesystems are now single files on the base filesystem. That's
better because it lets us use space much more efficiently, or decide
later we want three or four versions instead of just A/B versions, etc.

Mark


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

Re: Please test my asciinema snap

[Mark Shuttleworth]

Any recommendations for dealing with those?

On 19/01/17 16:20, Michael Hudson-Doyle wrote:
> PYTHONHOME also leaks into the recording environment.
>
> On 20 January 2017 at 13:03, Michael Hudson-Doyle
> <michael.hud...@canonical.com <mailto:michael.hud...@canonical.com>>
> wrote:
>
> This confused me for a
> while: https://asciinema.org/a/2ua1d08k6v8jiyy1m2uyvn8rx
> <https://asciinema.org/a/2ua1d08k6v8jiyy1m2uyvn8rx> (spoiler:
> python3 inside 'asciinema rec' is python3 from the core snap).
>
> Cheers,
> mwh
>
> On 18 January 2017 at 22:16, Mark Shuttleworth <m...@ubuntu.com
> <mailto:m...@ubuntu.com>> wrote:
>
> Hi folks
>
> (For those of you who Gmail does not filter this email on
> as-yet-unexplained-grounds :))
>
> Please could you test my asciinema snap? Asciinema is a
> console video
> recording utility that's great for CLI-diven demos. If you
> want to make
> a quick web video of a CLI / console journey, asciinema is the
> ticket.
>
> An older version (0.9.8) is in 16.04. The new 1.3.0 version is
> now a
> snap, and it should work on 16.04. I am also interested in
> feedback on
> 14.04 for those of you on Trusty steeds who are blazing the
> snaps-on-trusty trail.
>
> It's a 'classic-only' snap, so you need:
>
>   sudo snap install --classic asciinema
>
> Then 'asciinema rec' starts a recording session, and you're
> off to the
> races.
>
> Thanks!
>
> Mark
>
>
>
>
> --
> 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>
>
>
>
>
>

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

Re: Classic confinement success for LDC D compiler

[Mark Shuttleworth]

On 19/01/17 16:18, Joseph Rushton Wakeling wrote:
> On 13/01/17 21:46, Joseph Rushton Wakeling wrote:
>> Hearing about classic confinement was rather exciting given that it
>> seems
>> tailor-made for the use-cases of my current WiP snaps for the ldc2 D
>> compiler
>> and the dub D build system:
>> https://github.com/WebDrake/ldc2.snap/pull/1
>> https://github.com/WebDrake/dub.snap/pull/1
>
> Just to follow up on this: after everyone's help in this thread, I was
> able to adjust the design of my package for the D compiler `ldc2`:
> https://github.com/WebDrake/ldc2.snap/pull/2
>
> As far as I can tell, this fixes all the major issues with the
> original snap package.
>
> The `dub` package manager snap will follow some time soon now I've got
> the hang of things ;-)
>
> Thanks very much to everyone who offered advice and support. 

Congrats! What's the best way to get the D community aware of this?
Sounds like it would be a nice way for them to keep up to date.

Mark

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

Re: Signing snaps with your own keys on your own local store.

[Mark Shuttleworth]

I would suggest you start with classic (deb-based) Ubuntu and make
'classic' snaps. When those are working well you can start devmode
development to add the confinement, which gives you fully confined
('strict') snaps. At that point, you can use Ubuntu Core.

On the store, there are various folks taking different approaches, you
might want to just use the public one for now (you can have private
snaps in there). We'll make it easier to install your own store soon.

Mark

On 19/01/17 07:48, nitin mahendru wrote:
> Hi Everyone,
>
> I am new to the world of snaps and am pretty excited to learn more
> about it.
>
> I am trying to run ubuntu core on a Raspberry pi and I want to
> securely update snaps which run on it.
>
> What I want to do is:
>
> 1. Build my own snap
> 2. upload it to my own instance of a snap store where while uploading
> it can be signed using a keypair that I provide.
> 3. Run snap install on my raspberry Pi to install the snap I uploaded
> into my store. This should involve signature verification with my own
> public key.
>
> I can't seem to find the source code for a snap store. I found this
> https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex
>
> Then I also found this implementation
> https://github.com/noise/snapstore but that doesn't seem to serve my
> purpose.
>
> Do you guys know of a propper implementation for the snapstore ? I am
> trying to get past point 2 above.
>
> Thanks in advance.
>
> cheers!
> Nitin
>
>

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

Re: Please test my asciinema snap

[Mark Shuttleworth]

On 18/01/17 06:41, Dave Morley wrote:
> Not so happy on 14.04 paste.ubuntu.com/23821653/ I get a segfault :( 

Can you report a bug and include 'snap --version' please?

Thank you!
Mark



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

Re: Please test my asciinema snap

[Mark Shuttleworth]

On 18/01/17 06:12, Sergio Schvezov wrote:
> On Wed, 18 Jan 2017 10:40:47 +, Jamie Bennett wrote:
>> On 18/01/17 at 04:19am, Mark Shuttleworth wrote:
>>> ... you may also need to enable xenial-proposed main in
>>> /etc/apt/sources.list to make sure you have the very latest snapd.
>> Yes, classic needs snapd 2.21 from proposed otherwise you will 
>> not be able to
>> find or install the snap.
>>
>> After that, it works a treat [1], thanks.
> Working fine for me as well!


Thank you. Loving this :)

Mark


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

Please test my asciinema snap

[Mark Shuttleworth]

Hi folks

(For those of you who Gmail does not filter this email on
as-yet-unexplained-grounds :))

Please could you test my asciinema snap? Asciinema is a console video
recording utility that's great for CLI-diven demos. If you want to make
a quick web video of a CLI / console journey, asciinema is the ticket.

An older version (0.9.8) is in 16.04. The new 1.3.0 version is now a
snap, and it should work on 16.04. I am also interested in feedback on
14.04 for those of you on Trusty steeds who are blazing the
snaps-on-trusty trail.

It's a 'classic-only' snap, so you need:

  sudo snap install --classic asciinema

Then 'asciinema rec' starts a recording session, and you're off to the
races.

Thanks!

Mark




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

[Mark Shuttleworth]

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
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: snapd and semaphores

[Mark Shuttleworth]

On 10/01/17 08:44, Olivier Tilloy wrote:
> On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge  wrote:
>> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote:
>>> Here is the bug report: https://launchpad.net/bugs/1653955
>> Thanks! The fix is in master and will bi in snapd 2.21.
> Excellent, thanks Jamie for your prompt response!

Catching up on email, I have to say a TON of good stuff landed in 2.21.
Wow. Thank you everybody!

Mark

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

Re: netplan and post-up/pre-down scripts

[Mark Shuttleworth]

On 06/01/17 13:12, Mike Pontillo wrote:
>Long story short: in order to get the behavior I wanted, I wrote a
> custom script that monitors *operational status* (aka physical link
> up/down status), and I launch it using /e/n/i's `post-up`, and bring
> it down using /e/n/i's `pre-down` scripts.
>
>Looking at the `netplan` spec[4], I don't see a way to achieve that
> functionality. I know that many people are using the script-callout
> functionality in /e/n/i to achieve what they need to achieve, so it
> seems to me that having this in `netplan` is critical to achieving
> parity with what we have in Xenial with `ifupdown`.
>
>In an ideal world, I think `netplan` would be able to model my use
> case out-of-the-box.[5] But since we can't expect to model everyone's
> use case, it seems like custom scripting functionality is a hard
> requirement, though perhaps one that could have tricky cross-platform
> implications.

Would 'got-link' and 'lost-link' be good names for this?

Mark

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

Re: [NEWS] Kdenlive devel snap

[Mark Shuttleworth]

On 05/01/17 15:41, Tiago Herrmann wrote:
> Sorry to revive this old thread, but this very same website just
> posted a tutorial [1] on how to manage snaps.
> The maintainer of this website is a friend of mine and he told me his
> goal was to write the most complete snap utilization tutorial
> available in Portuguese.
> He has been doing a great job on spreading news about ubuntu and snap
> here in Brazil.
>
> [1] http://www.diolinux.com.br/2017/01/ubuntu-snap-utilization-manual.html
> or google translation:
> https://translate.google.com/translate?hl=pt-BR=pt=en=http%3A%2F%2Fwww.diolinux.com.br%2F2017%2F01%2Fubuntu-snap-utilization-manual.html
>

Very happy to see how many people are enjoying snaps now!

Those of you who have been thinking about making a snap, I would suggest
you start with a classic snap which should work on 14.04 and 16.04 very
easily. Then you can try to get it fully confined, starting with devmode.

Mark

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

Re: Apparmor error when using classic mode

[Mark Shuttleworth]

On 15/01/17 08:58, Luke Williams wrote:
> Hello,
>
> I have the following error when I try to install my snap in classic mode:
>
> root@ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap
> --classic --force-dangerous  
>  
> error: cannot perform the following tasks:
>   
> - Setup snap "flexswitch" (unset) security profiles (cannot setup
> apparmor for snap "flexswitch": cannot load apparmor profile "snap.flex
> switch.flexswitch": cannot load apparmor profile: exit status 1  
>
> apparmor_parser output:  
>
> profile has merged rule with conflicting x modifiers  
>   
> ERROR processing regexs for profile snap.flexswitch.flexswitch, failed
> to load   
> )
>
> - Setup snap "flexswitch" (unset) security profiles (cannot load
> apparmor profile "snap.flexswitch.flexswitch": cannot load apparmor prof
> ile: exit status 1
>   
> apparmor_parser output:  
>
> profile has merged rule with conflicting x modifiers  
>   
> ERROR processing regexs for profile snap.flexswitch.flexswitch, failed
> to load   
> )
>   
>
> I cannot find any information on why it is failing to install. Any
> thing I should look at to see what is keeping this from working or any
> more information you need to assist in troubleshooting?
>
> I am trying to install this snap on 16.04 Server.

I have a feeling this is when one tries to combine "confinement:
classic" with plugs on commands.

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

Re: Snap portability between different boards?

[Mark Shuttleworth]

... when I say identical, I don't mean arm64 and armhf are identical to
each other of course :) but rather that all armhf boards use the same
userspace, and same for all arm64.

Mark

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

Re: Snap portability between different boards?

[Mark Shuttleworth]

On 05/01/17 20:39, Dan Kegel wrote:
> can snaps built on the pi run on the artik, and vice versa?

They certainly should, yes. We have armhf and arm64 and from a
user-space perspective, modulo things like OpenGL, they are identical.

Mark

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

Re: Correct usage of snapcraft.yaml

[Mark Shuttleworth]

On 05/01/17 15:39, gareth.fra...@cliftonts.co.uk wrote:
> Once again please do forgive my lack of knowledge. Having managed to
> successfully release a snap I am now wondering what the correct thing
> to do is regarding github. My code is there for anyone to obtain, so
> should the snapcraft.yaml be included or is that something one would
> normally keep to themselves? 

Would encourage you to have the snapcraft.yaml in the git tree; it makes
it easier for people to contribute to that. Also, if the code is
evolving, would encourage you to setup Travis or other CI integration so
that you get an automatic edge release for (edgy) users :)

Mark

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

Re: Issues generating snap

[Mark Shuttleworth]

On 04/01/17 13:40, gareth.fra...@cliftonts.co.uk wrote:
> Thank you, that makes perfect sense. I'd also like to say a quick
> thanks for revolutionising my life. Discovered Feisty 10 years back
> and haven't looked back since!


You're welcome, it takes a big community to make Ubuntu happen. I hope
that you find snaps have just as big an impact :) It would be wonderful
if we can really improve the flow of bits from upstreams to users, or
even just make it easier for people to manage private apps that they are
pushing around on their networks.

Mark


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

Re: Snapcraft tool under debian armhf

[Mark Shuttleworth]

On 04/01/17 10:30, Boris Rybalkin wrote:
> Is it possible to get snapcraft tool under Debian?

This should be the easiest possible adaptation, in principle, because
Debian and Ubuntu are so well aligned. If there are patches needed they
would be simple and you can count on us to accept them. Also happy to
have some ongoing CI tests on snapcraft that test its operation on Debian.

Mark

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

Re: rqlite snap packaging

[Mark Shuttleworth]

Happy New Year everyone, and I wanted to bounce this message to the list
because the link has super-useful instructions for those of you setting
up CI-based daily-release-to-edge.

I think Travis is the right starting point if you are using Travis
already, and the Launchpad Builder approach has the benefit for those of
you wanting to provide multi-architecture snaps.

Having an automatic push and release to the edge channel is a GREAT way
to build your developer community, because it lets all your core
contributors and users provide rapid feedback on the evolution of the
tip of your master development branch. We currently have an edge channel
that is suited for development trunk branches, but we will soon have
additional channels with an edge that suits stable branches too. For now
I would recommend just setting up a daily / CI-smoketest based trunk
release to edge.

Mark

On 03/01/17 20:24, Evan Dandrea wrote:
> Happy New Year, Phillip.
>
> You might also be interested in this documentation on how to use
> Travis or Launchpad to automatically build and publish snaps for each
> commit on Github:
>
> http://snapcraft.io/docs/build-snaps/ci-integration


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

Re: Thinking of installing snap on Debian due to scarcity of snap packages for armhf

[Mark Shuttleworth]

Leo, I think we're inadvertently confusing folks by talking about the
two different kinds of "classic" in the same thread, although our use of
the term "classic" for two different things is the root cause.

Luther, there are two different 'classics' in play.

Classic Ubuntu is the deb based Ubuntu, where you install a root
filesystem which deb based, and where confinement is a
mixed-proposition. Snaps can be installed on Classic Ubuntu, they get a
crafted filesystem space that they see depending on the metadata
properties of the snap (they can sometimes see the deb based filesystem,
sometimes they can only see a core snap based filesystem, it depends on
their properties).

Ubuntu Core is the "pure snap" world, where *everything is a snap by
default*. But on Ubuntu Core, you can create a special container (the
"classic mode") where you can use debs.

These two approaches serve different needs.

For developer environments, or in the cloud, it's often convenient to
use debs for the base system. You have a developer to look after the
system and so totally automated updates aren't as important. Also,
there's a high ratio of professionals-to-systems, so admin costs
disappear in that budget (you don't think of yourself as paying a price
for admining your own system, even if in fact there is a cost in time).
So the Classic Ubuntu approach gives us snaps as a convenient delivery
mechanism for newer apps on the older, but familiar and convenient, deb
based filesystem.

For devices, or for very simplistic cloud systems like container hosts,
you want to have a base system that has the very low friction of snaps
by default. Imagine having 10 million home routers out there. Each of
them is very cheap to buy, but it would be expensive to SSH to them
individually and resolve package conflicts. So a pure-snap base system
for devices makes a lot of sense - you have a few apps that you care
about, and you want the lowest possible friction across millions of
those devices while preserving security and the ability to updates them
easily.

So Leo was talking about the "classic mode" (container) on a "pure-snap
Ubuntu Core" device. I was talking about "snaps on a classic (deb-based
root filesystem) Ubuntu".

Make sense?

In your case, I think my approach will be better for you. Use vanilla
Ubuntu Server (deb based and familiar) then use snaps for fresher and
auto-updating apps.

Mark

On 03/01/17 19:49, Leo Arias wrote:
> On Tue, Jan 3, 2017 at 10:26 AM, Luther Goh Lu Feng  wrote:
>> - Ubuntu core + snaps via classic mode
> If you install a deb in classic mode, it will not be able to affect
> the kernel, gadget or core snaps. It's isolated. The deb can break
> your classic chroot, but nothing else. You can just throw it away, and
> create it clean again.
> However, there are still things that will work on a classic ubuntu
> installation, but will not work in classic mode yet. Most of them are
> just bugs that need to be reported and somebody will fix them.
>
> I use classic mode to do prototyping and development while I get my
> software ready to work as a snap. And I find myself using it less
> every day, as new snaps are released to the store.
>
>> - Debian + snaps via snap
> This will give you a complete traditional system. Everything you
> learned in debian and ubuntu before will just work. So it could be a
> softer transition while you learn about snaps and your dependencies
> are shipped as snaps. You will not get all the benefits of a full
> snappy system, but you will get some by installing the snaps that are
> ready.
>
> As always, it's a trade-off. If you can give a try to both approaches,
> I would be really interested to hear your opinion.
>
> pura vida




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

Re: Thinking of installing snap on Debian due to scarcity of snap packages for armhf

[Mark Shuttleworth]

On 03/01/17 15:02, Ralf Mardorf wrote:
> An important note by the Arch Wiki is
> "Warning: snap-confine is built with the --disable-apparmor option;
> full confinement relies on an AppArmor enabled kernel with Ubuntu's
> Linux 4.4 patchset applied and a related profile for the snap." -
> https://wiki.archlinux.org/index.php/Snapd#Installation
>
> I guess this is something upstream/vendors should know about snaps and
> other distros, at least about Arch Linux.

My understanding is that Arch doesn't have a standard mac-based security
framework enabled; if that's incorrect we'd be glad to work together to
enable full security for confined snaps on Arch!

Also, with the new 'classic' mode, there will be a range of utility
snaps that are not sand-boxed on Ubuntu either, but are still very
useful and no doubt just as useful to Arch users and developers as well.

Mark


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

Re: Thinking of installing snap on Debian due to scarcity of snap packages for armhf

[Mark Shuttleworth]

Also, something to be aware of, is that snaps are built by the upstream
or vendor, not by the distribution. That means that architecture choices
are up to the upstream. We do make cross-architecture build services
available through Launchpad but vendors are not obliged to use those,
and if they are using a third-party build service (for example on Travis
as part of their CI) then architecture availability will be determined
by those services.

Mark

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

Re: Thinking of installing snap on Debian due to scarcity of snap packages for armhf

[Mark Shuttleworth]

On 03/01/17 10:24, Luther Goh Lu Feng wrote:
> This has lead me to wonder if a deploying snap on top of a classic install, 
> say Debian, is a much better idea, at least in the short term, before the 
> snap ecosystem is sufficiently matured and mainstream. Any thoughts on this? 
> Thanks

Snaps on Ubuntu Classic or Debian are a nice way to transition, yes,
until all the snaps are in place for your device. If you are shipping
many devices to the field, then the management cost of a pure-snap
approach should be dramatically lower than the cost of a mixed
classic+snap approach.

Mark

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

Re: Ubuntu core update corresponding to Zesty?

[Mark Shuttleworth]

On 16/12/16 10:04, Dan Kegel wrote:
> I need a newer gstreamer than is shipped in Ubuntu Core 16
> (gst-omx doesn't build against 1.8, but does against 1.10).
> I can build the whole gstreamer stack from source, but going forward
> would like to avoid that.
>
> Is there a Ubuntu Core daily somewhere corresponding to Zesty?
> Or when Zesty's alpha 1 comes out, will there a corresponding Ubuntu
> Core alpha build?

For long-term support I think 'core' will be aligned with the LTS
releases only.

For code like gstreamer I think it is plausible that there be a runtime
snap (see the experimental gnome runtime and similar efforts in the KDE
community) which is annual or more frequent than that.

However, given the move to delta updates I would suggest for the moment
that you simply bundle the libraries you need with your snap. This gives
you certainty in the short term, and the option to move to shared code
once the maintenance regime for that shared code is stable enough for
your purposes.

Mark




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

Re: Ubuntu core on BBB

[Mark Shuttleworth]

On 16/12/16 06:14, Luther Goh Lu Feng wrote:
> Mark mentioned "Rpi2/3 and Qualcomm Dragonboard are already certified". 
>
> Is getting "certified" == "having Ubuntu Core as an official option"?
>
> In the grand scheme of things should element14 or beagleboard 
> - get BBB to become an official reference platform produced by the snappy 
> team ?
> - or roll their own build of Ubuntu Core?
>
> Thanks for the clarifications.

With Ubuntu Core you will be able to make your own kernel, but then you
must take responsibility for it on your device. Alternatively, there can
be a certified kernel which will get security updates from Canonical,
which anybody can use on any "thing". We still need to do a little more
work to have that distinction clearly articulated - the community images
you see are one-offs by folks who were digging in behind the scenes to
make stuff work.

In a couple of weeks I expect this will look like:

 * you take the kernel source tree with snapcraft.yaml and make your own
device kernel snap
 * you use ubuntu-image with that to make your own device image
 * voila

Mark


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

Re: Ubuntu core on BBB

[Mark Shuttleworth]

Hi Luther

To help firm up BBB support, please log that request / preference with
the SoC manufacturer. Rpi2/3 and Qualcomm Dragonboard are already
certified iirc.

Mark

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

Re: WIP snap for 0ad

[Mark Shuttleworth]

On 15/12/16 07:15, Olivier Tilloy wrote:
> I haven’t gotten any further information. 2.18 is in zesty, (when)
> will it be backported to xenial/yakkety? 


I think the push is on for 2.20-in-xenial before the Christmas holiday.

Mark


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

Re: Accessing dbus (KDE Application)

[Mark Shuttleworth]

On 15/12/16 13:33, Jamie Strandboge wrote:
> FYI, the upcoming snapd 2.20 will support the 'dbus' interface. With
> this you
> can update your snap to include something like:
>
> slots:
>   dbus-corebird:
> interface: dbus
> bus: session
> name: org.baedert.corebird
>
> and then you should be able to run in strict mode and bind to the well-known
> DBus connection name.

That looks *great*, tastefully done.

Mark



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

Re: can't log in on ubuntu core console via sso...

[Mark Shuttleworth]

On 13/12/16 19:35, Dan Kegel wrote:
> I'm very confused.  You have SSO.  You tell people to create an SSO
> account to use the device.  Yet SSO can't be used to log into the
> system at the console.  ??

SSH keys associated with the SSO account are pulled into the device, so
you can SSH to it.

We could enable console (as in keyboard-and-monitor-on-device) access
too, if we want, that's what's open for discussion. There are lots of
ways to do that, simplistically just by asking for a login password to
be set during the device activation step that you saw. But the concern
is that users will reuse an important password when doing so.

We have 2-factor capabilities that might be useful. In general, I would
say we are open to suggestion but mindful of the opportunity to raise
the bar for device security.

Also, we're mindful of the fact that these devices will not be used
every day. So passwords that are unique to the device will easily be
forgotten.

All of that led us to the SSH approach that you see now. It's not a
final position, those are just the things to think about in the discussion.

Mark


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

Re: can't log in on ubuntu core console via sso...

[Mark Shuttleworth]

The thing that worries me is the likelihood of bad passwords being set.
We don't necessarily know what the software is on the device, and people
are likely to reuse passwords that are important to them on other
systems. So we though SSH enablement was the cleaner safer way to tty.
Happy to take feedback and in principle OK to have a local password.

Mark

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

Re: docker snap not working

[Mark Shuttleworth]

Can we add Docker to a list of 'critical snaps' that is part of our
pre-release validation suite?

Mark

On 06/12/16 05:05, Manik Taneja wrote:
>
>
> On Dec 6, 2016, at 4:51 AM, Loïc Minier  > wrote:
>
>> Hi,
>>
>> On Tue, Dec 6, 2016 at 3:49 AM, Peng Liu > > wrote:
>>
>> There is some known issue of the docker snap, check the google
>> doc for detailed information.
>> 
>> https://docs.google.com/document/d/1JHa6tkuR9PtpnAVVmAJIAKuyKBy8E9ZkvG5Wbc6HZSY/edit#
>> 
>> 
>>
>> And you need to make sure your snapd is the latest version.
>>
>>
>> Exactly; it only affects Ubuntu Core images (not snaps on classic),
>> and there are two workarounds:
>> - either install the snap with devmode
>> - or run this after boot (and then restart dockerd):
>>
>> $ sudo nsenter -m/run/snapd/ns/docker.mnt
>>
>> # umount --lazy /var/lib/snapd/hostfs/sys
>>
>> The fix is in snap-confine git and is planned for upload this Friday.
> Thanks Loic!
>>
>> Best regards,
>> - Loïc Minier
>> -- 
>> 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: New all-snap images available

[Mark Shuttleworth]

On 30/11/16 12:15, Shuduo Sang wrote:
> Please use GM image
> from 
> http://cdimage.ubuntu.com/ubuntu-core/16/current/ubuntu-core-16-pi2.img.xz.
>  
>
> It boots and I go to ssh into the raspberrypi. I can get to the
> login prompt but do not know the default username or password.
>
>  
>
> Ubuntu / Ubuntu is given in many guides but doesn’t seem to work.
>

Hi David

Given the vulnerability of a default username / password, we moved to
having account creation done on first boot in newer versions of the
system. We assume there is some online account verification system (the
reference implementation uses login.ubuntu.com but it would be plausible
to tie into any existing online authentication system). On first boot,
folks who can connect to the console of the device (or potentially who
have other privileged access) can trigger the creation of accounts for
themselves. Those use things like SSH credentials for access.

The net effect is that we solve one of the big problems in IoT, which
was at the heart of the recent Dyn attack.

Try the images that Shuduo pointed to, I think you'll like the new
system. If you really want a default user / password that can be setup
too, but we would consider it good practice to avoid those.

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

Re: is there an Avahi (mDNS) service snap?

[Mark Shuttleworth]

On 29/11/16 10:42, George Gross wrote:
> Q: is this something that needs to be built from source for armv7 target
> and then repackaged from .deb into snap?

If there is an existing deb which suits you, then that may well be a
useful way to go about creating the snap. It depends on whether the
binaries in that deb are easy to "relocate", since a snap shows up at
/snap/foo/current/* rather than the (deb-usual) /usr/bin/foo etc.

If not, and you just want a snap, then it's probably easier to assemble
the snap to build from source, so that it can be told that it will be
running from the snap location.

Make sense?

Mark

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

Re: Snaps to invoke external processes

[Mark Shuttleworth]

On 25/11/16 17:09, Gustavo Niemeyer wrote:
> The role of xdg-open itself is already to open the URL with whatever
> tooling is available, so it sounds like we're making the issue more
> complex than it ought to be.
>
> I think we should reimplement xdg-open in terms of snapctl, and have
> snapd itself doing the hand-over to the local xdg-open tool after some
> basic sanity checking on the URL. That way we're not really asking for
> anything from the local system (no dbus service) while remaining
> completely portable.
>

I think this works, as long a we handle the failure cases ("no
xdg-open") sweetly.

Mark

> On Wed, Nov 23, 2016 at 4:51 AM, Mark Shuttleworth <m...@ubuntu.com
> <mailto:m...@ubuntu.com>> wrote:
>
>
> I think the port of snapd to a distro should handle ensuring that
> "browse" works. How it does that is up to the port, as long as the
> behaviour is clear it is easy to implement. We just to be clear what
> expectaction a snap publisher can have. I would say "snap-browse"
> is the
> command to use, and on *Ubuntu* that would be snap-xdg-open.
>

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

Re: Snaps to invoke external processes

[Mark Shuttleworth]

I think the port of snapd to a distro should handle ensuring that
"browse" works. How it does that is up to the port, as long as the
behaviour is clear it is easy to implement. We just to be clear what
expectaction a snap publisher can have. I would say "snap-browse" is the
command to use, and on *Ubuntu* that would be snap-xdg-open.

Mark

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

Re: Snaps to invoke external processes

[Mark Shuttleworth]

On 22/11/16 06:46, Didier Roche wrote:
> Le 22/11/2016 à 05:43, Spencer Parkin a écrit :
>> Well, actually, not unless the customer also installs
>> snapd-xdg-open.  Why is it an add-on?  Why not just make it part of
>> snapd?
>
> I gues the idea was to keep it as a separate daemon and have the
> implementation which can easily change.
> The "why it's not installed by default" was the reason why I CCed
> Michael yesterday. I hope he will answer here.

Seems to me that we want a predictable result for all snap users,
otherwise we make installation instructions for snaps unnecessarily complex.

Mark

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

Re: Number of snaps in the snap store

[Mark Shuttleworth]

On 15/11/16 14:24, Chris wrote:
> Why is it that the Ubuntu Snap Store only lists 100 available snaps
> when the 'unofficial' store uApp Explorer lists over 500 snaps
> available? 

I think 'snap find' is rate-limited to top-100 matches for query
performance. uApp Explorer is probably scraping a different source, it's
roughly accurate for public snaps.

Mark



signature.asc
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?

[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

Re: Help making images to test console-conf changes

[Mark Shuttleworth]

On 07/11/16 06:27, Michael Hudson-Doyle wrote:
> I've been working on a rewrite of console-conf's networking bits, with
> the intent of making the UI a bit clearer and more dynamic (e.g. if
> you stick a USB Ethernet adapter in after you've started console-conf,
> it shows up in the UI).
>
> I've tested this locally but this is the sort of thing that should
> definitely be tested on all supported devices before it goes into
> core. I've put probert and subiquity packages into ppa:mwhudson/devirt
> but realised that I don't know how to make core snaps with custom
> packages on launchpad! If someone could help we with that, then I (or
> anyone) can make some images for people to test.
>

Custom images are a good start, but when the time comes we can always
push a core snap into a beta channel for you to make it easy for folks
to test.

Mark

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

Re: Python 3 plugin sanity checking

[Mark Shuttleworth]

On 28/10/16 23:27, Barry Warsaw wrote:
> Wouldn't it make sense for the Python 3 plugin to either automatically include
> the stdlib (e.g. usr/lib) or complain loudly if it's not included explicitly
> in the resulting snap?

Yes, it helps when the tools sanity-check and guide new devs to the
right outcome.

Mark



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

Re: calling cli apps

[Mark Shuttleworth]

This is an active discussion for us at the moment, I think we will have
a solution for you soon.

Mark

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

Re: Announce: Handbrake encoder

[Mark Shuttleworth]

On 07/10/16 17:52, Jacob Zimmermann wrote:
> I have built a snap package of the Handbrake video encoder. The package
> name is handbrake-jz.
>
> ATTENTION: to use it you MUST run the following command after
> installation, otherwise it will not work:
>
> sudo snap connect handbrake-jz:process-control ubuntu-core:process-control
>
> Optionally, to access external devices from handbrake, for example to be
> able to rip DVDs etc., you must also run:
>
> sudo snap connect handbrake-jz:mount-observe ubuntu-core:mount-observe

Nicely done!

Just to state the plan of record, we intend that store assertions can
pre-approve some auto-connection, or cue up a prompt for interactive
installations where the user is asked if they want to connect.

So in your case, the experience should become something like:

  $ sudo snap install handbrake
  Allow 'handbrake' to access DVDs? (Y/N) Y
  handbrake 1.3.2 installed

Mark



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

Re: My second snap ;-)

[Mark Shuttleworth]

On 04/10/16 18:44, Robert Park wrote:
> Thanks again Loic, I was finally able to achieve a snapped matplotlib
> (well, the current traceback I'm seeing is at least from my own app so
> I can iterate on that, matplotlib seems happy enough at least).

\o/ now the fun part starts when you get to push updates to your users
in real time :)

Mark

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

Re: My second snap ;-)

[Mark Shuttleworth]

Giving you your own /etc would enable you to do whatever you want in it,
but it would by definition also mean that any files you see there don't
reflect any OTHER apps understanding. So /etc/resolv.conf for example
would be meaningless, because yours might be different to that on the
snap next door.

It's hard to know in advance if your snap wants to READ stuff in /etc/
that is written by others, or WRITE stuff in /etc/ that is mainly used
by itself.

Mark

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

Re: How do you add config files - "file" can't find it's configuration files?

[Mark Shuttleworth]

On 16/09/16 06:11, Dave Chiluk wrote:
> I also realize that it would take more work than this simplistic
> suggestion, but has anyone researched something like that?  Plus it
> would give each application even better isolation since the isolation
> would be enforced by snappy.

Except that the NICE think about snaps is that they CAN be integrated
elsewhere on the filesystem, and a sledgehammer such as the one you
propose would make that more awkward by the looks of it.

I do think we need a quilt or other mechanism for carrying patches. I
nack'd that previously, but having dug in, I've come around.

Mark

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

Re: Accessing dbus (KDE Application)

[Mark Shuttleworth]

On 12/09/16 13:13, Daniel Llewellyn wrote:
> I just ran-up against this issue while trying to snap corebird, which
> wants to reserve the dbus name "org.baedert.corebird". This would fall
> afoul of the option to limit names to being under org.gnome namespace.

The more-sophisticated interface in development would allow you to
designate the namespaces to bind, not be tied to org.gnome.

That said, we could probably *trivially* do an org.gnome-specific
interface if that would unblock people and be considered safer than a *
binding.

Mark

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

Re: Snapping Neovim

[Mark Shuttleworth]

On 07/09/16 11:58, Gustavo Niemeyer wrote:
> They can install it as devmode, and we can also introduce an
> "editor-support" interface which gives global read/write access to it.

I like the idea of this, specifically excluding global execute (which
something like a chef snap or juju agent snap would want).

Mark

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

Re: More Ubuntu-Core boot up problems...

[Mark Shuttleworth]

On 07/09/16 06:56, MikeB wrote:
> This new 'first user experience' caught me by surprise - I don't think
> I saw anything about this on the snapcraft mailing list.  Is there
> some other list I'm not following that discusses these changes ahead
> of time?

Do we need a list for Ubuntu Core, the all-snap rendition of Ubuntu?
This list is mainly for people making snaps, which might be running on
any classic distro, and I would not want folks who's primary interest is
a snap running on their preferred distro to have to wade through threads
about Ubuntu Core.

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

Re: snapcraft's python plugins, road ahead and changes.

[Mark Shuttleworth]

On 03/09/16 10:07, MikeB wrote:
> Don't forget that at one point several folks thought it would be a
> good idea to move the location of custom plugins out of the parts
> directory - that's an awkward place for them.  Can't tell you how many
> times I've accidentally deleted the parts directory only to remember -
> too late - I had some changes in the custom plugins.

I'll second this. IIRC we wanted to use the parts directory to reduce
the footprint of snapcraft in an upstream tree, but I think that it
would be better to treat parts/ as entirely removable. That would
suggest putting the plugin some where like .snapcraft/

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

Re: PostgreSQL 9.6 snap and feedback

[Mark Shuttleworth]

One of my colleagues wrote regarding his experimental postgres-9-6 RC1
snap, and I'm replying to the list with permission, because I think he
raises a lot of good points and perspectives and questions that folks
here would have comments on.

On 31/08/16 13:08, Stuart Bishop wrote:
>
> PostgreSQL is well behaved and well polished, so snapping was not
> problematic. Unlike what most people are recommending, I started
> directly with strict confinement. My gut feeling is that it is better
> to trip over issues one at a time when they come up rather than try to
> deal with them in bulk once you have something working in devmode.
> That said, I didn't trip over many.

I think there should be a meme-generator for this. "I don't often make
snaps but when I do I start strictly".


>
> The biggest problem I had was dropping privileges to a non-root user.
> There is currently no way to do this (nor to create such a
> non-privileged user when the snap is installed). PostgreSQL upstream
> block the root user from running tools this, with deliberately no way
> to disable it since they traditionally took flak from poorly managed
> installs (and they still bitch about Debian using non-standard paths).
> I needed to patch several places in the code, and there may be some
> more lurking in there not triggered by the PostgreSQL test suite.

OK, we definitely want to support this.

I think the scaffolding we need is:

 * such user names should be managed globally (i.e. assigned in an
assertion)
 * such user names should by design not conflict with real users

I think this requirement has come up before and what we decided was to
pre-reserve a name in Ubuntu which would be in /etc/passwd up front.
Perhaps this was for LXD, I forget. That's not a scalable solution but
it might work for Pg.

> Usability is currently poor. PostgreSQL is cli heavy, so having all
> the well known commands with munged names like
> 'postgresql-9-6.pg-dump' instead of 'pg_dump' would stop adoption all
> by itself. I understand that this is being addressed, and I will be
> able to present the dozen or so commands with their preferred names.
> But this will also cause different issues, when I snap postgresql-10.
> postgresql-10 will have the same set of tools. So I'll have two sets
> on my path, each only able to deal with their own confinement. I think
> the search path needs a defined ordering (eg. alphabetically), and
> tools need to be available in both their prefixed and unprefixed form.
> I will need to have both postgresql-9-6 and postgresql-10 snaps
> installed in the same container, as this is the only migration path I
> can come up with (allowing postgresql-10.pg_upgrade access to the
> postgresql-9-6 containment via the content interface).

Yes, these are very useful practical items of feedback for the command
work. Let's promise to take that up in a sprint, when it's close to the
top of our priority list. As a straw man it seems that we want groups of
snaps (your pg versions) to be able to overlap in command names, but
have only one of them get that top-level space at a time. That's a
little bit like update-alternatives but with a snap as the level of
granularity. If pg-10 is your default then all the top-level commands
are pg-10, others are pg-X.command.


>
> PostgreSQL is very extensible, and I haven't worked out the best way
> to handle it. This includes adding arbitrary 3rd party Python, Perl
> and tcl libraries for use from the built in stored procedure
> languages. This includes building, linking and installing entirely new
> stored procedure languages such as Ruby and all their dependencies and
> extensions. This includes building, linking and installing C stored
> procedures. This includes building other PostgreSQL extensions and
> installing them where they can be installed using 'CREATE EXTENSION',
> such as Citus for massive scale out and sharding or BDR for multi
> master replication. The ecosystem is too vast to package everything,
> and a lot of people are using bespoke and proprietary tools.

Yes, the general question about plugins and extensions is super
interesting. Snaps offer tight and deterministic binaries on demand, and
that slightly conflicts with extensible ecosystems, but we must explore
the boundaries of the known world to better understand where we're going.

Simplistically, a snap author could make an ecosystem of things they
bring into their snap. But what you want is a little less controlled
than that.

>
> Launchpad was invaluable, as my attention span doesn't cover uploading
> 100MB++ blobs over my awful 3rd world ADSL connection. Awful hacks
> were used to get test suites running as part of the build process from
> the static snapcraft.yaml, which in hindsite would have been done
> better as a custom plugin.
>

Yeah, a custom plugin is a much easier way to solve build issues than I
expected too. We could do a much better job of helping people write such
plugins, for example by documenting the BasePlugin 

Re: Stuck in Ubuntu Core Profile Setup

[Mark Shuttleworth]

Hi Mike

You are seeing the bootstrapping of a brand new all-snap OS, sorry for
the rough patches but we have just added this first-boot experience. The
rest is shaping up very nicely, that part is just brand new. We expect a
usable image on Friday this week, and a release candidate later in the
month.

This new Ubuntu Core 16 image is shaping up to be something we can be
very proud of:

 * everything is a snap and those snaps are super-fast and
super-transactional
 * the bootstrap process is very factory-friendly for people making
physical appliances
 * there is a very strong security foundation that raises the bar for
all appliances and IoT

This first-user experience addresses some long-standing issues that have
bugged me about Ubuntu across cloud and devices for nearly a decade!

 * the 'ubuntu' default user is removed so appliance vendors have much
more brand control
 * we eliminate default users from the bootstrap process
 * we work the same way from cloud to edge appliance

Apologies again for the rough spots in the first code drop, but I bet
you love the end result.

Mark

On 01/09/16 06:47, MikeB wrote:
> On 01-Sep-2016, MikeB wrote:
>
> 1. I see a message saying 'Contacting the Store', then get the error
> "Creating user failed: error: bad user result: cannot create user for
> : no ssh keys found" -- OR -- 2. I immediately see
> the error "Creating user failed: error: bad user
> result: cannot create user "": Get
> https://login.ubuntu.com/api/v2/keys/: dial tcp: lookup
> login.ubuntu.com  on [::1]:53: read udp
> [::1]:40286->[::1]:53: read:
> connection refused I'l usually see the first error on the first
> try and the second error on
> subsequent tries until I power-cycle the target switch. In either
> case, I can never get past this setup, so as I said above, my
> target switch is now a brick. Can someone tell me how to get past
> this screen so that the boot completes
> and I can get back to work?
> ​
>
>
> ​I went to my Ubuntu One account and ​imported my Public SSH Key and I
> was able to successfully complete the 'Profile Setup'.  I hadn't
> realized that my account even required a public key.  So, I'm now pass
> the 'Profile Setup' and can use the switch again.
>
> However, I have some concerns about this new feature...
>
> 1. I'm concerned that the bootload just "froze" with no indication
> that it was looking for manual intervention.
> 2. I'm concerned that there was no obvious way to bypass this profile
> setup and get on with the boot.
> 3. I'm concerned that network equipment has to be registered to a
> particular user that has to have an Ubuntu One account with an
> imported public key.  In my particular case, these switches are used
> by many developers.  I don't want all the developers forced to create
> Ubuntu One accounts and I don't want to give all the developers my
> Ubuntu One credentials.
> 4. When the unit finally booted, I was unable to perform a 'sudo snap
> install hello-world'.  I encountered what looked like network errors. 
> I rebooted the switch and then was able to 'snap install'.  It doesn't
> look like the first boot left the network configuration in a good
> state as the boot finished up.
>
> Regards, Mike
>
>
>

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

Re: Using the content write interface

[Mark Shuttleworth]

On 30/08/16 15:39, Benjamin M Romer wrote:
> I'm experimenting with snaps and would like to use the content
> interface to share files with another snap. I couldn't find
> documentation for it, so I figured I'd ask.
>
> Since there's a "write:" option for the content interface, and the
> snap itself is read-only, it seemed likely that there is a way to
> expose files in $SNAP_DATA or $SNAP_COMMON so that the consuming snap
> could see and modify them. 

The content interface itself is very new, so I suspect the details are
still flexible based on this sort of feedback and experience. So thank
you for kick the tires :)

In general I would say it's unlikely that sharing the entire $SNAP_DATA
is desirable. I suspect that the interface is more aimed at:

 * common builds of shared libraries for large frameworks like ROS and
Qt and KDE
 * shared large data sets (for example texture files in a game system)

Mark


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

Re: Snapping LDC (LLVM-based D compiler)

[Mark Shuttleworth]

On 27/08/16 16:45, Joseph Rushton Wakeling wrote:
> It's been very exciting to see how straightforward most things are to
> get set up,

Yeah, it's been fun here too working on a few holiday snaps :)

> but I ran into a few issues that are blockers to finalizing the snap,
> so I thought I'd ask here for advice on how to address them.
>
> [snip]
>
> This happily builds and generates a snap, and so far as I can tell
> from the install, all the usual required files are there.  (By the
> way, I really do mean to have ldc in the `build-packages`; LDC now
> requires a D compiler to build it, so it's necessary to have the older
> ubuntu-packaged ldc 0.17.1 to build with.)
>
> The problems with the snap are threefold:
>
>   * LDC creates two different executables, ldc2 and ldmd2 (the latter
> is a
> wrapper that implements compiler flags to match D's reference
> compiler,
> "Digital Mars D" or dmd).  However, the names given to the snap
> executables
> are ldc.ldc2 and ldc.ldmd2.  While I understand the wish to
> namespace, is
> there any way to drop the `ldc.` prefix ... ?

We would like to add the ability to have a single snap offer up multiple
base-level commands. This will require some changes to snapd, if you are
comfortable writing code in Go then feel free to take this on as a
challenge :) Niemeyer or MVO on IRC would be able to give you some
implementation strategy ideas.

For now, if you have a command with the same name as your snap, then
that one can drop the namespacing. So if your one command was "ldc" then
you would not need ldc.ldc you could have just ldc.


>   * LDC creates a config file, `/etc/ldc2.conf`, using libconfig. 
> This defines
> some default compiler flags, including the default 'include'
> location of
> header files for the runtime and standard library.  However,
> perhaps because
> of how the snap is built, the include paths are specified as if
> the snap's
> install dir was the root:
>
> switches = [
> "-I/include/d/ldc",
> "-I/include/d",
> "-L-L/lib",
> "-defaultlib=phobos2-ldc,druntime-ldc",
> "-debuglib=phobos2-ldc-debug,druntime-ldc-debug"
> ];
>
> This means that when one tries to compile anything, the compiler
> emits
> error messages that it is unable to locate the headers for runtime or
> standard-library modules.  If one manually specifies the full-path
> include locations:
>
> -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d
>
> ... then the compiler can build an object file, but runs into the
> third
> of the problems ...


Not sure here, I think someone closer to the mechanics of snap paths can
help.


>
>   * LDC uses the default C compiler for linking, but the snap-installed
> compiler fails to find it, exiting with a message:
>
> Error: failed to locate gcc
>

The easy way to fix this is to bundle the linker. The slightly longer
way is to arrange for an interface that gets you a linker command. Bear
in mind that in Ubuntu Core environments you don't have apt-get to bring
in things like that to the base OS, you only have the core snap which is
minimal and definitely doesn't have the compiler :) If you depend on a
compiler outside, you will only work in places where someone has
provided that. My suggestion would be to add the linker to your snap,
which gets you unblocked at the price of a fatter snap. Then if you feel
inspired go about getting the linker interface set up, in such a way
that it can work first on classic systems which happen to have gcc, and
then even on all-snap core systems where the linker might be another snap.

> Can anyone advise on how best to address any of these problems?  I
> would assume the last in particular is down to the lack of an
> interface for access to things like a linker or other aspects of a
> build system? 

2 out of 3 ain't bad :)

Nicely done and welcome aboard!

Mark


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

Re: Snappy + root encryption

[Mark Shuttleworth]

Just to say thank you, these use-cases are all fantastic and things we
would accept as patches, or work into the roadmap.

Mark

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

Re: Snappy + root encryption

[Mark Shuttleworth]

Hi Xavier

With snaps on classic (deb-based) Linux there have been some bugs
related to encrypted home directories, not sure if those are fixed yet
but they are definitely in progress.

On Ubuntu Core (where the whole system is a collection of snaps, there
are no debs by default) it should be possible to have an encrypted disk.
The main question would be what your expectations of the boot process
would be. Most people who want Ubuntu Core are doing so for distributed
devices where there isn't going to be a human around if the machine reboots.

Mark

On 23/08/16 06:26, Xavier Pegenaute M2M wrote:
> Hi all,
>
> I am interested on building a snappy system with encryption to rootfs,
> I've been looking around but I didn't find any document or guide about
> it. Does snappy support it? If this is the case some one could point
> me to some info about it?
>
> Regards
>


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

Re: Guidance on deprecating debs for snaps

[Mark Shuttleworth]

Policy for non-core apps is that newer versions should be provided as
snaps, LTS-released versions should be maintained as debs (but not
updated to newer versions).

By non-core I mean anything that is not in the ubuntu-core snap.

By apps I mean things that would make a natural snap or (in the case of
libraries) snapcraft part.

So Marco is exactly right to ask this question now, since we need to
evolve a best practice for how to socialize that there is a newer
version of the software available as a snap.

Mark


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

Re: custom lxd bridges inside a snap

[Mark Shuttleworth]

On 17/08/16 09:53, Jamie Strandboge wrote:
> The snap connect is needed for privileged interfaces like
> network-control. It
> would be unfortunate for a tic tac toe game to, upon install, reconfigure your
> networking stack behind the scenes without the user knowing. Future assertions
> work will allow these sorts of privileged interfaces to be auto-connected and
> AIUI gadget snap developers will also have a voice in auto-connect.

I think the way Jamie phrased this is misleading.

Our intent is that specific auto-connections can be approved in advance.
That capability does not yet exist, but will soon. What Adam is asking
for is a perfectly reasonable thing and our intent is to make that work
the way he wants.

So Adam, don't worry about this, go ahead (but document the connect
command required while it is still needed).

Mark



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

Re: Putting git inside a snap

[Mark Shuttleworth]

On 17/08/16 09:26, David Callé wrote:
> On 17/08/2016 15:20, Mark Shuttleworth wrote:
>> On 16/08/16 22:09, Sergio Schvezov wrote:
>>> Create a new `apps` entry like this
>>> apps:
>>>sh:
>>>command: bash
>>>plugs: [same list of plugs used by what calls git]
>>>
>>> There's a `snap shell` (or similar) command making a come back some time
>>> and would make this more straightforward.
>> Given the nature of sandboxing during the development process ("zomg the
>> glass walls!") I think we should have a first-class command that spawns
>> a $SHELL (not the shell of the snap but your preferred shell) inside the
>> sandbox.
>
> Isn't that the purpose of the 'snap run --shell' command?
>
> $ snap run --help
> [...]
> [run command options]
>   --shellrun a shell instead of the command (useful for
> debugging)

Oh that's nice! Can I use the actual command name to get the specific
sandbox for that command?

  $ snap run --shell snap.command

Also, this still seems to require that the snap author stuck  "bin/bash"
in the snap:

  $ snap run --shell docker.docker
  cannot snap-exec: cannot exec "/snap/docker/33/bin/bash": no such file
or directory

Seems like we could drop that requirement since /bin/bash is always in
the core snap. But we might also want to let the publisher turn this
off, hence the snap.yaml suggestions.

And finally, I think that command should be "exec" not run, and the
snap-exec error suggests others feel the same way :)

Mark


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