Re: desktop-gtk3

[Didier Roche]

Le 31/03/2017 à 05:55, Spencer Parkin a écrit :

That just adds a deprecation warning (if I add the '/', I mean.)  It says,
"DEPRECATED: Found a "/" in the name of the 'desktiop/gtk3' part"

Here's the major error I'm getting...

"Issue while loading plugin: properties failed to load for desktop-gtk3:
Additional properties are not allowed ('prime' was unexpected)"

I'm punting on this for now (i.e., giving up), but if anyone has any ideas,
please let me know.  Thanks.


Check that the indentation is correct and you didn't change spaces with 
tabs or so on.

I just copied your snapcraft.yaml and don't have any problem here.
$ snapcraft --version
2.28

Didier


On Thu, Mar 30, 2017 at 11:21 AM, José Pekkarinen <
jose.pekkari...@canonical.com> wrote:



Did you tried [desktop/gtk3]?



$ snapcraft search

...

desktop-gtk3   Helpers for gtk2, gtk3, qt4 and qt5 or
glib minimal launchers.
...

desktop/gtk3   Helpers for gtk2, gtk3, qt4 and qt5 or
glib minimal launchers.
...



Best regards.



José.



On Thursday 30 March 2017 11:09:00 Spencer Parkin wrote:


Take a look at the following .yaml file.
https://github.com/ubuntu/snapcraft-desktop-helpers/

blob/master/demos/gtk3/s


napcraft.yaml
Notice the following line in it...
after: [desktop-gtk3]
That's the line I need, and the line I've used most often in my git
history, but it doesn't work anymore. When I'm back on my linux box this
evening, I can give more information.
I wonder if something has changed with an update of snapcraft.
On Thu, Mar 30, 2017 at 11:05 AM, José Pekkarinen <
jose.pekkari...@canonical.com> wrote:

On Thursday 30 March 2017 11:01:02 Spencer Parkin wrote:

Yes, that's the complete file. See, here's the thing. My program has
been
correctly snapping with "desktop-gtk3" in there fore quite some time.

It's

only recently that it's stopped working. I've looked in my git

history


to
see if maybe I've broken something, but that's how it's always been.

Reading your file what I thing you might want to do is this:
...
parts:
twistypuzzle:
plugin: scons
source: https://github.com/spencerparkin/TwistyPuzzle.git
source-branch: stable-release
build-packages:
- 
after:
- desktop-gtk3
- fontsystem
- 3dmath
- permutationgroup
- rapidjson
...
Let me know if I'm wrong on this assumption.
Best regards.
José.






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

Re: Contributing cloud parts

[Didier Roche]

Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit :

Hey,


Hey Tim,


what is the process of contributing a cloud part to 
https://wiki.ubuntu.com/snapcraft/parts (is it open for community 
contributions?)?


Are there any plans for having a real parts repository instead of a 
wiki page for cloud parts? I think something like parts.snapcraft.io 
would be pretty cool :)




There isn't any process as of now AFAIK. It is open for community 
contributions, so feel free to edit the wiki page adding your awesome 
cloud part :)
snapcraft update && snapcraft search should list your part within the 
next hour (the importer runs hourly AFAIK).


I agree some way to see/check metrics on parts popularity, getting 
user's feedback and such would be pretty cool!

Cheers,
Didier

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

Re: Shared UI Themes

[Didier Roche]

Le 16/03/2017 à 18:28, Michał Sawicz a écrit :

W dniu 16.03.2017 o 17:34, Sebastien Bacher pisze:

One other issue is that snaps are per-system and theme are
per-user-session/desktop. You could have different users login into
different desktop environment on your laptop, how do we handle them
needing different themes?

Sounds like we'd need the ability to connect to multiple theme snaps and
then have the user's environment choose the right one?

Is it even possible to plug into multiple slots?


AFAIK it's not possible and my last email on the topic (which wasn't the 
first one) didn't get traction: "One snap to connect them all (or: the 
plugin story)".
You can as well have a look at 
https://bugs.launchpad.net/snapd/+bug/1655125 to subscribe and follow 
the status.


Cheers,
Didier

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

Re: Class confinement for Python snaps

[Didier Roche]

Le 10/03/2017 à 16:14, Barry Warsaw a écrit :

I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm
running into some problems.  ubuntu-image is a Python 3 application, and I'm
using snapcraft 2.27.1+17.4 on Zesty.

The first problem I'm having is I think directly related to LP: #1670749.


Hey Barry,
Note as well that I opened 
https://bugs.launchpad.net/snapcraft/+bug/1670388 against the snapcraft 
project a couple of days ago.

I think snapcraft should at least fail the build to warn you about this.

Cheers,
Didier


   I
ended up reopening this because while Corey found that he ultimately only
needed to set the $PATH environment variable, I still also had to $PYTHONPATH
and I had to make sure the snap versions come before the system versions:

environment:
   PATH: $SNAP/bin/:$PATH
   PYTHONPATH: $SNAP/lib/python3.5/site-packages:$PYTHONPATH

This gets me pretty close, but then I run into my second problem which is that
we depend on pyparted, in Ubuntu as python3-pyparted.  This package contains
both Python source and an extension module and to further complicate things,
its tarball is only released on GitHub, not on PyPI, so adding it to
python-packages in the ubuntu-image part doesn't work.  Further, it doesn't
help to add python3-parted to stage-packages because it appears that with
classic confinement, none of those Python packages end up in the snap.

I tried to add a scriptlet to copy things over, but that also fails.  E.g.:

parts:
   ubuntu-image:
 plugin: python
 source: https://github.com/CanonicalLtd/ubuntu-image.git
 source-type: git
 python-packages:
   - PyYAML
   - attrs
   - voluptuous
 prime:
   - bin/ubuntu-image
   - usr
   - lib
   - sbin
 stage-packages:
   - e2fsprogs
   - mtools
   - python3-debian
   - python3-parted
   - util-linux
 install: |
   cp -a ../install/usr/lib/python3/dist-packages/parted 
../stage/lib/python3.5/site-packages
   cp -a ../install/usr/lib/python3/dist-packages/pyparted-*.egg-info 
../stage/lib/python3.5/site-packages

$ snapcraft
...
/home/barry/projects/ubuntu/allsnappy/ubuntu-image/parts/ubuntu-image/build
cp: cannot create directory '../stage/lib/python3.5/site-packages': No such 
file or directory
cp: cannot create regular file '../stage/lib/python3.5/site-packages': No such 
file or directory
Command '['/bin/sh', '/tmp/tmpfeczxcco', '/tmp/tmp2__1bdau']' returned non-zero 
exit status 1

This happens because ./stage/ is empty at the point that the install scriptlet
is run.

I can think of a couple of approaches that might be useful.

* Allow python-packages specifications to pip install from repositories other
   than PyPI.

* Allow python-packages to come from git and/or https URLs (I tried this and
   it didn't work).

* Integrate dirtbike and wheels into the Python parts building phases.
   (dirtbike is a tool that Debian/Ubuntu uses in very limited cases to turn
   installed distro packages into .whl files.)

* Provide a scriptlet hook that runs after the normal part installation step.

My current WIP snapcraft.yaml file is here:

https://github.com/CanonicalLtd/ubuntu-image/blob/lp1638645/snapcraft.yaml

I'm going to keep trying a few things, but any suggestions are welcome.  I'm
happy to file bugs as needed.

Cheers,
-Barry




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

A couple of new snap tutorials are now available!

[Didier Roche]

Following last few weeks announcement, we do have a couple of new 
tutorials available for snaps!


More info are available at 
https://insights.ubuntu.com/2017/03/02/a-couple-of-new-snap-tutorials-are-now-available/, 
but I want to give a big round of applause to Simos, present on this 
list, making excellent community contributions (and planning on more!)


If you want to get involved, do not hesitate to reach out to me, either 
on the list, or directly to me :)


See you at your next tutorial!
Didier


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

Re: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04

[Didier Roche]

Le 15/02/2017 à 16:33, Simos Xenitellis a écrit :
> On Mon, Feb 13, 2017 at 7:13 PM, Didier Roche <didro...@ubuntu.com> wrote:
>> Le 10/02/2017 à 17:30, Simos Xenitellis a écrit :
>>> I managed to complete the conversion and the tutorial is ready :-).
>>>
>>> Here it is,
>>> https://docs.google.com/document/d/1Nk-kw79lt84YJNEKS_WpnGzVSjrmCUVd1TsAx5aRoOA/
>>> Feel free to add to tutorials.ubuntu.com or make a copy in order to edit.
>>>
>>> Overall, the experience in converting to the format required by
>>> codelabs was interesting.
>>> I still need more practice before I would be able to write a tutorial
>>> in one go in the codelab style.
>> This really looks awesome! Thanks Simos :)
>>
>> I'll add some very small tweaking, but after a first look, it's very a
>> nice first shot. Well done :)
>
>> I'll keep you posted with a diff so that you can see what small
>> modifications I made to be more coherent with the other ones.
>>
> Thanks, looking forward to reading the changes.

And here we go:
https://docs.google.com/document/d/1cvXAZRkmKExNIOXMUQihQrd8dNZK6f8v4wk020NymuI/edit#.
I did find your tutorial to be so good, that I changed its destination
to be the default "use python plugin" one. Due to that, I removed the
"explain what snap/snapcraft is and publish to the store" parts, as they
are already covered in other base tutorials (and we want to create a
coherent story). I added of course the pre-requisite on them and
formatted some stuff to be inline with our current one.

Note, this is a draft, I didn't take the time to reread it yet (so
probably, a lot of typos and such, but I prefer to reread it on Monday
with a clear brain and fresh eye on this). I tried to explain the major
difference I've made (and what did divert originaly from the tutorials
guidelines) as comments on the doc.
Do not hesitate to ask (the document is opened for comments) if anything
isn't clear or if you have ideas to improve it. I hope most of my
changes and my comments will make sense.

If you feel those changes are good, we can publish it next week, and
wait eagerly for your next tutorial! (Maybe we can work together on
deciding first the layout, main titles and separations if you want)

Thanks again for your awesome work here!
Cheers,
Didier

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

One snap to connect them all (or: the plugin story)

[Didier Roche]

Ok, sorry for the catchy email title but couldn't resist :)

So, I'm in the situation where one snap would need to get configuration
and access to some files from other snaps. It's really similar to our
plugin story: even if in that case, we are talking about optional
configuration and files from one or multiple snaps shared with a single
one collecting them all.

I can see 2 options in the snapd philosophy:

- Content sharing. Sounds like it matches exactly the purpose of it.
However, even disregarding the manual connection that will be needed, we
are stuck on the fact that it's limited to one connection for a given
slot. If I want to share configuration and files from 3 snaps to the
master one, I can't do 3 times:
$ snap connect snap1:config my-master-snap:config
$ snap connect snap2:config my-master-snap:config
$ snap connect snap2:config my-master-snap:config

One way would be to create different slot names:
$ snap connect snap1:config my-master-snap:config1
$ snap connect snap2:config my-master-snap:config2
$ snap connect snap2:config my-master-snap:config3

But this doesn't help on the ease of use (the notice is then for people
"find the first available slot"… Not really user-friendly) nor in the
scalibity (fixed number of slots…)

- A dedicated interface which will handle multiple TCP connections and
DTRT. However, a dedicated interface suffers from the same issue than
previously and need to be hardcoded in snapd itself as AFAIK, there is
no way still as of today to have custom interfaces developped outside of
the snapd code itself.


Other ideas or plans for this?
Cheers,
didier



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

Re: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04

[Didier Roche]

Le 07/02/2017 à 14:05, Simos Xenitellis a écrit :
> On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche <didro...@ubuntu.com> wrote:
>> Le 06/02/2017 à 10:56, Simos Xenitellis a écrit :
>>> Hi All,
>>>
>>> I wrote an article about creating a snap for an existing Python
>>> program using the new snapcraft 2.26. Then, I uploaded to the Ubuntu
>>> Store.
>>>
>>> I am looking forward to receiving feedback :-)
>>>
>>> Link: 
>>> https://blog.simos.info/how-to-create-a-snap-for-a-python-app-with-networking-using-snapcraft-in-ubuntu-16-04/
>>>
>>> Link to HN submission: https://news.ycombinator.com/item?id=13578034
>>>
>>> Simos
>>>
>> Excellent work Simos!
>>
>> I think this kind of content would make an excellent official "pratical"
>> tutorials on https://tutorials.ubuntu.com. Are you interested into
>> contributing there?
>>
>> If you want more context on tutorials, the phisolophy and how to
>> contribute, I wrote a blog post some time ago about it:
>> https://insights.ubuntu.com/2017/01/20/tutorials-ubuntu-com-goes-live/.
>>
>> I'm also available for any help,
> Thanks Didier!
>
> I had a look at https://github.com/ubuntudesign/tutorials.ubuntu.com/issues
> and the direction that tutorials.ubuntu.com wants to take. It looks good.
> It requires planning in terms of the writing of the tutorials so that
> they are gradually incremental,
> and some basic tutorials can referenced by the more complex ones. It's
> a lot of dedicated work.
>
> I'll give it a go and try to write a couple of tutorials for
> tutorials.ubuntu.com. We will see how it goes :-)
> I think I'll start with the baseline tutorial for snapcraft.

Excellent news!
You can as well convert some of yours to this format! I give you the
direct link to the guidelines to have some coherences between the
tutorials in term of tones and content:
https://docs.google.com/document/d/1u5qmSNIcE8SjuAg6aKjTxOBGWIjBW0kYf01t4Dfw6-U/edit.

Keep in touch!
Cheers,
Didier

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

[Didier Roche]

Le 01/02/2017 à 13:05, Gustavo Niemeyer a écrit :
>
> Yes, that's in the plans for configuration support already.  The idea
> is to extend snapctl with the ability to introspect exactly which
> settings have changed since the last successful run of the script, and
> perhaps which values it used to hold before.
>
> For the time being, I suggest not worrying much about that. Just go
> ahead and implement the semantics you want the user of the snap to
> experience. Inside the configure hook, check to see if the requested
> value is already in place and do nothing in that case. This makes the
> script idempotent, resilient because it ensures the desired state is
> indeed in place, and also cheap to execute in the common case.
>  

If someone is interested, I have implemented this kind of idempotent
configure hook example. It can be found at
https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
as part of the christmas snap demo.
It features:
- support key=value formatting
- ignoring, but not erasing unknown keys, comment lines, empty ones.
- preserving formatting and ordering, even when changing an existing key.
- only snap set arguments will be modified if a value is set. If the
value assigned to it is empty, removing the key line
- new elements not present in existing configuration file are simply
appended.

Supporting new keys (like here "foo") is just a matter of adding:
update_opt_in_config foo

at the end of the file.

I hope this helps! (note that the issue is still "what's the supported
keys for this snap?")
Cheers,
Didier

>
>
> On Wed, Feb 1, 2017 at 8:31 AM, Oliver Grawert  > wrote:
>
> hi,
>
> after we recently added a config hook [1] to the core snap it is now
> possible to disable ssh if you require [2] ...
>
> there is a long standing request to do the same for syslog for systems
> running from SD card, which is why i looked into trying to extend the
> existing configure script for this, which made me notice some issue...
>
> when you call "snap set core foo=bar", there is no indication at all
> for the script which variable changes a value, neither in the shell
> environment nor in the argument list.
>
> the only way to get your value is to call snapctl for every existing
> variable [3]. since you dont know what specific variable was requested
> to change the only way to reliably write it is to write *all* existing
> variables ... 
>
> now, if you package something with a more complex config that you want
> completely handled via snap config this gets ugly very fast... imagine
> something like postfix with can potentially have 100s of config
> options. instead of atomically changing a single option you will
> regenerate the full config from scratch. this takes a lot longer,
> bringing the risk of a completely broken config in case of a power
> loss, beyond resulting an an awful config hook script with a large
> block of "snapctl get" calls at the top.
>
> can we extend the config hook implementation minimally so a "snap set
> core foo=bar" would at least have something like "SNAP_OPTION=foo" in
> the environment that the generating script or binary could read to
> avoid the unnecessary processing or would that break some design
> concept ?
>
> ciao
> oli
>
> [1] http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/
> hooks/configure
> 
> 
> [2] https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/ref
> erence/core-configuration.md
> 
> 
> [3] https://github.com/snapcore/snapd/wiki/hooks
> 
> --
> 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/listinfo/snapcraft

Changing default snapcraft behavior and erroring on missing libraries

[Didier Roche]

Le 31/01/2017 à 17:18, Sergio Schvezov a écrit :
> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote:
>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki 
>>  wrote:
 Do we have a clear understanding of why this happens? Qt apps are
 supposed to be binary compatible against newer releases.
 One exception could be if the app itself is shipping some plugins,
 because in that case I believe that these plugins are somehow bound to a
 specific Qt version.
>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on
>>> Qt version which should not be the case when the platform snap is
>>> used.
>> This is a bit tricky: when packaging a Qt application that uses the
>> platform snap, snapcraft will use ldd to crawl the app’s binaries and
>> will automagically add the libraries that it depends on to the
>> resulting snap (those libs are taken from the host system).
> This will be disabled by default and snapcraft will error on missing libraries
> unless you tell it is ok.
>
(first, sorry for the bad control+enter on my previous email)

I'm a little bit uncomfortable with that statement for mainly 2 reasons:
* Changing default behavior is always cumbersome to developers who just
wants to work on their app. Here, we are introducing a breaking change
(snaps that used to build won't build anymore, especially those on
core). It's annoying also for people who did hook up their CI to
autopublish a snap.

This is why we need to justify and carefully explain the change, in a
clear, defined way. I would suggest coordinating with David for a blog
post that we promote here and on the developer website:
  1. Why are we changing this? -> we are not doing this just to bother
you, developer, here is the technical reason why we are doing it.
  2. A small and minimal snippet of code of before/after so that people
aren't lost and know what to do
  3. When is it going to be released. Version, date, upgrade process.

As this default behavior changes a lot of things, we need to ensure as
well that all our code snippet and tutorials are updated. So
coordinating all the way, please!

* The second one is that it seems there is a disable mechanism, mainly
telling "I know what I'm doing". I think this isn't what we want to
achieve and it's not fine-grained enough.

A common use-case I can see is an app depending on a platform snap and
embedding additional libraries for some functionality. If we have to
disable the check for not erroring out on the platform snap libs, we may
miss, on snap creation, or upgrade or more… additional library checks.
It seems we shouldn't use a big hammer like this (if it's really what
I'm understanding from this statement), but rather trying to get a way
more fine-grained and precise approach.

Thoughts?
Didier



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

Re: ubuntu-app-platform updated to Qt 5.6.2

[Didier Roche]

Le 31/01/2017 à 17:18, Sergio Schvezov a écrit :
> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote:
>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki 
>>  wrote:
 Do we have a clear understanding of why this happens? Qt apps are
 supposed to be binary compatible against newer releases.
 One exception could be if the app itself is shipping some plugins,
 because in that case I believe that these plugins are somehow bound to a
 specific Qt version.
>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on
>>> Qt version which should not be the case when the platform snap is
>>> used.
>> This is a bit tricky: when packaging a Qt application that uses the
>> platform snap, snapcraft will use ldd to crawl the app’s binaries and
>> will automagically add the libraries that it depends on to the
>> resulting snap (those libs are taken from the host system).
> This will be disabled by default and snapcraft will error on missing libraries
> unless you tell it is ok.
>
I'm a little bit uncomfortable with this statement for 2 reasons:


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

Re: glGetUniformLocation fails in confinement mode

[Didier Roche]

Le 30/01/2017 à 15:39, Jamie Strandboge a écrit :
> On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote:
>> On 2017-01-30 01:56 AM, Spencer Parkin wrote:
>>>
>>>
>>> I have a program that has successfully snapped and run in confinement mode,
>>> but then I added a pixel and vertex shader
>>> which works when run on my classic system, but not in strict confinement as
>>> a snap.  I've tried to narrow down the
>>> earliest fail point, and I believe it is at the point where I'm calling
>>> glGetUniformFromLocation.  This is returning -1
>>> in confinement mode.  I'm able to read, compile and link my shader program,
>>> and bind it, but the first call to
>>> glGetUniformFromLocation fails.  Is OpenGL being denied read-access to a
>>> portion of protected memory?  If so, it
>>> certainly would fail to write there as well with a call to glUniform3f, for
>>> example.
>>>
>>> I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu
>>> core's, then running the scanlog, but the
>>> only app-armer denial I get is, I believe, unrelated to the problem.  In any
>>> case, I will give it here...
>>>
>>> Log: apparmer="DENIED" operation="open"
>>> profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/"
>>> pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000
>>> ouid=0
>>> File: /usr/share/glib-2.0/schemas/ (read)
>> That error message is because the launcher program "desktop-launch" can not
>> find the gsettings.  I don't know what
>> impact that will have (if any) but it's not going to affect how OpenGL works
>> internally.
>>
> AIUI, the desktop part is doing this as part of its bootstrap to generate what
> it needs in ~/snap/SNAP_NAME/SNAP_REVISION and it will only do this the first
> time a new revision of the snap is launched. This denial is harmless and 
> should
> only happen on classic (since /usr/share/glib-2.0/schemas doesn't exist on
> Ubuntu Core).
> 
> While harmless, it is also confusing. I'm not super familiar with the desktop
> part and wonder how we can improve this. Didier or Seb, would the 
> bootstrapping
> process work ok if we allowed read on the /usr/share/glib-2.0/schemas/ 
> directory
> in the unity7 (and maybe the x11) transitional classic interfaces?
> 

The issue is indeed that there is classic confinement vs core only. I
thought that it makes sense to read all traditional glib schema paths,
test that they exists, and if they exist, compile the gsetting schemas
alongside the snap specific ones.

/usr/share/glib-2.0/schemas/, as Jamie told, don't exist on core, so we
just skip it and don't have that denial. On classic however, it does.

I'm surprised thought hat there is even a denial: I thought classic gave
you access to your whole host system and this kind of things won't
happen, do you mind giving some precisions Jamie to fix my twisted
perception?

For the paths we are checking, we are basing ourself on $XDG_DATA_DIRS,
appending glib-2.0/schemas to each of them.
On 16.04 LTS, this is:
$ echo $XDG_DATA_DIRS
/usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop

As you can see, quite some paths are involved (even if in practice, only
/usr/share/glib-2.0/schemas/ would exist in general).
Hope that helps clarifying out!
Cheers,
Didier

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

Re: New 2.20 snapd release

[Didier Roche]

Le 03/01/2017 à 13:18, James Page a écrit :
> On Tue, 3 Jan 2017 at 12:15 James Page  > wrote:
>
> On Tue, 3 Jan 2017 at 11:58 Gustavo Niemeyer
>  > wrote:
>
> Will systemd handle multiple services with the same name
> without complaining? How would it disambiguate?
>
> We can pull off snap aliases because the binary paths are
> separate (not /usr/bin), and thus won't actually conflict even
> if system packages and snaps define the same name.
>
>
> I could see how this might be a problem; an Alias can either be
> defined in the systemd unit file (in which case systemd will
> create an appropriate symlink), or by creating the symlink from
> alias->actual in /etc/systemd/system - I'll poke at things and see
> how that might break!
>
>
> It would appear that any symlink created in /etc/systemd/system masks
> anything provided by a deb package in /lib/systemd/system - so the
> glance-api alias from a snap would override the glance-api systemd
> unit file provided by a deb package installed on the same system
>
> I guess this also fits into the general question of how to transition
> an existing system from deb->snap in a elegant way as well :-) 
>

Indeed, systemd has aliases for years, and we should use similarly the
Alias keyword in the unit file for those cases.
This just create a symlink at the right place and ensure only one unit
with this symlink can be enabled at a time.

This is how things like display manager, where some alternatives but a
fixed service name might be needed (for dependencies) are handled, fyi.
Cheers,
Didier


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

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

[Didier Roche]

Le 05/01/2017 à 14:31, Oliver Grawert a écrit :
> hi,
> Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert:
>> ogra@pi3:~$ grep audio= /boot/uboot/config.txt 
>> dtparam=audio=on
>>
> FYI both gadgets for pi2 and pi3 have just been updated in the edge
> channel with this fix, would be good if they could be tested with the
> pulse snap now :)

I guess you can now close https://bugs.launchpad.net/snappy/+bug/1645605
as well thus. (when I send a feedback email a couple of months ago
stating exactly the same issue ;)).
Thanks for fixing it now.

Cheers,
Didier


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

Re: Snapcraft's state tracking improvements

[Didier Roche]

Le 13/12/2016 à 22:57, Kyle Fazzari a écrit :
> Hey everyone.

Hey Kyle
>
> I feel it coming on... this is going to be a tome. tl;dr... snapcraft
> could be smarter than it is. But would that lead to its doing more for
> you than you want? We'd like to find out.
>
> I've spoken to a few of you individually about this, and I want to open
> this topic up for wider conversation. We have a number of bugs logged
> against snapcraft for its state tracking shortcomings. For example, a
> few of you may have run into these issues:
>
> - You add a stage package to a part in an already-built snap, and run
> `snapcraft` again. It happily says all the steps have already run, and
> generates a snap that doesn't contain your stage package.
>
> - You add (or modify) a file in the local source for a part of an
> already-built snap, and run `snapcraft` again`. It again reports that
> everything has already run, and generates a snap that doesn't contain
> your modifications.

There is another one: there is a remote source which changes. I think
snapcraft can be smarter about that and store the hash of the git/bzr
commit id, and check if new remote hash is the same or not. This is a
little bit more problematic for other kind of assets like tarballs, as
you can only create and check a checksum (if not published) after
downloading… defeating the caching purpose :)

> The point is: snapcraft is/will be smart enough to help a lot more than
> it currently does in these types of situations. The question I'm posing
> to you all is: how much do you want its help?
>
> I see four options for how to handle such situations:
>
>
> *Option 1*: Error out and make you be specific. This is the current
> behavior.
>
> *Option 2*: Automatically take care of everything. If you modify a part
> with dependencies, snapcraft will rebuild those dependencies as it sees
> fit without your needing to say so. Similarly, if you clean a part with
> dependencies, snapcraft will clean those dependencies as it sees fit
> without your needing to say so.
>
> *Option 3*: Prompt. "You've modified part A, but part B depends upon it.
> Would you like to rebuild it as well? (Y/n)" and the like.
>
> *Option 4*: Add the ability to configure this behavior between options
> 1-3. Perhaps the sensible default would be option 3.
>
>
> Our goal here is to do the least surprising thing, which is why we're
> asking for input from our users. Please let your voice be heard!

I would think a good way is always to not try to be too smart. This is
kicking back in some way in the future. I would personally go with
option 1 + a suggestion of command to run to autofix it. Instead of
prompting (option3), add an option like --auto (or --force).

This gives a sane default behavior, and let then integration tools (like
IDE integration or scripts) to use the --auto after detecting a failure.
Then, they can decide themselves to do it right away or to prompt the
user (which is harder if you implement option 3 as a CLI prompt).

Option 4 sounds dangerous to me, because there are mutiple situations
which can triggers this, and so, if you set auto as a default for
everything, you can go trigger surprising behavior for certain cases.
Here is my 2 cents




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

Re: Daemon: dbus examples

[Didier Roche]

Le 10/12/2016 à 14:29, l-snapcr...@znn.info a écrit :
> Hi Snapcrafter,

Hey lightonflux,

> in the documentation about keys in the yaml i saw a mention of "daemon:
> dbus" (1), but i could not find an explanation in the documentation of a
> real world example how it is used on github.
>
> Can someone point me to an example snapcraft.yaml where i can see how it
> is used?
> Or other documentation that gets more into detail.

We do suport similar keywords than systemd units. in that case, service
files which are created by snapd. (man systemd.service for more
information). The dbus type specifies there:
   Behavior of dbus is similar to simple; however, it is
expected that
   the daemon acquires a name on the D-Bus bus, as configured by
   BusName=. systemd will proceed with starting follow-up units
after
   the D-Bus bus name has been acquired. Service units with this
   option configured implicitly gain dependencies on the dbus.socket
   unit. This type is the default if BusName= is specified.

And this is where i'm surprised, we don't support AFAIK additional names
like BusName or such in snap.yaml, and so, the dbus keyword without
BusName doesn't make any sense. Michael, can you shed some lights here?
Cheers,
Didier

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

Re: Daemon: dbus examples

[Didier Roche]

Le 10/12/2016 à 14:29, l-snapcr...@znn.info a écrit :
> Hi Snapcrafter,

Hey lightonflux
>
> in the documentation about keys in the yaml i saw a mention of "daemon:
> dbus" (1), but i could not find an explanation in the documentation of a
> real world example how it is used on github.
>
> Can someone point me to an example snapcraft.yaml where i can see how it
> is used?
> Or other documentation that gets more into detail.

We do suport similar keywords than systemd units. in that case, service
files which are created by snapd. (man systemd.service for more
information). The dbus type specifies there:
  Behavior of dbus is similar to simple; however, it is expected that
  the daemon acquires a name on the D-Bus bus, as configured by
  BusName=. systemd will proceed with starting follow-up units after
  the D-Bus bus name has been acquired. Service units with this
  option configured implicitly gain dependencies on the dbus.socket
  unit. This type is the default if BusName= is specified.

And this is where i'm surprised, we don't support AFAIK additional names
like BusName or such in snap.yaml, and so, the dbus keyword without
BusName doesn't make any sense. Michael, can you shed some lights here?
Cheers,
Didier


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

Re: Ubuntu 16.04, which version of snapcraft

[Didier Roche]

Le 07/12/2016 à 21:53, Jenny Murphy a écrit :
> Hi,
>  So now I am ready to go with snapcraft 2.22.1.
>
> I think upgrading my snapcraft.yaml should be pretty straight forward?
>
> This is what I have :
>
> *services:*
> *  main:*
> *start: bin/wrapper*
> *description: EpiSensor Gateway Application*
> *
> *
> *parts:*
> *move-scripts:*
> *plugin: copy*
> *files:*
> *scripts: scripts*
> *main:*
> *plugin: ant*
> *source: .*
> *wrapper:*
> *plugin: make*
> *source: .*
>
>
> So I think my parts section will be ok. But I need to re-do the
> services section to :
>
> |apps: daemon1: command: bin/wrapper daemon: simple|
>
> Any other suggestions ?

Hey,

Sounds about right!
Note that the copy plugin is deprecated and could be replaced with the
dump plugin (using organize/stage/snap keyword for the equivalent
"files" functionality).

The rest should stay the same, you will have some warnings about missing
"grade" keyword probably. I suggest just running snapcraft init in
another directory so that you can spot the differences for the base
semantic ;)
Cheers,
Didier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: sha3-384 mismatch

[Didier Roche]

Le 05/12/2016 à 16:05, Gustavo Niemeyer a écrit :
> Xavier posted the exact URL of the failing snap in this thread:
Note it's not *the* failing snap but *a* failing snap. Every "snap
install" here is failing on my setup when they are more than a couple of
MB. This is why I posted as such in the instructions on the bug.

So, with curl -v -L, with the same snap than on the bug report, here are
the results: http://paste.ubuntu.com/23583801/
I did 10 successful downloads in a row. This snap is 23MB.

I did retry with the new revision (49), 32MB.
Tried 10 times with curl, 10 successful and complete downloads (one is
http://paste.ubuntu.com/23583847/), with expected size and checksum.
Tried 10 times with snapd, got hashsum mismatch 10 times. Download stops
after few KBs up to few MBs.

Cheers,
Didier

>
> "[1]
> - 
> https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap
> <https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap>
>  (extracted
> from the log file)"
>
> Bret also posted another one above (thanks!).
>
>
> On Mon, Dec 5, 2016 at 12:52 PM, Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit :
>>
>>
>> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche
>> <didro...@ubuntu.com <mailto:didro...@ubuntu.com>> wrote:
>>
>> I did though write on the bug: "contrary to curl or wget
>> which both supports large downloads."
>> The feedback thread mentioned as well "while same assets can
>> be successfully downloaded via curl or wget". 
>>
>> I thought that was really obvious that they worked
>> consistently and that I did rerun then multiple times or I
>> wouldn't have opened the bug report + write this feedback.
>> Sorry if that wasn't clear enough, let's move on :)
>>
>>
>> If you file a bug and a developer asks for specific information
>> that wasn't provided, it means the specific information is not
>> obvious.
>>
>>> Is it the case?  Did you ever get a failure with them?  Are
>>> they retrying while they work? Do you have a verbose dumb of
>>> the process?
>> Yes, as mentioned. I never got any failure with any of them
>> and I did retry multiple times in loop when I saw the snapd
>> failures.
>> wget is in verbose mode by default and I never got any hint
>> that it was retrying (just getting the normal download output).
>>
>> I did just try a verbose download in curl (here, an ubuntu
>> 300M image). Here is the output:
>> http://paste.ubuntu.com/23583568/
>> <http://paste.ubuntu.com/23583568/>. It seems that curl
>> doesn't complain of any reconnect.
>>
>>
>> You are downloading an image from an arbitrary server on the
>> internet unrelated to the problem we're trying to debug.
>>
>> Can you please attempt these several curl downloads while using
>> the exact same URL that failed for snapd?
>
> As a developer asking for more debug information, can you please
> paste the exact instructions on how to get those?
>
> I'm trying the https://public.apps.ubuntu.com/anon/download-snap/
> <https://public.apps.ubuntu.com/anon/download-snap/> based url
> with the .snap showing up in the logs to get the exact same assets
> I pasted snapd information on. However, curl -v returns (output
> stripped out):
> *   Trying 162.213.33.92...
> * Connected to public.apps.ubuntu.com
> <http://public.apps.ubuntu.com> (162.213.33.92) port 443 (#0)
> * found 173 certificates in /etc/ssl/certs/ca-certificates.crt
> * found 692 certificates in /etc/ssl/certs
> * ALPN, offering http/1.1
> * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
> *  server certificate verification OK
> *  server certificate status verification SKIPPED
> *  common name: public.apps.ubuntu.com
> <http://public.apps.ubuntu.com> (matched)
> *  server certificate expiration date OK
> *  server certificate activation date OK
> *  certificate public key: RSA
> *  certificate version: #3
> *  subject: C=GB,L=London,O=Canonical Group
> Ltd,CN=public.apps.ubuntu.com <http://public.apps.ubuntu.com>
> *  start date: Mon, 30 May 2016 00:00:00 GMT
> *  expire date: Wed, 21 Jun 2017 12:00:00 GMT

Re: snapd debug without systemd activation

[Didier Roche]

Le 05/12/2016 à 09:58, Boris Rybalkin a écrit :
> Hello,
>
> Is it possible to run snapd for debugging without systemd socket
> activation ?
>
> There is a check here:
> https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L198
>
> Which seems to expect socket from systemd.
>
> I was able to run and debug without systemd by adding explicit socket
> creation lines if activation did not return a valid listener.
>
> Should there be some 'else if "STANDALONE_MODE" == 1 then create
> sockets' ?
>
> I am using Idea go plugin and ideally hitting shift + f9 should just work.
Hey,

I'm unsure if there is any way in snapd to handle this directly.

However, you can use systemd functionality to disable the socket listening:
sudo systemctl disable snapd.socket

Cheers,
Didier

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

Re: sha3-384 mismatch

[Didier Roche]

Le 05/12/2016 à 09:13, Madper Xie a écrit :
> I would say the cdn that we are using correctly is not friendly to me.
> (China telecom 200M fiber.)
> Downloading slowly(20KB/s) and unstable.
>
> Hi @Didier, I noticed that you mentioned
> https://bugs.launchpad.net/bugs/1643893
> <https://bugs.launchpad.net/bugs/1643893> twice in this thread.
> However I'm not able to access it... Is the project private?

It was public at the time I published it. However, then, I had to add
private information as part of debug output (macaroons, which is private
snapd credentials) in a launchpad comment. We thus had to turn it
privately as we can't remove them (in a comment), sorry for this.
Upstream has access to it.

Here is a copy and paste of title/description: "snapd doesn't handle
well flaky network"
"

Some network can be stalled or have few disconnects. snapd doesn't
support them and dropped the connexion on cryptic message contrary to
curl or wget which both supports large downloads.

$ sudo snap install face-detection-demo --beta --devmode
-> download starts with 0, 1, 2% and suddenly jump to 100% printing:
error: cannot perform the following tasks:
- Download snap "face-detection-demo" (49) from channel "beta" (sha3-384
mismatch downloading face-detection-demo: got
4c1ddd585f69dd6e1dc19c3eb6aa2f7ecbbd5671ce9f816cbdfd0647986a59fdd9313fde013d98a00d501f8ca4b0979e
but expected
40927e42f8339fcae0ed7edfd3215ffb0abc1dadbfedce446ad4b39c06cb9ad94f30bdd0c6514bdb6477e86727b75767)

wget works on the same machine.

Easy reproducer:
- install ubuntu core on a rpi2, plug the the eth45 cable to your laptop
- switch network-manager to network sharing mode
- try installing any snap (more than a meg) from the rpi2."


Didier
> BR,
> Madper
>
> On Mon, Dec 5, 2016 at 3:23 PM, Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 03/12/2016 à 16:01, Gustavo Niemeyer a écrit :
>> Hi Xavier,
>>
>> There's definitely a problem interrupting the connection with the
>> server. The fact it works sometimes means it's inconsistent.
>>
>> Can you please try to download such files several times out of
>> snap and snapd, to see what the error is?
>>
>> Per my note above, we had a bug in snapd which prevents the real
>> error from being shown. We're always showing the digest mismatch
>> instead, which will of course happen if the download is
>> interrupted before its end.
>>
>>
> As written on the bug report + some part feedback emails you
> received some weeks earlier, it seems you ignored one part of the
> issue. Yes, it seems the network is failing. However, snapd
> consistenly fails in my case for downloading, while other tools,
> like wget and curl can download bigger files, many times, without
> ever getting one failure. They are more robust in difficult
> network situations it seems.
>
> So either the store connection side is fragile or snapd isn't
> robust enough while other tools cope with those conditions just
> fine (without any warning/debug message telling that they are
> retrying).
> Cheers,
> Didier
>
>> On Sat, Dec 3, 2016 at 12:49 PM, Xavier Pegenaute
>> <xpegena...@gmail.com <mailto:xpegena...@gmail.com>> wrote:
>>
>> Hi all,
>>
>> I don't know exactly where to find all the data you are
>> asking for, but this is what I found (below). Related to the
>> network, as a test, I just downloaded the linux kernel
>> .tar.xz (98MB) using python requests and worked properly. I
>> am not using any proxy at all.
>>
>> The "snap install" worked with hello-world but failed with
>> webdm, docker and nmap. I didn't try anymore.
>>
>> Let me know if you want any further test.
>> Regards
>> Xavi
>>
>>
>> -
>> root@localhost:/var/lib/snapd/snaps# ls -al webdm_24.snap
>> -rw-r--r-- 1 root root 3280896 Dec  3 14:12 webdm_24.snap
>> -
>>
>> -
>> root@localhost:/var/lib/snapd/snaps# sha384sum webdm_24.snap
>> 
>> 4ee3329efb0fc71a3217ec0fc7d92ba8f1d71db22036ddef8c4abefae6ca0dbe3e1847fde14bd420fc061c8d9b0795e8
>>  
>> webdm_24.snap
>> -
>>
>> Part of /var/lib/snapd/state.json:
>> 

Re: sha3-384 mismatch

[Didier Roche]

Le 03/12/2016 à 16:01, Gustavo Niemeyer a écrit :
> Hi Xavier,
>
> There's definitely a problem interrupting the connection with the
> server. The fact it works sometimes means it's inconsistent.
>
> Can you please try to download such files several times out of snap
> and snapd, to see what the error is?
>
> Per my note above, we had a bug in snapd which prevents the real error
> from being shown. We're always showing the digest mismatch instead,
> which will of course happen if the download is interrupted before its end.
>
>
As written on the bug report + some part feedback emails you received
some weeks earlier, it seems you ignored one part of the issue. Yes, it
seems the network is failing. However, snapd consistenly fails in my
case for downloading, while other tools, like wget and curl can download
bigger files, many times, without ever getting one failure. They are
more robust in difficult network situations it seems.

So either the store connection side is fragile or snapd isn't robust
enough while other tools cope with those conditions just fine (without
any warning/debug message telling that they are retrying).
Cheers,
Didier

> On Sat, Dec 3, 2016 at 12:49 PM, Xavier Pegenaute
> > wrote:
>
> Hi all,
>
> I don't know exactly where to find all the data you are asking
> for, but this is what I found (below). Related to the network, as
> a test, I just downloaded the linux kernel .tar.xz (98MB) using
> python requests and worked properly. I am not using any proxy at all.
>
> The "snap install" worked with hello-world but failed with webdm,
> docker and nmap. I didn't try anymore.
>
> Let me know if you want any further test.
> Regards
> Xavi
>
>
> -
> root@localhost:/var/lib/snapd/snaps# ls -al webdm_24.snap
> -rw-r--r-- 1 root root 3280896 Dec  3 14:12 webdm_24.snap
> -
>
> -
> root@localhost:/var/lib/snapd/snaps# sha384sum webdm_24.snap
> 
> 4ee3329efb0fc71a3217ec0fc7d92ba8f1d71db22036ddef8c4abefae6ca0dbe3e1847fde14bd420fc061c8d9b0795e8
>  
> webdm_24.snap
> -
>
> Part of /var/lib/snapd/state.json:
> -
>   "tasks": {
> "113": {
>   "id": "113",
>   "kind": "download-snap",
>   "summary": "Download snap \"webdm\" (24) from channel
> \"stable\"",
>   "status": 9,
>   "clean": true,
>   "progress": {
> "label": "webdm",
> "done": 3280896,
> "total": 3280896
>   },
>   "data": {
> "snap-setup": {
>   "channel": "stable",
>   "download-info": {
> "anon-download-url":
> 
> "https://public.apps.ubuntu.com/anon/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap
> 
> ",
> "download-url":
> 
> "https://public.apps.ubuntu.com/download-snap/rFpKbTdZ31LyAxWF6RpcerZov1TdtDly_24.snap
> 
> ",
> "size": 3280896,
> "sha3-384":
> 
> "d03ac82e6b4b559cc918ef581eacb933e66ad36b18f6bcb1b0ac4d91260ee14a815526d2bcecc474b215639ce2a3fcef"
>   },
>   "side-info": {
> "name": "webdm",
> "snap-id": "rFpKbTdZ31LyAxWF6RpcerZov1TdtDly",
> "revision": "24",
> "channel": "stable",
> "developer-id": "canonical",
> "developer": "canonical",
> "summary": "# Snappyd",
> "description": "This service allows you to manage your
> core device from a web interface."
>   }
> }
>   },
>   "halt-tasks": [
> "114",
> "120"
>   ],
>   "log": [
> "2016-12-03T14:08:45Z ERROR sha3-384 mismatch downloading
> webdm: got
> 
> d03ac82e6b4b559cc918ef581eacb933e66ad36b18f6bcb1b0ac4d91260ee14a815526d2bcecc474b215639ce2a3fcef
> but expected cea4eb570b28a3234
> 
> 410cc1abaf19a8a3b0f9d80fe71f6c422334a44267ffbca454eb85684722d3a517fe7666f5b8a85"
>   ],
>   "change": "22",
>   "spawn-time": "2016-12-03T14:08:41.26081942Z",
>   "ready-time": "2016-12-03T14:08:45.426213255Z"
> },
> -
>
>
>
> 2016-12-02 22:24 GMT+01:00 Gustavo Niemeyer
>  >:
>
> The problem here is just that we're checking the digest
> mismatch before we check the error reading from the network.
> Obviously, 

Re: configure hook

[Didier Roche]

Le 02/12/2016 à 02:53, Boris Rybalkin a écrit :
> Sorry still more questions on hooks.
>
> As I understand configure hooks are executed after services startup:
> https://github.com/snapcore/snapd/blob/3dc67f49c4b6fe3acd5add647ac35a42fbb395d5/overlord/snapstate/snapstate.go#L184
>
> If this is correct (and that is what I see) it completely breaks the
> idea of generating service configs (many tools want absolute paths in
> their configs) with configure hook as it has to be done before the start.
>
> This explains all my issues with keeping generated configs in
> SNAP_COMMON and every time I enable services and they fail I actually
> see configs from previous install :)
>
> Could anyone confirm this?

Hey Boris,

This is correct.

However, I think this forces some best practices on daemons. Remember
that configure hooks can as well be executed while your process is
running. Your process should be able to pick any configuration change
and adapt accordingly.
So, the idea is to choose sane default, not rely on a configure file
until the user chooses so, and diverge from their default (no config
file or no key in the config file means default).

That enables you to easily migrate defaults if you change them, as still
enable people to choose their own configuration without being impacted
by future default (note that ON (default) -> OFF -> ON switch, isn't a
default anymore, it's a user choice.

To illustrate that, I wrote a snap (codelab coming early next year)
where a nodejs app have a default port and title. However, you can via
"snap set" configure another port or title, and those changes are picked
immediatly by the daemon without restarting. Note that I tried to have a
generic configure hook, generating a key=value store, where setting ""
value revert to default and keeping comments, ordering and other
artefacts in your config
https://github.com/ubuntu/snow-on-me-snap/blob/master/meta/hooks/configure
for the config hook
https://github.com/ubuntu/snow-on-me-snap/blob/master/main.js#L71 for
the nodejs webserver picking up new config on the fly.

Hope that helps outlining why this behaviour shouldn't be a problem and
why organizing your code that way is an advantage in the end (hoping you
can act on the tools that requires this).
Didier


>
> On Fri, Nov 18, 2016 at 12:25 AM, Boris Rybalkin  > wrote:
>
> After reinstalling snapd (2.17.1) and cleaning /var/lib/snapd/
> issue seems to go away.
> Thank you very much!
>
> On Wed, Nov 16, 2016 at 7:20 PM, Boris Rybalkin
> > wrote:
>
> After upgrading snapd on desktop 16.04 from xenial-proposed
> now I have this wired message on install:
>
> Run configure hook of "syncloud-platform"
> error: cannot perform the following tasks:
> - Run configure hook of "syncloud-platform" snap if present
> (cannot snap-exec: cannot find hook "configure" in
> "syncloud-platform")
>
> snap --version
> snap2.17.1
> snapd   2.17.1
> series  16
> ubuntu  16.04
>
> Has this changed since 2.17?
>
>
> On 14 Nov 2016 22:44, "Sergio Schvezov"
>  > wrote:
>
> El 14/11/16 a las 18:35, Boris Rybalkin escribió:
>
> VM has snapd v2.17, is it possible to install this
> version on desktop 16.04/16.10 so I can have it for
> integration tests?
>
>
> It is in xenial-proposed
> https://launchpad.net/ubuntu/+source/snapd
> 
> If you want the latest and greatest at all times (non
> production). If you do this, follow the pinning process in
> https://wiki.ubuntu.com/Testing/EnableProposed
>  to pin
> snapd to xenial-proposed only and not risk getting more
> (potentially unstable) -proposed software.
>
> Also is there any documentation on how to install
> snapd on a linux?
>
>
> These are the installation instructions available for the
> variety of distros around:
> http://snapcraft.io/docs/core/install
> , in case you
> wonder where I got that link from, it is available as a
> link on the web front of http://snapcraft.io
>
> -- 
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io
> 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> 
>
>
>
>
> -- 
> 

Re: snap and qt

[Didier Roche]

Le 01/12/2016 à 06:20, Vasilisc a écrit :
> 30.11.2016 17:39, Didier Roche пишет:
>> Le 30/11/2016 à 09:29, Vasilisc a écrit :
>>> Hi folks,
>>> please help me.
>>> Qt app can't open folder and/or launch web browser
>>>
>>
>> Hey Vasilisc,
>>
>>> Error message
>>>
>>> virtual bool QGenericUnixServices::openDocument(const QUrl&): Unable
>>> to detect a launcher for 'file:///home/vasilisc/'
>>>
>>> virtual bool QGenericUnixServices::openUrl(const QUrl&): Unable to
>>> detect a web browser to launch 'http://www..'
>>>
>> The second error message is due to the fact tht xdg-open isn't findable
>> in your snap (Qt is using that helper to open an url). Remember the
>> previous discussions on using xdg-open to transmit browser opened
>> request on the desktop. Add /usr/loca/bin to your $PATH in your snap
>> path, ensure you have the desktop service installed and that should
>> work.
>>
>> Not opening random files on the system is by design, xdg-open filter
>> thoses. You can join the discussion at
>> https://github.com/snapcore/snapd-xdg-open/issues/18.
>>
>> Cheers,
>> Didier
>>
>>
> I found work solution.
>
> name: test2
> version: "2"
> summary: TEst
> description: |
> TEST
> confinement: strict
> architectures: [amd64]
>
> apps:
>   test2:
> command: xdg-open "http://google.com/;
> plugs: [network, network-bind, x11, home, unity7, gsettings]
>
> parts:
>   snapd-xdg-open:
> source: https://github.com/ubuntu-core/snapd-xdg-open.git
> plugin: copy
> files:
>   data/xdg-open: bin/xdg-open
>
>   integration:
>plugin: nil
>stage-packages:
> - bash
> #- xdg-utils
>
>
That works, or as said, you could just add in a wrapper /usr/local/bin
in your $PATH.

Cheers,
Didier


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

Re: Ubuntu Core for Beaglebone Black

[Didier Roche]

Le 08/11/2016 à 03:54, Luther Goh Lu Feng a écrit :
> Hi there,
>
> I am trying to install Ubuntu Core 16 on the Beaglebone Black. I have found 
> the images available for download[1]. I am aware of gadget snaps[2], and I am 
> guessing that beagleblack is the snap I should be looking at.
>
> But I am unsure how to proceed and cant find the documentation. My google 
> search only turned up results related to previous versions, which I wasn't 
> works for Ubuntu Core 16. Can someone please point me in the right direction 
> please? Really excited to give this release a spin.

The BeagleBone Black isn't an officially supported image, this is why
there is no official getting started instructions. I however think there
sholdn't be any big difference with the instructions on the same website
than a raspberry pi though
(https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/).

I'm CCing Oliver who creates this unofficial image.
Cheers,
Didier

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

Re: snap and qt

[Didier Roche]

Le 30/11/2016 à 09:29, Vasilisc a écrit :
> Hi folks,
> please help me.
> Qt app can't open folder and/or launch web browser
>

Hey Vasilisc,

> Error message
>
> virtual bool QGenericUnixServices::openDocument(const QUrl&): Unable
> to detect a launcher for 'file:///home/vasilisc/'
>
> virtual bool QGenericUnixServices::openUrl(const QUrl&): Unable to
> detect a web browser to launch 'http://www..'
>
The second error message is due to the fact tht xdg-open isn't findable
in your snap (Qt is using that helper to open an url). Remember the
previous discussions on using xdg-open to transmit browser opened
request on the desktop. Add /usr/loca/bin to your $PATH in your snap
path, ensure you have the desktop service installed and that should work.

Not opening random files on the system is by design, xdg-open filter
thoses. You can join the discussion at
https://github.com/snapcore/snapd-xdg-open/issues/18.

Cheers,
Didier


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

Re: Ubuntu Core 16 Feature Freeze

[Didier Roche]

Le 07/10/2016 à 11:46, Oliver Grawert a écrit :
> hi,
> Am Freitag, den 07.10.2016, 11:35 +0200 schrieb Oliver Grawert:
>>  
 These images are bootable, the PC image can be booted directly in
 qemu-kvm or virtualbox. When running the images in qemu-kvm it is
 helpful to use the "-redir" feature of qemu-kvm. E.g.:

 $ kvm -m 1500 -redir tcp:10022::22 -redir tcp:14200::14200
 ubuntu-core-16-amd64.img
>>> I was wondering if snapweb was listening to a different port
>> snapweb listens on 4200 which we redirect in the above command to the
>> hosts 14200 port (so we do not clash with a possibly running snapweb
> oops, but indeed the option should be:
>
> -redir tcp:14200::4200
>
> i.e. the kvm side still needs to listen to 4200.

Yeah, that was my point, one or the other, but it needs to match :)
Indeed, redirecting to 14200 might be good in the case someone has
already snapweb running on their system.



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

[Didier Roche]

Le 22/11/2016 à 15:38, Gustavo Niemeyer a écrit :
> The problem is that snapd works in environments where the dependencies
> to make the browser-launcher work aren't available.
>
> The right fix is probably to make it a dependency of one of the debs
> that are always installed on a normal desktop system, whether snapd is
> there or not. It's a very minimal piece of software.

How do you see non ubuntu distro being handled then?

Cheers,
Didier

>
> On Tue, Nov 22, 2016 at 5:21 AM, Mark Shuttleworth <m...@ubuntu.com
> <mailto:m...@ubuntu.com>> wrote:
>
> 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 <mailto:Snapcraft@lists.snapcraft.io>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> <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/listinfo/snapcraft

Re: Snaps to invoke external processes

[Didier Roche]

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.

Cheers,
Didier
>
> On Mon, Nov 21, 2016 at 9:09 PM, Spencer Parkin
> <spencertpar...@gmail.com <mailto:spencertpar...@gmail.com>> wrote:
>
> It's a miracle!  It works!  Now, for the first time ever, my users
> (all 0 of them) can reach the help page by clicking on "help" from
> within the app!  Thanks, Didier.  You're a real pal.
>
> On Mon, Nov 21, 2016 at 12:08 AM, Didier Roche
> <didro...@ubuntu.com <mailto:didro...@ubuntu.com>> wrote:
>
> Le 21/11/2016 à 04:26, Spencer a écrit :
> > It's been a few weeks now, but last I heard, the snapcraft
> team was or did a sprint to address current limitations snaps
> have regarding the invocation of external processes. 
> Specifically, it would be nice to launch the user's default
> browser with a URL, or let a snap invoke another instance of
> itself.  What's the status on this?
> >
> Hey Spencer,
>
> Default browser should works for some months already if your
> application
> (or toolkit, like Qt does) invoke the xdg-open to open the
> url. This is
> then transmitted via dbus to an external process on your
> classic system
> which then issues the real xdg-open command.
> For the others, there are been indeed multiple discussions on
> this at
> multiple places (here, on the bug report…), but no action or firm
> decision. I'm CCing Gustavo as he was the one against a more
> generic
> intermediate solutions.
>
> Cheers,
> Didier
>
>
> --
> 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: uwsgi systemd config (Type=notify)

[Didier Roche]

Le 21/11/2016 à 23:54, Boris Rybalkin a écrit :
> Hello,
>
> I am porting uwsgi systemd config to snap and having some problem.
> Snap installs correctly while systemd cannot start the service (some
> other configuration issue). I think uwsgi will notify systemd that it
> has started and looks like snap daemon does not support Type=notify.
>
> Original config:
> -
> [Unit]
> Description=uWSGI Internal
> After=syslog.target
>
> [Service]
> ;User=platform
> ExecStart={{ app_dir }}/uwsgi/bin/uwsgi --ini {{ config_root
> }}/config/uwsgi/internal.ini
> Restart=always
> KillSignal=SIGQUIT
> Type=notify
> StandardError=syslog
> NotifyAccess=all
> Environment=LD_LIBRARY_PATH={{ app_dir }}/python/lib
>
> [Install]
> WantedBy=multi-user.target
> -
> Which is almost exact copy of the recommended config by uwsgi developers:
> http://uwsgi-docs.readthedocs.io/en/latest/Systemd.html
>
> This is snap version:
> -
>   uwsgi:
> command: uwsgi/bin/uwsgi --ini ${SNAP_COMMON}/config/uwsgi/public.ini
> daemon: simple
> restart-condition: always
> plugs: [network, network-bind]
> -
>
> Snap way of defining systemd services seems very limited, is there a
> way to provide systemd version of the config in snapd?

Hey Boris,

This has been discussed some moons ago and indeed, it's not supported as
of today. Do you mind checking there is a bug for this in
https://launchpad.net/snappy and if none, file it?
Thanks!
Didier

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

[Didier Roche]

Le 21/11/2016 à 09:30, Eloy García (PC Actual) a écrit :
> Hi Didier.
>
> My snap package (wallpaperdownloader) invokes xdg-open internally but
> it isn't working yet. Should I use a specific interface to accomplish
> that? This is the snapcraft.yml
>

Hey Eloy,

You need to have snapd-xdg-open package installed on the desktop. IIRC,
the goal was to seed it by default or have snapd recommending it. CCing
mvo on that who also responsible for the package on ubuntu if there is
any reason this isn't the case yet.

Ensure you are then using xdg-open from /usr/local/bin/.

I konw this is working with the unity7 interface (I don't remember if
the x11 one is succifient, but it should, if not, it's a bug).
Cheers
Didier

> name: wallpaperdownloader
> version: "2.3"
> summary: Download, manage and change your favorite wallpapers from the 
> Internet
> description: WallpaperDownloader is a simple GUI Java based application for 
> downloading, managing and changing wallpapers from the Internet
> grade: stable
> confinement: strict
>
> apps:
>   wallpaperdownloader:
> command: wallpaperdownloader.sh
> plugs: [x11, network-bind, home, gsettings]
>
> parts:
>   # Pulls the code from the original source (master branch)
>   # desktop/gtk3 is a snapcraft part (snapcraft-desktop-helpers) from the 
> Wiki: https://wiki.ubuntu.com/snapcraft/parts
>   # It enables desktop integration and gsettings manipulation from the 
> confined application
>   # It is necessary to use gsettings interface (see above) in order to have a 
> fully functional
>   # desktop/gtk3 part
>   # Github repository for snapcraft-desktop-helpers: 
> https://github.com/ubuntu/snapcraft-desktop-helpers
>   wallpaperdownloader:
> source: https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader.git
> plugin: maven
> stage-packages:
>   # mate-desktop-common is necessary to have MATE gsettings schemas 
> available for the application
>   - mate-desktop-common
> after: [desktop-gtk3]
>
>   # It will copy wallpaperdownloader script into /bin/
>   # This script contains all the commands needed (sets env variables, 
> launches the jar file...) to
>   # execute the application
>   exec:
> plugin: dump
> source: scripts
>
> Thanks!!!
>
> Best,
>
> Eloy
>
> 2016-11-21 8:08 GMT+01:00 Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>>:
>
> Le 21/11/2016 à 04:26, Spencer a écrit :
> > It's been a few weeks now, but last I heard, the snapcraft team
> was or did a sprint to address current limitations snaps have
> regarding the invocation of external processes.  Specifically, it
> would be nice to launch the user's default browser with a URL, or
> let a snap invoke another instance of itself.  What's the status
> on this?
> >
> Hey Spencer,
>
> Default browser should works for some months already if your
> application
> (or toolkit, like Qt does) invoke the xdg-open to open the url.
> This is
> then transmitted via dbus to an external process on your classic
> system
> which then issues the real xdg-open command.
> For the others, there are been indeed multiple discussions on this at
> multiple places (here, on the bug report…), but no action or firm
> decision. I'm CCing Gustavo as he was the one against a more generic
> intermediate solutions.
>
> Cheers,
> Didier
>
>
> --
> 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>
>
>
>
>
> -- 
> Eloy García Almadén
>
>

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

Re: Cross platform snap creation?

[Didier Roche]

Le 14/11/2016 à 13:24, Érico P a écrit :
>
> Didier,
>
> Peter asked about building snaps from other systems, not running them.
> I think the idea would be to automate the building process of an app
> in Electron for multiple platforms. Forgive me if you got right and I
> just didn't understood what you have said.
>

Oh indeed, rereading, that's more than possible I misunderstood the
request this morning :)

I guess using a docker container like didrocks/snapcraft from dockerhub,
which always contain latest released version of snapcraft (based on
16.04 LTS).
Tell me if that suits your need Peter!
Didier
>
> Em 14 de nov de 2016 7:32 AM, "Didier Roche" <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> escreveu:
>
> Le 13/11/2016 à 15:58, Peter Uithoven a écrit :
>> 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-packager/issues/525#issuecomment-260109515>
>> https://github.com/electron-userland/electron-builder/issues/509
>> <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/
>
> Hey Peter,
>
> I don't think this is planned as of today, however, seeing snaps
> working on the Linux Windows subsystem would be indeed really
> interesting! The issue with elecctron apps is that they touch a
> big part of the technical stack (graphics, access to various
> files, javascript sandboxed engine…). I don't think that will be
> the easiest one.
>
> I think running some lxd ubuntu-core system containers would help
> at least as a first steps on supported platform for web service.
> Cheers,
> Didier
>
> --
> 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: Packaging nodejs apps

[Didier Roche]

Le 14/11/2016 à 10:55, Stephen Stewart a écrit :
> Hi,
>
> While looking into a nodejs/yarn plugin I wondered if I could make a
> yarn snap (not plugin), and simply define nodejs and yarn as parts,
> use dump plugin and be done, no plugin required:
>
> "Parts 'yarn' and 'node' have the following file paths in common which
> have different contents:"
>
> https://pastebin.canonical.com/170573/
>
> So I am wondering why doesn't this just work?

Hey Stephen,

It doesn't work simply because snapcraft doesn't know which file from
which part to ship. You have common files between parts with different
contents (as the error message underline). Which one of yarn's or node's
README.md should be included for instance?
>
> It seems like name collisions in parts might be a common enough thing,
> and I couldn't quite understand the help docs around filesets and
> organise to see a nice way to make this work for me across projects.

I guess http://snapcraft.io/docs/build-snaps/advanced-features will be a
better example.
Basically, you define in one parts a fileset with:
filesets:
  exclude:
- -README.md
- - LICENSE
- -lib/constants.js
(note the - to say to exclude those 3 files).

then, in the same part you want to exclude those files:
stage: [$exclude]
snap: [$exclude]

And you should be done!
Didier


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

Re: Symlink to snapcraft apps no longer working

[Didier Roche]

Le 14/11/2016 à 10:41, Zygmunt Krynicki a écrit :
>> Wiadomość napisana przez Martin Winter  w 
>> dniu 11.11.2016, o godz. 10:54:
>>
>> Not sure when this (recently) changed.
>>
>> All apps as defined by a snap are prefixed with the snap name
>>
>> Ie, I have under apps a “vtysh” defined, which then ends up as
>> quagga.vtysh (for the quagga snap).
>>
>> So far no issue.
>>
>> Now, a few weeks/months back, I was able to create a symlink
>> with “vtysh” pointing to “quagga.vtysh” and then could use the same
>> simple “vtysh” command to call the app. (same as traditional package 
>> installs)
>
> I think this is related to snap-run. You may have noticed that the 
> quagga.vtysh itself is a symlink to /usr/bin/snap. The new „snap run” command 
> understands symlinks and uses this as a hint on what to run.

Oh, good catch! Any way to get that fixed?
Martin, do you mind filing a bug?

Cheers,
Didier

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

Re: Symlink to snapcraft apps no longer working

[Didier Roche]

Le 11/11/2016 à 10:54, Martin Winter a écrit :
> Not sure when this (recently) changed.
>
> All apps as defined by a snap are prefixed with the snap name
>
> Ie, I have under apps a “vtysh” defined, which then ends up as
> quagga.vtysh (for the quagga snap).
>
> So far no issue.
>
> Now, a few weeks/months back, I was able to create a symlink
> with “vtysh” pointing to “quagga.vtysh” and then could use the same
> simple “vtysh” command to call the app. (same as traditional package
> installs)
>
> Link had to be done outside snap, but it allowed to keep all scripts
> unchanged.
>
> At the current snapd version (2.16ubuntu3), this does no longer work.
>
> all apps ends up as a symlink to the same /usr/bin/snap binary and
> somehow the
> binary seems to fail to call the correct app if there is another symlink
> used.
>
> Is there a way to get symlinks to still work as before?
>
Hey Martin,

I don't see what your issue is, nothing has changed and this isn't
linked at all to snapd but rather a traditional linux feature.

What commands are you running?
$ ln -s /snap/bin/gtk3-demo foo
$ ./foo
works here
$ ls -l foo
lrwxrwxrwx 1 didrocks didrocks 19 nov.  14 10:37 foo -> /snap/bin/gtk3-demo

As well.
Please provide debug output.

Cheers,
Didier

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

Re: Cross platform snap creation?

[Didier Roche]

Le 13/11/2016 à 15:58, Peter Uithoven a écrit :
> 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/

Hey Peter,

I don't think this is planned as of today, however, seeing snaps working
on the Linux Windows subsystem would be indeed really interesting! The
issue with elecctron apps is that they touch a big part of the technical
stack (graphics, access to various files, javascript sandboxed engine…).
I don't think that will be the easiest one.

I think running some lxd ubuntu-core system containers would help at
least as a first steps on supported platform for web service.
Cheers,
Didier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: configure hook

[Didier Roche]

Le 14/11/2016 à 10:04, Boris Rybalkin a écrit :
>
> Will it help if I upgrade to 16.10?
>
No, it contains the same version: https://launchpad.net/ubuntu/+source/snapd
Try the ubuntu core vm is the only easy way for you to progress there.

> Also what is really relation between snapd and ubuntu core on amd64?
>

snapd is part of the core snap. snapd from the core snap is running on
ubuntu core, snapd from the ubuntu package is running on the desktop.
(the REEXEC plan has been disabled some months ago, due to some issues IIRC)

Didier

>
> On 14 Nov 2016 8:01 am, "Didier Roche" <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 12/11/2016 à 17:45, Boris Rybalkin a écrit :
>>
>> Still struggling with hooks, they are not executed on install.
>>
>> snap$ snap run --hook=configure syncloud-platform
>> cannot snap-exec: cannot find hook "configure" in "syncloud-platform"
>> and even 'snap run --hook=configure mysnap' silently returns.
>>
>> I am using:
>> Ubuntu 16.04
>> snapd 2.16ubuntu3
>>
>> Does it have hook support?
>>
>
> It's supposed to have some, but IIRC, Kyle found some issues with
> it. Definitively, this version doesn't run the hook on install though.
>
>> According to this test they should even fail install if broken:
>> 
>> https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c8fc43051500bd6c3fda/tests/main/snap-set/task.yaml
>> 
>> <https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c8fc43051500bd6c3fda/tests/main/snap-set/task.yaml>
>>
>> As suggested I am copying meta/hooks to prime dir after running
>> snapcraft prime  and then running snapcraft snap.
>>
>> This bug says it is probably not yet available in edge, how do I
>> switch channel?
>>
>> https://bugs.launchpad.net/snappy/+bug/1636931
>> <https://bugs.launchpad.net/snappy/+bug/1636931>
>>
>
> As I said in some email above, the easiest path to test it is to
> use an ubuntu core VM (until a new snapd release is out for Ubuntu
> 16.04 desktop, CCing Michael to know when the next snapd hits
> stable + SRU published).
> Cheers,
> Didier
>
>> Thank you.
>>
>>
>> On 9 Nov 2016 09:21, "Didier Roche" <didro...@ubuntu.com
>> <mailto:didro...@ubuntu.com>> wrote:
>>
>> Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>>>
>>> One more question, should I expect a hook to run inside my
>>> snap package and use relative shebang like this?
>>>
>>> #!python/bin/python
>>>
>>> Assuming I am packaging python with my snap.
>>>
>> hooks are run using the same context than any "commands:" in
>> your snap.
>>
>> As long as we don't have snapcraft support, I don't think you
>> will have the override in PYTHONPATH, PYTHONHOME and such
>> (and I don't know if that's planned), but I'll give it a try
>> later this week or early new one to have great python hooks
>> examples.
>>
>> If you beat me to it, do not hesitate to report your results
>> here!
>>
>>> Thank you very much for your replies!
>>>
>>
>> My pleasure :)
>>
>>
>>>
>>> On 9 Nov 2016 08:58, "Didier Roche" <didro...@ubuntu.com
>>> <mailto:didro...@ubuntu.com>> wrote:
>>>
>>> Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :
>>>>
>>>> Sorry, I did not get that.
>>>>
>>>> I am using snapcraft, are you saying that just creating
>>>> hooks/configure is not enaugh?
>>>>
>>> It should be enough if you ensure it's in your final
>>> snap in meta/hooks/configure. (Look at your prime/
>>> directory).
>>> Enwei was talking about more advanced snapcraft
>>> integration, where you point to a file which is then
>>> copied for you in meta/hooks.
>>>
>>>> Looks like my hook is not executed:
>>>> https://github.com/syncloud/platform/tree/master/snap
>>>> <https://github.com/syncloud/platform/tree/master/snap>
>>>>
>>>> Is it possible to debug the execution of snap insta

Re: Nand flash booting.

[Didier Roche]

Le 14/11/2016 à 02:21, Daniel Toussaint a écrit :
> I am working on a board similar to Beaglebone Black, however instead
> of SD/eMMC it is booting from NAND flash directly. As far as I can see
> in the documentation there is no way yet to boot a Snappy image in
> this fashion, is support for this planned ? Is there anything I can do
> to help out with that ?
>
> Meanwhile, I am considering using the Yocto version of snapcraft to
> package the apps, so that we can later migrate to from the current
> Yocto image to Snappy. 
>
> Thanks for your comments.

Oliver (our Bleaglebone Black specialist and image author) should be
able to give some schedule if such feature is planned.
Didier

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

Re: crontab like snaps or interfaces

[Didier Roche]

Le 14/11/2016 à 09:03, Didier Roche a écrit :
> Le 14/11/2016 à 02:29, Enwei Zhang a écrit :
>> Hello,
>> I want to ask if there is any snaps or interfaces that could support
>> crontab or systemd.timer or that kind of timed operations.
>> For example, if my snap uses syslog to save all the logs, how should
>> logrotate work?
>>
>> Thanks so much.
> CCing Gustavo to get some clarification on this.
>
>
Also, please, open a bug on https://launchpad.net/snappy with the exact
use case. I'm unsure if you need an interface for this (interfaces are
between snaps), here it seems you only need systemd timer units and
crontab support (the same way we support services, hooks and such…)


Cheers,

Didier


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

Re: configure hook

[Didier Roche]

Le 12/11/2016 à 17:45, Boris Rybalkin a écrit :
>
> Still struggling with hooks, they are not executed on install.
>
> snap$ snap run --hook=configure syncloud-platform
> cannot snap-exec: cannot find hook "configure" in "syncloud-platform"
> and even 'snap run --hook=configure mysnap' silently returns.
>
> I am using:
> Ubuntu 16.04
> snapd 2.16ubuntu3
>
> Does it have hook support?
>

It's supposed to have some, but IIRC, Kyle found some issues with it.
Definitively, this version doesn't run the hook on install though.

> According to this test they should even fail install if broken:
> https://github.com/snapcore/snapd/blob/203591b28670ef5c4106c8fc43051500bd6c3fda/tests/main/snap-set/task.yaml
>
> As suggested I am copying meta/hooks to prime dir after running
> snapcraft prime  and then running snapcraft snap.
>
> This bug says it is probably not yet available in edge, how do I
> switch channel?
>
> https://bugs.launchpad.net/snappy/+bug/1636931
>

As I said in some email above, the easiest path to test it is to use an
ubuntu core VM (until a new snapd release is out for Ubuntu 16.04
desktop, CCing Michael to know when the next snapd hits stable + SRU
published).
Cheers,
Didier

> Thank you.
>
>
> On 9 Nov 2016 09:21, "Didier Roche" <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>>
>> One more question, should I expect a hook to run inside my snap
>> package and use relative shebang like this?
>>
>> #!python/bin/python
>>
>> Assuming I am packaging python with my snap.
>>
> hooks are run using the same context than any "commands:" in your
> snap.
>
> As long as we don't have snapcraft support, I don't think you will
> have the override in PYTHONPATH, PYTHONHOME and such (and I don't
> know if that's planned), but I'll give it a try later this week or
> early new one to have great python hooks examples.
>
> If you beat me to it, do not hesitate to report your results here!
>
>> Thank you very much for your replies!
>>
>
> My pleasure :)
>
>
>>
>> On 9 Nov 2016 08:58, "Didier Roche" <didro...@ubuntu.com
>> <mailto:didro...@ubuntu.com>> wrote:
>>
>> Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :
>>>
>>> Sorry, I did not get that.
>>>
>>> I am using snapcraft, are you saying that just creating
>>> hooks/configure is not enaugh?
>>>
>> It should be enough if you ensure it's in your final snap in
>> meta/hooks/configure. (Look at your prime/ directory).
>> Enwei was talking about more advanced snapcraft integration,
>> where you point to a file which is then copied for you in
>> meta/hooks.
>>
>>> Looks like my hook is not executed:
>>> https://github.com/syncloud/platform/tree/master/snap
>>> <https://github.com/syncloud/platform/tree/master/snap>
>>>
>>> Is it possible to debug the execution of snap install?
>>>
>>> I would like to see the state of the snap after it failed to
>>> start daemons. The only way to see the problem is to run
>>> journalctl and guess by startup errors.
>>>
>>>
>> Yeah, hooks are hard to debug, I filed
>> *https://bugs.launchpad.net/snappy/+bug/1640114
>> <https://bugs.launchpad.net/snappy/+bug/1640114> yesterday
>> about this.
>>
>> Didier
>> *
>>
>> --
>> 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 <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: configure hook

[Didier Roche]

Le 09/11/2016 à 10:15, Boris Rybalkin a écrit :
>
> One more question, should I expect a hook to run inside my snap
> package and use relative shebang like this?
>
> #!python/bin/python
>
> Assuming I am packaging python with my snap.
>
hooks are run using the same context than any "commands:" in your snap.

As long as we don't have snapcraft support, I don't think you will have
the override in PYTHONPATH, PYTHONHOME and such (and I don't know if
that's planned), but I'll give it a try later this week or early new one
to have great python hooks examples.

If you beat me to it, do not hesitate to report your results here!

> Thank you very much for your replies!
>

My pleasure :)


>
> On 9 Nov 2016 08:58, "Didier Roche" <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 09/11/2016 à 09:39, Boris Rybalkin a écrit :
>>
>> Sorry, I did not get that.
>>
>> I am using snapcraft, are you saying that just creating
>> hooks/configure is not enaugh?
>>
> It should be enough if you ensure it's in your final snap in
> meta/hooks/configure. (Look at your prime/ directory).
> Enwei was talking about more advanced snapcraft integration, where
> you point to a file which is then copied for you in meta/hooks.
>
>> Looks like my hook is not executed:
>> https://github.com/syncloud/platform/tree/master/snap
>> <https://github.com/syncloud/platform/tree/master/snap>
>>
>> Is it possible to debug the execution of snap install?
>>
>> I would like to see the state of the snap after it failed to
>> start daemons. The only way to see the problem is to run
>> journalctl and guess by startup errors.
>>
>>
> Yeah, hooks are hard to debug, I filed
> *https://bugs.launchpad.net/snappy/+bug/1640114
> <https://bugs.launchpad.net/snappy/+bug/1640114> yesterday about this.
>
> Didier
> *
>
> --
> 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: Snapping Chrome browser

[Didier Roche]

Le 08/11/2016 à 03:46, XiaoGuo Liu a écrit :
> Sorry, There is a typo in the last email. The installation instruction
> is:
>
> $ sudo snap install --beta --devmode

That's nice!

However, AFAIK, Chad (CCed) worked on this some months ago and got it
working as well in devmode.
The only issue on confinement was the sandbox itself which is tricky to
get working without it.

Please coordinate with him to see if any of this work can be reused on
your side!
Cheers,
Didier
>
> :)
>
> On Tue, Nov 8, 2016 at 10:02 AM, XiaoGuo Liu
> > wrote:
>
> Hi,
>
> After spending some effort, I finally made the Chrome browser snap
> working though it worked in "devmode". There is a small problem
> when I am trying to install it not using devmode.
>
> You can now install it like:
>
> $ sudo snap install --beta --devmoe
>
> The source code can be found
> at: https://github.com/liu-xiao-guo/mychrome
> 
>
> I have created a blog
> at: http://blog.csdn.net/ubuntutouch/article/details/53078713
> 
>
> Currently, it supports Chinese language and also Chinese input method.
>
> Thanks & best regards,
> XiaoGuo
>
> -- 
> XiaoGuo, Liu 
>
>
>
>
> -- 
> XiaoGuo, Liu 
>
>

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

Re: Snap hangs when accessing a special /dev/file (/dev/vcio) [ubuntu-core 16 / RaspberryPi2]

[Didier Roche]

Le 07/11/2016 à 12:17, Oliver Grawert a écrit :
> hi,
> Am Montag, den 07.11.2016, 11:23 +0100 schrieb Didier Roche:
>>  
>> Ah nice, I didn't find any documentation on it nor in the official
>> doc
>> (which was imported from the snapd repo before its removal) or in
>> https://github.com/snapcore/snapd/wiki/Interfaces. Any plan on
>> documenting it?
>>
>> Is there a bug report for ogra to enable it in the official gadget
>> snaps
>> for Pi 2/3?
> we only briefly had a hallway discussion about this at the sprint,
> happy to enable it in the gadget.
>
> but please note that a mailbox device (while using GPIO) gets quite
> some control over internal CPU processes, i think this needs additional
> securing over a plain GPIO interface ...

FYI, opened https://bugs.launchpad.net/snappy/+bug/1639798


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

Re: Error on compiling snap using wxPython

[Didier Roche]

Le 07/11/2016 à 13:25, Vincent JOBARD a écrit :
> Hi Didier Thx for your answer
>
> On Mon, Nov 7, 2016 at 9:02 AM Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 06/11/2016 à 01:40, Vincent JOBARD a écrit :
> > Hi every one
> >
> > Few days ago I found that a GUI exists for
> > YouTube-dl, https://github.com/MrS0m30n3/youtube-dl-gui.
> >
> > So I tried to create a snap for it, based on youtube-dl
> snapcraft.yaml
> > found in the Playpen
> >
> >
> https://github.com/Winael/youtube-dl-gui/blob/snapcraft/snapcraft.yaml
> >
> > but when I build my snap I have an error
> >
> > https://pastebin.ubuntu.com/23433523/
> >
> > I certainly miss something with the dependancies management but I
> > don't found what.
> >
> > Is there someone that could help me ?
>
> I suggest that you print PYTHON_PATH and look at the content that
> snapcraft has there. I doubt that the python plugin resolves
> dependencies from stage-packages at build time.
>
>
> How could I found the PYTHON_PATH from the parts ? I found that's not
> possible to download wxPython from PyPI so I can't use python-packages
> either. So I suppose that I need a Makefile, where I can specify the
> PYTHON_PATH. What do you think ? What can I specify as path ?

Let's see what Sergio tells (if this is supposed to be supported or not)
as he did rewrite recently the python plugin. If not, you can create
your own plugin inheriting from the python one, and exporting
PYTHON_PATH to what you need (there are some examples in the playpen for
this).
>
> >
> > I have to animate a workshop next week on how to create snaps, and
> > youtube-dl is one of my reference because of multi-source, cloud
> part
> > possibility and part priorization, and it could be nice to show
> how to
> > add a GUI on it with a desktop integration with a very simple
> > snapcraft.yaml file
> I suggest if you can't get that one working that you use the one I
> pointed you about. In addition, it's a continuation of the one you
> will
> demo as part of the conference and build upons multiple concepts:
> - mutiple sources (some local, some distant)
> - good ordering of properties
> - shortcuts and hints (.git enable stripping source-type)
> - services and commands talking together
> - local plugins.
>
>
> I'll use face-detection-demo snaps for the first part because it's the
> continuation of the presentation based on your work, but I have an
> hour and half so I will talk about youtube-dl. If I can't success with
> the GUI part, I will only show how to build youtube-dl CLI :) 
>
> Cheers
> Winael 
>
>

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

Re: Snap hangs when accessing a special /dev/file (/dev/vcio) [ubuntu-core 16 / RaspberryPi2]

[Didier Roche]

Le 07/11/2016 à 11:18, Simon Fels a écrit :
> On 07.11.2016 08:53, Didier Roche wrote:
>> Le 06/11/2016 à 11:50, Jacques Supcik a écrit :
>>> Dear community.
>>>
>>> I have a program <https://gitlab.com/telecom-tower/tower>, written in
>>> go, and running on a raspberry Pi 2, which displays messages on a LED
>>> panel. The panel <https://www.adafruit.com/product/2294> is made of
>>> "neo pixels" and is connected to the GPIO of the raspberry Pi.
>>> Internally, it uses the DMA and PWM to generate and accurate signals.
>>>
>>> The program currently runs well on a Raspbian system and I would like
>>> to move to ubuntu-core. I was able to build the snap and to deploy it
>>> on a raspberry Pi 2 running Core version 16. I installed the snap with
>>> "--dangerous", but as soon as the system configure the DMA/PWM/GPIO,
>>> it just freezes.
>>>
>>> I installed snappy-debug to check the logs and this is what I get:
>>>
>>> = AppArmor =
>>> Time: Nov  6 09:28:45
>>> Log: apparmor="DENIED" operation="open"
>>> profile="snap.telecom-tower.daemon" name="/dev/vcio" pid=4441
>>> comm="tower" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
>>> File: /dev/vcio (read)
>>>
>>> = Seccomp =
>>> Time: Nov  6 09:28:45
>>> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4441 comm="tower"
>>> exe="/snap/telecom-tower/x1/bin/tower" sig=31 arch=4028 14(mknod)
>>> compat=0 ip=0x76e3aaf6 code=0x0
>>> Syscall: mknod
>>>
>>> Note that if I scp the binary file and run on ubuntu core as root,
>>> then the program runs fine. (I don't install the snap, I just run the
>>> binary from the home directory.) 
>>>
>>> Does someone have an idea about what I can do to make my snap run?
>>>
>>> Thank you very much in advance for your support.
>> Hey Jacques,
>>
>> I think we did discuss about GPIO support in confined mode, but there is
>> no interface for this today AFAIK (CCing Jamie who can confirm and maybe
>> give a path/ETA forward).
>
> There is a GPIO interface. The downside of it is that you need a slot
> defined on the gadget snap. As long as this isn't done for the official
> gadget snaps for Pi 2/3 you can only build your own. See
> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/gpio.go
> for details about the interface itself.

Ah nice, I didn't find any documentation on it nor in the official doc
(which was imported from the snapd repo before its removal) or in
https://github.com/snapcore/snapd/wiki/Interfaces. Any plan on
documenting it?

Is there a bug report for ogra to enable it in the official gadget snaps
for Pi 2/3?
Cheers,
Didier

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

Re: Error on compiling snap using wxPython

[Didier Roche]

Le 06/11/2016 à 01:40, Vincent JOBARD a écrit :
> Hi every one
>
> Few days ago I found that a GUI exists for
> YouTube-dl, https://github.com/MrS0m30n3/youtube-dl-gui.
>
> So I tried to create a snap for it, based on youtube-dl snapcraft.yaml
> found in the Playpen
>
> https://github.com/Winael/youtube-dl-gui/blob/snapcraft/snapcraft.yaml
>
> but when I build my snap I have an error
>
> https://pastebin.ubuntu.com/23433523/
>
> I certainly miss something with the dependancies management but I
> don't found what.
>
> Is there someone that could help me ?

I suggest that you print PYTHON_PATH and look at the content that
snapcraft has there. I doubt that the python plugin resolves
dependencies from stage-packages at build time.
>
> I have to animate a workshop next week on how to create snaps, and
> youtube-dl is one of my reference because of multi-source, cloud part
> possibility and part priorization, and it could be nice to show how to
> add a GUI on it with a desktop integration with a very simple
> snapcraft.yaml file
I suggest if you can't get that one working that you use the one I
pointed you about. In addition, it's a continuation of the one you will
demo as part of the conference and build upons multiple concepts:
- mutiple sources (some local, some distant)
- good ordering of properties
- shortcuts and hints (.git enable stripping source-type)
- services and commands talking together
- local plugins.

Cheers,
Didier

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

Re: Project templates in snapcraft

[Didier Roche]

Le 05/11/2016 à 07:37, Spencer a écrit :
> Small, well commented examples, but not too small so as to leave out
> obviously wanted functionality, IMO, are way better than templates.
>  Part of the problem I have with any kind of template is OCD-based.  I
> don't want to start where someone else left off, and if I didn't write
> it, I won't immediately understand it, and I'm too lazy to read your
> code that's formatted in a way I don't like anyway.  (At work, though,
> I'm forced to wade through other people's crappy code.)
>
> Just having a nice suit of examples is the best, and I think the snap
> peeps have written some, but as I recall, they could be a bit better.
>  Of course, an example for every permutation of build system and
> use-case is too much, so you have to look to the snaps that the
> community has written.

+1 on this, agreed that small examples, using cloud parts for most
complex cases we want to capitalize on, will be greatly beneficial (more
than a templating system IMHO).
Cheers,
Didier
>
> Ha!  Mine are probably bad examples, though.  Don't look at mine.
>
> On Nov 4, 2016, at 8:11 PM, Érico P  > wrote:
>
>> Should be a place somewhere to store these recommended templates and
>> allow fetching third-party templates (I am thinking on cookiecutter
>> like templates).
>>
>> This has some resources on Electron, maybe it helps :
>> https://github.com/szwacz/electron-boilerplate
>>
>>
>> Em 5 de nov de 2016 00:00, "Chris Wayne" > > escreveu:
>>
>> There's really no standard way to build electron apps though
>>
>>
>> On Nov 4, 2016 9:58 PM, "Aaron Honeycutt"
>> > wrote:
>>
>> Also electron projects
>>
>>
>> On Fri, Nov 4, 2016, 9:20 PM XiaoGuo Liu
>> > > wrote:
>>
>> +1
>>
>> I think it may apply to "nodejs", "python", "tomcat",
>> "mysql", "php", "java" etc.
>>
>> Best regards,
>> XiaoGuo
>>
>> On Sat, Nov 5, 2016 at 1:39 AM, Benjamin Zeller
>> > > wrote:
>>
>> Just a small proposal to have templates in snapcraft,
>> that provide some sort of starting point for
>> people without the need to read lots of tutorials,
>> but get started with their project right away.
>>
>> My proposal would be to add a template engine in
>> snapcraft, that generates predefined projects
>> or at least a predefined snapcraft.yaml for a
>> specific use case.
>>
>> Something like:
>>
>> snapcraft init --template=ubuntu-touch-app , which
>> would bootstrap a simple snapcraft project
>> targeting QML/Qt APIs.
>>
>> I think that could help people to get their apps
>> snapped even faster.
>>
>> Cheers,
>>
>> Benjamin
>>
>>
>>
>> -- 
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> 
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>> 
>>
>>
>>
>>
>> -- 
>> XiaoGuo, Liu 
>> --
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io
>> 
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>> 
>>
>> -- 
>>
>> Aaron Honeycutt
>> - Ubuntu Fl Loco South Lead
>> - Kubuntu Council Member
>>
>>
>> --
>> 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
>> 
>>
>> -- 
>> Snapcraft mailing list
>> Snapcraft@lists.snapcraft.io 
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>
>

-- 
Snapcraft mailing list

Re: Snap hangs when accessing a special /dev/file (/dev/vcio) [ubuntu-core 16 / RaspberryPi2]

[Didier Roche]

Le 06/11/2016 à 11:50, Jacques Supcik a écrit :
> Dear community.
>
> I have a program , written in
> go, and running on a raspberry Pi 2, which displays messages on a LED
> panel. The panel  is made of
> "neo pixels" and is connected to the GPIO of the raspberry Pi.
> Internally, it uses the DMA and PWM to generate and accurate signals.
>
> The program currently runs well on a Raspbian system and I would like
> to move to ubuntu-core. I was able to build the snap and to deploy it
> on a raspberry Pi 2 running Core version 16. I installed the snap with
> "--dangerous", but as soon as the system configure the DMA/PWM/GPIO,
> it just freezes.
>
> I installed snappy-debug to check the logs and this is what I get:
>
> = AppArmor =
> Time: Nov  6 09:28:45
> Log: apparmor="DENIED" operation="open"
> profile="snap.telecom-tower.daemon" name="/dev/vcio" pid=4441
> comm="tower" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
> File: /dev/vcio (read)
>
> = Seccomp =
> Time: Nov  6 09:28:45
> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=4441 comm="tower"
> exe="/snap/telecom-tower/x1/bin/tower" sig=31 arch=4028 14(mknod)
> compat=0 ip=0x76e3aaf6 code=0x0
> Syscall: mknod
>
> Note that if I scp the binary file and run on ubuntu core as root,
> then the program runs fine. (I don't install the snap, I just run the
> binary from the home directory.) 
>
> Does someone have an idea about what I can do to make my snap run?
>
> Thank you very much in advance for your support.

Hey Jacques,

I think we did discuss about GPIO support in confined mode, but there is
no interface for this today AFAIK (CCing Jamie who can confirm and maybe
give a path/ETA forward).

Meanwhile, you can still install your snap in devmode to bypass
security, and that should do it in your case, mind confirming?
Cheers,
Didier
-- 
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: Optional daemon

[Didier Roche]

Le 28/10/2016 à 21:00, Aaron Ogle a écrit :
> Point definitely well made.  I'm with you now.  :)
>
> Now this being the case.  I can't just swap the location.  This is
> where I would need a rock solid upgrade hook.  But I would only need
> to run it the once. Any suggestions?  Or any good examples?

Maybe Kyle missed that one.
For now, AFAIK, we don't have upgrade hook (yet ;)). I would go with the
wrapper script (that I think you already have) path. Check for the
database location in $SNAP_DATA. If nothing exists, do the migration,
remove $SNAP_COMMON database content once done.

That should do the trick?
Cheers,
Didier

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

Re: Optional daemon

[Didier Roche]

Le 27/10/2016 à 17:33, Aaron Ogle a écrit :
> Didier:
>
> This sounds like exactly what I wanted!  So once this lands I will be
> able to just use: snapctl get value to get user set information?
Exactly!

>
> Will the snapctl command be available anywhere in the snap or only in
> the hooks?

I guess the main intent is to use them primarily in hooks, but nothing
should prevent it to be available in your other snap daemon as well (as
it's part of the core rootfs).

>
> Also the upgrade hook looks like it could be a thing of beauty. Any
> plans for a downgrade hook?

I don't know about any plan for that, I'll let others answer. I think
you mean a downgrade hook being executed after a snap revert to fetch
back "newer data" that could be lost in the revert process and transfer
back to the older version? Or do you have any other use case in mind?

Didier
>
> On Thu, Oct 27, 2016 at 10:14 AM Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
>
> Le 27/10/2016 à 16:50, Aaron Ogle a écrit :
> > Greetings,
> >
> > With our Rocket.Chat snap, we're looking to be able to allow someone
> > to run an external mongodb instead of the built in one.  As well as
> > we'd like to add something like caddy / traefik etc to do ssl
> > termination.  But its not a daemon we would want enabled out of the
> > box because of the effect on existing users.
> >
> > So basically looking for a way let the user of a snap enable or
> > disable two different daemons in our snap.
> >
> > Is this possible using anything out of the box?  Or would I have to
> > make the command ran in the daemon look at an environment variable /
> > file etc. and determine if it should make the daemon just exit?
> >
> > How have others handled this?  Or allowing users to customize snap
> > behaviour?
>
> Hey Aaron,
>
> sounds like a great plan for usability!
>
> I would suggest using configure hooks to proceed that. Hooks are
> just a
> way for users to set variable=value. Based on that, you can
> control your
> daemon with a configure script (triggered by this command) inside your
> snap. This one can triggers start and stop inside a mongodb daemon
> wrapper (waiting for a certain value to be passed for instance before
> executing the real daemon).
>
> The documentation is not yet published on snapcraft.io
> <http://snapcraft.io> AFAIK, but is
> available there:
> https://github.com/snapcore/snapd/blob/master/docs/hooks.md.
>
> However, please keep in mind about this bug
> https://bugs.launchpad.net/snappy/+bug/1636931, we need a new core
> image
> to have snapctl available from your snap, and so, you won't be able to
> experiment it right away.
>
> I'll probably write a codelab on this precise topic in a couple of
> weeks
> FYI (once the feature is really available to users and developers).
> Cheers,
> Didier
>
>
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io <mailto:Snapcraft@lists.snapcraft.io>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>
> -- 
>
>   
> *Aaron Ogle* Core Developer
>
> aaron.o...@rocket.chat <mailto:aaron.o...@rocket.chat>
>
> @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle>
>
> https://rocket.chat
>
>
>

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

Re: Optional daemon

[Didier Roche]

Le 27/10/2016 à 16:50, Aaron Ogle a écrit :
> Greetings,
>
> With our Rocket.Chat snap, we're looking to be able to allow someone
> to run an external mongodb instead of the built in one.  As well as
> we'd like to add something like caddy / traefik etc to do ssl
> termination.  But its not a daemon we would want enabled out of the
> box because of the effect on existing users.
>
> So basically looking for a way let the user of a snap enable or
> disable two different daemons in our snap.
>
> Is this possible using anything out of the box?  Or would I have to
> make the command ran in the daemon look at an environment variable /
> file etc. and determine if it should make the daemon just exit?
>
> How have others handled this?  Or allowing users to customize snap
> behaviour?

Hey Aaron,

sounds like a great plan for usability!

I would suggest using configure hooks to proceed that. Hooks are just a
way for users to set variable=value. Based on that, you can control your
daemon with a configure script (triggered by this command) inside your
snap. This one can triggers start and stop inside a mongodb daemon
wrapper (waiting for a certain value to be passed for instance before
executing the real daemon).

The documentation is not yet published on snapcraft.io AFAIK, but is
available there:
https://github.com/snapcore/snapd/blob/master/docs/hooks.md.

However, please keep in mind about this bug
https://bugs.launchpad.net/snappy/+bug/1636931, we need a new core image
to have snapctl available from your snap, and so, you won't be able to
experiment it right away.

I'll probably write a codelab on this precise topic in a couple of weeks
FYI (once the feature is really available to users and developers).
Cheers,
Didier


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

Re: Provisional snap for DUB (D language package/build manager)

[Didier Roche]

Le 27/10/2016 à 08:37, Didier Roche a écrit :
> Le 27/10/2016 à 01:13, Joseph Rushton Wakeling a écrit :
>> Hello folks,
> Hey Joseph,
>
> It would be great to have D support! Thanks for working on that :)
> I'm going to try to answer to some of your questions, but I'm sure
> Sergio (CCed) would be able to give deeper insights on some parts as
> being the snapcraft upstream.
>> Following my attempt to create a snap for LDC (LLVM-based compiler for
>> the D programming language), I thought I'd have a go at another
>> D-related project and snap DUB.  This is a package/build manager
>> that's popular in the D community, and so having it available as a
>> snap could be very useful.
>>
>> First caveats: this is a command-line developer tool, so some of the
>> same limitations are going to apply as were identified with the LDC
>> snap (access to system tools, linking against host-system development
>> libraries, etc.).  I also had to take some temporary shortcuts to
>> ensure that the packaged DUB had a D compiler available.
>>
>> The draft package is available here:
>> https://github.com/WebDrake/dub.snap/pull/1/files
>>
>> A few things on what went into it, and corresponding requests for
>> feedback.
>>
>> First: DUB can be built two ways; either by calling a shell script,
>> `build.sh`, or by DUB itself via an existing install.  I couldn't
>> identify an obvious way to handle the former, so (given that DUB is
>> packaged in Ubuntu 16.04) I opted to create a `dub.py` snapcraft plugin.
>>
>> I'm not a Pythonist myself, so any feedback on that code would be
>> welcome.  But I have a couple of other questions:
>>
>>   * Is there any way for the plugin to ask for a `dub` instance to be
>> available?
>> Currently I'm just specifying `dub` as a build dependency in
>> addition to the
>> plugin.
>>
>>   * Assuming I'd wanted to go the `build.sh` route, is there any way I
>> could
>> have achieved that with existing plugins?
> I would really advise going the build.sh route. Doing a custom snapcraft
> plugin as you started is definitively the right path.
> If you take other plugins having similar problematic, like Go, here is
> how they work:
> - Golang binaries (compiler tools and standard library) installs itself
> in parts//go. This logic is from the golang plugin itself.
> You will need in your case to ensure LDC is relocatable and can be
> downloaded and extracted this way. You can then build without depending
> on any package or distribution.
> - Then, the plugin run go build, go install, changing the paths. The
> plugin can define optional parameters that it will use then. In you
> case, I think the plugin will setup environment variables to refers to
> local LDC and standard D libraries. Then, you can have one option being
> "entry-point", which will refers in your DUB snap case to build.sh. The
> plugin would execute it.

Just a note: after a quick double checking , the snapcraft go plugin
relies on ubuntu packages (I think it should rather download latest
stable go and use GOROOT to use it). This isn't the case for other
plugins like nodejs which was the one I had in mind and I still think
you should prefer that road.

Didier

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

Re: Un-revert a snap

[Didier Roche]

Le 27/10/2016 à 09:44, YC Cheng a écrit :
> Reply in-line, YC
>
> 2016-10-27 15:36 GMT+08:00 Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>>:
>
> Le 27/10/2016 à 09:18, YC Cheng a écrit :
>> I found the following command works:
>>
>> snap revert --revision 29
>>
>> as expected.
>
> Indeed,
> you will notice though that any new data which have been produced
> after the revert by revision 20 will not be available to the new
> revision 29, which may not be the expected outcome.
> (So, the 2 commands are not equivalent)
>
>
> Yes, I saw that and that make sense to me. One idea to make "refresh"
> better is: we can check sum the snap and report more information. Or
> the message seem not make much sense to me. Do you think this sounds
> like another bug to fire ?

Hum, yeah, it could be more informative telling there is indeed a
possible revision during refresh, but that one was blacklisted (+ steps
for rereverting either removing data or keeping them).

>> We still need a command to list all revision of a snap install in
>> the system (we can get that from 'df', but still better to get
>> all info from a command) ?
> +1, as we had "snappy list -v" in 15.04.
>
>
> Fire a bug: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1637096
>  
>
> Didier
>
>>
>> YC
>>
>> 2016-10-27 14:38 GMT+08:00 Didier Roche <didro...@ubuntu.com
>> <mailto:didro...@ubuntu.com>>:
>>
>> Le 27/10/2016 à 08:32, YC Cheng a écrit :
>>> I think we need a way to just Un-revert from rev 20 to rev
>>> 29 without remove rev 29.
>>>
>>> Shall we fire a bug for that if we don't have such method
>>> exists now ?
>>
>> I think it's not that easy considering the associated data.
>> You need to swap them to restart from the latest version of
>> data from rev 20 to copy to 29. Explicitely removing that
>> version makes sense in that context. Have an unrevert command
>> won't convey that notion.
>>
>> Didier
>>
>>>
>>>
>>> 2016-10-27 14:13 GMT+08:00 Didier Roche <didro...@ubuntu.com
>>> <mailto:didro...@ubuntu.com>>:
>>>
>>> Le 27/10/2016 à 03:01, Marcos Alano a écrit :
>>> > Hello guys,
>>>
>>> Hey Marcos,
>>> >
>>> >
>>> > Sorry if I'm in the wrong mailing list. That's the
>>> only one about snap i
>>> > could found. The question is: how I revert-revert
>>> (un-revert) a snap? I
>>> > can install a snap:
>>> >
>>> > (sudo snap install hello) after thatr I can upgrade a
>>> snap (snap refresh
>>> > hello --channel=beta hello) and finally revert (sudo
>>> snap revert hello).
>>> > But after that if I try to re-upgrade I just can't:
>>> >
>>> > $ sudo snap refresh --beta hello
>>> >
>>> > error: cannot refresh "hello": snap "hello" has no
>>> updates available
>>> >
>>> > I'm doing something wrong?
>>>
>>> You are not doing it wrong :) The revert command
>>> "blacklists" this
>>> particular snap revisions on purpose, so that you don't
>>> reupdate to it.
>>> However, there is a way to get back to it! You can
>>> remove explicitely
>>> that revision (without removing the current snap). Data
>>> associated to
>>> the reverted revision will be cleaned up as well.
>>> Then, you can refresh.
>>>
>>> In a concrete example with the hello snap:
>>> 20 is the revision in the stable channel, 29 corresponds
>>> to the revision
>>> in the beta channel.
>>>
>>> # Install and update
>>> $ snap install hello
>>> $ snap list hello
>>> Name   Version  Rev  Developer  Notes
>>> hello 2.10 20   canonical  -
>>>

Re: Un-revert a snap

[Didier Roche]

Le 27/10/2016 à 09:18, YC Cheng a écrit :
> I found the following command works:
>
> snap revert --revision 29
>
> as expected.

Indeed,
you will notice though that any new data which have been produced after
the revert by revision 20 will not be available to the new revision 29,
which may not be the expected outcome.
(So, the 2 commands are not equivalent)


>
> We still need a command to list all revision of a snap install in the
> system (we can get that from 'df', but still better to get all info
> from a command) ?
+1, as we had "snappy list -v" in 15.04.

Didier
>
> YC
>
> 2016-10-27 14:38 GMT+08:00 Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>>:
>
> Le 27/10/2016 à 08:32, YC Cheng a écrit :
>> I think we need a way to just Un-revert from rev 20 to rev 29
>> without remove rev 29.
>>
>> Shall we fire a bug for that if we don't have such method exists
>> now ?
>
> I think it's not that easy considering the associated data. You
> need to swap them to restart from the latest version of data from
> rev 20 to copy to 29. Explicitely removing that version makes
> sense in that context. Have an unrevert command won't convey that
> notion.
>
> Didier
>
>>
>>
>> 2016-10-27 14:13 GMT+08:00 Didier Roche <didro...@ubuntu.com
>> <mailto:didro...@ubuntu.com>>:
>>
>> Le 27/10/2016 à 03:01, Marcos Alano a écrit :
>> > Hello guys,
>>
>> Hey Marcos,
>> >
>> >
>> > Sorry if I'm in the wrong mailing list. That's the only one
>> about snap i
>> > could found. The question is: how I revert-revert
>> (un-revert) a snap? I
>> > can install a snap:
>> >
>> > (sudo snap install hello) after thatr I can upgrade a snap
>> (snap refresh
>> > hello --channel=beta hello) and finally revert (sudo snap
>> revert hello).
>> > But after that if I try to re-upgrade I just can't:
>> >
>> > $ sudo snap refresh --beta hello
>> >
>> > error: cannot refresh "hello": snap "hello" has no updates
>> available
>> >
>> > I'm doing something wrong?
>>
>> You are not doing it wrong :) The revert command "blacklists"
>> this
>> particular snap revisions on purpose, so that you don't
>> reupdate to it.
>> However, there is a way to get back to it! You can remove
>> explicitely
>> that revision (without removing the current snap). Data
>> associated to
>> the reverted revision will be cleaned up as well.
>> Then, you can refresh.
>>
>> In a concrete example with the hello snap:
>> 20 is the revision in the stable channel, 29 corresponds to
>> the revision
>> in the beta channel.
>>
>> # Install and update
>> $ snap install hello
>> $ snap list hello
>> Name   Version  Rev  Developer  Notes
>> hello 2.10 20   canonical  -
>> $ snap refresh hello --beta
>> $ snap list hello
>> Name   Version  Rev  Developer  Notes
>> hello 2.10.1   29   canonical  -
>>
>> # Revert
>> $ snap revert hello
>> $ snap list hello
>> Name   Version  Rev  Developer  Notes
>> hello 2.10 20   canonical  -
>>
>> # Remove reverted version (and associated data)
>> $ snap remove hello --revision=29
>> hello removed
>> $ snap list hello
>> Name   Version  Rev  Developer  Notes
>> hello 2.10 20   canonical  -
>>
>> # Reupdate
>> $ snap refresh hello --beta
>> $ snap list hello
>> Name   Version  Rev  Developer  Notes
>> hello 2.10.1   29   canonical  -
>>
>> I hope that answer your questions :)
>> Cheers,
>> Didier
>>
>>
>> --
>> 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 <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: Provisional snap for DUB (D language package/build manager)

[Didier Roche]

Le 27/10/2016 à 01:13, Joseph Rushton Wakeling a écrit :
> Hello folks,

Hey Joseph,

It would be great to have D support! Thanks for working on that :)
I'm going to try to answer to some of your questions, but I'm sure
Sergio (CCed) would be able to give deeper insights on some parts as
being the snapcraft upstream.
>
> Following my attempt to create a snap for LDC (LLVM-based compiler for
> the D programming language), I thought I'd have a go at another
> D-related project and snap DUB.  This is a package/build manager
> that's popular in the D community, and so having it available as a
> snap could be very useful.
>
> First caveats: this is a command-line developer tool, so some of the
> same limitations are going to apply as were identified with the LDC
> snap (access to system tools, linking against host-system development
> libraries, etc.).  I also had to take some temporary shortcuts to
> ensure that the packaged DUB had a D compiler available.
>
> The draft package is available here:
> https://github.com/WebDrake/dub.snap/pull/1/files
>
> A few things on what went into it, and corresponding requests for
> feedback.
>
> First: DUB can be built two ways; either by calling a shell script,
> `build.sh`, or by DUB itself via an existing install.  I couldn't
> identify an obvious way to handle the former, so (given that DUB is
> packaged in Ubuntu 16.04) I opted to create a `dub.py` snapcraft plugin.
>
> I'm not a Pythonist myself, so any feedback on that code would be
> welcome.  But I have a couple of other questions:
>
>   * Is there any way for the plugin to ask for a `dub` instance to be
> available?
> Currently I'm just specifying `dub` as a build dependency in
> addition to the
> plugin.
>
>   * Assuming I'd wanted to go the `build.sh` route, is there any way I
> could
> have achieved that with existing plugins?

I would really advise going the build.sh route. Doing a custom snapcraft
plugin as you started is definitively the right path.
If you take other plugins having similar problematic, like Go, here is
how they work:
- Golang binaries (compiler tools and standard library) installs itself
in parts//go. This logic is from the golang plugin itself.
You will need in your case to ensure LDC is relocatable and can be
downloaded and extracted this way. You can then build without depending
on any package or distribution.
- Then, the plugin run go build, go install, changing the paths. The
plugin can define optional parameters that it will use then. In you
case, I think the plugin will setup environment variables to refers to
local LDC and standard D libraries. Then, you can have one option being
"entry-point", which will refers in your DUB snap case to build.sh. The
plugin would execute it.


>
> DUB doesn't have an `install` option, only a `build` one, which
> creates some problems in terms of determining what files go into the
> snap.  I compromised on a short term workaround where the plugin
> copies everything in the `build/` dir of the part being built, and the
> user is expected to manually specify what bits of that should actually
> wind up in the final snap.  If there is a target path where the built
> files are placed, the plugin can handle that, too.
>
> Two questions there, too:
>
>   * Is there any way to filter that stuff out already at the staging area
> or earlier?  I tried using `filesets:` but didn't have much luck.
>
>   * Is there any way to detect what extra files have been created
> after the
> build completes and just use those?

>From your questions and the statement that there is no explicit install
steps, I think you mean that D programs just build in tree (snapcraft
tries to encourage builds out of trees) and then, the install step for
people is to copy the resulting binaries and assets manually?

If so, I can see 2 paths here:
- either you expect people to explicitely list assets and binaries that
should be installed (this could again be a custom option of your plugin)
- either you try to be starter, as you told, and detect extra files
being created in the parts//build. There is no built-in
features in snapcraft for this as far as I know, but, it would be quite
easy to build it as part of your plugin: list at the start of the build
phase files in parts//build and redo the same thing after the
build. Then, in the install phase, use that list (that you store on
disk) to copy newly created content in parts//install. Then,
snapcraft will pick it up from there. Note that I think you still need a
manual options for your users to list eventual assets (or they can use
the dump plugin in another part).

Just pick the flow which would be the more natural to the D plugin users.

If you prefer to copy everything and have your users filtering from the
stage area to the prime area, you can use the "snap:" stenza (don't use
filesets for now if you don't plan to repeat the file list name).

>
> Since DUB needs a D compiler to be able to build anything, I first
> tried 

Re: Problems trying to create a snap package for bioinformatics tools

[Didier Roche]

Le 24/10/2016 à 16:13, Gordon Ball a écrit :

> Hello

Hey Gordon,

> I have been trying to create a snap package for the `cufflinks` [1]
> biofinformatics tools. These are packaged for debian/ubuntu, but the
> package is not built for xenial due to issues with boost 1.56-1.59. [2]

Nice way to ship latest to xenial users! Thanks for this 

> I tried building a snap package (see snapcraft.yaml below - just a
> simple `stage-packages` build) on yakkety in order to bundle the
> relevant dependencies and then install it on xenial, but I ran into the
> following issues:
>
>
>  * Trying to run any of the binaries gives the error
>
> failed to create user data directory. errmsg: Permission denied
>
>This is presumably related to #1592696, but in this case $HOME is on
> an NFS mount under /mnt. Probably an uncommon case, but this probably
> isn't the only such configuration.

Interesting use case 
In that case, I would say open a separate bugs for it. The issue can be
encryptfs, or profiles not supporting $HOME set to /mnt (or something
else to /home/*). It worthes tracking it!

>  * The package contains multiple binaries, and the links in /snap/bin
> are named, eg `cufflinks.cuffdiff`, which makes them incompatible with
> existing scripts. Additionally, I can't declare `apps:` keys with
> underscores in them, so some come out completely misnamed.
>
>Did I miss an option somewhere to better control command naming?

No, you didn't miss anything. As you noticed, commands are namespaced by
the snap name. So, there are 2 rules:
* . for general app name
*  only as a shortcut if snap name == app name

1. If the scripts you mentioned are part of what's shipped inside your
snap, I would advise patching upstream to accept rather relocatable path
(note that we do direct $PATH inside to $SNAP/bin/ and other similar
path, so they should find the "short" name). You can as well ship dummy
wrappers as part of your snap to also handle those use cases if needed
(but again, from call inside the snap)
2/ If the scripts are externals, we started to discuss about ways to
expose different top-level commands to the system. I'm CCing Gustavo
here who may want to share his plans around this.
Meanwhile, way to workaround this latter case are either:
 a) adapting your scripts to call the snap command schema
 b) ship some redirect dummy shell which will exec the corresponding
snapname.appname, and add the directory containing those scripts to your
user's $PATH.

Also, I don't see any reason why we are preventing underscores in app
name (nothing in yaml prevents key to be underscores). I don't link such
command name in general, but I don't see any good reasons for this.
Gustavo, is that deliberate?

Cheers,
Didier


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

Re: snap integration with XFCE

[Didier Roche]

Le 24/10/2016 à 10:58, Eloy García (PC Actual) a écrit :
> Hi Didier!
> 
> Thanks as always for your answer and feedback :) I suspected it and I
> was taking a look to desktop launcher source code on github, but I
> didn't have time to test it. One question: Can I create the symblink
> when the snap application is executed (after installation) via the
> script that i use to wrap up the launching process or will I have
> problems to do that because of the confinement?

No worry :)

As long as your snap has the right plug to access the initial file, this
isn't an issue (and exactly what I'm doing in the desktop launcher for
dconf/gsettings: creating symlink on first launch or after each snap
upgrade if the symlink isn't present).
You can see such an example in
https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/glib-only/launcher-specific#L37
for instance.

(But yeah, it relies on /home/$USER/ and should probably find a better
way to get user's real home directory. I can't use $HOME as it's
redirected to SNAP_USER_DATA in some cases)


> 
> Best,
> 
> Eloy
> 
> 2016-10-24 10:14 GMT+02:00 Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>>:
> 
> Le 06/10/2016 à 21:34, Eloy García (PC Actual) a écrit :
>> Hi all.
>>
>> I develop a java-based application to download and manage
>> wallpapers from the Internet (wallpaperdownloader)
>> (https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/overview 
>> <https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/overview>).
>> The applications is in the store but now I'm trying to integrate
>> XFCE desktop too. I mean, now you can set any wallpaper downloaded
>> directly from the GUI and it is working fine for GNOME 3, Unity
>> and MATE. All three of them use gsettings interface and
>> desktop-gtk3 wrapper part as you can see in the snapcraft.yaml:
>>
>> name: wallpaperdownloader
>> version: "2.2"
>> summary: Download and manage your favorite wallpapers from the Internet
>> description: WallpaperDownloader is a simple GUI Java based application 
>> for
>> downloading and managing wallpapers from the Internet
>> grade: stable
>> confinement: strict
>>
>> apps:
>>   wallpaperdownloader:
>> command: wallpaperdownloader.sh
>> plugs: [x11, network-bind, home, gsettings]
>>
>> parts:
>>   # Pulls the code from the original source (master branch)
>>   # desktop/gtk3 is a snapcraft part (snapcraft-desktop-helpers)
>> from the Wiki: https://wiki.ubuntu.com/snapcraft/parts
>> <https://wiki.ubuntu.com/snapcraft/parts>
>>   # It enables desktop integration and gsettings manipulation from
>> the confined application
>>   # It is necessary to use gsettings interface (see above) in order
>> to have a fully functional
>>   # desktop/gtk3 part
>>   # Github repository for snapcraft-desktop-helpers:
>> https://github.com/ubuntu/snapcraft-desktop-helpers
>> <https://github.com/ubuntu/snapcraft-desktop-helpers>
>>   wallpaperdownloader:
>> plugin: maven
>> source: ..
>> stage-packages:
>>   # mate-desktop-common is necessary to have MATE gsettings schemas
>> available for the application
>>   - mate-desktop-common
>> after: [desktop/gtk3]
>>
>>   # It will copy wallpaperdownloader script into /bin/
>>   # This script contains all the commands needed (sets env
>> variables, launches the jar file...) to
>>   # execute the application
>>   exec:
>> plugin: dump
>> source: scripts
>> Now, if XFCE desktop is detected by the application, the command
>> run inthe background is 'xfconf-query --channel xfce4-desktop
>> --property /backdrop/screen0/monitor0/workspace0/last-image --set
>> wallpaper.jpg'. If the application runs natively, there is no
>> problem and the wallpaper is set properly. But when I test the
>> snap package built, this is the error thrown:
>>
>> ERROR LinuxWallpaperChanger:188 - Property
>> "/backdrop/screen0/monitor0/workspace0/last-image" does not exist
>> on channel "xfce4-desktop". If a new property should be created,
>> use the --create option.
>>
>> I have included xfconf as stage-package and the command
>> xfconf-query is found within the snap. Could you give me a hint to
>> solve this problem?
>>
>> Thank you very 

Re: snap integration with XFCE

[Didier Roche]

Le 06/10/2016 à 21:34, Eloy García (PC Actual) a écrit :
> Hi all.
>
> I develop a java-based application to download and manage wallpapers
> from the Internet (wallpaperdownloader)
> (https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/overview).
> The applications is in the store but now I'm trying to integrate XFCE
> desktop too. I mean, now you can set any wallpaper downloaded directly
> from the GUI and it is working fine for GNOME 3, Unity and MATE. All
> three of them use gsettings interface and desktop-gtk3 wrapper part as
> you can see in the snapcraft.yaml:
>
> name: wallpaperdownloader
> version: "2.2"
> summary: Download and manage your favorite wallpapers from the Internet
> description: WallpaperDownloader is a simple GUI Java based application for
> downloading and managing wallpapers from the Internet
> grade: stable
> confinement: strict
>
> apps:
>   wallpaperdownloader:
> command: wallpaperdownloader.sh
> plugs: [x11, network-bind, home, gsettings]
>
> parts:
>   # Pulls the code from the original source (master branch)
>   # desktop/gtk3 is a snapcraft part (snapcraft-desktop-helpers) from
> the Wiki: https://wiki.ubuntu.com/snapcraft/parts
>   # It enables desktop integration and gsettings manipulation from the
> confined application
>   # It is necessary to use gsettings interface (see above) in order to
> have a fully functional
>   # desktop/gtk3 part
>   # Github repository for snapcraft-desktop-helpers:
> https://github.com/ubuntu/snapcraft-desktop-helpers
>   wallpaperdownloader:
> plugin: maven
> source: ..
> stage-packages:
>   # mate-desktop-common is necessary to have MATE gsettings schemas
> available for the application
>   - mate-desktop-common
> after: [desktop/gtk3]
>
>   # It will copy wallpaperdownloader script into /bin/
>   # This script contains all the commands needed (sets env variables,
> launches the jar file...) to
>   # execute the application
>   exec:
> plugin: dump
> source: scripts
> Now, if XFCE desktop is detected by the application, the command run
> inthe background is 'xfconf-query --channel xfce4-desktop --property
> /backdrop/screen0/monitor0/workspace0/last-image --set wallpaper.jpg'.
> If the application runs natively, there is no problem and the
> wallpaper is set properly. But when I test the snap package built,
> this is the error thrown:
>
> ERROR LinuxWallpaperChanger:188 - Property
> "/backdrop/screen0/monitor0/workspace0/last-image" does not exist on
> channel "xfce4-desktop". If a new property should be created, use the
> --create option.
>
> I have included xfconf as stage-package and the command xfconf-query
> is found within the snap. Could you give me a hint to solve this problem?
>
> Thank you very much for your time and your help :)

Hey Eloy,

I'm not a xfconf user and so can't answer to you precisly. However, my
guess is that you will need a file (like the dconf one we are using in
GNOME/Unity environment) shared between your user's settings and the
snap writable path.
The desktop launcher is creating a symlink (accessed via the home
interface) between the main user's dconf/user file to path of the snap
writable path, to be able to read the value. The gsettings interfaces
give, on its side, access to the dbus call for this.

I wonder if the unaccessible file/dbus property could trigger this error
fallback in xfconf, and hence, prints that message.

I hope this helps!
Cheers,
Didier

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

Re: Missing environment variables

[Didier Roche]

Le 21/10/2016 à 15:37, Aaron Ogle a écrit :
> Didier:
> 
> Like I said its only happened to a few people, never had it personally. 
> One upgraded to 16.10 and it went away(got impatient  I think).  Is
> there some piece of information I could get from them that might assist
> in the reproduction of the issue?
>

Let's wait for Zygmunt to answer if he can think of any case where a
missing SNAP_* env variable is possible with snap-confine as you think
your users are getting, or if it's a misconception on the debugging on
their side and something else is interfering which would lead to that error.

Cheers,
Didier

> 
> On Fri, Oct 21, 2016, 04:19 Didier Roche <didro...@ubuntu.com
> <mailto:didro...@ubuntu.com>> wrote:
> 
> Le 20/10/2016 à 17:36, Aaron Ogle a écrit :
>> Hey guys,
> 
> Hey Aaron,
> 
>>
>> With our Rocket.Chat server snap. We've had several cases now
>> where users come to us trying to figure out why it hasn't started
>> yet after installing.
>>
>> Our snap:
>> 
>> https://github.com/RocketChat/Rocket.Chat/blob/develop/.snapcraft/stable/snapcraft.yaml
>>
>> rocketchat-mongo:
>> command: env LC_ALL=C mongod --smallfiles --dbpath=$SNAP_COMMON
> 
> This is correct, and the generated wrapper (just checked, downloaded
> it from the store) is doing:
> exec "env" LC_ALL=C mongod --smallfiles --dbpath=$SNAP_COMMON "$@"
> 
> 
>>
>> After explaining to them how to get logs, it will say our mongo
>> install is missing the dbpath.
>>
>> The exact error they are getting:
>> Error parsing command line: the argument for option '--dbpath'
>> should follow immediately after the equal sign
>>
>> This seems like for some reason SNAP_COMMON isn't getting set.
>>
>> I've confirmed that they are using version 2.15 of snap / snapd.
>>
>> I also asked them to drop into the snap: sudo snap run --shell
>> rocketchat-server
>>
>> Then do an: env to see if SNAP_COMMON is even set. From there it
>> does seem to be set.
> Is it the case as well for you? I just tried this and:
> 
> didrocks@tidus:~$ sudo snap run --shell rocketchat-server
> root@tidus:/home/didrocks# env | grep SNAP_COMMON
> SNAP_COMMON=/var/snap/rocketchat-server/common
> 
> So, it's set for me, CCing Zyga who might have an idea if there are
> some cases where snap-confine doesn't set those variables…
> 
> Cheers,
> Didier
> --
> Snapcraft mailing list
> Snapcraft@lists.snapcraft.io <mailto:Snapcraft@lists.snapcraft.io>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snapcraft
> 
> -- 
> 
>   
> *Aaron Ogle* Core Developer
> 
> aaron.o...@rocket.chat <mailto:aaron.o...@rocket.chat>
> 
> @aaron.ogle <https://demo.rocket.chat/direct/aaron.ogle>
> 
> https://rocket.chat
> 


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

Re: Missing environment variables

[Didier Roche]

Le 20/10/2016 à 17:36, Aaron Ogle a écrit :
> Hey guys,

Hey Aaron,
>
> With our Rocket.Chat server snap. We've had several cases now where
> users come to us trying to figure out why it hasn't started yet after
> installing.
>
> Our snap:
> https://github.com/RocketChat/Rocket.Chat/blob/develop/.snapcraft/stable/snapcraft.yaml
>
> rocketchat-mongo:
> command: env LC_ALL=C mongod --smallfiles --dbpath=$SNAP_COMMON

This is correct, and the generated wrapper (just checked, downloaded it
from the store) is doing:
exec "env" LC_ALL=C mongod --smallfiles --dbpath=$SNAP_COMMON "$@"

>
> After explaining to them how to get logs, it will say our mongo
> install is missing the dbpath.
>
> The exact error they are getting:
> Error parsing command line: the argument for option '--dbpath' should
> follow immediately after the equal sign
>
> This seems like for some reason SNAP_COMMON isn't getting set.
>
> I've confirmed that they are using version 2.15 of snap / snapd.
>
> I also asked them to drop into the snap: sudo snap run --shell
> rocketchat-server
>
> Then do an: env to see if SNAP_COMMON is even set. From there it does
> seem to be set.
Is it the case as well for you? I just tried this and:

didrocks@tidus:~$ sudo snap run --shell rocketchat-server
root@tidus:/home/didrocks# env | grep SNAP_COMMON
SNAP_COMMON=/var/snap/rocketchat-server/common

So, it's set for me, CCing Zyga who might have an idea if there are some
cases where snap-confine doesn't set those variables…

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

Re: add-apt-repository and snapcraft cleanbuild?

[Didier Roche]

Le 15/10/2016 à 20:26, Dan Kegel a écrit :
> Hey all,
> Day 3 of using snapcraft, and I've managed to get
> both piglit and a proprietary app snapped and running.
> Snapcraft's learning curve is not too steep, kudos.
>
> Problem: I can't do 'snapcraft cleanbuild' on my proprietary
> apps because they depend on packages in a ppa and/or a
> private apt repo.
> Is there a way to specify add-apt-repository foo
> to be used during snapcraft cleanbuild?
>
Hey Dan,

It's a very valid request, and IIRC, this isn't supported yet. Sergio,
can we tackle during one of the sprint sessions next week?

Cheers,
Didier


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

Re: Official snap button

[Didier Roche]

Le 13/10/2016 à 19:12, Aaron Ogle a écrit :
> Greetings!
Hey Aaron,

>
> I work on the Rocket.Chat project.  We are looking at adding our
> desktop snap as well as our server snap to our website as the
> officially recommended way of installing.
>
> Ideally for the desktop at least we'd like to try and link to the
> Ubuntu Software store directly so they can install quickly.  But for
> the server I realize doing an application link is not very likely,
> especially since they likely wouldn't be visiting on the machine they
> would install the server on.  So we're thinking a button with some
> kind of information pop up.
>
> But we'd really love to see an officially button and design for this
> sort of thing.

I'm adding Thibaut who talked with the design team about some official
logos some times ago.

Indeed, as you are telling, there are 2 use-case:
- link (like the one we had in apt) for installing snaps via Ubuntu
Software using an particular schema (snap:///). Robert, is
there any plan on that?
- logo with instructions "snap install rocket.chat" for servers for
local installation (unsure if there is something planned like,
redirectering to the online store and manage your snap per device there)

Cheers,
Didier

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

Re: Ubuntu Snap Store

[Didier Roche]

Le 13/10/2016 à 01:01, Chris a écrit :
> When browsing snaps at uappexplorer.com I like to middle click and open
> a new tab in Firefox to read about it which allows me to keep my place
> in the original tab. At the Snap Store http://localhost:4200/store this
> isn't possible and if I were to click on a snap to examine it when go
> back to the store page I have to start all over again. Is there a way
> the site can be changed to allow for a middle click to open a new tab?
> I know nothing at all about websites so I don't know how this is done
> on other sites.
>
> Thanks
> Chris
>

Hey Chris,

I'm adding David Barth to the conversation who has taken the huge load
of reshaping snapweb recently :)

Cheers,
Didier


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

Re: Different values of environment variables during build time and run time, eg. JAVA_HOME and PATH

[Didier Roche]

Le 10/10/2016 à 23:49, Jian LUO a écrit :
>
> Hi,
>
> I don't think it counts as cross compiling since Java (at least in my
> case) is cross platform. Just wanted to compile Java with one JDK and
> run with another.
>

Hey,

I'm adding Sergio to the conversation, but I think the easiest path is
to create a custom plugin, inheriting from the base java one, which is
outputting a wrapper scripts with different JAVA env variables.
That way, you keep the current building behavior (build with java on the
machine), but output a script which will point to an armhf java path for
instance and download the correct version and packages version for all
those.
Cross-compilation-like may be needed as Manik suggested as you will need
to pull some packages which are architectures specific.

On how to create a custom plugin, here is some documentation:
http://snapcraft.io/docs/build-snaps/plugins and the playpen has some
example:
https://github.com/ubuntu/snappy-playpen/blob/master/idea/parts/plugins/x-antIntellij.py
I'll let Sergio adding more info as needed :)

Cheers,
Didier


> Jian
>
>
> On Oct 10, 2016 20:05, "Manik Taneja"  > wrote:
>
>
>
> On Mon, Oct 10, 2016 at 6:33 AM, Jian LUO  > wrote:
>
> Hi List,
>
> Is there any formal way in snapcraft  to set environment
> variables separately for build time and run time? The use case
> I'm facing is building a Java snap on amd64 host for armhf target.
>
> Snapcraft does not support cross-compilation. Consider building
> natively on armhf, or using this as reference-
>
> https://github.com/snapcore/snapd/blob/master/docs/cross-build.md
> 
>
> and let us know if you see any issues.
>
> /Manik
>
>
>

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

Re: Question on where snaps are stored

[Didier Roche]

Le 10/10/2016 à 03:20, Chris a écrit :
> On Mon, 2016-10-10 at 10:59 +1000, Jacob Zimmermann wrote:
>> The snap packages themselves are simply copied into
>> /var/lib/snapd/snaps
>> and then mounted into /snap (via /dev/loop).
>>
>> The folders under ~/snap are for configuration files and per-package
>> home directories (for those packages that don't have a home plug and
>> therefore don't access your real home directory). If a given user
>> never
>> launched a certain snapped app, that user wouldn't have the
>> corresponding subdir under ~/snap.
>>
>> Or at least I believe that's how it works, please someone correct me
>> if
>> I'm wrong.
>>
> For instance I just reinstalled this snap - https://uappexplorer.com/ap
> p/hello-snap.muhammad and you're correct, the folder in ~/snap is not
> present until I run 'hello-world'. You're absolutely correct Jacob.

You are right Jacob, this is the intended behavior (only create the data
dir for a particular user for a version of a snap only the first time
this snap application/service is started)

Cheers,
Didier
>
>> On 10/10/16 10:43, Chris wrote:
>>> Firstly I'm just a user of snaps, not a developer however I like
>>> the
>>> way everything is packaged together and their ease of installation,
>>> updating and, if necessary removal. My question is in my ~/snap
>>> folder
>>> certain of the snaps I've installed have subfolders, however some
>>> don't. I was under the impression that all installed snaps are put
>>> there. For example:
>>>
>>> /dev/loop1   97M   97M 0 100% /snap/wallpaperdownloader/4
>>> drwxrwxr-x 3 chris chris 4096 Oct  8 11:36 wallpaperdownloader
>>> /dev/loop2   11M   11M 0 100% /snap/speed-test/2
>>> drwxr-xr-x 4 chris chris 4096 Oct  9 17:32 speed-test
>>> /dev/loop3   62M   62M 0 100% /snap/pencilsheep/5
>>> drwxr-xr-x 4 chris chris 4096 Oct  6 19:09 pencilsheep
>>> /dev/loop4  640K  640K 0 100% /snap/hello-snap/1
>>> (There is no folder for this under ~/snap)
>>> /dev/loop5  107M  107M 0 100% /snap/blender-tpaw/2
>>> drwxr-xr-x 4 chris chris 4096 Oct  6 20:12 blender-tpaw
>>>
>>> I've noticed other snaps I install do the same. They show up in the
>>> /dev/loop* however not as a folder in my ~/snap. Am I missing
>>> something
>>> on how they install?
>>>
>>> Chris
>>>


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

Re: My second snap ;-)

[Didier Roche]

Le 02/10/2016 à 20:48, Robert Park a écrit :
> On Sun, Oct 2, 2016 at 1:43 AM, Loïc Minier  wrote:
>> So just create a matplotlibrc in your $SNAP and you should be good
> Thanks for this analysis. I created an empty matplotlibrc in $PWD and
> then got this instead:
>
> PermissionError: [Errno 13] Permission denied:
> '/home/robru/src/weight/matplotlibrc'
>
>
> Then I added 'home' to my plugs and got this:
>
> RuntimeError: Could not find the matplotlib data files
>
>
> I suppose the next step is to find a real matplotlibrc and use that
> instead of an empty file, however, my app doesn't need 'home' plug at
> all so it's a bit daft to include that for an optional config file
> that matplotlib has the ability to ignore if only it doesn't find one
> that exists. (I've used matplotlib for years and never known or cared
> about this file so whatever the defaults are are fine, I'd rather not
> ship a copy of this file)
>
> Is there a plug to just read /etc? or a sensible way to set all those
> env vars to /dev/null or something?
Hey Robert,

There is no plug to read from /etc on purpose. The goal is your snap to
be relocatable and not relying on anything system-wide, so that it can
run in different context. That's why you need to find a way to embedded
this file and looking for local assets.

If you want to change some env vars, you can create a shell wrapper that
you point your snap into. The shell will then executed your real binary,
once it has settled your environment properly.
Cheers,
Didier

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

Re: pulseaudio plug/slot

[Didier Roche]

Le 26/09/2016 à 06:27, Spencer Parkin a écrit :
> So I did two things to resolve this, I'm not sure if one of them was
> necessary, but...
>
> 1) I changed my app command to "env SDL_AUDIODRIVER=pulseaudio
> desktop-launch $SNAP/bin/[myprog]"
> 2) I changed the confinement from strict to devmode.
>
> It's probably the latter that solved the problem.  If the snapcraft
> developers are interested in testing out why audio doesn't work in
> strict mode, they can use my program as an test case, if they cared to.
Hey Spencer!

Some things you can do to test in strict mode is to tail
/var/log/syslog, running your program, and check the apparmor denial you
probably get when acessing to some files/do some calls.
That would be a great hint for you on debugging this issue, and report a
bug if a new interface tweak is needed!

Remember that you won't be able to publish on the stable channel if your
snap is in devmode.

Cheers,
Didier
>
> On Sun, Sep 25, 2016 at 6:28 PM, Spencer Parkin
> > wrote:
>
> Hi,
>
> I'm adding sound-fx to my snap-app and am running into the common
> problem of "it works in my real system, but not in the confined
> system."  I'm not sure how to trouble-shoot this problem.  I've
> added the "pulseaudio" plug to my snapcraft.yaml file, "snap
> interface" reports that my snap-app is using the "pulseaudio"
> plug, I've tried exporting the "SDL_AUDIODRIVER=pulseaudio"
> environment variable before running my snap to make sure that I'm
> using the appropriate audio back-end.  Hmmm...maybe snap-apps
> can't read environment variables?  Maybe I need to configure some
> env-vars in my snapcraft.yaml file?  I'll try to see how to setup
> the environment (env-vars) for snaps.
>
> Anyhow, I can hear my sound-fx when run on my real system, but not
> under unbuntu core.
>
> Thanks for any ideas you may have,
> --Sp
>
>
>
>

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

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: .desktop files for app-in-snap

[Didier Roche]

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

Re: Handling update-alternatives

[Didier Roche]

Le 05/08/2016 à 12:25, Dan Watkins a écrit :
> On 05/08/16 11:00, John Lenton wrote:
>> On 5 August 2016 at 10:20, Dan Watkins  wrote:
>>> Something I'm snapping tries to run `awk`, which isn't included in the
>>> ubuntu-core snap
>> awk *is* in the ubuntu-core snap. What's happening is bug #1580018:
>> you've used update-alternatives on the host to switch to an awk that
>> is different to the one in core. If you can live with mawk instead of
>> gawk on the host (at least during the build) things will work.
> The snapped program calls /usr/bin/awk at runtime, so I'd presumably
> need mawk to be installed in the host at runtime as well?
>
> (AIUI, /usr/bin/awk is a symlink to /etc/alternatives/awk which gets
> resolved against the host's /etc.  The host's /etc/alternatives/awk
> points at /usr/bin/[gm]awk which is then resolved against the snap's
> view of the world.)

I think that's something which could be fixed again by the request in
https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1583250/ as the
path is hardcoded in your program to redirect to the actual binary in $SNAP.
It seems that Gustavo missed my last ping on "Trying to package angband
as snap" topic (same ML) where this is referenced as well. Maybe I'll be
luckier this time :)

Cheers,
Didier

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

Re: SNAP_USER_COMMON

[Didier Roche]

Le 02/08/2016 à 07:45, Vasilisc a écrit :
>
> test snap raise error
> -
> echo "Writing to $SNAP_USER_COMMON"
> mkdir -p $SNAP_USER_COMMON/platform
> echo "hello common" > $SNAP_USER_COMMON/common.txt
> --
> grep -F audit syslog
>
> Aug  2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400
> audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir"
> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/"
> pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000
> ouid=1000

Hey Vasilisc,

where do you see an error in the above trace? Apparmor says "ALLOWED",
so the mkdir call wasn't blocked and work as expected, or did you notice
not having this directory and file created after those calls?

Didier

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