Re: demon snmp in snap

[Didier Roche]

Le 09/08/2016 à 09:53, BlinCT . a écrit :
> Good afternoon.

Hey Alexey,

> My name is Alexey
> I write for the first time, hoping to get advice from you
> Recently I started to try building a programs into Snap package. I
> need to build a demon. But unfortunatly there was a many problems due
> working. I faced on the lacking of documentation and description of
> the principle operation with demons.
> I will try to describe the work and attaching a file with yaml file
> and binary file (f2d).
> The system should work with 2 demons, snmpd and my own sub-agent. snmp
> service is working with system. sub-agent is handle our requests,
> which are not known for the snmpd.
> snmp should be able to "--start" and "--stop".
> sub-agent can running with different keys, for example ./f2d -Lo -n
>
> My questions:
> 1. How to make packaging into snap pack with 2 demons if I want a
> program running only by root and with the keys?
You just add different wrapper scripts (enabling one or the other with
some conditions) I would say triggering one or the other in this shell
scripts before starting the real daemon. Then, you can have two names
under apps: in your snapcraft.yaml, each command pointing to one of the
wrapper script.

> 2. How to work with file out of $SNAP?

You basically can't and shouldn't really on files outside of $SNAP apart
from really rare exceptions. The whole idea of snaps is that upstream
source is relocatable. Most of the times, they have some env variables
that you can set to ensure it's reading the files where you want them to
read (and you want them to read/create files in $SNAP*)

> 3. I collect snmp, he unpackage /etc/snmp/snmpd.conf and then I want
> to replace it by my own snmpd.conf. how to do it?
I think that depends on snpmd itself. You need to look at the source and
see if there is a parameter for the daemon like -c  or an
environment variable to point to some non hardcoded path. I'm sure
making that relocatable would be a welcome contribution by upstream if
it's not possible already!
> 4. The system have snmp. Could I install and work with other snmp in a
> program, if snmp was build in snap package?
I don't really know snmp itself, but as they communicating via TCP or
such? I don't think unix socket connection would be possible without
defining an interface (and some people reading this list can help you
getting started with this). If the communication is all network-y, you
just need to use then the "network" and "network-bind" interface (if you
are listening to incoming requests) for this.

I hope that helped!
Didier



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

Re: screenshot

[Sebastien Bacher]

Le 10/08/2016 à 08:04, Didier Roche a écrit :
> I guess for this kind of this, a bug is more appropriate than a ML
> discussion. Please open one (I would say against
> https://launchpad.net/ubuntu/+source/gnome-software) with appropriate
> details (name of the snap, and such…) so that people can debug it and
> reassign if needed.

Hey,

That issue has already been reported

https://bugs.launchpad.net/snappy/+bug/1603610

The bug doesn't have much detail but is reported on snappy as well so
it's likely that snapd doesn't provide that info to the client


Cheers,
Sebastien Bacher

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

Re: Removing sub-parts from the remote parts ecosystem.

[Didier Roche]

Le 09/08/2016 à 23:41, Joe Talbott a écrit :
> Dear Snapcrafters,

Hey Joe,
>
> The wiki introduced the concept of sub-parts and used namespacing to
> associate a list of sub-parts with a project-part.  However the
> concept was ill-conceived and now needs to be removed.  In essence,
> all parts should be top level parts.  Each entry in the wiki should
> identify one or more parts from a snapcraft.yaml file that are
> considered to be useful to other snapcraft users.  A current example
> of subparts might look like this:
>
>---
>origin: https://github.com/josepht/snaptastic
>maintainer: Joe Talbott 
>description: Some fun parts
>project-parts: fun-part
>parts: [a, b, c]
>
> Which would produce parts ‘fun-part/a’, ‘fun-part/b’, and
> ‘fun-part/c’.  The new approach should be:
>
>---
>origin: https://github.com/josepht/snaptastic
>maintainer: Joe Talbott 
>description: Some fun parts
>parts: [fun-part, fun-part-a, fun-part-b, fun-part-c]
>
> Where the hierarchy is removed and each part is a top-level part.  The
> part names will need to be changed in the snapcraft.yaml file as well.
>

Namespacing was really nice for things like desktop/ parts
(desktop/gtk3, desktop/gtk2, desktop/qt5, desktop/qt4,
desktop/glibonly). There is as well  mqtt-paho/python2 and
pqtt-patho/python3.
A lot of existing snaps are using those already and I find it really sad
that we are going to break backward compatibility for a feature that was
prominently advocated for in our blog posts like
http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/.
Developers prefer to work on their snap rather than fighting for keeping
it working with latest snapcraft/store, please keep that in mind.

I think at least a reasonable approach would be to have a transition
plan for a period of time backed into the tool. That means that
snapcraft needs to be able to detect namespaced parts, and suggests
corresponding new part name to use (as we only have 7 of them, that
seems reasonable to handle the mapping by hand). I think that will put a
nice precedent on how we care about developer experience, and try to
minimize the impact on everyone. Is there anything like this planned?

Also, please do not break this feature before the parts are transitioned
to the new name scheme.

My 2 cents
Didier


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

Re: Where to place config files, and nested config files

[Didier Roche]

Le 09/08/2016 à 23:50, Andreas Hasenack a écrit :
> Hi,

Hey Andreas,
>
> I'm starting to use snapcraft and picked squid-deb-proxy as my first
> victim. This is just the normal squid service with a set of
> configuration files tailored for deb package caching.
>
> I'm assuming that the best place for the squid config files is
> SNAP_DATA, because it's versioned and any rollback will include the
> configuration files as they were in the previous installed revision.
> Is that correct?
Correct!

>
> My other question is about nested configuration files.
>
> This particular squid config file includes other config files via
> absolute paths. In the normal deb package, you will see things like this:
>
> acl allowed_networks src
> "/etc/squid-deb-proxy/allowed-networks-src.acl"
>
> Now even if I point squid to the main/parent config file in SNAP_DATA,
> that absolute path above inside the config won't work because it's
> ouside SNAP_DATA. So what are my alternatives?
>
> a) hardcode the path above to use this prefix:
> /var/snap/squid-deb-proxy/current/. This is just like SNAP_DATA, but
> using "current" instead of the revision number, so it's stable. The
> acl line above would be like this, for example:
>
> acl allowed_networks src
> "/var/snap/squid-deb-proxy/current/etc/squid-deb-proxy/allowed-networks-src.acl"
>
> Can I use "current" like this, or is that abuse or bad form?
>
>
> b) use a simple template system and dynamically generate the config
> file with SNAP_DATA as the prefix before starting the service. I would
> have something like this in the template file:
> 
> acl allowed_networks src
> "@PREFIX@/etc/squid-deb-proxy/allowed-networks-src.acl"
>
> And generate the actual config file replacing @PREFIX@ with the
> contents of SNAP_DATA before starting the service. Is this overkill,
> or the most elegant solution?
>
>
> c) something else I'm missing? I'm very much starting my journey here :)

b) is the most elegant solution IMHO, it will always point to the right
directory, at runtime. That makes as well upstream config relocatable,
which is a net benefit for everyone :)

Cheers,
Didier

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

Re: screenshot

[Didier Roche]

Le 10/08/2016 à 07:58, Vasilisc a écrit :
> I uploaded in the Ubuntu Store a programs with their screenshots.
> GNOME Software does not show screenshot and icon.
> How fix this issue?
>

I guess for this kind of this, a bug is more appropriate than a ML
discussion. Please open one (I would say against
https://launchpad.net/ubuntu/+source/gnome-software) with appropriate
details (name of the snap, and such…) so that people can debug it and
reassign if needed.

Cheers,
Didier


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

screenshot

[Vasilisc]

I uploaded in the Ubuntu Store a programs with their screenshots. GNOME 
Software does not show screenshot and icon.

How fix this issue?

--
Best regards,
vasilisc

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

Re: ntopng strict snap published

[Manik Taneja]

On Tue, Aug 9, 2016 at 11:39 AM, Evan Dandrea 
wrote:

> On Mon, 8 Aug 2016 at 17:51 Sergio Schvezov 
> wrote:
>
>> El 08/08/16 a las 13:35, Blake Rouse escribió:
>> > I would like to setup some travis CI that will auto upload tip of
>> > dev into the edge channel of "ntopng".
>>
>> Evan has some guides for setting up CI and could also solve or point you
>> in the right direction to take the reserved name.
>>
>> snapcraft 2.15 should be able to allow setting up macaroons through env
>> vars (to make it easier to use things like travis-ci) but that shouldn't
>> stop you from using ev's current solution.
>>
>
> This will let you build and publish snaps off Travis runs. You'll want to
> change $MACAROON_SECRET to your favourite value from pwgen. You'll also
> need to change the snap name and the $TRAVIS_BRANCH conditional.
>
> https://gist.github.com/evandandrea/998180be091518da1f6330bf19ed7a40
>
> will this allow them to claim the reserved name?
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Where to place config files, and nested config files

[Andreas Hasenack]

Hi,

I'm starting to use snapcraft and picked squid-deb-proxy as my first
victim. This is just the normal squid service with a set of configuration
files tailored for deb package caching.

I'm assuming that the best place for the squid config files is SNAP_DATA,
because it's versioned and any rollback will include the configuration
files as they were in the previous installed revision. Is that correct?

My other question is about nested configuration files.

This particular squid config file includes other config files via absolute
paths. In the normal deb package, you will see things like this:

acl allowed_networks src "/etc/squid-deb-proxy/allowed-networks-src.acl"

Now even if I point squid to the main/parent config file in SNAP_DATA, that
absolute path above inside the config won't work because it's ouside
SNAP_DATA. So what are my alternatives?

a) hardcode the path above to use this prefix:
/var/snap/squid-deb-proxy/current/. This is just like SNAP_DATA, but using
"current" instead of the revision number, so it's stable. The acl line
above would be like this, for example:

acl allowed_networks src
"/var/snap/squid-deb-proxy/current/etc/squid-deb-proxy/allowed-networks-src.acl"

Can I use "current" like this, or is that abuse or bad form?


b) use a simple template system and dynamically generate the config file
with SNAP_DATA as the prefix before starting the service. I would have
something like this in the template file:

acl allowed_networks src "@PREFIX@
/etc/squid-deb-proxy/allowed-networks-src.acl"

And generate the actual config file replacing @PREFIX@ with the contents of
SNAP_DATA before starting the service. Is this overkill, or the most
elegant solution?


c) something else I'm missing? I'm very much starting my journey here :)

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

Removing sub-parts from the remote parts ecosystem.

[Joe Talbott]

Dear Snapcrafters,

The wiki introduced the concept of sub-parts and used namespacing to
associate a list of sub-parts with a project-part.  However the
concept was ill-conceived and now needs to be removed.  In essence,
all parts should be top level parts.  Each entry in the wiki should
identify one or more parts from a snapcraft.yaml file that are
considered to be useful to other snapcraft users.  A current example
of subparts might look like this:

   ---
   origin: https://github.com/josepht/snaptastic
   maintainer: Joe Talbott 
   description: Some fun parts
   project-parts: fun-part
   parts: [a, b, c]

Which would produce parts ‘fun-part/a’, ‘fun-part/b’, and
‘fun-part/c’.  The new approach should be:

   ---
   origin: https://github.com/josepht/snaptastic
   maintainer: Joe Talbott 
   description: Some fun parts
   parts: [fun-part, fun-part-a, fun-part-b, fun-part-c]

Where the hierarchy is removed and each part is a top-level part.  The
part names will need to be changed in the snapcraft.yaml file as well.


Thanks,
Joe

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

RE: How do I get a postinst stage properly executed - traceroute will not install correctly

[David Garrod]

Re:


Ø  However perhaps the design issue you're seeing is not with snaps but rather 
with debs: alternatives should be declarative rather than imperative – each 
.deb would document the alternatives it'd like to see updated on 
install/remove/upgrade. If we had that piece of data, we could process it when 
unpacking a .deb without running the postinst as root. But because right now 
this information is buried inside a shell script which could be of any form and 
expects to be run as root, we can't use it without resorting to solutions 
involving chroots.

While I agree that maybe “debs” should have additional declarative 
functionality like this, that currently isn’t the case. In my view SNAPs should 
be designed to live in the world that IS not in the world we’d like it to be. 
To be honest I’m surprised that SNAPs don’t make more use of “chroot” like you 
elude to. I suspect that running the postinst step inside a “chroot” would 
allow a lot of things to be done in a secure manner.

Not to take this thread off in a different direction but the major issue we’re 
having in moving a whole subsystem into a SNAP (one that we didn’t write but 
that we are SNAPifying – it happens to be OpenSwitch)  is tracking down and 
finding all the references the absolute root file system names and then adding 
the appropriate $SNAP_xxx prefix in front of each of them by CHANGING (yuck) 
the code. I wish that SNAPs could have made use of chroot and maybe found a 
neat way to layer the chroot inside the SNAP and the Unbuntu core on top of 
particular real root directories for R/O access (if the file wasn’t present in 
the chroot directory). I’m showing my age here but I wish there was a way you 
could use chroot and the concept that is used in that ancient (but I understand 
still being sold) OpenVMS O/S that allowed you to define “concealed logical 
names” mapped to an equivalence LIST that essentially enabled one name to 
reference a list of real directories in way where the user is totally unaware 
that the “logical” directory is really an amalgamation of contributions from 
multiple different places. Anyway I digress, I guess for now I’ll hack a custom 
solution for the “deb” I’m having issues with due to the postinst not being 
able to be run.

From: loic.min...@canonical.com [mailto:loic.min...@canonical.com] On Behalf Of 
Loïc Minier
Sent: Tuesday, August 09, 2016 8:18 AM
To: David Garrod
Cc: Didier Roche; snapcr...@lists.ubuntu.com
Subject: Re: How do I get a postinst stage properly executed - traceroute will 
not install correctly

Hi,

On Mon, Aug 8, 2016 at 12:01 PM, David Garrod 
mailto:dgar...@extremenetworks.com>> wrote:
While I’m sure I could hack this particular case and add a link in the startup 
of my snap I don’t see this as a general solution. What if a later version of 
the package changes the name of the file or something. Any true solution has to 
be based in what is in the postinst for the version of the package being 
installed. This seems like a general issue to me. In order to make the whole 
snap concept viable surely you have to be able to take packages unchanged and 
have your SNAP depend on them just as packages in the non-SNAP world depend on 
each other. I’d really like to see a mechanism whereby the installation of a 
SNAP can run the post install configure step in the context of the 
installation. Maybe that would involve deferring some of this to the snap start 
if absolutely necessary but in general this would not be needed. Are there any 
active plans to address this fundamental design issue?

It's indeed by design; snaps and debs are different. In the .deb world, you can 
hack the whole system in the postinst, leading to intrusive changes or problems 
upgrading, interferences between postinst initiated changes etc.

However perhaps the design issue you're seeing is not with snaps but rather 
with debs: alternatives should be declarative rather than imperative – each 
.deb would document the alternatives it'd like to see updated on 
install/remove/upgrade. If we had that piece of data, we could process it when 
unpacking a .deb without running the postinst as root. But because right now 
this information is buried inside a shell script which could be of any form and 
expects to be run as root, we can't use it without resorting to solutions 
involving chroots.

- Loïc Minier



DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary 
material and is solely for the use of the intended recipient. Any review, use, 
disclosure, distribution or copying of this transmittal is prohibited except by 
or on behalf of the intended recipient. If you have received this transmittal 
in error, please notify the sender and destroy this e-mail and any attachments 
and all copies, whether electronic or printed.
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listi

Re: ntopng strict snap published

[Evan Dandrea]

On Mon, 8 Aug 2016 at 17:51 Sergio Schvezov 
wrote:

> El 08/08/16 a las 13:35, Blake Rouse escribió:
> > I would like to setup some travis CI that will auto upload tip of
> > dev into the edge channel of "ntopng".
>
> Evan has some guides for setting up CI and could also solve or point you
> in the right direction to take the reserved name.
>
> snapcraft 2.15 should be able to allow setting up macaroons through env
> vars (to make it easier to use things like travis-ci) but that shouldn't
> stop you from using ev's current solution.
>

This will let you build and publish snaps off Travis runs. You'll want to
change $MACAROON_SECRET to your favourite value from pwgen. You'll also
need to change the snap name and the $TRAVIS_BRANCH conditional.

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

Re: How to handle conffiles in snaps?

[Kyle Fazzari]

On 08/09/2016 12:18 AM, Christian Ehrhardt wrote:
>
> On Tue, Aug 9, 2016 at 7:38 AM, Simon Fels  > wrote:
>
> Thanks a lot Simon for the answers!
> A few clarifications requests inline below (mostly getting the bug #
> to subscribe and refer).
>
> For upgrades
> there will be a hook at some point in the near future which will
> notify
> when your snap is upgraded and you can perform similar logic like you
> can do in the maintainer scripts to handle changed formts etc. But as
> far as I know there will be no modifications to the real /etc allowed
> for any application snap.
>
>
> Ok, I consider this WIP then - is there a bug I could subscribe myself
> and link to from my code?

Not yet (that I know of).

>  
>
> You could still store conf files in SNAP_USER_DATA to get them
> writable
> by the users of the system.
>
>
> It is a daemon that needs the conf, so I think I'll try hack something
> up in SNAP_DATA for now.
>  
>
> > The only snap-centric artifact about it I found was [1]. But
> that feels
> > broken/outdated as there is no "snappy" command anymore (and
> snap has no
> > "config" subcommand).
>
> Something similar will come back. From what I've heard there will be a
> apply-config hook which you can implement in your snap and a user can
> call from the outside with a simple 'snap set
> snap.name.confkey=confvalue' or similar.
>
>
> Thanks, as above I consider this WIP then - is there a bug I could
> subscribe myself and link to from my code?

Yeah, keep an eye on this one:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1596629

-- 
Kyle Fazzari (kyrofa)
Software Engineer
Canonical Ltd.
k...@canonical.com



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: How do I share a namespace between snap commands?

[David Garrod]

Re:

> even if you continue posting here (which is good to trigger discussion), 
> please file a bug against the snappy launchpad project:
>https://launchpad.net/snappy/ (even if I think this one may impact rather 
>snap-confine, but it will be redirected)
>
>Didier

Thanks. I've followed your suggestion and have logged bug:

https://bugs.launchpad.net/snappy/+bug/1611444




DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary 
material and is solely for the use of the intended recipient. Any review, use, 
disclosure, distribution or copying of this transmittal is prohibited except by 
or on behalf of the intended recipient. If you have received this transmittal 
in error, please notify the sender and destroy this e-mail and any attachments 
and all copies, whether electronic or printed.


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

Re: Copying the same file under different names in the yaml

[Christian Ehrhardt]

On Tue, Aug 9, 2016 at 5:50 PM, Cemil Azizoglu  wrote:

>   wrappers:
> plugin: copy
> files:
>   file.wrapper: A
>   file.wrapper: B
>

There might be something better, but what about this?:

  wrappersA:
plugin: copy
files:
  file.wrapper: A
  wrappersB:
plugin: copy
files:
  file.wrapper: B


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Copying the same file under different names in the yaml

[Cemil Azizoglu]

Hi,

I'd like to copy the same file under different names in my snap. So I'm
looking for something like this :

<...>
apps:
  A:
command: A
  B:
command: B
<...>
  wrappers:
plugin: copy
files:
  file.wrapper: A
  file.wrapper: B
---
But only the last one seems to take effect. Is there a way to express this?

Thanks,
Cemil Azizoglu
Mir Display Server - Team Lead
Canonical USA
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: How to handle conffiles in snaps?

[Oliver Grawert]

hi,
On Di, 2016-08-09 at 07:01 +, Nick Moffitt wrote:
> Simon Fels:
> > 
> > On 08.08.2016 22:06, Christian Ehrhardt wrote:
> > > 
> > > I was wondering how conffiles should be handled with snapcraft /
> > > snaps in general.
> [...]
> > 
> > You could still store conf files in SNAP_USER_DATA to get them
> > writable
> > by the users of the system.
> 
> Is there a good facility for install-time copying of template configs
> or
> other writeable-from-initial-state data into $SNAP_USER_DATA?
> 
no, SNAP_USER_DATA is a runtime, not a build time thing ... you have to
do it from your wrapper script that you most likely have to use anyway
for other stuff to set up the environment for your binary (also there
are not really any install time hooks, we are not debs with maintainer
scripts (luckily)) 

;)

at [1] and [2] you can see some examples ...

ciao
oli

[1] https://github.com/ogra1/packageproxy/blob/master/run-approx
[2] https://github.com/ogra1/upnp-server

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

Sharing "$HOME/.foo" between developer builds

[John Meinel]

One thing that has come up in recent conversations is that while it is
great that I can push up a custom build of an official snap and have
someone just try it, none of their settings will come across.

The specific case is for us developing Juju, where Juju will go out and
create new machines in AWS for you, and then tracks them currently in
~/.local/share/juju/*.yaml files. I we wanted to move those files into the
SNAP_USER_DATA, then when I try to install a developer's version of Juju,
none of my controllers would be visible. (And even if we had a mechanism to
copy the data over, the data no longer stays in sync if I created/removed
entities in juju-jameinel.juju testing.)

AIUI there is an interface for $HOME, but that doesn't expose any dot
files. Is there something around "I am an application of this  and
I'd like access to all of the data for " that doesn't require
creating an new interface for every application?

(As another example, imagine someone did a custom build of Firefox,
wouldn't you expect to still see all of your bookmarks?)

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

Re: How do I get a postinst stage properly executed - traceroute will not install correctly

[Loïc Minier]

Hi,

On Mon, Aug 8, 2016 at 12:01 PM, David Garrod 
wrote:

> While I’m sure I could hack this particular case and add a link in the
> startup of my snap I don’t see this as a general solution. What if a later
> version of the package changes the name of the file or something. Any true
> solution has to be based in what is in the postinst for the version of the
> package being installed. This seems like a general issue to me. In order to
> make the whole snap concept viable surely you have to be able to take
> packages unchanged and have your SNAP depend on them just as packages in
> the non-SNAP world depend on each other. I’d really like to see a mechanism
> whereby the installation of a SNAP can run the post install configure step
> in the context of the installation. Maybe that would involve deferring some
> of this to the snap start if absolutely necessary but in general this would
> not be needed. Are there any active plans to address this fundamental
> design issue?
>

It's indeed by design; snaps and debs are different. In the .deb world, you
can hack the whole system in the postinst, leading to intrusive changes or
problems upgrading, interferences between postinst initiated changes etc.

However perhaps the design issue you're seeing is not with snaps but rather
with debs: alternatives should be declarative rather than imperative – each
.deb would document the alternatives it'd like to see updated on
install/remove/upgrade. If we had that piece of data, we could process it
when unpacking a .deb without running the postinst as root. But because
right now this information is buried inside a shell script which could be
of any form and expects to be run as root, we can't use it without
resorting to solutions involving chroots.

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

Re: .desktop files for app-in-snap

[Vasilisc]

09.08.2016 12:47, Oliver Grawert пишет:

hi,
Am Dienstag, den 09.08.2016, 10:23 +0300 schrieb Vasilisc:


run wallpaperdownloader in Terminal and pin app

close wallpaperdownloader and launch app from Unity Launcher.
something happening? none!

"Exec=java" try execute Java in the host, but Java is not installed
by
default.

Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java
Sorry for my english. really only I see a problem?


your .desktop file is in the wrong place ... you need to put it into
your source directory into the "setup/gui" directory together with the
icon...

here is a java app that i packaged, take a look at the setup/gui
directory and at the "wrapper" script:

https://github.com/ogra1/jtiledownloader

now try the following:

sudo snap install jtiledownloader

once this is done, hit the windows key on your keyboard to bring up the
dash ... click the A at the bottom of the dash window to search for
applications, type "jtile" and you see an icon ... click it ...
the app starts, pin the icon in the launcher ... close the app ...

Good example! Thx

cat ~/.local/share/applications$ cat 
org-openstreetmap-fma-jtiledownloader-jtiledownloaderstart.desktop


[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
Name=JTileDownloader Version: 0.6.1
Icon=org-openstreetmap-fma-jtiledownloader-jtiledownloaderstart.png
Path=/home/vasilisc/snap/jtiledownloader/2
Exec=/snap/jtiledownloader/2/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java 
-jar /snap/jtiledownloader/2/jTileDownloader-0-6-1.jar

StartupNotify=false
StartupWMClass=org-openstreetmap-fma-jtiledownloader-JTileDownloaderStart
OnlyShowIn=Unity;
X-UnityGenerated=true

Right line
Exec=/snap/jtiledownloader/2/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java 
-jar /snap/jtiledownloader/2/jTileDownloader-0-6-1.jar


Thx Oliver.


if you now click the launcher icon again the app will start properly...

do *not* put anything manually into ~/.local/share, snapd puts the
.desktop file in the right place for the system if you had it in the
setup/gui dir in your snap source ...

ciao
oli






--
Best regards,
vasilisc

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

Re: .desktop files for app-in-snap

[Oliver Grawert]

hi,
Am Dienstag, den 09.08.2016, 10:23 +0300 schrieb Vasilisc:
> 
> run wallpaperdownloader in Terminal and pin app
> 
> close wallpaperdownloader and launch app from Unity Launcher.
> something happening? none!
> 
> "Exec=java" try execute Java in the host, but Java is not installed
> by 
> default.
> 
> Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java
> Sorry for my english. really only I see a problem?
> 
your .desktop file is in the wrong place ... you need to put it into
your source directory into the "setup/gui" directory together with the
icon... 

here is a java app that i packaged, take a look at the setup/gui
directory and at the "wrapper" script:

https://github.com/ogra1/jtiledownloader

now try the following:

sudo snap install jtiledownloader

once this is done, hit the windows key on your keyboard to bring up the
dash ... click the A at the bottom of the dash window to search for
applications, type "jtile" and you see an icon ... click it ... 
the app starts, pin the icon in the launcher ... close the app ...

if you now click the launcher icon again the app will start properly...

do *not* put anything manually into ~/.local/share, snapd puts the
.desktop file in the right place for the system if you had it in the
setup/gui dir in your snap source ...

ciao
oli

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

demon snmp in snap

[BlinCT .]

Good afternoon.
My name is Alexey
I write for the first time, hoping to get advice from you
Recently I started to try building a programs into Snap package. I need to
build a demon. But unfortunatly there was a many problems due working. I
faced on the lacking of documentation and description of the principle
operation with demons.
I will try to describe the work and attaching a file with yaml file and
binary file (f2d).
The system should work with 2 demons, snmpd and my own sub-agent. snmp
service is working with system. sub-agent is handle our requests, which are
not known for the snmpd.
snmp should be able to "--start" and "--stop".
sub-agent can running with different keys, for example ./f2d -Lo -n

My questions:
1. How to make packaging into snap pack with 2 demons if I want a program
running only by root and with the keys?
2. How to work with file out of $SNAP?
3. I collect snmp, he unpackage /etc/snmp/snmpd.conf and then I want to
replace it by my own snmpd.conf. how to do it?
4. The system have snmp. Could I install and work with other snmp in a
program, if snmp was build in snap package?

The archive contains files *.mib.txt with information for snmp. If main
snmpd doesn't knows *.mib.txt data they have sent sub-agent f2d.
f2d - sub-agent
f2d.dat - a data file which running with sub-agent and verify his changes.
The file can be changed. In that build file must be located in
/etc/snmp.data/f2d.dat


Thank you for your attention!
I really count upon your help.
I would be deeply grateful for all your advice.
Sincerely, Alexey

snapcraft.yaml

name: f2d
version: 0.1
summary: This is my-snap's summary
description: test snmp demon
confinement: strict

parts:
f2d:
plugin: copy
files:
bin/f2d : usr/bin/f2d
bin/Alexey.MIB.txt : usr/share/snmp/mibs/alexey1.mib.txt
bin/f2d.mib.txt : usr/share/snmp/mibs/f2d.mib.txt
bin/f2d.dat : /etc/snmp.data/f2d.dat
bin/snmpd.conf : etc/snmp/snmpd.conf

integration:
plugin: nil
stage-packages:
- snmp
- snmpd
- smitools

apps:
f2d:
command: usr/bin/f2d
daemon: simple

snmpd:
command: etc/init.d/snmpd --start
stop-command: etc/init.d/snmpd --stop
daemon: forking
plugs: ['network']
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: .desktop files for app-in-snap

[PC Actual]

Hi again Vasilisc.

Now I see the problem. If you pin the application executed from the
terminal, the Operating System creates its own standard launcher and
"bypasses" the init script you have defined within the snap package.
Instead, if you want to pin a snap application, you have to use the
launcher which was created in the dashboard (it has the icon you defined
within the snap package).

I think it is a limitation that you cannot handle, but please, if anyone
knows how to deal with it... :)

Best,

Eloy

2016-08-09 9:23 GMT+02:00 Vasilisc :

> 09.08.2016 10:05, Eloy García (PC Actual) пишет:
>
>> Hi again!
>> You don't need to have java installed on your system. This is the
>> "magic" of a snap package, that you can include anything your
>> application needs to run properly. I use maven plugin for my
>> application, so openjdk 8 is installed within the snap package.
>>
>
> Please, create the virtual machine with Ubuntu 16.04.
> Install - sudo snap install wallpaperdownloader
>
> run wallpaperdownloader in Terminal and pin app
>
> close wallpaperdownloader and launch app from Unity Launcher.
> something happening? none!
>
> "Exec=java" try execute Java in the host, but Java is not installed by
> default.
>
> Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java
> Sorry for my english. really only I see a problem?
>
>
>> El 9 ago. 2016 7:31 a. m., "Vasilisc" > > escribió:
>>
>> 09.08.2016 07:52, Vasilisc пишет:
>>
>> 08.08.2016 11:13, Eloy García (PC Actual) пишет:
>>
>> Hi! You can take a loot at snappy playpen github repository.
>> There is an
>> application (wallpaperdownloader) that it is java-based and
>> it has a
>> desktop icon working fine. This is the URL:
>>
>> https://github.com/ubuntu/snappy-playpen
>> 
>>
>> Best wishes!
>>
>> El 8 ago. 2016 9:46 a. m., "Didier Roche"
>> mailto:didro...@ubuntu.com>
>> >>
>> escribió:
>>
>> >
>>
>> Le 08/08/2016 à 08:47, Vasilisc a écrit :
>> > 08.08.2016 08:50, Didier Roche пишет:
>> >> Le 06/08/2016 à 09:47, Vasilisc a écrit :
>>  Please help me. If I launch the program in the
>> Terminal - well
>> done,
>>  but
>>  I can't start program from Unity Launcher.
>> 
>>  I tried to change parameter Exec in
>>  ~/.local/share/applications/app.desktop
>>  Exec=app-name
>>  Exec=snap-name.app-name
>>  Exec=$SNAP/usr/bin/start-script.sh
>>  Exec=$snap.$app
>> (http://snapcraft.io/docs/snaps/structure
>> )
>>
>> 
>>  and studied case
>>
>> https://github.com/ubuntu/snap
>> py-playpen/blob/master/vlc/setup/gui/vlc.desktop
>> > ppy-playpen/blob/master/vlc/setup/gui/vlc.desktop>
>>
>> > setup/gui/vlc.desktop
>> > setup/gui/vlc.desktop>>
>>
>> 
>> 
>> 
>>  but it didn't help.
>> 
>> >>> suspect lines
>> >>> Aug  6 10:20:35 vb gnome-session[2377]:
>> (gnome-software:2582):
>> >>> As-WARNING **: failed to rescan: Failed to parse
>> >>>
>>
>> /home/vasilisc/.local/share/applications/org-languagetool-gu
>> i-main.desktop
>>
>> >>>
>> >>> file: cannot process file of type
>> application/x-desktop
>> >>>
>> >>>
>> >> Hey Vasilisc,
>> >>
>> >> You didn't provide your .desktop file in setup/gui/
>> directory. Do you
>> >> mind doing this?
>> >> I suspect your type is different from
>> "Type=Application", which it
>> >> should be.
>> >> Didier
>> >
>> > I found a problem. My script-wrapper (usr/bin/run.sh)
>> run java app
>> > #!/bin/bash
>> >  bla-bla-bla 
>> > java -jar -Duser.home=$SNAP_USER_DATA
>> $SNAP/usr/bin/languagetool.jar
>> >
>> > in snapcraft.yaml
>> > apps:
>> >   languaget

Re: How to handle conffiles in snaps?

[Christian Ehrhardt]

On Tue, Aug 9, 2016 at 9:01 AM, Nick Moffitt 
wrote:

> > You could still store conf files in SNAP_USER_DATA to get them writable
> > by the users of the system.
>
> Is there a good facility for install-time copying of template configs or
> other writeable-from-initial-state data into $SNAP_USER_DATA?
>
> The way snaps are invoked do a great job of hijacking the $*PATH
> variables used to find executables and shared objects, but often we need
> to hack in a lot of shuffling around for /usr/share and /etc and /var/
> to aim them at snappy's special directories.


Yeah, that is a good question as well.
As you said, for now there is a lot of hacking to get access to those and
since there is no defined way (I'd know of) to provide templates.
But there is no need every app (re-)implements such hacks that in some
other way.
So +1 for an official snapcraft/snap way to make files available in
$SNAP_USER_DATA and such.

I'd think of something like support for that in the copy plugin like
supporting:
parts:
 defaultconf:
   plugin: copy
   files:
   etc/example.conf: $SNAP_USER_DATA/etc/foo.conf

Surely there is some more magic glue involved as on "snap building time"
the path of $SNAP_USER_DATA and such isn't fix IIRC (could change per setup
and in future).
Worth a feature request bug? I'll wait for the discussion first.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: .desktop files for app-in-snap

[Vasilisc]

09.08.2016 10:05, Eloy García (PC Actual) пишет:

Hi again!
You don't need to have java installed on your system. This is the
"magic" of a snap package, that you can include anything your
application needs to run properly. I use maven plugin for my
application, so openjdk 8 is installed within the snap package.


Please, create the virtual machine with Ubuntu 16.04.
Install - sudo snap install wallpaperdownloader

run wallpaperdownloader in Terminal and pin app

close wallpaperdownloader and launch app from Unity Launcher.
something happening? none!

"Exec=java" try execute Java in the host, but Java is not installed by 
default.


Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java
Sorry for my english. really only I see a problem?



El 9 ago. 2016 7:31 a. m., "Vasilisc" mailto:vasilisc...@gmail.com>> escribió:

09.08.2016 07:52, Vasilisc пишет:

08.08.2016 11:13, Eloy García (PC Actual) пишет:

Hi! You can take a loot at snappy playpen github repository.
There is an
application (wallpaperdownloader) that it is java-based and
it has a
desktop icon working fine. This is the URL:

https://github.com/ubuntu/snappy-playpen


Best wishes!

El 8 ago. 2016 9:46 a. m., "Didier Roche"
mailto:didro...@ubuntu.com>
>>
escribió:

>

Le 08/08/2016 à 08:47, Vasilisc a écrit :
> 08.08.2016 08:50, Didier Roche пишет:
>> Le 06/08/2016 à 09:47, Vasilisc a écrit :
 Please help me. If I launch the program in the
Terminal - well
done,
 but
 I can't start program from Unity Launcher.

 I tried to change parameter Exec in
 ~/.local/share/applications/app.desktop
 Exec=app-name
 Exec=snap-name.app-name
 Exec=$SNAP/usr/bin/start-script.sh
 Exec=$snap.$app
(http://snapcraft.io/docs/snaps/structure
)

 and studied case


https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop




>




 but it didn't help.

>>> suspect lines
>>> Aug  6 10:20:35 vb gnome-session[2377]:
(gnome-software:2582):
>>> As-WARNING **: failed to rescan: Failed to parse
>>>


/home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop

>>>
>>> file: cannot process file of type application/x-desktop
>>>
>>>
>> Hey Vasilisc,
>>
>> You didn't provide your .desktop file in setup/gui/
directory. Do you
>> mind doing this?
>> I suspect your type is different from
"Type=Application", which it
>> should be.
>> Didier
>
> I found a problem. My script-wrapper (usr/bin/run.sh)
run java app
> #!/bin/bash
>  bla-bla-bla 
> java -jar -Duser.home=$SNAP_USER_DATA
$SNAP/usr/bin/languagetool.jar
>
> in snapcraft.yaml
> apps:
>   languagetool:
> command: usr/bin/run.sh
> plugs: [network, network-bind, x11, home, unity7]
>
>
> If to attach the java-app to a panel Unity Launcher,
then the file
>
(~/.local/shape/applications/org-languagetool-gui-main.desktop
) will
> contain.
>
> [Desktop Entry]
> Encoding=UTF-8
> Version=1.0
> Type=Application
> Name=LanguageTool 3.4-SNAPSHOT
> Icon=org-languagetool-gui-main
> Exec=java -jar
-Duser.home=/home/vasilisc/snap/languagetool/x1
> /snap/languagetool/x1/usr/bin/languagetool.jar
>
> In a host-s

Re: How to handle conffiles in snaps?

[Christian Ehrhardt]

On Tue, Aug 9, 2016 at 7:38 AM, Simon Fels  wrote:

Thanks a lot Simon for the answers!
A few clarifications requests inline below (mostly getting the bug # to
subscribe and refer).

For upgrades
> there will be a hook at some point in the near future which will notify
> when your snap is upgraded and you can perform similar logic like you
> can do in the maintainer scripts to handle changed formts etc. But as
> far as I know there will be no modifications to the real /etc allowed
> for any application snap.
>

Ok, I consider this WIP then - is there a bug I could subscribe myself and
link to from my code?


> You could still store conf files in SNAP_USER_DATA to get them writable
> by the users of the system.
>

It is a daemon that needs the conf, so I think I'll try hack something up
in SNAP_DATA for now.


> > The only snap-centric artifact about it I found was [1]. But that feels
> > broken/outdated as there is no "snappy" command anymore (and snap has no
> > "config" subcommand).
>
> Something similar will come back. From what I've heard there will be a
> apply-config hook which you can implement in your snap and a user can
> call from the outside with a simple 'snap set
> snap.name.confkey=confvalue' or similar.
>

Thanks, as above I consider this WIP then - is there a bug I could
subscribe myself and link to from my code?


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: .desktop files for app-in-snap

[PC Actual]

Hi again!
You don't need to have java installed on your system. This is the "magic"
of a snap package, that you can include anything your application needs to
run properly. I use maven plugin for my application, so openjdk 8 is
installed within the snap package.

El 9 ago. 2016 7:31 a. m., "Vasilisc"  escribió:

> 09.08.2016 07:52, Vasilisc пишет:
>
>> 08.08.2016 11:13, Eloy García (PC Actual) пишет:
>>
>>> Hi! You can take a loot at snappy playpen github repository. There is an
>>> application (wallpaperdownloader) that it is java-based and it has a
>>> desktop icon working fine. This is the URL:
>>>
>>> https://github.com/ubuntu/snappy-playpen
>>>
>>> Best wishes!
>>>
>>> El 8 ago. 2016 9:46 a. m., "Didier Roche" >> > escribió:
>>>
>>> >
>>>
>>> Le 08/08/2016 à 08:47, Vasilisc a écrit :
 > 08.08.2016 08:50, Didier Roche пишет:
 >> Le 06/08/2016 à 09:47, Vasilisc a écrit :
  Please help me. If I launch the program in the Terminal - well
 done,
  but
  I can't start program from Unity Launcher.
 
  I tried to change parameter Exec in
  ~/.local/share/applications/app.desktop
  Exec=app-name
  Exec=snap-name.app-name
  Exec=$SNAP/usr/bin/start-script.sh
  Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure)
 
  and studied case

 https://github.com/ubuntu/snappy-playpen/blob/master/vlc/
>>> setup/gui/vlc.desktop
>>>
>>> >> setup/gui/vlc.desktop>
>>>
>>> 
 
 
  but it didn't help.
 
 >>> suspect lines
 >>> Aug  6 10:20:35 vb gnome-session[2377]: (gnome-software:2582):
 >>> As-WARNING **: failed to rescan: Failed to parse
 >>>

>>> /home/vasilisc/.local/share/applications/org-languagetool-gu
>>> i-main.desktop
>>>
>>> >>>
 >>> file: cannot process file of type application/x-desktop
 >>>
 >>>
 >> Hey Vasilisc,
 >>
 >> You didn't provide your .desktop file in setup/gui/ directory. Do you
 >> mind doing this?
 >> I suspect your type is different from "Type=Application", which it
 >> should be.
 >> Didier
 >
 > I found a problem. My script-wrapper (usr/bin/run.sh) run java app
 > #!/bin/bash
 >  bla-bla-bla 
 > java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar
 >
 > in snapcraft.yaml
 > apps:
 >   languagetool:
 > command: usr/bin/run.sh
 > plugs: [network, network-bind, x11, home, unity7]
 >
 >
 > If to attach the java-app to a panel Unity Launcher, then the file
 > (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will
 > contain.
 >
 > [Desktop Entry]
 > Encoding=UTF-8
 > Version=1.0
 > Type=Application
 > Name=LanguageTool 3.4-SNAPSHOT
 > Icon=org-languagetool-gui-main
 > Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1
 > /snap/languagetool/x1/usr/bin/languagetool.jar
 >
 > In a host-system can't execute a command (it's impossible)
 > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1
 > /snap/languagetool/x1/usr/bin/languagetool.jar
 >
 > I don't know what to do.

 You need to ship yourself your .desktop file, as you pointed via the vlc
 desktop file inside the snapcraft source.

 This one will have the correct Exec= after building it with snapcraft
 rather then one generated from unity.


 --
 Snapcraft mailing list
 Snapcraft@lists.snapcraft.io 
 Modify settings or unsubscribe

>>> at:https://lists.ubuntu.com/mailman/listinfo/snapcraft
>>> 
>>>
>>> 0) snap install wallpaperdownloader
>> 81.81 MB / 81.84 MB
>> [===
>> 
>> ==>_]
>> 99.97 % 1.74 MB/s
>>
>> wallpaperdownloader (stable) 2.1 from 'egarcia' installed
>>
>> 1) Run java-app wallpaperdownloader in Terminal or Alt+F2
>>
>> 2) To attach the program on a panel Unity.
>>
>> 3) cat .local/share/applications/es-estoes-wallpaperdownloader-main
>> .desktop
>>
>> [Desktop Entry]
>> Encoding=UTF-8
>> Version=1.0
>> Type=Application
>> Name=WallpaperDownloader V2.1
>> Icon=es-estoes-wallpaperdownloader-main.png
>> Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3
>> /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar
>> StartupNotify=false
>> StartupWMClass=es-estoes-wallpaperDownloader-Main
>> OnlyShowIn=Unity;
>> X-UnityGenerated=true
>> -
>> "Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3
>> /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar"
>>
>> If Java is not installed on your

Re: How to handle conffiles in snaps?

[Nick Moffitt]

Simon Fels:
> On 08.08.2016 22:06, Christian Ehrhardt wrote:
> > I was wondering how conffiles should be handled with snapcraft /
> > snaps in general.
[...]
> You could still store conf files in SNAP_USER_DATA to get them writable
> by the users of the system.

Is there a good facility for install-time copying of template configs or
other writeable-from-initial-state data into $SNAP_USER_DATA?

The way snaps are invoked do a great job of hijacking the $*PATH
variables used to find executables and shared objects, but often we need
to hack in a lot of shuffling around for /usr/share and /etc and /var/
to aim them at snappy's special directories.

-- 
Nick Moffitt

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