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

I think the intent is that a snap has a config schema which can be used for both validation and self-documentation of config items. Doing that tastefully is worth the wait :) Mark signature.asc Description: OpenPGP digital signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io

Re: chroot into a snap

On Feb 9, 2017 10:21 PM, "Simon Fels" wrote: On 09.02.2017 17:08, Thomas Voß wrote: > On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  > wrote: >> Because this will use nextcloud documents, and they are internal to >> nextcloud

Re: chroot into a snap

On 09.02.2017 17:08, Thomas Voß wrote: > On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  > wrote: >> Because this will use nextcloud documents, and they are internal to >> nextcloud snap >> > > In that case, content-sharing would help, yes. Is that always

Re: a little script: snapdiff

On 10.02.2017 01:44, Michael Hudson-Doyle wrote: > Very much inspired by debdiff, I wrote a little script to compare two > snaps. It looks like this: > > (master)mwhudson@aeglos:/opt/opensource/snaps/go$ snapdiff > go-17-mwhudson_1.snap go-17-mwhudson_2.snap > Only in second snap,

Re: IPC between snaps

On 09.02.2017 11:36, Roberto Mier Escandón  wrote: > Thanks Löic. > I'll take a look > > On 09/02/17 11:18, Loïc Minier wrote: >> Hi, >> >> Yes, this is typically how you allow a snap to talk to snapd or docker >> daemon or lxd. You need a new interface to grant access to this socket >> path. If

Re: 'organize' affects 'stage-packages'

I think you may point a folder name there in the organize something like: organize: 'usr/share/ubuntu-html5-ui-toolkit/': www/ubuntu-html5-ui-toolkit Basically, the folder "usr/share/ubuntu-html5-ui-toolkit" will be moved to directory "www/ubuntu-html5-ui-toolkit" in the snap. Best

'organize' affects 'stage-packages'

I just discovered that a part with: organize: '*': opt/ stage-packages: - some-great-package moves the contents of the stage-packages into opt in addition to the output of the plugin. Is this the intended behavior, and if so, is there a way to move only the plugin output into a subfolder?

a little script: snapdiff

Very much inspired by debdiff, I wrote a little script to compare two snaps. It looks like this: (master)mwhudson@aeglos:/opt/opensource/snaps/go$ snapdiff go-17-mwhudson_1.snap go-17-mwhudson_2.snap Only in second snap, go-17-mwhudson_2.snap: -rw-rw-r-- root/root 839 2017-02-03

Re: Package too old for cleanbuild

Hello, We have a few cleanbuild bugs open: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=cleanbuild Some of them are related to what you are asking, so I would appreciate if you go in there and add your comments with the ideal solution for your use case. If you don't find any bug that

Re: launchpad snap recipe fails with classic confinement

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

Re: Semaphores and access to /dev/shm

On 09/02/2017 02:22, Jamie Strandboge wrote: > I confirmed this works fine under confinement (return code checking omitted > for > clarity): > >char *name = "/dev/shm/sem.snap.foo.bar"; >open(name, O_CREAT | O_EXCL | O_RDRW, S_IRUSR | S_IWUSR); >sem_open("snap.foo.bar", 0); > Argh,

Re: Package too old for cleanbuild

On 02/09/2017 12:02 PM, Alan Pope wrote: > Hi Kyle (and Sergio!) > > On 9 February 2017 at 18:45, Kyle Fazzari wrote: >> If you find yourself using cleanbuild a lot (it makes a new ephemeral >> container, builds, then destroys the container), you might find some >>

Re: Package too old for cleanbuild

Hi Kyle (and Sergio!) On 9 February 2017 at 18:45, Kyle Fazzari wrote: > If you find yourself using cleanbuild a lot (it makes a new ephemeral > container, builds, then destroys the container), you might find some > workflow improvements by simply developing the snap

Re: launchpad snap recipe fails with classic confinement

El jueves, 9 de febrero de 2017 16h'23:34 ART, Colin Watson escribió: On Thu, Feb 09, 2017 at 02:09:49PM -0300, Sergio Schvezov wrote: El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche escribió: >Is building a snap with *classic*

Re: Spread linode backend

Hey Max, as a quick test, would you mind trying to set TAR_OPTIONS='--format=posix' in the environment you run spread in? Thanks, Thomas On Thu, Feb 9, 2017 at 6:19 PM, Max Brustkern wrote: > I'm attempting to use the spread linode backend with this system

Re: launchpad snap recipe fails with classic confinement

On Thu, Feb 09, 2017 at 02:09:49PM -0300, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche > escribió: > >Is building a snap with *classic* confinement from a recipe supported on > >lp? > > > >I created a snap recipe for my imported

Re: launchpad snap recipe fails with classic confinement

On 09/02/17 18:09, Sergio Schvezov wrote: El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche escribió: Is building a snap with *classic* confinement from a recipe supported on lp? I created a snap recipe for my imported git branch and tried to build, and the

Re: Package too old for cleanbuild

On 02/05/2017 11:46 PM, Michi Henning wrote: >> Would it make sense to extend the snapcraft yaml to let the developer >> specify where build-packages and stage-packages should be taken from? >> >> It would be nice to be able to run a "snapcraft cleanbuild" from zesty >> while effectively using

Spread linode backend

I'm attempting to use the spread linode backend with this system stanza, as described in the documentation: backends: linode: key: $(HOST:echo $LINODE_API_KEY) systems: - 'ubuntu-16.04' I'm getting this error: 2017/02/09 11:00:18 Error packing project content for

Re: launchpad snap recipe fails with classic confinement

El jueves, 9 de febrero de 2017 13h'40:03 ART, knitzsche escribió: Is building a snap with *classic* confinement from a recipe supported on lp? I created a snap recipe for my imported git branch and tried to build, and the builds fail with: Even though LP will

Re: [Dragonboard410c] Ubuntu OS Build Issues, and Support

On Thu, Feb 09, 2017 at 06:13:15AM +, Sunny Bhayani wrote: > > > the work is going on here: > > > > https://github.com/snapcore/snapcraft/pull/1115 > > Is there a way, that we can come to know about an official fix, apart from the > above link that you mentioned. If you don't want to wait

launchpad snap recipe fails with classic confinement

Is building a snap with *classic* confinement from a recipe supported on lp? I created a snap recipe for my imported git branch and tried to build, and the builds fail with: Preparing to pull env classic confinement requires the core snap to be installed. Install it by running `snap install

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

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

Re: chroot into a snap

On Thu, Feb 9, 2017 at 2:38 PM, Roberto Mier Escandón  wrote: > Because this will use nextcloud documents, and they are internal to > nextcloud snap > In that case, content-sharing would help, yes. > On 09/02/17 14:33, Thomas Voß wrote: >> I think you want: >>

Re: chroot into a snap

Because this will use nextcloud documents, and they are internal to nextcloud snap On 09/02/17 14:33, Thomas Voß wrote: > I think you want: > > https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go > > Why would you need to access documents in other snaps? > > On Thu, Feb

Re: chroot into a snap

awsome Thomas!. You got it!. Having the doc in any snap path can be rendered. So, that answers the point of chroot working ok, but now there is another problem: How can I access documents in other snaps? Can content interface solve this? (I'll try) On 09/02/17 14:04, Thomas Voß wrote: > On Thu,

Re: chroot into a snap

On Thu, Feb 9, 2017 at 11:35 AM, Roberto Mier Escandón  wrote: > > Hey Thomas, > > You can find the snap at [1] > Atttached are traces for: > > Devmode: > - service.txt are the logs of the service > - syslog.txt and snappy-debug.security.txt are the logs to see

Re: dlopen cannot load shared library

Thanks, The problem was, indeed, a fail in the path to a library. Your answers were key to solve it. The dlopen() now works ok. On 03/02/17 13:59, Mark Shuttleworth wrote: > On 03/02/17 12:41, Loïc Minier wrote: >> In classic mode, you see libraries from your classic Ubuntu system >> including

Re: IPC between snaps

Thanks Löic. I'll take a look On 09/02/17 11:18, Loïc Minier wrote: > Hi, > > Yes, this is typically how you allow a snap to talk to snapd or docker > daemon or lxd. You need a new interface to grant access to this socket > path. If you'd like some examples or look at existing ones, grep for

Re: IPC between snaps

Hi, Yes, this is typically how you allow a snap to talk to snapd or docker daemon or lxd. You need a new interface to grant access to this socket path. If you'd like some examples or look at existing ones, grep for socket under github.com/snapcore/snapd/interfaces. Cheers, - Loïc On Thu, Feb 9,

Re: chroot into a snap

Hey Roberto, On Wed, Feb 8, 2017 at 4:54 PM, Roberto Mier Escandón  wrote: > Hey engineers, > > I need some ideas to solve this: I'm trying to snap collaboraoffice > online but that's not being easy at all. FYI: this is a kind of Google > Drive stuff so that when

IPC between snaps

Hi, Is there any way to communicate processes in different snaps using pipes?. How can it be done in this or other way? Cheers. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft

Re: snapd available in Trusty Tahr

Hi Thomas, Thanks. I have reported a bug at https://bugs.launchpad.net/snapd/+bug/1663174 Best regards, XiaoGuo On Thu, Feb 9, 2017 at 5:11 PM, Thomas Voß wrote: > > > On Thu, Feb 9, 2017 at 10:09 AM, XiaoGuo Liu > wrote: > >> Hi Jamie,

Re: snapd available in Trusty Tahr

On Thu, Feb 9, 2017 at 10:09 AM, XiaoGuo Liu wrote: > Hi Jamie, > > For my case, right now, after I log out and login again (in fact, I > rebooted my machine). the /snap/bin path is still not added. Everything is > still the same. I cannot execute the "hello-word" snap

Re: ubuntu-app-platform updated to Qt 5.6.2

On Thu, Feb 9, 2017 at 7:36 AM, XiaoGuo Liu wrote: > Hi James, > > Thanks for your help. Yes, you are right! Now I do a new version of it, > and I used a wrapper to launch it. This time, the app can be launched > successfully, but still there is an error like: > > **

Re: snapd available in Trusty Tahr

Hi Jamie, For my case, right now, after I log out and login again (in fact, I rebooted my machine). the /snap/bin path is still not added. Everything is still the same. I cannot execute the "hello-word" snap app. I do not know where I did wrongly. Thanks & bestt regards, XiaoGuo On Thu, Feb 9,

Re: snapd available in Trusty Tahr

The simplest way is to log out and back in again. We are looking at other options on how to make this easier. Regards, Jamie. > On 9 Feb 2017, at 09:02, XiaoGuo Liu wrote: > > Hi Thomas, > > So, an end user needs to manually add the path, right? It is not a little

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

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

Re: snapd available in Trusty Tahr

Hi Thomas, So, an end user needs to manually add the path, right? It is not a little bit straightforward though. I think it would be good to come with detailed instructions. Thanks & best regards, XiaoGuo On Thu, Feb 9, 2017 at 4:39 PM, Thomas Voß wrote: > > > On