From xiaoguo.liu at canonical.com Mon Aug 1 01:54:37 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 1 Aug 2016 09:54:37 +0800 Subject: How to resolve same file conflicts from different parts when building a snap project? Message-ID: Hi, Recently, I tried to convert a qmake project from Ubuntu phone SDK to a snap project, and it worked well initially two weeks ago. The source code can be found at: https://github.com/liu-xiao-guo/rssreader_snap However, now I try to rebuild the project, and I get the following error: ========================================================================== Removing suid/guid from /home/liuxg/snappy/desktop/rssreader/parts/rssreader/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox Pulling rssreader Skipping build desktop/qt5 (already ran) 'rssreader' has prerequisites that need to be staged: desktop/qt5 Skipping pull desktop/qt5 (already ran) Skipping build desktop/qt5 (already ran) Parts 'desktop/qt5' and 'rssreader' have the following file paths in common which have different contents: usr/share/pkgconfig/xkeyboard-config.pc ========================================================================= I find that the same file "xkeyboard-config.pc" is from two different parts: - rssreader - desktop (desktop/qt5), which is used to invoke the Qt app. I do not know how to resolve the conflict issue the same file comes from two different parts Thanks & best regards, XiaoGuo -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Mon Aug 1 02:37:06 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 1 Aug 2016 10:37:06 +0800 Subject: How to resolve same file conflicts from different parts when building a snap project? In-Reply-To: References: Message-ID: Hi, I finally solved the problem by adding: stage: - -usr/share/pkgconfig/xkeyboard-config.pc in one of the parts to avoid the conflicts (the same file from different parts with the same installation path). Best regards, XiaoGuo On Mon, Aug 1, 2016 at 9:54 AM, XiaoGuo Liu wrote: > Hi, > > Recently, I tried to convert a qmake project from Ubuntu phone SDK to a > snap project, and it worked well initially two weeks ago. The source code > can be found at: > > https://github.com/liu-xiao-guo/rssreader_snap > > However, now I try to rebuild the project, and I get the following error: > > ========================================================================== > Removing suid/guid from > /home/liuxg/snappy/desktop/rssreader/parts/rssreader/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox > Pulling rssreader > Skipping build desktop/qt5 (already ran) > 'rssreader' has prerequisites that need to be staged: desktop/qt5 > Skipping pull desktop/qt5 (already ran) > Skipping build desktop/qt5 (already ran) > Parts 'desktop/qt5' and 'rssreader' have the following file paths in > common which have different contents: > usr/share/pkgconfig/xkeyboard-config.pc > ========================================================================= > > I find that the same file "xkeyboard-config.pc" is from two different > parts: > > - rssreader > - desktop (desktop/qt5), which is used to invoke the Qt app. > > I do not know how to resolve the conflict issue the same file comes from > two different parts > > Thanks & best regards, > XiaoGuo > > -- > XiaoGuo, Liu (刘晓国） > Mobile: +86-13911181302 > -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppa at jzimm.net Mon Aug 1 04:55:52 2016 From: ppa at jzimm.net (Jacob Zimmermann) Date: Mon, 1 Aug 2016 14:55:52 +1000 Subject: Overriding seccomp policy: shm_open Message-ID: <212b1dd3-4602-f6b8-2dab-13608a1b11e0@jzimm.net> Hi I'm trying to get my hands on snapcraft by building a snap of "Hatari" (Atari ST emulator). I got it working nicely in devmode but it won't run under strict confinement, specifically it gets killed when attempting to execute shm_open(). Based on whatever little information I could gather I tried to override the default policy like so: apps: hatari: command: hatari plugs: [home, unity7, hatari-permissions] ... plugs: hatari-permissions: type: old-security security-override: syscalls: [shm_open] But no avail, it just won't let it use this syscall. I couldn't find anything in the docs about how is it supposed to be done. Thanks & Best Regards Jacob From simon.fels at canonical.com Mon Aug 1 05:27:06 2016 From: simon.fels at canonical.com (Simon Fels) Date: Mon, 1 Aug 2016 07:27:06 +0200 Subject: Overriding seccomp policy: shm_open In-Reply-To: <212b1dd3-4602-f6b8-2dab-13608a1b11e0@jzimm.net> References: <212b1dd3-4602-f6b8-2dab-13608a1b11e0@jzimm.net> Message-ID: <579EDDAA.7010904@canonical.com> On 01.08.2016 06:55, Jacob Zimmermann wrote: > Hi > > I'm trying to get my hands on snapcraft by building a snap of "Hatari" > (Atari ST emulator). I got it working nicely in devmode but it won't run > under strict confinement, specifically it gets killed when attempting to > execute shm_open(). > > Based on whatever little information I could gather I tried to override > the default policy like so: > > apps: > hatari: > command: hatari > plugs: [home, unity7, hatari-permissions] > > ... > > plugs: > hatari-permissions: > type: old-security > security-override: > syscalls: [shm_open] The old-security interface is not available any more. To be able to further comment on the problem you hit here it will be good to know for what the Hatari emulator wants to use the shm_open syscall. > But no avail, it just won't let it use this syscall. I couldn't find > anything in the docs about how is it supposed to be done. To allow your snap to use the syscall shm_open it needs to use an interface which allows this. Its very likely that in this case there is no appropriate interface yet. As stated above we need to first find out what the emulator tries to do with shm_open here before we can judge further what kind of interface it would need. regards, Simon From didrocks at ubuntu.com Mon Aug 1 06:14:28 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 1 Aug 2016 08:14:28 +0200 Subject: How to resolve same file conflicts from different parts when building a snap project? In-Reply-To: References: Message-ID: Le 01/08/2016 à 04:37, XiaoGuo Liu a écrit : > Hi, > > I finally solved the problem by adding: > > stage: > - -usr/share/pkgconfig/xkeyboard-config.pc > > in one of the parts to avoid the conflicts (the same file from > different parts with the same installation path). Hey, I think you are getting https://bugs.launchpad.net/snapcraft/+bug/1604472, which was supposed to be fixed already in 2.13. Which version of snapcraft is it running? Sergio, do you mind confirming (he's the second to mention it)? Cheers, Didier > > Best regards, > XiaoGuo > > On Mon, Aug 1, 2016 at 9:54 AM, XiaoGuo Liu > wrote: > > Hi, > > Recently, I tried to convert a qmake project from Ubuntu phone SDK > to a snap project, and it worked well initially two weeks ago. The > source code can be found at: > > https://github.com/liu-xiao-guo/rssreader_snap > > However, now I try to rebuild the project, and I get the following > error: > > ========================================================================== > Removing suid/guid from > /home/liuxg/snappy/desktop/rssreader/parts/rssreader/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox > Pulling rssreader > Skipping build desktop/qt5 (already ran) > 'rssreader' has prerequisites that need to be staged: desktop/qt5 > Skipping pull desktop/qt5 (already ran) > Skipping build desktop/qt5 (already ran) > Parts 'desktop/qt5' and 'rssreader' have the following file paths > in common which have different contents: > usr/share/pkgconfig/xkeyboard-config.pc > ========================================================================= > > I find that the same file "xkeyboard-config.pc" is from two > different parts: > > - rssreader > - desktop (desktop/qt5), which is used to invoke the Qt app. > > I do not know how to resolve the conflict issue the same file > comes from two different parts > > Thanks & best regards, > XiaoGuo > > -- > XiaoGuo, Liu (刘晓国） > Mobile: +86-13911181302 > > > > > -- > XiaoGuo, Liu (刘晓国） > Mobile: +86-13911181302 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Mon Aug 1 06:26:49 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 1 Aug 2016 14:26:49 +0800 Subject: How to resolve same file conflicts from different parts when building a snap project? In-Reply-To: References: Message-ID: Hi Didier, I think it should be the same issue as the one described there. By the way, my snapcraft version is: liuxg at liuxg:~$ snapcraft --version 2.13.1 You can try my example at https://github.com/liu-xiao-guo/rssreader_snap/blob/master/snapcraft.yaml. You just need to take off the following line: stage: - -usr/share/pkgconfig/xkeyboard-config.pc in order to duplicate the issue. Best regards, XiaoGuo On Mon, Aug 1, 2016 at 2:14 PM, Didier Roche wrote: > Le 01/08/2016 à 04:37, XiaoGuo Liu a écrit : > > Hi, > > I finally solved the problem by adding: > > stage: > - -usr/share/pkgconfig/xkeyboard-config.pc > > in one of the parts to avoid the conflicts (the same file from different > parts with the same installation path). > > > Hey, > > I think you are getting https://bugs.launchpad.net/snapcraft/+bug/1604472, > which was supposed to be fixed already in 2.13. Which version of snapcraft > is it running? > > Sergio, do you mind confirming (he's the second to mention it)? > > Cheers, > Didier > > > Best regards, > XiaoGuo > > On Mon, Aug 1, 2016 at 9:54 AM, XiaoGuo Liu > wrote: > >> Hi, >> >> Recently, I tried to convert a qmake project from Ubuntu phone SDK to a >> snap project, and it worked well initially two weeks ago. The source code >> can be found at: >> >> https://github.com/liu-xiao-guo/rssreader_snap >> >> However, now I try to rebuild the project, and I get the following error: >> >> ========================================================================== >> Removing suid/guid from >> /home/liuxg/snappy/desktop/rssreader/parts/rssreader/install/usr/lib/x86_64-linux-gnu/oxide-qt/chrome-sandbox >> Pulling rssreader >> Skipping build desktop/qt5 (already ran) >> 'rssreader' has prerequisites that need to be staged: desktop/qt5 >> Skipping pull desktop/qt5 (already ran) >> Skipping build desktop/qt5 (already ran) >> Parts 'desktop/qt5' and 'rssreader' have the following file paths in >> common which have different contents: >> usr/share/pkgconfig/xkeyboard-config.pc >> ========================================================================= >> >> I find that the same file "xkeyboard-config.pc" is from two different >> parts: >> >> - rssreader >> - desktop (desktop/qt5), which is used to invoke the Qt app. >> >> I do not know how to resolve the conflict issue the same file comes from >> two different parts >> >> Thanks & best regards, >> XiaoGuo >> >> -- >> XiaoGuo, Liu (刘晓国） >> Mobile: +86-13911181302 >> > > > > -- > XiaoGuo, Liu (刘晓国） > Mobile: +86-13911181302 > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.chen at canonical.com Mon Aug 1 09:02:56 2016 From: david.chen at canonical.com (David Chen) Date: Mon, 1 Aug 2016 17:02:56 +0800 Subject: GeoClue Message-ID: <0d930314-3c93-80a5-76d4-3a4a47a80475@canonical.com> Hi, I am trying to make a snap for a weatherinfo example which I got from Qt creator. The problem I am having is, it seems to require "geoclue-master" and "ubuntu-geoip-provider" both running in order to get the location info. Since GeoClue is D-Bus related, I am wondering if there is a recommended way to make it work under snappy, or if there is any suggestion for this type of location service related apps? Btw, I learned there is a snapcraft pull option "--enable-geoip", does it have anything to do with this topic? Thanks and Regards, -- * DAVID CHEN** * -------------- next part -------------- An HTML attachment was scrubbed... URL: From howy.wang at canonical.com Mon Aug 1 09:22:49 2016 From: howy.wang at canonical.com (Howy Wang) Date: Mon, 1 Aug 2016 17:22:49 +0800 Subject: Can not launch atom-cwayne.atom Message-ID: Hi All, I just installed the snap, atom-cwayne.atom of snappy-playpen, but it can't be used after installation. My snapcraft verson is 2.13.1, and snapd version is 2.0.10 on Ubuntu 16.04 -64 bits. May I know which problems on my environment? The following information is for your reference. howy at howy-Vostro-14-5480:~$ atom-cwayne.atom howy at howy-Vostro-14-5480:~*$ /snap/atom-cwayne/1/bin/atom: line 108: /usr/bin/nohup: Permission denied* howy at howy-Vostro-14-5480:~$ sudo snap refresh atom-cwayne error: cannot perform the following tasks: - Download snap "atom-cwayne" from channel "stable" (revision 1 of snap "atom-cwayne" already installed) howy at howy-Vostro-14-5480:~$ sudo atom-cwayne.atom sudo: atom-cwayne.atom: command not found howy at howy-Vostro-14-5480:~$ snapcraft --version 2.13.1 Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.voss at canonical.com Mon Aug 1 09:30:53 2016 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Mon, 1 Aug 2016 11:30:53 +0200 Subject: GeoClue In-Reply-To: <0d930314-3c93-80a5-76d4-3a4a47a80475@canonical.com> References: <0d930314-3c93-80a5-76d4-3a4a47a80475@canonical.com> Message-ID: On Mon, Aug 1, 2016 at 11:02 AM, David Chen wrote: > Hi, > > I am trying to make a snap for a weatherinfo example which I got from Qt > creator. The problem I am having is, it seems to require "geoclue-master" > and "ubuntu-geoip-provider" both running in order to get the location info. The weatherinfo example uses QtPositioning/Location internally. Both fall back to a default backend, which is probably selected as Ubuntu's Geoip provider by default. For testing purposes, and if you are willing to alter some source code: you could switch to the simulator backend that comes as part of the Qt positioning source. In "void AppModel::networkSessionOpened()", change: d->src = QGeoPositionInfoSource::createDefaultSource(this); to d->src = QGeoPositionInfoSource::createSource("simulator", this); > Since GeoClue is D-Bus related, I am wondering if there is a recommended way > to make it work under snappy, or if there is any suggestion for this type of > location service related apps? > We have two interfaces "location-control" and "location-observe" in place. Both talk to the location-service as available on Ubuntu phones today. We are working on uploading a snap of the location-service with a pre-configured dummy setup that allows for rapid testing of location-based snaps. Upload should happen really soon. Hope that helps, Thomas > Btw, I learned there is a snapcraft pull option "--enable-geoip", does it > have anything to do with this topic? > > Thanks and Regards, > > -- > > DAVID CHEN > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From simon.fels at canonical.com Mon Aug 1 11:23:50 2016 From: simon.fels at canonical.com (Simon Fels) Date: Mon, 1 Aug 2016 13:23:50 +0200 Subject: Snaps on Yocto/OpenEmbedded Message-ID: Hey everyone, after an idea during the sprint in Heidelberg I've quickly created a meta-snappy layer for Yocto/OpenEmbedded which now brings snaps to any Yocto/OpenEmbedded based operating system (assuming it runs systemd). The relevant git repository and instructions how to get started are available at https://github.com/morphis/meta-snappy If you find any problems I am happy to review and accept pull-requests! Happy hacking! regards, Simon From kyle.fazzari at canonical.com Mon Aug 1 13:53:10 2016 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 1 Aug 2016 06:53:10 -0700 Subject: GeoClue In-Reply-To: <0d930314-3c93-80a5-76d4-3a4a47a80475@canonical.com> References: <0d930314-3c93-80a5-76d4-3a4a47a80475@canonical.com> Message-ID: <32d482a3-46c6-9ee0-8112-e1a51f220a01@canonical.com> On 08/01/2016 02:02 AM, David Chen wrote: > > Btw, I learned there is a snapcraft pull option "--enable-geoip", does > it have anything to do with this topic? > No, this relates to the package repository URLs used by snapcraft. Without this option enabled snapcraft will use the repositories configured on your system. With it enabled it will use the repositories closest to you as determined by your IP address. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From honeycuttaaron3 at gmail.com Mon Aug 1 14:45:57 2016 From: honeycuttaaron3 at gmail.com (Aaron Honeycutt) Date: Mon, 1 Aug 2016 10:45:57 -0400 Subject: Pithos snap Message-ID: Heyo all! I've hit the following bugs trying to make a snap of the new 1.2.0 release of Pith - a pandora GNOME desktop player. [1] https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1590831 [2] https://bugs.launchpad.net/snappy/+bug/1583250 [3] https://bugs.launchpad.net/snappy/+bug/1590679 I've gotten around 1 and 2 thanks to the cool folks in #snappy on IRC freenode but 3 is still holding me and I'm sure other folks back. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.wayne at canonical.com Mon Aug 1 15:15:34 2016 From: chris.wayne at canonical.com (Chris Wayne) Date: Mon, 1 Aug 2016 11:15:34 -0400 Subject: Can not launch atom-cwayne.atom In-Reply-To: References: Message-ID: Hi, You'll need to install with --devmode, and it should work. I need to upload a new version to make that clearer. Thanks Chris On Mon, Aug 1, 2016 at 5:22 AM, Howy Wang wrote: > Hi All, > > I just installed the snap, atom-cwayne.atom of snappy-playpen, but it > can't be used after installation. My snapcraft verson is 2.13.1, and snapd > version is 2.0.10 on Ubuntu 16.04 -64 bits. May I know which problems on > my environment? > > The following information is for your reference. > howy at howy-Vostro-14-5480:~$ atom-cwayne.atom > howy at howy-Vostro-14-5480:~*$ /snap/atom-cwayne/1/bin/atom: line 108: > /usr/bin/nohup: Permission denied* > howy at howy-Vostro-14-5480:~$ sudo snap refresh atom-cwayne > error: cannot perform the following tasks: > - Download snap "atom-cwayne" from channel "stable" (revision 1 of snap > "atom-cwayne" already installed) > howy at howy-Vostro-14-5480:~$ sudo atom-cwayne.atom > sudo: atom-cwayne.atom: command not found > howy at howy-Vostro-14-5480:~$ snapcraft --version > 2.13.1 > > Thank you. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Mon Aug 1 16:34:56 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 01 Aug 2016 11:34:56 -0500 Subject: Overriding seccomp policy: shm_open In-Reply-To: <579EDDAA.7010904@canonical.com> References: <212b1dd3-4602-f6b8-2dab-13608a1b11e0@jzimm.net> <579EDDAA.7010904@canonical.com> Message-ID: <1470069296.6183.139.camel@canonical.com> On Mon, 2016-08-01 at 07:27 +0200, Simon Fels wrote: > On 01.08.2016 06:55, Jacob Zimmermann wrote: > > > > Hi > > > > I'm trying to get my hands on snapcraft by building a snap of "Hatari" > > (Atari ST emulator). I got it working nicely in devmode but it won't run > > under strict confinement, specifically it gets killed when attempting to > > execute shm_open(). > > > > Based on whatever little information I could gather I tried to override > > the default policy like so: > > > > apps: > >   hatari: > >     command: hatari > >     plugs: [home, unity7, hatari-permissions] > > > > ... > > > > plugs: > >   hatari-permissions: > >     type: old-security > >     security-override: > >       syscalls: [shm_open] > The old-security interface is not available any more. To be able to > further comment on the problem you hit here it will be good to know for > what the Hatari emulator wants to use the shm_open syscall. > > > > > But no avail, it just won't let it use this syscall. I couldn't find > > anything in the docs about how is it supposed to be done. > To allow your snap to use the syscall shm_open it needs to use an > interface which allows this. Its very likely that in this case there is > no appropriate interface yet. As stated above we need to first find out > what the emulator tries to do with shm_open here before we can judge > further what kind of interface it would need. > shm_open() is allowed in the default policy for seccomp and if the path conforms to this from the default policy for apparmor, then there should be no issues:   # App-specific access to files and directories in /dev/shm. We allow file   # access in /dev/shm for shm_open() and files in subdirectories for open()   /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix, I suspect you need to adjust hatari to use (perhaps conditionally if SNAP env var is set, up to you) shm_open("snap.hatari.XXXXXX", ...) or similar. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Mon Aug 1 16:43:47 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 01 Aug 2016 11:43:47 -0500 Subject: Pithos snap In-Reply-To: References: Message-ID: <1470069827.6183.143.camel@canonical.com> On Mon, 2016-08-01 at 10:45 -0400, Aaron Honeycutt wrote: > Heyo all! > Hi! > [3] https://bugs.launchpad.net/snappy/+bug/1590679 > > I've gotten around 1 and 2 thanks to the cool folks in #snappy on IRC > freenode but 3 is still holding me and I'm sure other folks back. Today, you can install with --devmode and publish to the store in non-stable channels with 'confinement: devmode' in your yaml and be unblocked. There is an exploratory PR for this bug: https://github.com/snapcore/snapd/pull/1446/files This bug and PR came up last week which rekindled discussions that allows me to get this PR moving again. Stay tuned-- this bug should be fixed in a new snapd release soon (2.12 or later). -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From honeycuttaaron3 at gmail.com Mon Aug 1 16:47:31 2016 From: honeycuttaaron3 at gmail.com (Aaron Honeycutt) Date: Mon, 1 Aug 2016 12:47:31 -0400 Subject: Pithos snap In-Reply-To: <1470069827.6183.143.camel@canonical.com> References: <1470069827.6183.143.camel@canonical.com> Message-ID: So I just want on an update from snapd? And then use that in my yaml? On Aug 1, 2016 12:43 PM, "Jamie Strandboge" wrote: > On Mon, 2016-08-01 at 10:45 -0400, Aaron Honeycutt wrote: > > Heyo all! > > > Hi! > > > [3] https://bugs.launchpad.net/snappy/+bug/1590679 > > > > I've gotten around 1 and 2 thanks to the cool folks in #snappy on IRC > > freenode but 3 is still holding me and I'm sure other folks back. > > Today, you can install with --devmode and publish to the store in > non-stable > channels with 'confinement: devmode' in your yaml and be unblocked. > > There is an exploratory PR for this bug: > https://github.com/snapcore/snapd/pull/1446/files > > This bug and PR came up last week which rekindled discussions that allows > me to > get this PR moving again. Stay tuned-- this bug should be fixed in a new > snapd > release soon (2.12 or later). > > -- > Jamie Strandboge | http://www.canonical.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Mon Aug 1 16:54:18 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 01 Aug 2016 11:54:18 -0500 Subject: Pithos snap In-Reply-To: References: <1470069827.6183.143.camel@canonical.com> Message-ID: <1470070458.6183.151.camel@canonical.com> On Mon, 2016-08-01 at 12:47 -0400, Aaron Honeycutt wrote: > So I just want on an update from snapd? And then use that in my yaml? > Yes, but I think some things are going to change in the PR so I advise not changing yet or keeping an eye on the PR. > On Aug 1, 2016 12:43 PM, "Jamie Strandboge" wrote: > > > > > On Mon, 2016-08-01 at 10:45 -0400, Aaron Honeycutt wrote: > > > > > > Heyo all! > > > > > Hi! > > > > > > > > [3] https://bugs.launchpad.net/snappy/+bug/1590679 > > > > > > I've gotten around 1 and 2 thanks to the cool folks in #snappy on IRC > > > freenode but 3 is still holding me and I'm sure other folks back. > > Today, you can install with --devmode and publish to the store in > > non-stable > > channels with 'confinement: devmode' in your yaml and be unblocked. > > > > There is an exploratory PR for this bug: > > https://github.com/snapcore/snapd/pull/1446/files > > > > This bug and PR came up last week which rekindled discussions that allows > > me to > > get this PR moving again. Stay tuned-- this bug should be fixed in a new > > snapd > > release soon (2.12 or later). > > > > -- > > Jamie Strandboge             | http://www.canonical.com > > > > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From honeycuttaaron3 at gmail.com Mon Aug 1 16:55:19 2016 From: honeycuttaaron3 at gmail.com (Aaron Honeycutt) Date: Mon, 1 Aug 2016 12:55:19 -0400 Subject: Pithos snap In-Reply-To: <1470070458.6183.151.camel@canonical.com> References: <1470069827.6183.143.camel@canonical.com> <1470070458.6183.151.camel@canonical.com> Message-ID: Will do. Thanks for the update! On Aug 1, 2016 12:54 PM, "Jamie Strandboge" wrote: > On Mon, 2016-08-01 at 12:47 -0400, Aaron Honeycutt wrote: > > So I just want on an update from snapd? And then use that in my yaml? > > > > Yes, but I think some things are going to change in the PR so I advise not > changing yet or keeping an eye on the PR. > > > On Aug 1, 2016 12:43 PM, "Jamie Strandboge" wrote: > > > > > > > > On Mon, 2016-08-01 at 10:45 -0400, Aaron Honeycutt wrote: > > > > > > > > Heyo all! > > > > > > > Hi! > > > > > > > > > > > [3] https://bugs.launchpad.net/snappy/+bug/1590679 > > > > > > > > I've gotten around 1 and 2 thanks to the cool folks in #snappy on IRC > > > > freenode but 3 is still holding me and I'm sure other folks back. > > > Today, you can install with --devmode and publish to the store in > > > non-stable > > > channels with 'confinement: devmode' in your yaml and be unblocked. > > > > > > There is an exploratory PR for this bug: > > > https://github.com/snapcore/snapd/pull/1446/files > > > > > > This bug and PR came up last week which rekindled discussions that > allows > > > me to > > > get this PR moving again. Stay tuned-- this bug should be fixed in a > new > > > snapd > > > release soon (2.12 or later). > > > > > > -- > > > Jamie Strandboge | http://www.canonical.com > > > > > > > -- > Jamie Strandboge | http://www.canonical.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Tue Aug 2 05:45:14 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 2 Aug 2016 08:45:14 +0300 Subject: SNAP_USER_COMMON Message-ID: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> test snap raise error ------------------------- echo "Writing to $SNAP_USER_COMMON" mkdir -p $SNAP_USER_COMMON/platform echo "hello common" > $SNAP_USER_COMMON/common.txt -------------- grep -F audit syslog Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 --------------- I readed https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data https://github.com/snapcore/snapd/pull/1396 How it is correct to use a variable SNAP_USER_COMMON from snap package? -- Best regards, vasilisc From didrocks at ubuntu.com Tue Aug 2 06:00:06 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Tue, 2 Aug 2016 08:00:06 +0200 Subject: SNAP_USER_COMMON In-Reply-To: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> Message-ID: <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> Le 02/08/2016 à 07:45, Vasilisc a écrit : > > test snap raise error > ------------------------- > echo "Writing to $SNAP_USER_COMMON" > mkdir -p $SNAP_USER_COMMON/platform > echo "hello common" > $SNAP_USER_COMMON/common.txt > -------------- > grep -F audit syslog > > Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 > audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" > profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" > pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 > ouid=1000 Hey Vasilisc, where do you see an error in the above trace? Apparmor says "ALLOWED", so the mkdir call wasn't blocked and work as expected, or did you notice not having this directory and file created after those calls? Didier From vasilisc777 at gmail.com Tue Aug 2 06:04:49 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 2 Aug 2016 09:04:49 +0300 Subject: SNAP_USER_COMMON In-Reply-To: <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> Message-ID: <4f27af7e-d6eb-84a2-f165-7328ee64c84c@gmail.com> 02.08.2016 09:00, Didier Roche пишет: > Le 02/08/2016 à 07:45, Vasilisc a écrit : >> >> test snap raise error >> ------------------------- >> echo "Writing to $SNAP_USER_COMMON" >> mkdir -p $SNAP_USER_COMMON/platform >> echo "hello common" > $SNAP_USER_COMMON/common.txt >> -------------- >> grep -F audit syslog >> >> Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 >> audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" >> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" >> pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 >> ouid=1000 > > Hey Vasilisc, > > where do you see an error in the above trace? Apparmor says "ALLOWED", > so the mkdir call wasn't blocked and work as expected, or did you notice > not having this directory and file created after those calls? > > Didier ALLOWED because snap package installed --devmode without --devmode Aug 2 08:57:36 vb kernel: [ 4022.034692] audit: type=1400 audit(1470117456.515:40): apparmor="DENIED" operation="mkdir" profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" pid=5539 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 -- Best regards, vasilisc From vasilisc777 at gmail.com Tue Aug 2 06:12:34 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 2 Aug 2016 09:12:34 +0300 Subject: SNAP_USER_COMMON In-Reply-To: <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> Message-ID: 02.08.2016 09:00, Didier Roche пишет: > Le 02/08/2016 à 07:45, Vasilisc a écrit : >> >> test snap raise error >> ------------------------- >> echo "Writing to $SNAP_USER_COMMON" >> mkdir -p $SNAP_USER_COMMON/platform >> echo "hello common" > $SNAP_USER_COMMON/common.txt >> -------------- >> grep -F audit syslog >> >> Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 >> audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" >> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" >> pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 >> ouid=1000 > > Hey Vasilisc, > > where do you see an error in the above trace? Apparmor says "ALLOWED", > so the mkdir call wasn't blocked and work as expected, or did you notice > not having this directory and file created after those calls? > > Didier > Code echo "Writing to $SNAP_USER_COMMON" mkdir -p $SNAP_USER_COMMON -------------------- Aug 2 09:08:42 vb kernel: [ 4688.252234] audit: type=1400 audit(1470118122.727:44): apparmor="DENIED" operation="mkdir" profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" pid=5802 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 -- Best regards, vasilisc From vasilisc777 at gmail.com Tue Aug 2 06:39:51 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 2 Aug 2016 09:39:51 +0300 Subject: SNAP_USER_COMMON In-Reply-To: <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> Message-ID: 02.08.2016 09:00, Didier Roche пишет: > Le 02/08/2016 à 07:45, Vasilisc a écrit : >> >> test snap raise error >> ------------------------- >> echo "Writing to $SNAP_USER_COMMON" >> mkdir -p $SNAP_USER_COMMON/platform >> echo "hello common" > $SNAP_USER_COMMON/common.txt >> -------------- >> grep -F audit syslog >> >> Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 >> audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" >> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" >> pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 >> ouid=1000 > > Hey Vasilisc, > > where do you see an error in the above trace? Apparmor says "ALLOWED", > so the mkdir call wasn't blocked and work as expected, or did you notice > not having this directory and file created after those calls? > > Didier > LOL command "snap run test2" output execv failed: no such file or directory BUT create empty folders ~/snap/common/ ~/snap/x1/ work solution "snap run test2; test2" =) ======== * Isn't SNAP_USER_COMMON dir being created automatically by snapd? The launcher script in /snap/bin/ doesn't create it, and creating it manually inside the snap fails (permission denied). Running snap run app creates that folder, though (but the command fails with execv failed: No such file or directory... I have no idea how to use that command). – Bruno Nova Jul 11 at 20:14 * Yes, it should be, but it's not (a bug that's fixed in the upcoming release where snap run is used). – Kyle Jul 11 at 21:05 * Great, thank you! – Bruno Nova Jul 11 at 23:29 https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data -- Best regards, vasilisc From didrocks at ubuntu.com Tue Aug 2 07:04:04 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Tue, 2 Aug 2016 09:04:04 +0200 Subject: SNAP_USER_COMMON In-Reply-To: References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> Message-ID: <8641f239-9b0a-1d66-71bc-c1f36c517efc@ubuntu.com> Le 02/08/2016 à 08:12, Vasilisc a écrit : > 02.08.2016 09:00, Didier Roche пишет: >> Le 02/08/2016 à 07:45, Vasilisc a écrit : >>> >>> test snap raise error >>> ------------------------- >>> echo "Writing to $SNAP_USER_COMMON" >>> mkdir -p $SNAP_USER_COMMON/platform >>> echo "hello common" > $SNAP_USER_COMMON/common.txt >>> -------------- >>> grep -F audit syslog >>> >>> Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 >>> audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" >>> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" >>> pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 >>> ouid=1000 >> >> Hey Vasilisc, >> >> where do you see an error in the above trace? Apparmor says "ALLOWED", >> so the mkdir call wasn't blocked and work as expected, or did you notice >> not having this directory and file created after those calls? >> >> Didier >> > > Code > echo "Writing to $SNAP_USER_COMMON" > mkdir -p $SNAP_USER_COMMON > -------------------- > > Aug 2 09:08:42 vb kernel: [ 4688.252234] audit: type=1400 > audit(1470118122.727:44): apparmor="DENIED" operation="mkdir" > profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" > pid=5802 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 > ouid=1000 > Mind opening a bug against snappy on launchpad with your snapcraft.yaml, shell script and this output? I think the apparmor profile may need to be adjusted to write to $SNAP_USER_COMMON. Thanks! From loic.minier at ubuntu.com Tue Aug 2 10:35:13 2016 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 2 Aug 2016 12:35:13 +0200 Subject: How do I get a postinst stage properly executed - traceroute will not install correctly In-Reply-To: References: Message-ID: Hi David, On Thu, Jul 28, 2016 at 6:32 PM, David Garrod wrote: > > Yes I know I can do some special messing around to try and fix up the > installation but I don’t think that is a good idea. How can I get the > package to install fully and correctly inside the SNAP, i.e. properly > execute the “postinst” commands. > Taking a step back, Snapcraft is a tool to help you assemble snaps from various pieces. The stage-package feature is meant to easily consume package contents, but it's not a perfect installation of a .deb honoring posting etc. At the moment, it just unpacks the .deb (dpkg -x) as if it was a tarball. Capturing the installation of any possible .deb and its postinst would be quite complex: - we'd have to run these postinsts with root permissions during the build (however we do sudo apt install on the build-packages, so that's technically possible albeit intrusive) - we'd need a chroot and a way to record the changes done to this chroot (as to extract the new files) - we'd need to decide what to do with modified/updated files This is not out of the possible, but it's a lot of work and the "unpacking the .deb" heuristic works for most use cases. Perhaps there should be a separate plugin which does the "true .deb" installation process in a chroot etc., but for your specific traceroute use case it seems easier to just add the missing symlinks created by update-alternatives yourself (or simply move the binaries to the expected place!) Alternatively, you could also build traceroute from source instead of reusing the .deb. Cheers, - Loïc Minier -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Tue Aug 2 14:22:06 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 02 Aug 2016 09:22:06 -0500 Subject: SNAP_USER_COMMON In-Reply-To: <8641f239-9b0a-1d66-71bc-c1f36c517efc@ubuntu.com> References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> <8641f239-9b0a-1d66-71bc-c1f36c517efc@ubuntu.com> Message-ID: <1470147726.6021.6.camel@canonical.com> On Tue, 2016-08-02 at 09:04 +0200, Didier Roche wrote: > Le 02/08/2016 à 08:12, Vasilisc a écrit : > > > > 02.08.2016 09:00, Didier Roche пишет: > > > > > > Le 02/08/2016 à 07:45, Vasilisc a écrit : > > > > > > > > > > > > test snap raise error > > > > ------------------------- > > > > echo "Writing to $SNAP_USER_COMMON" > > > > mkdir -p $SNAP_USER_COMMON/platform > > > > echo "hello common" > $SNAP_USER_COMMON/common.txt > > > > -------------- > > > > grep -F audit syslog > > > > > > > > Aug  2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 > > > > audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" > > > > profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" > > > > pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 > > > > ouid=1000 > > > Hey Vasilisc, > > > > > > where do you see an error in the above trace? Apparmor says "ALLOWED", > > > so the mkdir call wasn't blocked and work as expected, or did you notice > > > not having this directory and file created after those calls? > > > > > > Didier > > > > > Code > > echo "Writing to $SNAP_USER_COMMON" > > mkdir -p $SNAP_USER_COMMON > > -------------------- > > > > Aug  2 09:08:42 vb kernel: [ 4688.252234] audit: type=1400 > > audit(1470118122.727:44): apparmor="DENIED" operation="mkdir" > > profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" > > pid=5802 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 > > ouid=1000 > > > Mind opening a bug against snappy on launchpad with your snapcraft.yaml, > shell script and this output? I think the apparmor profile may need to > be adjusted to write to $SNAP_USER_COMMON. Please file a bug, yes, but the bug is that 'snap run' is not creating the directory. The snap should not be expected to have to do this. The regression looks to have been introduced in https://github.com/snapcore/snapd/pull/1293 or perhaps you are using an old version of snapd and a new version of snap-confine? Regardless, please file a bug. Thanks! -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.fazzari at canonical.com Tue Aug 2 22:38:55 2016 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 2 Aug 2016 15:38:55 -0700 Subject: SNAP_USER_COMMON In-Reply-To: <1470147726.6021.6.camel@canonical.com> References: <65abeb12-14fa-e47b-fda3-a4469dc4d7b9@gmail.com> <98fcd503-39b4-bb2d-1f6b-8f6216f0a36b@ubuntu.com> <8641f239-9b0a-1d66-71bc-c1f36c517efc@ubuntu.com> <1470147726.6021.6.camel@canonical.com> Message-ID: <8b2cab73-e0d8-4ae6-62fa-6ac15c6c5139@canonical.com> On 08/02/2016 07:22 AM, Jamie Strandboge wrote: > On Tue, 2016-08-02 at 09:04 +0200, Didier Roche wrote: >> Le 02/08/2016 à 08:12, Vasilisc a écrit : >>> 02.08.2016 09:00, Didier Roche пишет: >>>> Le 02/08/2016 à 07:45, Vasilisc a écrit : >>>>> >>>>> test snap raise error >>>>> ------------------------- >>>>> echo "Writing to $SNAP_USER_COMMON" >>>>> mkdir -p $SNAP_USER_COMMON/platform >>>>> echo "hello common" > $SNAP_USER_COMMON/common.txt >>>>> -------------- >>>>> grep -F audit syslog >>>>> >>>>> Aug 2 08:34:16 vb kernel: [ 2622.276193] audit: type=1400 >>>>> audit(1470116056.762:34): apparmor="ALLOWED" operation="mkdir" >>>>> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" >>>>> pid=4971 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 >>>>> ouid=1000 >>>> Hey Vasilisc, >>>> >>>> where do you see an error in the above trace? Apparmor says "ALLOWED", >>>> so the mkdir call wasn't blocked and work as expected, or did you notice >>>> not having this directory and file created after those calls? >>>> >>>> Didier >>>> >>> Code >>> echo "Writing to $SNAP_USER_COMMON" >>> mkdir -p $SNAP_USER_COMMON >>> -------------------- >>> >>> Aug 2 09:08:42 vb kernel: [ 4688.252234] audit: type=1400 >>> audit(1470118122.727:44): apparmor="DENIED" operation="mkdir" >>> profile="snap.test2.test2" name="/home/vasilisc/snap/test2/common/" >>> pid=5802 comm="mkdir" requested_mask="c" denied_mask="c" fsuid=1000 >>> ouid=1000 >>> >> Mind opening a bug against snappy on launchpad with your snapcraft.yaml, >> shell script and this output? I think the apparmor profile may need to >> be adjusted to write to $SNAP_USER_COMMON. > Please file a bug, yes, but the bug is that 'snap run' is not creating the > directory. The snap should not be expected to have to do this. The regression > looks to have been introduced in https://github.com/snapcore/snapd/pull/1293 or > perhaps you are using an old version of snapd and a new version of snap-confine? > Regardless, please file a bug. > > Thanks! `snap run` does indeed have code to do this, but it doesn't seem that a version of snapd actually utilizing `snap run` has been released yet. It's my understanding that the version of snapd that would be using `snap run` would also be accompanied by the files within /snap/bin/ being symlinks instead of scripts, which isn't yet merged[1]. Of course, I may be wrong. Right now the /snap/bin/foo files are still scripts that shell out to ubuntu-core-launcher, which unless someone else added it, doesn't have code to do this. I didn't add it because I thought we'd have snap run soon, but that seemed to be blocked on a stable OS snap. Michael or Gustavo, do you have any more information on that? Should we add this logic to u-c-l while we're waiting? For more information, this test[2] reflects the current capabilities as I understand them. Note that SNAP_USER_COMMON is not tested yet, as `snap run` isn't used (thus the directories are not created). [1]: https://github.com/snapcore/snapd/pull/1254 [2]: https://github.com/snapcore/snapd/blob/master/tests/main/writable-areas/task.yaml -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From josh at pdk.io Tue Aug 2 22:44:49 2016 From: josh at pdk.io (Joshua Perry) Date: Tue, 2 Aug 2016 16:44:49 -0600 Subject: Rpi3 testing In-Reply-To: References: <1463592221.23678.4.camel@ubuntu.com> <1463596541.4114.10.camel@canonical.com> <1463598801.29215.2.camel@ubuntu.com> <1463599549.4114.12.camel@canonical.com> Message-ID: I’ve been trying to do this as well but keep getting HTTP 401 in response to pulling the required snaps. Is there some authentication to the image server required? Josh > On May 19, 2016, at 9:19 AM, Fernando Correa Neto wrote: > > FYI, I just tested and it works. > > Generated the image with: > > sudo ./ubuntu-device-flash core rolling-core --gadget canonical-pi3 --developer-mode --channel=edge --kernel canonical-pi2-linux --os xenial-preinstalled-core-armhf.os.snap -o rpi3-all-snap.img > > -Fernando > > On Wed, May 18, 2016 at 4:26 PM Jamie Strandboge > wrote: > On Wed, 2016-05-18 at 21:13 +0200, Oliver Grawert wrote: > > hi, > > > > On Mi, 2016-05-18 at 13:35 -0500, Jamie Strandboge wrote: > > > > > > Oliver, fyi this snappy-workaround-apparmor.service was only needed on 15.04 > > > and > > > fixed in the parser in 15.10. If this is causing you trouble, please feel > > > free > > > to remove it now > > already happened and tested ... thats what will go to the store > > tomorrow ... > > \o/ Thanks! :) > > -- > Jamie Strandboge | http://www.canonical.com > > -- > snappy-devel mailing list > snappy-devel at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Wed Aug 3 05:20:41 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 3 Aug 2016 08:20:41 +0300 Subject: analog sed Message-ID: <51cc9829-808f-eafa-c304-9a70b5508939@gmail.com> AppArmor not allowed "sed -i". how to find and replace substring? ------------------------------------------ syscall 93 scmp_sys_resolver 93 (fchown) https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1581310 -- Best regards, vasilisc From vasilisc777 at gmail.com Wed Aug 3 06:00:40 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 3 Aug 2016 09:00:40 +0300 Subject: analog sed In-Reply-To: <51cc9829-808f-eafa-c304-9a70b5508939@gmail.com> References: <51cc9829-808f-eafa-c304-9a70b5508939@gmail.com> Message-ID: <53b86d53-9145-63e2-c3a7-ee2e0eb157ab@gmail.com> 03.08.2016 08:20, Vasilisc пишет: > AppArmor not allowed "sed -i". > how to find and replace substring? > ------------------------------------------ > syscall 93 > scmp_sys_resolver 93 (fchown) > https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1581310 I apologize that hurried. work fine sed "s/old/new/g" $SNAP/input.txt | tee -a $SNAP_USER_DATA/output.txt -- Best regards, vasilisc From ogra at ubuntu.com Wed Aug 3 10:49:58 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 03 Aug 2016 12:49:58 +0200 Subject: Rpi3 testing In-Reply-To: References: <1463592221.23678.4.camel@ubuntu.com> <1463596541.4114.10.camel@canonical.com> <1463598801.29215.2.camel@ubuntu.com> <1463599549.4114.12.camel@canonical.com> Message-ID: <1470221398.29378.13.camel@ubuntu.com> hi, Am Dienstag, den 02.08.2016, 16:44 -0600 schrieb Joshua Perry: > I’ve been trying to do this as well but keep getting HTTP 401 in > response to pulling the required snaps. Is there some authentication > to the image server required? we are in the middle of making the switch to new image building and a new naming scheme this week, please stay tuned, there will be announcements soon... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Wed Aug 3 12:50:43 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 3 Aug 2016 15:50:43 +0300 Subject: xdg-open pls help Message-ID: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> "Using xdg-open in a snap package" https://olav.ninja/using-xdg-open-in-a-snap/ --------------------------- I modify this solution BEFORE snapd-xdg-open: source: https://github.com/ubuntu-core/snapd-xdg-open.git plugin : copy files: data/xdg-open: bin/xdg-open AFTER com.canonical.SafeLauncher.service : usr/share/dbus-1/services/com.canonical.SafeLauncher.service xdg-open: bin/xdg-open -------------------------- Script "xdg-open" contain dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1" File "com.canonical.SafeLauncher.service" contain [D-BUS Service] Name=com.canonical.SafeLauncher Exec=xdg-open But I see a problem Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files -- Best regards, vasilisc From seb128 at ubuntu.com Wed Aug 3 13:17:33 2016 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Wed, 3 Aug 2016 15:17:33 +0200 Subject: xdg-open pls help In-Reply-To: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> References: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> Message-ID: <58f7abbb-8c00-8a78-b895-3863b1dc6a92@ubuntu.com> Le 03/08/2016 à 14:50, Vasilisc a écrit : > Error org.freedesktop.DBus.Error.ServiceUnknown: The name > com.canonical.SafeLauncher was not provided by any .service files Hey, What is the system you trying one? If it's an snappy on classic Ubuntu you need snapd-xdg-open deb installed on the system side. Note that the xdg-open script is being included to the base image and those manual steps shouldn't be necessary once the changes land Cheers, Sebastien Bacher From vasilisc777 at gmail.com Wed Aug 3 13:19:32 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 3 Aug 2016 16:19:32 +0300 Subject: xdg-open pls help In-Reply-To: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> References: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> Message-ID: <8866adb9-33dc-94b2-247d-4a38793e4688@gmail.com> 03.08.2016 15:50, Vasilisc пишет: > Error org.freedesktop.DBus.Error.ServiceUnknown: The name > com.canonical.SafeLauncher was not provided by any .service files I add test part testsite: command: bin/xdg-open "http://ubuntu.com/" I see a problem $ app.testsite Failed to open connection to "session" message bus: Failed to connect to socket /tmp/dbus-OQWDAcdbVG: Permission denied -- Best regards, vasilisc From vasilisc777 at gmail.com Wed Aug 3 13:28:55 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 3 Aug 2016 16:28:55 +0300 Subject: xdg-open pls help In-Reply-To: References: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> <58f7abbb-8c00-8a78-b895-3863b1dc6a92@ubuntu.com> <5bcdf59f-ca13-6252-f21a-88db38a38434@gmail.com> Message-ID: <32b37915-93ab-2cd3-33af-9cb94a0f766c@gmail.com> 03.08.2016 16:25, Sebastien Bacher пишет: > Le 03/08/2016 à 15:23, Vasilisc a écrit : >> I should add snapd-xdg-open in section stage-package? > > No, you should install the deb on your ubuntu desktop, the way it works > is that the snap send a dbus signal to a service which is on the system side > > Cheers, > > Sebastien Bacher > But this automatically means that my snap work only users Ubuntu 16.10 =( http://packages.ubuntu.com/search?keywords=snapd-xdg-open&searchon=names&suite=all§ion=all yakkety (utils): Opens URLs via D-Bus [universe] 0.0.0: amd64 arm64 armhf i386 powerpc ppc64el s390x -- Best regards, vasilisc From seb128 at ubuntu.com Wed Aug 3 13:31:39 2016 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Wed, 3 Aug 2016 15:31:39 +0200 Subject: xdg-open pls help In-Reply-To: <32b37915-93ab-2cd3-33af-9cb94a0f766c@gmail.com> References: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> <58f7abbb-8c00-8a78-b895-3863b1dc6a92@ubuntu.com> <5bcdf59f-ca13-6252-f21a-88db38a38434@gmail.com> <32b37915-93ab-2cd3-33af-9cb94a0f766c@gmail.com> Message-ID: Le 03/08/2016 à 15:28, Vasilisc a écrit : > But this automatically means that my snap work only users Ubuntu 16.10 There is a SRU to backport that feature to 16.04 https://launchpad.net/ubuntu/+source/snapd-xdg-open/0.0.0~16.04 And as written earlier xdg-open is being included to the base image so those things should work out of the box in xenial with one of the next SRUs/updates Cheers, Sebastien BAcher From seb128 at ubuntu.com Wed Aug 3 13:47:34 2016 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Wed, 3 Aug 2016 15:47:34 +0200 Subject: xdg-open pls help In-Reply-To: <8866adb9-33dc-94b2-247d-4a38793e4688@gmail.com> References: <931c387f-f927-a8cc-6dc8-ea0df8eaeca8@gmail.com> <8866adb9-33dc-94b2-247d-4a38793e4688@gmail.com> Message-ID: <1bc2e938-2c12-858d-e08f-bed8af17c875@ubuntu.com> Le 03/08/2016 à 15:19, Vasilisc a écrit : > Failed to open connection to "session" message bus: Failed to connect > to socket /tmp/dbus-OQWDAcdbVG: Permission denied You might want to try to use the unity7 interface to be able to use dbus? Cheers, Sebastien Bacher From josh at pdk.io Wed Aug 3 23:07:41 2016 From: josh at pdk.io (Joshua Perry) Date: Wed, 3 Aug 2016 17:07:41 -0600 Subject: Rpi3 testing In-Reply-To: <1470221398.29378.13.camel@ubuntu.com> References: <1463592221.23678.4.camel@ubuntu.com> <1463596541.4114.10.camel@canonical.com> <1463598801.29215.2.camel@ubuntu.com> <1463599549.4114.12.camel@canonical.com> <1470221398.29378.13.camel@ubuntu.com> Message-ID: > On Aug 3, 2016, at 4:49 AM, Oliver Grawert wrote: > > hi, > Am Dienstag, den 02.08.2016, 16:44 -0600 schrieb Joshua Perry: >> I’ve been trying to do this as well but keep getting HTTP 401 in >> response to pulling the required snaps. Is there some authentication >> to the image server required? > > we are in the middle of making the switch to new image building and a > new naming scheme this week, please stay tuned, there will be > announcements soon... > > ciao > oli Thank you for the follow up, Oli. Will gadget, and kernel snaps still be needed in mostly the same format as the current system? I’d like to continue working on the pieces for our image if they aren’t going to change too much. Josh From ppa at jzimm.net Thu Aug 4 01:21:52 2016 From: ppa at jzimm.net (Jacob Zimmermann) Date: Thu, 4 Aug 2016 11:21:52 +1000 Subject: Overriding seccomp policy: shm_open In-Reply-To: <1470069296.6183.139.camel@canonical.com> References: <212b1dd3-4602-f6b8-2dab-13608a1b11e0@jzimm.net> <579EDDAA.7010904@canonical.com> <1470069296.6183.139.camel@canonical.com> Message-ID: > shm_open() is allowed in the default policy for seccomp and if the path conforms > to this from the default policy for apparmor, then there should be no issues: > > # App-specific access to files and directories in /dev/shm. We allow file > # access in /dev/shm for shm_open() and files in subdirectories for open() > /{dev,run}/shm/snap.@{SNAP_NAME}.** mrwlkix, > > I suspect you need to adjust hatari to use (perhaps conditionally if SNAP env > var is set, up to you) shm_open("snap.hatari.XXXXXX", ...) or similar. Ok I found it, in fact it was hatari trying to connect to pulseaudio. Adding pulseaudio to the plugs list solved the problem. Still, I wonder: 1) So is the moral of the story that there is no mechanism for a package maintainer to customise the security policy applicable to an individual package? That seems odd. 2) Assuming that it was necessary to patch hatari like Jamie suggested, what is the idiomatic way to apply a patch to upstream sources before compiling? Thanks Jacob From christian.ehrhardt at canonical.com Thu Aug 4 13:16:01 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Thu, 4 Aug 2016 15:16:01 +0200 Subject: How to snap packages that provide "extra" files to be used by something else Message-ID: Hi, while thinking about what I could experiment with snapping next I checked what I still use some external repositories for - as I considered those a great list of opportunities. One that I found there was my printer driver which consists of these packages [1] provided by [2]. But thinking about how that would fit into the snap world gave me a hard time, so I thought I better write it up for discussion. I mean I can only win, either by learning or by identifying something that we can convert into a valid feature request. The reason I thought this might be non-standard in regard to snaps is, that most of the functionality provided by these packages is achieved by placing files for other programs to pick it up. Some examples might be: - cups ppd files - /usr/share/cups/model/suld/ML-1740.ppd.gz - special cups filters - /usr/lib/cups/filter/pstosplc - or even libs for sane - /usr/lib/sane/libsane-smfp.so Now that doesn't fit in the (otherwise really great) sandboxing into ~/snap or /snap. Because in this case others programs should be able to pick up these files in common paths. It doesn't really qualify for an interface [3] as I thought to understand them so far. It might be somewhat close to the "home" plug in some ways - so maybe there lies the rescue. Yet the home plug it is more about the snap being able to reach out and not "others" being able to pick up the files of the snap. So what would be the preferred way to solve such issues in general when creating a snap? Thinking about it a bit further, even man-pages could be considered to fall in a very similar category right? Looking forward to learn, kind regards, Christian [1]: http://www.bchemnet.com/suldr/repository.html [2]: http://www.bchemnet.com/suldr/index.html [3]: http://snapcraft.io/docs/reference/interfaces -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Thu Aug 4 13:27:46 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 04 Aug 2016 08:27:46 -0500 Subject: Overriding seccomp policy: shm_open In-Reply-To: References: <212b1dd3-4602-f6b8-2dab-13608a1b11e0@jzimm.net> <579EDDAA.7010904@canonical.com> <1470069296.6183.139.camel@canonical.com> Message-ID: <1470317266.21843.10.camel@canonical.com> On Thu, 2016-08-04 at 11:21 +1000, Jacob Zimmermann wrote: > >  > 2) Assuming that it was necessary to patch hatari like Jamie suggested, > what is the idiomatic way to apply a patch to upstream sources before > compiling? > Once this bug is implemented, patching for something like shm_open() would not be necessary and it simply becomes a matter of packaging: https://bugs.launchpad.net/snapcraft/+bug/1577514 -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Thu Aug 4 13:53:13 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Thu, 4 Aug 2016 16:53:13 +0300 Subject: thx devs Message-ID: <4c121469-77a4-dd81-37d7-0bf900a877b1@gmail.com> Devs, thanks for your help. My contribution $ snap find vs Name Version Developer Notes Summary deadbeef-vs 0.7.2-snap1 vs - The Ultimate Music Player languagetool 3.4-snap2 vs - LanguageTool osddm 4.1.3.901-snap1 vs - Oracle SQL Developer Data Modeler tuxguitar-vs 1.3.2-snap2 vs - TuxGuitar vuze-vs 5.7.2.0-snap1 vs - Vuze is a powerful, open source, bittorrent client. -- Best regards, vasilisc From didrocks at ubuntu.com Thu Aug 4 14:24:51 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Thu, 4 Aug 2016 16:24:51 +0200 Subject: thx devs In-Reply-To: <4c121469-77a4-dd81-37d7-0bf900a877b1@gmail.com> References: <4c121469-77a4-dd81-37d7-0bf900a877b1@gmail.com> Message-ID: Le 04/08/2016 à 15:53, Vasilisc a écrit : > Devs, thanks for your help. > My contribution > > $ snap find vs > Name Version Developer Notes Summary > deadbeef-vs 0.7.2-snap1 vs - The Ultimate Music > Player > languagetool 3.4-snap2 vs - LanguageTool > osddm 4.1.3.901-snap1 vs - Oracle SQL Developer > Data Modeler > tuxguitar-vs 1.3.2-snap2 vs - TuxGuitar > vuze-vs 5.7.2.0-snap1 vs - Vuze is a powerful, > open source, bittorrent client. > Well done! Thanks a lot to you for your contributions and keeping up! Cant' wait to see your next snaps :) Cheers, Didier From blake.rouse at canonical.com Thu Aug 4 15:40:06 2016 From: blake.rouse at canonical.com (Blake Rouse) Date: Thu, 4 Aug 2016 11:40:06 -0400 Subject: ntopng strict snap published Message-ID: I have created a ntopng snap for the dev branch of ntopng. The snap works in strict mode once you connect it to the network-control interface. I currently registered the snap as ntopng-blake as ntopng is a reserved name. Let me know what you think. sudo snap install ntopng-blake sudo snap connect ntopng-blake:network-control ubuntu-core:network-control sudo systemctl restart snap.ntopng-blake.ntopng.service Login - http://localhost:3000 User - admin Pass - admin A couple things that would improve this snap are: 1. I need the ntopng service to start after the redis service. Currently in the ntopng service it loops until it can connect to redis and then spawns the ntopng process. It would be nice to say in snapcraft start this service after this other service has started. 2. Since network-control interface is a reserved interface you have to manually restart the service once the connection is made. It would be nice to say in snapcraft that this service should be restarted once the connection is made. Even better would be don't start this service until this connection is made. Overall this is an awesome way of getting ntopng running on your system, directly from tip of dev. ntopng - https://github.com/ntop/ntopng ntopng-snap - https://github.com/blakerouse/ntopng-snap Thanks, Blake Rouse -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabnhdev at gmail.com Thu Aug 4 18:58:59 2016 From: mabnhdev at gmail.com (MikeB) Date: Thu, 4 Aug 2016 14:58:59 -0400 Subject: Including custom kernel driver with a snap Message-ID: Can someone describe the strategy or point me to an example for including a custom kernel driver as part of a snap? I'm trying to put together a snap that requires several custom kernel drivers be installed along with the snap and would like to know the "snappy" way of doing this. Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Fri Aug 5 05:55:07 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 5 Aug 2016 07:55:07 +0200 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: Le 04/08/2016 à 17:40, Blake Rouse a écrit : > I have created a ntopng snap for the dev branch of ntopng. The snap > works in strict mode once you connect it to the network-control > interface. I currently registered the snap as ntopng-blake as ntopng > is a reserved name. Let me know what you think. > > sudo snap install ntopng-blake > sudo snap connect ntopng-blake:network-control ubuntu-core:network-control > sudo systemctl restart snap.ntopng-blake.ntopng.service > > Login - http://localhost:3000 > User - admin > Pass - admin > > A couple things that would improve this snap are: > > 1. I need the ntopng service to start after the redis service. > Currently in the ntopng service it loops until it can connect to redis > and then spawns the ntopng process. It would be nice to say in > snapcraft start this service after this other service has started. > > 2. Since network-control interface is a reserved interface you have to > manually restart the service once the connection is made. It would be > nice to say in snapcraft that this service should be restarted once > the connection is made. Even better would be don't start this service > until this connection is made. > > Overall this is an awesome way of getting ntopng running on your > system, directly from tip of dev. > > ntopng - https://github.com/ntop/ntopng > ntopng-snap - https://github.com/blakerouse/ntopng-snap Excellent work Blake! Do you think there is any chance that you propose it to upstream for merging your snapcraft.yaml to their upstream tree? Cheers, Didier From daniel.watkins at canonical.com Fri Aug 5 09:20:15 2016 From: daniel.watkins at canonical.com (Dan Watkins) Date: Fri, 5 Aug 2016 10:20:15 +0100 Subject: Handling update-alternatives Message-ID: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Hello all, Something I'm snapping tries to run `awk`, which isn't included in the ubuntu-core snap. As such, I added gawk to stage-packages for my part: parts: thing: ... stage-packages: - gawk Unfortunately, it didn't occur to me that awk is actually provided by update-alternatives, so just staging the package didn't provide me with `awk` on the PATH. It took me a few confusing build/examine iteration to realise what was going on, which lead to me adding: parts: thing: ... stage-packages: - gawk organize: usr/bin/gawk: usr/bin/awk This seems like a real wrinkle in the snapping experience; I both had to work out what the problem was, and then hack around it in a slightly uncomfortable way. What can we do to iron this out? My first thought was to add an `awk` part, which would allow you to specify the way in which you wanted awk to be provided (i.e. "this Ubuntu package", "build from this source") and ensure that awk would end up in the PATH of other things in the snap. My second thought was that creating a custom part for every Ubuntu package that uses update-alternatives is quite a lot of overhead. It's probably impractical, but parsing packages as they are staged to do just the `update-alternatives` step would be pretty cool. What do people think? Cheers, Dan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From evan.dandrea at canonical.com Fri Aug 5 09:33:42 2016 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Fri, 05 Aug 2016 09:33:42 +0000 Subject: Handling update-alternatives In-Reply-To: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> References: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Message-ID: On Fri, 5 Aug 2016 at 10:21 Dan Watkins wrote: > My first thought was to add an `awk` part, which would allow you to > specify the way in which you wanted awk to be provided (i.e. "this > Ubuntu package", "build from this source") and ensure that awk would end > up in the PATH of other things in the snap. > I'd create a part that builds awk from source, then add it to https://wiki.ubuntu.com/Snappy/Parts so others can benefit from your work (`snapcraft define awk`). My understanding of stage-packages is that it helps us until we have a diverse parts ecosystem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.lenton at canonical.com Fri Aug 5 10:00:47 2016 From: john.lenton at canonical.com (John Lenton) Date: Fri, 5 Aug 2016 11:00:47 +0100 Subject: Handling update-alternatives In-Reply-To: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> References: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Message-ID: On 5 August 2016 at 10:20, Dan Watkins wrote: > Something I'm snapping tries to run `awk`, which isn't included in the > ubuntu-core snap awk *is* in the ubuntu-core snap. What's happening is bug #1580018: you've used update-alternatives on the host to switch to an awk that is different to the one in core. If you can live with mawk instead of gawk on the host (at least during the build) things will work. From daniel.watkins at canonical.com Fri Aug 5 10:25:18 2016 From: daniel.watkins at canonical.com (Dan Watkins) Date: Fri, 5 Aug 2016 11:25:18 +0100 Subject: Handling update-alternatives In-Reply-To: References: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Message-ID: On 05/08/16 11:00, John Lenton wrote: > On 5 August 2016 at 10:20, Dan Watkins wrote: >> Something I'm snapping tries to run `awk`, which isn't included in the >> ubuntu-core snap > > awk *is* in the ubuntu-core snap. What's happening is bug #1580018: > you've used update-alternatives on the host to switch to an awk that > is different to the one in core. If you can live with mawk instead of > gawk on the host (at least during the build) things will work. The snapped program calls /usr/bin/awk at runtime, so I'd presumably need mawk to be installed in the host at runtime as well? (AIUI, /usr/bin/awk is a symlink to /etc/alternatives/awk which gets resolved against the host's /etc. The host's /etc/alternatives/awk points at /usr/bin/[gm]awk which is then resolved against the snap's view of the world.) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From john.lenton at canonical.com Fri Aug 5 10:27:19 2016 From: john.lenton at canonical.com (John Lenton) Date: Fri, 5 Aug 2016 11:27:19 +0100 Subject: Handling update-alternatives In-Reply-To: References: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Message-ID: On 5 August 2016 at 11:25, Dan Watkins wrote: > > The snapped program calls /usr/bin/awk at runtime, so I'd presumably > need mawk to be installed in the host at runtime as well? core has mawk, but not gawk. snaps run with the host's /etc/alternatives but core's /usr. From didrocks at ubuntu.com Fri Aug 5 11:54:33 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 5 Aug 2016 13:54:33 +0200 Subject: Handling update-alternatives In-Reply-To: References: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Message-ID: <933a351f-d0f4-d48a-087d-ef55458872fb@ubuntu.com> Le 05/08/2016 à 12:25, Dan Watkins a écrit : > On 05/08/16 11:00, John Lenton wrote: >> On 5 August 2016 at 10:20, Dan Watkins wrote: >>> Something I'm snapping tries to run `awk`, which isn't included in the >>> ubuntu-core snap >> awk *is* in the ubuntu-core snap. What's happening is bug #1580018: >> you've used update-alternatives on the host to switch to an awk that >> is different to the one in core. If you can live with mawk instead of >> gawk on the host (at least during the build) things will work. > The snapped program calls /usr/bin/awk at runtime, so I'd presumably > need mawk to be installed in the host at runtime as well? > > (AIUI, /usr/bin/awk is a symlink to /etc/alternatives/awk which gets > resolved against the host's /etc. The host's /etc/alternatives/awk > points at /usr/bin/[gm]awk which is then resolved against the snap's > view of the world.) I think that's something which could be fixed again by the request in https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1583250/ as the path is hardcoded in your program to redirect to the actual binary in $SNAP. It seems that Gustavo missed my last ping on "Trying to package angband as snap" topic (same ML) where this is referenced as well. Maybe I'll be luckier this time :) Cheers, Didier From dietmar.winkler at dwe.no Fri Aug 5 15:07:02 2016 From: dietmar.winkler at dwe.no (Dietmar Winkler) Date: Fri, 5 Aug 2016 17:07:02 +0200 Subject: Getting QT apps running. In-Reply-To: References: <83f185c8-1300-a503-f55d-9aa3f052c07a@canonical.com> <82d6e45f-eeab-03fb-df36-31adc7cf79b4@ubuntu.com> <1469784438.4310.58.camel@anubis> <1469785204.4310.64.camel@anubis> <1469790505.13113.2.camel@ubuntu.com> <1469793501.13113.21.camel@ubuntu.com> Message-ID: Hi, so I finally spend some time again on this. Since I could not get the menus to work under standard Ubuntu Unity 16.04 I thought maybe it's not the snap but something that does not agree within the desktop manager. So I simply installed ubuntu-mate-desktop and logged into standard mate. Then I rebuild the IPE application with three variants of plugs. I.e., in https://github.com/dietmarw/snaps/blob/master/ipe/snapcraft.yaml#L59 With: 1. plugs: [x11, home] 2. plugs: [unity7, home] 3. plugs: [x11, unity7, home] The result? ALL of those build worked flawlessly under Ubuntu Mate whilst under standard Ubuntu Unity (on the very same machine I get: 1. plugs: [x11, home] > ipe doesn't launch but also no errors in the terminal 2. plugs: [unity7, home] > ipe launches without menu 3. plugs: [x11, unity7, home] > ipe launches without menu Since ipe doesn't use any unity speciific stuff the right plug should actually be simply x11 (and as the FAQ pointed out https://github.com/otfried/ipe-wiki/wiki/FAQ#ipe-doesnt-work-correctly-on-ubuntu even when run natively one needs to remove the appmenu-qt5 package to get the menu). Question that still stands is why although appmenu-qt5 is NOT present, IPE would run when natively compiled (also under Unity) but only under non-unity desktop when build as a snap. Any idea how to explain this behaviour? /Dietmar/ On 29 July 2016 at 16:01, Dietmar Winkler wrote: > Thanks for the pointer. Reading through the documentation of > desktop-helper again I noticed that I might actually try the x11 plug > instead of unity7 since it is the appmenu that causes problems in the > first place. > > But now ipe would not launch at all. Also I don't get any error > messages (apart from the Gtk warnings). > > Are there any debug logs I could search for to see what is getting stuck? > > > > On 29 July 2016 at 15:34, Joe Talbott wrote: >> Note the remote parts are now at https://wiki.ubuntu.com/snapcraft/parts >> >> Cheers, >> Joe >> >> On Fri, Jul 29, 2016 at 8:53 AM, Dietmar Winkler wrote: >>> Seting the rests of the paths helped. I now have icons. The menu is >>> still missing which reminded me that there currently is an issue with >>> appmenu-qt5 which when naively compiled causes some keyboard shortcuts >>> not to work. >>> https://github.com/otfried/ipe-wiki/wiki/FAQ#ipe-doesnt-work-correctly-on-ubuntu >>> >>> I was wondering if it is possible to generate a variant of desktop/qt5 >>> without appmenu-qt5 staged. >>> >>> I've found the definition here: https://wiki.ubuntu.com/Snappy/Parts >>> but would still need the source to point to. >>> >>> -- >>> /Dietmar/ >>> >>> Secure email communication: >>> https://encrypt.to/dietmar.winkler at dwe.no >>> Public OpenPGP key: 0x235E6689 >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > /Dietmar/ > > Secure email communication: > https://encrypt.to/dietmar.winkler at dwe.no > Public OpenPGP key: 0x235E6689 -- /Dietmar/ Secure email communication: https://encrypt.to/dietmar.winkler at dwe.no Public OpenPGP key: 0x235E6689 From blake.rouse at canonical.com Fri Aug 5 18:53:17 2016 From: blake.rouse at canonical.com (Blake Rouse) Date: Fri, 5 Aug 2016 14:53:17 -0400 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: Already have pull request into the project. https://github.com/ntop/ntopng/pull/676 ntopng is a reserved name in the snappy store, so I don't know the process of getting an account that can have access to that name. Allowing them to publish under the correct name. On Fri, Aug 5, 2016 at 1:55 AM, Didier Roche wrote: > Le 04/08/2016 à 17:40, Blake Rouse a écrit : > > I have created a ntopng snap for the dev branch of ntopng. The snap > > works in strict mode once you connect it to the network-control > > interface. I currently registered the snap as ntopng-blake as ntopng > > is a reserved name. Let me know what you think. > > > > sudo snap install ntopng-blake > > sudo snap connect ntopng-blake:network-control > ubuntu-core:network-control > > sudo systemctl restart snap.ntopng-blake.ntopng.service > > > > Login - http://localhost:3000 > > User - admin > > Pass - admin > > > > A couple things that would improve this snap are: > > > > 1. I need the ntopng service to start after the redis service. > > Currently in the ntopng service it loops until it can connect to redis > > and then spawns the ntopng process. It would be nice to say in > > snapcraft start this service after this other service has started. > > > > 2. Since network-control interface is a reserved interface you have to > > manually restart the service once the connection is made. It would be > > nice to say in snapcraft that this service should be restarted once > > the connection is made. Even better would be don't start this service > > until this connection is made. > > > > Overall this is an awesome way of getting ntopng running on your > > system, directly from tip of dev. > > > > ntopng - https://github.com/ntop/ntopng > > ntopng-snap - https://github.com/blakerouse/ntopng-snap > > Excellent work Blake! > > Do you think there is any chance that you propose it to upstream for > merging your snapcraft.yaml to their upstream tree? > Cheers, > Didier > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve.langasek at canonical.com Fri Aug 5 19:52:08 2016 From: steve.langasek at canonical.com (Steve Langasek) Date: Fri, 5 Aug 2016 12:52:08 -0700 Subject: Handling update-alternatives In-Reply-To: References: <26db0052-4b6c-3172-38c3-4a7deb5bee36@canonical.com> Message-ID: <20160805195208.GB15188@virgil.dodds.net> On Fri, Aug 05, 2016 at 09:33:42AM +0000, Evan Dandrea wrote: > On Fri, 5 Aug 2016 at 10:21 Dan Watkins > wrote: > > My first thought was to add an `awk` part, which would allow you to > > specify the way in which you wanted awk to be provided (i.e. "this > > Ubuntu package", "build from this source") and ensure that awk would end > > up in the PATH of other things in the snap. > I'd create a part that builds awk from source, then add it to > https://wiki.ubuntu.com/Snappy/Parts so others can benefit from your work > (`snapcraft define awk`). > My understanding of stage-packages is that it helps us until we have a > diverse parts ecosystem. My understanding is that we have a rich repository of pre-built binaries that can be used via the stage-packages mechanism, that we should take advantage of wherever it makes sense instead of forcing rebuilds from source of standard Unix tools ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek at ubuntu.com vorlon at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vasilisc777 at gmail.com Sat Aug 6 07:37:44 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Sat, 6 Aug 2016 10:37:44 +0300 Subject: .desktop files for app-in-snap Message-ID: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> Please help me. If I launch the program in the Terminal - well done, but I can't start program from Unity Launcher. I tried to change parameter Exec in ~/.local/share/applications/app.desktop Exec=app-name Exec=snap-name.app-name Exec=$SNAP/usr/bin/start-script.sh Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) and studied case https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop but it didn't help. -- Best regards, vasilisc From vasilisc777 at gmail.com Sat Aug 6 07:47:59 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Sat, 6 Aug 2016 10:47:59 +0300 Subject: .desktop files for app-in-snap In-Reply-To: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> Message-ID: <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> > Please help me. If I launch the program in the Terminal - well done, but > I can't start program from Unity Launcher. > > I tried to change parameter Exec in ~/.local/share/applications/app.desktop > Exec=app-name > Exec=snap-name.app-name > Exec=$SNAP/usr/bin/start-script.sh > Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) > > and studied case > https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop > > but it didn't help. > suspect lines Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): As-WARNING **: failed to rescan: Failed to parse /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop file: cannot process file of type application/x-desktop -- Best regards, vasilisc From chris.wayne at canonical.com Sat Aug 6 13:54:09 2016 From: chris.wayne at canonical.com (Chris Wayne) Date: Sat, 6 Aug 2016 09:54:09 -0400 Subject: Using sudo from within a snap Message-ID: Hi guys, I seem to be having some issues while running anything as sudo from within a snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292). Is this something that's expected to work, or is this out of scope (it does work if you run the snap itself with sudo, although then it's a bit annoying as you're hit with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558 ). Thanks Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From fcole90 at gmail.com Sat Aug 6 18:53:27 2016 From: fcole90 at gmail.com (Fabio Colella) Date: Sat, 6 Aug 2016 20:53:27 +0200 Subject: Using sudo from within a snap In-Reply-To: References: Message-ID: I think using sudo should require proper plug an permission, because I assume your action to be something out of the ordinary app bounds On 6 August 2016 at 15:54, Chris Wayne wrote: > Hi guys, > > I seem to be having some issues while running anything as sudo from within > a snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/ > 1610292). Is this something that's expected to work, or is this out of > scope (it does work if you run the snap itself with sudo, although then > it's a bit annoying as you're hit with https://bugs.launchpad. > net/ubuntu/+source/snapd/+bug/1595558). > > Thanks > Chris > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppa at jzimm.net Mon Aug 8 01:34:14 2016 From: ppa at jzimm.net (Jacob Zimmermann) Date: Mon, 8 Aug 2016 11:34:14 +1000 Subject: First snaps Message-ID: <70106ffc-9807-e298-d1a0-7a9bd9d022f8@jzimm.net> Hi, I finally uploaded some small contributions: - hatari-emulator - fsuae - matroska-tools All in the Candidate channel. Best, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From didrocks at ubuntu.com Mon Aug 8 05:50:04 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 8 Aug 2016 07:50:04 +0200 Subject: .desktop files for app-in-snap In-Reply-To: <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> Message-ID: Le 06/08/2016 à 09:47, Vasilisc a écrit : >> Please help me. If I launch the program in the Terminal - well done, but >> I can't start program from Unity Launcher. >> >> I tried to change parameter Exec in >> ~/.local/share/applications/app.desktop >> Exec=app-name >> Exec=snap-name.app-name >> Exec=$SNAP/usr/bin/start-script.sh >> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) >> >> and studied case >> https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop >> >> >> but it didn't help. >> > suspect lines > Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): > As-WARNING **: failed to rescan: Failed to parse > /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop > file: cannot process file of type application/x-desktop > > Hey Vasilisc, You didn't provide your .desktop file in setup/gui/ directory. Do you mind doing this? I suspect your type is different from "Type=Application", which it should be. Didier From didrocks at ubuntu.com Mon Aug 8 06:05:12 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 8 Aug 2016 08:05:12 +0200 Subject: First snaps In-Reply-To: <70106ffc-9807-e298-d1a0-7a9bd9d022f8@jzimm.net> References: <70106ffc-9807-e298-d1a0-7a9bd9d022f8@jzimm.net> Message-ID: Le 08/08/2016 à 03:34, Jacob Zimmermann a écrit : > Hi, > > I finally uploaded some small contributions: > > - hatari-emulator > - fsuae > - matroska-tools > > All in the Candidate channel. Hey Jacob! Excellent work. I see you are looking for piece by publishing an atari and amiga emulator at the same time :) I couldn't get fsuae to work, does it require devmode? (I don't know if snapd already has the feature to warn/force people to use --devmode when confinment: devmode is set, Michael?). Did you get any issue/missing interfaces that we could report to upstream (not logged as an bug with snappy-interfaces against the snappy launchpad project)? Great work again, Didier From vasilisc777 at gmail.com Mon Aug 8 06:47:00 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Mon, 8 Aug 2016 09:47:00 +0300 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> Message-ID: 08.08.2016 08:50, Didier Roche пишет: > Le 06/08/2016 à 09:47, Vasilisc a écrit : >>> Please help me. If I launch the program in the Terminal - well done, but >>> I can't start program from Unity Launcher. >>> >>> I tried to change parameter Exec in >>> ~/.local/share/applications/app.desktop >>> Exec=app-name >>> Exec=snap-name.app-name >>> Exec=$SNAP/usr/bin/start-script.sh >>> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) >>> >>> and studied case >>> https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop >>> >>> >>> but it didn't help. >>> >> suspect lines >> Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): >> As-WARNING **: failed to rescan: Failed to parse >> /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop >> file: cannot process file of type application/x-desktop >> >> > Hey Vasilisc, > > You didn't provide your .desktop file in setup/gui/ directory. Do you > mind doing this? > I suspect your type is different from "Type=Application", which it > should be. > Didier I found a problem. My script-wrapper (usr/bin/run.sh) run java app #!/bin/bash .... bla-bla-bla .... java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar in snapcraft.yaml apps: languagetool: command: usr/bin/run.sh plugs: [network, network-bind, x11, home, unity7] If to attach the java-app to a panel Unity Launcher, then the file (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will contain. [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=LanguageTool 3.4-SNAPSHOT Icon=org-languagetool-gui-main Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 /snap/languagetool/x1/usr/bin/languagetool.jar In a host-system can't execute a command (it's impossible) java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 /snap/languagetool/x1/usr/bin/languagetool.jar I don't know what to do. -- Best regards, vasilisc From zygmunt.krynicki at canonical.com Mon Aug 8 07:30:33 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 8 Aug 2016 09:30:33 +0200 Subject: Using sudo from within a snap In-Reply-To: References: Message-ID: <0FD021A7-5D52-4FB1-B43A-AC770BDEB25C@canonical.com> > El 6 ago 2016, a las 20:53, Fabio Colella escribió: > > I think using sudo should require proper plug an permission, because I assume your action to be something out of the ordinary app bounds This is not really true. Any snap can have a background application that runs a root. Sudo feels more complicated to support but definitely doesn’t give you any more power. > > On 6 August 2016 at 15:54, Chris Wayne > wrote: > Hi guys, > > I seem to be having some issues while running anything as sudo from within a snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292 ). Is this something that's expected to work, or is this out of scope (it does work if you run the snap itself with sudo, although then it's a bit annoying as you're hit with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558 ). > > Thanks > Chris > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Mon Aug 8 07:36:42 2016 From: simon.fels at canonical.com (Simon Fels) Date: Mon, 8 Aug 2016 09:36:42 +0200 Subject: Using sudo from within a snap In-Reply-To: References: Message-ID: <37b95712-fa23-4b2d-1d3b-a5f9688221f1@canonical.com> On 06.08.2016 15:54, Chris Wayne wrote: > Hi guys, > > I seem to be having some issues while running anything as sudo from within a > snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292). If you package sudo within your snap snapcraft will strip the necessary suid bit from it so it wont work anymore. Only way to use sudo is to use the one from the core snap. > Is this something that's expected to work, or is this out of scope (it does work > if you run the snap itself with sudo, although then it's a bit annoying as > you're hit with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1595558). We should fix this so that a sudo works rather than putting sudo in a snap or use it from there. You could also check in your binary if its started as root and if not abort. regards, Simon From didrocks at ubuntu.com Mon Aug 8 07:45:08 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 8 Aug 2016 09:45:08 +0200 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> Message-ID: <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> Le 08/08/2016 à 08:47, Vasilisc a écrit : > 08.08.2016 08:50, Didier Roche пишет: >> Le 06/08/2016 à 09:47, Vasilisc a écrit : >>>> Please help me. If I launch the program in the Terminal - well done, >>>> but >>>> I can't start program from Unity Launcher. >>>> >>>> I tried to change parameter Exec in >>>> ~/.local/share/applications/app.desktop >>>> Exec=app-name >>>> Exec=snap-name.app-name >>>> Exec=$SNAP/usr/bin/start-script.sh >>>> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) >>>> >>>> and studied case >>>> https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop >>>> >>>> >>>> >>>> but it didn't help. >>>> >>> suspect lines >>> Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): >>> As-WARNING **: failed to rescan: Failed to parse >>> /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop >>> >>> file: cannot process file of type application/x-desktop >>> >>> >> Hey Vasilisc, >> >> You didn't provide your .desktop file in setup/gui/ directory. Do you >> mind doing this? >> I suspect your type is different from "Type=Application", which it >> should be. >> Didier > > I found a problem. My script-wrapper (usr/bin/run.sh) run java app > #!/bin/bash > .... bla-bla-bla .... > java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar > > in snapcraft.yaml > apps: > languagetool: > command: usr/bin/run.sh > plugs: [network, network-bind, x11, home, unity7] > > > If to attach the java-app to a panel Unity Launcher, then the file > (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will > contain. > > [Desktop Entry] > Encoding=UTF-8 > Version=1.0 > Type=Application > Name=LanguageTool 3.4-SNAPSHOT > Icon=org-languagetool-gui-main > Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 > /snap/languagetool/x1/usr/bin/languagetool.jar > > In a host-system can't execute a command (it's impossible) > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 > /snap/languagetool/x1/usr/bin/languagetool.jar > > I don't know what to do. You need to ship yourself your .desktop file, as you pointed via the vlc desktop file inside the snapcraft source. This one will have the correct Exec= after building it with snapcraft rather then one generated from unity. From eloy.garcia.pca at gmail.com Mon Aug 8 08:13:31 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Mon, 8 Aug 2016 10:13:31 +0200 Subject: .desktop files for app-in-snap In-Reply-To: <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> Message-ID: Hi! You can take a loot at snappy playpen github repository. There is an application (wallpaperdownloader) that it is java-based and it has a desktop icon working fine. This is the URL: https://github.com/ubuntu/snappy-playpen Best wishes! El 8 ago. 2016 9:46 a. m., "Didier Roche" escribió: > > Le 08/08/2016 à 08:47, Vasilisc a écrit : > > 08.08.2016 08:50, Didier Roche пишет: > >> Le 06/08/2016 à 09:47, Vasilisc a écrit : > >>>> Please help me. If I launch the program in the Terminal - well done, > >>>> but > >>>> I can't start program from Unity Launcher. > >>>> > >>>> I tried to change parameter Exec in > >>>> ~/.local/share/applications/app.desktop > >>>> Exec=app-name > >>>> Exec=snap-name.app-name > >>>> Exec=$SNAP/usr/bin/start-script.sh > >>>> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) > >>>> > >>>> and studied case > >>>> https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop > >>>> > >>>> > >>>> > >>>> but it didn't help. > >>>> > >>> suspect lines > >>> Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): > >>> As-WARNING **: failed to rescan: Failed to parse > >>> /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop > >>> > >>> file: cannot process file of type application/x-desktop > >>> > >>> > >> Hey Vasilisc, > >> > >> You didn't provide your .desktop file in setup/gui/ directory. Do you > >> mind doing this? > >> I suspect your type is different from "Type=Application", which it > >> should be. > >> Didier > > > > I found a problem. My script-wrapper (usr/bin/run.sh) run java app > > #!/bin/bash > > .... bla-bla-bla .... > > java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar > > > > in snapcraft.yaml > > apps: > > languagetool: > > command: usr/bin/run.sh > > plugs: [network, network-bind, x11, home, unity7] > > > > > > If to attach the java-app to a panel Unity Launcher, then the file > > (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will > > contain. > > > > [Desktop Entry] > > Encoding=UTF-8 > > Version=1.0 > > Type=Application > > Name=LanguageTool 3.4-SNAPSHOT > > Icon=org-languagetool-gui-main > > Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 > > /snap/languagetool/x1/usr/bin/languagetool.jar > > > > In a host-system can't execute a command (it's impossible) > > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 > > /snap/languagetool/x1/usr/bin/languagetool.jar > > > > I don't know what to do. > > You need to ship yourself your .desktop file, as you pointed via the vlc > desktop file inside the snapcraft source. > > This one will have the correct Exec= after building it with snapcraft > rather then one generated from unity. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Mon Aug 8 09:27:03 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 08 Aug 2016 11:27:03 +0200 Subject: Using sudo from within a snap In-Reply-To: <37b95712-fa23-4b2d-1d3b-a5f9688221f1@canonical.com> References: <37b95712-fa23-4b2d-1d3b-a5f9688221f1@canonical.com> Message-ID: <1470648423.29378.18.camel@ubuntu.com> hi, Am Montag, den 08.08.2016, 09:36 +0200 schrieb Simon Fels: > On 06.08.2016 15:54, Chris Wayne wrote: > > > > Hi guys, > > > > I seem to be having some issues while running anything as sudo from > > within a  > > snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+b > > ug/1610292).   > If you package sudo within your snap snapcraft will strip the > necessary > suid bit from it so it wont work anymore. Only way to use sudo is to > use > the one from the core snap. > how would you hook into /etc/sudoers (or /etc/sudoers.d/) ?  snapd would have to install or bind-mount a sudoers file above the one from the core snap ... you also need to make sure that your user exists in the password db ... both gets very hairy in an all-snap image where the core snap is actually the rootfs (and both of the above files are required for having the system functional) i could imagine a sudo interface here (for the binary) and shipping a generic /etc/sudoers.d/snapd mountpoint in the core snap where snapd/snap-confine could bind-mount a shipped sudoers snippet, but that still leaves the passwd db issue open... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ppa at jzimm.net Mon Aug 8 11:14:43 2016 From: ppa at jzimm.net (Jacob Zimmermann) Date: Mon, 8 Aug 2016 21:14:43 +1000 Subject: First snaps In-Reply-To: References: <70106ffc-9807-e298-d1a0-7a9bd9d022f8@jzimm.net> Message-ID: Hi Didier > I couldn't get fsuae to work, does it require devmode? (I don't know if > snapd already has the feature to warn/force people to use --devmode when > confinment: devmode is set, Michael?). > > Did you get any issue/missing interfaces that we could report to > upstream (not logged as an bug with snappy-interfaces against the snappy > launchpad project)? I just noticed the issue with fsuae when launched alone. I will investigate it. In the meantime it should work if you use fsuae.launcher, no devmode needed. Best, Jacob -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From dietmar.winkler at dwe.no Mon Aug 8 13:28:30 2016 From: dietmar.winkler at dwe.no (Dietmar Winkler) Date: Mon, 8 Aug 2016 15:28:30 +0200 Subject: Getting QT apps running. In-Reply-To: References: <83f185c8-1300-a503-f55d-9aa3f052c07a@canonical.com> <82d6e45f-eeab-03fb-df36-31adc7cf79b4@ubuntu.com> <1469784438.4310.58.camel@anubis> <1469785204.4310.64.camel@anubis> <1469790505.13113.2.camel@ubuntu.com> <1469793501.13113.21.camel@ubuntu.com> Message-ID: Hi, so today i decided to switch back to Unity (but still have the ubuntu-mate-desktop dependencies installed). Turns out the IPE snap is _now_ able to display the menu despite me running Unity. This was not the case before I installed the ubuntu-mate-desktop meta package. So properly confused now, especially since it seems the behaviour of snap packages (at the moment) are still _very_ dependent on installed system packages outside the snap package itself. -- /Dietmar/ Secure email communication: https://encrypt.to/dietmar.winkler at dwe.no Public OpenPGP key: 0x235E6689 From chris.j.arges at canonical.com Mon Aug 8 14:09:46 2016 From: chris.j.arges at canonical.com (Christopher Arges) Date: Mon, 8 Aug 2016 09:09:46 -0500 Subject: Connecting snap interfaces Message-ID: <20160808140945.GA7142@gmail.com> I'm snapping up a daemon and client program that requires several non-auto-connect interfaces. Right now for a user to install and run the program(s) correctly requires: snap install daemon-program_1_amd64.snap snap connect daemon-programd:hardware-observe ubuntu-core:hardware-observe snap connect daemon-programd:system-observe ubuntu-core:system-observe snap connect daemon-program:hardware-observe ubuntu-core:hardware-observe snap connect daemon-program:system-observe ubuntu-core:system-observe sudo systemctl restart snap.daemon-program.daemon-programd How can I make my snap auto-connect these special interfaces? --chris From blake.rouse at canonical.com Mon Aug 8 14:14:32 2016 From: blake.rouse at canonical.com (Blake Rouse) Date: Mon, 8 Aug 2016 10:14:32 -0400 Subject: Connecting snap interfaces In-Reply-To: <20160808140945.GA7142@gmail.com> References: <20160808140945.GA7142@gmail.com> Message-ID: I have the same problem with the ntopng snap. Instead auto connecting restricted interfaces I would prefer to see it restart the daemon that required those interfaces once all are connected. - Blake On Mon, Aug 8, 2016 at 10:09 AM, Christopher Arges < chris.j.arges at canonical.com> wrote: > I'm snapping up a daemon and client program that requires several > non-auto-connect interfaces. > > Right now for a user to install and run the program(s) correctly requires: > > snap install daemon-program_1_amd64.snap > snap connect daemon-programd:hardware-observe ubuntu-core:hardware-observe > snap connect daemon-programd:system-observe ubuntu-core:system-observe > snap connect daemon-program:hardware-observe ubuntu-core:hardware-observe > snap connect daemon-program:system-observe ubuntu-core:system-observe > sudo systemctl restart snap.daemon-program.daemon-programd > > How can I make my snap auto-connect these special interfaces? > > --chris > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Mon Aug 8 14:20:41 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 8 Aug 2016 16:20:41 +0200 Subject: Connecting snap interfaces In-Reply-To: <20160808140945.GA7142@gmail.com> References: <20160808140945.GA7142@gmail.com> Message-ID: <85E78A95-803A-4FD5-AAFF-EF37BDA860E2@canonical.com> > El 8 ago 2016, a las 16:09, Christopher Arges escribió: > > I'm snapping up a daemon and client program that requires several > non-auto-connect interfaces. > > Right now for a user to install and run the program(s) correctly requires: > > snap install daemon-program_1_amd64.snap > snap connect daemon-programd:hardware-observe ubuntu-core:hardware-observe > snap connect daemon-programd:system-observe ubuntu-core:system-observe > snap connect daemon-program:hardware-observe ubuntu-core:hardware-observe > snap connect daemon-program:system-observe ubuntu-core:system-observe > sudo systemctl restart snap.daemon-program.daemon-programd > > How can I make my snap auto-connect these special interfaces? This will be available to device makers through the gadget snap and device model assertions AFAIK. I suspect we may also allow this later on when more assertions are in place. For now I don’t know of any other way but you can track the development of ubuntu-image and the gadget snap (I don’t have any links handy but I bet the folks hacking on this will reply with more details). Best regards ZK From cemil.azizoglu at canonical.com Mon Aug 8 14:42:39 2016 From: cemil.azizoglu at canonical.com (Cemil Azizoglu) Date: Mon, 8 Aug 2016 09:42:39 -0500 Subject: snapcraft cleanbuild problem Message-ID: Hi, I've created a snap for mesa demos [1, 2] to add to the playpen. While building using "snapcraft cleanbuild" I'm getting "500 Internal Server Error" [3]. My lxc/lxd setup looks sane. Any ideas what might be wrong? Thanks [1] http://www.mesa3d.org/intro.html [2] https://cgit.freedesktop.org/mesa/demos [3] http://pastebin.ubuntu.com/22691796/ Cemil Azizoglu Mir Display Server - Team Lead Canonical USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Mon Aug 8 14:47:08 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 8 Aug 2016 11:47:08 -0300 Subject: snapcraft cleanbuild problem In-Reply-To: References: Message-ID: El 08/08/16 a las 11:42, Cemil Azizoglu escribió: > Hi, > > I've created a snap for mesa demos [1, 2] to add to the playpen. While > building using "snapcraft cleanbuild" I'm getting "500 Internal Server > Error" [3]. My lxc/lxd setup looks sane. Any ideas what might be wrong? This may be related to https://bugs.launchpad.net/snapcraft/+bug/1593409 It may not be if other containers created just work. So `dpkg-reconfigure lxd` might do the trick for you. I still need to talk to the lxd folks to figure out how to make this a seamless experience, but they have something coming up on their side that might just do the trick. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dgarrod at extremenetworks.com Mon Aug 8 15:50:57 2016 From: dgarrod at extremenetworks.com (David Garrod) Date: Mon, 8 Aug 2016 15:50:57 +0000 Subject: How do I share a namespace between snap commands? In-Reply-To: <1469638980.5406.135.camel@canonical.com> References: <1469638980.5406.135.camel@canonical.com> Message-ID: I just wanted follow up on this issue: Re: >From: Jamie Strandboge [mailto:jamie at canonical.com] >Sent: Wednesday, July 27, 2016 1:03 PM > ... > To your specific question, I would expect one app within your snap to be able to create a network namespace for another app in your snap to access. This is the core of the issue. From what I've posted can anybody see why this is not working? What's the next step? Should I continue posting here or would people prefer I file a bug report? Thanks, Dave ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From dgarrod at extremenetworks.com Mon Aug 8 16:01:18 2016 From: dgarrod at extremenetworks.com (David Garrod) Date: Mon, 8 Aug 2016 16:01:18 +0000 Subject: How do I get a postinst stage properly executed - traceroute will not install correctly In-Reply-To: References: Message-ID: Re: Ø Perhaps there should be a separate plugin which does the "true .deb" installation process in a chroot etc., but for your specific traceroute use case it seems easier to just add the missing symlinks created by update-alternatives yourself (or simply move the binaries to the expected place!) While I’m sure I could hack this particular case and add a link in the startup of my snap I don’t see this as a general solution. What if a later version of the package changes the name of the file or something. Any true solution has to be based in what is in the postinst for the version of the package being installed. This seems like a general issue to me. In order to make the whole snap concept viable surely you have to be able to take packages unchanged and have your SNAP depend on them just as packages in the non-SNAP world depend on each other. I’d really like to see a mechanism whereby the installation of a SNAP can run the post install configure step in the context of the installation. Maybe that would involve deferring some of this to the snap start if absolutely necessary but in general this would not be needed. Are there any active plans to address this fundamental design issue? ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Mon Aug 8 16:10:56 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 08 Aug 2016 18:10:56 +0200 Subject: How do I get a postinst stage properly executed - traceroute will not install correctly In-Reply-To: References: Message-ID: <1470672656.29303.16.camel@ubuntu.com> hi, On Di, 2016-08-02 at 12:35 +0200, Loïc Minier wrote: > Hi David, > > > Yes I know I can do some special messing around to try and fix up > > the installation but I don’t think that is a good idea. How can I > > get the package to install fully and correctly inside the SNAP, > > i.e. properly execute the “postinst” commands. > > > > Taking a step back, Snapcraft is a tool to help you assemble snaps > from various pieces. The stage-package feature is meant to easily > consume package contents, but it's not a perfect installation of a > .deb honoring posting etc. At the moment, it just unpacks the .deb > (dpkg -x) as if it was a tarball. > > Capturing the installation of any possible .deb and its postinst > would be quite complex: > - we'd have to run these postinsts with root permissions during the > build (however we do sudo apt install on the build-packages, so > that's technically possible albeit intrusive) > - we'd need a chroot and a way to record the changes done to this > chroot (as to extract the new files) > - we'd need to decide what to do with modified/updated files > there is one bit missing in your list: - we'd need to make sure your host doesnt get random system users or home dirs created for a stage package (which does not actually get installed on the build host but in the stage area)  imho that is the most ugly bit that prevents us from running postinsts ...  nontheless, even if you'd run them in a chroot, your paths would be broken in the resulting snap (this is true for a lot of things. starting with links over adduser calls up to update-alternatives ... not using the postinst scripts but properly setting up your start scripts inside the snap package to provide such a setup is still the sanest way here IMHO... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From blake.rouse at canonical.com Mon Aug 8 16:35:38 2016 From: blake.rouse at canonical.com (Blake Rouse) Date: Mon, 8 Aug 2016 12:35:38 -0400 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: Good news. Upstream has merged my pull request that places the snapcraft.yaml in the root of the project. I now have a question on how I can provide them with an account that will allow them to upload as ntopng. Currently ntopng is a reserved name. I would like to setup some travis CI that will auto upload tip of dev into the edge channel of "ntopng". On Fri, Aug 5, 2016 at 2:53 PM, Blake Rouse wrote: > Already have pull request into the project. > > https://github.com/ntop/ntopng/pull/676 > > ntopng is a reserved name in the snappy store, so I don't know the process > of getting an account that can have access to that name. Allowing them to > publish under the correct name. > > On Fri, Aug 5, 2016 at 1:55 AM, Didier Roche wrote: > >> Le 04/08/2016 à 17:40, Blake Rouse a écrit : >> > I have created a ntopng snap for the dev branch of ntopng. The snap >> > works in strict mode once you connect it to the network-control >> > interface. I currently registered the snap as ntopng-blake as ntopng >> > is a reserved name. Let me know what you think. >> > >> > sudo snap install ntopng-blake >> > sudo snap connect ntopng-blake:network-control >> ubuntu-core:network-control >> > sudo systemctl restart snap.ntopng-blake.ntopng.service >> > >> > Login - http://localhost:3000 >> > User - admin >> > Pass - admin >> > >> > A couple things that would improve this snap are: >> > >> > 1. I need the ntopng service to start after the redis service. >> > Currently in the ntopng service it loops until it can connect to redis >> > and then spawns the ntopng process. It would be nice to say in >> > snapcraft start this service after this other service has started. >> > >> > 2. Since network-control interface is a reserved interface you have to >> > manually restart the service once the connection is made. It would be >> > nice to say in snapcraft that this service should be restarted once >> > the connection is made. Even better would be don't start this service >> > until this connection is made. >> > >> > Overall this is an awesome way of getting ntopng running on your >> > system, directly from tip of dev. >> > >> > ntopng - https://github.com/ntop/ntopng >> > ntopng-snap - https://github.com/blakerouse/ntopng-snap >> >> Excellent work Blake! >> >> Do you think there is any chance that you propose it to upstream for >> merging your snapcraft.yaml to their upstream tree? >> Cheers, >> Didier >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Mon Aug 8 16:50:26 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 8 Aug 2016 13:50:26 -0300 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: El 08/08/16 a las 13:35, Blake Rouse escribió: > Good news. > > Upstream has merged my pull request that places the snapcraft.yaml in > the root of the project. Nice! > I now have a question on how I can provide them with an account that > will allow them to upload as ntopng. Currently ntopng is a reserved > name. I would like to setup some travis CI that will auto upload tip of > dev into the edge channel of "ntopng". Evan has some guides for setting up CI and could also solve or point you in the right direction to take the reserved name. snapcraft 2.15 should be able to allow setting up macaroons through env vars (to make it easier to use things like travis-ci) but that shouldn't stop you from using ev's current solution. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From christian.ehrhardt at canonical.com Mon Aug 8 20:06:10 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Mon, 8 Aug 2016 22:06:10 +0200 Subject: How to handle conffiles in snaps? Message-ID: Hi, I was wondering how conffiles should be handled with snapcraft / snaps in general. I understand that for a more "app" style application the configuration is mostly via some kind of UI/ webserver and it can store that "locally" in it's data dir. But for the common pattern of a server application with /etc/something.conf - how is that supposed to be working for snaps? That scheme is quite common in the server application world, so I expect there already was some thought or discussion, but my searches didn't find something good. Neither did my IRC request this afternoon so I thought it might be worth to write to the list. So in the .deb world one would have: 1. a package owning the conffile, usually the one with the binary(ies) reading the conffile 2. maintainer scripts to handle upgrade path with e.g. changed formats 3. a million guides out there in the web that refer to e.g. /etc/syslog.conf with their explanation I wonder how that should be handled when snapping such an app: 1. ok, it can belong to a snap that has the binaries consuming it. It gets a bit weird if there are multiple snaps bundling the same binaries thou (relatively rare I hope as libs don't have that much conf) 2. is there an active element in http://snapcraft.io/docs/core/updates that I missed 3. a new /etc interface being read-only for the snap? - maybe with interface-parms defining which files should be accessible? Yet how would the snap make the snap the available in /etc oon install? The only snap-centric artifact about it I found was [1]. But that feels broken/outdated as there is no "snappy" command anymore (and snap has no "config" subcommand). I'd be really happy to get some useful pointers or - if not already defined and documented - to kick off some discussion about it. [1]: https://developer.ubuntu.com/en/snappy/guides/config/ -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Mon Aug 8 20:06:10 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Mon, 8 Aug 2016 22:06:10 +0200 Subject: How to handle conffiles in snaps? Message-ID: Hi, I was wondering how conffiles should be handled with snapcraft / snaps in general. I understand that for a more "app" style application the configuration is mostly via some kind of UI/ webserver and it can store that "locally" in it's data dir. But for the common pattern of a server application with /etc/something.conf - how is that supposed to be working for snaps? That scheme is quite common in the server application world, so I expect there already was some thought or discussion, but my searches didn't find something good. Neither did my IRC request this afternoon so I thought it might be worth to write to the list. So in the .deb world one would have: 1. a package owning the conffile, usually the one with the binary(ies) reading the conffile 2. maintainer scripts to handle upgrade path with e.g. changed formats 3. a million guides out there in the web that refer to e.g. /etc/syslog.conf with their explanation I wonder how that should be handled when snapping such an app: 1. ok, it can belong to a snap that has the binaries consuming it. It gets a bit weird if there are multiple snaps bundling the same binaries thou (relatively rare I hope as libs don't have that much conf) 2. is there an active element in http://snapcraft.io/docs/core/updates that I missed 3. a new /etc interface being read-only for the snap? - maybe with interface-parms defining which files should be accessible? Yet how would the snap make the snap the available in /etc oon install? The only snap-centric artifact about it I found was [1]. But that feels broken/outdated as there is no "snappy" command anymore (and snap has no "config" subcommand). I'd be really happy to get some useful pointers or - if not already defined and documented - to kick off some discussion about it. [1]: https://developer.ubuntu.com/en/snappy/guides/config/ -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Tue Aug 9 04:52:45 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 9 Aug 2016 07:52:45 +0300 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> Message-ID: <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> 08.08.2016 11:13, Eloy García (PC Actual) пишет: > Hi! You can take a loot at snappy playpen github repository. There is an > application (wallpaperdownloader) that it is java-based and it has a > desktop icon working fine. This is the URL: > > https://github.com/ubuntu/snappy-playpen > > Best wishes! > > El 8 ago. 2016 9:46 a. m., "Didier Roche" > escribió: > > > > >> Le 08/08/2016 à 08:47, Vasilisc a écrit : >> > 08.08.2016 08:50, Didier Roche пишет: >> >> Le 06/08/2016 à 09:47, Vasilisc a écrit : >> >>>> Please help me. If I launch the program in the Terminal - well done, >> >>>> but >> >>>> I can't start program from Unity Launcher. >> >>>> >> >>>> I tried to change parameter Exec in >> >>>> ~/.local/share/applications/app.desktop >> >>>> Exec=app-name >> >>>> Exec=snap-name.app-name >> >>>> Exec=$SNAP/usr/bin/start-script.sh >> >>>> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) >> >>>> >> >>>> and studied case >> >>>>>https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop > >> >>>> >> >>>> >> >>>> >> >>>> but it didn't help. >> >>>> >> >>> suspect lines >> >>> Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): >> >>> As-WARNING **: failed to rescan: Failed to parse >> >>> > /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop >> >>> >> >>> file: cannot process file of type application/x-desktop >> >>> >> >>> >> >> Hey Vasilisc, >> >> >> >> You didn't provide your .desktop file in setup/gui/ directory. Do you >> >> mind doing this? >> >> I suspect your type is different from "Type=Application", which it >> >> should be. >> >> Didier >> > >> > I found a problem. My script-wrapper (usr/bin/run.sh) run java app >> > #!/bin/bash >> > .... bla-bla-bla .... >> > java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar >> > >> > in snapcraft.yaml >> > apps: >> > languagetool: >> > command: usr/bin/run.sh >> > plugs: [network, network-bind, x11, home, unity7] >> > >> > >> > If to attach the java-app to a panel Unity Launcher, then the file >> > (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will >> > contain. >> > >> > [Desktop Entry] >> > Encoding=UTF-8 >> > Version=1.0 >> > Type=Application >> > Name=LanguageTool 3.4-SNAPSHOT >> > Icon=org-languagetool-gui-main >> > Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 >> > /snap/languagetool/x1/usr/bin/languagetool.jar >> > >> > In a host-system can't execute a command (it's impossible) >> > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 >> > /snap/languagetool/x1/usr/bin/languagetool.jar >> > >> > I don't know what to do. >> >> You need to ship yourself your .desktop file, as you pointed via the vlc >> desktop file inside the snapcraft source. >> >> This one will have the correct Exec= after building it with snapcraft >> rather then one generated from unity. >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe > at:https://lists.ubuntu.com/mailman/listinfo/snapcraft > > 0) snap install wallpaperdownloader 81.81 MB / 81.84 MB [=============================================================================================================================================================>_] 99.97 % 1.74 MB/s wallpaperdownloader (stable) 2.1 from 'egarcia' installed 1) Run java-app wallpaperdownloader in Terminal or Alt+F2 2) To attach the program on a panel Unity. 3) cat .local/share/applications/es-estoes-wallpaperdownloader-main.desktop [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=WallpaperDownloader V2.1 Icon=es-estoes-wallpaperdownloader-main.png Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar StartupNotify=false StartupWMClass=es-estoes-wallpaperDownloader-Main OnlyShowIn=Unity; X-UnityGenerated=true --------------------------------- "Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar" If Java is not installed on your system, then you have a problem. "Exec=java" - It's not right. For example, my script-wrapper can do the useful steps BEFORE start of the java program. -- Best regards, vasilisc From vasilisc777 at gmail.com Tue Aug 9 05:31:00 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 9 Aug 2016 08:31:00 +0300 Subject: .desktop files for app-in-snap In-Reply-To: <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> Message-ID: 09.08.2016 07:52, Vasilisc пишет: > 08.08.2016 11:13, Eloy García (PC Actual) пишет: >> Hi! You can take a loot at snappy playpen github repository. There is an >> application (wallpaperdownloader) that it is java-based and it has a >> desktop icon working fine. This is the URL: >> >> https://github.com/ubuntu/snappy-playpen >> >> Best wishes! >> >> El 8 ago. 2016 9:46 a. m., "Didier Roche" > > escribió: >> >> > >> >>> Le 08/08/2016 à 08:47, Vasilisc a écrit : >>> > 08.08.2016 08:50, Didier Roche пишет: >>> >> Le 06/08/2016 à 09:47, Vasilisc a écrit : >>> >>>> Please help me. If I launch the program in the Terminal - well >>> done, >>> >>>> but >>> >>>> I can't start program from Unity Launcher. >>> >>>> >>> >>>> I tried to change parameter Exec in >>> >>>> ~/.local/share/applications/app.desktop >>> >>>> Exec=app-name >>> >>>> Exec=snap-name.app-name >>> >>>> Exec=$SNAP/usr/bin/start-script.sh >>> >>>> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) >>> >>>> >>> >>>> and studied case >>> >>>>>> https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop >>>>>> >> >> >>> >>>> >>> >>>> >>> >>>> >>> >>>> but it didn't help. >>> >>>> >>> >>> suspect lines >>> >>> Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): >>> >>> As-WARNING **: failed to rescan: Failed to parse >>> >>> >> /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop >> >>> >>> >>> >>> file: cannot process file of type application/x-desktop >>> >>> >>> >>> >>> >> Hey Vasilisc, >>> >> >>> >> You didn't provide your .desktop file in setup/gui/ directory. Do you >>> >> mind doing this? >>> >> I suspect your type is different from "Type=Application", which it >>> >> should be. >>> >> Didier >>> > >>> > I found a problem. My script-wrapper (usr/bin/run.sh) run java app >>> > #!/bin/bash >>> > .... bla-bla-bla .... >>> > java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar >>> > >>> > in snapcraft.yaml >>> > apps: >>> > languagetool: >>> > command: usr/bin/run.sh >>> > plugs: [network, network-bind, x11, home, unity7] >>> > >>> > >>> > If to attach the java-app to a panel Unity Launcher, then the file >>> > (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will >>> > contain. >>> > >>> > [Desktop Entry] >>> > Encoding=UTF-8 >>> > Version=1.0 >>> > Type=Application >>> > Name=LanguageTool 3.4-SNAPSHOT >>> > Icon=org-languagetool-gui-main >>> > Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 >>> > /snap/languagetool/x1/usr/bin/languagetool.jar >>> > >>> > In a host-system can't execute a command (it's impossible) >>> > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 >>> > /snap/languagetool/x1/usr/bin/languagetool.jar >>> > >>> > I don't know what to do. >>> >>> You need to ship yourself your .desktop file, as you pointed via the vlc >>> desktop file inside the snapcraft source. >>> >>> This one will have the correct Exec= after building it with snapcraft >>> rather then one generated from unity. >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe >> at:https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > 0) snap install wallpaperdownloader > 81.81 MB / 81.84 MB > [=============================================================================================================================================================>_] > 99.97 % 1.74 MB/s > > wallpaperdownloader (stable) 2.1 from 'egarcia' installed > > 1) Run java-app wallpaperdownloader in Terminal or Alt+F2 > > 2) To attach the program on a panel Unity. > > 3) cat .local/share/applications/es-estoes-wallpaperdownloader-main.desktop > > [Desktop Entry] > Encoding=UTF-8 > Version=1.0 > Type=Application > Name=WallpaperDownloader V2.1 > Icon=es-estoes-wallpaperdownloader-main.png > Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 > /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar > StartupNotify=false > StartupWMClass=es-estoes-wallpaperDownloader-Main > OnlyShowIn=Unity; > X-UnityGenerated=true > --------------------------------- > "Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 > /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar" > > If Java is not installed on your system, then you have a problem. > "Exec=java" - It's not right. > > For example, my script-wrapper can do the useful steps BEFORE start of > the java program. Java is not installed by default in Ubuntu 16.04.1 $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.1 LTS Release: 16.04 Codename: xenial $ java -version The program 'java' can be found in the following packages: * default-jre * gcj-5-jre-headless * openjdk-8-jre-headless * gcj-4.8-jre-headless * gcj-4.9-jre-headless * openjdk-9-jre-headless Ask your administrator to install one of them How will it work "Exec=java"? -- Best regards, vasilisc From simon.fels at canonical.com Tue Aug 9 05:38:15 2016 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 9 Aug 2016 07:38:15 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: References: Message-ID: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> On 08.08.2016 22:06, Christian Ehrhardt wrote: > Hi, > I was wondering how conffiles should be handled with snapcraft / snaps in general. > I understand that for a more "app" style application the configuration is mostly > via some kind of UI/ webserver and it can store that "locally" in it's data dir. > > But for the common pattern of a server application with /etc/something.conf - > how is that supposed to be working for snaps? > That scheme is quite common in the server application world, so I expect there > already was some thought or discussion, but my searches didn't find something good. > Neither did my IRC request this afternoon so I thought it might be worth to > write to the list. > > So in the .deb world one would have: > > 1. a package owning the conffile, usually the one with the binary(ies) reading > the conffile > 2. maintainer scripts to handle upgrade path with e.g. changed formats > 3. a million guides out there in the web that refer to e.g. /etc/syslog.conf > with their explanation > > I wonder how that should be handled when snapping such an app: > > 1. ok, it can belong to a snap that has the binaries consuming it. > It gets a bit weird if there are multiple snaps bundling the same binaries > thou (relatively rare I hope as libs don't have that much conf) > 2. is there an active element in http://snapcraft.io/docs/core/updates that I > missed > 3. a new /etc interface being read-only for the snap? - maybe with > interface-parms defining which files should be accessible? > Yet how would the snap make the snap the available in /etc oon install? All configuration files have to live within the snap itself. There is no sharing with others unless you use something like the content interface which allows sharing of content between multiple snaps. For upgrades there will be a hook at some point in the near future which will notify when your snap is upgraded and you can perform similar logic like you can do in the maintainer scripts to handle changed formts etc. But as far as I know there will be no modifications to the real /etc allowed for any application snap. You could still store conf files in SNAP_USER_DATA to get them writable by the users of the system. > The only snap-centric artifact about it I found was [1]. But that feels > broken/outdated as there is no "snappy" command anymore (and snap has no > "config" subcommand). Something similar will come back. From what I've heard there will be a apply-config hook which you can implement in your snap and a user can call from the outside with a simple 'snap set snap.name.confkey=confvalue' or similar. If you don't want to wait for that you could hack something for the moment by adding a simple app to your snap which writes configuration files in SNAP_DATA/SNAP_USER_DATA and can be called by the user with ".config " and switch to the hook once it landed. I hope that helps a bit. regards, Simon From simon.fels at canonical.com Tue Aug 9 05:38:15 2016 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 9 Aug 2016 07:38:15 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: References: Message-ID: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> On 08.08.2016 22:06, Christian Ehrhardt wrote: > Hi, > I was wondering how conffiles should be handled with snapcraft / snaps in general. > I understand that for a more "app" style application the configuration is mostly > via some kind of UI/ webserver and it can store that "locally" in it's data dir. > > But for the common pattern of a server application with /etc/something.conf - > how is that supposed to be working for snaps? > That scheme is quite common in the server application world, so I expect there > already was some thought or discussion, but my searches didn't find something good. > Neither did my IRC request this afternoon so I thought it might be worth to > write to the list. > > So in the .deb world one would have: > > 1. a package owning the conffile, usually the one with the binary(ies) reading > the conffile > 2. maintainer scripts to handle upgrade path with e.g. changed formats > 3. a million guides out there in the web that refer to e.g. /etc/syslog.conf > with their explanation > > I wonder how that should be handled when snapping such an app: > > 1. ok, it can belong to a snap that has the binaries consuming it. > It gets a bit weird if there are multiple snaps bundling the same binaries > thou (relatively rare I hope as libs don't have that much conf) > 2. is there an active element in http://snapcraft.io/docs/core/updates that I > missed > 3. a new /etc interface being read-only for the snap? - maybe with > interface-parms defining which files should be accessible? > Yet how would the snap make the snap the available in /etc oon install? All configuration files have to live within the snap itself. There is no sharing with others unless you use something like the content interface which allows sharing of content between multiple snaps. For upgrades there will be a hook at some point in the near future which will notify when your snap is upgraded and you can perform similar logic like you can do in the maintainer scripts to handle changed formts etc. But as far as I know there will be no modifications to the real /etc allowed for any application snap. You could still store conf files in SNAP_USER_DATA to get them writable by the users of the system. > The only snap-centric artifact about it I found was [1]. But that feels > broken/outdated as there is no "snappy" command anymore (and snap has no > "config" subcommand). Something similar will come back. From what I've heard there will be a apply-config hook which you can implement in your snap and a user can call from the outside with a simple 'snap set snap.name.confkey=confvalue' or similar. If you don't want to wait for that you could hack something for the moment by adding a simple app to your snap which writes configuration files in SNAP_DATA/SNAP_USER_DATA and can be called by the user with ".config " and switch to the hook once it landed. I hope that helps a bit. regards, Simon From ian.booth at canonical.com Tue Aug 9 05:46:59 2016 From: ian.booth at canonical.com (Ian Booth) Date: Tue, 9 Aug 2016 15:46:59 +1000 Subject: godeps plugin enhancement... maybe? Message-ID: <8d2e4de5-d571-dde4-62b3-858cd4f1d73e@canonical.com> Hi folks Firstly, thanks for the recent godeps plugin. I'd like to be able to control where the git checkout goes, or better just snap from source. When the pull step runs, it places all the source into /parts/juju/go/src It takes a loooong time to checkout everything and then run godeps, especially when godeps runs to pull all the dependencies one by one. I'd love to be able to have the plugin be able to use an existing source tree in my gopath which I have checked out and already pulled dependencies for (ie the place where I work with my IDE). That way my workflow could be to hack on my code locally, and then build the snap directly from source on disk; godeps will just skip over almost all the dependencies since they already exist. I can see that snapcraft supports source types of git, bzr, hg, svn, tar, or zip. I really want a source type of "file" and I give it a directory like ~/projects/juju/go/src The above would be used in lieu of /parts/juju/go/src By having a source type of "file", the git pull step would not be required and my local development workflow would be much better and faster - hack in my IDE, build snap, test etc. Is there a way to do that now that I am not aware of, or is this a "patches accepted" thing? From simon.fels at canonical.com Tue Aug 9 05:50:59 2016 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 9 Aug 2016 07:50:59 +0200 Subject: godeps plugin enhancement... maybe? In-Reply-To: <8d2e4de5-d571-dde4-62b3-858cd4f1d73e@canonical.com> References: <8d2e4de5-d571-dde4-62b3-858cd4f1d73e@canonical.com> Message-ID: <04fc5567-11b2-6435-21f7-1939d08d8ed1@canonical.com> On 09.08.2016 07:46, Ian Booth wrote: > Hi folks > > Firstly, thanks for the recent godeps plugin. > > I'd like to be able to control where the git checkout goes, or better just snap > from source. When the pull step runs, it places all the source into > /parts/juju/go/src > > It takes a loooong time to checkout everything and then run godeps, especially > when godeps runs to pull all the dependencies one by one. > > I'd love to be able to have the plugin be able to use an existing source tree in > my gopath which I have checked out and already pulled dependencies for (ie the > place where I work with my IDE). That way my workflow could be to hack on my > code locally, and then build the snap directly from source on disk; godeps will > just skip over almost all the dependencies since they already exist. > > I can see that snapcraft supports source types of git, bzr, hg, svn, tar, or zip. > I really want a source type of "file" and I give it a directory like > ~/projects/juju/go/src You could just specify: source: . to build from the same directory the snapcraft.yaml file is in or specify another dir like source: /home/ubuntu/my-source-checkout But not really sure if that works for Go as well and if the GOPATH is correctly setup. regards, Simon > The above would be used in lieu of /parts/juju/go/src > > By having a source type of "file", the git pull step would not be required and > my local development workflow would be much better and faster - hack in my IDE, > build snap, test etc. > > Is there a way to do that now that I am not aware of, or is this a "patches > accepted" thing? > From ian.booth at canonical.com Tue Aug 9 06:01:42 2016 From: ian.booth at canonical.com (Ian Booth) Date: Tue, 9 Aug 2016 16:01:42 +1000 Subject: godeps plugin enhancement... maybe? In-Reply-To: <04fc5567-11b2-6435-21f7-1939d08d8ed1@canonical.com> References: <8d2e4de5-d571-dde4-62b3-858cd4f1d73e@canonical.com> <04fc5567-11b2-6435-21f7-1939d08d8ed1@canonical.com> Message-ID: <1d00b3e0-8a19-e7a4-a877-9c934c0696a2@canonical.com> I tried: source: /path/to/my/go/juju/src But it seems the godeps plugin ignores that as it still wanted to run godeps in /parts/juju/src/dependencies.tsv The plugin is really new, and works well with git sources. Just not directories yet. On 09/08/16 15:50, Simon Fels wrote: > On 09.08.2016 07:46, Ian Booth wrote: >> Hi folks >> >> Firstly, thanks for the recent godeps plugin. >> >> I'd like to be able to control where the git checkout goes, or better just snap >> from source. When the pull step runs, it places all the source into >> /parts/juju/go/src >> >> It takes a loooong time to checkout everything and then run godeps, especially >> when godeps runs to pull all the dependencies one by one. >> >> I'd love to be able to have the plugin be able to use an existing source tree in >> my gopath which I have checked out and already pulled dependencies for (ie the >> place where I work with my IDE). That way my workflow could be to hack on my >> code locally, and then build the snap directly from source on disk; godeps will >> just skip over almost all the dependencies since they already exist. >> >> I can see that snapcraft supports source types of git, bzr, hg, svn, tar, or zip. >> I really want a source type of "file" and I give it a directory like >> ~/projects/juju/go/src > > You could just specify: > > source: . > > to build from the same directory the snapcraft.yaml file is in or > specify another dir like > > source: /home/ubuntu/my-source-checkout > > But not really sure if that works for Go as well and if the GOPATH is > correctly setup. > > regards, > Simon > >> The above would be used in lieu of /parts/juju/go/src >> >> By having a source type of "file", the git pull step would not be required and >> my local development workflow would be much better and faster - hack in my IDE, >> build snap, test etc. >> >> Is there a way to do that now that I am not aware of, or is this a "patches >> accepted" thing? >> > > From didrocks at ubuntu.com Tue Aug 9 06:08:19 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Tue, 9 Aug 2016 08:08:19 +0200 Subject: How do I share a namespace between snap commands? In-Reply-To: References: <1469638980.5406.135.camel@canonical.com> Message-ID: <82b76113-3b81-3e33-688b-36bca351c11a@ubuntu.com> Le 08/08/2016 à 17:50, David Garrod a écrit : > I just wanted follow up on this issue: > > Re: > >> From: Jamie Strandboge [mailto:jamie at canonical.com] >> Sent: Wednesday, July 27, 2016 1:03 PM >> ... >> To your specific question, I would expect one app within your snap to be able to create a network namespace for another app in your snap to access. > This is the core of the issue. From what I've posted can anybody see why this is not working? What's the next step? Should I continue posting here or would people prefer I file a bug report? Hey David, even if you continue posting here (which is good to trigger discussion), please file a bug against the snappy launchpad project: https://launchpad.net/snappy/ (even if I think this one may impact rather snap-confine, but it will be redirected) Didier From nick.moffitt at canonical.com Tue Aug 9 07:01:30 2016 From: nick.moffitt at canonical.com (Nick Moffitt) Date: Tue, 9 Aug 2016 07:01:30 +0000 Subject: How to handle conffiles in snaps? In-Reply-To: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> Message-ID: <20160809070130.GC17712@zork.net> Simon Fels: > On 08.08.2016 22:06, Christian Ehrhardt wrote: > > I was wondering how conffiles should be handled with snapcraft / > > snaps in general. [...] > You could still store conf files in SNAP_USER_DATA to get them writable > by the users of the system. Is there a good facility for install-time copying of template configs or other writeable-from-initial-state data into $SNAP_USER_DATA? The way snaps are invoked do a great job of hijacking the $*PATH variables used to find executables and shared objects, but often we need to hack in a lot of shuffling around for /usr/share and /etc and /var/ to aim them at snappy's special directories. -- Nick Moffitt From nick.moffitt at canonical.com Tue Aug 9 07:01:30 2016 From: nick.moffitt at canonical.com (Nick Moffitt) Date: Tue, 9 Aug 2016 07:01:30 +0000 Subject: How to handle conffiles in snaps? In-Reply-To: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> Message-ID: <20160809070130.GC17712@zork.net> Simon Fels: > On 08.08.2016 22:06, Christian Ehrhardt wrote: > > I was wondering how conffiles should be handled with snapcraft / > > snaps in general. [...] > You could still store conf files in SNAP_USER_DATA to get them writable > by the users of the system. Is there a good facility for install-time copying of template configs or other writeable-from-initial-state data into $SNAP_USER_DATA? The way snaps are invoked do a great job of hijacking the $*PATH variables used to find executables and shared objects, but often we need to hack in a lot of shuffling around for /usr/share and /etc and /var/ to aim them at snappy's special directories. -- Nick Moffitt From eloy.garcia.pca at gmail.com Tue Aug 9 07:05:26 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 9 Aug 2016 09:05:26 +0200 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> Message-ID: Hi again! You don't need to have java installed on your system. This is the "magic" of a snap package, that you can include anything your application needs to run properly. I use maven plugin for my application, so openjdk 8 is installed within the snap package. El 9 ago. 2016 7:31 a. m., "Vasilisc" escribió: > 09.08.2016 07:52, Vasilisc пишет: > >> 08.08.2016 11:13, Eloy García (PC Actual) пишет: >> >>> Hi! You can take a loot at snappy playpen github repository. There is an >>> application (wallpaperdownloader) that it is java-based and it has a >>> desktop icon working fine. This is the URL: >>> >>> https://github.com/ubuntu/snappy-playpen >>> >>> Best wishes! >>> >>> El 8 ago. 2016 9:46 a. m., "Didier Roche" >> > escribió: >>> >>> > >>> >>> Le 08/08/2016 à 08:47, Vasilisc a écrit : >>>> > 08.08.2016 08:50, Didier Roche пишет: >>>> >> Le 06/08/2016 à 09:47, Vasilisc a écrit : >>>> >>>> Please help me. If I launch the program in the Terminal - well >>>> done, >>>> >>>> but >>>> >>>> I can't start program from Unity Launcher. >>>> >>>> >>>> >>>> I tried to change parameter Exec in >>>> >>>> ~/.local/share/applications/app.desktop >>>> >>>> Exec=app-name >>>> >>>> Exec=snap-name.app-name >>>> >>>> Exec=$SNAP/usr/bin/start-script.sh >>>> >>>> Exec=$snap.$app (http://snapcraft.io/docs/snaps/structure) >>>> >>>> >>>> >>>> and studied case >>>> >>>> https://github.com/ubuntu/snappy-playpen/blob/master/vlc/ >>>>>>> setup/gui/vlc.desktop >>>>>>> >>>>>>> >> setup/gui/vlc.desktop> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> but it didn't help. >>>> >>>> >>>> >>> suspect lines >>>> >>> Aug 6 10:20:35 vb gnome-session[2377]: (gnome-software:2582): >>>> >>> As-WARNING **: failed to rescan: Failed to parse >>>> >>> >>>> >>> /home/vasilisc/.local/share/applications/org-languagetool-gu >>> i-main.desktop >>> >>> >>> >>>> >>> file: cannot process file of type application/x-desktop >>>> >>> >>>> >>> >>>> >> Hey Vasilisc, >>>> >> >>>> >> You didn't provide your .desktop file in setup/gui/ directory. Do you >>>> >> mind doing this? >>>> >> I suspect your type is different from "Type=Application", which it >>>> >> should be. >>>> >> Didier >>>> > >>>> > I found a problem. My script-wrapper (usr/bin/run.sh) run java app >>>> > #!/bin/bash >>>> > .... bla-bla-bla .... >>>> > java -jar -Duser.home=$SNAP_USER_DATA $SNAP/usr/bin/languagetool.jar >>>> > >>>> > in snapcraft.yaml >>>> > apps: >>>> > languagetool: >>>> > command: usr/bin/run.sh >>>> > plugs: [network, network-bind, x11, home, unity7] >>>> > >>>> > >>>> > If to attach the java-app to a panel Unity Launcher, then the file >>>> > (~/.local/shape/applications/org-languagetool-gui-main.desktop ) will >>>> > contain. >>>> > >>>> > [Desktop Entry] >>>> > Encoding=UTF-8 >>>> > Version=1.0 >>>> > Type=Application >>>> > Name=LanguageTool 3.4-SNAPSHOT >>>> > Icon=org-languagetool-gui-main >>>> > Exec=java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 >>>> > /snap/languagetool/x1/usr/bin/languagetool.jar >>>> > >>>> > In a host-system can't execute a command (it's impossible) >>>> > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 >>>> > /snap/languagetool/x1/usr/bin/languagetool.jar >>>> > >>>> > I don't know what to do. >>>> >>>> You need to ship yourself your .desktop file, as you pointed via the vlc >>>> desktop file inside the snapcraft source. >>>> >>>> This one will have the correct Exec= after building it with snapcraft >>>> rather then one generated from unity. >>>> >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe >>>> >>> at:https://lists.ubuntu.com/mailman/listinfo/snapcraft >>> >>> >>> 0) snap install wallpaperdownloader >> 81.81 MB / 81.84 MB >> [=========================================================== >> ============================================================ >> ======================================>_] >> 99.97 % 1.74 MB/s >> >> wallpaperdownloader (stable) 2.1 from 'egarcia' installed >> >> 1) Run java-app wallpaperdownloader in Terminal or Alt+F2 >> >> 2) To attach the program on a panel Unity. >> >> 3) cat .local/share/applications/es-estoes-wallpaperdownloader-main >> .desktop >> >> [Desktop Entry] >> Encoding=UTF-8 >> Version=1.0 >> Type=Application >> Name=WallpaperDownloader V2.1 >> Icon=es-estoes-wallpaperdownloader-main.png >> Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 >> /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar >> StartupNotify=false >> StartupWMClass=es-estoes-wallpaperDownloader-Main >> OnlyShowIn=Unity; >> X-UnityGenerated=true >> --------------------------------- >> "Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 >> /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar" >> >> If Java is not installed on your system, then you have a problem. >> "Exec=java" - It's not right. >> >> For example, my script-wrapper can do the useful steps BEFORE start of >> the java program. >> > Java is not installed by default in Ubuntu 16.04.1 > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 16.04.1 LTS > Release: 16.04 > Codename: xenial > > $ java -version > The program 'java' can be found in the following packages: > * default-jre > * gcj-5-jre-headless > * openjdk-8-jre-headless > * gcj-4.8-jre-headless > * gcj-4.9-jre-headless > * openjdk-9-jre-headless > Ask your administrator to install one of them > > How will it work "Exec=java"? > > -- > Best regards, > vasilisc > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Tue Aug 9 07:18:21 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 9 Aug 2016 09:18:21 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> Message-ID: On Tue, Aug 9, 2016 at 7:38 AM, Simon Fels wrote: Thanks a lot Simon for the answers! A few clarifications requests inline below (mostly getting the bug # to subscribe and refer). For upgrades > there will be a hook at some point in the near future which will notify > when your snap is upgraded and you can perform similar logic like you > can do in the maintainer scripts to handle changed formts etc. But as > far as I know there will be no modifications to the real /etc allowed > for any application snap. > Ok, I consider this WIP then - is there a bug I could subscribe myself and link to from my code? > You could still store conf files in SNAP_USER_DATA to get them writable > by the users of the system. > It is a daemon that needs the conf, so I think I'll try hack something up in SNAP_DATA for now. > > The only snap-centric artifact about it I found was [1]. But that feels > > broken/outdated as there is no "snappy" command anymore (and snap has no > > "config" subcommand). > > Something similar will come back. From what I've heard there will be a > apply-config hook which you can implement in your snap and a user can > call from the outside with a simple 'snap set > snap.name.confkey=confvalue' or similar. > Thanks, as above I consider this WIP then - is there a bug I could subscribe myself and link to from my code? -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Tue Aug 9 07:18:21 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 9 Aug 2016 09:18:21 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> Message-ID: On Tue, Aug 9, 2016 at 7:38 AM, Simon Fels wrote: Thanks a lot Simon for the answers! A few clarifications requests inline below (mostly getting the bug # to subscribe and refer). For upgrades > there will be a hook at some point in the near future which will notify > when your snap is upgraded and you can perform similar logic like you > can do in the maintainer scripts to handle changed formts etc. But as > far as I know there will be no modifications to the real /etc allowed > for any application snap. > Ok, I consider this WIP then - is there a bug I could subscribe myself and link to from my code? > You could still store conf files in SNAP_USER_DATA to get them writable > by the users of the system. > It is a daemon that needs the conf, so I think I'll try hack something up in SNAP_DATA for now. > > The only snap-centric artifact about it I found was [1]. But that feels > > broken/outdated as there is no "snappy" command anymore (and snap has no > > "config" subcommand). > > Something similar will come back. From what I've heard there will be a > apply-config hook which you can implement in your snap and a user can > call from the outside with a simple 'snap set > snap.name.confkey=confvalue' or similar. > Thanks, as above I consider this WIP then - is there a bug I could subscribe myself and link to from my code? -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Tue Aug 9 07:23:52 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 9 Aug 2016 10:23:52 +0300 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> Message-ID: 09.08.2016 10:05, Eloy García (PC Actual) пишет: > Hi again! > You don't need to have java installed on your system. This is the > "magic" of a snap package, that you can include anything your > application needs to run properly. I use maven plugin for my > application, so openjdk 8 is installed within the snap package. Please, create the virtual machine with Ubuntu 16.04. Install - sudo snap install wallpaperdownloader run wallpaperdownloader in Terminal and pin app close wallpaperdownloader and launch app from Unity Launcher. something happening? none! "Exec=java" try execute Java in the host, but Java is not installed by default. Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java Sorry for my english. really only I see a problem? > > El 9 ago. 2016 7:31 a. m., "Vasilisc" > escribió: > > 09.08.2016 07:52, Vasilisc пишет: > > 08.08.2016 11:13, Eloy García (PC Actual) пишет: > > Hi! You can take a loot at snappy playpen github repository. > There is an > application (wallpaperdownloader) that it is java-based and > it has a > desktop icon working fine. This is the URL: > > https://github.com/ubuntu/snappy-playpen > > > Best wishes! > > El 8 ago. 2016 9:46 a. m., "Didier Roche" > > >> > escribió: > > > > > Le 08/08/2016 à 08:47, Vasilisc a écrit : > > 08.08.2016 08:50, Didier Roche пишет: > >> Le 06/08/2016 à 09:47, Vasilisc a écrit : > >>>> Please help me. If I launch the program in the > Terminal - well > done, > >>>> but > >>>> I can't start program from Unity Launcher. > >>>> > >>>> I tried to change parameter Exec in > >>>> ~/.local/share/applications/app.desktop > >>>> Exec=app-name > >>>> Exec=snap-name.app-name > >>>> Exec=$SNAP/usr/bin/start-script.sh > >>>> Exec=$snap.$app > (http://snapcraft.io/docs/snaps/structure > ) > >>>> > >>>> and studied case > > https://github.com/ubuntu/snappy-playpen/blob/master/vlc/setup/gui/vlc.desktop > > > > > > >>>> > >>>> > >>>> > >>>> but it didn't help. > >>>> > >>> suspect lines > >>> Aug 6 10:20:35 vb gnome-session[2377]: > (gnome-software:2582): > >>> As-WARNING **: failed to rescan: Failed to parse > >>> > > /home/vasilisc/.local/share/applications/org-languagetool-gui-main.desktop > > >>> > >>> file: cannot process file of type application/x-desktop > >>> > >>> > >> Hey Vasilisc, > >> > >> You didn't provide your .desktop file in setup/gui/ > directory. Do you > >> mind doing this? > >> I suspect your type is different from > "Type=Application", which it > >> should be. > >> Didier > > > > I found a problem. My script-wrapper (usr/bin/run.sh) > run java app > > #!/bin/bash > > .... bla-bla-bla .... > > java -jar -Duser.home=$SNAP_USER_DATA > $SNAP/usr/bin/languagetool.jar > > > > in snapcraft.yaml > > apps: > > languagetool: > > command: usr/bin/run.sh > > plugs: [network, network-bind, x11, home, unity7] > > > > > > If to attach the java-app to a panel Unity Launcher, > then the file > > > (~/.local/shape/applications/org-languagetool-gui-main.desktop > ) will > > contain. > > > > [Desktop Entry] > > Encoding=UTF-8 > > Version=1.0 > > Type=Application > > Name=LanguageTool 3.4-SNAPSHOT > > Icon=org-languagetool-gui-main > > Exec=java -jar > -Duser.home=/home/vasilisc/snap/languagetool/x1 > > /snap/languagetool/x1/usr/bin/languagetool.jar > > > > In a host-system can't execute a command (it's impossible) > > java -jar -Duser.home=/home/vasilisc/snap/languagetool/x1 > > /snap/languagetool/x1/usr/bin/languagetool.jar > > > > I don't know what to do. > > You need to ship yourself your .desktop file, as you > pointed via the vlc > desktop file inside the snapcraft source. > > This one will have the correct Exec= after building it > with snapcraft > rather then one generated from unity. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe > > at:https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > 0) snap install wallpaperdownloader > 81.81 MB / 81.84 MB > [=============================================================================================================================================================>_] > 99.97 % 1.74 MB/s > > wallpaperdownloader (stable) 2.1 from 'egarcia' installed > > 1) Run java-app wallpaperdownloader in Terminal or Alt+F2 > > 2) To attach the program on a panel Unity. > > 3) cat > .local/share/applications/es-estoes-wallpaperdownloader-main.desktop > > [Desktop Entry] > Encoding=UTF-8 > Version=1.0 > Type=Application > Name=WallpaperDownloader V2.1 > Icon=es-estoes-wallpaperdownloader-main.png > Exec=java -jar -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 > /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar > StartupNotify=false > StartupWMClass=es-estoes-wallpaperDownloader-Main > OnlyShowIn=Unity; > X-UnityGenerated=true > --------------------------------- > "Exec=java -jar > -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 > /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar" > > If Java is not installed on your system, then you have a problem. > "Exec=java" - It's not right. > > For example, my script-wrapper can do the useful steps BEFORE > start of > the java program. > > Java is not installed by default in Ubuntu 16.04.1 > $ lsb_release -a > No LSB modules are available. > Distributor ID: Ubuntu > Description: Ubuntu 16.04.1 LTS > Release: 16.04 > Codename: xenial > > $ java -version > The program 'java' can be found in the following packages: > * default-jre > * gcj-5-jre-headless > * openjdk-8-jre-headless > * gcj-4.8-jre-headless > * gcj-4.9-jre-headless > * openjdk-9-jre-headless > Ask your administrator to install one of them > > How will it work "Exec=java"? > > -- > Best regards, > vasilisc > -- Best regards, vasilisc From christian.ehrhardt at canonical.com Tue Aug 9 07:29:01 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 9 Aug 2016 09:29:01 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: <20160809070130.GC17712@zork.net> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> <20160809070130.GC17712@zork.net> Message-ID: On Tue, Aug 9, 2016 at 9:01 AM, Nick Moffitt wrote: > > You could still store conf files in SNAP_USER_DATA to get them writable > > by the users of the system. > > Is there a good facility for install-time copying of template configs or > other writeable-from-initial-state data into $SNAP_USER_DATA? > > The way snaps are invoked do a great job of hijacking the $*PATH > variables used to find executables and shared objects, but often we need > to hack in a lot of shuffling around for /usr/share and /etc and /var/ > to aim them at snappy's special directories. Yeah, that is a good question as well. As you said, for now there is a lot of hacking to get access to those and since there is no defined way (I'd know of) to provide templates. But there is no need every app (re-)implements such hacks that in some other way. So +1 for an official snapcraft/snap way to make files available in $SNAP_USER_DATA and such. I'd think of something like support for that in the copy plugin like supporting: parts: defaultconf: plugin: copy files: etc/example.conf: $SNAP_USER_DATA/etc/foo.conf Surely there is some more magic glue involved as on "snap building time" the path of $SNAP_USER_DATA and such isn't fix IIRC (could change per setup and in future). Worth a feature request bug? I'll wait for the discussion first. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Tue Aug 9 07:29:01 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 9 Aug 2016 09:29:01 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: <20160809070130.GC17712@zork.net> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> <20160809070130.GC17712@zork.net> Message-ID: On Tue, Aug 9, 2016 at 9:01 AM, Nick Moffitt wrote: > > You could still store conf files in SNAP_USER_DATA to get them writable > > by the users of the system. > > Is there a good facility for install-time copying of template configs or > other writeable-from-initial-state data into $SNAP_USER_DATA? > > The way snaps are invoked do a great job of hijacking the $*PATH > variables used to find executables and shared objects, but often we need > to hack in a lot of shuffling around for /usr/share and /etc and /var/ > to aim them at snappy's special directories. Yeah, that is a good question as well. As you said, for now there is a lot of hacking to get access to those and since there is no defined way (I'd know of) to provide templates. But there is no need every app (re-)implements such hacks that in some other way. So +1 for an official snapcraft/snap way to make files available in $SNAP_USER_DATA and such. I'd think of something like support for that in the copy plugin like supporting: parts: defaultconf: plugin: copy files: etc/example.conf: $SNAP_USER_DATA/etc/foo.conf Surely there is some more magic glue involved as on "snap building time" the path of $SNAP_USER_DATA and such isn't fix IIRC (could change per setup and in future). Worth a feature request bug? I'll wait for the discussion first. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From eloy.garcia.pca at gmail.com Tue Aug 9 07:48:42 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 9 Aug 2016 09:48:42 +0200 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> Message-ID: Hi again Vasilisc. Now I see the problem. If you pin the application executed from the terminal, the Operating System creates its own standard launcher and "bypasses" the init script you have defined within the snap package. Instead, if you want to pin a snap application, you have to use the launcher which was created in the dashboard (it has the icon you defined within the snap package). I think it is a limitation that you cannot handle, but please, if anyone knows how to deal with it... :) Best, Eloy 2016-08-09 9:23 GMT+02:00 Vasilisc : > 09.08.2016 10:05, Eloy García (PC Actual) пишет: > >> Hi again! >> You don't need to have java installed on your system. This is the >> "magic" of a snap package, that you can include anything your >> application needs to run properly. I use maven plugin for my >> application, so openjdk 8 is installed within the snap package. >> > > Please, create the virtual machine with Ubuntu 16.04. > Install - sudo snap install wallpaperdownloader > > run wallpaperdownloader in Terminal and pin app > > close wallpaperdownloader and launch app from Unity Launcher. > something happening? none! > > "Exec=java" try execute Java in the host, but Java is not installed by > default. > > Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java > Sorry for my english. really only I see a problem? > > >> El 9 ago. 2016 7:31 a. m., "Vasilisc" > > escribió: >> >> 09.08.2016 07:52, Vasilisc пишет: >> >> 08.08.2016 11:13, Eloy García (PC Actual) пишет: >> >> Hi! You can take a loot at snappy playpen github repository. >> There is an >> application (wallpaperdownloader) that it is java-based and >> it has a >> desktop icon working fine. This is the URL: >> >> https://github.com/ubuntu/snappy-playpen >> >> >> Best wishes! >> >> El 8 ago. 2016 9:46 a. m., "Didier Roche" >> >> >> >> escribió: >> >> > >> >> Le 08/08/2016 à 08:47, Vasilisc a écrit : >> > 08.08.2016 08:50, Didier Roche пишет: >> >> Le 06/08/2016 à 09:47, Vasilisc a écrit : >> >>>> Please help me. If I launch the program in the >> Terminal - well >> done, >> >>>> but >> >>>> I can't start program from Unity Launcher. >> >>>> >> >>>> I tried to change parameter Exec in >> >>>> ~/.local/share/applications/app.desktop >> >>>> Exec=app-name >> >>>> Exec=snap-name.app-name >> >>>> Exec=$SNAP/usr/bin/start-script.sh >> >>>> Exec=$snap.$app >> (http://snapcraft.io/docs/snaps/structure >> ) >> >> >>>> >> >>>> and studied case >> >> https://github.com/ubuntu/snap >> py-playpen/blob/master/vlc/setup/gui/vlc.desktop >> > ppy-playpen/blob/master/vlc/setup/gui/vlc.desktop> >> >> > setup/gui/vlc.desktop >> > setup/gui/vlc.desktop>> >> >> >>>> >> >>>> >> >>>> >> >>>> but it didn't help. >> >>>> >> >>> suspect lines >> >>> Aug 6 10:20:35 vb gnome-session[2377]: >> (gnome-software:2582): >> >>> As-WARNING **: failed to rescan: Failed to parse >> >>> >> >> /home/vasilisc/.local/share/applications/org-languagetool-gu >> i-main.desktop >> >> >>> >> >>> file: cannot process file of type >> application/x-desktop >> >>> >> >>> >> >> Hey Vasilisc, >> >> >> >> You didn't provide your .desktop file in setup/gui/ >> directory. Do you >> >> mind doing this? >> >> I suspect your type is different from >> "Type=Application", which it >> >> should be. >> >> Didier >> > >> > I found a problem. My script-wrapper (usr/bin/run.sh) >> run java app >> > #!/bin/bash >> > .... bla-bla-bla .... >> > java -jar -Duser.home=$SNAP_USER_DATA >> $SNAP/usr/bin/languagetool.jar >> > >> > in snapcraft.yaml >> > apps: >> > languagetool: >> > command: usr/bin/run.sh >> > plugs: [network, network-bind, x11, home, unity7] >> > >> > >> > If to attach the java-app to a panel Unity Launcher, >> then the file >> > >> (~/.local/shape/applications/o >> rg-languagetool-gui-main.desktop >> ) will >> > contain. >> > >> > [Desktop Entry] >> > Encoding=UTF-8 >> > Version=1.0 >> > Type=Application >> > Name=LanguageTool 3.4-SNAPSHOT >> > Icon=org-languagetool-gui-main >> > Exec=java -jar >> -Duser.home=/home/vasilisc/snap/languagetool/x1 >> > /snap/languagetool/x1/usr/bin/languagetool.jar >> > >> > In a host-system can't execute a command (it's >> impossible) >> > java -jar -Duser.home=/home/vasilisc/sna >> p/languagetool/x1 >> > /snap/languagetool/x1/usr/bin/languagetool.jar >> > >> > I don't know what to do. >> >> You need to ship yourself your .desktop file, as you >> pointed via the vlc >> desktop file inside the snapcraft source. >> >> This one will have the correct Exec= after building it >> with snapcraft >> rather then one generated from unity. >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> >> > >> > >> Modify settings or unsubscribe >> >> at:https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > > >> >> 0) snap install wallpaperdownloader >> 81.81 MB / 81.84 MB >> [=========================================================== >> ============================================================ >> ======================================>_] >> 99.97 % 1.74 MB/s >> >> wallpaperdownloader (stable) 2.1 from 'egarcia' installed >> >> 1) Run java-app wallpaperdownloader in Terminal or Alt+F2 >> >> 2) To attach the program on a panel Unity. >> >> 3) cat >> .local/share/applications/es-estoes-wallpaperdownloader-main >> .desktop >> >> [Desktop Entry] >> Encoding=UTF-8 >> Version=1.0 >> Type=Application >> Name=WallpaperDownloader V2.1 >> Icon=es-estoes-wallpaperdownloader-main.png >> Exec=java -jar -Duser.home=/home/vasilisc/sna >> p/wallpaperdownloader/3 >> /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar >> StartupNotify=false >> StartupWMClass=es-estoes-wallpaperDownloader-Main >> OnlyShowIn=Unity; >> X-UnityGenerated=true >> --------------------------------- >> "Exec=java -jar >> -Duser.home=/home/vasilisc/snap/wallpaperdownloader/3 >> /snap/wallpaperdownloader/3/jar/wallpaperdownloader.jar" >> >> If Java is not installed on your system, then you have a problem. >> "Exec=java" - It's not right. >> >> For example, my script-wrapper can do the useful steps BEFORE >> start of >> the java program. >> >> Java is not installed by default in Ubuntu 16.04.1 >> $ lsb_release -a >> No LSB modules are available. >> Distributor ID: Ubuntu >> Description: Ubuntu 16.04.1 LTS >> Release: 16.04 >> Codename: xenial >> >> $ java -version >> The program 'java' can be found in the following packages: >> * default-jre >> * gcj-5-jre-headless >> * openjdk-8-jre-headless >> * gcj-4.8-jre-headless >> * gcj-4.9-jre-headless >> * openjdk-9-jre-headless >> Ask your administrator to install one of them >> >> How will it work "Exec=java"? >> >> -- >> Best regards, >> vasilisc >> >> > > -- > Best regards, > vasilisc > -- Eloy García Almadén -------------- next part -------------- An HTML attachment was scrubbed... URL: From sektorct at gmail.com Tue Aug 9 07:53:27 2016 From: sektorct at gmail.com (BlinCT .) Date: Tue, 9 Aug 2016 09:53:27 +0200 Subject: demon snmp in snap Message-ID: Good afternoon. My name is Alexey I write for the first time, hoping to get advice from you Recently I started to try building a programs into Snap package. I need to build a demon. But unfortunatly there was a many problems due working. I faced on the lacking of documentation and description of the principle operation with demons. I will try to describe the work and attaching a file with yaml file and binary file (f2d). The system should work with 2 demons, snmpd and my own sub-agent. snmp service is working with system. sub-agent is handle our requests, which are not known for the snmpd. snmp should be able to "--start" and "--stop". sub-agent can running with different keys, for example ./f2d -Lo -n My questions: 1. How to make packaging into snap pack with 2 demons if I want a program running only by root and with the keys? 2. How to work with file out of $SNAP? 3. I collect snmp, he unpackage /etc/snmp/snmpd.conf and then I want to replace it by my own snmpd.conf. how to do it? 4. The system have snmp. Could I install and work with other snmp in a program, if snmp was build in snap package? The archive contains files *.mib.txt with information for snmp. If main snmpd doesn't knows *.mib.txt data they have sent sub-agent f2d. f2d - sub-agent f2d.dat - a data file which running with sub-agent and verify his changes. The file can be changed. In that build file must be located in /etc/snmp.data/f2d.dat Thank you for your attention! I really count upon your help. I would be deeply grateful for all your advice. Sincerely, Alexey snapcraft.yaml name: f2d version: 0.1 summary: This is my-snap's summary description: test snmp demon confinement: strict parts: f2d: plugin: copy files: bin/f2d : usr/bin/f2d bin/Alexey.MIB.txt : usr/share/snmp/mibs/alexey1.mib.txt bin/f2d.mib.txt : usr/share/snmp/mibs/f2d.mib.txt bin/f2d.dat : /etc/snmp.data/f2d.dat bin/snmpd.conf : etc/snmp/snmpd.conf integration: plugin: nil stage-packages: - snmp - snmpd - smitools apps: f2d: command: usr/bin/f2d daemon: simple snmpd: command: etc/init.d/snmpd --start stop-command: etc/init.d/snmpd --stop daemon: forking plugs: ['network'] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Aug 9 09:47:14 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 09 Aug 2016 11:47:14 +0200 Subject: .desktop files for app-in-snap In-Reply-To: References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> Message-ID: <1470736034.29378.30.camel@ubuntu.com> hi, Am Dienstag, den 09.08.2016, 10:23 +0300 schrieb Vasilisc: > > run wallpaperdownloader in Terminal and pin app > > close wallpaperdownloader and launch app from Unity Launcher. > something happening? none! > > "Exec=java" try execute Java in the host, but Java is not installed > by  > default. > > Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java > Sorry for my english. really only I see a problem? > your .desktop file is in the wrong place ... you need to put it into your source directory into the "setup/gui" directory together with the icon...  here is a java app that i packaged, take a look at the setup/gui directory and at the "wrapper" script: https://github.com/ogra1/jtiledownloader now try the following: sudo snap install jtiledownloader once this is done, hit the windows key on your keyboard to bring up the dash ... click the A at the bottom of the dash window to search for applications, type "jtile" and you see an icon ... click it ...  the app starts, pin the icon in the launcher ... close the app ... if you now click the launcher icon again the app will start properly... do *not* put anything manually into ~/.local/share, snapd puts the .desktop file in the right place for the system if you had it in the setup/gui dir in your snap source ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From vasilisc777 at gmail.com Tue Aug 9 09:57:58 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 9 Aug 2016 12:57:58 +0300 Subject: .desktop files for app-in-snap In-Reply-To: <1470736034.29378.30.camel@ubuntu.com> References: <6a0760b9-6e96-1322-f8e4-be3a5a70acb2@gmail.com> <82b44708-00ab-081b-2cf1-e61bd1ee4b2a@gmail.com> <6418eb4c-0c1b-d772-39ac-92c0f2ed32dc@ubuntu.com> <445a4586-88d2-6e9f-e6fc-2ef105047a23@gmail.com> <1470736034.29378.30.camel@ubuntu.com> Message-ID: <08148cc3-45a0-c5e5-706f-050057c16f7a@gmail.com> 09.08.2016 12:47, Oliver Grawert пишет: > hi, > Am Dienstag, den 09.08.2016, 10:23 +0300 schrieb Vasilisc: >> >> run wallpaperdownloader in Terminal and pin app >> >> close wallpaperdownloader and launch app from Unity Launcher. >> something happening? none! >> >> "Exec=java" try execute Java in the host, but Java is not installed >> by >> default. >> >> Your Java in snap placed - $SNAP/usr/lib/jvm/default-java/bin/java >> Sorry for my english. really only I see a problem? >> > your .desktop file is in the wrong place ... you need to put it into > your source directory into the "setup/gui" directory together with the > icon... > > here is a java app that i packaged, take a look at the setup/gui > directory and at the "wrapper" script: > > https://github.com/ogra1/jtiledownloader > > now try the following: > > sudo snap install jtiledownloader > > once this is done, hit the windows key on your keyboard to bring up the > dash ... click the A at the bottom of the dash window to search for > applications, type "jtile" and you see an icon ... click it ... > the app starts, pin the icon in the launcher ... close the app ... Good example! Thx cat ~/.local/share/applications$ cat org-openstreetmap-fma-jtiledownloader-jtiledownloaderstart.desktop [Desktop Entry] Encoding=UTF-8 Version=1.0 Type=Application Name=JTileDownloader Version: 0.6.1 Icon=org-openstreetmap-fma-jtiledownloader-jtiledownloaderstart.png Path=/home/vasilisc/snap/jtiledownloader/2 Exec=/snap/jtiledownloader/2/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java -jar /snap/jtiledownloader/2/jTileDownloader-0-6-1.jar StartupNotify=false StartupWMClass=org-openstreetmap-fma-jtiledownloader-JTileDownloaderStart OnlyShowIn=Unity; X-UnityGenerated=true Right line!!!! Exec=/snap/jtiledownloader/2/usr/lib/jvm/java-1.8.0-openjdk-amd64/jre/bin/java -jar /snap/jtiledownloader/2/jTileDownloader-0-6-1.jar Thx Oliver. > if you now click the launcher icon again the app will start properly... > > do *not* put anything manually into ~/.local/share, snapd puts the > .desktop file in the right place for the system if you had it in the > setup/gui dir in your snap source ... > > ciao > oli > > > -- Best regards, vasilisc From loic.minier at ubuntu.com Tue Aug 9 12:18:01 2016 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 9 Aug 2016 08:18:01 -0400 Subject: How do I get a postinst stage properly executed - traceroute will not install correctly In-Reply-To: References: Message-ID: Hi, On Mon, Aug 8, 2016 at 12:01 PM, David Garrod wrote: > While I’m sure I could hack this particular case and add a link in the > startup of my snap I don’t see this as a general solution. What if a later > version of the package changes the name of the file or something. Any true > solution has to be based in what is in the postinst for the version of the > package being installed. This seems like a general issue to me. In order to > make the whole snap concept viable surely you have to be able to take > packages unchanged and have your SNAP depend on them just as packages in > the non-SNAP world depend on each other. I’d really like to see a mechanism > whereby the installation of a SNAP can run the post install configure step > in the context of the installation. Maybe that would involve deferring some > of this to the snap start if absolutely necessary but in general this would > not be needed. Are there any active plans to address this fundamental > design issue? > It's indeed by design; snaps and debs are different. In the .deb world, you can hack the whole system in the postinst, leading to intrusive changes or problems upgrading, interferences between postinst initiated changes etc. However perhaps the design issue you're seeing is not with snaps but rather with debs: alternatives should be declarative rather than imperative – each .deb would document the alternatives it'd like to see updated on install/remove/upgrade. If we had that piece of data, we could process it when unpacking a .deb without running the postinst as root. But because right now this information is buried inside a shell script which could be of any form and expects to be run as root, we can't use it without resorting to solutions involving chroots. - Loïc Minier -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at arbash-meinel.com Tue Aug 9 12:37:15 2016 From: john at arbash-meinel.com (John Meinel) Date: Tue, 9 Aug 2016 16:37:15 +0400 Subject: Sharing "$HOME/.foo" between developer builds Message-ID: One thing that has come up in recent conversations is that while it is great that I can push up a custom build of an official snap and have someone just try it, none of their settings will come across. The specific case is for us developing Juju, where Juju will go out and create new machines in AWS for you, and then tracks them currently in ~/.local/share/juju/*.yaml files. I we wanted to move those files into the SNAP_USER_DATA, then when I try to install a developer's version of Juju, none of my controllers would be visible. (And even if we had a mechanism to copy the data over, the data no longer stays in sync if I created/removed entities in juju-jameinel.juju testing.) AIUI there is an interface for $HOME, but that doesn't expose any dot files. Is there something around "I am an application of this and I'd like access to all of the data for " that doesn't require creating an new interface for every application? (As another example, imagine someone did a custom build of Firefox, wouldn't you expect to still see all of your bookmarks?) John =:-> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Aug 9 13:43:03 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 09 Aug 2016 15:43:03 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: <20160809070130.GC17712@zork.net> References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> <20160809070130.GC17712@zork.net> Message-ID: <1470750183.29303.23.camel@ubuntu.com> hi, On Di, 2016-08-09 at 07:01 +0000, Nick Moffitt wrote: > Simon Fels: > > > > On 08.08.2016 22:06, Christian Ehrhardt wrote: > > > > > > I was wondering how conffiles should be handled with snapcraft / > > > snaps in general. > [...] > > > > You could still store conf files in SNAP_USER_DATA to get them > > writable > > by the users of the system. > > Is there a good facility for install-time copying of template configs > or > other writeable-from-initial-state data into $SNAP_USER_DATA? > no, SNAP_USER_DATA is a runtime, not a build time thing ... you have to do it from your wrapper script that you most likely have to use anyway for other stuff to set up the environment for your binary (also there are not really any install time hooks, we are not debs with maintainer scripts (luckily))  ;) at [1] and [2] you can see some examples ... ciao oli [1] https://github.com/ogra1/packageproxy/blob/master/run-approx [2] https://github.com/ogra1/upnp-server -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From cemil.azizoglu at canonical.com Tue Aug 9 15:50:31 2016 From: cemil.azizoglu at canonical.com (Cemil Azizoglu) Date: Tue, 9 Aug 2016 10:50:31 -0500 Subject: Copying the same file under different names in the yaml Message-ID: Hi, I'd like to copy the same file under different names in my snap. So I'm looking for something like this : ------------------------------------ <...> apps: A: command: A B: command: B <...> wrappers: plugin: copy files: file.wrapper: A file.wrapper: B --------------------------------------- But only the last one seems to take effect. Is there a way to express this? Thanks, Cemil Azizoglu Mir Display Server - Team Lead Canonical USA -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Tue Aug 9 15:57:34 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 9 Aug 2016 17:57:34 +0200 Subject: Copying the same file under different names in the yaml In-Reply-To: References: Message-ID: On Tue, Aug 9, 2016 at 5:50 PM, Cemil Azizoglu wrote: > wrappers: > plugin: copy > files: > file.wrapper: A > file.wrapper: B > There might be something better, but what about this?: wrappersA: plugin: copy files: file.wrapper: A wrappersB: plugin: copy files: file.wrapper: B -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgarrod at extremenetworks.com Tue Aug 9 16:31:49 2016 From: dgarrod at extremenetworks.com (David Garrod) Date: Tue, 9 Aug 2016 16:31:49 +0000 Subject: How do I share a namespace between snap commands? In-Reply-To: <82b76113-3b81-3e33-688b-36bca351c11a@ubuntu.com> References: <1469638980.5406.135.camel@canonical.com> <82b76113-3b81-3e33-688b-36bca351c11a@ubuntu.com> Message-ID: Re: > even if you continue posting here (which is good to trigger discussion), please file a bug against the snappy launchpad project: >https://launchpad.net/snappy/ (even if I think this one may impact rather snap-confine, but it will be redirected) > >Didier Thanks. I've followed your suggestion and have logged bug: https://bugs.launchpad.net/snappy/+bug/1611444 ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From kyle.fazzari at canonical.com Tue Aug 9 17:37:28 2016 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 9 Aug 2016 10:37:28 -0700 Subject: How to handle conffiles in snaps? In-Reply-To: References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> Message-ID: On 08/09/2016 12:18 AM, Christian Ehrhardt wrote: > > On Tue, Aug 9, 2016 at 7:38 AM, Simon Fels > wrote: > > Thanks a lot Simon for the answers! > A few clarifications requests inline below (mostly getting the bug # > to subscribe and refer). > > For upgrades > there will be a hook at some point in the near future which will > notify > when your snap is upgraded and you can perform similar logic like you > can do in the maintainer scripts to handle changed formts etc. But as > far as I know there will be no modifications to the real /etc allowed > for any application snap. > > > Ok, I consider this WIP then - is there a bug I could subscribe myself > and link to from my code? Not yet (that I know of). > > > You could still store conf files in SNAP_USER_DATA to get them > writable > by the users of the system. > > > It is a daemon that needs the conf, so I think I'll try hack something > up in SNAP_DATA for now. > > > > The only snap-centric artifact about it I found was [1]. But > that feels > > broken/outdated as there is no "snappy" command anymore (and > snap has no > > "config" subcommand). > > Something similar will come back. From what I've heard there will be a > apply-config hook which you can implement in your snap and a user can > call from the outside with a simple 'snap set > snap.name.confkey=confvalue' or similar. > > > Thanks, as above I consider this WIP then - is there a bug I could > subscribe myself and link to from my code? Yeah, keep an eye on this one: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1596629 -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From evan.dandrea at canonical.com Tue Aug 9 17:39:34 2016 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Tue, 09 Aug 2016 17:39:34 +0000 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: On Mon, 8 Aug 2016 at 17:51 Sergio Schvezov wrote: > El 08/08/16 a las 13:35, Blake Rouse escribió: > > I would like to setup some travis CI that will auto upload tip of > > dev into the edge channel of "ntopng". > > Evan has some guides for setting up CI and could also solve or point you > in the right direction to take the reserved name. > > snapcraft 2.15 should be able to allow setting up macaroons through env > vars (to make it easier to use things like travis-ci) but that shouldn't > stop you from using ev's current solution. > This will let you build and publish snaps off Travis runs. You'll want to change $MACAROON_SECRET to your favourite value from pwgen. You'll also need to change the snap name and the $TRAVIS_BRANCH conditional. https://gist.github.com/evandandrea/998180be091518da1f6330bf19ed7a40 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgarrod at extremenetworks.com Tue Aug 9 17:42:02 2016 From: dgarrod at extremenetworks.com (David Garrod) Date: Tue, 9 Aug 2016 17:42:02 +0000 Subject: How do I get a postinst stage properly executed - traceroute will not install correctly In-Reply-To: References: Message-ID: Re: Ø However perhaps the design issue you're seeing is not with snaps but rather with debs: alternatives should be declarative rather than imperative – each .deb would document the alternatives it'd like to see updated on install/remove/upgrade. If we had that piece of data, we could process it when unpacking a .deb without running the postinst as root. But because right now this information is buried inside a shell script which could be of any form and expects to be run as root, we can't use it without resorting to solutions involving chroots. While I agree that maybe “debs” should have additional declarative functionality like this, that currently isn’t the case. In my view SNAPs should be designed to live in the world that IS not in the world we’d like it to be. To be honest I’m surprised that SNAPs don’t make more use of “chroot” like you elude to. I suspect that running the postinst step inside a “chroot” would allow a lot of things to be done in a secure manner. Not to take this thread off in a different direction but the major issue we’re having in moving a whole subsystem into a SNAP (one that we didn’t write but that we are SNAPifying – it happens to be OpenSwitch) is tracking down and finding all the references the absolute root file system names and then adding the appropriate $SNAP_xxx prefix in front of each of them by CHANGING (yuck) the code. I wish that SNAPs could have made use of chroot and maybe found a neat way to layer the chroot inside the SNAP and the Unbuntu core on top of particular real root directories for R/O access (if the file wasn’t present in the chroot directory). I’m showing my age here but I wish there was a way you could use chroot and the concept that is used in that ancient (but I understand still being sold) OpenVMS O/S that allowed you to define “concealed logical names” mapped to an equivalence LIST that essentially enabled one name to reference a list of real directories in way where the user is totally unaware that the “logical” directory is really an amalgamation of contributions from multiple different places. Anyway I digress, I guess for now I’ll hack a custom solution for the “deb” I’m having issues with due to the postinst not being able to be run. From: loic.minier at canonical.com [mailto:loic.minier at canonical.com] On Behalf Of Loïc Minier Sent: Tuesday, August 09, 2016 8:18 AM To: David Garrod Cc: Didier Roche; snapcraft at lists.ubuntu.com Subject: Re: How do I get a postinst stage properly executed - traceroute will not install correctly Hi, On Mon, Aug 8, 2016 at 12:01 PM, David Garrod > wrote: While I’m sure I could hack this particular case and add a link in the startup of my snap I don’t see this as a general solution. What if a later version of the package changes the name of the file or something. Any true solution has to be based in what is in the postinst for the version of the package being installed. This seems like a general issue to me. In order to make the whole snap concept viable surely you have to be able to take packages unchanged and have your SNAP depend on them just as packages in the non-SNAP world depend on each other. I’d really like to see a mechanism whereby the installation of a SNAP can run the post install configure step in the context of the installation. Maybe that would involve deferring some of this to the snap start if absolutely necessary but in general this would not be needed. Are there any active plans to address this fundamental design issue? It's indeed by design; snaps and debs are different. In the .deb world, you can hack the whole system in the postinst, leading to intrusive changes or problems upgrading, interferences between postinst initiated changes etc. However perhaps the design issue you're seeing is not with snaps but rather with debs: alternatives should be declarative rather than imperative – each .deb would document the alternatives it'd like to see updated on install/remove/upgrade. If we had that piece of data, we could process it when unpacking a .deb without running the postinst as root. But because right now this information is buried inside a shell script which could be of any form and expects to be run as root, we can't use it without resorting to solutions involving chroots. - Loïc Minier ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.talbott at canonical.com Tue Aug 9 21:41:52 2016 From: joe.talbott at canonical.com (Joe Talbott) Date: Tue, 9 Aug 2016 17:41:52 -0400 Subject: Removing sub-parts from the remote parts ecosystem. Message-ID: Dear Snapcrafters, The wiki introduced the concept of sub-parts and used namespacing to associate a list of sub-parts with a project-part. However the concept was ill-conceived and now needs to be removed. In essence, all parts should be top level parts. Each entry in the wiki should identify one or more parts from a snapcraft.yaml file that are considered to be useful to other snapcraft users. A current example of subparts might look like this: --- origin: https://github.com/josepht/snaptastic maintainer: Joe Talbott description: Some fun parts project-parts: fun-part parts: [a, b, c] Which would produce parts ‘fun-part/a’, ‘fun-part/b’, and ‘fun-part/c’. The new approach should be: --- origin: https://github.com/josepht/snaptastic maintainer: Joe Talbott description: Some fun parts parts: [fun-part, fun-part-a, fun-part-b, fun-part-c] Where the hierarchy is removed and each part is a top-level part. The part names will need to be changed in the snapcraft.yaml file as well. Thanks, Joe From andreas at canonical.com Tue Aug 9 21:50:18 2016 From: andreas at canonical.com (Andreas Hasenack) Date: Tue, 9 Aug 2016 18:50:18 -0300 Subject: Where to place config files, and nested config files Message-ID: Hi, I'm starting to use snapcraft and picked squid-deb-proxy as my first victim. This is just the normal squid service with a set of configuration files tailored for deb package caching. I'm assuming that the best place for the squid config files is SNAP_DATA, because it's versioned and any rollback will include the configuration files as they were in the previous installed revision. Is that correct? My other question is about nested configuration files. This particular squid config file includes other config files via absolute paths. In the normal deb package, you will see things like this: acl allowed_networks src "/etc/squid-deb-proxy/allowed-networks-src.acl" Now even if I point squid to the main/parent config file in SNAP_DATA, that absolute path above inside the config won't work because it's ouside SNAP_DATA. So what are my alternatives? a) hardcode the path above to use this prefix: /var/snap/squid-deb-proxy/current/. This is just like SNAP_DATA, but using "current" instead of the revision number, so it's stable. The acl line above would be like this, for example: acl allowed_networks src "/var/snap/squid-deb-proxy/current/etc/squid-deb-proxy/allowed-networks-src.acl" Can I use "current" like this, or is that abuse or bad form? b) use a simple template system and dynamically generate the config file with SNAP_DATA as the prefix before starting the service. I would have something like this in the template file: acl allowed_networks src "@PREFIX@ /etc/squid-deb-proxy/allowed-networks-src.acl" And generate the actual config file replacing @PREFIX@ with the contents of SNAP_DATA before starting the service. Is this overkill, or the most elegant solution? c) something else I'm missing? I'm very much starting my journey here :) Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Tue Aug 9 22:19:33 2016 From: manik at canonical.com (Manik Taneja) Date: Tue, 9 Aug 2016 16:19:33 -0600 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: On Tue, Aug 9, 2016 at 11:39 AM, Evan Dandrea wrote: > On Mon, 8 Aug 2016 at 17:51 Sergio Schvezov > wrote: > >> El 08/08/16 a las 13:35, Blake Rouse escribió: >> > I would like to setup some travis CI that will auto upload tip of >> > dev into the edge channel of "ntopng". >> >> Evan has some guides for setting up CI and could also solve or point you >> in the right direction to take the reserved name. >> >> snapcraft 2.15 should be able to allow setting up macaroons through env >> vars (to make it easier to use things like travis-ci) but that shouldn't >> stop you from using ev's current solution. >> > > This will let you build and publish snaps off Travis runs. You'll want to > change $MACAROON_SECRET to your favourite value from pwgen. You'll also > need to change the snap name and the $TRAVIS_BRANCH conditional. > > https://gist.github.com/evandandrea/998180be091518da1f6330bf19ed7a40 > > will this allow them to claim the reserved name? -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Wed Aug 10 05:58:38 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 10 Aug 2016 08:58:38 +0300 Subject: screenshot Message-ID: I uploaded in the Ubuntu Store a programs with their screenshots. GNOME Software does not show screenshot and icon. How fix this issue? -- Best regards, vasilisc From didrocks at ubuntu.com Wed Aug 10 06:04:41 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 10 Aug 2016 08:04:41 +0200 Subject: screenshot In-Reply-To: References: Message-ID: Le 10/08/2016 à 07:58, Vasilisc a écrit : > I uploaded in the Ubuntu Store a programs with their screenshots. > GNOME Software does not show screenshot and icon. > How fix this issue? > I guess for this kind of this, a bug is more appropriate than a ML discussion. Please open one (I would say against https://launchpad.net/ubuntu/+source/gnome-software) with appropriate details (name of the snap, and such…) so that people can debug it and reassign if needed. Cheers, Didier From didrocks at ubuntu.com Wed Aug 10 06:06:48 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 10 Aug 2016 08:06:48 +0200 Subject: Where to place config files, and nested config files In-Reply-To: References: Message-ID: <28aede4b-6b00-9153-7113-38d81fc630fb@ubuntu.com> Le 09/08/2016 à 23:50, Andreas Hasenack a écrit : > Hi, Hey Andreas, > > I'm starting to use snapcraft and picked squid-deb-proxy as my first > victim. This is just the normal squid service with a set of > configuration files tailored for deb package caching. > > I'm assuming that the best place for the squid config files is > SNAP_DATA, because it's versioned and any rollback will include the > configuration files as they were in the previous installed revision. > Is that correct? Correct! > > My other question is about nested configuration files. > > This particular squid config file includes other config files via > absolute paths. In the normal deb package, you will see things like this: > > acl allowed_networks src > "/etc/squid-deb-proxy/allowed-networks-src.acl" > > Now even if I point squid to the main/parent config file in SNAP_DATA, > that absolute path above inside the config won't work because it's > ouside SNAP_DATA. So what are my alternatives? > > a) hardcode the path above to use this prefix: > /var/snap/squid-deb-proxy/current/. This is just like SNAP_DATA, but > using "current" instead of the revision number, so it's stable. The > acl line above would be like this, for example: > > acl allowed_networks src > "/var/snap/squid-deb-proxy/current/etc/squid-deb-proxy/allowed-networks-src.acl" > > Can I use "current" like this, or is that abuse or bad form? > > > b) use a simple template system and dynamically generate the config > file with SNAP_DATA as the prefix before starting the service. I would > have something like this in the template file: > > acl allowed_networks src > "@PREFIX@/etc/squid-deb-proxy/allowed-networks-src.acl" > > And generate the actual config file replacing @PREFIX@ with the > contents of SNAP_DATA before starting the service. Is this overkill, > or the most elegant solution? > > > c) something else I'm missing? I'm very much starting my journey here :) b) is the most elegant solution IMHO, it will always point to the right directory, at runtime. That makes as well upstream config relocatable, which is a net benefit for everyone :) Cheers, Didier From didrocks at ubuntu.com Wed Aug 10 06:14:41 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 10 Aug 2016 08:14:41 +0200 Subject: Removing sub-parts from the remote parts ecosystem. In-Reply-To: References: Message-ID: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> Le 09/08/2016 à 23:41, Joe Talbott a écrit : > Dear Snapcrafters, Hey Joe, > > The wiki introduced the concept of sub-parts and used namespacing to > associate a list of sub-parts with a project-part. However the > concept was ill-conceived and now needs to be removed. In essence, > all parts should be top level parts. Each entry in the wiki should > identify one or more parts from a snapcraft.yaml file that are > considered to be useful to other snapcraft users. A current example > of subparts might look like this: > > --- > origin: https://github.com/josepht/snaptastic > maintainer: Joe Talbott > description: Some fun parts > project-parts: fun-part > parts: [a, b, c] > > Which would produce parts ‘fun-part/a’, ‘fun-part/b’, and > ‘fun-part/c’. The new approach should be: > > --- > origin: https://github.com/josepht/snaptastic > maintainer: Joe Talbott > description: Some fun parts > parts: [fun-part, fun-part-a, fun-part-b, fun-part-c] > > Where the hierarchy is removed and each part is a top-level part. The > part names will need to be changed in the snapcraft.yaml file as well. > Namespacing was really nice for things like desktop/ parts (desktop/gtk3, desktop/gtk2, desktop/qt5, desktop/qt4, desktop/glibonly). There is as well mqtt-paho/python2 and pqtt-patho/python3. A lot of existing snaps are using those already and I find it really sad that we are going to break backward compatibility for a feature that was prominently advocated for in our blog posts like http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/. Developers prefer to work on their snap rather than fighting for keeping it working with latest snapcraft/store, please keep that in mind. I think at least a reasonable approach would be to have a transition plan for a period of time backed into the tool. That means that snapcraft needs to be able to detect namespaced parts, and suggests corresponding new part name to use (as we only have 7 of them, that seems reasonable to handle the mapping by hand). I think that will put a nice precedent on how we care about developer experience, and try to minimize the impact on everyone. Is there anything like this planned? Also, please do not break this feature before the parts are transitioned to the new name scheme. My 2 cents Didier From seb128 at ubuntu.com Wed Aug 10 06:20:20 2016 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Wed, 10 Aug 2016 08:20:20 +0200 Subject: screenshot In-Reply-To: References: Message-ID: <1f9bfd15-20ed-e8e4-c239-4a4fa135acbb@ubuntu.com> Le 10/08/2016 à 08:04, Didier Roche a écrit : > I guess for this kind of this, a bug is more appropriate than a ML > discussion. Please open one (I would say against > https://launchpad.net/ubuntu/+source/gnome-software) with appropriate > details (name of the snap, and such…) so that people can debug it and > reassign if needed. Hey, That issue has already been reported https://bugs.launchpad.net/snappy/+bug/1603610 The bug doesn't have much detail but is reported on snappy as well so it's likely that snapd doesn't provide that info to the client Cheers, Sebastien Bacher From didrocks at ubuntu.com Wed Aug 10 06:30:42 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 10 Aug 2016 08:30:42 +0200 Subject: demon snmp in snap In-Reply-To: References: Message-ID: <402eb7eb-6966-6cf7-eea0-219f7016210b@ubuntu.com> Le 09/08/2016 à 09:53, BlinCT . a écrit : > Good afternoon. Hey Alexey, > My name is Alexey > I write for the first time, hoping to get advice from you > Recently I started to try building a programs into Snap package. I > need to build a demon. But unfortunatly there was a many problems due > working. I faced on the lacking of documentation and description of > the principle operation with demons. > I will try to describe the work and attaching a file with yaml file > and binary file (f2d). > The system should work with 2 demons, snmpd and my own sub-agent. snmp > service is working with system. sub-agent is handle our requests, > which are not known for the snmpd. > snmp should be able to "--start" and "--stop". > sub-agent can running with different keys, for example ./f2d -Lo -n > > My questions: > 1. How to make packaging into snap pack with 2 demons if I want a > program running only by root and with the keys? You just add different wrapper scripts (enabling one or the other with some conditions) I would say triggering one or the other in this shell scripts before starting the real daemon. Then, you can have two names under apps: in your snapcraft.yaml, each command pointing to one of the wrapper script. > 2. How to work with file out of $SNAP? You basically can't and shouldn't really on files outside of $SNAP apart from really rare exceptions. The whole idea of snaps is that upstream source is relocatable. Most of the times, they have some env variables that you can set to ensure it's reading the files where you want them to read (and you want them to read/create files in $SNAP*) > 3. I collect snmp, he unpackage /etc/snmp/snmpd.conf and then I want > to replace it by my own snmpd.conf. how to do it? I think that depends on snpmd itself. You need to look at the source and see if there is a parameter for the daemon like -c or an environment variable to point to some non hardcoded path. I'm sure making that relocatable would be a welcome contribution by upstream if it's not possible already! > 4. The system have snmp. Could I install and work with other snmp in a > program, if snmp was build in snap package? I don't really know snmp itself, but as they communicating via TCP or such? I don't think unix socket connection would be possible without defining an interface (and some people reading this list can help you getting started with this). If the communication is all network-y, you just need to use then the "network" and "network-bind" interface (if you are listening to incoming requests) for this. I hope that helped! Didier From christian.ehrhardt at canonical.com Wed Aug 10 07:15:37 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Wed, 10 Aug 2016 09:15:37 +0200 Subject: How to handle conffiles in snaps? In-Reply-To: References: <8bdc15c1-9f17-9e16-0c29-7bc68dfba4c8@canonical.com> Message-ID: On Tue, Aug 9, 2016 at 7:37 PM, Kyle Fazzari wrote: > > > On 08/09/2016 12:18 AM, Christian Ehrhardt wrote: > > > On Tue, Aug 9, 2016 at 7:38 AM, Simon Fels > wrote: > > Thanks a lot Simon for the answers! > A few clarifications requests inline below (mostly getting the bug # to > subscribe and refer). > > For upgrades >> there will be a hook at some point in the near future which will notify >> when your snap is upgraded and you can perform similar logic like you >> can do in the maintainer scripts to handle changed formts etc. But as >> far as I know there will be no modifications to the real /etc allowed >> for any application snap. >> > > Ok, I consider this WIP then - is there a bug I could subscribe myself and > link to from my code? > > > Not yet (that I know of). Thank you for referring the other one Kyle. I opened https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1611638 for this issue to be tracked and discussed. If there is some hidden one I couldn't find it, but things can be dup'ed later if there was one hiding :-) Thanks everybody for the great initial discussion. I have things working via workarounds for now and am subscribed to all related bugs I found to participate. -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Wed Aug 10 07:25:05 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Wed, 10 Aug 2016 09:25:05 +0200 Subject: Where to place config files, and nested config files In-Reply-To: <28aede4b-6b00-9153-7113-38d81fc630fb@ubuntu.com> References: <28aede4b-6b00-9153-7113-38d81fc630fb@ubuntu.com> Message-ID: On Wed, Aug 10, 2016 at 8:06 AM, Didier Roche wrote: > > b) use a simple template system and dynamically generate the config > > file with SNAP_DATA as the prefix before starting the service. I would > > have something like this in the template file: > > > > acl allowed_networks src > > "@PREFIX@/etc/squid-deb-proxy/allowed-networks-src.acl" > > > > And generate the actual config file replacing @PREFIX@ with the > > contents of SNAP_DATA before starting the service. Is this overkill, > > or the most elegant solution? > > > > > > c) something else I'm missing? I'm very much starting my journey here :) > > b) is the most elegant solution IMHO, it will always point to the right > directory, at runtime. That makes as well upstream config relocatable, > which is a net benefit for everyone :) Hi Andreas, I agree to all that was said. But spinning further your snaps life with that config, you might start wondering when/how to make these files available at e.g. SNAP_DATA, please feel fee to chime in on https://bugs.launchpad.net/snapcraft/+bug/1611287 for that. And as soon as squid_deb_proxy or others give you headache about upgrading with format changes (your template now differs from the conf that the user modified :-/) you can take a look at the discussion for https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1611638 -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Wed Aug 10 07:30:50 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Wed, 10 Aug 2016 10:30:50 +0300 Subject: locale Message-ID: <99a39802-4063-b678-a4a4-e3a0cc15a8eb@gmail.com> Program in snap package may try open file and path contain non-English letters. What I did. ---------------------------- snapcraft.yaml: apps: app-name: command: usr/bin/run.sh plugs: [network, network-bind, x11, home, unity7] integration: plugin: nil stage-packages: - ttf-wqy-zenhei # china - fonts-kacst # arabic - locales - locales-all - libc-bin # for localedef ....... ---------------------------- script-wrapper usr/bin/run.sh contain #============================= export I18NPATH=$SNAP/usr/share/i18n export LOCPATH=$SNAP_USER_DATA export LC_ALL=$LANG LANG1=$(echo $LANG | cut -f1 -d.) ENC=UTF-8 LOC="$LANG" # generate a locale so we get properly working charsets and graphics if [ ! -e $SNAP_USER_DATA/$LOC ]; then $SNAP/usr/bin/localedef --prefix=$SNAP_USER_DATA -f $ENC -i $LANG1 $SNAP_USER_DATA/$LOC fi #============================= There is an easier way? -- Best regards, vasilisc From michael.vogt at canonical.com Wed Aug 10 08:52:26 2016 From: michael.vogt at canonical.com (Michael Vogt) Date: Wed, 10 Aug 2016 10:52:26 +0200 Subject: Boot environment variables changes Message-ID: <20160810085226.GB3871@bod> Hi, as part of our work to create device images, we recently changed and simplified the boot environment variables that are used by the gadget snap. If you work on creating gadget snaps, there are some small tweaks that you need to do: The "snappy_{os,kernel}" boot variable names got changed to "snap_{core,kernel}". The boot protocol changed from snappy_mode={regular,try} and snappy_trival_boot={0,1} to snap_mode={"",try,trying}. An example for the pi2/uboot implementation with the new logic can be found here: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/boot-assets/uboot.env.in#L48 For most people this change is totally transparent, this only affects you if you actually work on the bootloader configuration (grub.cfg or uboot.env) of gadget snaps. Cheers, Michael From joe.talbott at canonical.com Wed Aug 10 11:51:10 2016 From: joe.talbott at canonical.com (Joe Talbott) Date: Wed, 10 Aug 2016 07:51:10 -0400 Subject: Removing sub-parts from the remote parts ecosystem. In-Reply-To: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> References: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> Message-ID: On Aug 10, 2016 2:15 AM, "Didier Roche" wrote: > > Le 09/08/2016 à 23:41, Joe Talbott a écrit : > > Dear Snapcrafters, > > Hey Joe, > > > > The wiki introduced the concept of sub-parts and used namespacing to > > associate a list of sub-parts with a project-part. However the > > concept was ill-conceived and now needs to be removed. In essence, > > all parts should be top level parts. Each entry in the wiki should > > identify one or more parts from a snapcraft.yaml file that are > > considered to be useful to other snapcraft users. A current example > > of subparts might look like this: > > > > --- > > origin: https://github.com/josepht/snaptastic > > maintainer: Joe Talbott > > description: Some fun parts > > project-parts: fun-part > > parts: [a, b, c] > > > > Which would produce parts ‘fun-part/a’, ‘fun-part/b’, and > > ‘fun-part/c’. The new approach should be: > > > > --- > > origin: https://github.com/josepht/snaptastic > > maintainer: Joe Talbott > > description: Some fun parts > > parts: [fun-part, fun-part-a, fun-part-b, fun-part-c] > > > > Where the hierarchy is removed and each part is a top-level part. The > > part names will need to be changed in the snapcraft.yaml file as well. > > > > Namespacing was really nice for things like desktop/ parts > (desktop/gtk3, desktop/gtk2, desktop/qt5, desktop/qt4, > desktop/glibonly). There is as well mqtt-paho/python2 and > pqtt-patho/python3. > A lot of existing snaps are using those already and I find it really sad > that we are going to break backward compatibility for a feature that was > prominently advocated for in our blog posts like > http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/. > Developers prefer to work on their snap rather than fighting for keeping > it working with latest snapcraft/store, please keep that in mind. > > I think at least a reasonable approach would be to have a transition > plan for a period of time backed into the tool. That means that > snapcraft needs to be able to detect namespaced parts, and suggests > corresponding new part name to use (as we only have 7 of them, that > seems reasonable to handle the mapping by hand). I think that will put a > nice precedent on how we care about developer experience, and try to > minimize the impact on everyone. Is there anything like this planned? The plan would be to convert the wiki parts and their origins but to have a deprecation warning for any snapcraft.yaml using the namespaced part names and to have snapcraft automatically convert '/' to '-' during part loading. This should lessen the pain for developers and allow them to make plans to update their snapcraft.yaml files. Thanks, Joe > > Also, please do not break this feature before the parts are transitioned > to the new name scheme. > > My 2 cents > Didier > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Wed Aug 10 12:29:49 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Wed, 10 Aug 2016 14:29:49 +0200 Subject: Removing sub-parts from the remote parts ecosystem. In-Reply-To: References: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> Message-ID: <78cd3c7e-b4fc-36af-85d3-c52a3d4b7d15@ubuntu.com> Le 10/08/2016 à 13:51, Joe Talbott a écrit : > > The plan would be to convert the wiki parts and their origins but to > have a deprecation warning for any snapcraft.yaml using the namespaced > part names and to have snapcraft automatically convert '/' to '-' during > part loading. This should lessen the pain for developers and allow them > to make plans to update their snapcraft.yaml files. > Sounds great! So I guess we'll have some time where we'll have duplicate on the wiki? Just to give enough time for people to upgrade to a snapcraft version which supports this automatic conversion? Thanks, Didier From joe.talbott at canonical.com Wed Aug 10 12:39:41 2016 From: joe.talbott at canonical.com (Joe Talbott) Date: Wed, 10 Aug 2016 08:39:41 -0400 Subject: Removing sub-parts from the remote parts ecosystem. In-Reply-To: <78cd3c7e-b4fc-36af-85d3-c52a3d4b7d15@ubuntu.com> References: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> <78cd3c7e-b4fc-36af-85d3-c52a3d4b7d15@ubuntu.com> Message-ID: On Wed, Aug 10, 2016 at 8:29 AM, Didier Roche wrote: > Le 10/08/2016 à 13:51, Joe Talbott a écrit : > >> >> The plan would be to convert the wiki parts and their origins but to >> have a deprecation warning for any snapcraft.yaml using the namespaced >> part names and to have snapcraft automatically convert '/' to '-' during >> part loading. This should lessen the pain for developers and allow them >> to make plans to update their snapcraft.yaml files. >> > > Sounds great! So I guess we'll have some time where we'll have duplicate > on the wiki? Just to give enough time for people to upgrade to a > snapcraft version which supports this automatic conversion? Hrm, I'll have to think about that a bit. There will only be one version of the parser so it wouldn't handle the old versions in the wiki. Thanks for bringing it up. Thanks, Joe From sergio.schvezov at canonical.com Wed Aug 10 14:31:05 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 10 Aug 2016 11:31:05 -0300 Subject: Removing sub-parts from the remote parts ecosystem. In-Reply-To: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> References: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> Message-ID: El 10/08/16 a las 03:14, Didier Roche escribió: > Le 09/08/2016 à 23:41, Joe Talbott a écrit : > Namespacing was really nice for things like desktop/ parts > (desktop/gtk3, desktop/gtk2, desktop/qt5, desktop/qt4, > desktop/glibonly). There is as well mqtt-paho/python2 and > pqtt-patho/python3. I am going to change mqtt-paho/python2 and pqtt-patho/python3. I own the origin. > A lot of existing snaps are using those already and I find it really sad > that we are going to break backward compatibility for a feature that was > prominently advocated for in our blog posts like > http://blog.sergiusens.org/posts/The-Snapcraft-Parts-Ecosystem/. > Developers prefer to work on their snap rather than fighting for keeping > it working with latest snapcraft/store, please keep that in mind. A design review proved that this was confusing and not straightforward for the writer of the parts. The subparts thing was also just to satisfy the `after` dependencies of the main project part being exported (and hidden from users). We accidentally leaked that information and the rest is history. > I think at least a reasonable approach would be to have a transition > plan for a period of time backed into the tool. That means that > snapcraft needs to be able to detect namespaced parts, and suggests > corresponding new part name to use (as we only have 7 of them, that > seems reasonable to handle the mapping by hand). I think that will put a > nice precedent on how we care about developer experience, and try to > minimize the impact on everyone. Is there anything like this planned? > > Also, please do not break this feature before the parts are transitioned > to the new name scheme. That is what is being debated. That said I think the transition will be fast as we don't plan to fix existing bugs where a `/` is involved as it just opened a can of worms. The way out is to transition. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joe.talbott at canonical.com Wed Aug 10 20:37:01 2016 From: joe.talbott at canonical.com (Joe Talbott) Date: Wed, 10 Aug 2016 16:37:01 -0400 Subject: Removing sub-parts from the remote parts ecosystem. In-Reply-To: References: <04cbe940-61f8-eef3-fb34-781595059f05@ubuntu.com> <78cd3c7e-b4fc-36af-85d3-c52a3d4b7d15@ubuntu.com> Message-ID: Actually it's not as bad as I thought. We'd have duplicate entries; the original would now have the project-part and '/' in explicitly in each part name; and the new would be a copy with the slashes changed to '-'. This will allow older versions of snapcraft to continue to use the versions with '/' in the name and newer versions will work with either one until we disallow '/' in part names. To get the 'desktop' sub-parts to work I forked the snapcraft-desktop-helpers repo and added the duplicate parts there as well; one version with '/' and one with '-'. I then copied the wiki contents into a file locally and changed it to contain the duplicate part names as well. Both version 2.13.1 and the version I'm working on in my PR which will be in a release after 2.14 worked with the duplicated names. By "worked" I only mean that snapcraft was able to build a snap using a snapcraft.yaml containing either version of the part name. Thanks, Joe On Wed, Aug 10, 2016 at 8:39 AM, Joe Talbott wrote: > On Wed, Aug 10, 2016 at 8:29 AM, Didier Roche wrote: >> Le 10/08/2016 à 13:51, Joe Talbott a écrit : >> >>> >>> The plan would be to convert the wiki parts and their origins but to >>> have a deprecation warning for any snapcraft.yaml using the namespaced >>> part names and to have snapcraft automatically convert '/' to '-' during >>> part loading. This should lessen the pain for developers and allow them >>> to make plans to update their snapcraft.yaml files. >>> >> >> Sounds great! So I guess we'll have some time where we'll have duplicate >> on the wiki? Just to give enough time for people to upgrade to a >> snapcraft version which supports this automatic conversion? > > Hrm, I'll have to think about that a bit. There will only be one > version of the parser so it wouldn't handle the old versions in the > wiki. Thanks for bringing it up. > > Thanks, > Joe From sergio.schvezov at canonical.com Wed Aug 10 23:14:08 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 10 Aug 2016 20:14:08 -0300 Subject: ANN: snapcraft 2.14 has been released Message-ID: <6e874878-83aa-7616-7b1c-0313ba7f2c66@ubuntu.com> Hi there, just in case people are not on the announce list (you should if you care about these ANN emails), here's the announcement email link: https://lists.ubuntu.com/archives/snapcraft-announce/2016-August/000000.html If you prefer formatted text the same content can be seen here: https://github.com/snapcore/snapcraft/releases/tag/2.14 Cheers Sergio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From howy.wang at canonical.com Thu Aug 11 05:37:27 2016 From: howy.wang at canonical.com (Howy Wang) Date: Thu, 11 Aug 2016 13:37:27 +0800 Subject: [JavaGame] A snap question for audio. Message-ID: Hi there, I made a snap, javagame and it works well. Now the snap upload for javagame.howy to the Ubuntu Store has been approved. But I found something wrong with audio, the following is the wrong message during running the snap. *[MUSIC][11:39:29] Playing song: Towards The End* *[ERROR][11:39:29] Problem playing file sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 61ab49d* *[ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create AudioDevice* *[MUSIC][11:39:29] Playing song: yoshi song* *[ERROR][11:39:29] Problem playing file sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 35104da8* *[ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create AudioDevice* I have checked my snapcraft.yaml has "plugs" with pulseaudio and "$ snap interfaces" has ":pulseaudio javagame:, too. This is the $ snap interfaces howy at howy-Vostro-14-5480:~/examples/java$ snap interfaces Slot Plug :camera - :cups-control - :firewall-control - :gsettings - :hardware-observe - :home atom-cwayne,javagame,jtiledownloader,openjdk-demo,qtclocks,wallpaperdownloader :locale-control - :log-observe snappy-debug :modem-manager - :mount-observe - :network jtiledownloader,openjdk-demo :network-bind javagame,jtiledownloader,wallpaperdownloader :network-control - :network-manager - :network-observe - :opengl game-2048 :optical-drive - :ppp - :pulseaudio javagame :snapd-control - :system-observe - :timeserver-control - :timezone-control - :unity7 game-2048,openjdk-demo,qtclocks :x11 game-2048,javagame,jtiledownloader,qtclocks,wallpaperdownloader Any suggestions or examples can help to solve audio issue? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Thu Aug 11 11:00:37 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Thu, 11 Aug 2016 13:00:37 +0200 Subject: [JavaGame] A snap question for audio. In-Reply-To: References: Message-ID: > El 11 ago 2016, a las 7:37, Howy Wang escribió: > > Hi there, > > I made a snap, javagame and it works well. > Now the snap upload for javagame.howy to the Ubuntu Store has been approved. > But I found something wrong with audio, the following is the wrong message during running the snap. Do you see any denials in the system log? You can check for them using journalctl -f when you start the game. > > [MUSIC][11:39:29] Playing song: Towards The End > [ERROR][11:39:29] Problem playing file sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 61ab49d > [ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create AudioDevice > [MUSIC][11:39:29] Playing song: yoshi song > [ERROR][11:39:29] Problem playing file sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 35104da8 > [ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create AudioDevice > > I have checked my snapcraft.yaml has "plugs" with pulseaudio and "$ snap interfaces" has ":pulseaudio javagame:, too. > This is the $ snap interfaces > > howy at howy-Vostro-14-5480:~/examples/java$ snap interfaces > Slot Plug > :camera - > :cups-control - > :firewall-control - > :gsettings - > :hardware-observe - > :home atom-cwayne,javagame,jtiledownloader,openjdk-demo,qtclocks,wallpaperdownloader > :locale-control - > :log-observe snappy-debug > :modem-manager - > :mount-observe - > :network jtiledownloader,openjdk-demo > :network-bind javagame,jtiledownloader,wallpaperdownloader > :network-control - > :network-manager - > :network-observe - > :opengl game-2048 > :optical-drive - > :ppp - > :pulseaudio javagame > :snapd-control - > :system-observe - > :timeserver-control - > :timezone-control - > :unity7 game-2048,openjdk-demo,qtclocks > :x11 game-2048,javagame,jtiledownloader,qtclocks,wallpaperdownloader > > Any suggestions or examples can help to solve audio issue? > Thank you. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at arbash-meinel.com Thu Aug 11 13:05:42 2016 From: john at arbash-meinel.com (John Meinel) Date: Thu, 11 Aug 2016 17:05:42 +0400 Subject: Sharing "$HOME/.foo" between developer builds In-Reply-To: References: Message-ID: It sounds like the design goal for this is around "branches" of snaps, where you are essentially forking the version history, but 2 snaps are still considered the same identity, and thus sharing the same configuration. It also sounds like while that is a known and planned feature, it is not a high priority feature. Is there a suggested work around for this in the short/mid term? John =:-> On Tue, Aug 9, 2016 at 4:37 PM, John Meinel wrote: > One thing that has come up in recent conversations is that while it is > great that I can push up a custom build of an official snap and have > someone just try it, none of their settings will come across. > > The specific case is for us developing Juju, where Juju will go out and > create new machines in AWS for you, and then tracks them currently in > ~/.local/share/juju/*.yaml files. I we wanted to move those files into the > SNAP_USER_DATA, then when I try to install a developer's version of Juju, > none of my controllers would be visible. (And even if we had a mechanism to > copy the data over, the data no longer stays in sync if I created/removed > entities in juju-jameinel.juju testing.) > > AIUI there is an interface for $HOME, but that doesn't expose any dot > files. Is there something around "I am an application of this and > I'd like access to all of the data for " that doesn't require > creating an new interface for every application? > > (As another example, imagine someone did a custom build of Firefox, > wouldn't you expect to still see all of your bookmarks?) > > John > =:-> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Thu Aug 11 22:06:18 2016 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 11 Aug 2016 16:06:18 -0600 Subject: How to snap packages that provide "extra" files to be used by something else In-Reply-To: References: Message-ID: <57ACF6DA.1030405@canonical.com> Hello Christian! On 2016-08-04 07:16, Christian Ehrhardt wrote: > Hi, > while thinking about what I could experiment with snapping next I > checked what I still use some external repositories for - as I > considered those a great list of opportunities. > > One that I found there was my printer driver which consists of these > packages [1] provided by [2]. > But thinking about how that would fit into the snap world gave me a hard > time, so I thought I better write it up for discussion. I mean I can > only win, either by learning or by identifying something that we can > convert into a valid feature request. > > The reason I thought this might be non-standard in regard to snaps is, > that most of the functionality provided by these packages is achieved by > placing files for other programs to pick it up. Some examples might be: > - cups ppd files - /usr/share/cups/model/suld/ML-1740.ppd.gz > - special cups filters - /usr/lib/cups/filter/pstosplc > - or even libs for sane - /usr/lib/sane/libsane-smfp.so > > Now that doesn't fit in the (otherwise really great) sandboxing into > ~/snap or /snap. > Because in this case others programs should be able to pick up these > files in common paths. > > It doesn't really qualify for an interface [3] as I thought to > understand them so far. > > It might be somewhat close to the "home" plug in some ways - so maybe > there lies the rescue. > Yet the home plug it is more about the snap being able to reach out and > not "others" being able to pick up the files of the snap. > > So what would be the preferred way to solve such issues in general when > creating a snap? > > Thinking about it a bit further, even man-pages could be considered to > fall in a very similar category right? > > Looking forward to learn, kind regards, > Christian > > [1]: http://www.bchemnet.com/suldr/repository.html > [2]: http://www.bchemnet.com/suldr/index.html > [3]: http://snapcraft.io/docs/reference/interfaces There have been some discussions in past weeks about cups and printers, started by Till (cc'ed here). He can probably tell you more about the plans, the work in progress and the things that are still left to define. pura vida. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From leo.arias at canonical.com Thu Aug 11 22:45:09 2016 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 11 Aug 2016 16:45:09 -0600 Subject: Including custom kernel driver with a snap In-Reply-To: References: Message-ID: <57ACFFF5.2040204@canonical.com> Hello Mike! On 2016-08-04 12:58, MikeB wrote: > Can someone describe the strategy or point me to an example for > including a custom kernel driver as part of a snap? > > I'm trying to put together a snap that requires several custom kernel > drivers be installed along with the snap and would like to know the > "snappy" way of doing this. Your question comes at a great time :) There is code, and example and discussion about this here: https://github.com/snapcore/snapd/pull/1602 Feel free to join. pura vida. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From howy.wang at canonical.com Fri Aug 12 02:19:30 2016 From: howy.wang at canonical.com (Howy Wang) Date: Fri, 12 Aug 2016 10:19:30 +0800 Subject: [JavaGame] A snap question for audio. In-Reply-To: References: Message-ID: Hi Zygmunt, Yes, I got some similar wrong message during " journalctl -f " *Aug 12 10:05:26 howy-Vostro-14-5480 audit[6827]: AVC apparmor="DENIED" operation="open" profile="snap.javagame.play" name="/dev/snd/controlC1" pid=6827 comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0* Should I add more plugs or change something on my snapcraft.yaml? Thank you. 2016-08-11 19:00 GMT+08:00 Zygmunt Krynicki : > > El 11 ago 2016, a las 7:37, Howy Wang escribió: > > Hi there, > > I made a snap, javagame and it works well. > Now the snap upload for javagame.howy to the Ubuntu Store has been > approved. > But I found something wrong with audio, the following is the wrong message > during running the snap. > > > Do you see any denials in the system log? You can check for them using > journalctl -f when you start the game. > > > *[MUSIC][11:39:29] Playing song: Towards The End* > *[ERROR][11:39:29] Problem playing file > sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 61ab49d* > *[ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create > AudioDevice* > *[MUSIC][11:39:29] Playing song: yoshi song* > *[ERROR][11:39:29] Problem playing file > sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 35104da8* > *[ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create > AudioDevice* > > I have checked my snapcraft.yaml has "plugs" with pulseaudio and "$ snap > interfaces" has ":pulseaudio javagame:, too. > This is the $ snap interfaces > > howy at howy-Vostro-14-5480:~/examples/java$ snap interfaces > Slot Plug > :camera - > :cups-control - > :firewall-control - > :gsettings - > :hardware-observe - > :home atom-cwayne,javagame,jtiledownloader,openjdk-demo, > qtclocks,wallpaperdownloader > :locale-control - > :log-observe snappy-debug > :modem-manager - > :mount-observe - > :network jtiledownloader,openjdk-demo > :network-bind javagame,jtiledownloader,wallpaperdownloader > :network-control - > :network-manager - > :network-observe - > :opengl game-2048 > :optical-drive - > :ppp - > :pulseaudio javagame > :snapd-control - > :system-observe - > :timeserver-control - > :timezone-control - > :unity7 game-2048,openjdk-demo,qtclocks > :x11 game-2048,javagame,jtiledownloader,qtclocks, > wallpaperdownloader > > Any suggestions or examples can help to solve audio issue? > Thank you. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > > -- Regards, -- *Howy Wang* *O *+886-2-8729-6849 *M* +886 928-258-081 Field Engineering | Canonical Ltd. www.canonical.com | www.ubuntu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: denied.log Type: text/x-log Size: 4778 bytes Desc: not available URL: From simon.fels at canonical.com Fri Aug 12 05:44:33 2016 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 12 Aug 2016 07:44:33 +0200 Subject: [JavaGame] A snap question for audio. In-Reply-To: References: Message-ID: On 12.08.2016 04:19, Howy Wang wrote: > Hi Zygmunt, > > Yes, I got some similar wrong message during "journalctl -f" > *Aug 12 10:05:26 howy-Vostro-14-5480 audit[6827]: AVC apparmor="DENIED" > operation="open" profile="snap.javagame.play" name="/dev/snd/controlC1" pid=6827 > comm="java" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 > * > * > * > Should I add more plugs or change something on my snapcraft.yaml? > Thank you. This really much looks like your app is directly talking with ALSA instead of pulseaudio. Can you verify this? The pulseaudio interface currently only allows directly talking with pulseaudio but AFAIK not using the ALSA pulse plugin. Can't say that for sure but this is what it looks like. regards, Simon > > > 2016-08-11 19:00 GMT+08:00 Zygmunt Krynicki >: > > >> El 11 ago 2016, a las 7:37, Howy Wang > > escribió: >> >> Hi there, >> >> I made a snap, javagame and it works well. >> Now the snap upload for javagame.howy to the Ubuntu Store has been approved. >> But I found something wrong with audio, the following is the wrong message >> during running the snap. > > Do you see any denials in the system log? You can check for them using > journalctl -f when you start the game. > >> >> *[MUSIC][11:39:29] Playing song: Towards The End* >> *[ERROR][11:39:29] Problem playing file >> sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 61ab49d* >> *[ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create >> AudioDevice* >> *[MUSIC][11:39:29] Playing song: yoshi song* >> *[ERROR][11:39:29] Problem playing file >> sun.net.www.protocol.jar.JarURLConnection$JarURLInputStream at 35104da8* >> *[ERROR][11:39:29]javazoom.jl.decoder.JavaLayerException: Cannot create >> AudioDevice* >> >> I have checked my snapcraft.yaml has "plugs" with pulseaudio and "$ snap >> interfaces" has ":pulseaudio javagame:, too. >> This is the $ snap interfaces >> >> howy at howy-Vostro-14-5480:~/examples/java$ snap interfaces >> Slot Plug >> :camera - >> :cups-control - >> :firewall-control - >> :gsettings - >> :hardware-observe - >> :home >> atom-cwayne,javagame,jtiledownloader,openjdk-demo,qtclocks,wallpaperdownloader >> :locale-control - >> :log-observe snappy-debug >> :modem-manager - >> :mount-observe - >> :network jtiledownloader,openjdk-demo >> :network-bind javagame,jtiledownloader,wallpaperdownloader >> :network-control - >> :network-manager - >> :network-observe - >> :opengl game-2048 >> :optical-drive - >> :ppp - >> :pulseaudio javagame >> :snapd-control - >> :system-observe - >> :timeserver-control - >> :timezone-control - >> :unity7 game-2048,openjdk-demo,qtclocks >> :x11 >> game-2048,javagame,jtiledownloader,qtclocks,wallpaperdownloader >> >> Any suggestions or examples can help to solve audio issue? >> Thank you. >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > > > > -- > Regards, > -- > *Howy Wang* > *O *+886-2-8729-6849 *M*+886 928-258-081 > Field Engineering | Canonical Ltd. > www.canonical.com | www.ubuntu.com > > > > From jamie at canonical.com Fri Aug 12 11:25:12 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 12 Aug 2016 06:25:12 -0500 Subject: Including custom kernel driver with a snap In-Reply-To: <57ACFFF5.2040204@canonical.com> References: <57ACFFF5.2040204@canonical.com> Message-ID: <1471001112.6752.34.camel@canonical.com> On Thu, 2016-08-11 at 16:45 -0600, Leo Arias wrote: > Hello Mike! > > On 2016-08-04 12:58, MikeB wrote: > > > > Can someone describe the strategy or point me to an example for > > including a custom kernel driver as part of a snap? > > > > I'm trying to put together a snap that requires several custom kernel > > drivers be installed along with the snap and would like to know the > > "snappy" way of doing this. > Your question comes at a great time :) > There is code, and example and discussion about this here: > https://github.com/snapcore/snapd/pull/1602 > Note that this is an extremely privileged interface since it essentially gives device ownership to the snap and there will be assertions and store checks limiting its use. AFAIK, the snappy way of doing this is still to build a kernel snap with the drivers you want. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mark at ubuntu.com Fri Aug 12 11:35:53 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 12 Aug 2016 07:35:53 -0400 Subject: How to snap packages that provide "extra" files to be used by something else In-Reply-To: References: Message-ID: On 04/08/16 09:16, Christian Ehrhardt wrote: > Now that doesn't fit in the (otherwise really great) sandboxing into > ~/snap or /snap. > Because in this case others programs should be able to pick up these > files in common paths. > > It doesn't really qualify for an interface [3] as I thought to > understand them so far. Interfaces should actually handle this case very well, as long as both sides of the file exchange are predictable. So I can imagine CUPS providing an interface to ingest PPDs and a PPD snap that consumes that interface making the PPDs available. In the next wave of landings, you'll see the ability to execute code in both snaps when an interface is being connected, allowing you to agree for example on filenames etc. Mark From mark at ubuntu.com Fri Aug 12 12:04:34 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 12 Aug 2016 08:04:34 -0400 Subject: ntopng strict snap published In-Reply-To: References: Message-ID: <3d30020b-f8ec-d025-e2d4-34307bb01ba4@ubuntu.com> On 09/08/16 18:19, Manik Taneja wrote: > > will this allow them to claim the reserved name? We can allocate a name to a publisher very easily, just need the authoritative upstream to ask on this mailing list. In this case we should probably use the new 'collaborators' feature in the store, which lets multiple accounts (the 'collaborators') push a snap on behalf of the actual publisher. That way the community person who leads the setup of the snap and the CI with Travis and Github integration can shepherd things along until folks upstream have the hang of it. Then we could remove the snapcrafter from the collaborators list, which means the upstream publisher has exclusive ability to release new revisions, once they have a good upstream process for daily builds (edge) and betas and the actual candidate/stable releases too. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Fri Aug 12 12:36:28 2016 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Fri, 12 Aug 2016 14:36:28 +0200 Subject: How to snap packages that provide "extra" files to be used by something else In-Reply-To: References: Message-ID: On Fri, Aug 12, 2016 at 1:35 PM, Mark Shuttleworth wrote: > Interfaces should actually handle this case very well, as long as both > sides of the file exchange are predictable. So I can imagine CUPS > providing an interface to ingest PPDs and a PPD snap that consumes that > interface making the PPDs available. > > In the next wave of landings, you'll see the ability to execute code in > both snaps when an interface is being connected, allowing you to agree > for example on filenames etc. > Ack: In any pure snap setup the interface based solution would have been my way to go for this. And it certainly is the right one. In the context of the request I was thinking more about snaps on classic and how e.g. a "classic" system could pick up those. Or turning around the statement: How a snap would ensure things are picked up by the "host" in classic. A generic solution for this isn't the most important feature - as it might also break isolation more than we like. So - if considered as a generic feature - this might just end up as one of the constraints for snaps on classic. But for a few common cases (like manpages see bug 1575593 I think we should design and provide something that can be commonly used). Looking forward for the next wave of landings then - maybe the "active interface connect" if we want to call it that way would already provide enough to solve it that way. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri Aug 12 12:50:47 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 12 Aug 2016 08:50:47 -0400 Subject: How to snap packages that provide "extra" files to be used by something else In-Reply-To: References: Message-ID: <1e36f4c3-ed49-d76a-eb59-a9887f69e84b@ubuntu.com> On 12/08/16 08:36, Christian Ehrhardt wrote: > In the context of the request I was thinking more about snaps on > classic and how e.g. a "classic" system could pick up those. > Or turning around the statement: How a snap would ensure things are > picked up by the "host" in classic. > > A generic solution for this isn't the most important feature - as it > might also break isolation more than we like. > So - if considered as a generic feature - this might just end up as > one of the constraints for snaps on classic. > But for a few common cases (like manpages see bug 1575593 I think we > should design and provide something that can be commonly used). If the CUPS in the classic environment is a snap, then the snap-to-snap interface will work for classic just as well as all-snap Ubuntu Core. If the CUPS is a deb, then something (could be snapd) would need to know how to handle the interface in enough detail to feed the bits to CUPS. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Fri Aug 12 17:07:10 2016 From: manik at canonical.com (Manik Taneja) Date: Fri, 12 Aug 2016 10:07:10 -0700 Subject: ntopng strict snap published In-Reply-To: <3d30020b-f8ec-d025-e2d4-34307bb01ba4@ubuntu.com> References: <3d30020b-f8ec-d025-e2d4-34307bb01ba4@ubuntu.com> Message-ID: On Fri, Aug 12, 2016 at 5:04 AM, Mark Shuttleworth wrote: > On 09/08/16 18:19, Manik Taneja wrote: > > > will this allow them to claim the reserved name? > > > We can allocate a name to a publisher very easily, just need the > authoritative upstream to ask on this mailing list. > > In this case we should probably use the new 'collaborators' feature in the > store, which lets multiple accounts (the 'collaborators') push a snap on > behalf of the actual publisher. That way the community person who leads the > setup of the snap and the CI with Travis and Github integration can > shepherd things along until folks upstream have the hang of it. Then we > could remove the snapcrafter from the collaborators list, which means the > upstream publisher has exclusive ability to release new revisions, once > they have a good upstream process for daily builds (edge) and betas and the > actual candidate/stable releases too. > Thanks Mark. I'll work with Blake and have him setup as the collaborator, until upstream takes over. Cheers, Manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From sektorct at gmail.com Sat Aug 13 14:01:57 2016 From: sektorct at gmail.com (BlinCT .) Date: Sat, 13 Aug 2016 16:01:57 +0200 Subject: Qt application error Message-ID: Hello. Anyone can tell me, why would can this error when I try starting application? QML debugging is enabled. Only use this in a safe environment. This application failed to start because it could not find or load the Qt platform plugin "xcb" in "". Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, xcb. Reinstalling the application may fix this problem. Emergency stop (memory dump is made) ---------------------------------------------------------------------------------- If necessary, I use Qt 5.7.0, and use dynamic libraries qt It's my snapcraft.yaml name: timerproject version: "1.0" summary: timer description: | Application for time-management confinement: strict architectures: [amd64] apps: timerproject: command: desktop-launch ProjectTimer plugs: ['home', 'unity7', 'x11', 'opengl'] parts: timerproject: plugin: copy files: bin/ProjectTimer : usr/bin/ProjectTimer setup/gui/icon.png : usr/share/icons/timer.ico integration: plugin: nil stage-packages: - libc-bin - libxkbcommon0 - ttf-ubuntu-font-family - dmz-cursor-theme - light-themes - shared-mime-info - libqt5gui5 - libgdk-pixbuf2.0-0 - libqt5svg5 - appmenu-qt5 after: [desktop/qt5] -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.chen at canonical.com Mon Aug 15 03:35:03 2016 From: david.chen at canonical.com (David Chen) Date: Mon, 15 Aug 2016 11:35:03 +0800 Subject: Qt application error In-Reply-To: References: Message-ID: <483e9873-a087-330b-732b-ecec02151cf3@canonical.com> Hi BlinCT, Have you tried setting |QT_QPA_PLATFORM_PLUGIN_PATH? Regards, -David | On 08/13/2016 10:01 PM, BlinCT . wrote: > Hello. > Anyone can tell me, why would can this error when I try starting > application? > > QML debugging is enabled. Only use this in a safe environment. > This application failed to start because it could not find or load the > Qt platform plugin "xcb" > in "". > > Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, > offscreen, xcb. > > Reinstalling the application may fix this problem. > Emergency stop (memory dump is made) > ---------------------------------------------------------------------------------- > If necessary, I use Qt 5.7.0, and use dynamic libraries qt > > It's my snapcraft.yaml > > name: timerproject > version: "1.0" > summary: timer > description: | > Application for time-management > confinement: strict > architectures: [amd64] > > apps: > timerproject: > command: desktop-launch ProjectTimer > plugs: ['home', 'unity7', 'x11', 'opengl'] > > parts: > timerproject: > plugin: copy > files: > bin/ProjectTimer : usr/bin/ProjectTimer > setup/gui/icon.png : usr/share/icons/timer.ico > > integration: > plugin: nil > stage-packages: > - libc-bin > - libxkbcommon0 > - ttf-ubuntu-font-family > - dmz-cursor-theme > - light-themes > - shared-mime-info > - libqt5gui5 > - libgdk-pixbuf2.0-0 > - libqt5svg5 > - appmenu-qt5 > after: [desktop/qt5] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.vogt at canonical.com Mon Aug 15 17:58:03 2016 From: michael.vogt at canonical.com (Michael Vogt) Date: Mon, 15 Aug 2016 19:58:03 +0200 Subject: New ubuntu-core snap in the candidate channel Message-ID: <20160815175803.GC3871@bod> Hello! We have updated the "ubuntu-core" snap in the candidate channel. It passes our spread QA tests and we want to promote it into the stable channel soon. It contains a ton of bugfixes, as well as new features that are important for the upcoming all-snap images, and will allow us to switch to "snap run" when running apps from snaps. We would like to ask you to help testing this snap. Please run: $ sudo snap refresh --candidate ubuntu-core on your (classic) system and let us know if you notice any issues. Thanks, Michael (on behalf of the snapd team) From matthew.bruzek at canonical.com Tue Aug 16 13:39:56 2016 From: matthew.bruzek at canonical.com (Matt Bruzek) Date: Tue, 16 Aug 2016 08:39:56 -0500 Subject: Build snaps in container Message-ID: ​​ To get better acquainted with snapping I built a snapcraft environment in an Ubuntu docker container. This gives us a consistent snapcraft environment everywhere, from development, CI to my colleagues OSX installation. This is a minimum viable product that provides a few features: * Gives developers access to the snapcraft tools in many environments. * Users can mount a directory from the host into the container to do snapcraft builds and leave builds artifacts on the host. * The container follows a similar pattern that we use in CI with other projects. Developers and the CI system build using the same environment. ​If you are interested in the source code, check the project out here: https://github.com/juju-solutions/snapbox It is also available on docker hub: https://hub.docker.com/r/ jujusolutions/snapbox/ making the setup: docker run --rm -it -v path/to/snapcraft:/home/snapper/snap jujusolutions/snapbox We are looking to snap up Kubernetes for the upstream packaging. Right now it looks like we may have to build a custom plugin. If anyone wants to help out with that please let me know. - Matt Bruzek -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Aug 16 13:51:23 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 16 Aug 2016 15:51:23 +0200 Subject: Build snaps in container In-Reply-To: References: Message-ID: <1471355483.22293.8.camel@ubuntu.com> hi, On Di, 2016-08-16 at 08:39 -0500, Matt Bruzek wrote: > > To get better acquainted with snapping I built a snapcraft > environment in an Ubuntu docker container. This gives us a consistent > snapcraft environment everywhere, from development, CI to my > colleagues OSX installation. > did you compare the build times with the builtin container mechanism that snapcraft ships by default (cleanbuild) ?  might be interesting to compare snapbox to "snapcraft cleanbuild" in that area... :) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From chris.wayne at canonical.com Tue Aug 16 13:53:41 2016 From: chris.wayne at canonical.com (Chris Wayne) Date: Tue, 16 Aug 2016 09:53:41 -0400 Subject: Using sudo from within a snap In-Reply-To: <1470648423.29378.18.camel@ubuntu.com> References: <37b95712-fa23-4b2d-1d3b-a5f9688221f1@canonical.com> <1470648423.29378.18.camel@ubuntu.com> Message-ID: Is this something that could be added to the roadmap? We'd really prefer to not have to call the snap itself with sudo as it creates some permissions issues (root-owned dirs in $HOME for example) and some other general flakiness. What would the sudo interface entail, just access to /usr/bin/sudo and /etc/sudoers.d/snap.mountpoint? On Mon, Aug 8, 2016 at 5:27 AM, Oliver Grawert wrote: > hi, > Am Montag, den 08.08.2016, 09:36 +0200 schrieb Simon Fels: > > On 06.08.2016 15:54, Chris Wayne wrote: > > > > > > Hi guys, > > > > > > I seem to be having some issues while running anything as sudo from > > > within a > > > snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+b > > > ug/1610292). > > If you package sudo within your snap snapcraft will strip the > > necessary > > suid bit from it so it wont work anymore. Only way to use sudo is to > > use > > the one from the core snap. > > > how would you hook into /etc/sudoers (or /etc/sudoers.d/) ? > snapd would have to install or bind-mount a sudoers file above the one > from the core snap ... you also need to make sure that your user exists > in the password db ... both gets very hairy in an all-snap image where > the core snap is actually the rootfs (and both of the above files are > required for having the system functional) > > i could imagine a sudo interface here (for the binary) and shipping a > generic /etc/sudoers.d/snapd mountpoint in the core snap where > snapd/snap-confine could bind-mount a shipped sudoers snippet, but that > still leaves the passwd db issue open... > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pawel.stolowski at canonical.com Tue Aug 16 14:17:06 2016 From: pawel.stolowski at canonical.com (Pawel Stolowski) Date: Tue, 16 Aug 2016 16:17:06 +0200 Subject: my snap cannot be build anymore - 'ascii' codec can't encode character Message-ID: <1eb39f0e-0359-d55c-d4cf-f723fd3a4ccd@canonical.com> Hi, I'm getting the following error when trying to 'snapcraft cleanbuild' something I contributed a few weeks ago to playpen - https://github.com/ubuntu/snappy-playpen/tree/master/qcomicbook: ..... (installation of dependencies)..... Processing triggers for ureadahead (0.100.0-19) ... 'ascii' codec can't encode character '\u29f8' in position 19: ordinal not in range(128) Command '['lxc', 'exec', 'snapcraft-hydrographically-foraminiferal- magdalene', '--', 'snapcraft', 'snap', '--output', 'qcomicbook_0.9.1_amd64.snap']' returned non-zero exit status 1 it worked back then and I haven't touched it since... looks like a bug in snapcraft ? Has anyone experienced it? Cheers, Pawel From ogra at ubuntu.com Tue Aug 16 14:22:56 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 16 Aug 2016 16:22:56 +0200 Subject: my snap cannot be build anymore - 'ascii' codec can't encode character In-Reply-To: <1eb39f0e-0359-d55c-d4cf-f723fd3a4ccd@canonical.com> References: <1eb39f0e-0359-d55c-d4cf-f723fd3a4ccd@canonical.com> Message-ID: <1471357376.22293.9.camel@ubuntu.com> hi, On Di, 2016-08-16 at 16:17 +0200, Pawel Stolowski wrote: > Hi, > > I'm getting the following error when trying to 'snapcraft > cleanbuild'  > ... > Processing triggers for ureadahead (0.100.0-19) ... > 'ascii' codec can't encode character '\u29f8' in position 19: ordinal   that is: https://bugs.launchpad.net/bugs/1607015 ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Tue Aug 16 14:31:57 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 16 Aug 2016 11:31:57 -0300 Subject: my snap cannot be build anymore - 'ascii' codec can't encode character In-Reply-To: <1471357376.22293.9.camel@ubuntu.com> References: <1eb39f0e-0359-d55c-d4cf-f723fd3a4ccd@canonical.com> <1471357376.22293.9.camel@ubuntu.com> Message-ID: <3770dc0f-09c9-aa8e-8056-466eb39c31a8@ubuntu.com> El 16/08/16 a las 11:22, Oliver Grawert escribió: > hi, > On Di, 2016-08-16 at 16:17 +0200, Pawel Stolowski wrote: >> Hi, >> >> I'm getting the following error when trying to 'snapcraft >> cleanbuild' >> ... >> Processing triggers for ureadahead (0.100.0-19) ... >> 'ascii' codec can't encode character '\u29f8' in position 19: ordinal > > that is: > > https://bugs.launchpad.net/bugs/1607015 namespaced parts have been a problem from a user experience point of view, we won't be fixing these but allow for a good transition out of namespaced parts. 2.15 will provide the path out of this where all parts from an origin will be top-level and declared. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From joe.talbott at canonical.com Tue Aug 16 14:34:07 2016 From: joe.talbott at canonical.com (Joe Talbott) Date: Tue, 16 Aug 2016 10:34:07 -0400 Subject: my snap cannot be build anymore - 'ascii' codec can't encode character In-Reply-To: <3770dc0f-09c9-aa8e-8056-466eb39c31a8@ubuntu.com> References: <1eb39f0e-0359-d55c-d4cf-f723fd3a4ccd@canonical.com> <1471357376.22293.9.camel@ubuntu.com> <3770dc0f-09c9-aa8e-8056-466eb39c31a8@ubuntu.com> Message-ID: In the mean time you can use the 'desktop-xxx' version of the desktop helpers now. Thanks, Joe On Tue, Aug 16, 2016 at 10:31 AM, Sergio Schvezov wrote: > > > El 16/08/16 a las 11:22, Oliver Grawert escribió: >> hi, >> On Di, 2016-08-16 at 16:17 +0200, Pawel Stolowski wrote: >>> Hi, >>> >>> I'm getting the following error when trying to 'snapcraft >>> cleanbuild' >>> ... >>> Processing triggers for ureadahead (0.100.0-19) ... >>> 'ascii' codec can't encode character '\u29f8' in position 19: ordinal >> >> that is: >> >> https://bugs.launchpad.net/bugs/1607015 > > namespaced parts have been a problem from a user experience point of > view, we won't be fixing these but allow for a good transition out of > namespaced parts. 2.15 will provide the path out of this where all parts > from an origin will be top-level and declared. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From pawel.stolowski at canonical.com Tue Aug 16 15:10:21 2016 From: pawel.stolowski at canonical.com (Pawel Stolowski) Date: Tue, 16 Aug 2016 17:10:21 +0200 Subject: my snap cannot be build anymore - 'ascii' codec can't encode character In-Reply-To: References: <1eb39f0e-0359-d55c-d4cf-f723fd3a4ccd@canonical.com> <1471357376.22293.9.camel@ubuntu.com> <3770dc0f-09c9-aa8e-8056-466eb39c31a8@ubuntu.com> Message-ID: That helped, thanks! Pawel On 16.08.2016 16:34, Joe Talbott wrote: > In the mean time you can use the 'desktop-xxx' version of the desktop > helpers now. > > Thanks, > Joe > > On Tue, Aug 16, 2016 at 10:31 AM, Sergio Schvezov > wrote: >> >> El 16/08/16 a las 11:22, Oliver Grawert escribió: >>> hi, >>> On Di, 2016-08-16 at 16:17 +0200, Pawel Stolowski wrote: >>>> Hi, >>>> >>>> I'm getting the following error when trying to 'snapcraft >>>> cleanbuild' >>>> ... >>>> Processing triggers for ureadahead (0.100.0-19) ... >>>> 'ascii' codec can't encode character '\u29f8' in position 19: ordinal >>> that is: >>> >>> https://bugs.launchpad.net/bugs/1607015 >> namespaced parts have been a problem from a user experience point of >> view, we won't be fixing these but allow for a good transition out of >> namespaced parts. 2.15 will provide the path out of this where all parts >> from an origin will be top-level and declared. >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >> From jamie at canonical.com Tue Aug 16 15:59:43 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 16 Aug 2016 10:59:43 -0500 Subject: Using sudo from within a snap In-Reply-To: References: <37b95712-fa23-4b2d-1d3b-a5f9688221f1@canonical.com> <1470648423.29378.18.camel@ubuntu.com> Message-ID: <1471363183.6422.7.camel@canonical.com> On Tue, 2016-08-16 at 09:53 -0400, Chris Wayne wrote: > Is this something that could be added to the roadmap?  We'd really prefer > to not have to call the snap itself with sudo as it creates some > permissions issues (root-owned dirs in $HOME for example) and some other > general flakiness.  What would the sudo interface entail, just access to > /usr/bin/sudo and /etc/sudoers.d/snap.mountpoint? > In the bug[1] we're focused on sudo and/or pkexec not working within a devmode snap. With devmode, sudo should work and we can work through how to fix that. Indeed, the conversation has moved to the bug. Using sudo from within a strict mode snap is fundamentally at odds with what strict mode is meant to accomplish and adding a sudo interface while keeping strong confinement is a very thorny problem. This mailing list discussion veered into that area, but I suggest we focus on devmode. [1]https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292 > On Mon, Aug 8, 2016 at 5:27 AM, Oliver Grawert wrote: > > > > > hi, > > Am Montag, den 08.08.2016, 09:36 +0200 schrieb Simon Fels: > > > > > > On 06.08.2016 15:54, Chris Wayne wrote: > > > > > > > > > > > > Hi guys, > > > > > > > > I seem to be having some issues while running anything as sudo from > > > > within a > > > > snap (namely bug https://bugs.launchpad.net/ubuntu/+source/snapd/+b > > > > ug/1610292). > > > If you package sudo within your snap snapcraft will strip the > > > necessary > > > suid bit from it so it wont work anymore. Only way to use sudo is to > > > use > > > the one from the core snap. > > > > > how would you hook into /etc/sudoers (or /etc/sudoers.d/) ? > > snapd would have to install or bind-mount a sudoers file above the one > > from the core snap ... you also need to make sure that your user exists > > in the password db ... both gets very hairy in an all-snap image where > > the core snap is actually the rootfs (and both of the above files are > > required for having the system functional) > > > > i could imagine a sudo interface here (for the binary) and shipping a > > generic /etc/sudoers.d/snapd mountpoint in the core snap where > > snapd/snap-confine could bind-mount a shipped sudoers snippet, but that > > still leaves the passwd db issue open... > > > > ciao > >         oli > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/snapcraft > > > > > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/s > napcraft -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mabnhdev at gmail.com Tue Aug 16 16:12:31 2016 From: mabnhdev at gmail.com (MikeB) Date: Tue, 16 Aug 2016 12:12:31 -0400 Subject: Including custom kernel driver with a snap Message-ID: On 2016-08-12 06:25:12 -0500 Jamie Strandboge wrote: > Note that this is an extremely privileged interface since it essentially gives > device ownership to the snap and there will be assertions and store checks > limiting its use. AFAIK, the snappy way of doing this is still to build a kernel > snap with the drivers you want. Hmmm. Interesting point about building the drivers into the kernel. Note that these are custom kernel drivers distributed separately from the kernel. I've never tried to build a custom driver as part of the kernel, so I'll have to look into it more. I suspect that I'll have to build a custom kernel snap for my target platform(s) anyways since some platforms need standard drivers at boot time that are not included with the standard kernel snap. So, this might be a reasonable solution. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From wakeroid at gmail.com Tue Aug 16 18:08:13 2016 From: wakeroid at gmail.com (Alexey Yakovenko) Date: Tue, 16 Aug 2016 20:08:13 +0200 Subject: Using snap for application with plugins Message-ID: Hi (Before I start, I'd like to apologise if this message has duplicates, I messed up with the mailing list subscription at first). Many users are requesting snap package format for my music player application. I researched this topic, and came up with a list of problems which I could not solve from documentation or google searches. So here's a short introduction to my app architecture: * The main module, which is a console application, which can load and use plugins of various kinds * A set of standard plugins, which can link to certain libraries * Example plugins: GTK2 UI, GTK3 UI, PulseAudio output, Various input plugins, etc * External plugins, which a user may download from internet -- they can be anything, for example a plugin could implement a UI in Qt4 or Qt5, or ncurses, or play sound via Jack. * It is not known at the time of package creation, what these packages could be. So when I'm creating the package, I have a problem -- which UI toolkit to use, if my app supports any toolkit? It ships with GTK2 and GTK3, but there are external plugins which add more toolkits. I can't really predict which toolkit the user wants, and what libraries the plugins will use -- it can be Qt4 or 5, or ncurses, or anything really. Another problem. Let's take the jack output plugin as an example.. If the user downloads jack.so (the plugin), and puts it in the folder, the player won't be able to load it, because the jack client library is not a part of snap, or because there's no access to jack server, or something like that, correct? So, the final question.. Is it just a terrible idea to use snap for this kind of applications? Or am I misunderstanding something, and all of this is possible? I really hope to get some useful "official" answers, which I could forward to the users which request snap packages :) Best regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.voss at canonical.com Tue Aug 16 18:56:30 2016 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Tue, 16 Aug 2016 20:56:30 +0200 Subject: Using snap for application with plugins In-Reply-To: References: Message-ID: Hey Alexey, first of all: Thanks for reaching out :) And to answer your final question first: Snap'ing up applications that feature a runtime extension mechanism is certainly possible, complexity depends on the actual application, though. To get you started fast: devmode (see http://askubuntu.com/questions/783945/what-is-devmode-for-snaps) should help to get you off the ground. Also note that we are right now snap'ing our Unity8 scopes and dash infrastructure. In a sense, our scopes are an example of a really complex plugin system and we are likely facing very similar problems. I'll ask specific questions inline. On Tue, Aug 16, 2016 at 8:08 PM, Alexey Yakovenko wrote: > Hi > > (Before I start, I'd like to apologise if this message has duplicates, I > messed up with the mailing list subscription at first). > > Many users are requesting snap package format for my music player > application. > > I researched this topic, and came up with a list of problems which I could > not solve from documentation or google searches. > > So here's a short introduction to my app architecture: > > * The main module, which is a console application, which can load and use > plugins of various kinds Is your application using an in- or out-of-process plugin architecture? > * A set of standard plugins, which can link to certain libraries > * Example plugins: GTK2 UI, GTK3 UI, PulseAudio output, Various input > plugins, etc Do you maintain those plugins in-tree? Would you be fine with distributing them within your application's snap? Or would you rather prefer to distribute them as separate snaps, with you being the publisher? > * External plugins, which a user may download from internet -- they can be > anything, for example a plugin could implement a UI in Qt4 or Qt5, or > ncurses, or play sound via Jack. Is the download and installation handled by your application or with the help of the underlying packaging system? As to what degree do you "trust" those plugins and their authors? Would you be fine to publish them as well? > * It is not known at the time of package creation, what these packages > could be. > > So when I'm creating the package, I have a problem -- which UI toolkit to > use, if my app supports any toolkit? It ships with GTK2 and GTK3, but there > are external plugins which add more toolkits. I can't really predict which > toolkit the user wants, and what libraries the plugins will use -- it can be > Qt4 or 5, or ncurses, or anything really. > I'm trying to rephrase a little: Your application supports plugins which may use *any* toolkit as long as the plugin bundles the respective runtime dependencies correctly. So it is ultimately the responsibility of the plugin to provide all the required libraries. > Another problem. Let's take the jack output plugin as an example.. > > If the user downloads jack.so (the plugin), and puts it in the folder, the > player won't be able to load it, because the jack client library is not a > part of snap, or because there's no access to jack server, or something like > that, correct? > The answer depends on how your application handles plugin download & installation. The issues would be solved if plugins were snaps. In that case, the individual plugin brings along its dependencies and defines the interfaces it would like to use (see [1] for an excellent introduction & overview to Snappy interfaces). > So, the final question.. Is it just a terrible idea to use snap for this > kind of applications? Or am I misunderstanding something, and all of this is > possible? > > I really hope to get some useful "official" answers, which I could forward > to the users which request snap packages :) > Looking forward to your answers and to dive deeper in your specific case. Cheers, Thomas P.S.: Feel free to reach out on irc(#snappy at freenode), too. [1] http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html > Best regards. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From adam.stokes at canonical.com Tue Aug 16 19:07:54 2016 From: adam.stokes at canonical.com (Adam Stokes) Date: Tue, 16 Aug 2016 19:07:54 +0000 Subject: custom lxd bridges inside a snap Message-ID: I've found some discussion on this here: https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html I am curious to know if this is possible now or still a work in progress? I have a snap that requires a custom LXD bridge and would like to make use of that if possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wakeroid at gmail.com Tue Aug 16 19:55:07 2016 From: wakeroid at gmail.com (Alexey Yakovenko) Date: Tue, 16 Aug 2016 21:55:07 +0200 Subject: Using snap for application with plugins In-Reply-To: References: Message-ID: Hi Thomas Thanks for replying so quickly! Answering inline. :) On Tue, Aug 16, 2016 at 8:56 PM, Thomas Voß wrote: > Hey Alexey, > > first of all: Thanks for reaching out :) And to answer your final > question first: Snap'ing up applications that feature > a runtime extension mechanism is certainly possible, complexity > depends on the actual application, though. > > To get you started fast: devmode (see > http://askubuntu.com/questions/783945/what-is-devmode-for-snaps) > should help to get you off the ground. > Yes, thanks, I know about dev mode, of course running the app in dev mode just makes it work the same, as it would work without using snap, right?. I can also run my application from the mounted snap volume directly, with the same result. Of course this works. However, I suppose that this is not really the idea behind snap? Or is it one of the standard / expected use cases on the end users side, to install from snap, but run directly? > > Also note that we are right now snap'ing our Unity8 scopes and dash > infrastructure. In a sense, our scopes are an example of a > really complex plugin system and we are likely facing very similar > problems. > Well, yeah, perhaps, but in your case, as far as I understand, you can either build snaps for all of the scopes, or force the scope developers to do that. I can't have this luxury. Please, see below for more answers and more questions :) > > I'll ask specific questions inline. > > On Tue, Aug 16, 2016 at 8:08 PM, Alexey Yakovenko > wrote: > > Hi > > > > (Before I start, I'd like to apologise if this message has duplicates, I > > messed up with the mailing list subscription at first). > > > > Many users are requesting snap package format for my music player > > application. > > > > I researched this topic, and came up with a list of problems which I > could > > not solve from documentation or google searches. > > > > So here's a short introduction to my app architecture: > > > > * The main module, which is a console application, which can load and use > > plugins of various kinds > > Is your application using an in- or out-of-process plugin architecture? > In-process. > > > * A set of standard plugins, which can link to certain libraries > > * Example plugins: GTK2 UI, GTK3 UI, PulseAudio output, Various input > > plugins, etc > > Do you maintain those plugins in-tree? Would you be fine with > distributing them within your application's snap? > Or would you rather prefer to distribute them as separate snaps, with > you being the publisher? > They are 3rd party projects, most often developed and distributed without my knowledge -- i.e. 100% third party. They can be released a few years after my application ships. Most of the time, they are also binary-compatible with multiple versions of the host application. There's a ton of plugins which can run on any version of the host app, released in the last 5 years. Even if I wanted to make snaps for each of them, I would not have resources to do that. So I can't really answer positively to any of the 2 questions. The plugins are just *.so files, sometimes with extra data files, which need to be dropped to ~/.local/lib/appname (that's when not using snap). Of course, the standard plugins which I ship with the host application don't have any problems, I think they would "just work". > > > * External plugins, which a user may download from internet -- they can > be > > anything, for example a plugin could implement a UI in Qt4 or Qt5, or > > ncurses, or play sound via Jack. > > Is the download and installation handled by your application or with > the help of the underlying packaging system? > Neither. Usually a user downloads a zip file from a plugin developer's website, and unpacks it into ~/.local/lib/appname. If there are no binary builds available, a user has to compile the plugin by himself. Many developers are providing shell scripts to compile and install, or full featured build systems using Make etc. Unfortunately, neither the host application, nor the plugins, are available in most linux distribution package systems. This is what's making snap particularly interesting (if it can do what's needed). > As to what degree do you "trust" those plugins and their authors? > I don't know most of them. There are a few developers who I have contact with, but technically I can't trust any of them. It's completely up to the end user whether to install certain plugin, or not -- the same way as he would install an application downloaded from the internet. > Would you be fine to publish them as well? > I'm already publishing a bunch of the 3rd party plugins, but I can't publish all of them for many reasons. There are simply too many of these projects. I can't even keep track of them. Basically, people release new ones almost weekly. > > > * It is not known at the time of package creation, what these > packages > > could be. > > > > So when I'm creating the package, I have a problem -- which UI toolkit to > > use, if my app supports any toolkit? It ships with GTK2 and GTK3, but > there > > are external plugins which add more toolkits. I can't really predict > which > > toolkit the user wants, and what libraries the plugins will use -- it > can be > > Qt4 or 5, or ncurses, or anything really. > > > > I'm trying to rephrase a little: Your application supports plugins > which may use *any* toolkit > as long as the plugin bundles the respective runtime dependencies > correctly. So it is ultimately the > responsibility of the plugin to provide all the required libraries. > Yeah, so the answer is "a plugin which is using Qt5 could work, but it would need to be in snap package, and has to ship its own version of Qt5" as an example? But still, each of the plugin developers would have to provide each of their plugins in snap packages? The problem is that I can't make them do that. I don't have communication with them. Some developers build a plugin, make a .so out of it, put this on their website, and forget about it forever. So we sometimes have only this .so file, without source code even. What is also important: a user might already have a bunch of plugins installed on his computer, and he would obviously want or need to keep them, so if he can't use them with deadbeef from Snap -- he would not be using deadbeef from snap at all, and stick with another installation method (one of the existing ones). A more complex question that I couldn't find an answer too: How to make a snap, which can use both GTK2 and GTK3. To simplify the discussion, let's say I have 2 executable files, app_gtk2, and app_gtk3. They ship in the same snap. Is it possible to do this, so that either of the 2 apps can be used from within the same snap package? So what I described above is a simplified version. What I really have: there's only 1 executable file, but it can load either a GTK2 plugin (ui_gtk2.so), or a GTK3 plugin (ui_gtk3.so), depending on the configuration and command line options. > > Another problem. Let's take the jack output plugin as an example.. > > > > If the user downloads jack.so (the plugin), and puts it in the folder, > the > > player won't be able to load it, because the jack client library is not a > > part of snap, or because there's no access to jack server, or something > like > > that, correct? > > > > The answer depends on how your application handles plugin download & > installation. > The issues would be solved if plugins were snaps. In that case, the > individual plugin brings > along its dependencies and defines the interfaces it would like to use > (see [1] for an excellent introduction & overview to > Snappy interfaces). > Application itself doesn't manage plugin download & installation at all. It can load and run the plugins which are already downloaded and present in one of the pre-defined folders. There's no central registry of all plugins, therefore it's not really possible to change this easily. > > > So, the final question.. Is it just a terrible idea to use snap for this > > kind of applications? Or am I misunderstanding something, and all of > this is > > possible? > > > > I really hope to get some useful "official" answers, which I could > forward > > to the users which request snap packages :) > > > > Looking forward to your answers and to dive deeper in your specific case. > > Cheers, > > Thomas > > P.S.: Feel free to reach out on irc(#snappy at freenode), too. > Sure, let's see the outcome of this round of questions, and then we can see if it's worth to continue. > > [1] http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html > > > Best regards. > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Tue Aug 16 21:04:41 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 16 Aug 2016 16:04:41 -0500 Subject: custom lxd bridges inside a snap In-Reply-To: References: Message-ID: <1471381481.2868.2.camel@canonical.com> On Tue, 2016-08-16 at 19:07 +0000, Adam Stokes wrote: > I've found some discussion on this here: > > https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html > > I am curious to know if this is possible now or still a work in progress? I > have a snap that requires a custom LXD bridge and would like to make use of > that if possible. The 'network-control' interface is meant to be used for this sort of thing and should give you the permissions required for setting up bridges, etc. If there are bugs with the security policy, please file them at: https://bugs.launchpad.net/snappy/+filebug and add the 'snapd-interface' tag. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From marco.ceppi at canonical.com Tue Aug 16 22:08:04 2016 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Tue, 16 Aug 2016 22:08:04 +0000 Subject: Putting git inside a snap Message-ID: Hello, I've spent the better part of my day hitting my head too hard against a wall. Figured I'd ask the list for more assistance. tl;dr: git doesn't work when included inside my snap and it's really messing me up. snap install charm --edge I'm snapping charm and charm-tools as a single snap. One is a godeps "part type" and the other python. Getting these two working together in a single snap was pretty straight forward. The charm command works as expected and finds the charm-tools plugins bundled alongside the snap it the proper path. https://github.com/juju-solutions/charm-pkg/blob/8ed82a1e70c748f76c3c39b2f70a1499a39c1864/snapcraft.yaml My problem is some of the charm-tools commands rely on git, bzr, or hg to perform their commands. When trying the most basic step command `charm create foo` Which will checkout the python-reactive boilerplate template from github and place it in the users current working directory the following errors pop up in the output: warning: templates not found /usr/share/git-core/templates fatal: Unable to find remote helper for 'https' During this run, there's nothing from apparmor complaining about bits and the snap is in strict confinement. Even in devmode the error persists. The second error seems to be the core of the problem, based on this http://stackoverflow.com/q/8329485/196832 it seems that git has been compiled without ssl support. I find this hard to believe since it's being pulled from the archive and it works pretty well on my Xenial machine. After consulting some in IRC the suggestion seems to be that I need to compile git from source in my snapcraft parts. After a few hours of trying to get the following part to compile I've all but given up. git: plugin: autotools source: https://github.com/git/git.git source-type: git source-tag: v2.9.3 install-via: prefix stage-packages: - libcurl4-gnutls-dev - libexpat1-dev - gettext - zlib1g-dev - libssl-dev - libc6-dev Has anyone included git as a part of their snap? Is there a different way to interface with git? How can I troubleshoot this further? We're (over)due for a release of charm and charm-tools and I'd honestly prefer snap distribution over deb packages but compiling git from upstream just to get it working seems like a step in the wrong direction. Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.dandrea at canonical.com Tue Aug 16 22:58:28 2016 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Tue, 16 Aug 2016 22:58:28 +0000 Subject: Putting git inside a snap In-Reply-To: References: Message-ID: On Tue, 16 Aug 2016 at 17:09 Marco Ceppi wrote: > > After consulting some in IRC the suggestion seems to be that I need to > compile git from source in my snapcraft parts. After a few hours of trying > to get the following part to compile I've all but given up. > Before content interfaces became a thing, I bundled git into the jenkins snap using the following (trimmed for clarity): https://gist.github.com/evandandrea/440222ecfbb37a1962512f33fb0fa7c9 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.ceppi at canonical.com Tue Aug 16 23:28:33 2016 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Tue, 16 Aug 2016 23:28:33 +0000 Subject: Putting git inside a snap In-Reply-To: References: Message-ID: Thanks for the hint, I've added that to my snapcraft.yaml but I'm still getting the same error. What's the best way to troubleshoot this, is there a way to 'enter' the snap environment and poke the git command? Marco On Tue, Aug 16, 2016 at 6:58 PM Evan Dandrea wrote: > On Tue, 16 Aug 2016 at 17:09 Marco Ceppi > wrote: > >> >> After consulting some in IRC the suggestion seems to be that I need to >> compile git from source in my snapcraft parts. After a few hours of trying >> to get the following part to compile I've all but given up. >> > > Before content interfaces became a thing, I bundled git into the jenkins > snap using the following (trimmed for clarity): > > https://gist.github.com/evandandrea/440222ecfbb37a1962512f33fb0fa7c9 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Tue Aug 16 23:45:18 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 17 Aug 2016 01:45:18 +0200 Subject: Putting git inside a snap In-Reply-To: References: Message-ID: <1471391118.22293.13.camel@ubuntu.com> hi, On Di, 2016-08-16 at 22:08 +0000, Marco Ceppi wrote: > Hello, I've spent the better part of my day hitting my head too hard > against a wall. Figured I'd ask the list for more assistance. > > tl;dr: git doesn't work when included inside my snap and it's really > messing me up. depending on how flexible a binary is you can try using wrappers any play with these ... https://git-scm.com/book/tr/v2/Git-Internals-Environment-Variables i would suspect git to be actually very flexible in that regard, given that devs most likely try out different versions installed in parallel ...  ;) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Wed Aug 17 02:09:13 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 16 Aug 2016 23:09:13 -0300 Subject: Putting git inside a snap In-Reply-To: References: Message-ID: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> El 16/08/16 a las 20:28, Marco Ceppi escribió: > Thanks for the hint, I've added that to my snapcraft.yaml but I'm still > getting the same error. What's the best way to troubleshoot this, is > there a way to 'enter' the snap environment and poke the git command? Create a new `apps` entry like this apps: sh: command: bash plugs: [same list of plugs used by what calls git] There's a `snap shell` (or similar) command making a come back some time and would make this more straightforward. For what it's worth I strace and gdb like this in a `snap try` session. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From robert.ancell at canonical.com Wed Aug 17 02:24:26 2016 From: robert.ancell at canonical.com (Robert Ancell) Date: Wed, 17 Aug 2016 02:24:26 +0000 Subject: snapd events API Message-ID: Hi, I've been trying to access snapd events using the REST API [1] and I'm not able to get it working. When I do the websocket upgrade I send something like this: GET /v2/events HTTP/1.1 Host: Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: ... Sec-WebSocket-Version: 13 And snapd just returns: HTTP/1.1 500 Internal Server Error Content-Type: text/plain; charset=utf-8 X-Content-Type-Options: nosniff Date: Wed, 17 Aug 2016 02:23:25 GMT Content-Length: 100 Internal Server Error websocket upgrade failed: websocket: response does not implement http.Hijacker Googling around it seems like the Go code needs to implement some sort of "Hijacker" interface. Has anyone got the events support to work? Am I doing something wrong? --Robert [1] https://github.com/snapcore/snapd/blob/master/docs/rest.md -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.lenton at canonical.com Wed Aug 17 10:25:45 2016 From: john.lenton at canonical.com (John Lenton) Date: Wed, 17 Aug 2016 11:25:45 +0100 Subject: snapd events API In-Reply-To: References: Message-ID: On 17 August 2016 at 03:24, Robert Ancell wrote: > I've been trying to access snapd events using the REST API [1] and I'm not > able to get it working. I'm afraid the events work has fallen by the wayside. It was not completed afaik, and obviously has no (or not enough) tests otherwise this would've popped up. We're not using it for anything, and the only consumer we had was also the implementer (namely snapweb) but moved away from using (at least in the short term) it mid-implementation. I'm all for fixing it, but we're rather tight for time I'm afraid. Patches welcome :-D From adam.stokes at canonical.com Wed Aug 17 13:07:25 2016 From: adam.stokes at canonical.com (Adam Stokes) Date: Wed, 17 Aug 2016 13:07:25 +0000 Subject: custom lxd bridges inside a snap In-Reply-To: <1471381481.2868.2.camel@canonical.com> References: <1471381481.2868.2.camel@canonical.com> Message-ID: After talking to people in IRC I've been lead to believe that I can't actually create and start a network bridge without the user running additional commands. My user experience is: $ snap install conjure-up .. custom LXD bridge is created during that install, the bridge is then started But what I'm being told is I have to do: $ snap install conjure-up $ snap connect $ some form of systemctl command This is required even though I've set in my snapcraft.yaml that I need access to those plugins (network-control, network-bind, firewall-control). This is actually a blocker for me as I can not replicate the same user experience as if the user was installing via deb packages. Am I missing anything? Can this be resolved to just running a single install command and having everything setup for the user to start with? For reference this is my snapcraft and files I need to work: https://github.com/conjure-up/conjure-up/tree/patch-add-bridge-to-snap/snapcraft On Tue, Aug 16, 2016 at 5:04 PM Jamie Strandboge wrote: > On Tue, 2016-08-16 at 19:07 +0000, Adam Stokes wrote: > > I've found some discussion on this here: > > > > > https://lists.ubuntu.com/archives/snappy-app-devel/2015-November/000477.html > > > > I am curious to know if this is possible now or still a work in > progress? I > > have a snap that requires a custom LXD bridge and would like to make use > of > > that if possible. > > The 'network-control' interface is meant to be used for this sort of thing > and > should give you the permissions required for setting up bridges, etc. If > there > are bugs with the security policy, please file them at: > > https://bugs.launchpad.net/snappy/+filebug > > and add the 'snapd-interface' tag. > > -- > Jamie Strandboge | http://www.canonical.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Wed Aug 17 13:20:16 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 17 Aug 2016 09:20:16 -0400 Subject: Putting git inside a snap In-Reply-To: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> References: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> Message-ID: On 16/08/16 22:09, Sergio Schvezov wrote: > Create a new `apps` entry like this > apps: > sh: > command: bash > plugs: [same list of plugs used by what calls git] > > There's a `snap shell` (or similar) command making a come back some time > and would make this more straightforward. Given the nature of sandboxing during the development process ("zomg the glass walls!") I think we should have a first-class command that spawns a $SHELL (not the shell of the snap but your preferred shell) inside the sandbox. It might be reasonable to have a snap.yaml flag to turn that ability OFF for some snaps, but it seems silly to have boilerplate for debugging purposes. For example, how about adding a 'enter-sandbox' command to snap, so: $ snap enter-sandbox app.command Now running inside the sandbox for app.command $ And in snap.yaml: debugging: [ allow-sandbox ] Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From david.calle at canonical.com Wed Aug 17 13:26:46 2016 From: david.calle at canonical.com (=?UTF-8?Q?David_Call=c3=a9?=) Date: Wed, 17 Aug 2016 15:26:46 +0200 Subject: Putting git inside a snap In-Reply-To: References: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> Message-ID: On 17/08/2016 15:20, Mark Shuttleworth wrote: > On 16/08/16 22:09, Sergio Schvezov wrote: >> Create a new `apps` entry like this >> apps: >> sh: >> command: bash >> plugs: [same list of plugs used by what calls git] >> >> There's a `snap shell` (or similar) command making a come back some time >> and would make this more straightforward. > Given the nature of sandboxing during the development process ("zomg the > glass walls!") I think we should have a first-class command that spawns > a $SHELL (not the shell of the snap but your preferred shell) inside the > sandbox. Isn't that the purpose of the 'snap run --shell' command? $ snap run --help [...] [run command options] --shell run a shell instead of the command (useful for debugging) David > > It might be reasonable to have a snap.yaml flag to turn that ability OFF > for some snaps, but it seems silly to have boilerplate for debugging > purposes. > > For example, how about adding a 'enter-sandbox' command to snap, so: > > $ snap enter-sandbox app.command > Now running inside the sandbox for app.command > $ > > And in snap.yaml: > > > debugging: [ allow-sandbox ] > > Mark > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Wed Aug 17 13:35:41 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 17 Aug 2016 09:35:41 -0400 Subject: Putting git inside a snap In-Reply-To: References: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> Message-ID: <1bebfb37-bb96-8a68-4a50-3335794347f3@ubuntu.com> On 17/08/16 09:26, David Callé wrote: > On 17/08/2016 15:20, Mark Shuttleworth wrote: >> On 16/08/16 22:09, Sergio Schvezov wrote: >>> Create a new `apps` entry like this >>> apps: >>> sh: >>> command: bash >>> plugs: [same list of plugs used by what calls git] >>> >>> There's a `snap shell` (or similar) command making a come back some time >>> and would make this more straightforward. >> Given the nature of sandboxing during the development process ("zomg the >> glass walls!") I think we should have a first-class command that spawns >> a $SHELL (not the shell of the snap but your preferred shell) inside the >> sandbox. > > Isn't that the purpose of the 'snap run --shell' command? > > $ snap run --help > [...] > [run command options] > --shell run a shell instead of the command (useful for > debugging) Oh that's nice! Can I use the actual command name to get the specific sandbox for that command? $ snap run --shell snap.command Also, this still seems to require that the snap author stuck "bin/bash" in the snap: $ snap run --shell docker.docker cannot snap-exec: cannot exec "/snap/docker/33/bin/bash": no such file or directory Seems like we could drop that requirement since /bin/bash is always in the core snap. But we might also want to let the publisher turn this off, hence the snap.yaml suggestions. And finally, I think that command should be "exec" not run, and the snap-exec error suggests others feel the same way :) Mark From marco.ceppi at canonical.com Wed Aug 17 13:36:16 2016 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Wed, 17 Aug 2016 13:36:16 +0000 Subject: Putting git inside a snap In-Reply-To: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> References: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> Message-ID: On Tue, Aug 16, 2016 at 10:11 PM Sergio Schvezov < sergio.schvezov at canonical.com> wrote: > Create a new `apps` entry like this > > apps: > sh: > command: bash > plugs: [same list of plugs used by what calls git] > I did something similar: apps: git: command: usr/bin/git plugs: [...] This way I could mess around with charm.git and play with environment variables. At the end of the day GIT_EXEC_PATH and PREFIX were needed. Even still I'm having issues with things like `git clone --recursive` so I've patched those calls out of the source code for now (when not needed). I'll keep playing around to see if I can get git-submodules to work but 95% of the use cases for the tool are functioning now. > There's a `snap shell` (or similar) command making a come back some time > and would make this more straightforward. > > For what it's worth I strace and gdb like this in a `snap try` session. > I spent quite a long time with strace against charm.git, but that lead to more problems than help. I've not used `snap try` yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Wed Aug 17 13:53:14 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 17 Aug 2016 08:53:14 -0500 Subject: custom lxd bridges inside a snap In-Reply-To: References: <1471381481.2868.2.camel@canonical.com> Message-ID: <1471441994.2868.12.camel@canonical.com> On Wed, 2016-08-17 at 13:07 +0000, Adam Stokes wrote: > After talking to people in IRC I've been lead to believe that I can't > actually create and start a network bridge without the user running > additional commands. > > My user experience is: > > $ snap install conjure-up > > .. custom LXD bridge is created during that install, the bridge is then > started > > But what I'm being told is I have to do: > > $ snap install conjure-up > $ snap connect The snap connect is needed for privileged interfaces like network-control. It would be unfortunate for a tic tac toe game to, upon install, reconfigure your networking stack behind the scenes without the user knowing. Future assertions work will allow these sorts of privileged interfaces to be auto-connected and AIUI gadget snap developers will also have a voice in auto-connect. > $ some form of systemctl command If you use:   daemon: simple # or one of the others   command: path/to/your/bridge/setup   stop-command: path/to/your/bridge/teardown then a systemd unit is created for path/to/your/bridge/setup/command. Based on your yaml, it seems you understand this point and AIUI, recent hooks work in snapd can help with running restarting your units after interface connect. Perhaps others can comment on the status of that work and how to leverage it? -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Wed Aug 17 13:55:03 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 17 Aug 2016 10:55:03 -0300 Subject: Putting git inside a snap In-Reply-To: References: <4d5a9efb-3850-9cf3-5cea-b68716162ce1@ubuntu.com> Message-ID: El 17/08/16 a las 10:36, Marco Ceppi escribió: > On Tue, Aug 16, 2016 at 10:11 PM Sergio Schvezov > > > wrote: > > Create a new `apps` entry like this > > apps: > sh: > command: bash > plugs: [same list of plugs used by what calls git] > > > I did something similar: > > apps: > git: > command: usr/bin/git > plugs: [...] > > This way I could mess around with charm.git and play with environment > variables. At the end of the day GIT_EXEC_PATH and PREFIX were needed. > > Even still I'm having issues with things like `git clone --recursive` so > I've patched those calls out of the source code for now (when not > needed). I'll keep playing around to see if I can get git-submodules to > work but 95% of the use cases for the tool are functioning now. > > > There's a `snap shell` (or similar) command making a come back some time > and would make this more straightforward. > > For what it's worth I strace and gdb like this in a `snap try` session. > > > I spent quite a long time with strace against charm.git, but that lead > to more problems than help. I've not used `snap try` yet. The reason I mention `snap try` is becuase I am lazy :-) snap try --devmode prime Then if needed when in the snap's environment cp /usr/bin/strace prime And anything else you can think of. From jamie at canonical.com Wed Aug 17 13:55:35 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 17 Aug 2016 08:55:35 -0500 Subject: Using sudo from within a snap In-Reply-To: <1471363183.6422.7.camel@canonical.com> References: <37b95712-fa23-4b2d-1d3b-a5f9688221f1@canonical.com> <1470648423.29378.18.camel@ubuntu.com> <1471363183.6422.7.camel@canonical.com> Message-ID: <1471442135.2868.13.camel@canonical.com> On Tue, 2016-08-16 at 10:59 -0500, Jamie Strandboge wrote: > On Tue, 2016-08-16 at 09:53 -0400, Chris Wayne wrote: > > > > Is this something that could be added to the roadmap?  We'd really prefer > > to not have to call the snap itself with sudo as it creates some > > permissions issues (root-owned dirs in $HOME for example) and some other > > general flakiness.  What would the sudo interface entail, just access to > > /usr/bin/sudo and /etc/sudoers.d/snap.mountpoint? > > > In the bug[1] we're focused on sudo and/or pkexec not working within a devmode > snap. With devmode, sudo should work and we can work through how to fix that. > Indeed, the conversation has moved to the bug. > For those interested, there was a bug in the snap itself and the details can be found here: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1610292/comments/4 -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Wed Aug 17 13:56:25 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 17 Aug 2016 10:56:25 -0300 Subject: snapd events API In-Reply-To: References: Message-ID: Yeah, this is non-working remainings of something that wasn't discussed much. Before patching it, we need to come up with a more clear idea of how the API looks like, how it's supposed to evolve, and what's the plan for integration into the various aspects of the system. On Wed, Aug 17, 2016 at 7:25 AM, John Lenton wrote: > On 17 August 2016 at 03:24, Robert Ancell > wrote: > > I've been trying to access snapd events using the REST API [1] and I'm > not > > able to get it working. > > I'm afraid the events work has fallen by the wayside. It was not > completed afaik, and obviously has no (or not enough) tests otherwise > this would've popped up. We're not using it for anything, and the only > consumer we had was also the implementer (namely snapweb) but moved > away from using (at least in the short term) it mid-implementation. > > I'm all for fixing it, but we're rather tight for time I'm afraid. > Patches welcome :-D > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at ubuntu.com Wed Aug 17 14:22:21 2016 From: ted at ubuntu.com (Ted Gould) Date: Wed, 17 Aug 2016 09:22:21 -0500 Subject: snapd events API In-Reply-To: References: Message-ID: <1471443741.6816.4.camel@ubuntu.com> For me, the most critical events are package installed, upgraded¹ and removed. The primary use-case is to handle entries on the Unity panel (i.e. remove them if the package gets removed). That seems like an easy place to get started. Ted ¹ Not sure if upgrade is a remove/install pair, listed for completeness, not because we have a need for it to be distinct. On Wed, 2016-08-17 at 10:56 -0300, Gustavo Niemeyer wrote: > Yeah, this is non-working remainings of something that wasn't > discussed much. > > Before patching it, we need to come up with a more clear idea of how > the API looks like, how it's supposed to evolve, and what's the plan > for integration into the various aspects of the system. > > On Wed, Aug 17, 2016 at 7:25 AM, John Lenton > om> wrote: > > On 17 August 2016 at 03:24, Robert Ancell > > com> wrote: > > > I've been trying to access snapd events using the REST API [1] > > and I'm not > > > able to get it working. > > > > I'm afraid the events work has fallen by the  wayside. It was not > > completed afaik, and obviously has no (or not enough) tests > > otherwise > > this would've popped up. We're not using it for anything, and the > > only > > consumer we had was also the implementer (namely snapweb) but moved > > away from using (at least in the short term) it mid-implementation. > > > > I'm all for fixing it, but we're rather tight for time I'm afraid. > > Patches welcome :-D > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > --  > gustavo @ http://niemeyer.net > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Wed Aug 17 14:26:23 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 17 Aug 2016 11:26:23 -0300 Subject: snapd events API In-Reply-To: <1471443741.6816.4.camel@ubuntu.com> References: <1471443741.6816.4.camel@ubuntu.com> Message-ID: Understood, thanks for the details. For the time being, I suggest implementing that in terms of polling since we already have good APIs for that which should be very fast (it's all in memory). This gives us some more time to focus on the image deliverables that we have impending, and some time to design the events API properly as well. On Wed, Aug 17, 2016 at 11:22 AM, Ted Gould wrote: > > For me, the most critical events are package installed, upgraded¹ and > removed. The primary use-case is to handle entries on the Unity panel (i.e. > remove them if the package gets removed). That seems like an easy place to > get started. > > Ted > > ¹ Not sure if upgrade is a remove/install pair, listed for completeness, > not because we have a need for it to be distinct. > > On Wed, 2016-08-17 at 10:56 -0300, Gustavo Niemeyer wrote: > > Yeah, this is non-working remainings of something that wasn't discussed > much. > > Before patching it, we need to come up with a more clear idea of how the > API looks like, how it's supposed to evolve, and what's the plan for > integration into the various aspects of the system. > > On Wed, Aug 17, 2016 at 7:25 AM, John Lenton > wrote: > > On 17 August 2016 at 03:24, Robert Ancell > wrote: > > I've been trying to access snapd events using the REST API [1] and I'm > not > > able to get it working. > > I'm afraid the events work has fallen by the wayside. It was not > completed afaik, and obviously has no (or not enough) tests otherwise > this would've popped up. We're not using it for anything, and the only > consumer we had was also the implementer (namely snapweb) but moved > away from using (at least in the short term) it mid-implementation. > > I'm all for fixing it, but we're rather tight for time I'm afraid. > Patches welcome :-D > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing listSnapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Wed Aug 17 15:45:04 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 17 Aug 2016 11:45:04 -0400 Subject: custom lxd bridges inside a snap In-Reply-To: <1471441994.2868.12.camel@canonical.com> References: <1471381481.2868.2.camel@canonical.com> <1471441994.2868.12.camel@canonical.com> Message-ID: <48c039c7-88a0-8882-8f2a-4703dca3dacd@ubuntu.com> On 17/08/16 09:53, Jamie Strandboge wrote: > The snap connect is needed for privileged interfaces like > network-control. It > would be unfortunate for a tic tac toe game to, upon install, reconfigure your > networking stack behind the scenes without the user knowing. Future assertions > work will allow these sorts of privileged interfaces to be auto-connected and > AIUI gadget snap developers will also have a voice in auto-connect. I think the way Jamie phrased this is misleading. Our intent is that specific auto-connections can be approved in advance. That capability does not yet exist, but will soon. What Adam is asking for is a perfectly reasonable thing and our intent is to make that work the way he wants. So Adam, don't worry about this, go ahead (but document the connect command required while it is still needed). Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From dgarrod at extremenetworks.com Wed Aug 17 18:52:55 2016 From: dgarrod at extremenetworks.com (David Garrod) Date: Wed, 17 Aug 2016 18:52:55 +0000 Subject: How do I share a namespace between snap commands? References: <1469638980.5406.135.camel@canonical.com> <82b76113-3b81-3e33-688b-36bca351c11a@ubuntu.com> Message-ID: Unfortunately my bug report has not received any substantive replies so I'm back here. Please could someone comment on the issue I'm having and/or give me a pointer on where to look to try and diagnose the cause of the failure. This problem is severely holding up our progress in SNAPifying OpenSwitch. Thanks, Dave -----Original Message----- From: David Garrod Sent: Tuesday, August 09, 2016 12:32 PM To: 'Didier Roche'; Jamie Strandboge; snapcraft at lists.ubuntu.com Subject: RE: How do I share a namespace between snap commands? Re: > even if you continue posting here (which is good to trigger discussion), please file a bug against the snappy launchpad project: >https://launchpad.net/snappy/ (even if I think this one may impact rather snap-confine, but it will be redirected) > >Didier Thanks. I've followed your suggestion and have logged bug: https://bugs.launchpad.net/snappy/+bug/1611444 ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From marco.ceppi at canonical.com Wed Aug 17 21:28:32 2016 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Wed, 17 Aug 2016 21:28:32 +0000 Subject: Guidance on deprecating debs for snaps Message-ID: Hello! Today we have packages in xenial that provide software which I intend to provide as snap only going forward. Since I'm generally lazy, and don't want to do both snap and debs of the software, snaps are a huge win in simplicity of release for me. Has anyone deprecated debian packages yet in favor of snaps? My end goal is people who've installed the debian package from the xenial archive will get an updated debian package which no longer is the software but instead either guides them to installing the snap or installs it for them. Are there guidelines for how to do this? Has anyone tried before? Or should we not tangle these two yet? Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Wed Aug 17 21:41:33 2016 From: seth.arnold at canonical.com (Seth Arnold) Date: Wed, 17 Aug 2016 14:41:33 -0700 Subject: Guidance on deprecating debs for snaps In-Reply-To: References: Message-ID: <20160817214133.GC17621@hunt> On Wed, Aug 17, 2016 at 09:28:32PM +0000, Marco Ceppi wrote: > Has anyone deprecated debian packages yet in favor of snaps? My end goal is > people who've installed the debian package from the xenial archive will get > an updated debian package which no longer is the software but instead > either guides them to installing the snap or installs it for them. This sounds like a surprising and inconsiderate thing to do to our users. There's probably still time to get your transitional package into yakkety before feature freeze (or file for a feature freeze exception) but once it was shipped in an LTS we've agreed to support it for five years. (Where "support" is of course variable -- for main, we support it. For universe, the community supports it and someone will sponsor updates.) Be sure to consider how 16.04 LTS -> 18.04 LTS upgrades will work. We also support LTS to LTS upgrades. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From marco.ceppi at canonical.com Wed Aug 17 21:56:15 2016 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Wed, 17 Aug 2016 21:56:15 +0000 Subject: Guidance on deprecating debs for snaps In-Reply-To: <20160817214133.GC17621@hunt> References: <20160817214133.GC17621@hunt> Message-ID: On Wed, Aug 17, 2016 at 5:42 PM Seth Arnold wrote: > On Wed, Aug 17, 2016 at 09:28:32PM +0000, Marco Ceppi wrote: > > Has anyone deprecated debian packages yet in favor of snaps? My end goal > is > > people who've installed the debian package from the xenial archive will > get > > an updated debian package which no longer is the software but instead > > either guides them to installing the snap or installs it for them. > > This sounds like a surprising and inconsiderate thing to do to our > users. There's probably still time to get your transitional package into > yakkety before feature freeze (or file for a feature freeze exception) but > once it was shipped in an LTS we've agreed to support it for five years. > (Where "support" is of course variable -- for main, we support it. For > universe, the community supports it and someone will sponsor updates.) > Well, it's either that or basically anyone who installs the debian version from the archive just deals with an out of date, never updated, version of the software. That to me, as a maintainer of a software project, feels more inconsiderate. I ask because I'd like to get my users the latest bits, but there seems to be no way for me to have a snap "conflict" with a deb package (which, I get is the whole point). So now, if you snap install, /usr/bin/ still takes priority over /snap/bin. This means I have make sure not only to tell people to snap install the software, but also uninstall the previous deb packages. I can only imagine this leading to a lot of confusion as updates are released in the snap but aren't reflected on users systems. > Be sure to consider how 16.04 LTS -> 18.04 LTS upgrades will work. We also > support LTS to LTS upgrades. > It sounds like I simply need to pull my packages from yakkety now. I don't plan on continuing to build debian packages going forward. I just don't see a point in it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.chen at canonical.com Thu Aug 18 01:47:59 2016 From: david.chen at canonical.com (David Chen) Date: Thu, 18 Aug 2016 09:47:59 +0800 Subject: ANN: snapcraft 2.14 has been released In-Reply-To: <6e874878-83aa-7616-7b1c-0313ba7f2c66@ubuntu.com> References: <6e874878-83aa-7616-7b1c-0313ba7f2c66@ubuntu.com> Message-ID: <9f0777ef-34d4-b640-33f4-7bb4028239a8@canonical.com> Hi Sergio, Do you know where I can find examples for new plugins `dump`, `rust` and `godeps`? Thanks and Regards, -David On 08/11/2016 07:14 AM, Sergio Schvezov wrote: > Hi there, just in case people are not on the announce list (you should > if you care about these ANN emails), here's the announcement email link: > > https://lists.ubuntu.com/archives/snapcraft-announce/2016-August/000000.html > > If you prefer formatted text the same content can be seen here: > > https://github.com/snapcore/snapcraft/releases/tag/2.14 > > Cheers > Sergio > > > -- * DAVID CHEN * Technical Lead | Field Engineering | UES RM D, 46F, No. 7, Sec. 5, Xin-Yi Rd., Taipei City, Taiwan 11049 *O* +(886) 2 8729-6885 *M* +(886) 988-858-524 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: footer_logo.png Type: image/png Size: 1737 bytes Desc: not available URL: From gustavo.niemeyer at canonical.com Thu Aug 18 02:17:35 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 17 Aug 2016 23:17:35 -0300 Subject: HEADS UP: New spread version coming Message-ID: Hello all, The following changes have just landed in the spread repository, some of them incompatible with the previous yaml files. Given the incompatibility, the spread snap or the binary version used by the snapd tests weren't updated, but this should happen at some point tomorrow. The main changes are: - Reboot at any point by simply inlining the # REBOOT comment - New QEMU backend, thanks to Michael Vogt - Environment variables are now properly ordered - The syntax $[...] in env vars has been dropped - The syntax $(...) in env vars will now execute remotely as expected - The syntax $(HOST: ...) was introduced to execute the command locally - Both of these will now correctly strip of EOLs, thanks to John Lenton - Bash now executed with -u, to catch undefined vars, also thanks to John - Images with fixed usernames and passwords are now supported - $HOME won't be hacked when debugging tasks (-debug and -shell) The documentation was updated to cover all the changes: https://github.com/snapcore/spread Please let me know if you find any issues. gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Thu Aug 18 02:20:20 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 17 Aug 2016 23:20:20 -0300 Subject: ANN: snapcraft 2.14 has been released In-Reply-To: <9f0777ef-34d4-b640-33f4-7bb4028239a8@canonical.com> References: <6e874878-83aa-7616-7b1c-0313ba7f2c66@ubuntu.com> <9f0777ef-34d4-b640-33f4-7bb4028239a8@canonical.com> Message-ID: El 17/08/16 a las 22:47, David Chen escribió: > Hi Sergio, > > Do you know where I can find examples for new plugins `dump`, `rust` and > `godeps`? For godeps look at the juju folk (ping balloons on irc). For dump, it is pretty straightforward, the tomcat maven example/demo in the sources use it. Rust is contributed by the community, I have no example but know elopio ran a project with it. In any case, `snapcraft help ` is what you need to get started. From mark at ubuntu.com Thu Aug 18 11:37:00 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 18 Aug 2016 07:37:00 -0400 Subject: Guidance on deprecating debs for snaps In-Reply-To: References: <20160817214133.GC17621@hunt> Message-ID: <979a7e8f-1719-d0d1-daa1-cc38fa3601eb@ubuntu.com> Policy for non-core apps is that newer versions should be provided as snaps, LTS-released versions should be maintained as debs (but not updated to newer versions). By non-core I mean anything that is not in the ubuntu-core snap. By apps I mean things that would make a natural snap or (in the case of libraries) snapcraft part. So Marco is exactly right to ask this question now, since we need to evolve a best practice for how to socialize that there is a newer version of the software available as a snap. Mark From jenny.murphy at episensor.com Thu Aug 18 11:37:50 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 18 Aug 2016 12:37:50 +0100 Subject: ubuntu login on Snappy Ubuntu Core Message-ID: Hi, Is it possible that the ubuntu login on a Snappy Ubuntu Core platform can expire. Up to one month ago I was logging in with username ubuntu and the password ubuntu. Now access is denied with that password. I am grateful for any suggestions. Jenny -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.stokes at canonical.com Thu Aug 18 12:16:15 2016 From: adam.stokes at canonical.com (Adam Stokes) Date: Thu, 18 Aug 2016 12:16:15 +0000 Subject: Guidance on deprecating debs for snaps In-Reply-To: <979a7e8f-1719-d0d1-daa1-cc38fa3601eb@ubuntu.com> References: <20160817214133.GC17621@hunt> <979a7e8f-1719-d0d1-daa1-cc38fa3601eb@ubuntu.com> Message-ID: I spoke with Steve Langasek about this a bit ago and the solution he mentioned was to convert your deb package into basically a stub package that prints a debconf note guiding the user to install the updated apps via `snap install`. On Thu, Aug 18, 2016 at 7:38 AM Mark Shuttleworth wrote: > > Policy for non-core apps is that newer versions should be provided as > snaps, LTS-released versions should be maintained as debs (but not > updated to newer versions). > > By non-core I mean anything that is not in the ubuntu-core snap. > > By apps I mean things that would make a natural snap or (in the case of > libraries) snapcraft part. > > So Marco is exactly right to ask this question now, since we need to > evolve a best practice for how to socialize that there is a newer > version of the software available as a snap. > > Mark > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.stokes at canonical.com Thu Aug 18 12:18:37 2016 From: adam.stokes at canonical.com (Adam Stokes) Date: Thu, 18 Aug 2016 12:18:37 +0000 Subject: ANN: snapcraft 2.14 has been released In-Reply-To: References: <6e874878-83aa-7616-7b1c-0313ba7f2c66@ubuntu.com> <9f0777ef-34d4-b640-33f4-7bb4028239a8@canonical.com> Message-ID: Hi David, Here is my snapcraft.yaml that shows using the dump plugin: https://github.com/conjure-up/conjure-up/blob/master/snapcraft/snapcraft.yaml On Wed, Aug 17, 2016 at 10:21 PM Sergio Schvezov < sergio.schvezov at canonical.com> wrote: > > El 17/08/16 a las 22:47, David Chen escribió: > > Hi Sergio, > > > > Do you know where I can find examples for new plugins `dump`, `rust` and > > `godeps`? > > For godeps look at the juju folk (ping balloons on irc). > For dump, it is pretty straightforward, the tomcat maven example/demo in > the sources use it. > Rust is contributed by the community, I have no example but know elopio > ran a project with it. > > In any case, `snapcraft help ` is what you need to get > started. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Thu Aug 18 12:22:51 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 18 Aug 2016 09:22:51 -0300 Subject: ubuntu login on Snappy Ubuntu Core In-Reply-To: References: Message-ID: <284be995-263a-b3e2-f700-a8371b824106@ubuntu.com> El 18/08/16 a las 08:37, Jenny Murphy escribió: > Hi, > Is it possible that the ubuntu login on a Snappy Ubuntu Core platform > can expire. > Up to one month ago I was logging in with username ubuntu and the > password ubuntu. > Now access is denied with that password. > I am grateful for any suggestions. Yes, the macaroon expires. It can however be refreshed. As far as I know, snapd had some refresh logic in place. In the case of snapcraft we do not have the refresh logic in place yet. If this is snapd related, the version you are on would be good to know to determine if there is a bug or that you are just not in the release that implements refreshing the macaroon. A quick search made me think you might be affected by https://bugs.launchpad.net/click-package-index/+bug/1606897 Cheers Sergio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From sergio.schvezov at canonical.com Thu Aug 18 12:28:25 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 18 Aug 2016 09:28:25 -0300 Subject: ubuntu login on Snappy Ubuntu Core In-Reply-To: References: Message-ID: <51f34932-8fe5-8e86-b480-745253067031@ubuntu.com> Disregard my previous email, my mind was set to snapd and store communication. Sorry about that El 18/08/16 a las 08:37, Jenny Murphy escribió: > Hi, > Is it possible that the ubuntu login on a Snappy Ubuntu Core platform > can expire. > Up to one month ago I was logging in with username ubuntu and the > password ubuntu. > Now access is denied with that password. > I am grateful for any suggestions. > Jenny > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 > (0) 61 512 511 w | http://www.episensor.com > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From john.lenton at canonical.com Thu Aug 18 13:12:30 2016 From: john.lenton at canonical.com (John Lenton) Date: Thu, 18 Aug 2016 14:12:30 +0100 Subject: ubuntu login on Snappy Ubuntu Core In-Reply-To: References: Message-ID: On 18 August 2016 at 12:37, Jenny Murphy wrote: > Is it possible that the ubuntu login on a Snappy Ubuntu Core platform can > expire. no (well, yes, but it's something you'd have to do yourself using the usual pam tools, not something snappy would do for you). What images are you using? From jamie at canonical.com Thu Aug 18 13:58:31 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 18 Aug 2016 08:58:31 -0500 Subject: How do I share a namespace between snap commands? In-Reply-To: References: <1469638980.5406.135.camel@canonical.com> <82b76113-3b81-3e33-688b-36bca351c11a@ubuntu.com> Message-ID: <1471528711.2868.19.camel@canonical.com> On Wed, 2016-08-17 at 18:52 +0000, David Garrod wrote: > Unfortunately my bug report has not received any substantive replies so I'm > back here. Please could someone comment on the issue I'm having and/or give me > a pointer on where to look to try and diagnose the cause of the failure. This > problem is severely holding up our progress in SNAPifying OpenSwitch. > FYI for those watching the list and not the bug[1], the problem stems from snappy's use of a private mount namespace. That discussion and paths forward are being discussed in the bug. [1]https://bugs.launchpad.net/snappy/+bug/1611444 > Thanks, > > Dave > > -----Original Message----- > From: David Garrod > Sent: Tuesday, August 09, 2016 12:32 PM > To: 'Didier Roche'; Jamie Strandboge; snapcraft at lists.ubuntu.com > Subject: RE: How do I share a namespace between snap commands? > > Re: > > > > > even if you continue posting here (which is good to trigger discussion), > > please file a bug against the snappy launchpad project: > > https://launchpad.net/snappy/ (even if I think this one may impact rather > > snap-confine, but it will be redirected) > > > > Didier > Thanks. I've followed your suggestion and have logged bug: > > https://bugs.launchpad.net/snappy/+bug/1611444 > > > ________________________________ > > DISCLAIMER: > This e-mail and any attachments to it may contain confidential and proprietary > material and is solely for the use of the intended recipient. Any review, use, > disclosure, distribution or copying of this transmittal is prohibited except > by or on behalf of the intended recipient. If you have received this > transmittal in error, please notify the sender and destroy this e-mail and any > attachments and all copies, whether electronic or printed. > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jenny.murphy at episensor.com Thu Aug 18 14:56:17 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 18 Aug 2016 15:56:17 +0100 Subject: ubuntu login on Snappy Ubuntu Core In-Reply-To: References: Message-ID: Hi, I am using snapcraft 1.1.0 and ubuntu-core 15.04. On 18 August 2016 at 14:12, John Lenton wrote: > On 18 August 2016 at 12:37, Jenny Murphy > wrote: > > Is it possible that the ubuntu login on a Snappy Ubuntu Core platform > can > > expire. > > no (well, yes, but it's something you'd have to do yourself using the > usual pam tools, not something snappy would do for you). > > What images are you using? > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Thu Aug 18 16:39:46 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 18 Aug 2016 12:39:46 -0400 Subject: Guidance on deprecating debs for snaps In-Reply-To: References: <20160817214133.GC17621@hunt> <979a7e8f-1719-d0d1-daa1-cc38fa3601eb@ubuntu.com> Message-ID: On 18/08/16 08:16, Adam Stokes wrote: > I spoke with Steve Langasek about this a bit ago and the solution he > mentioned was to convert your deb package into basically a stub > package that prints a debconf note guiding the user to install the > updated apps via `snap install`. Right, in some cases we will actually want to convert folks from the one to the other. In others, we'll want to alert them that there is a newer version of the app available in the other format, then handle the crossover cleanly (i.e. snap install might also remove the deb). Mark From robert.ancell at canonical.com Fri Aug 19 02:33:04 2016 From: robert.ancell at canonical.com (Robert Ancell) Date: Fri, 19 Aug 2016 02:33:04 +0000 Subject: Announcing snapd-glib Message-ID: Hi all, At the Heidelberg sprint we decided to create a library that would allow GLib based projects to more easily access snapd and reduce duplication across these projects. I've got the first cut of this done, meet snapd-glib! - On Launchpad [1] - Implements all [2] of the snapd REST API [3]. - Provides both synchronous and asynchronous methods - Supports GObject introspection (i.e. Python etc support) - Supports Vala. - Will support Qt/QML in the future [4]. - Uploaded to Ubuntu Yakkety, will be there once it is accepted into the NEW queue. Use the libsnapd-glib-dev or gir1.2-snapd-0 packages. - Currently using so version number 0 - ABI is not guaranteed to be stable until we go to 1. - Will SRU to Ubuntu 14.04 once the API/ABI is stable. Here's a taste of the API: #!/usr/bin/python import gi gi.require_version ('Snapd', '0') from gi.repository import Snapd c = Snapd.Client () c.connect_sync () snaps = c.list_sync () for s in snaps: print s.get_name () + ' ' + s.get_version () Happy Hacking! (And patches welcome). --Robert [1] http://launchpad.net/snapd-glib [2] OK, just the main stuff and what I was able to get to work. But the goal is to access everything there. [3] https://github.com/snapcore/snapd/blob/master/docs/rest.md [4] https://bugs.launchpad.net/bugs/1614797 -------------- next part -------------- An HTML attachment was scrubbed... URL: From honeycuttaaron3 at gmail.com Fri Aug 19 09:35:55 2016 From: honeycuttaaron3 at gmail.com (Aaron Honeycutt) Date: Fri, 19 Aug 2016 05:35:55 -0400 Subject: Announcing snapd-glib In-Reply-To: References: Message-ID: Could this help with this error when trying to snap Pithos ( http://pastebin.ubuntu.com/23068283/) ? On Thu, Aug 18, 2016 at 10:33 PM, Robert Ancell wrote: > Hi all, > > At the Heidelberg sprint we decided to create a library that would allow > GLib based projects to more easily access snapd and reduce duplication > across these projects. > > I've got the first cut of this done, meet snapd-glib! > > - On Launchpad [1] > - Implements all [2] of the snapd REST API [3]. > - Provides both synchronous and asynchronous methods > - Supports GObject introspection (i.e. Python etc support) > - Supports Vala. > - Will support Qt/QML in the future [4]. > - Uploaded to Ubuntu Yakkety, will be there once it is accepted into the > NEW queue. Use the libsnapd-glib-dev or gir1.2-snapd-0 packages. > - Currently using so version number 0 - ABI is not guaranteed to be stable > until we go to 1. > - Will SRU to Ubuntu 14.04 once the API/ABI is stable. > > Here's a taste of the API: > > #!/usr/bin/python > > import gi > > gi.require_version ('Snapd', '0') > from gi.repository import Snapd > > c = Snapd.Client () > c.connect_sync () > snaps = c.list_sync () > for s in snaps: > print s.get_name () + ' ' + s.get_version () > > Happy Hacking! (And patches welcome). > > --Robert > > [1] http://launchpad.net/snapd-glib > [2] OK, just the main stuff and what I was able to get to work. But the > goal is to access everything there. > [3] https://github.com/snapcore/snapd/blob/master/docs/rest.md > [4] https://bugs.launchpad.net/bugs/1614797 > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.chen at canonical.com Fri Aug 19 10:10:44 2016 From: david.chen at canonical.com (David Chen) Date: Fri, 19 Aug 2016 18:10:44 +0800 Subject: Snapping Qt 5.7 APPs Message-ID: Hi, I met some problems when trying to create snap for Qt5.7 apps. After some digging and discussing with people, finally I have a temporary solution which I thought might be worth sharing. Please see the example below that I put together, hopefully people will find it useful and solve some of their problems as well. https://github.com/davidchen0813/virtualkeyboard-demo Detail listed in README.md. Notes: 1. The example uses a custom plugin [1], which is modified from old qml plugin [2]. 2. If you are running Nvidia graphic, you might meet this issue: https://bugs.launchpad.net/snappy/+bug/1588192 3. Without LIBGL_DRIVERS_PATH=$SNAP/usr/lib/x86_64-linux-gnu/dri, you will hit this issue: https://bugs.launchpad.net/snappy/+bug/1584178 [1] https://github.com/snapcore/snapcraft/blob/46c46d31b21e4283c4b8fba3e432fb8458414236/docs/plugins.md [2] http://bazaar.launchpad.net/~ted/snapcraft/qml/view/head:/snapcraft/plugins/qml.py Thanks and Regards, -- DAVID CHEN -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.voss at canonical.com Fri Aug 19 13:39:02 2016 From: thomas.voss at canonical.com (=?UTF-8?Q?Thomas_Vo=C3=9F?=) Date: Fri, 19 Aug 2016 15:39:02 +0200 Subject: Using snap for application with plugins In-Reply-To: References: Message-ID: On Tue, Aug 16, 2016 at 9:55 PM, Alexey Yakovenko wrote: > Hi Thomas > > Thanks for replying so quickly! Answering inline. :) > And sorry for the high latency now, your reply made it to my spam folder *sigh* > On Tue, Aug 16, 2016 at 8:56 PM, Thomas Voß > wrote: >> >> Hey Alexey, >> >> first of all: Thanks for reaching out :) And to answer your final >> question first: Snap'ing up applications that feature >> a runtime extension mechanism is certainly possible, complexity >> depends on the actual application, though. >> >> To get you started fast: devmode (see >> http://askubuntu.com/questions/783945/what-is-devmode-for-snaps) >> should help to get you off the ground. > > > Yes, thanks, I know about dev mode, of course running the app in dev mode > just makes it work the same, as it would work without using snap, right?. > I can also run my application from the mounted snap volume directly, with > the same result. Of course this works. > > However, I suppose that this is not really the idea behind snap? > Or is it one of the standard / expected use cases on the end users side, to > install from snap, but run directly? > >> >> >> Also note that we are right now snap'ing our Unity8 scopes and dash >> infrastructure. In a sense, our scopes are an example of a >> really complex plugin system and we are likely facing very similar >> problems. > > > Well, yeah, perhaps, but in your case, as far as I understand, you can > either build snaps for all of the scopes, or force the scope developers to > do that. > I can't have this luxury. Please, see below for more answers and more > questions :) > >> >> >> I'll ask specific questions inline. >> >> On Tue, Aug 16, 2016 at 8:08 PM, Alexey Yakovenko >> wrote: >> > Hi >> > >> > (Before I start, I'd like to apologise if this message has duplicates, I >> > messed up with the mailing list subscription at first). >> > >> > Many users are requesting snap package format for my music player >> > application. >> > >> > I researched this topic, and came up with a list of problems which I >> > could >> > not solve from documentation or google searches. >> > >> > So here's a short introduction to my app architecture: >> > >> > * The main module, which is a console application, which can load and >> > use >> > plugins of various kinds >> >> Is your application using an in- or out-of-process plugin architecture? > > > In-process. > >> >> >> > * A set of standard plugins, which can link to certain libraries >> > * Example plugins: GTK2 UI, GTK3 UI, PulseAudio output, Various >> > input >> > plugins, etc >> >> Do you maintain those plugins in-tree? Would you be fine with >> distributing them within your application's snap? >> Or would you rather prefer to distribute them as separate snaps, with >> you being the publisher? > > > They are 3rd party projects, most often developed and distributed without my > knowledge -- i.e. 100% third party. > They can be released a few years after my application ships. > Most of the time, they are also binary-compatible with multiple versions of > the host application. > There's a ton of plugins which can run on any version of the host app, > released in the last 5 years. > Even if I wanted to make snaps for each of them, I would not have resources > to do that. > So I can't really answer positively to any of the 2 questions. > The plugins are just *.so files, sometimes with extra data files, which need > to be dropped to ~/.local/lib/appname (that's when not using snap). > > Of course, the standard plugins which I ship with the host application don't > have any problems, I think they would "just work". > >> >> >> > * External plugins, which a user may download from internet -- they can >> > be >> > anything, for example a plugin could implement a UI in Qt4 or Qt5, or >> > ncurses, or play sound via Jack. >> >> Is the download and installation handled by your application or with >> the help of the underlying packaging system? > > > Neither. Usually a user downloads a zip file from a plugin developer's > website, and unpacks it into ~/.local/lib/appname. > If there are no binary builds available, a user has to compile the plugin by > himself. Many developers are providing shell scripts to compile and install, > or full featured build systems using Make etc. > > Unfortunately, neither the host application, nor the plugins, are available > in most linux distribution package systems. > This is what's making snap particularly interesting (if it can do what's > needed). > > >> >> As to what degree do you "trust" those plugins and their authors? > > > I don't know most of them. > There are a few developers who I have contact with, but technically I can't > trust any of them. > It's completely up to the end user whether to install certain plugin, or not > -- the same way as he would install an application downloaded from the > internet. > Now that triggers a question for me: How do end users resolve dependencies of plugins today? Do they just assume that the downloaded plugins bring along whatever they need? Or do they rely on the package manager to resolve dependencies ad hoc? In any case: It seems to me that shipping your application and its core plugins as a snap is certainly possible. For installing 3rd party plugins: Why not have an "app" or command on your snap that takes care of copying files and folders to the right place in the writable parts of the snap. I'm thinking along the lines of: yourapp.install-plugin /path/to/file/or/folder That would also help your users in that they don't need to know about a specific directory to place plugins into. > >> >> Would you be fine to publish them as well? > > > I'm already publishing a bunch of the 3rd party plugins, but I can't publish > all of them for many reasons. > There are simply too many of these projects. I can't even keep track of > them. > Basically, people release new ones almost weekly. > >> >> >> > * It is not known at the time of package creation, what these >> > packages >> > could be. >> > >> > So when I'm creating the package, I have a problem -- which UI toolkit >> > to >> > use, if my app supports any toolkit? It ships with GTK2 and GTK3, but >> > there >> > are external plugins which add more toolkits. I can't really predict >> > which >> > toolkit the user wants, and what libraries the plugins will use -- it >> > can be >> > Qt4 or 5, or ncurses, or anything really. >> > >> >> I'm trying to rephrase a little: Your application supports plugins >> which may use *any* toolkit >> as long as the plugin bundles the respective runtime dependencies >> correctly. So it is ultimately the >> responsibility of the plugin to provide all the required libraries. > > > Yeah, so the answer is "a plugin which is using Qt5 could work, but it would > need to be in snap package, and has to ship its own version of Qt5" as an > example? Yup, but that comes back to my question: How are dependencies for the plugins handled today? > But still, each of the plugin developers would have to provide each of their > plugins in snap packages? Not necessarily, see my comment before. You could decide to support both ways. > The problem is that I can't make them do that. I don't have communication > with them. > Some developers build a plugin, make a .so out of it, put this on their > website, and forget about it forever. > So we sometimes have only this .so file, without source code even. > > What is also important: a user might already have a bunch of plugins > installed on his computer, and he would obviously want or need to keep them, > so if he can't use them with deadbeef from Snap -- he would not be using > deadbeef from snap at all, and stick with another installation method (one > of the existing ones). > Access to common shared directories in the user's home directory is possible. I think that should solve the problem of supporting old plugin installations. > A more complex question that I couldn't find an answer too: > How to make a snap, which can use both GTK2 and GTK3. > > To simplify the discussion, let's say I have 2 executable files, app_gtk2, > and app_gtk3. They ship in the same snap. > Is it possible to do this, so that either of the 2 apps can be used from > within the same snap package? > Sure, you can have multiple apps/commands defined on your snap and just bundle all of their dependencies up. snapcraft helps you in crafting such a snap. HTH, Thomas > So what I described above is a simplified version. > > What I really have: there's only 1 executable file, but it can load either a > GTK2 plugin (ui_gtk2.so), or a GTK3 plugin (ui_gtk3.so), depending on the > configuration and command line options. > > >> >> > Another problem. Let's take the jack output plugin as an example.. >> > >> > If the user downloads jack.so (the plugin), and puts it in the folder, >> > the >> > player won't be able to load it, because the jack client library is not >> > a >> > part of snap, or because there's no access to jack server, or something >> > like >> > that, correct? >> > >> >> The answer depends on how your application handles plugin download & >> installation. >> The issues would be solved if plugins were snaps. In that case, the >> individual plugin brings >> along its dependencies and defines the interfaces it would like to use >> (see [1] for an excellent introduction & overview to >> Snappy interfaces). > > > Application itself doesn't manage plugin download & installation at all. > It can load and run the plugins which are already downloaded and present in > one of the pre-defined folders. > > There's no central registry of all plugins, therefore it's not really > possible to change this easily. > >> >> >> > So, the final question.. Is it just a terrible idea to use snap for this >> > kind of applications? Or am I misunderstanding something, and all of >> > this is >> > possible? >> > >> > I really hope to get some useful "official" answers, which I could >> > forward >> > to the users which request snap packages :) >> > >> >> Looking forward to your answers and to dive deeper in your specific case. >> >> Cheers, >> >> Thomas >> >> P.S.: Feel free to reach out on irc(#snappy at freenode), too. > > > Sure, let's see the outcome of this round of questions, and then we can see > if it's worth to continue. > >> >> >> [1] http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html >> >> > Best regards. >> > >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > > From wakeroid at gmail.com Fri Aug 19 16:38:52 2016 From: wakeroid at gmail.com (Alexey Yakovenko) Date: Fri, 19 Aug 2016 18:38:52 +0200 Subject: Using snap for application with plugins In-Reply-To: References: Message-ID: Hi Thomas, and sorry for the duplicate message, at first I replied privately instead of posting to the list > >> > >> As to what degree do you "trust" those plugins and their authors? > > > > > > I don't know most of them. > > There are a few developers who I have contact with, but technically I > can't > > trust any of them. > > It's completely up to the end user whether to install certain plugin, or > not > > -- the same way as he would install an application downloaded from the > > internet. > > > > Now that triggers a question for me: How do end users resolve > dependencies of plugins today? > Do they just assume that the downloaded plugins bring along whatever > they need? Or do they rely > on the package manager to resolve dependencies ad hoc? > When the users download binaries, they usually only rely on the "system" libraries, like GTK, GLIBC, etc, and statically link everything else. However, many plugins require certain libraries to be installed in the system, and won't load otherwise. Of course, these plugins only dynamically link to the libraries with stable API and which support backwards compatibility. Example being the plugin for supporting Jack, or Qt. I'm not aware of any popular linux distributions, that ship my application or its plugins, so there's no answer to the package manager question. > > In any case: It seems to me that shipping your application and its > core plugins as a snap is certainly possible. > Yes, I mentioned in one of the previous conversations, that this part works fine. > For installing 3rd party plugins: Why not have an "app" or command on > your snap that takes care of copying files and folders > to the right place in the writable parts of the snap. I'm thinking > along the lines of: > > yourapp.install-plugin /path/to/file/or/folder > Yes, I think we figured out that part already in the previous round (or maybe I figured this out by talking with someone else). However, the plugins won't be able to access the libraries from within sandbox, so they won't work. As far as I understand, the way to solve this would be to package such plugins as snap packages. However, at this time I don't know how to make the host application find those plugins (i.e. how to enumerate any external plugins installed via snap). > > That would also help your users in that they don't need to know about > a specific directory to place plugins into. > That's more a usability problem, than a technical one. And yes, I agree that usability can be improved this way. But that won't make the plugins work :) > > Yeah, so the answer is "a plugin which is using Qt5 could work, but it > would > > need to be in snap package, and has to ship its own version of Qt5" as an > > example? > > Yup, but that comes back to my question: How are dependencies for the > plugins > handled today? > They are not handled in any way. Basically, you download a plugin, and you need to make sure that e.g. Qt is installed. If Qt is not installed -- dlopen would fail, and the plugin would be ignored. > > Access to common shared directories in the user's home directory is > possible. > I think that should solve the problem of supporting old plugin > installations. > OK, that's good to know. I couldn't make this work, but I think I needed to update my Ubuntu installation. Anyway, I think that I have enough information for now. Thanks for all the responses, and best regards! -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.vogt at canonical.com Fri Aug 19 18:09:22 2016 From: michael.vogt at canonical.com (Michael Vogt) Date: Fri, 19 Aug 2016 20:09:22 +0200 Subject: New experimental images Message-ID: <20160819180922.GD3871@bod> Hi, we have a set of new experimental images available at: http://people.canonical.com/~mvo/all-snaps/16/ These images fix some bugs around the new upgrade code in grub/uboot. So if you experienced strange issues here those should be fixed now (and our automatic tests got fixed to check for those). Note that the "amd64" image got renamed to "pc" to make it more consistent with the gadget snap name (but happy to revert that if its considerd too generic). As always, please give the images a go and let us know about any issues. We hope to move the images to a more offical place soon but we want to have some more testing first to ensure the upgrade issues are all resolved. Cheers, Michael (on behalf of the snapd team) From ppa at jzimm.net Fri Aug 19 23:06:38 2016 From: ppa at jzimm.net (Jacob Zimmermann) Date: Sat, 20 Aug 2016 09:06:38 +1000 Subject: New experimental images In-Reply-To: <20160819180922.GD3871@bod> References: <20160819180922.GD3871@bod> Message-ID: <10cb800c-5016-a220-e2c2-3ec13d861809@jzimm.net> Hi Michael Would it be possible to include btrfs in the image's initramfs? Cheers Jacob On 20/08/16 04:09, Michael Vogt wrote: > Hi, > > we have a set of new experimental images available at: > > http://people.canonical.com/~mvo/all-snaps/16/ > > These images fix some bugs around the new upgrade code in grub/uboot. So > if you experienced strange issues here those should be fixed now (and > our automatic tests got fixed to check for those). > > Note that the "amd64" image got renamed to "pc" to make it more > consistent with the gadget snap name (but happy to revert that if its > considerd too generic). > > As always, please give the images a go and let us know about any > issues. We hope to move the images to a more offical place soon but we > want to have some more testing first to ensure the upgrade issues are > all resolved. > > Cheers, > Michael (on behalf of the snapd team) > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 538 bytes Desc: OpenPGP digital signature URL: From gustavo.niemeyer at canonical.com Sat Aug 20 11:12:46 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Sat, 20 Aug 2016 08:12:46 -0300 Subject: HEADS UP: New spread version coming In-Reply-To: References: Message-ID: Hello all, This is now live in both in travis and as a new snap package. Tests in master are passing. There were a couple of last minute changes: - The reboot functionality now works via a function rather than a comment: https://github.com/snapcore/spread#rebooting - There's a new "adhoc" backend, which allows scripting the allocation and discarding of systems: https://github.com/snapcore/spread#adhoc This is enables us to run tests against physical boards and other custom situations. Please let me know if you see any issues, and have a good weekend. On Wed, Aug 17, 2016 at 11:17 PM, Gustavo Niemeyer < gustavo.niemeyer at canonical.com> wrote: > Hello all, > > The following changes have just landed in the spread repository, some of > them incompatible with the previous yaml files. > > Given the incompatibility, the spread snap or the binary version used by > the snapd tests weren't updated, but this should happen at some point > tomorrow. > > The main changes are: > > - Reboot at any point by simply inlining the # REBOOT comment > - New QEMU backend, thanks to Michael Vogt > - Environment variables are now properly ordered > - The syntax $[...] in env vars has been dropped > - The syntax $(...) in env vars will now execute remotely as expected > - The syntax $(HOST: ...) was introduced to execute the command locally > - Both of these will now correctly strip of EOLs, thanks to John Lenton > - Bash now executed with -u, to catch undefined vars, also thanks to John > - Images with fixed usernames and passwords are now supported > - $HOME won't be hacked when debugging tasks (-debug and -shell) > > The documentation was updated to cover all the changes: > > https://github.com/snapcore/spread > > Please let me know if you find any issues. > > > gustavo @ http://niemeyer.net > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Sat Aug 20 11:37:54 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 20 Aug 2016 07:37:54 -0400 Subject: Announcing snapd-glib In-Reply-To: References: Message-ID: <79dfc21b-c402-3ad1-ee94-c9388621f7e4@ubuntu.com> On 18/08/16 22:33, Robert Ancell wrote: > At the Heidelberg sprint we decided to create a library that would > allow GLib based projects to more easily access snapd and reduce > duplication across these projects. Thanks Robert, I think this will make it much easier for people to build their own store experience and device management! Mark From ogra at ubuntu.com Mon Aug 22 17:05:01 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 22 Aug 2016 19:05:01 +0200 Subject: New experimental images In-Reply-To: <20160819180922.GD3871@bod> References: <20160819180922.GD3871@bod> Message-ID: <1471885501.6937.30.camel@ubuntu.com> hi, Am Freitag, den 19.08.2016, 20:09 +0200 schrieb Michael Vogt: > Hi, > > we have a set of new experimental images available at: > >     http://people.canonical.com/~mvo/all-snaps/16/ > > These images fix some bugs around the new upgrade code in grub/uboot. > So > if you experienced strange issues here those should be fixed now (and > our automatic tests got fixed to check for those). > aaand ... for the rpi3 users around here: http://people.canonical.com/~ogra/snappy/all-snaps/ this is the first pi3 image that has all the needed bits included to make the wlan device work (beyond the fixes mvo pointed out). enjoy ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Aug 22 17:14:00 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 22 Aug 2016 19:14:00 +0200 Subject: New experimental images In-Reply-To: <20160819180922.GD3871@bod> References: <20160819180922.GD3871@bod> Message-ID: <1471886040.6937.36.camel@ubuntu.com> hi, Am Freitag, den 19.08.2016, 20:09 +0200 schrieb Michael Vogt: > Hi, > > we have a set of new experimental images available ... one thing to also point out here is that these images are all built against the edge channel ...  since our automatic daily builds for ubuntu-core land there every day, you will get automatic daily upgrades, note though, that unlike in 15.04 these images will *not* reboot themselves after the upgrade, you have to do this manually ...  the auto-build of ubuntu-core kicks off around 5:30 UTC and hits the devices around 5:50/6:00 UTC. you can check with the "snap changes" command if an update arrived and if you should/want to reboot to the new rootfs. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From leo.arias at canonical.com Tue Aug 23 00:44:16 2016 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 22 Aug 2016 18:44:16 -0600 Subject: Build snaps in container In-Reply-To: References: Message-ID: <57BB9C60.7040308@canonical.com> Hello! We have a couple of dockerfiles in the playpen too: https://github.com/ubuntu/snappy-playpen/tree/master/testing We use them because we can't easily get xenial and lxd in travis, so we can't use cleanbuild. I wonder if we should get an official one. One thing I notice from your dockerfile is that you are installing some packages in addition to snapcraft. I think that could cause problems because any packages required to build the snap should be specified as build-packages in the snapcraft.yaml. pura vida. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From leo.arias at canonical.com Tue Aug 23 01:49:52 2016 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 22 Aug 2016 19:49:52 -0600 Subject: ANN: snapcraft 2.14 has been released In-Reply-To: References: <6e874878-83aa-7616-7b1c-0313ba7f2c66@ubuntu.com> <9f0777ef-34d4-b640-33f4-7bb4028239a8@canonical.com> Message-ID: <57BBABC0.7030106@canonical.com> On 2016-08-17 20:20, Sergio Schvezov wrote: > Rust is contributed by the community, I have no example but know elopio > ran a project with it. Yes, I was playing with cargo. It was simple and I got a snap that worked in dev mode, but then I started wondering about using this snap to build the future rust snaps, I fell into the rabbit hole and didn't finish testing it :) As soon as I have some free time again I'll contribute it to the playpen. Your question about examples is interesting. We have been talking about modifying our demos to be more useful, instead of the random sample that we currently have in there. One option is to make a hello world for every plugin, but then that's not a real world example so it also has limited use; and that's more or less what we have in our integration suite [1]. On the other hand, if we take a real world project as an example, it could get too complex to be useful for users getting started. And there's the playpen which also serves as a showcase. So, opinions and branches are welcome. [1] https://github.com/snapcore/snapcraft/tree/master/integration_tests/snaps/simple-rust -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From xavier.pegenaute at nexiona.com Tue Aug 23 10:26:18 2016 From: xavier.pegenaute at nexiona.com (Xavier Pegenaute M2M) Date: Tue, 23 Aug 2016 12:26:18 +0200 Subject: Snappy + root encryption Message-ID: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> Hi all, I am interested on building a snappy system with encryption to rootfs, I've been looking around but I didn't find any document or guide about it. Does snappy support it? If this is the case some one could point me to some info about it? Regards From loic.minier at ubuntu.com Tue Aug 23 10:33:30 2016 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 23 Aug 2016 12:33:30 +0200 Subject: Build snaps in container In-Reply-To: References: Message-ID: Hi, On Tue, Aug 16, 2016 at 3:39 PM, Matt Bruzek wrote: > It is also available on docker hub: https://hub.docker.com/r/jujus > olutions/snapbox/ > Thanks for sharing! Didier and Sergio had already published Docker images with snapcraft: https://hub.docker.com/r/didrocks/snapcraft/ https://hub.docker.com/r/sergiusens/snapcraft/ I guess we should consolidate these and have some kind of official Ubuntu namespace and images. Cheers, - Loïc Minier -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Tue Aug 23 11:21:53 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 23 Aug 2016 07:21:53 -0400 Subject: Snappy + root encryption In-Reply-To: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> Message-ID: Hi Xavier With snaps on classic (deb-based) Linux there have been some bugs related to encrypted home directories, not sure if those are fixed yet but they are definitely in progress. On Ubuntu Core (where the whole system is a collection of snaps, there are no debs by default) it should be possible to have an encrypted disk. The main question would be what your expectations of the boot process would be. Most people who want Ubuntu Core are doing so for distributed devices where there isn't going to be a human around if the machine reboots. Mark On 23/08/16 06:26, Xavier Pegenaute M2M wrote: > Hi all, > > I am interested on building a snappy system with encryption to rootfs, > I've been looking around but I didn't find any document or guide about > it. Does snappy support it? If this is the case some one could point > me to some info about it? > > Regards > From zygmunt.krynicki at canonical.com Tue Aug 23 11:34:07 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Tue, 23 Aug 2016 13:34:07 +0200 Subject: Snappy + root encryption In-Reply-To: References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> Message-ID: > Wiadomość napisana przez Mark Shuttleworth w dniu 23.08.2016, o godz. 13:21: > > Hi Xavier > > With snaps on classic (deb-based) Linux there have been some bugs > related to encrypted home directories, not sure if those are fixed yet > but they are definitely in progress. All known bugs related to encryption are fixed upstream and are a part of the 1.0.40 release. I am working on the SRU process to get those fixes released across the distribution landscape. > On Ubuntu Core (where the whole system is a collection of snaps, there > are no debs by default) it should be possible to have an encrypted disk. > The main question would be what your expectations of the boot process > would be. Most people who want Ubuntu Core are doing so for distributed > devices where there isn't going to be a human around if the machine reboots. > > Mark > > On 23/08/16 06:26, Xavier Pegenaute M2M wrote: >> Hi all, >> >> I am interested on building a snappy system with encryption to rootfs, >> I've been looking around but I didn't find any document or guide about >> it. Does snappy support it? If this is the case some one could point >> me to some info about it? >> >> Regards >> > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From xavier.pegenaute at nexiona.com Tue Aug 23 11:47:42 2016 From: xavier.pegenaute at nexiona.com (Xavier Pegenaute M2M) Date: Tue, 23 Aug 2016 13:47:42 +0200 Subject: Snappy + root encryption In-Reply-To: References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> Message-ID: <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> Hi Mark, actually, our goal is to provide hardware to be delivered on costumer premises but for this we need an extra layer of security. This is the reason we are considering the encryption solution. If it is possible our first and preferred solution is to encrypt as much as possible starting from rootfs. I guess I should port the cryptsetup package and dependencies to snap, but since I saw in your mailing list some references I wanted to be sure this is not already done or being in process. As a second step, AFAIK, I should modify the boot process to include support for partition decryption which again I am not sure this is already supported on snappy (crossing fingers xD ). Regards On 23/08/16 13:21, Mark Shuttleworth wrote: > Hi Xavier > > With snaps on classic (deb-based) Linux there have been some bugs > related to encrypted home directories, not sure if those are fixed yet > but they are definitely in progress. > > On Ubuntu Core (where the whole system is a collection of snaps, there > are no debs by default) it should be possible to have an encrypted disk. > The main question would be what your expectations of the boot process > would be. Most people who want Ubuntu Core are doing so for distributed > devices where there isn't going to be a human around if the machine reboots. > > Mark > > On 23/08/16 06:26, Xavier Pegenaute M2M wrote: >> Hi all, >> >> I am interested on building a snappy system with encryption to rootfs, >> I've been looking around but I didn't find any document or guide about >> it. Does snappy support it? If this is the case some one could point >> me to some info about it? >> >> Regards >> From sergio.schvezov at canonical.com Tue Aug 23 12:48:46 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 23 Aug 2016 09:48:46 -0300 Subject: Build snaps in container In-Reply-To: References: Message-ID: <43331857-caf2-1558-c14c-0defec52d6b5@ubuntu.com> El 23/08/16 a las 07:33, Loïc Minier escribió: > Hi, > > On Tue, Aug 16, 2016 at 3:39 PM, Matt Bruzek > > wrote: > > It is also available on docker hub: > https://hub.docker.com/r/jujusolutions/snapbox/ > > > > Thanks for sharing! Didier and Sergio had already published Docker > images with snapcraft: > https://hub.docker.com/r/didrocks/snapcraft/ > https://hub.docker.com/r/sergiusens/snapcraft/ > I guess we should consolidate these and have some kind of official > Ubuntu namespace and images. I discussed with Evan and we are going to move the Dockerfile to an official location like snapcore/snapcraft and have it updated regularly. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alejandro.vera at gmail.com Tue Aug 23 13:37:12 2016 From: alejandro.vera at gmail.com (Alejandro Vera) Date: Tue, 23 Aug 2016 10:37:12 -0300 Subject: A snap that uses other apps Message-ID: Hi everyone... I am developing an app for internal use in my company. In my app I can config an external commando line app to format code and I can config my browser to open files. But when I package it as a snap my app can not see those apps What should I do? I think this is very common. I hope I do not have to package the browser and the cli-app in my snap Thanks! -- Alejandro Vera http://www.recicleta.cl -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Tue Aug 23 15:18:45 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Tue, 23 Aug 2016 17:18:45 +0200 Subject: A snap that uses other apps In-Reply-To: References: Message-ID: <02012772-3A84-495D-8F38-CEBD41B0AE0A@canonical.com> > Wiadomość napisana przez Alejandro Vera w dniu 23.08.2016, o godz. 15:37: > > Hi everyone... > > I am developing an app for internal use in my company. > > In my app I can config an external commando line app to format code and I can config my browser to open files. But when I package it as a snap my app can not see those apps > > What should I do? I think this is very common. I hope I do not have to package the browser and the cli-app in my snap > It depends on how those apps look like. In general the whole host filesystem is exposed as /var/lib/snapd/hostfs. In devmode you can run anything installed there (that is the root filesystem of your computer) assuming you set PATH, LD_LIBRARY_PATH and anything else like that to point there. Best regards. ZK > Thanks! > > -- > Alejandro Vera > http://www.recicleta.cl > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Wed Aug 24 05:34:54 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 24 Aug 2016 13:34:54 +0800 Subject: Does anyone know how to build snap for ARM architecture? Message-ID: Hi, I just now successfully used launchpad.net to build snaps for ARM architecture. However, the precondition is that it works on my desktop well. I am thinking whether there is an alternative way to compile snaps for armhf in view of the fact that raspberry is now supporting the architecture. I used to come with a docker solution to it for 15.04. Now docker snap is not there any more. Can anyone tell me how to build for armhf snaps? Thanks & best regards, XiaoGuo -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Wed Aug 24 05:44:40 2016 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 24 Aug 2016 07:44:40 +0200 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: On 24.08.2016 07:34, XiaoGuo Liu wrote: > Hi, > > I just now successfully used launchpad.net to > build snaps for ARM architecture. However, the precondition is that it > works on my desktop well. I am thinking whether there is an alternative > way to compile snaps for armhf in view of the fact that raspberry is now > supporting the architecture. I used to come with a docker solution to it > for 15.04. Now docker snap is not there any more. Can anyone tell me how > to build for armhf snaps? I've installed Ubuntu Server for that purpose on one of my pi2 machines and doing all builds there. The classic snap from the store (not sure how far that is, but installing with snap install --devmode --edge classic should work) would be another possible way to build on an arm device as it gives you a full apt-get'able system on an all-snap one. regards, Simon From xiaoguo.liu at canonical.com Wed Aug 24 06:12:09 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 24 Aug 2016 14:12:09 +0800 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: Hi Simon, Thanks a lot for your reply. On 15.04, I installed docker, and inside docker, I installed a Ubuntu Server so that I can compile for armhf. A lot of developers may not have the luxury to have two arm devices. I am thinking your second option could be more realistic. I do not have a Ubuntu Core device yet. So, the right command is: $ snap install --devmode --edge classic In this case, it enters to the classic ubuntu mode, rightt? By the way, how to exit the mode? Previously, I saw some instructions like: $ sudo snappy enable-classic $ snappy shell classic $ sudo snappy destroy-classic I think they were for the 15.04 Ubuntu core. Thanks & best regards, XiaoGuo On Wed, Aug 24, 2016 at 1:44 PM, Simon Fels wrote: > On 24.08.2016 07:34, XiaoGuo Liu wrote: > > Hi, > > > > I just now successfully used launchpad.net to > > build snaps for ARM architecture. However, the precondition is that it > > works on my desktop well. I am thinking whether there is an alternative > > way to compile snaps for armhf in view of the fact that raspberry is now > > supporting the architecture. I used to come with a docker solution to it > > for 15.04. Now docker snap is not there any more. Can anyone tell me how > > to build for armhf snaps? > > I've installed Ubuntu Server for that purpose on one of my pi2 machines > and doing all builds there. The classic snap from the store (not sure > how far that is, but installing with snap install --devmode --edge > classic should work) would be another possible way to build on an arm > device as it gives you a full apt-get'able system on an all-snap one. > > regards, > Simon > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From loic.minier at ubuntu.com Wed Aug 24 06:40:16 2016 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Wed, 24 Aug 2016 08:40:16 +0200 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: Hi, On Wed, Aug 24, 2016 at 7:34 AM, XiaoGuo Liu wrote: > I just now successfully used launchpad.net to build snaps for ARM > architecture. However, the precondition is that it works on my desktop > well. I am thinking whether there is an alternative way to compile snaps > for armhf in view of the fact that raspberry is now supporting the > architecture. I used to come with a docker solution to it for 15.04. Now > docker snap is not there any more. Can anyone tell me how to build for > armhf snaps? > Docker snap should be available for 15.04 in stable channel; it's only in the edge channel (and using devmode) for series 16 (install with snap install --devmode --edge docker). Please let me know if it's in any way broken or missing! Otherwise you can indeed use the classic environment, or a classic image as Simon mentioned. Cheers, - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Wed Aug 24 07:05:11 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 24 Aug 2016 15:05:11 +0800 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: Hi Loïc, Thanks! Yes, I want to build it for Ubuntu core series 16. I will have a try. Best regards, XiaoGuo On Wed, Aug 24, 2016 at 2:40 PM, Loïc Minier wrote: > Hi, > > On Wed, Aug 24, 2016 at 7:34 AM, XiaoGuo Liu > wrote: > >> I just now successfully used launchpad.net to build snaps for ARM >> architecture. However, the precondition is that it works on my desktop >> well. I am thinking whether there is an alternative way to compile snaps >> for armhf in view of the fact that raspberry is now supporting the >> architecture. I used to come with a docker solution to it for 15.04. Now >> docker snap is not there any more. Can anyone tell me how to build for >> armhf snaps? >> > > Docker snap should be available for 15.04 in stable channel; it's only in > the edge channel (and using devmode) for series 16 (install with snap > install --devmode --edge docker). Please let me know if it's in any way > broken or missing! > > Otherwise you can indeed use the classic environment, or a classic image > as Simon mentioned. > > Cheers, > - Loïc > -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Aug 24 08:37:09 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 24 Aug 2016 10:37:09 +0200 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: <1472027829.6937.63.camel@ubuntu.com> hi, Am Mittwoch, den 24.08.2016, 13:34 +0800 schrieb XiaoGuo Liu: > Hi, > > I just now successfully used launchpad.net to build snaps for ARM > architecture. However, the precondition is that it works on my > desktop well. I am thinking whether there is an alternative way to > compile snaps for armhf in view of the fact that raspberry is now > supporting the architecture. I used to come with a docker solution to > it for 15.04. Now docker snap is not there any more. Can anyone tell > me how to build for armhf snaps? grab the pi2 image from: http://people.canonical.com/~mvo/all-snaps/16/ or the pi3 image from: http://people.canonical.com/~ogra/snappy/all-snaps/ put it on the SD, boot and log in... run: ubuntu at pi3:~$ sudo snap install classic --devmode --beta classic (beta) 16.04-4 from 'canonical' installed ubuntu at pi3:~$ sudo classic.create Creating classic environment Parallel unsquashfs: Using 4 processors 8313 inodes (8981 blocks) to write ... Generating locales (this might take a while)... Generation complete. Processing triggers for libc-bin (2.23-0ubuntu3) ... ubuntu at pi3:~$ sudo classic.shell (classic)ubuntu at pi3:~$ sudo apt update [sudo] password for ubuntu:  Get:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease [247 kB] Get:2 http://ports.ubuntu.com/ubuntu-ports xenial-updates InRelease [95.7 kB] ... All packages are up to date. (classic)ubuntu at pi3:~$ sudo apt install snapcraft git-core ... etc ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jenny.murphy at episensor.com Wed Aug 24 10:58:46 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Wed, 24 Aug 2016 11:58:46 +0100 Subject: File permissions within a snap Message-ID: Hi, I have a java application built as a .snap. As part of its normal operation it will create some files (for output). However this is not successful due to permissions issue : For example , I tried to create the file in /home/ubuntu/examples/ : java.io.FileNotFoundException: /home/ubuntu/examples/example.txt (Permission denied) I got a similar result whenI tired to create it in the current dir : /apps/gateway.sideload/IcNYWMFDGBeY So is there a way around this? Thanks in advance for any suggestions. -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Wed Aug 24 11:01:45 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Wed, 24 Aug 2016 13:01:45 +0200 Subject: File permissions within a snap In-Reply-To: References: Message-ID: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> > Wiadomość napisana przez Jenny Murphy w dniu 24.08.2016, o godz. 12:58: > > Hi, > I have a java application built as a .snap. > As part of its normal operation it will create some files (for output). > However this is not successful due to permissions issue : > For example , I tried to create the file in /home/ubuntu/examples/ : > java.io.FileNotFoundException: /home/ubuntu/examples/example.txt (Permission denied) > I got a similar result whenI tired to create it in the current dir : > /apps/gateway.sideload/IcNYWMFDGBeY You can freely create files in $SNAP_USER_DATA - the per-user data directory or $SNAP_DATA - the global data directory (for daemons). If you want to write to other locations you need an interface to do it. For example you can use the home interface to get write access to most of the $HOME directory. You can do this by just defining a „home” plug on your application. Best regards ZK > > So is there a way around this? > > Thanks in advance for any suggestions. > > -- > Jenny Murphy > EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland > jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.bishop at canonical.com Wed Aug 24 12:15:43 2016 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Wed, 24 Aug 2016 19:15:43 +0700 Subject: Using snap for application with plugins In-Reply-To: References: Message-ID: On 19 August 2016 at 20:39, Thomas Voß wrote: > Now that triggers a question for me: How do end users resolve > dependencies of plugins today? > Do they just assume that the downloaded plugins bring along whatever > they need? Or do they rely > on the package manager to resolve dependencies ad hoc? > > In any case: It seems to me that shipping your application and its > core plugins as a snap is certainly possible. > For installing 3rd party plugins: Why not have an "app" or command on > your snap that takes care of copying files and folders > to the right place in the writable parts of the snap. I'm thinking > along the lines of: > > yourapp.install-plugin /path/to/file/or/folder > > That would also help your users in that they don't need to know about > a specific directory to place plugins into. > > I'm interested in using Juju plugins with the new Juju snap. With a packaged installation, users run a command 'juju foo' or '../1.29.3/juju foo' which calls a juju executable. juju then executes 'juju-foo' from $PATH, with a modified environment ($PATH gets prepended to ensure the correct version of juju and tools is found by the plugin). The juju-foo plugin does its thing, usually needing to invoke the original juju executable. Plugins are often quick hacks and not distributed. They cannot all be distributed in the juju snap. Plugins often come with their own set of dependencies, such as Python libraries or calling tools such as graphviz. They are not a compiled .so or .zip file. So juju snap needs to invoke plugins, outside of its containment, and these plugins need to call back to juju (ie. stay devmode). Or the plugins and all their dependencies need to be brought inside juju's containment. To run with your suggestion, would the juju snap need to provide a way to install other snaps inside its containment? Is that possible? Or should this be standard in snapd, being able to merge snaps into existing snaps extending its containment and modifying its behaviour (similar to juju subordinate charms)? Or is there a simpler way? I think the goal here is meet or exceed the functionality of the existing package installations. Snaps are going to be a hard sell to people who have grown used to dumping a shell script in their $PATH to enhance usability. git plugins are very similar, so it isn't just a juju problem. > Access to common shared directories in the user's home directory is > possible. > I think that should solve the problem of supporting old plugin > installations. > This approach doesn't work when plugins need to reinvoke juju or call /snap/bin/graphviz. But if, in addition to home, we had an interface that allowed calling executables in /snap/bin it could work. -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.vera at gmail.com Wed Aug 24 13:45:07 2016 From: alejandro.vera at gmail.com (Alejandro Vera) Date: Wed, 24 Aug 2016 10:45:07 -0300 Subject: A snap that uses other apps In-Reply-To: <02012772-3A84-495D-8F38-CEBD41B0AE0A@canonical.com> References: <02012772-3A84-495D-8F38-CEBD41B0AE0A@canonical.com> Message-ID: Hi... In my /var/lib/snapd/hostfs there are no files. How can Install an app there? I need js-beautify installed using python pip. If I want to distribute my snap inside my company without using devmode, which is the way to access other cli-apps? Thanks :D On Tue, Aug 23, 2016 at 12:18 PM, Zygmunt Krynicki < zygmunt.krynicki at canonical.com> wrote: > > Wiadomość napisana przez Alejandro Vera w dniu > 23.08.2016, o godz. 15:37: > > Hi everyone... > > I am developing an app for internal use in my company. > > In my app I can config an external commando line app to format code and I > can config my browser to open files. But when I package it as a snap my app > can not see those apps > > What should I do? I think this is very common. I hope I do not have to > package the browser and the cli-app in my snap > > > It depends on how those apps look like. > > In general the whole host filesystem is exposed as /var/lib/snapd/hostfs. > In devmode you can run anything installed there (that is the root > filesystem of your computer) assuming you set PATH, LD_LIBRARY_PATH and > anything else like that to point there. > > Best regards. > ZK > > > Thanks! > > -- > Alejandro Vera > http://www.recicleta.cl > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > > -- Alejandro Vera http://www.recicleta.cl -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.nitzsche at canonical.com Wed Aug 24 13:55:02 2016 From: kyle.nitzsche at canonical.com (knitzsche) Date: Wed, 24 Aug 2016 09:55:02 -0400 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: I have been able to build armhf snaps on my amd64 host using an armhf pbuilder chroot. Cheers, Kyle On 08/24/2016 01:34 AM, XiaoGuo Liu wrote: > Hi, > > I just now successfully used launchpad.net to > build snaps for ARM architecture. However, the precondition is that it > works on my desktop well. I am thinking whether there is an alternative > way to compile snaps for armhf in view of the fact that raspberry is now > supporting the architecture. I used to come with a docker solution to it > for 15.04. Now docker snap is not there any more. Can anyone tell me how > to build for armhf snaps? > > Thanks & best regards, > XiaoGuo > > -- > XiaoGuo, Liu (刘晓国） > Mobile: +86-13911181302 > > From timo.jyrinki at gmail.com Wed Aug 24 15:18:37 2016 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Wed, 24 Aug 2016 18:18:37 +0300 Subject: Snapping Qt 5.7 APPs In-Reply-To: References: Message-ID: Hi David! Thanks, seems to work nicely! I think some shortcuts like this are a good workaround as compiling the whole Qt is a huge time consumer. I'm interested in understanding the needs of Qt users (and snappy users interested in Qt), so I'm curious what brings you to using Qt 5.7? If it's the new virtual keyboard module alone, I could see about getting that available compiled against older Qt version, if it does not rely on too many Qt internal changes. That would make it unneeded to bundle a whole new Qt for just one extra module. Also, we already have a virtual keyboard based on maliit-framework / ubuntu-keyboard in active development so if you haven't yet it'd be useful to chat with the current developers of that to know what would be the plan for which uses cases, if you prefer the Qt's virtualkeyboard module. As for the Qt versions in general, the next stable phone/tablet platform will use Qt 5.6 as the system Qt as 5.6 is a long-term supported version by upstream, which will receive bug fixes and security fixes for 3 years. Qt 5.5, 5.7 or 5.8 are/were only supported for roughly 9 months or so (as soon as 5.8.0 will be out, there will likely not be further development of 5.7 series). For most applications it may make sense to use the Qt used by the systems application instead of shipping one's own Qt version if there's not a critical feature missing. An option is also to backport the most wanted features to the system Qt. -Timo 2016-08-19 13:10 GMT+03:00 David Chen : > Hi, > > I met some problems when trying to create snap for Qt5.7 apps. After some > digging and discussing with people, finally I have a temporary solution > which I thought might be worth sharing. Please see the example below that I > put together, hopefully people will find it useful and solve some of their > problems as well. > > https://github.com/davidchen0813/virtualkeyboard-demo > > Detail listed in README.md. > > Notes: > > 1. The example uses a custom plugin [1], which is modified from old qml > plugin [2]. > > 2. If you are running Nvidia graphic, you might meet this issue: > https://bugs.launchpad.net/snappy/+bug/1588192 > > 3. Without LIBGL_DRIVERS_PATH=$SNAP/usr/lib/x86_64-linux-gnu/dri, you will > hit this issue: https://bugs.launchpad.net/snappy/+bug/1584178 > > > [1] > https://github.com/snapcore/snapcraft/blob/46c46d31b21e4283c4b8fba3e432fb8458414236/docs/plugins.md > > [2] > http://bazaar.launchpad.net/~ted/snapcraft/qml/view/head:/snapcraft/plugins/qml.py > > > Thanks and Regards, > > -- > > DAVID CHEN > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From chris.j.arges at canonical.com Wed Aug 24 15:24:58 2016 From: chris.j.arges at canonical.com (Christopher Arges) Date: Wed, 24 Aug 2016 10:24:58 -0500 Subject: Intropsecting Connected Slots/Plugs From Within a Snap Message-ID: >From within a snapped program I'd like to check if all my slots/plugs are connected properly. This way I can either handle functionality different if something is not connected, or inform the user to connect before proceeding. I'm guessing the snapd-control interface contains this functionality, but then that requires that the snapd-control interface is also manually connected. In addition I'll need to write client code to connect to snapd and query it. Is there a better way to handle this? It would be great if one could introspect connected interfaces for the snap itsself without additional connections. Thanks, --chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Wed Aug 24 15:29:17 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 24 Aug 2016 12:29:17 -0300 Subject: Intropsecting Connected Slots/Plugs From Within a Snap In-Reply-To: References: Message-ID: There will be a proper way to do that soonish, via snapctl. It's a new tool and mechanism that is being developed under the hook support theme, but that will be generalized after that so that we can have richer interactions between snaps and their mothership. On Wed, Aug 24, 2016 at 12:24 PM, Christopher Arges < chris.j.arges at canonical.com> wrote: > From within a snapped program I'd like to check if all my slots/plugs are > connected properly. This way I can either handle functionality different if > something is not connected, or inform the user to connect before proceeding. > > I'm guessing the snapd-control interface contains this functionality, but > then that requires that the snapd-control interface is also manually > connected. In addition I'll need to write client code to connect to snapd > and query it. > > Is there a better way to handle this? It would be great if one could > introspect connected interfaces for the snap itsself without additional > connections. > > Thanks, > --chris > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tyhicks at canonical.com Wed Aug 24 16:30:54 2016 From: tyhicks at canonical.com (Tyler Hicks) Date: Wed, 24 Aug 2016 11:30:54 -0500 Subject: Snappy + root encryption In-Reply-To: <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> Message-ID: <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> On 08/23/2016 06:47 AM, Xavier Pegenaute M2M wrote: > Hi Mark, > > actually, our goal is to provide hardware to be delivered on costumer > premises but for this we need an extra layer of security. This is the > reason we are considering the encryption solution. > > If it is possible our first and preferred solution is to encrypt as much > as possible starting from rootfs. > > I guess I should port the cryptsetup package and dependencies to snap, > but since I saw in your mailing list some references I wanted to be sure > this is not already done or being in process. > > As a second step, AFAIK, I should modify the boot process to include > support for partition decryption which again I am not sure this is > already supported on snappy (crossing fingers xD ). Will your devices have a display and a keyboard? Will a human always be present during the boot process (after a planned or unplanned reboot) to enter the password? If the answer is 'no' to either of those questions, there's more work to do in order to provide secure storage of the encryption key in a way that makes it automatically accessible during the boot process. Let us know what your needs are and we can at least capture the use case and requirements in a feature request bug so that we can try to support you when designing the storage encryption solution in the platform itself. Thanks! Tyler > > Regards > > On 23/08/16 13:21, Mark Shuttleworth wrote: >> Hi Xavier >> >> With snaps on classic (deb-based) Linux there have been some bugs >> related to encrypted home directories, not sure if those are fixed yet >> but they are definitely in progress. >> >> On Ubuntu Core (where the whole system is a collection of snaps, there >> are no debs by default) it should be possible to have an encrypted disk. >> The main question would be what your expectations of the boot process >> would be. Most people who want Ubuntu Core are doing so for distributed >> devices where there isn't going to be a human around if the machine >> reboots. >> >> Mark >> >> On 23/08/16 06:26, Xavier Pegenaute M2M wrote: >>> Hi all, >>> >>> I am interested on building a snappy system with encryption to rootfs, >>> I've been looking around but I didn't find any document or guide about >>> it. Does snappy support it? If this is the case some one could point >>> me to some info about it? >>> >>> Regards >>> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From evan.dandrea at canonical.com Wed Aug 24 16:35:26 2016 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Wed, 24 Aug 2016 16:35:26 +0000 Subject: Publishing to the snap store from Travis Message-ID: New versions of snapcraft can push a snap right into a channel. With a small wrapper, you can teach Travis to build snaps out of your git commits and release them into edge [1, 2]: https://gist.github.com/evandandrea/c754964bfdfb176844f26f605ebbb8db Your users can then drink from the firehose with: $ snap refresh --channel=edge your-snap-name And jump back when they can no longer take the heat: $ snap refresh --channel=stable your-snap-name Let me know if you find this useful or have any follow up questions. Thanks, Evan 1: This uses a macaroon you provide (`snapcraft login`), but encrypts the cached copy such that pull requests cannot steal it. 2: In this example I used an "edge" git branch, but you can easily modify .travis.sh to send commits on master, or any branch, to the edge channel. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Thu Aug 25 02:33:53 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 25 Aug 2016 10:33:53 +0800 Subject: How to assign a hardware in my snap application? Message-ID: Hi, On Series 16, we need to use interface to make the connection between the Ubuntu core and Snap apps in order to make use of the hardware. Previously, on 15.04, I used the following command do get the hardware assignment: (RaspberryPi2)ubuntu at localhost:~$ sudo snappy hw-assign piglow.sideload /dev/i2c-1 'piglow.sideload' is now allowed to access '/dev/i2c-1' Currently, I list all of the interfaces from raspberry pi snappy image, but I do not find any interface which corresponds to my requirement. Do I need to wait for the interface? or I did it wrongly? What should be the right interface to use in my case? ubuntu at localhost:~/apps$ snap interfaces Slot Plug :bluetooth-control - :firewall-control - :fuse-support - :hardware-observe - :home - :kernel-module-control - :locale-control - :log-observe - :mount-observe - :network piglow-app,snapweb :network-bind piglow-app,snapweb,webcam-webui :network-control - :network-observe - :opengl - :ppp - :process-control - :snapd-control snapweb :system-observe - :system-trace - :timeserver-control - :timezone-control - :tpm - - webcam-webui:camera Also, I find that the "camera" interface is missing in the current image. Thanks & best regards, XiaoGuo -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From vicamo.yang at canonical.com Thu Aug 25 03:16:41 2016 From: vicamo.yang at canonical.com (Vicamo Yang) Date: Thu, 25 Aug 2016 11:16:41 +0800 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: Hi, I got some docker images in https://hub.docker.com/r/vicamo/ubuntu . Basically all Ubuntu suite-arch combinations are available, so you may want to try snapcraft on them. Dockerfile source code are available in https://github.com/vicamo/docker-brew-ubuntu-core . Feel free to fork your own and customize the images for snapcraft. :) On Thu, Aug 25, 2016 at 11:02 AM, YC Cheng wrote: > > ---------- Forwarded message ---------- > From: knitzsche > Date: 2016-08-24 21:55 GMT+08:00 > Subject: Re: Does anyone know how to build snap for ARM architecture? > To: XiaoGuo Liu , snapcraft at lists.snapcraft.io > > > I have been able to build armhf snaps on my amd64 host using an armhf > pbuilder chroot. > > Cheers, > Kyle > > On 08/24/2016 01:34 AM, XiaoGuo Liu wrote: >> >> Hi, >> >> I just now successfully used launchpad.net to >> build snaps for ARM architecture. However, the precondition is that it >> works on my desktop well. I am thinking whether there is an alternative >> way to compile snaps for armhf in view of the fact that raspberry is now >> supporting the architecture. I used to come with a docker solution to it >> for 15.04. Now docker snap is not there any more. Can anyone tell me how >> to build for armhf snaps? >> >> Thanks & best regards, >> XiaoGuo >> >> -- >> XiaoGuo, Liu (刘晓国） >> Mobile: +86-13911181302 >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- Vicamo Yang From xiaoguo.liu at canonical.com Thu Aug 25 03:49:13 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 25 Aug 2016 11:49:13 +0800 Subject: Does anyone know how to build snap for ARM architecture? In-Reply-To: References: Message-ID: Hi Vicamo, That is very good. I will try it later on. By the way, I have successfully compiled armhf snap by using "classic" application. It is very convenient :) Thanks & best regards, XiaoGuo On Thu, Aug 25, 2016 at 11:16 AM, Vicamo Yang wrote: > Hi, > > I got some docker images in https://hub.docker.com/r/vicamo/ubuntu . > Basically all Ubuntu suite-arch combinations are available, so you may > want to try snapcraft on them. Dockerfile source code are available in > https://github.com/vicamo/docker-brew-ubuntu-core . Feel free to fork > your own and customize the images for snapcraft. :) > > On Thu, Aug 25, 2016 at 11:02 AM, YC Cheng wrote: > > > > ---------- Forwarded message ---------- > > From: knitzsche > > Date: 2016-08-24 21:55 GMT+08:00 > > Subject: Re: Does anyone know how to build snap for ARM architecture? > > To: XiaoGuo Liu , > snapcraft at lists.snapcraft.io > > > > > > I have been able to build armhf snaps on my amd64 host using an armhf > > pbuilder chroot. > > > > Cheers, > > Kyle > > > > On 08/24/2016 01:34 AM, XiaoGuo Liu wrote: > >> > >> Hi, > >> > >> I just now successfully used launchpad.net to > >> build snaps for ARM architecture. However, the precondition is that it > >> works on my desktop well. I am thinking whether there is an alternative > >> way to compile snaps for armhf in view of the fact that raspberry is now > >> supporting the architecture. I used to come with a docker solution to it > >> for 15.04. Now docker snap is not there any more. Can anyone tell me how > >> to build for armhf snaps? > >> > >> Thanks & best regards, > >> XiaoGuo > >> > >> -- > >> XiaoGuo, Liu (刘晓国） > >> Mobile: +86-13911181302 > >> > >> > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > Vicamo Yang > -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.vogt at canonical.com Thu Aug 25 08:04:22 2016 From: michael.vogt at canonical.com (Michael Vogt) Date: Thu, 25 Aug 2016 10:04:22 +0200 Subject: New snapd 2.12 release in 16.04 & new core snap Message-ID: <20160825080422.GE3871@bod> Hello, the snappy team is happy to announce that the snapd 2.12 release is released into Ubuntu 16.04 (xenial-updates) and Fedora 24 (COPR). Other distribution will follow soon. We also did a new release of the "core" snap that contains this version of snapd. Snapd will automatically refresh you to the latest core snap. Some highlights: - new interfaces: + gpio + browser-support + bluetooth-control + system-trace + process-control - image related improvements/fixes - many bugs fixed - many spread integration tests added I hope you enjoy the new release! If there are any questions or if you notice any issues, please let us know. Cheers, Michael (on behalf of the snapd team) From robert.ancell at canonical.com Thu Aug 25 10:52:11 2016 From: robert.ancell at canonical.com (Robert Ancell) Date: Thu, 25 Aug 2016 10:52:11 +0000 Subject: Announcing snapd-glib In-Reply-To: References: Message-ID: I blogged an introduction to snapd-glib: http://bobthegnome.blogspot.co.nz/2016/08/introducing-snapd-glib.html On Fri, Aug 19, 2016 at 2:33 PM Robert Ancell wrote: > Hi all, > > At the Heidelberg sprint we decided to create a library that would allow > GLib based projects to more easily access snapd and reduce duplication > across these projects. > > I've got the first cut of this done, meet snapd-glib! > > - On Launchpad [1] > - Implements all [2] of the snapd REST API [3]. > - Provides both synchronous and asynchronous methods > - Supports GObject introspection (i.e. Python etc support) > - Supports Vala. > - Will support Qt/QML in the future [4]. > - Uploaded to Ubuntu Yakkety, will be there once it is accepted into the > NEW queue. Use the libsnapd-glib-dev or gir1.2-snapd-0 packages. > - Currently using so version number 0 - ABI is not guaranteed to be stable > until we go to 1. > - Will SRU to Ubuntu 14.04 once the API/ABI is stable. > > Here's a taste of the API: > > #!/usr/bin/python > > import gi > > gi.require_version ('Snapd', '0') > from gi.repository import Snapd > > c = Snapd.Client () > c.connect_sync () > snaps = c.list_sync () > for s in snaps: > print s.get_name () + ' ' + s.get_version () > > Happy Hacking! (And patches welcome). > > --Robert > > [1] http://launchpad.net/snapd-glib > [2] OK, just the main stuff and what I was able to get to work. But the > goal is to access everything there. > [3] https://github.com/snapcore/snapd/blob/master/docs/rest.md > [4] https://bugs.launchpad.net/bugs/1614797 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenny.murphy at episensor.com Thu Aug 25 11:03:07 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 25 Aug 2016 12:03:07 +0100 Subject: File permissions within a snap In-Reply-To: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> Message-ID: Hi, Do I need to define the location of SNAP_USER_DATA. Currently I added the following line to a wrapper script that already runs in my app : echo "User Data = " $SNAP_USER_DATA The result is User Data = Thanks a lot for you help. I guess this stuff is very basic but I am having to get up to speed quickly on snappy. Jenny On 24 August 2016 at 12:01, Zygmunt Krynicki wrote: > > Wiadomość napisana przez Jenny Murphy w dniu > 24.08.2016, o godz. 12:58: > > Hi, > I have a java application built as a .snap. > As part of its normal operation it will create some files (for output). > However this is not successful due to permissions issue : > For example , I tried to create the file in /home/ubuntu/examples/ : > java.io.FileNotFoundException: /home/ubuntu/examples/example.txt > (Permission denied) > I got a similar result whenI tired to create it in the current dir : > /apps/gateway.sideload/IcNYWMFDGBeY > > > You can freely create files in $SNAP_USER_DATA - the per-user data > directory or $SNAP_DATA - the global data directory (for daemons). > > If you want to write to other locations you need an interface to do it. > For example you can use the home interface to get write access to most of > the $HOME directory. > > You can do this by just defining a „home” plug on your application. > > Best regards > ZK > > > So is there a way around this? > > Thanks in advance for any suggestions. > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 w | http://www.episensor.com > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Thu Aug 25 11:13:41 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 25 Aug 2016 13:13:41 +0200 Subject: File permissions within a snap In-Reply-To: References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> Message-ID: <1472123621.19477.32.camel@ubuntu.com> hi, On Do, 2016-08-25 at 12:03 +0100, Jenny Murphy wrote: > Hi, >  Do I need to define the location of SNAP_USER_DATA. Currently I > added the following line to a wrapper script that already runs in my > app : > > echo "User Data = " $SNAP_USER_DATA > > > The result is >  User Data = you probably want the variable inside the quotes ;)  you can install the hello-world snap to check the default environment a snap gets ... ubuntu at pi3:~$ hello-world.env |grep SNAP_USER_DATA SNAP_USER_DATA=/home/ubuntu/snap/hello-world/27 there is also a hellp-world.sh in that package that spawns a shell inside a typical snap sandbox so you can inspect the environment more and try out what is writable etc. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jenny.murphy at episensor.com Thu Aug 25 11:31:34 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 25 Aug 2016 12:31:34 +0100 Subject: File permissions within a snap In-Reply-To: <1472123621.19477.32.camel@ubuntu.com> References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> <1472123621.19477.32.camel@ubuntu.com> Message-ID: Hi, Unfortunately, either inside or outside quotes it is still blank. Do you have a link to that hello world example you mentioned. The previous reply (from yesterday) mentioned the use of interfaces, maybe this would be cleaner than messing around with scripts and environment variables? I am using snapcraft 1.1.0, are interfaces available to use in that version? Jenny On 25 August 2016 at 12:13, Oliver Grawert wrote: > hi, > On Do, 2016-08-25 at 12:03 +0100, Jenny Murphy wrote: > > Hi, > > Do I need to define the location of SNAP_USER_DATA. Currently I > > added the following line to a wrapper script that already runs in my > > app : > > > > echo "User Data = " $SNAP_USER_DATA > > > > > > The result is > > User Data = > > you probably want the variable inside the quotes ;) > > you can install the hello-world snap to check the default environment a > snap gets ... > > ubuntu at pi3:~$ hello-world.env |grep SNAP_USER_DATA > SNAP_USER_DATA=/home/ubuntu/snap/hello-world/27 > > there is also a hellp-world.sh in that package that spawns a shell > inside a typical snap sandbox so you can inspect the environment more > and try out what is writable etc. > > ciao > oli > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From josh at pdk.io Thu Aug 25 12:00:13 2016 From: josh at pdk.io (Joshua Perry) Date: Thu, 25 Aug 2016 06:00:13 -0600 Subject: Snappy + root encryption In-Reply-To: <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> Message-ID: > On Aug 24, 2016, at 10:30 AM, Tyler Hicks wrote: > > On 08/23/2016 06:47 AM, Xavier Pegenaute M2M wrote: >> Hi Mark, >> >> actually, our goal is to provide hardware to be delivered on costumer >> premises but for this we need an extra layer of security. This is the >> reason we are considering the encryption solution. >> >> If it is possible our first and preferred solution is to encrypt as much >> as possible starting from rootfs. >> >> I guess I should port the cryptsetup package and dependencies to snap, >> but since I saw in your mailing list some references I wanted to be sure >> this is not already done or being in process. >> >> As a second step, AFAIK, I should modify the boot process to include >> support for partition decryption which again I am not sure this is >> already supported on snappy (crossing fingers xD ). > > Will your devices have a display and a keyboard? Will a human always be > present during the boot process (after a planned or unplanned reboot) to > enter the password? > > If the answer is 'no' to either of those questions, there's more work to > do in order to provide secure storage of the encryption key in a way > that makes it automatically accessible during the boot process. > > Let us know what your needs are and we can at least capture the use case > and requirements in a feature request bug so that we can try to support > you when designing the storage encryption solution in the platform > itself. Thanks! > > Tyler > >> >> Regards >> >> On 23/08/16 13:21, Mark Shuttleworth wrote: >>> Hi Xavier >>> >>> With snaps on classic (deb-based) Linux there have been some bugs >>> related to encrypted home directories, not sure if those are fixed yet >>> but they are definitely in progress. >>> >>> On Ubuntu Core (where the whole system is a collection of snaps, there >>> are no debs by default) it should be possible to have an encrypted disk. >>> The main question would be what your expectations of the boot process >>> would be. Most people who want Ubuntu Core are doing so for distributed >>> devices where there isn't going to be a human around if the machine >>> reboots. >>> >>> Mark >>> >>> On 23/08/16 06:26, Xavier Pegenaute M2M wrote: >>>> Hi all, >>>> >>>> I am interested on building a snappy system with encryption to rootfs, >>>> I've been looking around but I didn't find any document or guide about >>>> it. Does snappy support it? If this is the case some one could point >>>> me to some info about it? >>>> >>>> Regards I’ll chime in here since we share a similar use-case. We are using an ATECC508A(1) for hardened cryptographic key storage and ECDH ephemeral key setup. Our trust chain is pretty typical--as far as secure-boot processes are concerned--rooted in the boot ROM which verifies the bootloader, u-boot verifies the kernel and other boot assets, and then the kernel/init verifies the rootfs. During device personalization this Secure Element internally generates a keypair which we sign with our distribution signing certificate. The data volume is then encrypted with a random symmetrical key which is in turn stored--encrypted with the SE public key--in the boot volume. Once the kernel and initrd are verified during the boot process, the init script communicates with the SE (using an encrypted I2C channel set up by the boot ROM to verify the u-boot signature) and asks it to verify the rootfs signatures (a and b) and decrypt the symmetrical key for mounting the data volume. We didn’t see the necessity in rootfs encryption since we don’t store sensitive data there. So while we do sign and verify our rootfs loads to ensure system integrity, we only encrypt the data volume. 1. https://github.com/AtmelCSO/cryptoauth-openssl-engine -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Thu Aug 25 13:12:28 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 25 Aug 2016 10:12:28 -0300 Subject: File permissions within a snap In-Reply-To: References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> <1472123621.19477.32.camel@ubuntu.com> Message-ID: <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> El jueves, 25 de agosto de 2016 08h'31:34 ART, Jenny Murphy escribió: > Hi, > Unfortunately, either inside or outside quotes it is still blank. > > Do you have a link to that hello world example you mentioned. > > The previous reply (from yesterday) mentioned the use of interfaces, maybe > this would be cleaner than messing around with scripts and environment > variables? > I am using snapcraft 1.1.0, are interfaces available to use in > that version? It should be SNAP_APP_PATH and SNAP_APP_DATA_PATH This may help https://qrl.dell.com/files/en-us/Html/Z5000/US Application Developer Manual.html Cheers -- Enviado con Dekko desde mi dispositivo Ubuntu From joe.talbott at canonical.com Thu Aug 25 13:23:32 2016 From: joe.talbott at canonical.com (Joe Talbott) Date: Thu, 25 Aug 2016 09:23:32 -0400 Subject: File permissions within a snap In-Reply-To: <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> <1472123621.19477.32.camel@ubuntu.com> <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> Message-ID: Fixed url is: https://qrl.dell.com/files/en-us/Html/Z5000/US%20Application%20Developer%20Manual.html Joe On Thu, Aug 25, 2016 at 9:12 AM, Sergio Schvezov wrote: > El jueves, 25 de agosto de 2016 08h'31:34 ART, Jenny Murphy > escribió: >> >> Hi, >> Unfortunately, either inside or outside quotes it is still blank. >> >> Do you have a link to that hello world example you mentioned. >> >> The previous reply (from yesterday) mentioned the use of interfaces, maybe >> this would be cleaner than messing around with scripts and environment >> variables? >> I am using snapcraft 1.1.0, are interfaces available to use in that >> version? > > > It should be SNAP_APP_PATH and SNAP_APP_DATA_PATH > > This may help https://qrl.dell.com/files/en-us/Html/Z5000/US Application > Developer Manual.html > > Cheers > > > -- > Enviado con Dekko desde mi dispositivo Ubuntu > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft From jenny.murphy at episensor.com Thu Aug 25 13:56:45 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 25 Aug 2016 14:56:45 +0100 Subject: File permissions within a snap In-Reply-To: <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> <1472123621.19477.32.camel@ubuntu.com> <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> Message-ID: Hi, Yes thank you that is what I was looking for. On 25 August 2016 at 14:12, Sergio Schvezov wrote: > El jueves, 25 de agosto de 2016 08h'31:34 ART, Jenny Murphy < > jenny.murphy at episensor.com> escribió: > >> Hi, >> Unfortunately, either inside or outside quotes it is still blank. >> >> Do you have a link to that hello world example you mentioned. >> >> The previous reply (from yesterday) mentioned the use of interfaces, maybe >> this would be cleaner than messing around with scripts and environment >> variables? >> I am using snapcraft 1.1.0, are interfaces available to use in that >> version? >> > > It should be SNAP_APP_PATH and SNAP_APP_DATA_PATH > > This may help https://qrl.dell.com/files/en-us/Html/Z5000/US Application > Developer Manual.html > > Cheers > > > -- > Enviado con Dekko desde mi dispositivo Ubuntu > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Thu Aug 25 14:36:36 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Thu, 25 Aug 2016 16:36:36 +0200 Subject: File permissions within a snap In-Reply-To: References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> <1472123621.19477.32.camel@ubuntu.com> <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> Message-ID: <750C623E-9CD4-47A3-88ED-CD9E27E9B7A5@canonical.com> > Wiadomość napisana przez Jenny Murphy w dniu 25.08.2016, o godz. 15:56: > > Hi, > Yes thank you that is what I was looking for. > > > On 25 August 2016 at 14:12, Sergio Schvezov > wrote: > El jueves, 25 de agosto de 2016 08h'31:34 ART, Jenny Murphy > escribió: > Hi, > Unfortunately, either inside or outside quotes it is still blank. > > Do you have a link to that hello world example you mentioned. > > The previous reply (from yesterday) mentioned the use of interfaces, maybe > this would be cleaner than messing around with scripts and environment > variables? > I am using snapcraft 1.1.0, are interfaces available to use in that version? > > It should be SNAP_APP_PATH and SNAP_APP_DATA_PATH > I’m sorry, my advice was designed for snapd in 16.04 and beyond. I was not aware you are looking at 15.04 support. Best regards ZK -------------- next part -------------- An HTML attachment was scrubbed... URL: From xavier.pegenaute at nexiona.com Thu Aug 25 16:10:03 2016 From: xavier.pegenaute at nexiona.com (Xavier Pegenaute M2M) Date: Thu, 25 Aug 2016 18:10:03 +0200 Subject: Snappy + root encryption In-Reply-To: <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> Message-ID: <86e9c256-789c-6ecf-df6b-12fe0da01226@nexiona.com> Hi Tyler, All, my use case is something like this: we develop some software that can be installed in some hardware provided by the client. One of our clients requires a snappy distribution. To protect our data we need to encrypt all FSs in the snappy. Even if at the moment we have some weak points such as the place were we store the keys. It is not expected to have a human around every time the snappy boots but time to time it may be possible. Our goal is to protect the content in case some one takes the hardware and mount the partitions as an external drive. To do so I want to encrypt the FSs with LUKS and provide somehow the key at boot time and decrypt the FSs: system-a/b, writable and swap. During this process I am facing some problems which I need to solve asap: - The configured grub on the FS, apparently does not belong to the real system. When I run update-grub from a fresh installation does not appear the same menu options than when booted before. - The "break=premount" parameter does not work - The kernel and initrd image are located in /boot but the "boot" partition point to /boot/efi which I guess it will be a problem when de rootfs is encrypted. As a solution, I guess it is better to move the kernel + initrd to /boot/efi. I will need to only update grub and update-initramfs. Am I missing something? Best Regards, Xavi On 24/08/16 18:30, Tyler Hicks wrote: > On 08/23/2016 06:47 AM, Xavier Pegenaute M2M wrote: >> Hi Mark, >> >> actually, our goal is to provide hardware to be delivered on costumer >> premises but for this we need an extra layer of security. This is the >> reason we are considering the encryption solution. >> >> If it is possible our first and preferred solution is to encrypt as much >> as possible starting from rootfs. >> >> I guess I should port the cryptsetup package and dependencies to snap, >> but since I saw in your mailing list some references I wanted to be sure >> this is not already done or being in process. >> >> As a second step, AFAIK, I should modify the boot process to include >> support for partition decryption which again I am not sure this is >> already supported on snappy (crossing fingers xD ). > Will your devices have a display and a keyboard? Will a human always be > present during the boot process (after a planned or unplanned reboot) to > enter the password? > > If the answer is 'no' to either of those questions, there's more work to > do in order to provide secure storage of the encryption key in a way > that makes it automatically accessible during the boot process. > > Let us know what your needs are and we can at least capture the use case > and requirements in a feature request bug so that we can try to support > you when designing the storage encryption solution in the platform > itself. Thanks! > > Tyler From victor.palau at canonical.com Thu Aug 25 16:28:46 2016 From: victor.palau at canonical.com (Victor Palau) Date: Thu, 25 Aug 2016 17:28:46 +0100 Subject: Snappy + root encryption In-Reply-To: <86e9c256-789c-6ecf-df6b-12fe0da01226@nexiona.com> References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> <86e9c256-789c-6ecf-df6b-12fe0da01226@nexiona.com> Message-ID: Hi Xavier, On Thu, Aug 25, 2016 at 5:10 PM, Xavier Pegenaute M2M < xavier.pegenaute at nexiona.com> wrote: > Hi Tyler, All, > > my use case is something like this: > > we develop some software that can be installed in some hardware provided > by the client. One of our clients requires a snappy distribution. To > protect our data we need to encrypt all FSs in the snappy. Even if at the > moment we have some weak points such as the place were we store the keys. > It is not expected to have a human around every time the snappy boots but > time to time it may be possible. > Our goal is to protect the content in case some one takes the hardware and > mount the partitions as an external drive. > But surely if someone takes the hardware, they just need to boot it and it will decrypt itself. So unless you are storing the decryption key outside the device I am not sure how this will provide you additional security. no? > > To do so I want to encrypt the FSs with LUKS and provide somehow the key > at boot time and decrypt the FSs: system-a/b, writable and swap. During > this process I am facing some problems which I need to solve asap: > - The configured grub on the FS, apparently does not belong to the real > system. When I run update-grub from a fresh installation does not appear > the same menu options than when booted before. > - The "break=premount" parameter does not work > - The kernel and initrd image are located in /boot but the "boot" > partition point to /boot/efi which I guess it will be a problem when de > rootfs is encrypted. > As a solution, I guess it is better to move the kernel + initrd to > /boot/efi. I will need to only update grub and update-initramfs. Am I > missing something? > > Best Regards, > Xavi > > > On 24/08/16 18:30, Tyler Hicks wrote: > >> On 08/23/2016 06:47 AM, Xavier Pegenaute M2M wrote: >> >>> Hi Mark, >>> >>> actually, our goal is to provide hardware to be delivered on costumer >>> premises but for this we need an extra layer of security. This is the >>> reason we are considering the encryption solution. >>> >>> If it is possible our first and preferred solution is to encrypt as much >>> as possible starting from rootfs. >>> >>> I guess I should port the cryptsetup package and dependencies to snap, >>> but since I saw in your mailing list some references I wanted to be sure >>> this is not already done or being in process. >>> >>> As a second step, AFAIK, I should modify the boot process to include >>> support for partition decryption which again I am not sure this is >>> already supported on snappy (crossing fingers xD ). >>> >> Will your devices have a display and a keyboard? Will a human always be >> present during the boot process (after a planned or unplanned reboot) to >> enter the password? >> >> If the answer is 'no' to either of those questions, there's more work to >> do in order to provide secure storage of the encryption key in a way >> that makes it automatically accessible during the boot process. >> >> Let us know what your needs are and we can at least capture the use case >> and requirements in a feature request bug so that we can try to support >> you when designing the storage encryption solution in the platform >> itself. Thanks! >> >> Tyler >> > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenny.murphy at episensor.com Thu Aug 25 17:18:02 2016 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 25 Aug 2016 18:18:02 +0100 Subject: File permissions within a snap In-Reply-To: <750C623E-9CD4-47A3-88ED-CD9E27E9B7A5@canonical.com> References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> <1472123621.19477.32.camel@ubuntu.com> <5e576be4-f339-45a8-87e2-f11109bbc074@canonical.com> <750C623E-9CD4-47A3-88ED-CD9E27E9B7A5@canonical.com> Message-ID: No problem. On 25 August 2016 at 15:36, Zygmunt Krynicki wrote: > > Wiadomość napisana przez Jenny Murphy w dniu > 25.08.2016, o godz. 15:56: > > Hi, > Yes thank you that is what I was looking for. > > > On 25 August 2016 at 14:12, Sergio Schvezov > wrote: > >> El jueves, 25 de agosto de 2016 08h'31:34 ART, Jenny Murphy < >> jenny.murphy at episensor.com> escribió: >> >>> Hi, >>> Unfortunately, either inside or outside quotes it is still blank. >>> >>> Do you have a link to that hello world example you mentioned. >>> >>> The previous reply (from yesterday) mentioned the use of interfaces, >>> maybe >>> this would be cleaner than messing around with scripts and environment >>> variables? >>> I am using snapcraft 1.1.0, are interfaces available to use in that >>> version? >>> >> >> It should be SNAP_APP_PATH and SNAP_APP_DATA_PATH >> >> > I’m sorry, my advice was designed for snapd in 16.04 and beyond. I was not > aware you are looking at 15.04 support. > > Best regards > ZK > > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Fri Aug 26 02:32:50 2016 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Fri, 26 Aug 2016 10:32:50 +0800 Subject: File permissions within a snap In-Reply-To: References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> Message-ID: Hi Jenny, I do not think you need to define "SNAP_USER_DATA＂．It is already there. Please check my "hello" example code at https://github.com/liu-xiao-guo/helloworld-demo. After you install the app, you can run the command like: liuxg at liuxg:~$ hello.env | grep SNAP SNAP_USER_COMMON=/home/liuxg/snap/hello/common SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl: SNAP_COMMON=/var/snap/hello/common SNAP_USER_DATA=/home/liuxg/snap/hello/x1 SNAP_DATA=/var/snap/hello/x1 SNAP_REVISION=x1 SNAP_NAME=hello SNAP_ARCH=amd64 SNAP_VERSION=1.0 SNAP=/snap/hello/x1 Basically, SNAP_USER_DATA is defined as "/home/liuxg/snap/Your_Package_Name/version_number" Best regards, XiaoGuo On Thu, Aug 25, 2016 at 7:03 PM, Jenny Murphy wrote: > Hi, > Do I need to define the location of SNAP_USER_DATA. Currently I added > the following line to a wrapper script that already runs in my app : > > echo "User Data = " $SNAP_USER_DATA > > > The result is > User Data = > > > Thanks a lot for you help. I guess this stuff is very basic but I am > having to get up to speed quickly on snappy. > Jenny > > On 24 August 2016 at 12:01, Zygmunt Krynicki com> wrote: > >> >> Wiadomość napisana przez Jenny Murphy w >> dniu 24.08.2016, o godz. 12:58: >> >> Hi, >> I have a java application built as a .snap. >> As part of its normal operation it will create some files (for output). >> However this is not successful due to permissions issue : >> For example , I tried to create the file in /home/ubuntu/examples/ : >> java.io.FileNotFoundException: /home/ubuntu/examples/example.txt >> (Permission denied) >> I got a similar result whenI tired to create it in the current dir : >> /apps/gateway.sideload/IcNYWMFDGBeY >> >> >> You can freely create files in $SNAP_USER_DATA - the per-user data >> directory or $SNAP_DATA - the global data directory (for daemons). >> >> If you want to write to other locations you need an interface to do it. >> For example you can use the home interface to get write access to most of >> the $HOME directory. >> >> You can do this by just defining a „home” plug on your application. >> >> Best regards >> ZK >> >> >> So is there a way around this? >> >> Thanks in advance for any suggestions. >> >> -- >> *Jenny Murphy* >> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >> jenny.murphy at episensor.com t | +353 (0) 61 >> 512 511 w | http://www.episensor.com >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> >> > > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 w | http://www.episensor.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- XiaoGuo, Liu (刘晓国） Mobile: +86-13911181302 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eloy.garcia.pca at gmail.com Fri Aug 26 05:23:08 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Fri, 26 Aug 2016 07:23:08 +0200 Subject: No such file or directory when try to execute gsettings Message-ID: Hello everybody. I am developing a java-based application that downloads and changes the desktop wallpaper. Depends on the desktop environment, it has to execute a "native" program to do this job. For instance, in Unity executes "gsettings set org.gnome.desktop.background picture-uri file:///home/serrano/Pictures/y.jpg" command line, but gsettings is not found under confinment, throwing this error: Cannot run program "gsettings": error=2, No such file or directory. I have tried gsettings and Unity7 interfaces with no luck. i guess is more a question of executing a program outside the confinment. How could I do that? Thank you very much! Best, Eloy -- Eloy García Almadén -------------- next part -------------- An HTML attachment was scrubbed... URL: From xavier.pegenaute at nexiona.com Fri Aug 26 06:59:49 2016 From: xavier.pegenaute at nexiona.com (Xavier Pegenaute M2M) Date: Fri, 26 Aug 2016 08:59:49 +0200 Subject: Snappy + root encryption In-Reply-To: References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> <86e9c256-789c-6ecf-df6b-12fe0da01226@nexiona.com> Message-ID: <897259df-2cca-ceaa-55be-3838cfa1194b@nexiona.com> Hi Victor, I totally agree with your comment, our second step is to protect/hide/whatever the key store. Regards On 25/08/16 18:28, Victor Palau wrote: > Hi Xavier, > > On Thu, Aug 25, 2016 at 5:10 PM, Xavier Pegenaute M2M > > > wrote: > > Hi Tyler, All, > > my use case is something like this: > > we develop some software that can be installed in some hardware > provided by the client. One of our clients requires a snappy > distribution. To protect our data we need to encrypt all FSs in > the snappy. Even if at the moment we have some weak points such as > the place were we store the keys. It is not expected to have a > human around every time the snappy boots but time to time it may > be possible. > Our goal is to protect the content in case some one takes the > hardware and mount the partitions as an external drive. > > But surely if someone takes the hardware, they just need to boot it > and it will decrypt itself. So unless you are storing the decryption > key outside the device I am not sure how this will provide you > additional security. no? > > > To do so I want to encrypt the FSs with LUKS and provide somehow > the key at boot time and decrypt the FSs: system-a/b, writable and > swap. During this process I am facing some problems which I need > to solve asap: > - The configured grub on the FS, apparently does not belong to the > real system. When I run update-grub from a fresh installation does > not appear the same menu options than when booted before. > - The "break=premount" parameter does not work > - The kernel and initrd image are located in /boot but the "boot" > partition point to /boot/efi which I guess it will be a problem > when de rootfs is encrypted. > As a solution, I guess it is better to move the kernel + > initrd to /boot/efi. I will need to only update grub and > update-initramfs. Am I missing something? > > Best Regards, > Xavi > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seb128 at ubuntu.com Fri Aug 26 08:25:06 2016 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Fri, 26 Aug 2016 10:25:06 +0200 Subject: No such file or directory when try to execute gsettings In-Reply-To: References: Message-ID: Le 26/08/2016 à 07:23, Eloy García (PC Actual) a écrit : > I have tried gsettings and Unity7 interfaces with no luck. i guess is > more a question of executing a program outside the confinment. How > could I do that? Thank you very much! Hey, Using the system command is not allowed but you can include it in your snap and it should work (either copy the binary or stage-packages the deb) Cheers, Sebastien Bacher From ogra at ubuntu.com Fri Aug 26 08:44:02 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 26 Aug 2016 10:44:02 +0200 Subject: File permissions within a snap In-Reply-To: References: <68FBACF1-6415-4401-A24D-E9345672643E@canonical.com> Message-ID: <1472201042.6937.83.camel@ubuntu.com> hi, Am Freitag, den 26.08.2016, 10:32 +0800 schrieb XiaoGuo Liu: > Hi Jenny, > > I do not think you need to define "SNAP_USER_DATA＂．It is already > there. Please check my "hello" example code at https://github.com/liu > -xiao-guo/helloworld-demo. After you install the app, you can run the > command like: > > liuxg at liuxg:~$ hello.env | grep SNAP > SNAP_USER_COMMON=/home/liuxg/snap/hello/common > SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl: > SNAP_COMMON=/var/snap/hello/common > SNAP_USER_DATA=/home/liuxg/snap/hello/x1 > SNAP_DATA=/var/snap/hello/x1 > SNAP_REVISION=x1 > SNAP_NAME=hello > SNAP_ARCH=amd64 > SNAP_VERSION=1.0 > SNAP=/snap/hello/x1 > > Basically, SNAP_USER_DATA is defined as > "/home/liuxg/snap/Your_Package_Name/version_number" > jenny is talking about 15.04, there these variables did not even exist ;) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From eloy.garcia.pca at gmail.com Fri Aug 26 09:00:29 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Fri, 26 Aug 2016 11:00:29 +0200 Subject: No such file or directory when try to execute gsettings In-Reply-To: References: Message-ID: Thank you very much for your quick answer. I want to implement this for other desktop environments, so I guess I have to include every binary I want to invoke, right? I'll give it a try. Thanks again! El 26 ago. 2016 10:26 a. m., "Sebastien Bacher" escribió: > Le 26/08/2016 à 07:23, Eloy García (PC Actual) a écrit : > > I have tried gsettings and Unity7 interfaces with no luck. i guess is > > more a question of executing a program outside the confinment. How > > could I do that? Thank you very much! > > Hey, > > Using the system command is not allowed but you can include it in your > snap and it should work (either copy the binary or stage-packages the deb) > > Cheers, > > Sebastien Bacher > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew.williams at canonical.com Fri Aug 26 16:19:11 2016 From: matthew.williams at canonical.com (Matthew Williams) Date: Fri, 26 Aug 2016 17:19:11 +0100 Subject: Snapping Neovim Message-ID: Hey folks, So I decided to have a go at snapping neovim ( https://github.com/mattyw/neovim/blob/01-snapcraft/snapcraft.yaml) Getting it going with devmode was easy - I loved not having to mess around with confinement while getting the rest of the snap working, that's a great feature. My problem now is what kind of thing I should be doing for classes of application like this when confinement is strict. As you can see from the above yaml I've added the home part which means I can read and write files in home. But for things like configuration files neovim looks in hidden files and directories, and as a user you want to be able to edit these files, and indeed any file on disk. But this doesn't fit the confinement model very well. I was wondering if anyone on the list had a good suggestion for what I should be doing? Thanks Matty -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.mcdermott at canonical.com Fri Aug 26 16:30:17 2016 From: andrew.mcdermott at canonical.com (Andrew McDermott) Date: Fri, 26 Aug 2016 17:30:17 +0100 Subject: Snapping Neovim In-Reply-To: References: Message-ID: Hi, I'm interested in accessing dotfiles in $HOME too. I tried to snap some KVM MAAS scripts[0] but ran into issues because I couldn't read .maascli.db. [0] https://github.com/frobware/kvm-maas On 26 August 2016 at 17:19, Matthew Williams wrote: > Hey folks, > > So I decided to have a go at snapping neovim (https://github.com/mattyw/ > neovim/blob/01-snapcraft/snapcraft.yaml) > > Getting it going with devmode was easy - I loved not having to mess around > with confinement while getting the rest of the snap working, that's a great > feature. > > My problem now is what kind of thing I should be doing for classes of > application like this when confinement is strict. As you can see from the > above yaml I've added the home part which means I can read and write files > in home. But for things like configuration files neovim looks in hidden > files and directories, and as a user you want to be able to edit these > files, and indeed any file on disk. But this doesn't fit the confinement > model very well. > > I was wondering if anyone on the list had a good suggestion for what I > should be doing? > > Thanks > > Matty > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Andrew McDermott Juju Core Sapphire team -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at canonical.com Fri Aug 26 16:53:43 2016 From: andreas at canonical.com (Andreas Hasenack) Date: Fri, 26 Aug 2016 13:53:43 -0300 Subject: Snapping Neovim In-Reply-To: References: Message-ID: Can you change neovim to look for these dot files elsewhere, like $SNAP_USER_DATA (if I didn't typoed the var name)? On Fri, Aug 26, 2016 at 1:19 PM, Matthew Williams < matthew.williams at canonical.com> wrote: > Hey folks, > > So I decided to have a go at snapping neovim (https://github.com/mattyw/ > neovim/blob/01-snapcraft/snapcraft.yaml) > > Getting it going with devmode was easy - I loved not having to mess around > with confinement while getting the rest of the snap working, that's a great > feature. > > My problem now is what kind of thing I should be doing for classes of > application like this when confinement is strict. As you can see from the > above yaml I've added the home part which means I can read and write files > in home. But for things like configuration files neovim looks in hidden > files and directories, and as a user you want to be able to edit these > files, and indeed any file on disk. But this doesn't fit the confinement > model very well. > > I was wondering if anyone on the list had a good suggestion for what I > should be doing? > > Thanks > > Matty > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Fri Aug 26 17:23:08 2016 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 26 Aug 2016 11:23:08 -0600 Subject: Snapping Neovim In-Reply-To: References: Message-ID: <57C07AFC.2030300@canonical.com> On 2016-08-26 10:53, Andreas Hasenack wrote: > Can you change neovim to look for these dot files elsewhere, like > $SNAP_USER_DATA (if I didn't typoed the var name)? That is right for the config files of Neovim itself. However, I would like to be able to edit something like ~/.bashrc. We have a bug for that: https://bugs.launchpad.net/snappy/+bug/1607067 It doesn't have a lot of information, so feel free to expand it in the comments. pura vida. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mark at ubuntu.com Fri Aug 26 21:32:53 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 26 Aug 2016 17:32:53 -0400 Subject: Snappy + root encryption In-Reply-To: <897259df-2cca-ceaa-55be-3838cfa1194b@nexiona.com> References: <7fed1693-3be9-0f97-f47e-abd0bc2e2b56@nexiona.com> <8437cb49-3476-7970-8841-c67b196a9256@nexiona.com> <16fd837f-ed2b-6a52-d58e-8e3808151bc9@canonical.com> <86e9c256-789c-6ecf-df6b-12fe0da01226@nexiona.com> <897259df-2cca-ceaa-55be-3838cfa1194b@nexiona.com> Message-ID: Just to say thank you, these use-cases are all fantastic and things we would accept as patches, or work into the roadmap. Mark From oriol.rius at gmail.com Sat Aug 27 07:01:15 2016 From: oriol.rius at gmail.com (Oriol Rius) Date: Sat, 27 Aug 2016 07:01:15 +0000 Subject: Dell Gateway Message-ID: Hi, I'm working with Ubuntu Snappy on a Dell Gateway and I want to remove next services from the systemd: cloud-config.service enabled cloud-final.service enabled cloud-init-local.service enabled cloud-init.service enabled Using "systemctl disable " I disable the services and they are correctly deactivated and soft link is removed from their /etc/systemd directory. But when I reboot the box everything is restored, I don't know where Snappy changes that. Of course, I remounted the root partition as a 'rw' and later I returned to 'ro' but there is a process o something that restores the original services. Thank you for your ideas. Oriol Rius -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Sat Aug 27 20:45:55 2016 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 27 Aug 2016 22:45:55 +0200 Subject: Snapping LDC (LLVM-based D compiler) Message-ID: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> Hello all, I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the D programming language. I recognize that snapping a compiler might be jumping ahead of the current intended use-case(s), but it's fun to see what could be possible -- and besides, D's compilers are updated fairly often, so it would be great to be able to package them easily in a truly cross-distro form. It's been very exciting to see how straightforward most things are to get set up, but I ran into a few issues that are blockers to finalizing the snap, so I thought I'd ask here for advice on how to address them. First things first: LDC is built using cmake, and getting the essentials of the `snapcraft.yaml` file set up was super-simple: ----------------------------------------- name: ldc version: "1.0.0" summary: D compiler with LLVM backend description: LDC is a compiler for the D programming Language. It is based on the latest DMD frontend and uses LLVM as backend. confinement: devmode apps: ldc2: command: ldc2 plugs: [home] ldmd2: command: ldmd2 plugs: [home] parts: ldc: plugin: cmake source: git://github.com/ldc-developers/ldc.git source-tag: v1.0.0 build-packages: - ldc - llvm-dev - libconfig++-dev - libcurl4-gnutls-dev - libedit-dev - zlib1g-dev ----------------------------------------- This happily builds and generates a snap, and so far as I can tell from the install, all the usual required files are there. (By the way, I really do mean to have ldc in the `build-packages`; LDC now requires a D compiler to build it, so it's necessary to have the older ubuntu-packaged ldc 0.17.1 to build with.) The problems with the snap are threefold: * LDC creates two different executables, ldc2 and ldmd2 (the latter is a wrapper that implements compiler flags to match D's reference compiler, "Digital Mars D" or dmd). However, the names given to the snap executables are ldc.ldc2 and ldc.ldmd2. While I understand the wish to namespace, is there any way to drop the `ldc.` prefix ... ? * LDC creates a config file, `/etc/ldc2.conf`, using libconfig. This defines some default compiler flags, including the default 'include' location of header files for the runtime and standard library. However, perhaps because of how the snap is built, the include paths are specified as if the snap's install dir was the root: switches = [ "-I/include/d/ldc", "-I/include/d", "-L-L/lib", "-defaultlib=phobos2-ldc,druntime-ldc", "-debuglib=phobos2-ldc-debug,druntime-ldc-debug" ]; This means that when one tries to compile anything, the compiler emits error messages that it is unable to locate the headers for runtime or standard-library modules. If one manually specifies the full-path include locations: -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d ... then the compiler can build an object file, but runs into the third of the problems ... * LDC uses the default C compiler for linking, but the snap-installed compiler fails to find it, exiting with a message: Error: failed to locate gcc Can anyone advise on how best to address any of these problems? I would assume the last in particular is down to the lack of an interface for access to things like a linker or other aspects of a build system? I'm really delighted with how blissfully simple it was to get the essentials of packaging in place, and it would be really great if there were straightforward solutions to the remaining issues. Thanks in advance for any advice, and best wishes, -- Joe From mark at ubuntu.com Sat Aug 27 22:05:30 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 27 Aug 2016 18:05:30 -0400 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> Message-ID: On 27/08/16 16:45, Joseph Rushton Wakeling wrote: > It's been very exciting to see how straightforward most things are to > get set up, Yeah, it's been fun here too working on a few holiday snaps :) > but I ran into a few issues that are blockers to finalizing the snap, > so I thought I'd ask here for advice on how to address them. > > [snip] > > This happily builds and generates a snap, and so far as I can tell > from the install, all the usual required files are there. (By the > way, I really do mean to have ldc in the `build-packages`; LDC now > requires a D compiler to build it, so it's necessary to have the older > ubuntu-packaged ldc 0.17.1 to build with.) > > The problems with the snap are threefold: > > * LDC creates two different executables, ldc2 and ldmd2 (the latter > is a > wrapper that implements compiler flags to match D's reference > compiler, > "Digital Mars D" or dmd). However, the names given to the snap > executables > are ldc.ldc2 and ldc.ldmd2. While I understand the wish to > namespace, is > there any way to drop the `ldc.` prefix ... ? We would like to add the ability to have a single snap offer up multiple base-level commands. This will require some changes to snapd, if you are comfortable writing code in Go then feel free to take this on as a challenge :) Niemeyer or MVO on IRC would be able to give you some implementation strategy ideas. For now, if you have a command with the same name as your snap, then that one can drop the namespacing. So if your one command was "ldc" then you would not need ldc.ldc you could have just ldc. > * LDC creates a config file, `/etc/ldc2.conf`, using libconfig. > This defines > some default compiler flags, including the default 'include' > location of > header files for the runtime and standard library. However, > perhaps because > of how the snap is built, the include paths are specified as if > the snap's > install dir was the root: > > switches = [ > "-I/include/d/ldc", > "-I/include/d", > "-L-L/lib", > "-defaultlib=phobos2-ldc,druntime-ldc", > "-debuglib=phobos2-ldc-debug,druntime-ldc-debug" > ]; > > This means that when one tries to compile anything, the compiler > emits > error messages that it is unable to locate the headers for runtime or > standard-library modules. If one manually specifies the full-path > include locations: > > -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d > > ... then the compiler can build an object file, but runs into the > third > of the problems ... Not sure here, I think someone closer to the mechanics of snap paths can help. > > * LDC uses the default C compiler for linking, but the snap-installed > compiler fails to find it, exiting with a message: > > Error: failed to locate gcc > The easy way to fix this is to bundle the linker. The slightly longer way is to arrange for an interface that gets you a linker command. Bear in mind that in Ubuntu Core environments you don't have apt-get to bring in things like that to the base OS, you only have the core snap which is minimal and definitely doesn't have the compiler :) If you depend on a compiler outside, you will only work in places where someone has provided that. My suggestion would be to add the linker to your snap, which gets you unblocked at the price of a fatter snap. Then if you feel inspired go about getting the linker interface set up, in such a way that it can work first on classic systems which happen to have gcc, and then even on all-snap core systems where the linker might be another snap. > Can anyone advise on how best to address any of these problems? I > would assume the last in particular is down to the lack of an > interface for access to things like a linker or other aspects of a > build system? 2 out of 3 ain't bad :) Nicely done and welcome aboard! Mark From mark at ubuntu.com Sat Aug 27 22:15:52 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 27 Aug 2016 18:15:52 -0400 Subject: edge channel of ubuntu-core Message-ID: <69463bd5-3be7-d9a5-6f0c-691d11b4c8a7@ubuntu.com> Hi folks The ubuntu-core image currently released in the 'edge' channel has a bug which breaks snapd in some circumstances. If you are bitten by this the solution is to edit /etc/environment adding this line: SNAP_REEXEC=0 Then just 'sudo service snapd restart' and 'snap refresh ubuntu-core --channel=XXX' where XXX is not edge :) Thanks to lool for the pointers, Mark From stanley.hsiao at canonical.com Sun Aug 28 01:39:59 2016 From: stanley.hsiao at canonical.com (Chen-Han Hsiao (Stanley)) Date: Sun, 28 Aug 2016 09:39:59 +0800 Subject: Dell Gateway In-Reply-To: References: Message-ID: Hi, Oriol, Currently the cloud-init service is enabled by systemd generator /lib/systemd/system-generators/cloud-init-generator. And it is read-only, can't be modified. So systemd will always try to generator the cloud-init service file. If you want to disable cloud-init service, there is still one way to do so: Add kernel parameter "cloud-init=disabled" to grub.cfg. Once the cloud-init systemd-generator detect this kernel parameter, it would stop generate the cloud-init service file. I hope this will help. Best. Stanley. On Sat, Aug 27, 2016 at 3:01 PM, Oriol Rius wrote: > Hi, I'm working with Ubuntu Snappy on a Dell Gateway and I want to remove > next services from the systemd: > > cloud-config.service enabled > cloud-final.service enabled > cloud-init-local.service enabled > cloud-init.service enabled > > Using "systemctl disable " I disable the services and they > are correctly deactivated and soft link is removed from their /etc/systemd > directory. > > But when I reboot the box everything is restored, I don't know where > Snappy changes that. Of course, I remounted the root partition as a 'rw' > and later I returned to 'ro' but there is a process o something that > restores the original services. > > Thank you for your ideas. > > Oriol Rius > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Chen-Han (Stanley) Hsiao 蕭辰翰 Software Engineer / Commercial Engineering - PC & Core stanley.hsiao at canonical.com https://launchpad.net/~swem Canonical Ltd. Room D, 46F, No. 7, Xin Yi Rd., Sec.5, Taipei 101, 11049 Taiwan 11049 台北市信義區信義路 5 段 7 號 46 樓 D 室 Phone: 886-2-8729-6811 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Sun Aug 28 12:00:05 2016 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 28 Aug 2016 14:00:05 +0200 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> Message-ID: <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> On 28.08.2016 00:05, Mark Shuttleworth wrote: > On 27/08/16 16:45, Joseph Rushton Wakeling wrote: >> It's been very exciting to see how straightforward most things are to >> get set up, > > Yeah, it's been fun here too working on a few holiday snaps :) Just the weekend, in my case, but the same principle applies ... :-) > We would like to add the ability to have a single snap offer up multiple > base-level commands. This will require some changes to snapd, if you are > comfortable writing code in Go then feel free to take this on as a > challenge :) Niemeyer or MVO on IRC would be able to give you some > implementation strategy ideas. Well, no promises (busy times elsewhere in life), but I'll certainly try to take a glance. I've never written go code before, but there's a first time for everything... > For now, if you have a command with the same name as your snap, then > that one can drop the namespacing. So if your one command was "ldc" then > you would not need ldc.ldc you could have just ldc. Cool, thanks! I'll rename the snap to `ldc2` then (this is the expected compiler command). That still leaves `ldmd2` to deal with later, but that's less important in general. >> This means that when one tries to compile anything, the compiler >> emits >> error messages that it is unable to locate the headers for runtime or >> standard-library modules. If one manually specifies the full-path >> include locations: >> >> -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d >> >> ... then the compiler can build an object file, but runs into the >> third >> of the problems ... > > Not sure here, I think someone closer to the mechanics of snap paths can > help. I tried also using strict confinement, just to see if it would make a difference, but it doesn't. I presume a complication here is that a snap package might be installed into /snap/ or into /home//snap/ so the precise path would have to be determined at install time, it can't be known at packaging time ... ? Is there any wildcard that could be used in order to get the snap's install dir, that could be inserted into the config file? Along the lines of, -I$WHERE_THE_SNAP_LIVES/include/d/ldc ... ? > The easy way to fix this is to bundle the linker. The slightly longer > way is to arrange for an interface that gets you a linker command. Ah, interesting thought -- I'd considered the interface to the linker, but the thought of just bundling it hadn't occurred to me. I'll chat with the LDC devs and see what the minimal requirement would be here. > Bear in mind that in Ubuntu Core environments you don't have apt-get to bring > in things like that to the base OS, you only have the core snap which is > minimal and definitely doesn't have the compiler :) If you depend on a > compiler outside, you will only work in places where someone has > provided that. My suggestion would be to add the linker to your snap, > which gets you unblocked at the price of a fatter snap. Then if you feel > inspired go about getting the linker interface set up, in such a way > that it can work first on classic systems which happen to have gcc, and > then even on all-snap core systems where the linker might be another snap. Re the classic system -- it did occur to me that the most straightforward short-term solution would be to require that the `classic` snap be present. So in that case it's just a matter of exposing (say) a `gcc` interface from the classic snap, or just the linker if it's possible to be narrower? >> Can anyone advise on how best to address any of these problems? I >> would assume the last in particular is down to the lack of an >> interface for access to things like a linker or other aspects of a >> build system? > > 2 out of 3 ain't bad :) Is this the point where we start singing, "I want you, I need you" to one another? :-P As it happens I don't know if I _need_ snappy, but I am finding myself wanting it and I'm reasonably on the path to loving it ... a better 2 out of 3 than Meatloaf's, I feel ... :-) > Nicely done and welcome aboard! Cheers! Thanks again & best wishes, -- Joe From mark at ubuntu.com Sun Aug 28 16:28:43 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sun, 28 Aug 2016 12:28:43 -0400 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> Message-ID: <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> On 28/08/16 08:00, Joseph Rushton Wakeling wrote: > >> We would like to add the ability to have a single snap offer up multiple >> base-level commands. This will require some changes to snapd, if you are >> comfortable writing code in Go then feel free to take this on as a >> challenge :) Niemeyer or MVO on IRC would be able to give you some >> implementation strategy ideas. > > Well, no promises (busy times elsewhere in life), but I'll certainly > try to take a glance. I've never written go code before, but there's > a first time for everything... > Can highly recommend learning Go, but this would be the deep end, better to find more straightforward starting point :) >> For now, if you have a command with the same name as your snap, then >> that one can drop the namespacing. So if your one command was "ldc" then >> you would not need ldc.ldc you could have just ldc. > > Cool, thanks! I'll rename the snap to `ldc2` then (this is the > expected compiler command). > > That still leaves `ldmd2` to deal with later, but that's less > important in general. Yeah, that would end up as ldc2.ldmd2 for the moment, but once we have multiple commands mapped in from the snap we could allocate the ldmd2 command to it and it would automatically become available without the snap namespace prefix. > I presume a complication here is that a snap package might be > installed into /snap/ or into /home//snap/ so the precise path > would have to be determined at install time, it can't be known at > packaging time ... ? > > Is there any wildcard that could be used in order to get the snap's > install dir, that could be inserted into the config file? Along the > lines of, > > -I$WHERE_THE_SNAP_LIVES/include/d/ldc > Try $SNAP for the location of the snap root, and there are a few others like $SNAP_DATA and $SNAP_COMMON and $SNAP_USER_DATA and $SNAP_USER_COMMON which are writable directories (the COMMON ones are unversioned the others get snapshotted on update). The snap also get its own /tmp directory. > Re the classic system -- it did occur to me that the most > straightforward short-term solution would be to require that the > `classic` snap be present. So in that case it's just a matter of > exposing (say) a `gcc` interface from the classic snap, or just the > linker if it's possible to be narrower? Yes you can arrange for the snap to see stuff from the rest of the world, but the more of that you have, the more you burden the user to get all those bits in place. I would explore the bundling option and see how that pans out. It doesn't look like it's particularly large. And we're adding delta updates so even if it is quite large it will only affect update sizes when it changes. > Is this the point where we start singing, "I want you, I need you" to > one another? :-P LOL :) Mark From joseph.wakeling at webdrake.net Sun Aug 28 21:21:00 2016 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 28 Aug 2016 23:21:00 +0200 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> Message-ID: <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> On 28.08.2016 18:28, Mark Shuttleworth wrote: > Try $SNAP for the location of the snap root, and there are a few others > like $SNAP_DATA and $SNAP_COMMON and $SNAP_USER_DATA and > $SNAP_USER_COMMON which are writable directories (the COMMON ones are > unversioned the others get snapshotted on update). The snap also get its > own /tmp directory. I found a different solution courtesy of LDC itself: it supports a wildcard %%ldcbinarypath%% that can be inserted into paths in the ldc2.conf file. It's easy to handle this manually -- just `snapcraft stage`, a quick search'n'replace in stage/etc/ldc2.conf, and then `snapcraft snap` to finish things up -- but is there any way to insert some sort of end-of-stage hook to do this automatically? Being able to trigger a simple `sed` call would be enough, I'd have thought. I can always provide a Makefile that carries out the stages, but it'd be nice if it was possible to just specify this from within snapcraft.yaml. > Yes you can arrange for the snap to see stuff from the rest of the > world, but the more of that you have, the more you burden the user to > get all those bits in place. I would explore the bundling option and see > how that pans out. It doesn't look like it's particularly large. And > we're adding delta updates so even if it is quite large it will only > affect update sizes when it changes. OK, makes sense. According to the LDC devs: You need a GCC-compatible linker driver, which links in the C standard libraries. (The latter is the reason why (g)cc is used instead of ld.) You might need to pull in the full GCC package if there is no other way to depend on a C toolchain. ... which is a bit 'ouch', but seems like a viable enough starting point. Just to make sure I don't head off in completely the wrong direction, is there a straightforward (or at least, advisable) way to include gcc and the C standard libraries in a snap, perhaps deriving from existing Ubuntu packages? I imagine this doesn't have a ready solution yet, but just to make sure... Thanks again & best wishes, -- Joe From joseph.wakeling at webdrake.net Mon Aug 29 00:01:01 2016 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 29 Aug 2016 02:01:01 +0200 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> Message-ID: On 28.08.2016 23:21, Joseph Rushton Wakeling wrote: > Just to make sure I don't head off in completely the wrong direction, is there a > straightforward (or at least, advisable) way to include gcc and the C standard > libraries in a snap, perhaps deriving from existing Ubuntu packages? I imagine > this doesn't have a ready solution yet, but just to make sure... OK, I discovered `stage-packages` ;-) This is turning into a little bit of a rabbit warren, but looks promising: including gcc and libc6 got me to the point where the complaints have moved from the availability of gcc to: /snap/ldc2/x1/usr/bin/ld: cannot find crt1.o: No such file or directory /snap/ldc2/x1/usr/bin/ld: cannot find crti.o: No such file or directory /snap/ldc2/x1/usr/bin/ld: cannot find -lrt /snap/ldc2/x1/usr/bin/ld: cannot find -ldl /snap/ldc2/x1/usr/bin/ld: cannot find -lpthread /snap/ldc2/x1/usr/bin/ld: cannot find -lm /snap/ldc2/x1/usr/bin/ld: cannot find -lc /snap/ldc2/x1/usr/bin/ld: cannot find crtn.o: No such file or directory As far as I can see the libraries are installed, but presumably something is missing from various bits of config to tell gcc where to look for them. No doubt I'll be able to work it out after sleeping on it ... :-P From andrew.wilkins at canonical.com Mon Aug 29 01:38:08 2016 From: andrew.wilkins at canonical.com (Andrew Wilkins) Date: Mon, 29 Aug 2016 01:38:08 +0000 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> Message-ID: On Mon, Aug 29, 2016 at 8:02 AM Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 28.08.2016 23:21, Joseph Rushton Wakeling wrote: > > Just to make sure I don't head off in completely the wrong direction, is > there a > > straightforward (or at least, advisable) way to include gcc and the C > standard > > libraries in a snap, perhaps deriving from existing Ubuntu packages? I > imagine > > this doesn't have a ready solution yet, but just to make sure... > > OK, I discovered `stage-packages` ;-) This is turning into a little bit > of a > rabbit warren, but looks promising: including gcc and libc6 got me to the > point > where the complaints have moved from the availability of gcc to: > > /snap/ldc2/x1/usr/bin/ld: cannot find crt1.o: No such file or > directory > /snap/ldc2/x1/usr/bin/ld: cannot find crti.o: No such file or > directory > /snap/ldc2/x1/usr/bin/ld: cannot find -lrt > /snap/ldc2/x1/usr/bin/ld: cannot find -ldl > /snap/ldc2/x1/usr/bin/ld: cannot find -lpthread > /snap/ldc2/x1/usr/bin/ld: cannot find -lm > /snap/ldc2/x1/usr/bin/ld: cannot find -lc > /snap/ldc2/x1/usr/bin/ld: cannot find crtn.o: No such file or > directory > I've been looking into doing this too, for llgo (Go compiler frontend for LLVM). You need libc6-dev also. After including that, I was then met with another issue: libc.so is a linker script, and that uses absolute paths to point at the real libraries. I haven't solved that yet. If it's possible to override files in a staged package, you could just provide a replacement linker script. Cheers, Andrew > As far as I can see the libraries are installed, but presumably something > is > missing from various bits of config to tell gcc where to look for them. > > No doubt I'll be able to work it out after sleeping on it ... :-P > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xavier.pegenaute at nexiona.com Mon Aug 29 10:44:14 2016 From: xavier.pegenaute at nexiona.com (Xavier Pegenaute M2M) Date: Mon, 29 Aug 2016 12:44:14 +0200 Subject: Snappy + root encryption + vmlinuz files lost Message-ID: <8ef95f4e-b15e-955b-0ef9-64759c527aff@nexiona.com> Hi all, I've been able to encrypt the rootfs but I am stuck on legally boot vmlinux and cia from the unencrypted /dev/vda2 partition. Firstly I tried looking for some configuration files: - With the initramfs I found the BOOTDIR keyword in the /etc/initramfs-tools/update-initramfs.conf file which works properly. - But for the vmlinuz files I did not find any reference for it. Anyone know how I could move the generation of these files into another dir? As a second approach I though in changing the "/boot/efi" mount point to "/boot" but this fstab entry apparently is created dynamically on initramfs time and based on labels. I don't see the proper way to modify it. Anyone could provide a bot of light here? Regards From zygmunt.krynicki at canonical.com Mon Aug 29 11:30:47 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 29 Aug 2016 13:30:47 +0200 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> Message-ID: > Wiadomość napisana przez Joseph Rushton Wakeling w dniu 27.08.2016, o godz. 22:45: > > Hello all, > > I thought I'd have a go at making a snap of LDC, the LLVM-based compiler for the D programming language. I recognize that snapping a compiler might be jumping ahead of the current intended use-case(s), but it's fun to see what could be possible -- and besides, D's compilers are updated fairly often, so it would be great to be able to package them easily in a truly cross-distro form. > > It's been very exciting to see how straightforward most things are to get set up, but I ran into a few issues that are blockers to finalizing the snap, so I thought I'd ask here for advice on how to address them. > > First things first: LDC is built using cmake, and getting the essentials of the `snapcraft.yaml` file set up was super-simple: > > ----------------------------------------- > name: ldc > version: "1.0.0" > summary: D compiler with LLVM backend > description: LDC is a compiler for the D programming Language. > It is based on the latest DMD frontend and uses LLVM as backend. > confinement: devmode > > apps: > ldc2: > command: ldc2 > plugs: [home] > ldmd2: > command: ldmd2 > plugs: [home] > > parts: > ldc: > plugin: cmake > source: git://github.com/ldc-developers/ldc.git > source-tag: v1.0.0 > build-packages: > - ldc > - llvm-dev > - libconfig++-dev > - libcurl4-gnutls-dev > - libedit-dev > - zlib1g-dev > ----------------------------------------- > > This happily builds and generates a snap, and so far as I can tell from the install, all the usual required files are there. (By the way, I really do mean to have ldc in the `build-packages`; LDC now requires a D compiler to build it, so it's necessary to have the older ubuntu-packaged ldc 0.17.1 to build with.) > > The problems with the snap are threefold: > > * LDC creates two different executables, ldc2 and ldmd2 (the latter is a > wrapper that implements compiler flags to match D's reference compiler, > "Digital Mars D" or dmd). However, the names given to the snap executables > are ldc.ldc2 and ldc.ldmd2. While I understand the wish to namespace, is > there any way to drop the `ldc.` prefix ... ? > > * LDC creates a config file, `/etc/ldc2.conf`, using libconfig. This defines > some default compiler flags, including the default 'include' location of > header files for the runtime and standard library. However, perhaps because > of how the snap is built, the include paths are specified as if the snap's > install dir was the root: > > switches = [ > "-I/include/d/ldc", > "-I/include/d", > "-L-L/lib", > "-defaultlib=phobos2-ldc,druntime-ldc", > "-debuglib=phobos2-ldc-debug,druntime-ldc-debug" > ]; > > This means that when one tries to compile anything, the compiler emits > error messages that it is unable to locate the headers for runtime or > standard-library modules. If one manually specifies the full-path > include locations: > > -I/snap/ldc/current/include/d/ldc -I/snap/ldc/current/include/d > > ... then the compiler can build an object file, but runs into the third > of the problems ... > > * LDC uses the default C compiler for linking, but the snap-installed > compiler fails to find it, exiting with a message: > > Error: failed to locate gcc You can try to „see” gcc via /var/lib/snapd/hostfs/usr/bin/gcc but I bet it won’t „just work” because we are now in a chroot [1]. You could try to put gcc inside your own snap (I would actually do this to stay fully self-contained) but that might require different work to snap. Given enough permissions you could get out of the chroot and run host’s gcc with appropriate arguments but you might run into issues with passing files around by path (see the referenced link for details). If you only use -pipe then things should work. We also have snapd-xdg-open and I was wondering if it would be okay to extend it to do things like „run this command on the host with the permission of the current user” if the command can be white-listed to belong to an interface (e.g. you we could say that LDC has permissions to run „gcc” with any arguments). [1] http://www.zygoon.pl/2016/08/snap-execution-environment.html > > Can anyone advise on how best to address any of these problems? I would assume the last in particular is down to the lack of an interface for access to things like a linker or other aspects of a build system? > > I'm really delighted with how blissfully simple it was to get the essentials of packaging in place, and it would be really great if there were straightforward solutions to the remaining issues. > > Thanks in advance for any advice, and best wishes, > > -- Joe > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From mabnhdev at gmail.com Mon Aug 29 12:33:59 2016 From: mabnhdev at gmail.com (MikeB) Date: Mon, 29 Aug 2016 08:33:59 -0400 Subject: Snappy on OpenSwitch Message-ID: Hi, I'm very interested in adding Snappy support to OpenSwitch ( www.openswitch.net). OpenSwitch is a Network Operating System for network switches build upon OpenEmbedded/Yocto/Poky. I'm using a branch of OpenSwitch in which they've upgraded to Yocto 2.1 - https://github.com/open-switch/ops-build branch "feature/yocto_2.1". I've added meta-snappy to the bblayers.conf file used to build OpenSwitch and I was able to successfully 'bitbake snappy-demo-image' so that I at least know your meta-snappy layer is compatible with the OpenSwitch layers. My knowledge of OE/bitbake is limited and I'm hoping someone could provide some pointers or guidance to integrating Snappy onto an existing OE/Yocto distribution such as OpenSwitch. Thanks, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Mon Aug 29 12:46:00 2016 From: simon.fels at canonical.com (Simon Fels) Date: Mon, 29 Aug 2016 14:46:00 +0200 Subject: Snappy on OpenSwitch In-Reply-To: References: Message-ID: <55cdfee6-d6d2-22ea-5d1a-d5bfd9449dcf@canonical.com> Hey Mike, > I'm very interested in adding Snappy support to OpenSwitch > (www.openswitch.net ). > > OpenSwitch is a Network Operating System for network switches build upon > OpenEmbedded/Yocto/Poky. Pretty nice idea! > I'm using a branch of OpenSwitch in which they've upgraded to Yocto 2.1 > - https://github.com/open-switch/ops-build > branch > "feature/yocto_2.1". > > I've added meta-snappy to the bblayers.conf file used to build > OpenSwitch and I was able to successfully 'bitbake snappy-demo-image' so > that I at least know your meta-snappy layer is compatible with the > OpenSwitch layers. > > My knowledge of OE/bitbake is limited and I'm hoping someone could > provide some pointers or guidance to integrating Snappy onto an existing > OE/Yocto distribution such as OpenSwitch. You already did the first step and verified the build of the relevant components (snapd and snap-confine) works well in OpenSwitch. The next step is to get the different config options for the kernel into your kernel defconfig. We have various sample kernel trees at [1] which you can use as reference. In meta-snappy I extended the default linux-yocto defconfig with the bits listed in [2]. I suspect OpenSwitch may use a different kernel tree so you have to apply the different options for it as well. You don't need any AppArmor related patches if you want just unconfined snaps working for a first step. As next thing you have to add snapd and snap-confine to the content of the OpenSwitch image. Adding snap-confine and snapd in [3] is ok to get it things working. Later you want to add a packagegroup especially for snappy which I am planing to add to meta-snappy which then will automatically pull in all necessary dependencies for you. Once that is done you should be able to build a regular OpenSwitch image, flash it on a device or boot it in an emulator and should have snapd running and being able to install snaps and run their applications. If you need further help or have questions, just ask here or ping me (nick morphis) on IRC in #snappy on FreeNode. regards, Simon [1]: https://github.com/snapcore/sample-kernels [2]: https://github.com/morphis/meta-snappy/blob/master/recipes-kernel/linux/files/snappy.cfg [3]: https://git.openswitch.net/cgit/openswitch/ops-build/tree/yocto/openswitch/meta-distro-openswitch/recipes-core/packagegroups/packagegroup-openswitch.bb?h=feature/yocto_2.1 From michael.vogt at canonical.com Mon Aug 29 15:48:52 2016 From: michael.vogt at canonical.com (Michael Vogt) Date: Mon, 29 Aug 2016 17:48:52 +0200 Subject: New 2.13 snapd release available Message-ID: <20160829154852.GF3871@bod> Hi, we are happy to announce that the new 2.13 release is released in Ubuntu 16.04 and Fedora 24 (COPR). Other distributions will follow soon. We also released a new version of the "core" snap that contains this version of snapd. Some highlights: - snap assertions checking is working end-to-end (!) - new interfaces: + lxd-support (we are very excited about this one) + fuse + mpris fixes - many bugfixes - image improvements Please let us know if you notice any issues. Cheers, Michael From joseph.wakeling at webdrake.net Mon Aug 29 22:06:24 2016 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 30 Aug 2016 00:06:24 +0200 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> Message-ID: <30004526-4ac8-996c-5d25-31373469252b@webdrake.net> On 29.08.2016 03:38, Andrew Wilkins wrote: > I've been looking into doing this too, for llgo (Go compiler frontend for LLVM). Nice! :-) > You need libc6-dev also. After including that, I was then met with another > issue: libc.so is a linker script, and that uses absolute paths to point at the > real libraries. I haven't solved that yet. If it's possible to override files in > a staged package, you could just provide a replacement linker script. Yea, including libc6-dev gets me to the point where attempting to build a program fails with: cannot find /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a ... which I presume is down to the linker script expecting the absolute paths you describe. I already edit some stuff after the stage -- my current process is to type `snapcraft stage`, and after that completes, editing files in the `stage/` directory, followed by `snapcraft snap` to finish it up. So, in principle it should be possible to edit the stuff in stage/usr/lib/x86_64-linux-gnu to change the paths. (I guess it'll need to be more than just libc.so though; I'd guess libm.so and libpthread.so will also need to be tweaked.) It's a bit late at night for me to start work on it now and I probably won't have time tomorrow, but I'll give it a go some time this week. If you get to it before me and it works for you, let me know! Thanks & best wishes, -- Joe From andrew.wilkins at canonical.com Tue Aug 30 04:18:27 2016 From: andrew.wilkins at canonical.com (Andrew Wilkins) Date: Tue, 30 Aug 2016 04:18:27 +0000 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: <30004526-4ac8-996c-5d25-31373469252b@webdrake.net> References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> <30004526-4ac8-996c-5d25-31373469252b@webdrake.net> Message-ID: On Tue, Aug 30, 2016 at 6:06 AM Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 29.08.2016 03:38, Andrew Wilkins wrote: > > I've been looking into doing this too, for llgo (Go compiler frontend > for LLVM). > > Nice! :-) > > > You need libc6-dev also. After including that, I was then met with > another > > issue: libc.so is a linker script, and that uses absolute paths to point > at the > > real libraries. I haven't solved that yet. If it's possible to override > files in > > a staged package, you could just provide a replacement linker script. > > Yea, including libc6-dev gets me to the point where attempting to build a > program fails with: > > cannot find /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a > > ... which I presume is down to the linker script expecting the absolute > paths > you describe. > > I already edit some stuff after the stage -- my current process is to type > `snapcraft stage`, and after that completes, editing files in the `stage/` > directory, followed by `snapcraft snap` to finish it up. > > So, in principle it should be possible to edit the stuff in > stage/usr/lib/x86_64-linux-gnu to change the paths. (I guess it'll need > to be > more than just libc.so though; I'd guess libm.so and libpthread.so will > also > need to be tweaked.) > > It's a bit late at night for me to start work on it now and I probably > won't > have time tomorrow, but I'll give it a go some time this week. If you get > to it > before me and it works for you, let me know! > Actually, editing the files isn't necessary at all. You can just pass the --sysroot option to gcc. I just hacked up a quick gcc snap which works: https://gist.github.com/axw/1d4b0206e11ff46a26439244224a4cc9 If you can convince ldc2 to pass the same option (/etc/ldc2.conf?), then it should just work. Cheers, Andrew > Thanks & best wishes, > > -- Joe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Tue Aug 30 07:16:13 2016 From: vasilisc777 at gmail.com (Vasilisc) Date: Tue, 30 Aug 2016 10:16:13 +0300 Subject: xdg-open again Message-ID: <308ea1b5-e355-3a44-44d4-d4bbc7aa470a@gmail.com> 1) snapcraft.yaml for test-app 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 2) prime/bin/xdg-open #!/bin/sh dbus-send --print-reply --session --dest=com.canonical.SafeLauncher / com.canonical.SafeLauncher.OpenURL string:"$1" 3) My host Ubuntu 16.10 have installed snapd-xdg-open $ apt-cache policy snapd-xdg-open snapd-xdg-open: Installed: 0.0.0 $ apt-cache policy snapd snapd: Installed: 2.14+16.10 =============================================== If I run test2, then got the problem /snap/test2/x1/bin/xdg-open: 3: /snap/test2/x1/bin/xdg-open: dbus-send: Permission denied In /var/log/syslog Aug 30 10:13:04 vasilisc kernel: [ 349.006386] audit: type=1400 audit(1472541184.035:52): apparmor="DENIED" operation="exec" profile="snap.test2.test2" name="/usr/bin/dbus-send" pid=32126 comm="xdg-open" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 -- Best regards, vasilisc From eloy.garcia.pca at gmail.com Tue Aug 30 07:20:25 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 30 Aug 2016 09:20:25 +0200 Subject: No such file or directory when try to execute gsettings In-Reply-To: References: Message-ID: Hi all again. As Sebastian Bacher suggested, I included gsettings binary within my snap package. This is the snapcraft.yaml file: 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 confinement: strict apps: wallpaperdownloader: command: wallpaperdownloader.sh plugs: [x11, network-bind, home] parts: # Pulls the code from the original source (master branch) wallpaperdownloader: plugin: maven source: . stage-packages: - libglib2.0-bin # 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: copy files: wallpaperdownloader.sh: bin/wallpaperdownloader.sh ------------- Including libglib2.0-bin as stage-package, the application doesn't complain anymore about "No such file or directoy" because it finds gsettings binary on stage/usr/bin. Nevertheless, nothing happens when command line "gsettings set org.gnome.desktop.background picture-uri file://blablabla.jpg" is executed within the java code. I don't know how to "link" this command inside the snap with the native "command" and configuration files outside. The execution of this command should affect to the native environment and not the snap confinement created I guess, in order to change the current wallpaper in GNOME 3 or Unity. Any ideas or suggestions? Thank you very much for your time and effort :) Best, Eloy 2016-08-26 11:00 GMT+02:00 Eloy García (PC Actual) < eloy.garcia.pca at gmail.com>: > Thank you very much for your quick answer. I want to implement this for > other desktop environments, so I guess I have to include every binary I > want to invoke, right? > > I'll give it a try. Thanks again! > > El 26 ago. 2016 10:26 a. m., "Sebastien Bacher" > escribió: > >> Le 26/08/2016 à 07:23, Eloy García (PC Actual) a écrit : >> > I have tried gsettings and Unity7 interfaces with no luck. i guess is >> > more a question of executing a program outside the confinment. How >> > could I do that? Thank you very much! >> >> Hey, >> >> Using the system command is not allowed but you can include it in your >> snap and it should work (either copy the binary or stage-packages the deb) >> >> Cheers, >> >> Sebastien Bacher >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> > -- Eloy García Almadén -------------- next part -------------- An HTML attachment was scrubbed... URL: From seb128 at ubuntu.com Tue Aug 30 08:05:27 2016 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Tue, 30 Aug 2016 10:05:27 +0200 Subject: No such file or directory when try to execute gsettings In-Reply-To: References: Message-ID: Le 30/08/2016 à 09:20, Eloy García (PC Actual) a écrit : > Any ideas or suggestions? Thank you very much for your time and effort :) Hey, I didn't look into details of your snap but gsettings is confined so you need to add "gsettings" interface to your list, maybe start trying if that's enough to make it work Cheers, Sebastien Bacher From eloy.garcia.pca at gmail.com Tue Aug 30 08:15:38 2016 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 30 Aug 2016 10:15:38 +0200 Subject: No such file or directory when try to execute gsettings In-Reply-To: References: Message-ID: Hi Sebastien! Thanks for your answer, but I forgot to say I tried gsettings and unity7 interfaces with no success. Nevertheless, I only put those interfaces in snapcraft.yml, but I didn't do anyting else (configurations, tweaks...). Adding more information, this is the script executed when wallpaperdownloader is launched. Maybe it is here where I should add some mappings to the "native" environment? #!/bin/sh # Only for packaging! # Script for snap packaging wallpaperdownloader application. It is not related to the code itself # Not good, needed for fontconfig export XDG_DATA_HOME=$SNAP/usr/share # Font Config export FONTCONFIG_PATH=$SNAP/etc/fonts/config.d export FONTCONFIG_FILE=$SNAP/etc/fonts/fonts.conf export HOME=$SNAP_USER_DATA java -jar -Duser.home=$SNAP_USER_DATA $SNAP/jar/wallpaperdownloader.jar Thanks again :) Eloy 2016-08-30 10:05 GMT+02:00 Sebastien Bacher : > Le 30/08/2016 à 09:20, Eloy García (PC Actual) a écrit : > > Any ideas or suggestions? Thank you very much for your time and effort :) > > > Hey, > > I didn't look into details of your snap but gsettings is confined so you > need to add "gsettings" interface to your list, maybe start trying if > that's enough to make it work > > Cheers, > > Sebastien Bacher > > -- Eloy García Almadén -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.romer at canonical.com Tue Aug 30 19:39:09 2016 From: benjamin.romer at canonical.com (Benjamin M Romer) Date: Tue, 30 Aug 2016 15:39:09 -0400 Subject: Using the content write interface Message-ID: Hi, I'm experimenting with snaps and would like to use the content interface to share files with another snap. I couldn't find documentation for it, so I figured I'd ask. Since there's a "write:" option for the content interface, and the snap itself is read-only, it seemed likely that there is a way to expose files in $SNAP_DATA or $SNAP_COMMON so that the consuming snap could see and modify them. I tried using $SNAP_DATA for the path, but that doesn't work: cannot mount /snap/supplier/x1/$SNAP_DATA at /snap/consumer/x1/data with options bind. errmsg: No such file or directory The mount point exists, so I believe it was using "$SNAP_DATA" literally, and not doing any substitution. What's the right way to point it at the right directory (assuming it's possible)? If write is not possible, is there a way to expose $SNAP_DATA with the "read:" option? Thanks in advance. :) -- Ben From mark at ubuntu.com Tue Aug 30 20:58:46 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 30 Aug 2016 16:58:46 -0400 Subject: Using the content write interface In-Reply-To: References: Message-ID: <602d1aca-95cb-dd4b-7d04-dad5f3d33a71@ubuntu.com> On 30/08/16 15:39, Benjamin M Romer wrote: > I'm experimenting with snaps and would like to use the content > interface to share files with another snap. I couldn't find > documentation for it, so I figured I'd ask. > > Since there's a "write:" option for the content interface, and the > snap itself is read-only, it seemed likely that there is a way to > expose files in $SNAP_DATA or $SNAP_COMMON so that the consuming snap > could see and modify them. The content interface itself is very new, so I suspect the details are still flexible based on this sort of feedback and experience. So thank you for kick the tires :) In general I would say it's unlikely that sharing the entire $SNAP_DATA is desirable. I suspect that the interface is more aimed at: * common builds of shared libraries for large frameworks like ROS and Qt and KDE * shared large data sets (for example texture files in a game system) Mark From yann.sionneau at parrot.com Wed Aug 31 08:49:05 2016 From: yann.sionneau at parrot.com (Yann Sionneau) Date: Wed, 31 Aug 2016 10:49:05 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? Message-ID: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> Hello, It seems the new (snapp'ed) ubuntu-device-flash cannot use my own gadget snap anymore. yann at imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 -o snappy.img --channel edge --gadget $PWD/../../../xxx_2.0_all.snap --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os ubuntu-core --developer-mode --enable-ssh cannot use "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../../xxx_2.0_all.snap", must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"] Is porting Snappy on non official devices not supported anymore? How is it supposed to work now? I must confess that I am blocked in my work because of this change, I cannot generate nor flash images anymore and my project is thus stalled :/ Thanks! Regards, -- Yann From simon.fels at canonical.com Wed Aug 31 08:56:34 2016 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 31 Aug 2016 10:56:34 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? In-Reply-To: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> References: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> Message-ID: <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> On 31.08.2016 10:49, Yann Sionneau wrote: > Hello, > > It seems the new (snapp'ed) ubuntu-device-flash cannot use my own gadget > snap anymore. > > yann at imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 > -o snappy.img --channel edge --gadget $PWD/../../../xxx_2.0_all.snap > --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os > ubuntu-core --developer-mode --enable-ssh > cannot use > "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../../xxx_2.0_all.snap", > must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" > "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"] > > Is porting Snappy on non official devices not supported anymore? No, that is not the case. > How is it supposed to work now? I must confess that I am blocked in my > work because of this change, I cannot generate nor flash images anymore > and my project is thus stalled :/ We're currently in a phase where ubuntu-device-flash is still being used but the future will be a new tool called ubuntu-image which will allow you to create images in a much better way. >From what I got from Michael a lot things are currently hard coded inside ubuntu-device-flash. See [1] for the relevant code bits. You can override the sanity check for the gadget names with setting UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the command line you're executing. Didn't tested this but maybe Michael can comment how this should work. regards, Simon [1]: https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image/view/head:/ubuntu-device-flash/snappy.go#L116 From yann.sionneau at parrot.com Wed Aug 31 09:11:07 2016 From: yann.sionneau at parrot.com (Yann Sionneau) Date: Wed, 31 Aug 2016 11:11:07 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? In-Reply-To: <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> References: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> Message-ID: Le 08/31/2016 à 10:56 AM, Simon Fels a écrit : > On 31.08.2016 10:49, Yann Sionneau wrote: >> Hello, >> >> It seems the new (snapp'ed) ubuntu-device-flash cannot use my own gadget >> snap anymore. >> >> yann at imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 >> -o snappy.img --channel edge --gadget $PWD/../../../xxx_2.0_all.snap >> --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os >> ubuntu-core --developer-mode --enable-ssh >> cannot use >> "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../../xxx_2.0_all.snap", >> must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" >> "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"] >> >> Is porting Snappy on non official devices not supported anymore? > No, that is not the case. > >> How is it supposed to work now? I must confess that I am blocked in my >> work because of this change, I cannot generate nor flash images anymore >> and my project is thus stalled :/ > We're currently in a phase where ubuntu-device-flash is still being used > but the future will be a new tool called ubuntu-image which will allow > you to create images in a much better way. Yes I've heard of the new ubuntu-image tool. It's a good idea to make this new tool! It's just important I think that the old tools stay functional until the new ones are ready. > > From what I got from Michael a lot things are currently hard coded > inside ubuntu-device-flash. See [1] for the relevant code bits. > > You can override the sanity check for the gadget names with setting > UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the command > line you're executing. Didn't tested this but maybe Michael can comment > how this should work. Ok, the environment variable works, thanks a lot! Now I get this: error while executing external command mkfs.ext4 -F -L writable /dev/mapper/loop3p2: mke2fs 1.42.13 (17-May-2015) Invalid filesystem option set: has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize any idea? > > regards, > Simon > > [1]: > https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image/view/head:/ubuntu-device-flash/snappy.go#L116 > From loic.minier at ubuntu.com Wed Aug 31 10:16:41 2016 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Wed, 31 Aug 2016 12:16:41 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? In-Reply-To: References: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> Message-ID: Works for me: $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 /snap/bin/ubuntu-device-flash --verbose core 16 -o snappy.img --channel edge --gadget pc --kernel pc-kernel --os ubuntu-core Determining gadget configuration 836.00 KB / 836.00 KB [==================================] 100.00% 12.77 MB/s 0 Partitioning... Formatting... Mounting... Provisioning... 74.40 MB / 74.40 MB [===================================] 100.00% 24.02 MB/s 3s 74.40 MB / 74.40 MB [===================================] 100.00% 59.46 MB/s 1s 110.54 MB / 110.54 MB [=================================] 100.00% 23.19 MB/s 4s 836.00 KB / 836.00 KB [==================================] 100.00% 68.23 MB/s 0 Unmounting... New image complete Summary: Output: snappy.img Architecture: amd64 Channel: edge Version: 0 On Wed, Aug 31, 2016 at 11:11 AM, Yann Sionneau wrote: > > > Le 08/31/2016 à 10:56 AM, Simon Fels a écrit : > > On 31.08.2016 10:49, Yann Sionneau wrote: > >> Hello, > >> > >> It seems the new (snapp'ed) ubuntu-device-flash cannot use my own gadget > >> snap anymore. > >> > >> yann at imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 > >> -o snappy.img --channel edge --gadget $PWD/../../../xxx_2.0_all.snap > >> --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os > >> ubuntu-core --developer-mode --enable-ssh > >> cannot use > >> "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../. > ./xxx_2.0_all.snap", > >> must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" > >> "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" > "plano-amd64"] > >> > >> Is porting Snappy on non official devices not supported anymore? > > No, that is not the case. > > > >> How is it supposed to work now? I must confess that I am blocked in my > >> work because of this change, I cannot generate nor flash images anymore > >> and my project is thus stalled :/ > > We're currently in a phase where ubuntu-device-flash is still being used > > but the future will be a new tool called ubuntu-image which will allow > > you to create images in a much better way. > Yes I've heard of the new ubuntu-image tool. It's a good idea to make > this new tool! > It's just important I think that the old tools stay functional until the > new ones are ready. > > > > From what I got from Michael a lot things are currently hard coded > > inside ubuntu-device-flash. See [1] for the relevant code bits. > > > > You can override the sanity check for the gadget names with setting > > UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the command > > line you're executing. Didn't tested this but maybe Michael can comment > > how this should work. > Ok, the environment variable works, thanks a lot! > Now I get this: > > error while executing external command mkfs.ext4 -F -L writable > /dev/mapper/loop3p2: mke2fs 1.42.13 (17-May-2015) > Invalid filesystem option set: > has_journal,extent,huge_file,flex_bg,metadata_csum,64bit, > dir_nlink,extra_isize > > any idea? > > > > > regards, > > Simon > > > > [1]: > > https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/ > minimal-first-boot-no-prepare-image/view/head:/ubuntu- > device-flash/snappy.go#L116 > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Wed Aug 31 10:26:09 2016 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 31 Aug 2016 12:26:09 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? In-Reply-To: References: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> Message-ID: On 31.08.2016 12:16, Loïc Minier wrote: > Works for me: > > $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 > /snap/bin/ubuntu-device-flash --verbose core 16 -o snappy.img --channel > edge --gadget pc --kernel pc-kernel --os ubuntu-core Yann is trying to use a gadget snap which isn't in the store but placed on the local disk. So I suspect he is running something like $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 /snap/bin/ubuntu-device-flash ... --gadget /home/user/my-gadget.snap ... regards, Simon > Determining gadget configuration > > 836.00 KB / 836.00 KB [==================================] 100.00% > 12.77 MB/s 0 > > Partitioning... > > Formatting... > > Mounting... > > Provisioning... > > 74.40 MB / 74.40 MB [===================================] 100.00% 24.02 > MB/s 3s > > 74.40 MB / 74.40 MB [===================================] 100.00% 59.46 > MB/s 1s > > 110.54 MB / 110.54 MB [=================================] 100.00% 23.19 > MB/s 4s > > 836.00 KB / 836.00 KB [==================================] 100.00% > 68.23 MB/s 0 > > Unmounting... > > New image complete > > Summary: > > Output: snappy.img > > Architecture: amd64 > > Channel: edge > > Version: 0 > > > On Wed, Aug 31, 2016 at 11:11 AM, Yann Sionneau > > wrote: > > > > Le 08/31/2016 à 10:56 AM, Simon Fels a écrit : > > On 31.08.2016 10:49, Yann Sionneau wrote: > >> Hello, > >> > >> It seems the new (snapp'ed) ubuntu-device-flash cannot use my own gadget > >> snap anymore. > >> > >> yann at imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose core 16 > >> -o snappy.img --channel edge --gadget $PWD/../../../xxx_2.0_all.snap > >> --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os > >> ubuntu-core --developer-mode --enable-ssh > >> cannot use > >> "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../../xxx_2.0_all.snap", > >> must be one of: ["canonical-i386" "canonical-pc" "pc" "canonical-pi2" > >> "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" "plano-amd64"] > >> > >> Is porting Snappy on non official devices not supported anymore? > > No, that is not the case. > > > >> How is it supposed to work now? I must confess that I am blocked in my > >> work because of this change, I cannot generate nor flash images anymore > >> and my project is thus stalled :/ > > We're currently in a phase where ubuntu-device-flash is still being used > > but the future will be a new tool called ubuntu-image which will allow > > you to create images in a much better way. > Yes I've heard of the new ubuntu-image tool. It's a good idea to make > this new tool! > It's just important I think that the old tools stay functional until the > new ones are ready. > > > > From what I got from Michael a lot things are currently hard coded > > inside ubuntu-device-flash. See [1] for the relevant code bits. > > > > You can override the sanity check for the gadget names with setting > > UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the command > > line you're executing. Didn't tested this but maybe Michael can comment > > how this should work. > Ok, the environment variable works, thanks a lot! > Now I get this: > > error while executing external command mkfs.ext4 -F -L writable > /dev/mapper/loop3p2: mke2fs 1.42.13 (17-May-2015) > Invalid filesystem option set: > has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize > > any idea? > > > > > regards, > > Simon > > > > [1]: > > > https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/minimal-first-boot-no-prepare-image/view/head:/ubuntu-device-flash/snappy.go#L116 > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > - Loïc > > From ogra at ubuntu.com Wed Aug 31 10:34:18 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 31 Aug 2016 12:34:18 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? In-Reply-To: References: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> Message-ID: <1472639658.5902.5.camel@ubuntu.com> hi, Am Mittwoch, den 31.08.2016, 12:26 +0200 schrieb Simon Fels: > On 31.08.2016 12:16, Loïc Minier wrote: > > > > Works for me: > > > > $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 > > /snap/bin/ubuntu-device-flash --verbose core 16 -o snappy.img -- > > channel > > edge  --gadget pc --kernel pc-kernel --os ubuntu-core > Yann is trying to use a gadget snap which isn't in the store but > placed > on the local disk. So I suspect he is running something like > > $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 > /snap/bin/ubuntu-device-flash ... --gadget /home/user/my-gadget.snap > ... > ...  > >     /dev/mapper/loop3p2: mke2fs 1.42.13 (17-May-2015) this looks more like there are dangling loop devices (and mounts) from former failed attempts ... i'd try umount and kpartx -d ...  ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Wed Aug 31 11:07:23 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 31 Aug 2016 08:07:23 -0300 Subject: Spread 2016.08.31 is out Message-ID: Hello all, The "enable holidays" release of spread is out in code and snap form with the following improvements: - New halt-timeout option in Linode backend to automatically shutdown and take over machines that run for too long. Our snapd setup will enable that option with a 2h setting, meaning that if there are no more machines available, those running for more than 2h will be stopped and used. The data in the original system is moved aside and not destroyed. - Better handling of high contention. When there was just one or two machines available and too many runners trying to pick them up, the fight might end up on a high number of jobs for the Linode server to handle, slowing selection down. This is now handled better. Please let me know if you see any issues. gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.romer at canonical.com Wed Aug 31 13:05:59 2016 From: benjamin.romer at canonical.com (Benjamin M Romer) Date: Wed, 31 Aug 2016 09:05:59 -0400 Subject: Using the content write interface In-Reply-To: <602d1aca-95cb-dd4b-7d04-dad5f3d33a71@ubuntu.com> References: <602d1aca-95cb-dd4b-7d04-dad5f3d33a71@ubuntu.com> Message-ID: <9d53e384-f506-48ac-e077-002e2c317328@canonical.com> On 08/30/2016 04:58 PM, Mark Shuttleworth wrote: > The content interface itself is very new, so I suspect the details are > still flexible based on this sort of feedback and experience. So thank > you for kick the tires :) I'd like to think of it as shining the tires. :) > In general I would say it's unlikely that sharing the entire $SNAP_DATA > is desirable. What I had in mind here are applications similar to BOINC, where the data to be processed is downloaded from outside and shouldn't be processed under the management application's security model. The download area could be opened using the content interface, with each client project inside its own snap for isolation. This approach could also be used by services like mail spools and message or print queues, or services that work like FTP or Wordpress, where files are uploaded but need to be accessible to plug-ins or other services (like DLNA for a media server, or HTTP, or ClamAV). > I suspect that the interface is more aimed at: > > * common builds of shared libraries for large frameworks like ROS and > Qt and KDE > * shared large data sets (for example texture files in a game system) > > Mark > I've worked with QT in snaps a little, and that would be really good, it'd save a lot of space! :) Having a shareable data area for the QT snap could give users a way to install custom themes at the system level, or make it easier for user-defined external tools to integrate with a snap of the SDK's IDE. I think it'd be nice to have. :) -- Ben From mark at ubuntu.com Wed Aug 31 13:07:18 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 31 Aug 2016 09:07:18 -0400 Subject: Using the content write interface In-Reply-To: <9d53e384-f506-48ac-e077-002e2c317328@canonical.com> References: <602d1aca-95cb-dd4b-7d04-dad5f3d33a71@ubuntu.com> <9d53e384-f506-48ac-e077-002e2c317328@canonical.com> Message-ID: <6d436862-cbb3-8f80-b144-13d7d6e1c12d@ubuntu.com> On 31/08/16 09:05, Benjamin M Romer wrote: > What I had in mind here are applications similar to BOINC, where the > data to be processed is downloaded from outside and shouldn't be > processed under the management application's security model. The > download area could be opened using the content interface, with each > client project inside its own snap for isolation. > > This approach could also be used by services like mail spools and > message or print queues, or services that work like FTP or Wordpress, > where files are uploaded but need to be accessible to plug-ins or > other services (like DLNA for a media server, or HTTP, or ClamAV). Yes, I think it makes sense to have shared writable content, just not the ENTIRETY of the shared writable content. But that's a niggle. Keep shining :) Mark From loic.minier at ubuntu.com Wed Aug 31 18:27:23 2016 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Wed, 31 Aug 2016 20:27:23 +0200 Subject: New ubuntu-device-flash cannot use own gadget snap? In-Reply-To: References: <39865ede-2842-64f2-81a4-7c4b7397514f@parrot.com> <8d9a0ed6-b546-9a3c-c531-129c65d96d7f@canonical.com> Message-ID: Yep; but the failure in kpartx didn't seem specific to local vs remote snaps. For people on the list, I followed up on IRC and Yann was running into weird issues with kpartx and ext4 in his environments, but from a clean Ubuntu vm things worked and that's a viable solution for now. Cheers, - Loïc On Wed, Aug 31, 2016 at 12:26 PM, Simon Fels wrote: > On 31.08.2016 12:16, Loïc Minier wrote: > > Works for me: > > > > $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 > > /snap/bin/ubuntu-device-flash --verbose core 16 -o snappy.img --channel > > edge --gadget pc --kernel pc-kernel --os ubuntu-core > > Yann is trying to use a gadget snap which isn't in the store but placed > on the local disk. So I suspect he is running something like > > $ sudo -E UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 > /snap/bin/ubuntu-device-flash ... --gadget /home/user/my-gadget.snap ... > > regards, > Simon > > > Determining gadget configuration > > > > 836.00 KB / 836.00 KB [==================================] 100.00% > > 12.77 MB/s 0 > > > > Partitioning... > > > > Formatting... > > > > Mounting... > > > > Provisioning... > > > > 74.40 MB / 74.40 MB [===================================] 100.00% 24.02 > > MB/s 3s > > > > 74.40 MB / 74.40 MB [===================================] 100.00% 59.46 > > MB/s 1s > > > > 110.54 MB / 110.54 MB [=================================] 100.00% 23.19 > > MB/s 4s > > > > 836.00 KB / 836.00 KB [==================================] 100.00% > > 68.23 MB/s 0 > > > > Unmounting... > > > > New image complete > > > > Summary: > > > > Output: snappy.img > > > > Architecture: amd64 > > > > Channel: edge > > > > Version: 0 > > > > > > On Wed, Aug 31, 2016 at 11:11 AM, Yann Sionneau > > > wrote: > > > > > > > > Le 08/31/2016 à 10:56 AM, Simon Fels a écrit : > > > On 31.08.2016 10:49, Yann Sionneau wrote: > > >> Hello, > > >> > > >> It seems the new (snapp'ed) ubuntu-device-flash cannot use my own > gadget > > >> snap anymore. > > >> > > >> yann at imperium$ sudo -E /snap/bin/ubuntu-device-flash --verbose > core 16 > > >> -o snappy.img --channel edge --gadget > $PWD/../../../xxx_2.0_all.snap > > >> --kernel ../../../xxx_kernel/xxx-kernel_3.10.97_armhf.snap --os > > >> ubuntu-core --developer-mode --enable-ssh > > >> cannot use > > >> "/home/yann/dev/snappy_xxx/tools/snappy/xxx_image/../../. > ./xxx_2.0_all.snap", > > >> must be one of: ["canonical-i386" "canonical-pc" "pc" > "canonical-pi2" > > >> "pi2" "pi3" "canonical-dragon" "dragonboard" "beagleblack" > "plano-amd64"] > > >> > > >> Is porting Snappy on non official devices not supported anymore? > > > No, that is not the case. > > > > > >> How is it supposed to work now? I must confess that I am blocked > in my > > >> work because of this change, I cannot generate nor flash images > anymore > > >> and my project is thus stalled :/ > > > We're currently in a phase where ubuntu-device-flash is still > being used > > > but the future will be a new tool called ubuntu-image which will > allow > > > you to create images in a much better way. > > Yes I've heard of the new ubuntu-image tool. It's a good idea to make > > this new tool! > > It's just important I think that the old tools stay functional until > the > > new ones are ready. > > > > > > From what I got from Michael a lot things are currently hard coded > > > inside ubuntu-device-flash. See [1] for the relevant code bits. > > > > > > You can override the sanity check for the gadget names with setting > > > UBUNTU_DEVICE_FLASH_IGNORE_UNSTABLE_GADGET_DEFINITION=1 in the > command > > > line you're executing. Didn't tested this but maybe Michael can > comment > > > how this should work. > > Ok, the environment variable works, thanks a lot! > > Now I get this: > > > > error while executing external command mkfs.ext4 -F -L writable > > /dev/mapper/loop3p2: mke2fs 1.42.13 (17-May-2015) > > Invalid filesystem option set: > > has_journal,extent,huge_file,flex_bg,metadata_csum,64bit, > dir_nlink,extra_isize > > > > any idea? > > > > > > > > regards, > > > Simon > > > > > > [1]: > > > > > https://bazaar.launchpad.net/~mvo/goget-ubuntu-touch/ > minimal-first-boot-no-prepare-image/view/head:/ubuntu- > device-flash/snappy.go#L116 > > minimal-first-boot-no-prepare-image/view/head:/ubuntu- > device-flash/snappy.go#L116> > > > > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > > > > > > > -- > > - Loïc > > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Wed Aug 31 19:35:44 2016 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 31 Aug 2016 21:35:44 +0200 Subject: Snapping LDC (LLVM-based D compiler) In-Reply-To: References: <5acf380b-fe37-68df-9eba-15ccbbefe8a9@webdrake.net> <7cff62a8-b4ec-34ab-b674-69b186d340d0@webdrake.net> <5620d7bf-458b-330f-92cb-83e48f0a2bad@ubuntu.com> <622ce8d3-75f9-f1f9-0797-21e7af47beb7@webdrake.net> <30004526-4ac8-996c-5d25-31373469252b@webdrake.net> Message-ID: On 30.08.2016 06:18, Andrew Wilkins wrote: > Actually, editing the files isn't necessary at all. You can just pass the > --sysroot option to gcc. I just hacked up a quick gcc snap which works: > https://gist.github.com/axw/1d4b0206e11ff46a26439244224a4cc9 Cool stuff. As a gcc snap, this works for me; note you can use --sysroot=$SNAP for portability. > If you can convince ldc2 to pass the same option (/etc/ldc2.conf?), then it > should just work. Unfortunately, it looks like there are some complications here :-\ Let's start with my snapcraft.yaml: https://gist.github.com/WebDrake/e4ec1d1065df3011bf88f69a0c00544a ... which defines commands for both gcc and ld, both with the --sysroot=$SNAP option. First things first, run `snapcraft stage`. Then edit the auto-generated stage/etc/ldc2.conf and replace it with this: https://gist.github.com/WebDrake/229645efeca14fa54b0b1c82bcbb6477 ... which as you can see includes a compiler flag: `-gcc=ldc2.gcc`. This should ensure that ldc2.gcc is called when LDC wants to call GCC. Now we can run `snapcraft snap` to finish up, and we can install the resulting snap package. OK, let's create a simple Hello World in D: //////////////////// void main () { import std.stdio : writeln; writeln("Hello, snappy LDC!"); } //////////////////// Now, let's try to build it, using the -v flag so that it'll output all that it does: ldc2.ldmd2 -v hello.d ... and much follows, concluding with: /snap/ldc2/x1/usr/bin/gcc hello.o -o hello -L/snap/ldc2/x1/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 /snap/ldc2/x1/usr/bin/ld: cannot find /usr/lib/x86_64-linux-gnu/libpthread_nonshared.a collect2: error: ld returned 1 exit status Error: /snap/ldc2/x1/usr/bin/gcc failed with status: 1 ... which is very odd; it suggests that despite explicitly asking for `ldc2.gcc` to be called (which would use the --sysroot flag), it's somehow not. I've tried testing by running the "normal" apt-installed ldc and passing the -gcc=ldc2.gcc option, and this works just fine, which makes me wonder: could something weird be happening which is causing the ldc2.gcc command to be "de-aliased" if it's run from within the snap itself? Thanks & best wishes, -- Joe