Re: ANN: snapcraft 2.14 has been released
El 17/08/16 a las 22:47, David Chen escribió: > Hi Sergio, > > Do you know where I can find examples for new plugins `dump`, `rust` and > `godeps`? For godeps look at the juju folk (ping balloons on irc). For dump, it is pretty straightforward, the tomcat maven example/demo in the sources use it. Rust is contributed by the community, I have no example but know elopio ran a project with it. In any case, `snapcraft help ` is what you need to get started. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
HEADS UP: New spread version coming
Hello all, The following changes have just landed in the spread repository, some of them incompatible with the previous yaml files. Given the incompatibility, the spread snap or the binary version used by the snapd tests weren't updated, but this should happen at some point tomorrow. The main changes are: - Reboot at any point by simply inlining the # REBOOT comment - New QEMU backend, thanks to Michael Vogt - Environment variables are now properly ordered - The syntax $[...] in env vars has been dropped - The syntax $(...) in env vars will now execute remotely as expected - The syntax $(HOST: ...) was introduced to execute the command locally - Both of these will now correctly strip of EOLs, thanks to John Lenton - Bash now executed with -u, to catch undefined vars, also thanks to John - Images with fixed usernames and passwords are now supported - $HOME won't be hacked when debugging tasks (-debug and -shell) The documentation was updated to cover all the changes: https://github.com/snapcore/spread Please let me know if you find any issues. gustavo @ http://niemeyer.net -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: ANN: snapcraft 2.14 has been released
Hi Sergio, Do you know where I can find examples for new plugins `dump`, `rust` and `godeps`? Thanks and Regards, -David On 08/11/2016 07:14 AM, Sergio Schvezov wrote: > Hi there, just in case people are not on the announce list (you should > if you care about these ANN emails), here's the announcement email link: > > https://lists.ubuntu.com/archives/snapcraft-announce/2016-August/00.html > > If you prefer formatted text the same content can be seen here: > > https://github.com/snapcore/snapcraft/releases/tag/2.14 > > Cheers > Sergio > > > -- * DAVID CHEN * Technical Lead | Field Engineering | UES RM D, 46F, No. 7, Sec. 5, Xin-Yi Rd., Taipei City, Taiwan 11049 *O* +(886) 2 8729-6885 *M* +(886) 988-858-524 -- 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
On Wed, Aug 17, 2016 at 5:42 PM Seth Arnold wrote: > On Wed, Aug 17, 2016 at 09:28:32PM +, Marco Ceppi wrote: > > Has anyone deprecated debian packages yet in favor of snaps? My end goal > is > > people who've installed the debian package from the xenial archive will > get > > an updated debian package which no longer is the software but instead > > either guides them to installing the snap or installs it for them. > > This sounds like a surprising and inconsiderate thing to do to our > users. There's probably still time to get your transitional package into > yakkety before feature freeze (or file for a feature freeze exception) but > once it was shipped in an LTS we've agreed to support it for five years. > (Where "support" is of course variable -- for main, we support it. For > universe, the community supports it and someone will sponsor updates.) > Well, it's either that or basically anyone who installs the debian version from the archive just deals with an out of date, never updated, version of the software. That to me, as a maintainer of a software project, feels more inconsiderate. I ask because I'd like to get my users the latest bits, but there seems to be no way for me to have a snap "conflict" with a deb package (which, I get is the whole point). So now, if you snap install, /usr/bin/ still takes priority over /snap/bin. This means I have make sure not only to tell people to snap install the software, but also uninstall the previous deb packages. I can only imagine this leading to a lot of confusion as updates are released in the snap but aren't reflected on users systems. > Be sure to consider how 16.04 LTS -> 18.04 LTS upgrades will work. We also > support LTS to LTS upgrades. > It sounds like I simply need to pull my packages from yakkety now. I don't plan on continuing to build debian packages going forward. I just don't see a point in it. -- 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
On Wed, Aug 17, 2016 at 09:28:32PM +, Marco Ceppi wrote: > Has anyone deprecated debian packages yet in favor of snaps? My end goal is > people who've installed the debian package from the xenial archive will get > an updated debian package which no longer is the software but instead > either guides them to installing the snap or installs it for them. This sounds like a surprising and inconsiderate thing to do to our users. There's probably still time to get your transitional package into yakkety before feature freeze (or file for a feature freeze exception) but once it was shipped in an LTS we've agreed to support it for five years. (Where "support" is of course variable -- for main, we support it. For universe, the community supports it and someone will sponsor updates.) Be sure to consider how 16.04 LTS -> 18.04 LTS upgrades will work. We also support LTS to LTS upgrades. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Guidance on deprecating debs for snaps
Hello! Today we have packages in xenial that provide software which I intend to provide as snap only going forward. Since I'm generally lazy, and don't want to do both snap and debs of the software, snaps are a huge win in simplicity of release for me. Has anyone deprecated debian packages yet in favor of snaps? My end goal is people who've installed the debian package from the xenial archive will get an updated debian package which no longer is the software but instead either guides them to installing the snap or installs it for them. Are there guidelines for how to do this? Has anyone tried before? Or should we not tangle these two yet? Marco -- 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?
Unfortunately my bug report has not received any substantive replies so I'm back here. Please could someone comment on the issue I'm having and/or give me a pointer on where to look to try and diagnose the cause of the failure. This problem is severely holding up our progress in SNAPifying OpenSwitch. Thanks, Dave -Original Message- From: David Garrod Sent: Tuesday, August 09, 2016 12:32 PM To: 'Didier Roche'; Jamie Strandboge; snapcr...@lists.ubuntu.com Subject: RE: How do I share a namespace between snap commands? 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: custom lxd bridges inside a snap
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: snapd events API
Understood, thanks for the details. For the time being, I suggest implementing that in terms of polling since we already have good APIs for that which should be very fast (it's all in memory). This gives us some more time to focus on the image deliverables that we have impending, and some time to design the events API properly as well. On Wed, Aug 17, 2016 at 11:22 AM, Ted Gould wrote: > > For me, the most critical events are package installed, upgraded¹ and > removed. The primary use-case is to handle entries on the Unity panel (i.e. > remove them if the package gets removed). That seems like an easy place to > get started. > > Ted > > ¹ Not sure if upgrade is a remove/install pair, listed for completeness, > not because we have a need for it to be distinct. > > On Wed, 2016-08-17 at 10:56 -0300, Gustavo Niemeyer wrote: > > Yeah, this is non-working remainings of something that wasn't discussed > much. > > Before patching it, we need to come up with a more clear idea of how the > API looks like, how it's supposed to evolve, and what's the plan for > integration into the various aspects of the system. > > On Wed, Aug 17, 2016 at 7:25 AM, John Lenton > wrote: > > On 17 August 2016 at 03:24, Robert Ancell > wrote: > > I've been trying to access snapd events using the REST API [1] and I'm > not > > able to get it working. > > I'm afraid the events work has fallen by the wayside. It was not > completed afaik, and obviously has no (or not enough) tests otherwise > this would've popped up. We're not using it for anything, and the only > consumer we had was also the implementer (namely snapweb) but moved > away from using (at least in the short term) it mid-implementation. > > I'm all for fixing it, but we're rather tight for time I'm afraid. > Patches welcome :-D > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing listsnapcr...@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/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: snapd events API
For me, the most critical events are package installed, upgraded¹ and removed. The primary use-case is to handle entries on the Unity panel (i.e. remove them if the package gets removed). That seems like an easy place to get started. Ted ¹ Not sure if upgrade is a remove/install pair, listed for completeness, not because we have a need for it to be distinct. On Wed, 2016-08-17 at 10:56 -0300, Gustavo Niemeyer wrote: > Yeah, this is non-working remainings of something that wasn't > discussed much. > > Before patching it, we need to come up with a more clear idea of how > the API looks like, how it's supposed to evolve, and what's the plan > for integration into the various aspects of the system. > > On Wed, Aug 17, 2016 at 7:25 AM, John Lenton > om> wrote: > > On 17 August 2016 at 03:24, Robert Ancell > > com> wrote: > > > I've been trying to access snapd events using the REST API [1] > > and I'm not > > > able to get it working. > > > > I'm afraid the events work has fallen by the wayside. It was not > > completed afaik, and obviously has no (or not enough) tests > > otherwise > > this would've popped up. We're not using it for anything, and the > > only > > consumer we had was also the implementer (namely snapweb) but moved > > away from using (at least in the short term) it mid-implementation. > > > > I'm all for fixing it, but we're rather tight for time I'm afraid. > > Patches welcome :-D > > > > -- > > Snapcraft mailing list > > Snapcraft@lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: custom lxd bridges inside a snap
On Wed, 2016-08-17 at 13:07 +, Adam Stokes wrote: > After talking to people in IRC I've been lead to believe that I can't > actually create and start a network bridge without the user running > additional commands. > > My user experience is: > > $ snap install conjure-up > > .. custom LXD bridge is created during that install, the bridge is then > started > > But what I'm being told is I have to do: > > $ snap install conjure-up > $ snap connect 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. > $ some form of systemctl command If you use: daemon: simple # or one of the others command: path/to/your/bridge/setup stop-command: path/to/your/bridge/teardown then a systemd unit is created for path/to/your/bridge/setup/command. Based on your yaml, it seems you understand this point and AIUI, recent hooks work in snapd can help with running restarting your units after interface connect. Perhaps others can comment on the status of that work and how to leverage it? -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: snapd events API
Yeah, this is non-working remainings of something that wasn't discussed much. Before patching it, we need to come up with a more clear idea of how the API looks like, how it's supposed to evolve, and what's the plan for integration into the various aspects of the system. On Wed, Aug 17, 2016 at 7:25 AM, John Lenton wrote: > On 17 August 2016 at 03:24, Robert Ancell > wrote: > > I've been trying to access snapd events using the REST API [1] and I'm > not > > able to get it working. > > I'm afraid the events work has fallen by the wayside. It was not > completed afaik, and obviously has no (or not enough) tests otherwise > this would've popped up. We're not using it for anything, and the only > consumer we had was also the implementer (namely snapweb) but moved > away from using (at least in the short term) it mid-implementation. > > I'm all for fixing it, but we're rather tight for time I'm afraid. > Patches welcome :-D > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Using sudo from within a snap
On Tue, 2016-08-16 at 10:59 -0500, Jamie Strandboge wrote: > On Tue, 2016-08-16 at 09:53 -0400, Chris Wayne wrote: > > > > Is this something that could be added to the roadmap? We'd really prefer > > to not have to call the snap itself with sudo as it creates some > > permissions issues (root-owned dirs in $HOME for example) and some other > > general flakiness. What would the sudo interface entail, just access to > > /usr/bin/sudo and /etc/sudoers.d/snap.mountpoint? > > > In the bug[1] we're focused on sudo and/or pkexec not working within a devmode > snap. With devmode, sudo should work and we can work through how to fix that. > Indeed, the conversation has moved to the bug. > For those interested, there was a bug in the snap itself and the details can be found here: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292/comments/4 -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Putting git inside a snap
El 17/08/16 a las 10:36, Marco Ceppi escribió: > On Tue, Aug 16, 2016 at 10:11 PM Sergio Schvezov > mailto:sergio.schve...@canonical.com>> > wrote: > > Create a new `apps` entry like this > > apps: >sh: >command: bash >plugs: [same list of plugs used by what calls git] > > > I did something similar: > > apps: > git: > command: usr/bin/git > plugs: [...] > > This way I could mess around with charm.git and play with environment > variables. At the end of the day GIT_EXEC_PATH and PREFIX were needed. > > Even still I'm having issues with things like `git clone --recursive` so > I've patched those calls out of the source code for now (when not > needed). I'll keep playing around to see if I can get git-submodules to > work but 95% of the use cases for the tool are functioning now. > > > There's a `snap shell` (or similar) command making a come back some time > and would make this more straightforward. > > For what it's worth I strace and gdb like this in a `snap try` session. > > > I spent quite a long time with strace against charm.git, but that lead > to more problems than help. I've not used `snap try` yet. The reason I mention `snap try` is becuase I am lazy :-) snap try --devmode prime Then if needed when in the snap's environment cp /usr/bin/strace prime And anything else you can think of. -- 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
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
Re: Putting git inside a snap
On Tue, Aug 16, 2016 at 10:11 PM Sergio Schvezov < sergio.schve...@canonical.com> wrote: > Create a new `apps` entry like this > > apps: >sh: >command: bash >plugs: [same list of plugs used by what calls git] > I did something similar: apps: git: command: usr/bin/git plugs: [...] This way I could mess around with charm.git and play with environment variables. At the end of the day GIT_EXEC_PATH and PREFIX were needed. Even still I'm having issues with things like `git clone --recursive` so I've patched those calls out of the source code for now (when not needed). I'll keep playing around to see if I can get git-submodules to work but 95% of the use cases for the tool are functioning now. > There's a `snap shell` (or similar) command making a come back some time > and would make this more straightforward. > > For what it's worth I strace and gdb like this in a `snap try` session. > I spent quite a long time with strace against charm.git, but that lead to more problems than help. I've not used `snap try` yet. -- 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
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)
David
>
> It might be reasonable to have a snap.yaml flag to turn that ability OFF
> for some snaps, but it seems silly to have boilerplate for debugging
> purposes.
>
> For example, how about adding a 'enter-sandbox' command to snap, so:
>
> $ snap enter-sandbox app.command
> Now running inside the sandbox for app.command
> $
>
> And in snap.yaml:
>
>
> debugging: [ allow-sandbox ]
>
> Mark
>
>
>
--
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
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.
It might be reasonable to have a snap.yaml flag to turn that ability OFF
for some snaps, but it seems silly to have boilerplate for debugging
purposes.
For example, how about adding a 'enter-sandbox' command to snap, so:
$ snap enter-sandbox app.command
Now running inside the sandbox for app.command
$
And in snap.yaml:
debugging: [ allow-sandbox ]
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: custom lxd bridges inside a snap
After talking to people in IRC I've been lead to believe that I can't actually create and start a network bridge without the user running additional commands. My user experience is: $ snap install conjure-up .. custom LXD bridge is created during that install, the bridge is then started But what I'm being told is I have to do: $ snap install conjure-up $ snap connect $ some form of systemctl command This is required even though I've set in my snapcraft.yaml that I need access to those plugins (network-control, network-bind, firewall-control). This is actually a blocker for me as I can not replicate the same user experience as if the user was installing via deb packages. Am I missing anything? Can this be resolved to just running a single install command and having everything setup for the user to start with? For reference this is my snapcraft and files I need to work: https://github.com/conjure-up/conjure-up/tree/patch-add-bridge-to-snap/snapcraft On Tue, Aug 16, 2016 at 5:04 PM Jamie Strandboge wrote: > On Tue, 2016-08-16 at 19:07 +, Adam Stokes wrote: > > I've found some discussion on this here: > > > > > https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html > > > > I am curious to know if this is possible now or still a work in > progress? I > > have a snap that requires a custom LXD bridge and would like to make use > of > > that if possible. > > The 'network-control' interface is meant to be used for this sort of thing > and > should give you the permissions required for setting up bridges, etc. If > there > are bugs with the security policy, please file them at: > > https://bugs.launchpad.net/snappy/+filebug > > and add the 'snapd-interface' tag. > > -- > Jamie Strandboge | http://www.canonical.com > > -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: snapd events API
On 17 August 2016 at 03:24, Robert Ancell wrote: > I've been trying to access snapd events using the REST API [1] and I'm not > able to get it working. I'm afraid the events work has fallen by the wayside. It was not completed afaik, and obviously has no (or not enough) tests otherwise this would've popped up. We're not using it for anything, and the only consumer we had was also the implementer (namely snapweb) but moved away from using (at least in the short term) it mid-implementation. I'm all for fixing it, but we're rather tight for time I'm afraid. Patches welcome :-D -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
