Re: One snap to connect them all (or: the plugin story)
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
Re: chroot into a snap
I tried content sharing and works fine in this case, Nextcloud exposing a slot to its documents folder. I think I saw somewhere this is only valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the same time. Is that correct? Can removable-media improve this? On 10/02/17 08:05, Kyle Fazzari wrote: > 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 snap >>> >> >> In that case, content-sharing would help, yes. > > Is that always the case? I thought we talked a while back about using > the removable-media interface also as an option in the nextcloud snap to > allow users placing their data on an external hardware driver or > different partition. Not sure if this was ever implemented. > > > Simon is correct, this is indeed supported. > > > -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: chroot into a snap
On 10.02.2017 09:16, Roberto Mier Escandón wrote: > I tried content sharing and works fine in this case, Nextcloud exposing > a slot to its documents folder. I think I saw somewhere this is only > valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the > same time. Is that correct? Can removable-media improve this? There can be multiple plugs using the slot. The removable-media interfaces allows access to the host /media directory. That is everything. So unless nextcloud places its data files there this doesn't help you. regards, Simon -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: chroot into a snap
Ah, thanks. I'd better use content then. On 10/02/17 09:38, Simon Fels wrote: > On 10.02.2017 09:16, Roberto Mier Escandón wrote: >> I tried content sharing and works fine in this case, Nextcloud exposing >> a slot to its documents folder. I think I saw somewhere this is only >> valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the >> same time. Is that correct? Can removable-media improve this? > > There can be multiple plugs using the slot. > > The removable-media interfaces allows access to the host /media > directory. That is everything. So unless nextcloud places its data files > there this doesn't help you. > > regards, > Simon > > -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: chroot into a snap
I think you have to support both as otherwise you may miss certain setups of nextcloud. One may be configured to use $SNAP_DATA/$SNAP_COMMON to store its data, another one may use /media/.. to do that. In the end there needs to be some kind of communication happen between both snaps. Either the nextcloud snap shares the data directory via the content interface, regardless where it is. However for that case I am not sure if the security rules of the content interface would allow such a case (effectively sharing /media to another snap via the content interface). The other way would be that the nextcloud snap somehow exposes a pointer for the office snap where to look for its data and then it can either use the path connected via the content or via the removable-media plug. regards, Simon On Fri, Feb 10, 2017 at 9:48 AM, Roberto Mier Escandón < roberto.escan...@canonical.com> wrote: > Ah, thanks. I'd better use content then. > > On 10/02/17 09:38, Simon Fels wrote: > > On 10.02.2017 09:16, Roberto Mier Escandón wrote: > >> I tried content sharing and works fine in this case, Nextcloud exposing > >> a slot to its documents folder. I think I saw somewhere this is only > >> valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the > >> same time. Is that correct? Can removable-media improve this? > > > > There can be multiple plugs using the slot. > > > > The removable-media interfaces allows access to the host /media > > directory. That is everything. So unless nextcloud places its data files > > there this doesn't help you. > > > > regards, > > Simon > > > > > > -- > 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
start engine before client
The program "app1" is not mine. It consists of two parts. I create snapcraft.yaml apps: engine: command: $SNAP/opt/app1/engine --start plugs: [home, unity7, x11, pulseaudio, network, network-bind] player: command: $SNAP/opt/app1/player "$@" plugs: [home, unity7, x11, pulseaudio, network, network-bind] If to launch an engine (app1.engine) and then the client (app1.player), then everything works perfectly. How to make that start of the client automatically launched an engine? Sorry for my english. -- Best regards, vasilisc -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: chroot into a snap
That's interesting, Simon. Good idea having available both $SNAP_DATA and /media. We'll do. But now, let's back to original topic: chroot into snap. After solving the issue Thomas found related with the path of the document, I see now there are two operations not allowed in strict confinement: mknod and chroot. Here is what the snappy-debug.security log shows: = Seccomp = Time: Feb 10 12:31:31 Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=31983 comm="loolkit" exe="/snap/loolwsd/x16/usr/bin/loolforkit" sig=31 arch=c03e 133(mknod) compat=0 ip=0x7f6a6d6450fd code=0x0 Syscall: mknod = Seccomp = Time: Feb 10 12:31:42 Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=11048 comm="loolkit" exe="/snap/loolwsd/x17/usr/bin/loolforkit" sig=31 arch=c03e 161(chroot) compat=0 ip=0x7fd0178dfb47 code=0x0 Syscall: chroot I've solved that by plugging docker-support and all works fine. But that interface gives a lot of permissions, and the name maybe is not the most accurate for a case like this. Shouldn't we have an interface allowing mknod, chroot and maybe ptrace for snaps creating their own chroot jails?. BR. On 10/02/17 11:34, Simon Fels wrote: > I think you have to support both as otherwise you may miss certain setups > of nextcloud. One may be configured to use $SNAP_DATA/$SNAP_COMMON to store > its data, another one may use /media/.. to do that. In the end there needs > to be some kind of communication happen between both snaps. > > Either the nextcloud snap shares the data directory via the content > interface, regardless where it is. However for that case I am not sure if > the security rules of the content interface would allow such a case > (effectively sharing /media to another snap via the content interface). > > The other way would be that the nextcloud snap somehow exposes a pointer > for the office snap where to look for its data and then it can either use > the path connected via the content or via the removable-media plug. > > regards, > Simon > > On Fri, Feb 10, 2017 at 9:48 AM, Roberto Mier Escandón < > roberto.escan...@canonical.com> wrote: > >> Ah, thanks. I'd better use content then. >> >> On 10/02/17 09:38, Simon Fels wrote: >>> On 10.02.2017 09:16, Roberto Mier Escandón wrote: I tried content sharing and works fine in this case, Nextcloud exposing a slot to its documents folder. I think I saw somewhere this is only valid for a 1-1 plug-slot, so that only 1 snap can use that slot at the same time. Is that correct? Can removable-media improve this? >>> >>> There can be multiple plugs using the slot. >>> >>> The removable-media interfaces allows access to the host /media >>> directory. That is everything. So unless nextcloud places its data files >>> there this doesn't help you. >>> >>> regards, >>> Simon >>> >>> >> >> -- >> 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: 'organize' affects 'stage-packages'
You can use a separate part for the stage packages: parts: part1: ... organize: '*': opt/ part2: plugin: nil stage-packages: - some-great-package On Thu, Feb 9, 2017 at 11:47 PM, Ruddick Lawrence wrote: > 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? > > Thanks, > Ruddick > > -- > Snapcraft mailing list > Snapcraft@lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- -mt -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Spread linode backend
I tried exporting that before running spread, and that didn't change the result. Thanks, Max On Thu, Feb 9, 2017 at 2:26 PM, Thomas Voß wrote: > 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 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 delivery: cannot > pack > > project tree: > > - > > tar: > > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/ > expected.classic.ubuntu-core.linode.i386.json: > > file name is too long (max 99); not dumped > > tar: > > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/ > expected.classic.ubuntu-core.qemu.amd64.json: > > file name is too long (max 99); not dumped > > tar: > > snapd/cmd/snap-confine/spread-tests/main/mount-ns-layout/ > expected.classic.ubuntu-core.linode.amd64.json: > > file name is too long (max 99); not dumped > > tar: Exiting with failure status due to previous errors > > - > > 2017/02/09 11:00:19 Successful tasks: 0 > > 2017/02/09 11:00:19 Aborted tasks: 9 > > error: cannot pack project content for delivery > > > > Any suggestions? > > > > Thanks, > > Max > > > > -- > > 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: HowTo: How to create a snap for a Python app with networking using snapcraft in Ubuntu 16.04
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. Simos -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: 'organize' affects 'stage-packages'
Thanks, that's what I ended up doing. It just surprised me that the stage-packages were subject to organization. Ruddick On Fri, Feb 10, 2017 at 5:57 AM, Michael Terry wrote: > > > You can use a separate part for the stage packages: > > parts: > part1: > ... > organize: > '*': opt/ > part2: > plugin: nil > stage-packages: > - some-great-package > > > On Thu, Feb 9, 2017 at 11:47 PM, Ruddick Lawrence > wrote: > > > 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? > > > > Thanks, > > Ruddick > > > > -- > > Snapcraft mailing list > > Snapcraft@lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/snapcraft > > > > > > > -- > -mt > -- next part -- > An HTML attachment was scrubbed... > URL: <https://lists.ubuntu.com/archives/snapcraft/ > attachments/20170210/ef7683db/attachment-0001.html> > -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Exposing dbus interface and using it inside the same snap
Hi, I've been struggling with getting dbus interface exposed. I am getting this error during runtime: GLib.Error: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.1160" is not allowed to own the service "com.screenly.playlist" due to security policies in the configuration file (9) jdstrand helped me on IRC, and told me I need to have a slot and a plug in my snap. I am doing something wrong though, can someone help out with how it's correctly supposed to be used? apps: playlist: command: usr/bin/playlist-service.sh daemon: simple plugs: [network-bind, network, playlist-dbus] websocket: command: usr/bin/websocket-service.sh daemon: simple plugs: [network-bind, network, dbus] slots: [websocket-dbus] slots: playlist-dbus: interface: dbus name: com.screenly bus: system plugs: websocket-dbus: interface: dbus name: com.screenly bus: system -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: launchpad snap recipe fails with classic confinement
On Thu, Feb 09, 2017 at 04:43:33PM -0300, Sergio Schvezov wrote: > El jueves, 9 de febrero de 2017 16h'23:34 ART, Colin Watson > escribió: > >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. This is on our dogfood instance now and I've been able to get a successful run out of it: https://dogfood.paddev.net/~cjwatson/+snap/helloworld-classic/+build/413 The ticket to deploy this is (internal link): https://portal.admin.canonical.com/99787 ... so I expect that this will be rolled out by the time you release snapcraft 2.27. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- 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
On 08/02/17 17:15, Joseph Rushton Wakeling wrote: On 07/02/17 21:17, Thomas Voß wrote: https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 was released to the updates pocket today. Thanks! I'll hopefully be able to report back to you tomorrow whether all works as expected. Just to confirm: today I was able to successfully install snapd on Ubuntu 14.04, with just the regular repositories enabled (no -proposed). I was then able to successfully install and run snap packages (after a restart to ensure the PATH variable included /snap/bin). Unfortunately being able to do this revealed some rather fundamental problems with the 'universality' of my LDC snap, but more on that in another thread ... ;-) Thanks to everyone who got snapd ported successfully to 14.04! -- 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
On Fri, Feb 10, 2017 at 8:39 PM, Joseph Rushton Wakeling wrote: > On 08/02/17 17:15, Joseph Rushton Wakeling wrote: >> >> On 07/02/17 21:17, Thomas Voß wrote: >>> >>> >>> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-xenial/+bug/1655724 >>> was released to the updates pocket today. >> >> >> Thanks! I'll hopefully be able to report back to you tomorrow whether all >> works >> as expected. > > > Just to confirm: today I was able to successfully install snapd on Ubuntu > 14.04, with just the regular repositories enabled (no -proposed). I was > then able to successfully install and run snap packages (after a restart to > ensure the PATH variable included /snap/bin). > \o/, thanks for your feedback :) > Unfortunately being able to do this revealed some rather fundamental > problems with the 'universality' of my LDC snap, but more on that in another > thread ... ;-) > Watching the list, curious what you found out. Thanks, Thomas > Thanks to everyone who got snapd ported successfully to 14.04! > > > -- > 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
LDC compiler snap issues on 14.04 (ABI compatibility?)
Hi all,
So, earlier today I tried out my ldc2 snap on an Ubuntu 14.04 system for the
first time.
sudo snap install --classic --edge ldc2
worked just fine, but I ran into problems as soon as I tried to compile a simple
'hello world' program:
void main()
{
import std.stdio : writeln;
writeln("Hello, D!");
}
Attempting to compile this program resulted in a segfault in GCC (which LDC
invokes in order to link programs).
Running `ldc -v` for verbose output, the precise call that segfaulted was:
/usr/bin/gcc hello.o -o hello -L/snap/ldc2/3/bin/../lib -lphobos2-ldc
-ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64
My suspicion is that that `libphobos2-ldc` and `libdruntime-ldc`, which are
provided as precompiled static libraries in the snap package, are not ABI
compatible with 14.04, hence the segfault.
What do people reckon, and any advice on how to address it? This is a case
where I don't see bundling GCC with the snap as really fixing things, because if
my ABI suspicion is right, it would surely still result in incompatibility with
any host-system libraries the user might want to link against.
It's possible I might be able to address this by supplying druntime and phobos
as source-only libraries (not a problem since D compilation is extremely fast),
but that's not going to solve things for other people facing a similar issue, so
I'm happy to help testing things if a more robust solution seems possible.
Anyway, does anyone have any thoughts?
Thanks & best wishes,
-- Joe
--
Snapcraft mailing list
Snapcraft@lists.snapcraft.io
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: LDC compiler snap issues on 14.04 (ABI compatibility?)
On 10/02/17 21:41, Joseph Rushton Wakeling wrote: Running `ldc -v` for verbose output, the precise call that segfaulted was: /usr/bin/gcc hello.o -o hello -L/snap/ldc2/3/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 My suspicion is that that `libphobos2-ldc` and `libdruntime-ldc`, which are provided as precompiled static libraries in the snap package, are not ABI compatible with 14.04, hence the segfault. For the avoidance of doubt: none of the other linked libraries are provided in the snap itself, only libdruntime-ldc and libphobos2-ldc. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: LDC compiler snap issues on 14.04 (ABI compatibility?)
On Fri, Feb 10, 2017 at 09:41:52PM +0100, Joseph Rushton Wakeling wrote: > Attempting to compile this program resulted in a segfault in GCC (which LDC > invokes in order to link programs). [...] > Anyway, does anyone have any thoughts? Hi Joe, can you grab the dmesg output that might include DENIED lines as well as the kernel's segfault report? This may give enough information for someone to suggest the next step. Thanks signature.asc Description: PGP signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
