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

Re: Running xdg-open

[Didier Roche]

Le 03/03/2017 à 15:54, Oliver Grawert a écrit :

hi,
Am Freitag, den 03.03.2017, 15:22 +0100 schrieb Mark Shuttleworth:

On 03/03/17 15:02, Alberto Mardegan wrote:

   Currently the xdg-open tool is provided by the core snap, which
has it
located in its /usr/local/bin/ path.

Will it not always be available at /snap/core/current/usr/local/bin/
?

yes, and it has been there since day one (of the core 16 series at
least).

the fix for handling the PATH in snap-confine is only in snapd 2.23
which has only just made it into xenial-proposed.


Indeed, we only discussed the last point: /usr/local/bin was in the snap 
$PATH in the past, but there has been a regression (I guess due to the 
move to snap-confine or a new core snap) where it's not anymore. 
/usr/local/bin is not in the user's path, nor in the snap $PATH as it 
used to be.


Didier

--
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 17/02/2017 à 15:47, Didier Roche a écrit :

Le 15/02/2017 à 16:33, Simos Xenitellis a écrit :

On Mon, Feb 13, 2017 at 7:13 PM, Didier Roche  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!


For those who followed that thread, with the modifications we discussed 
above (and some more exchanges with Simos on google doc comments), we do 
have that tutorial, focusing on how to snap a python application 
published here: https://tutorials.ubuntu.com/tutorial/snap-python-app


Congrats again Simos, well done, and looking for more :)
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 15/02/2017 à 16:33, Simos Xenitellis a écrit :
> On Mon, Feb 13, 2017 at 7:13 PM, Didier Roche  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

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

[Didier Roche]

Le 10/02/2017 à 17:30, Simos Xenitellis a écrit :
> On Tue, Feb 7, 2017 at 3:54 PM, Didier Roche  wrote:
>> Le 07/02/2017 à 14:05, Simos Xenitellis a écrit :
>>> On Tue, Feb 7, 2017 at 9:13 AM, Didier Roche  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.
>>
> 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 would be interested in any comment you have about the codelab format
and style, and anything you liked/didn't like.

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.

If you have any other to do, do not hesitate to keep us posted!
Cheers,
Didier

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

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

[Didier Roche]

Le 09/02/2017 à 17:12, Kyle Fazzari a écrit :
>
> On 02/09/2017 01:04 AM, Didier Roche wrote:
>> 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…)
> Does https://bugs.launchpad.net/snapd/+bug/1655125 cover this case?
>
>
Rereading today with fresh eyes and brain, yeah, that exactly covers it.
Thanks Kyle for pointing the discussion out!



-- 
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  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: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04

[Didier Roche]

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,
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 à 15:48, Michael Hall a écrit :
> On a related note, does anybody have a suggestion on a lightweight way
> of programmatically modifying configs in .ini, XML or JSON?
>
> I have a couple of use-cases (erlang-based nosql databases) where the
> server updates the the local configuration, so I can't just overwrite
> the whole thing every time. Didier's example will work for a very basic
> key=value config file, but not something more structured, and I'd hate
> to introduce Python, Perl or Java just for this.

That's exactly why I limited for now to simple key=value (and
sourceable) files, while keeping comments and other formats (so .ini
file should work if you scaffold it). I wanted to limit the hook to
shell script to be architecture independant and not adding a dep on some
runtime language.

I don't know if it's sane to have more structured one in dash-compatible
shell. Introducing helpers written in Go means that you have to compile
your (potential arch-all snap like a nodejs webserver) to be arch-dependant.
Thoughts?

Didier
>
>
> Michael Hall
> mhall...@ubuntu.com
>
> On 02/01/2017 08:54 AM, Didier Roche wrote:
>> 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 >> <mailto:o...@ubuntu.com>> 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.
>

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

Re: glGetUniformLocation fails in confinement mode

[Didier Roche]

Le 31/01/2017 à 20:35, Jamie Strandboge a écrit :
> On Tue, 2017-01-31 at 17:04 +0100, Didier Roche wrote:
>> 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:
>>> 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?
>>
> 'classic' is an overloaded term. There is 'classic distro' (eg Ubuntu Desktop)
> and there is 'classic confinement' (ie, 'confinement: classic'). What the 
> above
> denial is about is 'confinement: strict' on classic Ubuntu and my question was
> if the desktop part would work ok if we allowed /usr/share/glib-2.0/schemas/
> with 'confinement: strict'. Based on your comment, it sounds like 'yes', but 
> can
> you confirm?

Ah got it :)
So yes, you can add this path. Note that we'll have the same denials if
others paths (like /usr/loca/share/glib-2.0/schemas) happens to have
some schema files for whatever reason. So, I don't know if you should
add all paths (see below) or just the one logically containing schemas.

Not that the first element of XDG_DATA_DIRS is based on session name
(here, under unity7, we are in the ubuntu session, hence
/usr/share/ubuntu, unity8 would be something like /usr/share/unity8 for
now…), making this more complex.
We don't expect for now (contrary to gconf days), for those to have
schema files.

>
>> 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/snap
>> d/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).
> I'll keep these in mind.
>
>
>

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

Re: Changing default snapcraft behavior and erroring on missing libraries

[Didier Roche]

Le 31/01/2017 à 18:02, Kyle Fazzari a écrit :
>
> On 01/31/2017 08:40 AM, Didier Roche wrote:
>> 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!
> I completely agree.
>
>> * 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.
> Without knowing much about this change, I figure something like this
> would fit into build-attributes, which is per-part at least.
>
>> 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.
> You mean like asking the snap developer to provide an explicit list of
> libraries to error on? Or an explicit list of libraries to pull from the
> system if missing? Anything more fine-grained sounds messy to maintain
> from a snap developer perspective. And this applies to either direction:
> automatically pulling in dependencies from the system, or erroring on
> missing libraries.
>
> Note that, in your example, the consumer app should likely be built with
> the providing snap unpacked into the staging area. This guarantees that
> the consumer is build with the libraries etc. actually contained in the
> providing snap. Using this workflow, snapcraft doesn't do anything
> special with the libs contained in the staging area, even if they're
> filtered out of the final snap via the `prime` keyword. Where "anything
> special" is defined as trying to pull them in from the system, etc. I
> figure the "error on missing libs" would follow the same logic, and not
> error if the libs are satisfied in stage.

Thanks for the answer Kyle!
Indeed, if libs in stage are treated as you described (and the ldd isn't
done in prime/ thus), this would totally work, and avoid having this
manifest libs (that I didn't see each snaps having, but as a fallback,
only the platform snaps to generate it).

I guess it's just a matter of confirming the behavior will be this one
to iremove my second point of concern :)
Cheers,
Didier

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

Re: Changing default snapcraft behavior and erroring on missing libraries

[Didier Roche]

Le 31/01/2017 à 18:33, Sergio Schvezov a écrit :
> On Tue, 31 Jan 2017 17:40:09 +0100, Didier Roche wrote:
>> 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,
>>>>>> 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).
>>> 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.
> The reason is simple, we are leaking libraries by default, like 
> libsupersecrect.so.1 and you won't even know about it.
>
>
I do fully understand the reason, don't worry ;), the first point was
more "this needs to be planned out, synchronised, and well explained to
the world". So, if we go to that breaking changes, please ensure that we
have all content with all points and examples for an easy transition
path. This is how we can allievate some unhappiness to developers about
a breaking changes and make them part of it, while helping them
transitionning.



-- 
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: icon for snap

[Didier Roche]

Le 08/12/2016 à 14:18, Jenny Murphy a écrit :
>
> Hi,

Hey Jenny
>  In the older version of snapcraft (1.1.0) I used the icon keyword in
> the yaml file to specify the icon for my .snap.
> It seems that this is deprecated in snapcraft 2.22.1 :
>
> DEPRECATED: 'icon' defined in snapcraft.yaml. Look at
> https://github.com/snapcore/snapcraft/blob/master/docs/metadata.md#snap-icon
> for more information
>

>From what I know (CCing Sergio to confirm), it's going to make a big
come back :)
It's currently only set by convention,  but if the come back is soon, I
would suggest to wait for it (you can set the icon meanwhile as well on
myapps.developer.ubuntu.com website for your snap).

And yes, unfortunately, the link doesn't point to anything valid. Thanks
for the notice!

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 à 17:32, Gustavo Niemeyer a écrit :
> Okay, so curl is not retrying. That means the problem is specific to
> something snapd is doing with the server.. might still be a problem on
> the client or the server under those particular conditions.
>
> Can I hand you a binary for you to try out?

Sure! I'm happy to give it a test (probably tomorrow by now), while I
have my setup nearby.


>
> On Mon, Dec 5, 2016 at 1:44 PM, Didier Roche  <mailto:didro...@ubuntu.com>> wrote:
>
> 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/
> <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/
> <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
>> 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
>>> 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.ubu

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  <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
>> 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: sha3-384 mismatch

[Didier Roche]

Le 05/12/2016 à 15:38, Gustavo Niemeyer a écrit :
>
>
> On Mon, Dec 5, 2016 at 12:23 PM, Didier Roche  <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/ 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 (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 (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
*  start date: Mon, 30 May 2016 00:00:00 GMT
*  expire date: Wed, 21 Jun 2017 12:00:00 GMT
*  issuer: C=US,O=DigiCert Inc,CN=DigiCert SHA2 Secure Server CA
*  compression: NULL
* ALPN, server did not agree to a protocol
> GET /anon/download-snap/YZ7LshLxDQQIrhAL6DMLub2yTVUA2DIK_15.snap HTTP/1.1
> Host: public.apps.ubuntu.com
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 302 FOUND

I guess that's due to the macaroon exchanged system and I'm not
authorized or something else?
Thanks for helping debugging.

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 à 13:57, Gustavo Niemeyer a écrit :
>
>
> On Mon, Dec 5, 2016 at 5:23 AM, Didier Roche  <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.
>
>
> Neither this thread nor the bug report mentioned that wget/curl worked
> consistently across several tries.

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 :)
>
> 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/. It seems that
curl doesn't complain of any reconnect.

>
> 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).
>
>
> Yes, something is wrong. :)

Right, I have the feeling this is related to some timeout when the
connexion hangs without any data for a very short period of time (as the
failure happens in ~1s or 2s each time after downloading 1 or 2Mb).

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

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  <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
>> 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:
>> -
>>   "task

Re: content sharing from $SNAP_COMMON

[Didier Roche]

Le 02/12/2016 à 19:34, Tim Kuhlman a écrit :
> I have a snap that writes data to $SNAP_COMMON as it runs and I want to make 
> that data available to another
> snap. Unfortunately when I setup the content interface and set the plug side 
> to share
> '/var/snap/snap-name/common/subdir' it fails.
>
> I can share data in $SNAP with the content interface but of course the daemon 
> running in that snap can't
> write there. Am I missing anything? Is there any way to share dynamically 
> created data from one snap with another?
>
> Thanks for the help.

Hey Tim,

I know that was supposed to be supported, but I don't know the
implementation status of this.

Zygmunt, can you shed some lights to us there?
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 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
> 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:
> -
>   "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, if we fail to read from the network, the mismatch
>   

Re: sha3-384 mismatch

[Didier Roche]

Le 02/12/2016 à 17:03, Bret A. Barker a écrit :
> Assuming you were hitting this error with a snapd prior to 2.18, then I think 
> Madper is correct. Prior to 2.18 the order of the parameters for "got %s but 
> expected %" was backward, see:
>   https://github.com/snapcore/snapd/blob/release/2.17/store/store.go#L1155
>
> And fixed in:
>   https://github.com/snapcore/snapd/blob/release/2.18/store/store.go#L1378
>
> -bret

However, as you can see in https://bugs.launchpad.net/bugs/1643893, I
can still reproduce pretty easily here this kind of error (nework
dropping and snapd disconnecting). While curl or wget can cope with the
download as expected.
Cheers,
Didier
>
> On Fri, Dec 02, 2016 at 11:34:49PM +0800, Madper Xie wrote:
>> Hi Pegenaute,
>>
>> In fact I'm meeting this issue every day before I setup a proxy...
>> May I know if you can reproduce it? And if so, did you get different
>> sha3-384 every time?
>>
>> I think it's more like a network issue. The downloading interrupted somehow
>> so you got an incomplete snap pkg file. Which lead to a wrong sha result.
>>
>> BR,
>> Madper
>>
>> On Fri, Dec 2, 2016 at 10:42 PM, James Tait 
>> wrote:
>>
>>> On 2 December 2016 at 13:32, David Barth 
>>> wrote:
>>>
>>>
 On Fri, Dec 2, 2016 at 1:04 PM, Pegenaute Bresme, Xavier <
 xpegenaut...@iam.cat> wrote:

> Hi all,
>
> I just installed the last version [1] and when I execute these lines the
> output is as follows.
>
> I guess the package list is not properly updated/synchronized with the
> package repository. Am I wrong?, how could I fix it ?
>
> --
> root@localhost:~# snap refresh
> All snaps up to date.
> root@localhost:~# snap install snapweb
> error: cannot perform the following tasks:
> - Download snap "snapweb" (25) from channel "stable" (sha3-384 mismatch
> downloading snapweb: got
> ​​
> 8b83c8eb7f7aa306bc342fd1b424fa95ccf379c068c4735085bc81ee6b51
> bb02a23b8c3c2a34f842619d7650b3152787 but expected
> d0e1cd6d578c8eaab13e10dac4acbd7e8f6337da45b291fa7ae0358a2939
> 3059732b29bb61a65d18e693b8e6e8a53b62)
>
 What is surprising is the "expected" signature.
 Snap is downloading the correct armhf build for 0.21.2, ie #25, and the
 SHA3 it obtained corresponds to the published version.

 ​Moreover, that expected hash doesn’t seem to exist in the index​, at
>>> least not for that package. Where has snapd got that value from?
>>> ​
>>> --
>>> James Tait, BSc. | https://launchpad.net/~jamestait/
>>> Software Engineer, Canonical Online Services
>>> Ubuntu - Linux for human beings | www.ubuntu.com
>>>
>>> --
>>> 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

Re: sha3-384 mismatch

[Didier Roche]

Le 02/12/2016 à 13:04, Pegenaute Bresme, Xavier a écrit :
> Hi all,
>
> I just installed the last version [1] and when I execute these lines
> the output is as follows.
>
> I guess the package list is not properly updated/synchronized with the
> package repository. Am I wrong?, how could I fix it ?
>
> --
> root@localhost:~# snap refresh
> All snaps up to date.
> root@localhost:~# snap install snapweb
> error: cannot perform the following tasks:
> - Download snap "snapweb" (25) from channel "stable" (sha3-384
> mismatch downloading snapweb: got
> 8b83c8eb7f7aa306bc342fd1b424fa95ccf379c068c4735085bc81ee6b51bb02a23b8c3c2a34f842619d7650b3152787
> but expected
> d0e1cd6d578c8eaab13e10dac4acbd7e8f6337da45b291fa7ae0358a29393059732b29bb61a65d18e693b8e6e8a53b62)
> --

Hey!

Does it happen with only this snap or other ones as well (with similar
size)? I'm asking as I think it can be similar to
https://bugs.launchpad.net/bugs/1643893

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 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
> mailto:ribal...@gmail.com>> 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
> 
>
>
>
>
> -- 
> Boris Rybalkin
> ribal...@gmail.com 
>
>
>
>
> 

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: Wifi setup problem on Bubblegum 96board ubuntu core snappy

[Didier Roche]

Le 28/11/2016 à 14:19, Zechao Wang a écrit :
> Hi, 
>
> I'm working on Bubblegum 96board platform to support ubuntu snappy core.
> Everything is ok, and usb2eth is works well.
>
> But Wifi can not work, because snappy core use READ-ONLY file system,
> i cannot edit the file 
> /etc/network/interfaces. (wifi device driver is modprobed, and wlan0
> is displayed. )
>
> And the READ-ONLY file system is generated by ubuntu-image tool, it's
> a black box to us.
>
> So, could someone give me some advice how to fix the problem.

Hey Zechao,

I know that there are some tweaking for this to be supported on official
board images. I didn't dive myself into it, but I'm sure Oliver will
explain or point to correct documentation (if any, we should have that,
David, do we, I couldn't find it?) to help you there.

Cheers,
Didier

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

Re: Docker to snappy

[Didier Roche]

Le 28/11/2016 à 13:55, Anca Emanuel a écrit :
>
> Hi.
>

Hey Anca,
>
> It is possible to imagine some tool to transform a docker recipe to
> snappy ?
> Example: https://github.com/discourse/discourse_docker
>

I don't think transforming a dockerfile directly in a snap would work.
Indeed, you are running scripts, don't necessarily have you stack
location in relocatable path and such. I feel this will more error out
and take more time to do the final conversion than being beneficial.

However, as a transition solution, I know we have some docker snap.
Loïc (who worked on snapping docker), is it possible to turn this into a
docker part and embed the image + docker itself, while pointing at the
entry point?
Cheers,
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 25/11/2016 à 18:09, Gustavo Niemeyer a écrit :
> The role of xdg-open itself is already to open the URL with whatever
> tooling is available, so it sounds like we're making the issue more
> complex than it ought to be.
>
> I think we should reimplement xdg-open in terms of snapctl, and have
> snapd itself doing the hand-over to the local xdg-open tool after some
> basic sanity checking on the URL. That way we're not really asking for
> anything from the local system (no dbus service) while remaining
> completely portable.
>
Ah, that was my fist implementation proposal which wasn't accepted at
the time. Happy to see that our view converge now 

Gustavo, do you mind opening a bug for tracking this (and we can
reference people who want to help/contribute to it) as it would be an
easy first snapd contribution for newcomers?

Cheers,
Didier

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

Re: quassel-webserver snap

[Didier Roche]

Le 23/11/2016 à 18:19, Celso Providelo a écrit :
>
>
> On Wed, Nov 23, 2016 at 2:52 PM Leo Arias  > wrote:
>
> Hello,
>
> I know a bunch of people here use quassel. There's a new snap for you:
>
> $ sudo snap install quassel-webserver --edge
> $ sensible-browser https://localhost:64443
>
> The main developer, Joël Charles, has been amazing. For a couple
> of weeks we have been experimenting with his project. First, we
> had to solve an issue with the less-middleware module because it
> wanted to use the install directory instead of SNAP_DATA [1], then
> we got travis to build the snap on every PR [2], and finally he
> agreed to beta test the new enable-ci command of snapcraft that
> Celso is working on.
>
> When I asked about feedback or feature requests, he said: "Not
> that I think of, it just went very smoothly" :_)
>
> Of course, a few seconds later travis broke and we found a bug in
> Celso's PR, just to keep us grounded. It was a quick fix, and now
> every change on master will build and push the snap to edge [3].
>
> I really want to thank Joël because we now have a set of scripts
> tested in real live, that we can just apply to new projects. Also
> Celso because without the enable-ci command, this would never have
> been a smooth experience.
>
>
> Amazing work Leo! Thanks for jumping in so quickly (it's not even
> landed in master) and experimenting with this feature in real
> circumstances.
>
> Until it lands and 2.23 gets SRU-ed in xenial we have to cope with the
> lack of support for local store credentials (`.snapcraft.cfg`). There
> are other less-intrusive alternatives like [1], but once the
> transition is gone `enable-ci` will do the right thing for the
> majority of projects (simple ones).
>
> We hope this initiative along with build.snapcraft.io
>  (down the road) will considerably increase
> the number of revisions released in edge, like we already see for core
> and lxd. That's why we are also working on metrics to capture how
> developers are pushing/releasing their snaps (webui, snapcraft,
> travis, LP, etc). It will be nice to observe these trending as we
> offer easier ways to do CI with snaps.
>
Great work guys!

It would be nice of you guys to blog about your experience for
integrating CI from master and push to the store on a edge channel as a
step by step recipe. Maybe something worth posting on
https://insights.ubuntu.com?

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

Re: snap and ssh

[Didier Roche]

Le 23/11/2016 à 14:14, Vasilisc a écrit :
> Please give me advice. I want use openssh-client in snap package.
> But ssh try read system path
>
> vasilisc@vb:/home/vasilisc$ echo $HOME
> /home/vasilisc/snap/pac/x1
>
> vasilisc@vb:/home/vasilisc$ echo $SNAP_USER_DATA
> /home/vasilisc/snap/pac/x1
>
> vasilisc@vb:/home/vasilisc$ ssh vasilisc@192.168.3.6
> The authenticity of host '192.168.3.6 (192.168.3.6)' can't be
> established.
> ECDSA key fingerprint is
> SHA256:hfV+C1ZOuysKlslXmj1bBKr6OaDKphmMN8KCbwcDlug.
> Are you sure you want to continue connecting (yes/no)? yes
> Failed to add the host to the list of known hosts
> (/home/vasilisc/.ssh/known_hosts).
> Load key "/home/vasilisc/.ssh/id_rsa": Permission denied
>
> How to make the ssh-client use the correct path?
>
Hey Vasilisc,

It seems then that ssh is using hardcoded paths like /home/$USER/.ssh
for looking by default to id_rsa file and not using $HOME. Multiple ways
to get that fixed:
* reading the openssh-client code and fix it to use $HOME (and so, it
will use your snap $HOME)
* use ssh -i (look at the manpage for ssh) to point to an identity file
directly

Cheers,
Didier


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

Re: Problem to connect to ubuntu-app-platform:platform

[Didier Roche]

Le 22/11/2016 à 19:25, Sergio Cazzolato a écrit :
>
>
> On Tue, Nov 22, 2016 at 3:16 PM, Jamie Strandboge  > wrote:
>
> On Tue, 2016-11-22 at 15:06 -0300, Sergio Cazzolato wrote:
> > Hello, I am having troubles to launch my snap due to a missing
> connection
> > to ubuntu-app-platform:platform. No matter if I run "snap
> connect" always I
> > get the same message telling that I need to connect the app with
> > ubuntu-app-platform:platform.
> >
> > I am running this in yakkety. Any idea about this issue?
>
> I ran into this while testing the kde-framework-5 content snap
> with a KDE snap
> today. For me, what was happening is that if you launch your snap
> before you
> connect, then the shared mount namespace is setup without the
> content mount, so
> you need to discard that namespace after you 'snap connect' and
> start the
> application again.
>
> I think if after you snap connect, if you do:
>
> $ sudo /usr/lib/snapd/snap-discard-ns kpi-empty-app
> $ kpi-empty-app
>
> It will work (it would also work after reboot). Obviously, this is
> a bug but I'm
> not sure there is one filed. I think Zygmunt (in CC) is aware of
> the issue.
> Zygmunt, can you comment?
>
>
> It works nice, thanks!

Do you mind opening a bug on this one?
Cheers,
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 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  <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: snap and /etc/termcap

[Didier Roche]

Le 22/11/2016 à 12:27, Vasilisc a écrit :
> Guru, please help me.
> App in snap uses GTK/Perl/VTE (Terminal emulator widget - libvte9)
> In snapcraft.yaml
> ---
>  integration:
>   plugin: nil
>   stage-packages:
>- libvte9
>- libvte-common
>- libvte-2.91-common
> 
> ---
>
> VTE try open system file /etc/termcap and
> 1) if file not exist
> OR
> 2) if apparmor cannot allow access
>
> I got the problem
> "*** VTE ***: Failed to load terminal capabilities from '/etc/termcap
>
> I cannot press functional key, Enter ...
>
> I see in /var/log/syslog
> Nov 22 14:08:15 vb kernel: [16287.624094] audit: type=1400
> audit(1479812895.462:4889): apparmor="DENIED" operation="open"
> profile="snap.pac.pac" name="/etc/termcap" pid=13542 comm="pac"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
>
> I found in source code vte
> http://packages.ubuntu.com/xenial/libvte9  ->
> http://archive.ubuntu.com/ubuntu/pool/main/v/vte/vte_0.28.2.orig.tar.xz
> 
> commit 2b6cff9bfeb5ab13cc519abc45a15d9ad58948c0
> Author: Nalin Dahyabhai 
> Date:   Thu Aug 8 02:26:11 2002 +
> * src/interpret.c: look for $pkgdatadir/termcap/$TERM first, as
> the widget does, before consulting /etc/termcap.
> -
>
> But I do not understand what I should do
>
> In my wrapper script run.sh I tried redefine some variables, but
> problem still alive.
> --
> if [ ! -e "$SNAP_USER_DATA/.terminfo" ]; then
> mkdir -p "$SNAP_USER_DATA/.terminfo"
> export TERMINFO="$SNAP_USER_DATA/.terminfo"
> export TERMINFO_DIRS="$SNAP_USER_DATA/.terminfo"
> tic $SNAP/opt/pac/res/termcap
> echo "export TERMINFO=$SNAP_USER_DATA/.terminfo" >
> "$SNAP_USER_DATA/.bashrc"
> echo "export TERMINFO_DIRS=$SNAP_USER_DATA/.terminfo" >>
> "$SNAP_USER_DATA/.bashrc"
> fi
>
> export TERMINFO="$SNAP_USER_DATA/.terminfo"
> export TERMINFO_DIRS="$SNAP_USER_DATA/.terminfo"
> export TERMCAP="$SNAP/usr/share/terminfo/x/xterm+256color"
> ---
>
> Sorry for my english. Help me please.

Hey Vasilisc,

I don't think you can access to that file (see the denial preventing you
to access to it). This is linked the topic of having a terminal
interface (you will be blocked on other things anyway, like being unable
to launch other snaps, even in devmode.

Looking at
https://bugs.launchpad.net/snappy/+bugs?field.tag=snapd-interface, it
doesn't seem that anybody logged a bug for a terminal interface. Please
file one against this snappy launchpad project and tag it with
"snapd-interface".

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 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
> 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
> 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  <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: Snaps to invoke external processes

[Didier Roche]

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

Re: configure hook

[Didier Roche]

Le 16/11/2016 à 03:05, Enwei Zhang a écrit :
> Hi Didier and folks,
> I didn't find any bug to track the missing hooks support in snapcraft.
> Do we need a new one?

Hey Enwei,

There is one though: https://bugs.launchpad.net/snapcraft/+bug/1586465
Didier


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

Re: Cliqz Snap

[Didier Roche]

Le 14/11/2016 à 15:13, Chris a écrit :
> On Mon, 2016-11-14 at 09:11 +0100, Didier Roche wrote:
>> Le 13/11/2016 à 19:04, Chris a écrit :
>>> On Sun, 2016-11-13 at 09:17 -0600, Chris wrote:
>>>> On Sun, 2016-11-13 at 10:41 +0800, XiaoGuo Liu wrote:
>>>>> Hi Chris,
>>>>>
>>>>> You may find the tips at https://github.com/snapcore/snapd/wiki
>>>>> /Sec
>>>>> ur
>>>>> ity. You may use the command like:
>>>>>
>>>>> $ scmp_sys_resolver 983045
>>>>> set_tls
>>>>> to find out the security violation.
>>>>>
>>>>> Best regards,
>>>>> XiaoGuo
>>>>>
>>>> Thank you XiaoGuo, so in my case I have syscall=272. Running 
>>>>
>>>> chris@localhost:~$ scmp_sys_resolver 272
>>>> unshare
>>>>
>>>> I've installed snappy-debug but can't seem to get any kind of
>>>> output
>>>> when run. Maybe I'm using the wrong commands?
>>>>
>>> Replying to my own post. I wasn't running the snap whenever I ran
>>>
>>> sudo snappy-debug.security scanlog --all-entries cliqz
>>>
>>> Once I executed the snap from the menu with the above running I got
>>>
>>> chris@localhost:~$ sudo snappy-debug.security scanlog --all-entries
>>> cliqz
>>> kernel.printk_ratelimit = 0
>>> = Seccomp =
>>> Time: Nov 13 11:49:59
>>> Log: auid=1000 uid=1000 gid=1000 ses=3 pid=29796 comm="cliqz"
>>> exe="/snap/cliqz/6/opt/CLIQZ/CLIQZ" sig=31 arch=c03e
>>> 272(unshare)
>>> compat=0 ip=0x7ffacd899c19 code=0x0
>>> Syscall: unshare
>>>
>>> So, now it seems as there is a seccomp violation stopping the snap
>>> from
>>> running, at least that's what it appears to me to be. Where would I
>>> go
>>> from here? Contact the snap author?
>> Indeed, the snap author didn't set the confinement rules on his app.
>> The
>> snap should then be in devmode (but not published in the stable
>> channel), to not create user frustration executing something which
>> fails.
>>
>> Do you mind contacting upstream so that they work on confinement?
>> Thanks!
>> Didier
>>
> Hello Didier, do you mean to contact the author?
Hey Chris, indeed,

>  I did go to the
> support page and asked about the snap package not working and I
> received the below in reply, not being able to read German I 'think' it
> just points me to a link for support and their blog.
>
> Hallo Cpollock,
>
> deine Anfrage hat den CLIQZ Support erreicht. Unser Ziel ist es, dir so
> schnell wie möglich zu antworten. Das wird nicht allzu lange dauern,
> versprochen.
>
> In der Zwischenzeit kannst du mal in unsere FAQs schauen: https://cliqz
> .com/support
>
> Und kennst du schon unseren Blog? Schau mal hier: https://cliqz.com/abo
> utus/blog
>
> Danke für deine Geduld. Wir melden uns bald wieder bei dir!
>
> Der CLIQZ Support
>
> The support link takes me to the same place where I had said the snap
> doesn't work, I didn't see anything in the blog link about the snap
> package.

Yeah, my little remaining knowledge of German classes leads to the same
conclusion than yours.
Any native speaker here to help us by any chance? :)

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 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"  <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 à 12:19, Stephen Stewart a écrit :
> On Mon, Nov 14, 2016 at 10:34 AM Didier Roche  <mailto:didro...@ubuntu.com>> wrote:
>
> 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,
>
>
> Hi Didier,
>  
>
>
> 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?
>
>
> Fair enough, but ...
>  
>
> >
> > 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).
>
>
> ... sure, but both parts need `lib/constants.js`; I can't exclude
> lib/constants for one part and hope that my snap will work, can I?
>
> I feel like I'm missing something really obvious here :(

Ah, in that case, it means that you need to install both nodejs and yarn
(I don't know the latter) in different install path, and have wrappers
so that they know how to find each other IMHO.

You can use organize to rename a directory in the stage and prime
directory, that would be a good way to install in different path with
the dump plugin.
However, you will need to provide those wrappers scripts/glue code so
that one can know about the other.

Cheers,
Didier
-- 
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: Provisional snap for DUB (D language package/build manager)

[Didier Roche]

Le 13/11/2016 à 18:09, Joseph Rushton Wakeling a écrit :
> On 13/11/16 10:11, Joseph Rushton Wakeling wrote:
>> On 03/11/16 11:49, Joseph Rushton Wakeling wrote:
>>> On 01/11/16 22:43, Sergio Schvezov wrote:
 If this is the problem and you can patch the software then removing
 the chown
 could work, I am CCing Jamie for other ideas that could come up.
>>
>> Looking at the dub source code, it seems that the actual build --
>> i.e. the
>> compiler call that generates the binary -- writes to a temporary
>> .dub/ directory
>> created in the project tree, and the generated files are then copied
>> to the
>> user-perceived output location, with chown and chmod calls to
>> preserve the
>> permissions:
>> https://github.com/dlang/dub/blob/v1.0.0/source/dub/internal/vibecompat/core/file.d#L126-L128
>>
>
> OK, upstream accepted my patch to deal with this.  The current state
> of my external snap package, described here:
> https://github.com/WebDrake/dub.snap/pull/1
>
> ... now works with some essential basics:
>
>   * it can compile a program that has no dependencies;
>
>   * it can download dub packages from https://code.dlang.org/ and
> incorporate
> them into a project.
>
> The major TODOs would be:
>
>   * ensure the dub plugin downloads an upstream dub rather than
> relying on
> ubuntu packages;
>
>   * separate the D compiler from the snap, allowing dub to use any
> compiler
> available on the host system (whether installed as a system
> package or
> as a snap package);
>
>   * find a way for it to access system libraries so as to build dub
> packages
> that have these as dependencies.
>
> The latter two I presume come down to the known issue about how to
> make host resources available to a snap in a safe manner, but I'd be
> interested in any thoughts on whether the D compiler issue might be
> achieved any more easily.
>

I guess for now, the compiler part (and access to system libraries)
should be part of an interface. I'm CCing Jamie to see if he has any
thoughts on that.

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

Re: Cliqz Snap

[Didier Roche]

Le 13/11/2016 à 19:04, Chris a écrit :
> On Sun, 2016-11-13 at 09:17 -0600, Chris wrote:
>> On Sun, 2016-11-13 at 10:41 +0800, XiaoGuo Liu wrote:
>>> Hi Chris,
>>>
>>> You may find the tips at https://github.com/snapcore/snapd/wiki/Sec
>>> ur
>>> ity. You may use the command like:
>>>
>>> $ scmp_sys_resolver 983045
>>> set_tls
>>> to find out the security violation.
>>>
>>> Best regards,
>>> XiaoGuo
>>>
>> Thank you XiaoGuo, so in my case I have syscall=272. Running 
>>
>> chris@localhost:~$ scmp_sys_resolver 272
>> unshare
>>
>> I've installed snappy-debug but can't seem to get any kind of output
>> when run. Maybe I'm using the wrong commands?
>>
> Replying to my own post. I wasn't running the snap whenever I ran
>
> sudo snappy-debug.security scanlog --all-entries cliqz
>
> Once I executed the snap from the menu with the above running I got
>
> chris@localhost:~$ sudo snappy-debug.security scanlog --all-entries
> cliqz
> kernel.printk_ratelimit = 0
> = Seccomp =
> Time: Nov 13 11:49:59
> Log: auid=1000 uid=1000 gid=1000 ses=3 pid=29796 comm="cliqz"
> exe="/snap/cliqz/6/opt/CLIQZ/CLIQZ" sig=31 arch=c03e 272(unshare)
> compat=0 ip=0x7ffacd899c19 code=0x0
> Syscall: unshare
>
> So, now it seems as there is a seccomp violation stopping the snap from
> running, at least that's what it appears to me to be. Where would I go
> from here? Contact the snap author?

Indeed, the snap author didn't set the confinement rules on his app. The
snap should then be in devmode (but not published in the stable
channel), to not create user frustration executing something which fails.

Do you mind contacting upstream so that they work on confinement?
Thanks!
Didier

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

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: crontab like snaps or interfaces

[Didier Roche]

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.


-- 
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"  <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" > <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"  <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: configure hook

[Didier Roche]

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
>
> 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 yesterday about this.

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 09/11/2016 à 07:44, Enwei Zhang a écrit :
> Hi Didier,
> Sorry to cut in.
> Is "hooks" working now in snapcraft?
> I encountered error:
> I used below in snapcraft.yaml:
>
> hooks: # Top-level YAML attribute, parallel to `apps`
> upgrade: # Hook name, corresponds to executable name
> plugs: [network] # Or any other plugs required by this hook
>
> enwei@XPS-13-9350:~/work/snap/simple-daemon$ snapcraft
> Issues while validating snapcraft.yaml: Additional properties are not
> allowed ('hooks' was unexpected)
> enwei@XPS-13-9350:~/work/snap/simple-daemon$ snapcraft --version
> 2.20

No, right now, they are only implemented in snapd.
You need to place the correct file in the meta/hooks/ folder (if you are
using snapcraft, do this in the prime/ directory, before "snapcraft snap
prime/").

There is an example available at
https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/basic-hooks/meta/hooks.

Hope that helps!
Didier
>
> Thanks.
>
> Br
> Enwei
>
>
>
> On Tue, Nov 8, 2016 at 6:28 PM, Didier Roche  <mailto:didro...@ubuntu.com>> wrote:
>
> Le 08/11/2016 à 04:52, Kyle Fazzari a écrit :
> >
> > On Nov 6, 2016 21:51, "Didier Roche"  <mailto:didro...@ubuntu.com>
> > <mailto:didro...@ubuntu.com <mailto:didro...@ubuntu.com>>> wrote:
> >>
> >> Le 06/11/2016 à 00:22, Boris Rybalkin a écrit :
> >> >
> >> > Hello,
> >> >
> >>
> >> Hey Boris,
> >> >
> >> > I want to generate my config on snap install using snap location
> >> > variables.
> >> >
> >> > From the docs configure hook is only triggered when 'snap set' is
> >> > called. Will configure also be called on install and upgrade?
> >> >
> >> I didn't try it myself yet, but from what I heard yeah, they
> will be run
> >> at that time. Kyle can confirm (and if so, we'll update to the
> >> documentation to reflect that).
> >
> > When I wrote it (and the docs) it was only run with `snap set`. I
> > believe it's been modified since then to run upon initial install as
> > well as upgrade; indeed Gustavo mentioned that it should serve as an
> > install and an upgrade hook. The docs weren't updated with this
> change,
> > it seems. That recommendation should also be documented.
> >
> > Kyle
> >
>
> FYI, opened
> https://github.com/ubuntudesign/snapcraft.io/issues/216
> <https://github.com/ubuntudesign/snapcraft.io/issues/216>
> about it (after confirming manually this new behavior).
>
> So, to answer on the initial reply: yes, the hooks are ran on install
> and upgrade.
>
> 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: configure hook

[Didier Roche]

Le 08/11/2016 à 04:52, Kyle Fazzari a écrit :
> 
> On Nov 6, 2016 21:51, "Didier Roche"  <mailto:didro...@ubuntu.com>> wrote:
>>
>> Le 06/11/2016 à 00:22, Boris Rybalkin a écrit :
>> >
>> > Hello,
>> >
>>
>> Hey Boris,
>> >
>> > I want to generate my config on snap install using snap location
>> > variables.
>> >
>> > From the docs configure hook is only triggered when 'snap set' is
>> > called. Will configure also be called on install and upgrade?
>> >
>> I didn't try it myself yet, but from what I heard yeah, they will be run
>> at that time. Kyle can confirm (and if so, we'll update to the
>> documentation to reflect that).
> 
> When I wrote it (and the docs) it was only run with `snap set`. I
> believe it's been modified since then to run upon initial install as
> well as upgrade; indeed Gustavo mentioned that it should serve as an
> install and an upgrade hook. The docs weren't updated with this change,
> it seems. That recommendation should also be documented.
> 
> Kyle
> 

FYI, opened https://github.com/ubuntudesign/snapcraft.io/issues/216
about it (after confirming manually this new behavior).

So, to answer on the initial reply: yes, the hooks are ran on install
and upgrade.

Cheers,
Didier

-- 
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
> mailto:xiaoguo@canonical.com>> 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  <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"
>> mailto:honeycuttaar...@gmail.com>> 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
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 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: configure hook

[Didier Roche]

Le 06/11/2016 à 00:22, Boris Rybalkin a écrit :
>
> Hello,
>

Hey Boris,
>
> I want to generate my config on snap install using snap location
> variables.
>
> From the docs configure hook is only triggered when 'snap set' is
> called. Will configure also be called on install and upgrade?
>
I didn't try it myself yet, but from what I heard yeah, they will be run
at that time. Kyle can confirm (and if so, we'll update to the
documentation to reflect that).

Cheers,
Didier

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

Re: xterm

[Didier Roche]

Le 01/11/2016 à 14:55, Joe Coates a écrit :
>
> The main app in my snapped feature wants to initiate some xterm
> sessions and run a different local snap command in each.  However, I
> can’t manage to get a terminal emulator of any sort to behave
> correctly within the snap (if they startup at all, then they cannot
> receive keystroke input).  I have tried xterm, rxvt, and the vte-based
> sakura as staged-packages.   Plugging to the X11 slot interface (and
> even Unity7) seems to have no effect.They build OK but fail at
> runtime with similar failures :
>
>  
>
> >/snap/exfab/x1/usr/bin/sakura: error while loading shared libraries:
> libgtk-3.so.0: cannot open shared object file: No such file or directory
>
> >/snap/exfab/x1/usr/bin/rxvt-xterm: error while loading shared
> libraries: libX11.so.6: cannot open shared object file: No such file
> or directory
>
> >/snap/exfab/x1/usr/bin/xterm: error while loading shared libraries:
> libXft.so.2: cannot open shared object file: No such file or directory
>
>  
>
> My target machine is a Xenial VM in VirtualBox . . .
>
> Does anyone do terminal emulation from a snap ?
>

This is still quite hard to achieve nowdays (I did try myself half a
year ago with byobu/tmux), due to a couple of issues:
- you need for most of them to have some /dev/pts access, and no
interfaces as of today exists to mediate this.
- you can't execute a snap command from another snap.

I remember that we discussed a couple of months ago about a "shell" or
similar interface to get that done. I'm ccing Gustavo to see if he has
more news on those to share with us.

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 01/11/2016 à 21:18, Eloy García (PC Actual) a écrit :
> Hi Didier, hi all.
> 
> I've been trying to accomplish this mission but I miss something (my bet
> is that I need an interface similar to gsettings but it doesn't exist
> something like this).
> 
> 1.- I have successfully created a symlink from
> /home/$USER/.config/xfce4/xfconf/xfce-perchannel-xml inside the snap
> directory and all the XML files in which the configuration is stored are
> accessible for the application.
> 
> 2.- I have defined, as stage package, xfconf, the tool to write
> configurations directly into those XML files.
> 
> 3.- But when I execute ' xfconf-query --channel xfce4-desktop --property
> /backdrop/screen0/monitor0/workspace0/last-image --set wallpaper.jpg'
> inside my application, I still receive '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.' and xfce-destop.xml (the XML which has the
> configuration for the background wallpaper) is not modified at all.
> 
> Maybe is needed an interface similar to gsettings? If this is the case,
> can I program something like that?

Indeed, you probably need some interfaces similar to gsettings. You ned
first to understand how xfconf works internally (which dbus interfaces,
which files paths it's using and such?)

Then, once this step is done, you can start developping your own
interface in snapd.
http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
is a good introductionary reference for this.

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 à 19:00, Aaron Ogle a écrit :
> On Thu, Oct 27, 2016 at 11:56 AM Kyle Fazzari
> mailto:kyle.fazz...@canonical.com>> wrote:
>
>
> So are you storing this database in $SNAP_COMMON? Because
> $SNAP_DATA would do this for you, no?
>
>
> Correct we are doing in $SNAP_COMMON.  Is $SNAP_DATA using CoW?  Or is
> it going to be a full copy.  From what I could see it was a full
> copy.  This would quickly add up.  Not to mention you loose all of our
> messages sent when you roll back.


I would suggest to use $SNAP_DATA. Once we have garbage collection
enabled on snapd, you will have approx. 2 copies at most of your data
(the old version and the current one). I guess this is a reasonable
tradeoff to ensure you can always revert safely.

Imagine the case if a new version corrupts your data. You will not have
any way to retrieve them back if you store in $SNAP_COMMON, whichever
downgrade scripts you are writing…

So, I would argue to try $SNAP_DATA first, and then only revisit to move
to $SNAP_COMMON if you see that doesn't suit you.
Making sense?
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  <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  <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 > <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 >> <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
>&

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  <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 > <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: Un-revert a snap

[Didier Roche]

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  <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
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: Un-revert a snap

[Didier Roche]

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

Re: "path must be relative" in filesets is holdover convention from debian packaging, causes grief

[Didier Roche]

Le 25/10/2016 à 08:46, Dan Kegel a écrit :
> On Mon, Oct 24, 2016 at 11:21 PM, Didier Roche  wrote:
>> You have the parts//install directory, which is your target
>> for your parts installation. All files are there (and DESTDIR is set to
>> there). It sounds then normal to not rely on absolute path, but only
>> relative one to reference those, and not $ANYFILE_FROM_YOUR_HOST_SYSTEM,
>> doesn't it?
> 
> Yes.  I'm asking for syntactic sugar.  Please ignore the leading slash
> rather than throwing an error.  This will make life easier for users
> generating snapcraft.yaml, who otherwise have to script removing that slash.
> 
>> Maybe that's my twisted debian packager mindset, but do you mind
>> providing a real example? If an upstream project ignores DESTDIR and
>> install directly on system path, this is quite ackward and should be
>> fixed in other way.
> 
> I'm not talking about supporting that.  I'm talking about doing
> everything right *except* for not having to strip the leading
> slash off those paths.
> 
> Another way of looking at is is, the path should be evaluated
> in the confined context rather than the outer context.
> Does that make more sense?
> 
> Grouchily yours,
> random user tired of doing sed -e 's,^/,,' all over the place.
> 


Ah ok, that makes sense. I think that would be possible, ignoring
leading "/". Not sure it's a feature we should advertize, but I don't
see any kind of side-effect to it, as long as we requires all files to
be in known snapcraft dirs.

Sergio, Kyle, wdyt?


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

Re: Configuring apparmor / seccomp for a snap to allow sendmsg and mkfifo?

[Didier Roche]

Le 24/10/2016 à 21:52, Dan Kegel a écrit :
> I'm trying to snap a largish package; works fine in devmode,
> but as the app likes to use unix sockets and fifos, it fails in
> confined mode with
>
> $ sudo /snap/bin/snappy-debug.security scanlog
> = AppArmor =
> Time: Oct 24 11:41:09
> Log: apparmor="DENIED" operation="sendmsg" profile="snap.foo" pid=8536
> comm="foo" family="unix" sock_type="dgram" protocol=0
> requested_mask="send" denied_mask="send" addr=none
> peer_addr="@6E7669646961356165373434376600"
> peer="unconfined"
>
> = Seccomp =
> Time: Oct 24 11:41:09
> Log: auid=4294967295 uid=1001 gid=1001 ses=4294967295 pid=8536
> comm="foo" exe="/snap/foo/x7/bin/foo" sig=31 arch=c03e 133(mknod)
> compat=0 ip=0x7f17f6fb542d code=0x0
> Syscall: mknod
>
> Any suggestions (other than 'don't do that')?
Unix sockets are definitively possible. I'm using sockets based on unix
files for some of my project and write them to $SNAP_DATA (for daemons,
the daemon creating the socket) and it works well. You may want to try this?

On mknod, I don't know if we have any plan for enabling this in some
ways. CCing Jamie for this.

> I imagine there's a way to configure both apparmor and seccomp for
> snaps, but haven't found it yet.
> https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement
> has some clues
> http://askubuntu.com/questions/796809/add-custom-apparmor-rules-to-snap
> seems on topic
> Should I be looking at the snapd source?  (I see there's an apparmor
> interface, but maybe that's internal only...)
>
I don't think we want snaps to ship their own configuration. It's better
to collaborate on a snapd interface that can be reused between snaps,
rather than letting any snap defining its own confinement rules (or said
differently, the confinment may be useless if we allow this).

Cheers,
Didier


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

Re: "path must be relative" in filesets is holdover convention from debian packaging, causes grief

[Didier Roche]

Le 24/10/2016 à 17:49, Dan Kegel a écrit :
> Hi!
>
> When generating snapcraft.yaml from e.g. CMakeLists.txt for a large project,
> I wanted to exclude some dev files which live at a
> configuration-dependent location, e.g.
>
> filesets:
>   dev:
> - -@FOO@/include
> - -@FOO@/lib/*.a
> - -usr/share/doc
>
> Can you spot the usability problem?  This fails with the error
>
> path "/opt/foo/include" must be relative
>
> Please, for the love of $deity, don't make the same usability mistake
> debian packaging did.
> Don't make authors add special cases in their script to strip off the
> leading slash of paths.
>
> That is all.  Thank you.

Hey Dan,

Unsure I'm following you there.
You have the parts//install directory, which is your target
for your parts installation. All files are there (and DESTDIR is set to
there). It sounds then normal to not rely on absolute path, but only
relative one to reference those, and not $ANYFILE_FROM_YOUR_HOST_SYSTEM,
doesn't it?


Maybe that's my twisted debian packager mindset, but do you mind
providing a real example? If an upstream project ignores DESTDIR and
install directly on system path, this is quite ackward and should be
fixed in other way.
Thoughts?
Didier

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

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  <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?
>>
&g

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