From sergio.schvezov at canonical.com Sat Apr 1 01:21:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 31 Mar 2017 22:21:00 -0300 Subject: Getting snapcraft.yaml version from a script In-Reply-To: References: Message-ID: On Mar 31, 2017 4:57 PM, "Gregory Lutostanski" < gregory.lutostanski at canonical.com> wrote: Curious how everyone makes sure the version string in the snapcraft.yaml up to date. And if there is an easy way to essentially drive it via 'git tags' and 'git describe'. If anyone has an recipe I would be very happy to use it across my repos. I've tried the following prepare script: sed -i 's/^version: .*/version: '`git describe --tags`'/' snapcraft.yaml But that won't work because snapcraft has read it before checking out the part to build. And I don't like having a separate build script if not necessary (especially since the launchpad builders wont use it). I have been playing around with npm recently, and the way their versions work are good -- but they are only dealing with public releases with a set semver (usually), but at least they have a script to update it with 'npm/yarn version'. What I would really like is to not directly specify the version but let snapcraft get it for me by executing a script. If there is nothing already existent out there... here is a proposal for allowing it and letting it be backward compatible: By default get it from the top-level 'version' value in snapcraft.yaml If that is not present one (and only one) of the parts must have a 'source-version'[1] key,value pair, where the value is a script to be executed -- just like the prepare step. [1] could also be named source-version-script This would get us the following: allow to specify string version using the old keyword. Make a new-keyword that allows us to set the version based on a script. The two different examples would look like... ``` name: some-package version: 1.2.0 ``` XOR ``` name: some-package parts: some-package: source: . source-version: git describe --tags ``` A further extension could be to have the source plugins (such as git/bzr/hg) have default source-version commands and if there is a part with the same name as the snap, use that by default, but that is just sugar and implicit data (which could be argued for either way). Thoughts, or other ways people are doing this now would be greatly appreciated. By the way, not sure if this is already thought out or if this is even the right place for a post like this. To avoid duplication I will redirect you to https://forum.snapcraft.io/t/snapcraft-version-scriptlets/106 From sergio.schvezov at canonical.com Sat Apr 1 01:21:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 31 Mar 2017 22:21:00 -0300 Subject: Getting snapcraft.yaml version from a script In-Reply-To: References: Message-ID: On Mar 31, 2017 4:57 PM, "Gregory Lutostanski" < gregory.lutostanski at canonical.com> wrote: Curious how everyone makes sure the version string in the snapcraft.yaml up to date. And if there is an easy way to essentially drive it via 'git tags' and 'git describe'. If anyone has an recipe I would be very happy to use it across my repos. I've tried the following prepare script: sed -i 's/^version: .*/version: '`git describe --tags`'/' snapcraft.yaml But that won't work because snapcraft has read it before checking out the part to build. And I don't like having a separate build script if not necessary (especially since the launchpad builders wont use it). I have been playing around with npm recently, and the way their versions work are good -- but they are only dealing with public releases with a set semver (usually), but at least they have a script to update it with 'npm/yarn version'. What I would really like is to not directly specify the version but let snapcraft get it for me by executing a script. If there is nothing already existent out there... here is a proposal for allowing it and letting it be backward compatible: By default get it from the top-level 'version' value in snapcraft.yaml If that is not present one (and only one) of the parts must have a 'source-version'[1] key,value pair, where the value is a script to be executed -- just like the prepare step. [1] could also be named source-version-script This would get us the following: allow to specify string version using the old keyword. Make a new-keyword that allows us to set the version based on a script. The two different examples would look like... ``` name: some-package version: 1.2.0 ``` XOR ``` name: some-package parts: some-package: source: . source-version: git describe --tags ``` A further extension could be to have the source plugins (such as git/bzr/hg) have default source-version commands and if there is a part with the same name as the snap, use that by default, but that is just sugar and implicit data (which could be argued for either way). Thoughts, or other ways people are doing this now would be greatly appreciated. By the way, not sure if this is already thought out or if this is even the right place for a post like this. To avoid duplication I will redirect you to https://forum.snapcraft.io/t/snapcraft-version-scriptlets/106 From spencertparkin at gmail.com Sat Apr 1 05:02:36 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Fri, 31 Mar 2017 23:02:36 -0600 Subject: desktop-gtk3 In-Reply-To: <268b3ae1-198c-2140-c65e-cee90d6eca78@ubuntu.com> References: <3502320.28Fj99hbr4@ant> <5432201.hknf6qD210@ant> <268b3ae1-198c-2140-c65e-cee90d6eca78@ubuntu.com> Message-ID: Thanks, Didier. I was on 2.19 of snapcraft. Apparently I was way out of date. Now it is working again, and you can all bask in the glory of my latest release to be uploaded shortly. BTW, I have some snaps that I've uploaded and published, but their total peices of garbage. I can unpublish them from the website, but is there a way to delete them altogether? On Fri, Mar 31, 2017 at 1:06 AM, Didier Roche wrote: > Le 31/03/2017 à 05:55, Spencer Parkin a écrit : > >> That just adds a deprecation warning (if I add the '/', I mean.) It says, >> "DEPRECATED: Found a "/" in the name of the 'desktiop/gtk3' part" >> >> Here's the major error I'm getting... >> >> "Issue while loading plugin: properties failed to load for desktop-gtk3: >> Additional properties are not allowed ('prime' was unexpected)" >> >> I'm punting on this for now (i.e., giving up), but if anyone has any >> ideas, >> please let me know. Thanks. >> > > Check that the indentation is correct and you didn't change spaces with > tabs or so on. > I just copied your snapcraft.yaml and don't have any problem here. > $ snapcraft --version > 2.28 > > Didier > > >> On Thu, Mar 30, 2017 at 11:21 AM, José Pekkarinen < >> jose.pekkarinen at canonical.com> wrote: >> >> >>> Did you tried [desktop/gtk3]? >>> >>> >>> >>> $ snapcraft search >>> >>> ... >>> >>> desktop-gtk3 Helpers for gtk2, gtk3, qt4 and qt5 or >>> glib minimal launchers. >>> ... >>> >>> desktop/gtk3 Helpers for gtk2, gtk3, qt4 and qt5 or >>> glib minimal launchers. >>> ... >>> >>> >>> >>> Best regards. >>> >>> >>> >>> José. >>> >>> >>> >>> On Thursday 30 March 2017 11:09:00 Spencer Parkin wrote: >>> >>> Take a look at the following .yaml file. >>>> https://github.com/ubuntu/snapcraft-desktop-helpers/ >>>> >>> blob/master/demos/gtk3/s >>> >>> napcraft.yaml >>>> Notice the following line in it... >>>> after: [desktop-gtk3] >>>> That's the line I need, and the line I've used most often in my git >>>> history, but it doesn't work anymore. When I'm back on my linux box this >>>> evening, I can give more information. >>>> I wonder if something has changed with an update of snapcraft. >>>> On Thu, Mar 30, 2017 at 11:05 AM, José Pekkarinen < >>>> jose.pekkarinen at canonical.com> wrote: >>>> >>>>> On Thursday 30 March 2017 11:01:02 Spencer Parkin wrote: >>>>> >>>>>> Yes, that's the complete file. See, here's the thing. My program has >>>>>> been >>>>>> correctly snapping with "desktop-gtk3" in there fore quite some time. >>>>>> >>>>> It's >>>>> >>>>>> only recently that it's stopped working. I've looked in my git >>>>>> >>>>> history >>> >>> to >>>>>> see if maybe I've broken something, but that's how it's always been. >>>>>> >>>>> Reading your file what I thing you might want to do is this: >>>>> ... >>>>> parts: >>>>> twistypuzzle: >>>>> plugin: scons >>>>> source: https://github.com/spencerparkin/TwistyPuzzle.git >>>>> source-branch: stable-release >>>>> build-packages: >>>>> - >>>>> after: >>>>> - desktop-gtk3 >>>>> - fontsystem >>>>> - 3dmath >>>>> - permutationgroup >>>>> - rapidjson >>>>> ... >>>>> Let me know if I'm wrong on this assumption. >>>>> Best regards. >>>>> José. >>>>> >>>> >>> >>> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > From spencertparkin at gmail.com Sat Apr 1 06:50:36 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Sat, 1 Apr 2017 00:50:36 -0600 Subject: explicit priming Message-ID: Hi, My snapcraft.yaml file... https://github.com/spencerparkin/TwistyPuzzle/blob/stable-release/Snap/snapcraft.yaml ...as you can see, has a new "prime:" section in it. This wasn't needed in all my earlier snappings, but to finally get my program snapping correctly again, I've had to explicitly add some things in there. I suppose that snapcraft may not be detecting the "libmir*.so*" files as dependencies. Is this a bug in snapcraft? Why did I need to explicitly add my executable files and my "Data" directory? Are these no longer automatically added if you start to explicitly prime things? Thanks. Clearly I'm an novice snap crafter. BTW, how is the snap/snapcraft project coming along? Is it doing well, poor? Is it catching on? Is it the ultimate in package technology!? Thanks, --Spencer From n.curalli at domotz.com Sat Apr 1 07:14:20 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Sat, 1 Apr 2017 07:14:20 +0000 Subject: some console-conf start-up traceback References: Message-ID: Hi Michael, the current snap core on edge channel work fine. The problem that I report disappeared, then I can confirm from my side that the bug is fixed. Cheers, Nicolino. Il 29/03/2017 22:00, Michael Hudson-Doyle ha scritto: > > This should be fixed in the latest edge version of the core snap. Let me > know how it goes if you try it! > > Cheers, > mwh From n.curalli at domotz.com Sat Apr 1 07:17:34 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Sat, 1 Apr 2017 07:17:34 +0000 Subject: a mechanism to make the snap kernel updrade failed References: Message-ID: Hi all, any suggestion or hint about this? Cheers Nicolino Il 28/03/2017 11:32, Nicolino Curalli ha scritto: > [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] > > Hi all, > > we are testing the our kernel snap (Linux4.9) for a orangepi plus 2e board. > > We use the example showed at https://github.com/snapcore/pi3-gadget/blob/master/prebuilt/uboot.env.in for configuring u-boot to support the kernel update. > > This is the code that we use for configuring uboot to support the kernel update: > > snappy_boot=if test "${snap_mode}" = "try"; then setenv snap_mode "trying"; saveenv; if test "${snap_try_core}" != ""; then setenv snap_core "${snap_try_core}"; fi; if test "${snap_try_kernel}" != ""; then setenv snap_kernel "${snap_try_kernel}"; fi; elif test "${snap_mode}" = "trying"; then setenv snap_mode ""; saveenv; fi; run loadfiles; setenv mmcroot "/dev/disk/by-label/writable ${snappy_cmdline} snap_core=${snap_core} snap_kernel=${snap_kernel}"; run mmcargs; bootz ${kernel_addr} ${initrd_addr}:${initrd_size} ${fdt_addr} > snappy_cmdline=net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc > snappy_mode=regular > snappy_trial_boot=0 > > This is the starting point. > > 1) is it the correct way to get to declare u-boot boot.cmd and setting for first gadget deploy? what are the defconfig to use? U-boot version? patch to apply to u-boot code? > > We already tested successful upgrade of the kernel snap. > > Now our goal is the possibility to simulate or provocate a failed upgrade for kernel snap. > > 2) Any suggestions on how to trigger this situation? > > > PS: some other question about u-boot configuration: > > 3) we don't find documentation about snap_ variable usage: it seem that the glue between this type of variable and update process is some action made by snapd; > > Where could we find this mechanism in the code or other place - e.g test ? > > > Thanks in advance for any help. > > Cheers, > > Nicolino > > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From sergio.schvezov at canonical.com Sat Apr 1 11:45:47 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sat, 1 Apr 2017 08:45:47 -0300 Subject: explicit priming In-Reply-To: References: Message-ID: On Apr 1, 2017 3:51 AM, "Spencer Parkin" wrote: Hi, My snapcraft.yaml file... https://github.com/spencerparkin/TwistyPuzzle/blob/stable-release/Snap/ snapcraft.yaml ...as you can see, has a new "prime:" section in it. This wasn't needed in all my earlier snappings, but to finally get my program snapping correctly again, I've had to explicitly add some things in there. I suppose that snapcraft may not be detecting the "libmir*.so*" files as dependencies. Is this a bug in snapcraft? Why did I need to explicitly add my executable files and my "Data" directory? Are these no longer automatically added if you start to explicitly prime things? If you curso only added that bin entry you essentially created a whitelist so all entries would need to be added. Thanks. Clearly I'm an novice snap crafter. BTW, how is the snap/snapcraft project coming along? Is it doing well, poor? Is it catching on? Is it the ultimate in package technology!? I cannot answer this question without looking biased 😇 From john.lenton at canonical.com Sat Apr 1 21:22:24 2017 From: john.lenton at canonical.com (John Lenton) Date: Sat, 1 Apr 2017 22:22:24 +0100 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> <20170331103744.GA21800@riva.ucam.org> Message-ID: On 31 March 2017 at 21:52, Neal Gompa wrote: > we > definitely don't want to use less than SHA256 for snaps. note snaps use sha3-384 currently; the above discussion is, as I understand it, about snapcraft checking upstream checksums at build time. From ngompa13 at gmail.com Sat Apr 1 21:27:52 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Sat, 1 Apr 2017 17:27:52 -0400 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> <20170331103744.GA21800@riva.ucam.org> Message-ID: On Sat, Apr 1, 2017 at 5:22 PM, John Lenton wrote: > On 31 March 2017 at 21:52, Neal Gompa wrote: >> we >> definitely don't want to use less than SHA256 for snaps. > > note snaps use sha3-384 currently; the above discussion is, as I > understand it, about snapcraft checking upstream checksums at build > time. > Sure, but it's just as important that the inputs can be trusted for a given snap created by snapcraft, and allowing people to choose weak algorithms is against that. -- 真実はいつも一つ！/ Always, there's only one truth! From michael.hudson at canonical.com Sun Apr 2 22:17:18 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Mon, 3 Apr 2017 10:17:18 +1200 Subject: some console-conf start-up traceback In-Reply-To: References: Message-ID: Hi Nicolino, Glad to hear it! Cheers, mwh On 1 April 2017 at 20:14, Nicolino Curalli wrote: > Hi Michael, > the current snap core on edge channel work fine. > The problem that I report disappeared, then I can confirm from my side > that the bug is fixed. > > Cheers, > Nicolino. > > > > > > Il 29/03/2017 22:00, Michael Hudson-Doyle ha scritto: > > > > This should be fixed in the latest edge version of the core snap. Let me > > know how it goes if you try it! > > > > Cheers, > > mwh > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From sunny.bhayani at einfochips.com Mon Apr 3 07:54:51 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Mon, 3 Apr 2017 07:54:51 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support Message-ID: Hi Oliver, > > i'm a bit short on time this week but i'll see what i can do :) > > Really appreciate and would eagerly wait if you can try it (if time > permits). > Sorry to bother you, but really looking forward for your time to check if you face the same error what we are facing after building the Xenial sources. Awaiting your reply. Thanks, Sunny ************************************************************************************************************************************************************* eInfochips Business Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated. Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. ************************************************************************************************************************************************************* From alberto.mardegan at canonical.com Mon Apr 3 09:50:39 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Mon, 3 Apr 2017 12:50:39 +0300 Subject: Issues creating webapps snaps with stric confinement In-Reply-To: References: Message-ID: On 31/03/2017 16:28, Vincent JOBARD wrote: > Hi Everyone > > I just try to follow the tutorial to learn how to create webapps snaps > using snapcraft. ( > https://developer.ubuntu.com/en/phone/web/ubuntu-webapps-guide/, very nice > tutorial by the way) > > Unfortunately, when I try to create my snap with strict confinement, I have > a network Error page, but all works fine in devmode. > > I'm at work behind a proxy with cntlm authentification. could it be related > ? Hard to say. Do you have some denials in the syslog when running the application? And if you run it from the console, is there any difference in the output compared to when running in devmode? Ciao, Alberto From kyle.nitzsche at canonical.com Mon Apr 3 13:07:43 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Mon, 3 Apr 2017 09:07:43 -0400 Subject: Issues using dbus in strict In-Reply-To: References: Message-ID: <6fab440b-a25d-d9f9-0307-2e409088b57e@canonical.com> Hi Jamie, Do you have any input on this issue? thanks On 03/31/2017 10:55 AM, Sergey Borovkov wrote: > Hi. I am running a couple of daemons (daemon: simple) and they interact > between each other using dbus. Unfortunately I've ran into the issue when > porting them from devmode to strict, I am getting this backtrace just > trying to obtain SystemBus in python: > > Mar 31 12:44:02 localhost.localdomain snap[1466]: GLib.Error: > g-io-error-quark: Could not connect: Permission denied (14) > Mar 31 12:44:02 localhost.localdomain snap[1466]: return Gio.bus_get_sync(type, > None).pydbus > Mar 31 12:44:02 localhost.localdomain snap[1466]: File "/snap/screenly- > client/165/lib/python3.5/site-packages/pydbus/bus.py", line 19, in bus_get > Mar 31 12:44:02 localhost.localdomain snap[1466]: return bus_get(Bus.Type. > SYSTEM) > Mar 31 12:44:02 localhost.localdomain snap[1466]: File "/snap/screenly- > client/165/lib/python3.5/site-packages/pydbus/bus.py", line 57, in SystemBus > Mar 31 12:44:02 localhost.localdomain snap[1466]: self.bus = SystemBus() > Mar 31 12:44:02 localhost.localdomain kernel: audit: type=1400 > audit(1490964242.523:72): apparmor="DENIED" operation="connect" profile= > "snap.screenly-client.websocket" name="/run/dbus/system_bus_socket" > pid=1466 comm="python3" req > Mar 31 12:44:02 localhost.localdomain audit[1466]: AVC apparmor="DENIED" > operation="connect" profile="snap.screenly-client.websocket" name="/ > run/dbus/system_bus_socket" pid=1466 comm="python3" requested_mask="wr" > denied_mask="wr" > > I am not sure if I need to use some additional interfaces - to get it > working under devmode I've used the following code (And I can't find > anything relevant in wiki): > > playlist: > command: usr/bin/playlist-service.sh > daemon: simple > plugs: [network-bind, network] > slots: [playlist-dbus-server] > > websocket: > command: usr/bin/websocket-service.sh > daemon: simple > plugs: [network-bind, network, playlist-dbus-client] > > slots: > playlist-dbus-server: > interface: dbus > name: com.screenly.playlist > bus: system > > plugs: > playlist-dbus-client: > interface: dbus > name: com.screenly.playlist > bus: system > From jamie at canonical.com Mon Apr 3 13:58:52 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 03 Apr 2017 08:58:52 -0500 Subject: Issues using dbus in strict In-Reply-To: References: Message-ID: <1491227932.3689.1.camel@canonical.com> On Fri, 2017-03-31 at 17:55 +0300, Sergey Borovkov wrote: ... > Mar 31 12:44:02 localhost.localdomain kernel: audit: type=1400 > audit(1490964242.523:72): apparmor="DENIED" operation="connect" profile= > "snap.screenly-client.websocket" name="/run/dbus/system_bus_socket" > pid=1466 comm="python3" req > Mar 31 12:44:02 localhost.localdomain audit[1466]: AVC apparmor="DENIED" > operation="connect" profile="snap.screenly-client.websocket" name="/ > run/dbus/system_bus_socket" pid=1466 comm="python3" requested_mask="wr" > denied_mask="wr" > > I am not sure if I need to use some additional interfaces - to get it > working under devmode I've used the following code (And I can't find > anything relevant in wiki): > >   playlist: >     command: usr/bin/playlist-service.sh >     daemon: simple >     plugs: [network-bind, network] >     slots: [playlist-dbus-server] > >   websocket: >     command: usr/bin/websocket-service.sh >     daemon: simple >     plugs: [network-bind, network, playlist-dbus-client] > > slots: >   playlist-dbus-server: >     interface: dbus >     name: com.screenly.playlist >     bus: system > > plugs: >   playlist-dbus-client: >     interface: dbus >     name: com.screenly.playlist >     bus: system You shouldn't need additional interfaces. It sounds like your interfaces are not connected. What is the output of 'snap interfaces'? -- 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 serge.borovkov at gmail.com Mon Apr 3 14:57:06 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Mon, 3 Apr 2017 17:57:06 +0300 Subject: Issues using dbus in strict In-Reply-To: <1491227932.3689.1.camel@canonical.com> References: <1491227932.3689.1.camel@canonical.com> Message-ID: Hi, I manually connected interfaces. But the issue is that it can't even connect to system bus? Before trying to call any methods. root at localhost:/home/pi# snap interfaces Slot Plug :account-control - :alsa - :autopilot-introspection - :bluetooth-control - :browser-support screenly-client:browser-support-plug :camera - :classic-support - :core-support core :dcdbas-control - :docker-support - :firewall-control - :framebuffer screenly-client :fuse-support - :hardware-observe - :home - :io-ports-control - :kernel-module-control - :locale-control - :log-observe screenly-client :lxd-support - :mount-observe - :network screenly-client,screenly-pi3 :network-bind core,screenly-client :network-control - :network-observe - :network-setup-control - :network-setup-observe - :opengl screenly-client :openvswitch-support - :physical-memory-control - :physical-memory-observe - :ppp - :process-control - :raw-usb - :removable-media - :shutdown - :snapd-control - :system-observe - :system-trace - :time-control - :timeserver-control - :timezone-control - :tpm - :uhid - screenly-client:playlist-dbus-server screenly-client:playlist-dbus-client screenly-pi3:bcm-gpio-0 - screenly-pi3:bcm-gpio-1 - screenly-pi3:bcm-gpio-10 - screenly-pi3:bcm-gpio-11 - screenly-pi3:bcm-gpio-12 - screenly-pi3:bcm-gpio-13 - screenly-pi3:bcm-gpio-14 - screenly-pi3:bcm-gpio-15 - screenly-pi3:bcm-gpio-16 - screenly-pi3:bcm-gpio-17 - screenly-pi3:bcm-gpio-18 - screenly-pi3:bcm-gpio-19 - screenly-pi3:bcm-gpio-2 - screenly-pi3:bcm-gpio-20 - screenly-pi3:bcm-gpio-21 - screenly-pi3:bcm-gpio-22 - screenly-pi3:bcm-gpio-23 - screenly-pi3:bcm-gpio-24 - screenly-pi3:bcm-gpio-25 - screenly-pi3:bcm-gpio-26 - screenly-pi3:bcm-gpio-3 - screenly-pi3:bcm-gpio-4 - screenly-pi3:bcm-gpio-5 - screenly-pi3:bcm-gpio-6 - screenly-pi3:bcm-gpio-7 - screenly-pi3:bcm-gpio-8 - screenly-pi3:bcm-gpio-9 - - screenly-pi3:snapd-control On 3 April 2017 at 16:58, Jamie Strandboge wrote: > On Fri, 2017-03-31 at 17:55 +0300, Sergey Borovkov wrote: > > ... > > > Mar 31 12:44:02 localhost.localdomain kernel: audit: type=1400 > > audit(1490964242.523:72): apparmor="DENIED" operation="connect" profile= > > "snap.screenly-client.websocket" name="/run/dbus/system_bus_socket" > > pid=1466 comm="python3" req > > Mar 31 12:44:02 localhost.localdomain audit[1466]: AVC apparmor="DENIED" > > operation="connect" profile="snap.screenly-client.websocket" name="/ > > run/dbus/system_bus_socket" pid=1466 comm="python3" requested_mask="wr" > > denied_mask="wr" > > > > I am not sure if I need to use some additional interfaces - to get it > > working under devmode I've used the following code (And I can't find > > anything relevant in wiki): > > > > playlist: > > command: usr/bin/playlist-service.sh > > daemon: simple > > plugs: [network-bind, network] > > slots: [playlist-dbus-server] > > > > websocket: > > command: usr/bin/websocket-service.sh > > daemon: simple > > plugs: [network-bind, network, playlist-dbus-client] > > > > slots: > > playlist-dbus-server: > > interface: dbus > > name: com.screenly.playlist > > bus: system > > > > plugs: > > playlist-dbus-client: > > interface: dbus > > name: com.screenly.playlist > > bus: system > > You shouldn't need additional interfaces. It sounds like your interfaces > are not > connected. What is the output of 'snap interfaces'? > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > 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 Mon Apr 3 16:12:32 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 03 Apr 2017 11:12:32 -0500 Subject: Issues using dbus in strict In-Reply-To: References: <1491227932.3689.1.camel@canonical.com> Message-ID: <1491235952.3689.23.camel@canonical.com> On Mon, 2017-04-03 at 17:57 +0300, Sergey Borovkov wrote: > Hi, I manually connected interfaces. But the issue is that it can't even > connect to system bus? Before trying to call any methods. > I'm slightly confused, so let's back up. It sounds like you are saying that you install the snap and the client isn't allowed to connect to the system bus before the interfaces are connected. Once the interfaces are connected, things work correctly. Is this accurate? If so, this is how the dbus interface is designed. The slots side (the service) is given enough permissions to run at all (eg, to connect to the system bus to bind to the well-known name) and the client has no permissions to use the service until a connection is made. Since your client isn't plugging anything else that uses the system bus, access to the system bus itself will be denied until interfaces that allow access to it are connected (eg, you connect your client to your service). If not, can you please describe the steps taken when you see the issue? > root at localhost:/home/pi# snap interfaces > Slot                                  Plug > :account-control                      - > :alsa                                 - > :autopilot-introspection              - > :bluetooth-control                    - > :browser-support                      screenly-client:browser-support-plug > :camera                               - > :classic-support                      - > :core-support                         core > :dcdbas-control                       - > :docker-support                       - > :firewall-control                     - > :framebuffer                          screenly-client > :fuse-support                         - > :hardware-observe                     - > :home                                 - > :io-ports-control                     - > :kernel-module-control                - > :locale-control                       - > :log-observe                          screenly-client > :lxd-support                          - > :mount-observe                        - > :network                              screenly-client,screenly-pi3 > :network-bind                         core,screenly-client > :network-control                      - > :network-observe                      - > :network-setup-control                - > :network-setup-observe                - > :opengl                               screenly-client > :openvswitch-support                  - > :physical-memory-control              - > :physical-memory-observe              - > :ppp                                  - > :process-control                      - > :raw-usb                              - > :removable-media                      - > :shutdown                             - > :snapd-control                        - > :system-observe                       - > :system-trace                         - > :time-control                         - > :timeserver-control                   - > :timezone-control                     - > :tpm                                  - > :uhid                                 - > screenly-client:playlist-dbus-server  screenly-client:playlist-dbus-client > screenly-pi3:bcm-gpio-0               - > screenly-pi3:bcm-gpio-1               - > screenly-pi3:bcm-gpio-10              - > screenly-pi3:bcm-gpio-11              - > screenly-pi3:bcm-gpio-12              - > screenly-pi3:bcm-gpio-13              - > screenly-pi3:bcm-gpio-14              - > screenly-pi3:bcm-gpio-15              - > screenly-pi3:bcm-gpio-16              - > screenly-pi3:bcm-gpio-17              - > screenly-pi3:bcm-gpio-18              - > screenly-pi3:bcm-gpio-19              - > screenly-pi3:bcm-gpio-2               - > screenly-pi3:bcm-gpio-20              - > screenly-pi3:bcm-gpio-21              - > screenly-pi3:bcm-gpio-22              - > screenly-pi3:bcm-gpio-23              - > screenly-pi3:bcm-gpio-24              - > screenly-pi3:bcm-gpio-25              - > screenly-pi3:bcm-gpio-26              - > screenly-pi3:bcm-gpio-3               - > screenly-pi3:bcm-gpio-4               - > screenly-pi3:bcm-gpio-5               - > screenly-pi3:bcm-gpio-6               - > screenly-pi3:bcm-gpio-7               - > screenly-pi3:bcm-gpio-8               - > screenly-pi3:bcm-gpio-9               - > -                                     screenly-pi3:snapd-control > > > On 3 April 2017 at 16:58, Jamie Strandboge wrote: > > > > > On Fri, 2017-03-31 at 17:55 +0300, Sergey Borovkov wrote: > > > > ... > > > > > > > > Mar 31 12:44:02 localhost.localdomain kernel: audit: type=1400 > > > audit(1490964242.523:72): apparmor="DENIED" operation="connect" profile= > > > "snap.screenly-client.websocket" name="/run/dbus/system_bus_socket" > > > pid=1466 comm="python3" req > > > Mar 31 12:44:02 localhost.localdomain audit[1466]: AVC apparmor="DENIED" > > > operation="connect" profile="snap.screenly-client.websocket" name="/ > > > run/dbus/system_bus_socket" pid=1466 comm="python3" requested_mask="wr" > > > denied_mask="wr" > > > > > > I am not sure if I need to use some additional interfaces - to get it > > > working under devmode I've used the following code (And I can't find > > > anything relevant in wiki): > > > > > >   playlist: > > >     command: usr/bin/playlist-service.sh > > >     daemon: simple > > >     plugs: [network-bind, network] > > >     slots: [playlist-dbus-server] > > > > > >   websocket: > > >     command: usr/bin/websocket-service.sh > > >     daemon: simple > > >     plugs: [network-bind, network, playlist-dbus-client] > > > > > > slots: > > >   playlist-dbus-server: > > >     interface: dbus > > >     name: com.screenly.playlist > > >     bus: system > > > > > > plugs: > > >   playlist-dbus-client: > > >     interface: dbus > > >     name: com.screenly.playlist > > >     bus: system > > You shouldn't need additional interfaces. It sounds like your interfaces > > are not > > connected. What is the output of 'snap interfaces'? > > > > -- > > Jamie Strandboge             | http://www.canonical.com > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/snapcraft > > > > -- 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 corey.bryant at canonical.com Mon Apr 3 17:00:17 2017 From: corey.bryant at canonical.com (Corey Bryant) Date: Mon, 3 Apr 2017 13:00:17 -0400 Subject: Modular Application Updates: Libvirt and QEMU In-Reply-To: References: Message-ID: On Tue, Mar 28, 2017 at 4:26 AM, Christian Ehrhardt < christian.ehrhardt at canonical.com> wrote: > On Mon, Mar 27, 2017 at 9:13 PM, Dmitrii Shcherbakov < > dmitrii.shcherbakov at canonical.com> wrote: > > > > > > TL;DR: Putting libvirt and QEMU into the same snap removes an ability > > to update them independently and only use new QEMU binaries after VM > > shutdown. > > > > [...] > > 7 If a QEMU process is terminated via SIGTERM or SIGKILL, the guest > > kernel page cache and buffer cache will not be dropped which will > > highly likely cause a file system corruption. > > > > There are hooks you can link in yourself for upgrades IIRC. > That could be used to at least gracefully shut them down - but I agree that > there should be no reason to do so at all. > The qemu's should continue to run through and after the update. > > [...] > > > > The idea with any 'classic' package management system (for debs, rpms > > etc.) is as follows: > > > > 1 Updates move new files over the old ones. That is, shared objects > > and binaries are unlinked but not overwritten - if there is still a > > process that has a file open (or mmaped which requires a file to be > > open) an old inode and the related data on a file system is kept until > > the reference count is zero; > > > > 2 Running programs can use old binaries and shared objects which they > > have open until restart > > > > [...] > > > > 1 A new squashfs and an old squash fs are obviously different file > > systems - hence inodes refer to different file systems; > > > > 2 All processes are killed during an update unconditionally and the > > new file system is used to run new processes; > > > > Yeah for server side things with a longer lifecycle that doesn't seem > right. > > > > 3 Some libraries are taken from the core snap's file system which > > remains the same (but may change as the core snap may have been > > updated before while a particular snap used an old version of it). > > > > In some sense the squashfs entry points can be considered your new inode. > All new application starts should be from the new version, but any old > program could continue to run from the old content. > That would be true for core-snap and application snap - only once all old > refs are gone the old version can "really" go away. > > So think of an upgrade: > PRE: content in /snap/app/oldver/foo > UPGRAD adds: /snap/app/newver/foo > UPGRADE changes: /snap/app/current is set to newver > But /snap/app/oldver/foo would stay around and running applications kept > alive. > Only once the last one is gone /snap/app/oldver would completely vanish. > > I like this suggestion. It sounds similar to this, which seems to be how traditional libvirt/qemu packages work: http://unix.stackexchange.com/questions/74142/why-does-a-software-package-run-just-fine-even-when-it-is-being-upgraded Dmitrii, it sound likes without any support like that above, any update to the qemu/libvirt snap would require all VMs to be shut down during the update. Is that right? If so that's going to be a tough situation. Corey > IIRC we keep it around anyway to be able to roll back right [1]? > We already make sure nothing new is started from old. > Maybe it is just a way more advanced garbage collection and a change to the > update behavior to leave things alive. > > > > Also on the "killing on update" as a major change in behavior - and to take > it a bit out of the qemu/libvirt example. > If I watch a movie on one screen in my snap vlc and in another console > would refresh all snaps on my system I'd in no way expect it to kill my > running vid. > I haven't tried, but according to the report here that is what would happen > right? > I'd expect it to continue to run and whenever I start a new vlc next time > it will be the new upgraded one. > BTW - I realized that "snap remove vlc" leaves it alive, so refresh being > harder than remove to a running app seems even more wrong. > > > Thanks for sharing your thoughts Dimitri, I think you uncovered an > important and interesting part of the snap implications which is worth > to be thought through in detail. > I hope the snap'xperts can jump in with a deeper view onto all this - > especially on all the snap vs snap_data considerations that have to go into > this when running from old+new at the same time would become allowed. > > [1]: https://developer.ubuntu.com/en/snappy/guides/garbage/ > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From joseph.wakeling at webdrake.net Mon Apr 3 19:18:37 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 3 Apr 2017 21:18:37 +0200 Subject: Architecture-specific settings for snapcraft parts Message-ID: <0087f355-5b3a-b63e-e817-19b4e89c6a5e@webdrake.net> Hello all, Recently I tried some ARM builds of the LDC snap package, and came across some issues where one of the custom C flags used were not supported: https://launchpadlibrarian.net/313662608/buildlog_snap_ubuntu_xenial_armhf_ldc2_BUILDING.txt.gz Is there any way to customize the settings for parts according to architecture? In this case I'm looking to customize the cmake configflags. I could imagine maybe using a scriptlet to export some environment variable conditional on the architecture, but wondered if anyone else has any ideas. Thanks & best wishes, -- Joe From akgrant0710 at gmail.com Mon Apr 3 19:25:21 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Mon, 3 Apr 2017 19:25:21 +0000 Subject: classic 32 bit application In-Reply-To: References: <20170330213822.GA5109@hunt> Message-ID: <20170403192521.GA125@e01215cbc306> Hi James, Thanks for your reply. On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote: > On 31 March 2017 at 05:38, Seth Arnold wrote: > > On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: > >> I'm trying to package a 32 bit software development environment: Pharo > >> Smalltalk (http://pharo.org). > >> > >> I've got it working OK as a devmode package, but as soon as I switch it > >> to classic confinement it fails to run. > > > > I was under the impression the usual progression is from devmode to > > strict. Are you certain classic is the correct direction for your snap? > > I ran into a similar conundrum for the Python snap I built. If your > package contains a language runtime and interactive shell, it is > difficult to decide what sort of confinement policy makes sense. It > is possible to run under strict confinement with few or any interfaces > connected, but depending on what the user wants to do might want a lot > more permission (e.g. ability to access the network, ability to write > to the home directory, etc). > > At present the best option seems to be to package things with strict > confinement but ensure that it will be functional if installed with > --classic. That gives safety by default, but full functionality on > request. Of course, this means snapcraft isn't giving any help with > the necessary link flags to get things working reliably on non-Ubuntu > systems. I guess that's something to try and solve next. > > James. This is a step closer, but is still problematic as the bin directories (/bin, /usr/bin, etc.) are still mapped to the snapcraft package. Looks like I'll have to wait until the 64 bit version of the application is available. Thanks again, Alistair On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: > Hi All, > > I'm trying to package a 32 bit software development environment: Pharo > Smalltalk (http://pharo.org). > > I've got it working OK as a devmode package, but as soon as I switch it > to classic confinement it fails to run. > > The error message displayed when attempting to run the executable is "No > such file or directory" > > Attempting to print the shared object dependencies from within a snap > shell with ldd results in: > > $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo > not a dynamic executable > > Since the only change is the confinement from devmode to classic and > I've checked that the executable file does actually exist, and it's the > same one as in devmode, my current hypothesis is that somehow the 32 bit > environment isn't working properly in classic mode, probably because it > isn't configured correctly, and not that there's a problem with the > executable. > > Are there any known problems with 32-bit applications and classic > confinement, or anything in particular that needs to be configured for > it to work properly? From serge.borovkov at gmail.com Mon Apr 3 19:57:03 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Mon, 3 Apr 2017 22:57:03 +0300 Subject: Issues using dbus in strict In-Reply-To: <1491235952.3689.23.camel@canonical.com> References: <1491227932.3689.1.camel@canonical.com> <1491235952.3689.23.camel@canonical.com> Message-ID: So once the interfaces are connected the following happens: 1. In websocket service (the one that just calls methods over dbus) I can get system bus without any issues. 2. In the second service, the one that exposes dbus interface I get following exception when running this code: try: bus = SystemBus() bus.publish("com.screenly.playlist", playlist_service) except: log = logging.getLogger('screenly.PlaylistService') log.exception("Unable to register on system bus: ") Apr 03 19:53:49 localhost.localdomain python3[1246]: screenly.PlaylistService Unable to register on system bus: Traceback (most recent call last): File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/bus.py", line 43, in dbus return self._dbus AttributeError: 'Bus' object has no attribute '_dbus' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/snap/screenly-client/x1/lib/python3.5/site-packages/screenly/client/playlist.py", line 605, in main bus.publish("com.screenly.playlist", playlist_service) File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/publication.py", line 42, in publish return Publication(self, bus_name, *objects) File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/publication.py", line 35, in __init__ self._at_exit(bus.request_name(bus_name, allow_replacement=allow_replacement, replace=replace).__exit__) File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/request_name.py", line 29, in request_name return NameOwner(self, name, allow_replacement, replace) File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/request_name.py", line 8, in __init__ res = bus.dbus.RequestName(name, flags) File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/bus.py", line 45, in dbus self._dbus = self.get(".DBus")[""] File "/snap/screenly-client/x1/lib/python3.5/site-packages/pydbus/proxy.py", line 47, in get 0, timeout_to_glib(timeout), None) GLib.GError: g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=" From jamie at canonical.com Mon Apr 3 21:10:15 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 03 Apr 2017 16:10:15 -0500 Subject: Issues using dbus in strict In-Reply-To: References: <1491227932.3689.1.camel@canonical.com> <1491235952.3689.23.camel@canonical.com> Message-ID: <1491253815.3689.25.camel@canonical.com> On Mon, 2017-04-03 at 22:57 +0300, Sergey Borovkov wrote: ...                                   GLib.GError: > g-dbus-error-quark: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: An > AppArmor policy prevents this sender from sending this message to this > recipient; type=" We worked through this on IRC. It was a bug in the dbus interface with the fixed proposed here: https://github.com/snapcore/snapd/pull/3133 -- 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 adam.heavens at falconelectric.co.uk Tue Apr 4 09:54:19 2017 From: adam.heavens at falconelectric.co.uk (Adam Heavens) Date: Tue, 4 Apr 2017 09:54:19 +0000 Subject: Pi3 - Ubuntu Core - mir-kiosk Message-ID: Hello, Looking for a little help, I am trying to install mir-kiosk on Ubuntu core running on a Raspberry Pi3, however I can't get the black window and cursor to start. I pretty sure it is the Raspberry Pi build as I can get it to work in a VM using these instructions https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ After reading the archives of this mailing list I have tried updating all snaps to Edge and re-installed but always get the same error. "Mir returned: Failed to connect to server socket: No such file or directory" Screenshot of syslog below [cid:image001.png at 01D2AD31.CBDE9350] [cid:image002.png at 01D2AD31.CBDE9350] Any help or guidance appreciated Thanks Adam -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 775421 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 61221 bytes Desc: image002.png URL: From james.henstridge at canonical.com Tue Apr 4 10:10:32 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Tue, 4 Apr 2017 18:10:32 +0800 Subject: classic 32 bit application In-Reply-To: <20170403192521.GA125@e01215cbc306> References: <20170330213822.GA5109@hunt> <20170403192521.GA125@e01215cbc306> Message-ID: On 4 April 2017 at 03:25, Alistair Grant wrote: > Hi James, > > Thanks for your reply. > > On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote: >> On 31 March 2017 at 05:38, Seth Arnold wrote: >> > On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: >> >> I'm trying to package a 32 bit software development environment: Pharo >> >> Smalltalk (http://pharo.org). >> >> >> >> I've got it working OK as a devmode package, but as soon as I switch it >> >> to classic confinement it fails to run. >> > >> > I was under the impression the usual progression is from devmode to >> > strict. Are you certain classic is the correct direction for your snap? >> >> I ran into a similar conundrum for the Python snap I built. If your >> package contains a language runtime and interactive shell, it is >> difficult to decide what sort of confinement policy makes sense. It >> is possible to run under strict confinement with few or any interfaces >> connected, but depending on what the user wants to do might want a lot >> more permission (e.g. ability to access the network, ability to write >> to the home directory, etc). >> >> At present the best option seems to be to package things with strict >> confinement but ensure that it will be functional if installed with >> --classic. That gives safety by default, but full functionality on >> request. Of course, this means snapcraft isn't giving any help with >> the necessary link flags to get things working reliably on non-Ubuntu >> systems. I guess that's something to try and solve next. >> >> James. > > This is a step closer, but is still problematic as the bin directories > (/bin, /usr/bin, etc.) are still mapped to the snapcraft package. > > Looks like I'll have to wait until the 64 bit version of the > application is available. If there are particular utilities usually found in /bin or /usr/bin that aren't part of the "core" snap, you will probably need to include them in your own snap. If you still want help with this, it'd be useful to give a link to your in-progress snap or snapcraft project. Without that, it is a bit difficult to tell what is causing the problem. James. From xiaoguo.liu at canonical.com Tue Apr 4 11:39:39 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 4 Apr 2017 19:39:39 +0800 Subject: Issues creating webapps snaps with stric confinement In-Reply-To: References: Message-ID: Hi Winael, Have you seen the tutorial at https://tutorials.ubuntu.com/tutorial/snap-a-website#0? Best regards, XiaoGuo On Fri, Mar 31, 2017 at 9:28 PM, Vincent JOBARD wrote: > Hi Everyone > > I just try to follow the tutorial to learn how to create webapps snaps > using snapcraft. ( > https://developer.ubuntu.com/en/phone/web/ubuntu-webapps-guide/, very nice > tutorial by the way) > > Unfortunately, when I try to create my snap with strict confinement, I have > a network Error page, but all works fine in devmode. > > I'm at work behind a proxy with cntlm authentification. could it be related > ? > > Thx for your answers guys > > Cheers > Winael > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu From akgrant0710 at gmail.com Tue Apr 4 14:53:17 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Tue, 4 Apr 2017 14:53:17 +0000 Subject: classic 32 bit application In-Reply-To: References: <20170330213822.GA5109@hunt> <20170403192521.GA125@e01215cbc306> Message-ID: <20170404145317.GA41@694ff8791ca7> Hi James, Thanks for your follow-up. On Tue, Apr 04, 2017 at 06:10:32PM +0800, James Henstridge wrote: > On 4 April 2017 at 03:25, Alistair Grant wrote: > > Hi James, > > > > On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote: > >> On 31 March 2017 at 05:38, Seth Arnold wrote: > >> > On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: > >> >> I'm trying to package a 32 bit software development environment: Pharo > >> >> Smalltalk (http://pharo.org). > >> >> > >> >> I've got it working OK as a devmode package, but as soon as I switch it > >> >> to classic confinement it fails to run. > >> > > >> > I was under the impression the usual progression is from devmode to > >> > strict. Are you certain classic is the correct direction for your snap? > >> > >> I ran into a similar conundrum for the Python snap I built. If your > >> package contains a language runtime and interactive shell, it is > >> difficult to decide what sort of confinement policy makes sense. It > >> is possible to run under strict confinement with few or any interfaces > >> connected, but depending on what the user wants to do might want a lot > >> more permission (e.g. ability to access the network, ability to write > >> to the home directory, etc). > >> > >> At present the best option seems to be to package things with strict > >> confinement but ensure that it will be functional if installed with > >> --classic. That gives safety by default, but full functionality on > >> request. Of course, this means snapcraft isn't giving any help with > >> the necessary link flags to get things working reliably on non-Ubuntu > >> systems. I guess that's something to try and solve next. > >> > >> James. > > > > This is a step closer, but is still problematic as the bin directories > > (/bin, /usr/bin, etc.) are still mapped to the snapcraft package. > > > > Looks like I'll have to wait until the 64 bit version of the > > application is available. > > If there are particular utilities usually found in /bin or /usr/bin > that aren't part of the "core" snap, you will probably need to include > them in your own snap. If you still want help with this, it'd be > useful to give a link to your in-progress snap or snapcraft project. > Without that, it is a bit difficult to tell what is causing the > problem. OK, thanks for the clarification. The real problem is that I'm unable to get a 32 bit application working with classic confinement. The application runs fine in devmode, but building with classic confinement and running produces: $ pharo --version /snap/pharo/x1/usr/bin/pharo: line 13: /snap/pharo/x1/usr/bin/pharo-vm/pharo: No such file or directory $ ls -l /snap/pharo/x1/usr/bin/pharo-vm/pharo -rwxr-xr-x 1 root root 4599008 Apr 4 15:15 /snap/pharo/x1/usr/bin/pharo-vm/pharo $ snap run --shell pharo $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo not a dynamic executable My guess is that I've either configured it incorrectly, or for some reason the 32 bit architecture isn't working in classic confinement. The project is at: https://github.com/akgrant43/pharo-snap I'm just changing the confinement to classic to reproduce the problems. (A bit of a disclaimer, this is my first snapcraft project and I'm not familiar with the pharo build process, so the whole thing is still a work-in-progress, and needs plenty of tidying up :-)). Thanks again, Alistair From sergio.schvezov at canonical.com Tue Apr 4 15:17:05 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 4 Apr 2017 15:17:05 +0000 Subject: classic 32 bit application In-Reply-To: <20170404145317.GA41@694ff8791ca7> References: <20170330213822.GA5109@hunt> <20170403192521.GA125@e01215cbc306> <20170404145317.GA41@694ff8791ca7> Message-ID: <2u1tvs.onw54u.1hge199-qmf@smtp.googlemail.com> On Tue, 4 Apr 2017 14:53:17 +0000, Alistair Grant wrote: > Hi James, > > Thanks for your follow-up. > > On Tue, Apr 04, 2017 at 06:10:32PM +0800, James Henstridge wrote: >> On 4 April 2017 at 03:25, Alistair Grant wrote: >> > Hi James, >> > >> > On Fri, Mar 31, 2017 at 03:08:39PM +0800, James Henstridge wrote: >> >> On 31 March 2017 at 05:38, Seth Arnold >> wrote: >> >> > On Thu, Mar 30, 2017 at 08:10:26AM +0200, Alistair Grant wrote: >> >> >> I'm trying to package a 32 bit software development >> environment: Pharo >> >> >> Smalltalk (http://pharo.org). >> >> >> >> >> >> I've got it working OK as a devmode package, but as soon >> as I switch it >> >> >> to classic confinement it fails to run. >> >> > >> >> > I was under the impression the usual progression is from devmode to >> >> > strict. Are you certain classic is the correct direction >> for your snap? >> >> >> >> I ran into a similar conundrum for the Python snap I built. If your >> >> package contains a language runtime and interactive shell, it is >> >> difficult to decide what sort of confinement policy makes sense. It >> >> is possible to run under strict confinement with few or any interfaces >> >> connected, but depending on what the user wants to do might want a lot >> >> more permission (e.g. ability to access the network, ability to write >> >> to the home directory, etc). >> >> >> >> At present the best option seems to be to package things with strict >> >> confinement but ensure that it will be functional if installed with >> >> --classic. That gives safety by default, but full functionality on >> >> request. Of course, this means snapcraft isn't giving any help with >> >> the necessary link flags to get things working reliably on non-Ubuntu >> >> systems. I guess that's something to try and solve next. >> >> >> >> James. >> > >> > This is a step closer, but is still problematic as the bin directories >> > (/bin, /usr/bin, etc.) are still mapped to the snapcraft package. >> > >> > Looks like I'll have to wait until the 64 bit version of the >> > application is available. >> >> If there are particular utilities usually found in /bin or /usr/bin >> that aren't part of the "core" snap, you will probably need to include >> them in your own snap. If you still want help with this, it'd be >> useful to give a link to your in-progress snap or snapcraft project. >> Without that, it is a bit difficult to tell what is causing the >> problem. > > OK, thanks for the clarification. > > The real problem is that I'm unable to get a 32 bit application working > with classic confinement. > > The application runs fine in devmode, but building with classic > confinement and running produces: > > $ pharo --version > /snap/pharo/x1/usr/bin/pharo: line 13: > /snap/pharo/x1/usr/bin/pharo-vm/pharo: No such file or directory > $ ls -l /snap/pharo/x1/usr/bin/pharo-vm/pharo > -rwxr-xr-x 1 root root 4599008 Apr 4 15:15 > /snap/pharo/x1/usr/bin/pharo-vm/pharo > $ snap run --shell pharo > $ ldd /snap/pharo/x1/usr/bin/pharo-vm/pharo > not a dynamic executable > > My guess is that I've either configured it incorrectly, or for some > reason the 32 bit architecture isn't working in classic confinement. I am not sure how the low levels work here wrt to program loaders and 32bit versus 64bit support, if they are different, there is currently no support in snapcraft for this, which for classic confined snaps sets the program loader to a specific binary, you can of course override this with a combination of LDFLAGS to set the loader to something more appropriate (just make sure the loader comes from the core snap or you won't be cross distro or even cross series on Ubuntu). > The project is at: https://github.com/akgrant43/pharo-snap > I'm just changing the confinement to classic to reproduce the problems. You can't just switch the confinement value, you will need to rebuild. > (A bit of a disclaimer, this is my first snapcraft project and I'm not > familiar with the pharo build process, so the whole thing is still a > work-in-progress, and needs plenty of tidying up :-)). When going classic you might need more knowledge of how everything is connected and linked though. Even with a code base I know I ran into things like this https://forum.snapcraft.io/t/classic-snaps-and-python/141 -- Sent using Dekko from my Ubuntu device From jamie.bennett at canonical.com Tue Apr 4 15:19:51 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Tue, 4 Apr 2017 16:19:51 +0100 Subject: snapd 2.23.6 released to the stable channel Message-ID: Hi, The snappy team is happy to announce another release of the 2.23.6 series. This release focuses on improving the robustness of the configuration hook system. The new release is available in the core snap in the stable channel and should be making it’s way to you soon automatically. It is also available in the 14.04, 16.04, 16.10 and 17.04 proposed pockets. More distributions will follow at their own pace. To install this new release just run the following command: $ sudo snap refresh core Or wait for an automatic refresh. On the classic distribution you can also enable -proposed (see https://wiki.ubuntu.com/Testing/EnableProposed1) and install snapd from there. The changes in detail: • tests: fix interfaces-cups-control for zesty • configstate,hookstate: timeout the configure hook after 5 mins, report failures • packaging: rename the file shipping snap-confine AA profile to workaround dpkg bug #858004 • many: ignore configure hook failures on core refresh to ensure upgrades are always possible • snapstate: restart as needed if we undid unlinking aka relinked core or kernel snap • support for snap core set pi-config.framebuffer_{width,height} (and a bunch more, seehttps://forum.snapcraft.io/t/configuration-options-for-core-snap/87 for all options) config.txt setting The source is available at https://github.com/snapcore/snapd/releases/tag/2.23.69, with test results and more discussion at: https://forum.snapcraft.io/t/new-release-snapd-2-23-6/26 Enjoy and let us know if you notice any issues. Regards, The snapd release team. From kevin.gunn at canonical.com Tue Apr 4 16:18:43 2017 From: kevin.gunn at canonical.com (Kevin Gunn) Date: Tue, 4 Apr 2017 11:18:43 -0500 Subject: Pi3 - Ubuntu Core - mir-kiosk In-Reply-To: References: Message-ID: Hey Adam, First, Thanks for trying it out! sorry you're having trouble. Myself and some other folks have just tried out the pi3 with mir-kiosk and all seems to be working without issue on our end. Our one guess is potentially related to your display setup... But the best way to proceed would be to file a bug & attach your whole syslog there. Email threads tend to be messy for debugging. You can log a bug for us at https://bugs.launchpad.net/mir/+filebug Then we can capture all the discussion, logs, etc to see what might be the issue. Thanks, kg On Tue, Apr 4, 2017 at 4:54 AM, Adam Heavens < adam.heavens at falconelectric.co.uk> wrote: > Hello, > > Looking for a little help, I am trying to install mir-kiosk on Ubuntu core > running on a Raspberry Pi3, however I can't get the black window and cursor > to start. I pretty sure it is the Raspberry Pi build as I can get it to > work in a VM using these instructions > > https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ > > After reading the archives of this mailing list I have tried updating all > snaps to Edge and re-installed but always get the same error. > > "Mir returned: Failed to connect to server socket: No such file or > directory" > > Screenshot of syslog below > > [cid:image001.png at 01D2AD31.CBDE9350] > > [cid:image002.png at 01D2AD31.CBDE9350] > > > Any help or guidance appreciated > > Thanks > > Adam > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > From loic.minier at ubuntu.com Tue Apr 4 16:19:50 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 4 Apr 2017 18:19:50 +0200 Subject: classic 32 bit application In-Reply-To: <20170404145317.GA41@694ff8791ca7> References: <20170330213822.GA5109@hunt> <20170403192521.GA125@e01215cbc306> <20170404145317.GA41@694ff8791ca7> Message-ID: Hi! On Tue, Apr 4, 2017 at 4:53 PM, Alistair Grant wrote: > The project is at: https://github.com/akgrant43/pharo-snap > I gave this a quick build-try, but build failed in the pharo part with this tail in build.log: Set up version info... Add PharoV50.sources... cp: cannot stat 'PharoV50.sources': No such file or directory Looking at the error you're getting, first check if you're running ldd against a shell script or an ELF file; it should work against a 32-bits ELF. I did manage to bundle a prebuilt 32-bits app in an amd64 snap here: https://github.com/lool/quortus-epc-snap/blob/master/snap/snapcraft.yaml and it basically just involved shipping libc6:i386 in the snap, so double-check that the runtime linker (/lib/ld-linux.so.2) and all dependent 32-bits libraries are in the snap and in the search path. If the runtime linker can't be found for some reason, create your own wrapper to launch your executable by calling the runtime linker directly (run "/lib/ld-linux.so.2" to get help output or see man page). Hope this helps! - Loïc Minier From adam.heavens at falconelectric.co.uk Tue Apr 4 18:35:29 2017 From: adam.heavens at falconelectric.co.uk (Adam Heavens) Date: Tue, 4 Apr 2017 18:35:29 +0000 Subject: Pi3 - Ubuntu Core - mir-kiosk In-Reply-To: References: Message-ID: Thank you Kevin, I have logged a bug report as suggested, logged under reference #1679801 Thanks Adam -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Kevin Gunn Sent: 04 April 2017 17:19 To: Snapcraft Subject: Re: Pi3 - Ubuntu Core - mir-kiosk Hey Adam, First, Thanks for trying it out! sorry you're having trouble. Myself and some other folks have just tried out the pi3 with mir-kiosk and all seems to be working without issue on our end. Our one guess is potentially related to your display setup... But the best way to proceed would be to file a bug & attach your whole syslog there. Email threads tend to be messy for debugging. You can log a bug for us at https://bugs.launchpad.net/mir/+filebug Then we can capture all the discussion, logs, etc to see what might be the issue. Thanks, kg On Tue, Apr 4, 2017 at 4:54 AM, Adam Heavens < adam.heavens at falconelectric.co.uk> wrote: > Hello, > > Looking for a little help, I am trying to install mir-kiosk on Ubuntu > core running on a Raspberry Pi3, however I can't get the black window > and cursor to start. I pretty sure it is the Raspberry Pi build as I > can get it to work in a VM using these instructions > > https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ > > After reading the archives of this mailing list I have tried updating > all snaps to Edge and re-installed but always get the same error. > > "Mir returned: Failed to connect to server socket: No such file or > directory" > > Screenshot of syslog below > > [cid:image001.png at 01D2AD31.CBDE9350] > > [cid:image002.png at 01D2AD31.CBDE9350] > > > Any help or guidance appreciated > > Thanks > > Adam > > > -- > 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 From akgrant0710 at gmail.com Wed Apr 5 06:53:43 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Wed, 5 Apr 2017 06:53:43 +0000 Subject: classic 32 bit application In-Reply-To: References: <20170330213822.GA5109@hunt> <20170403192521.GA125@e01215cbc306> <20170404145317.GA41@694ff8791ca7> Message-ID: <20170405065343.GA144@99a69969fb86> Hi Loic & Sergio, On Tue, Apr 04, 2017 at 06:19:50PM +0200, Lo??c Minier wrote: > Hi! > > ... > > If the runtime > linker can't be found for some reason, create your own wrapper to launch > your executable by calling the runtime linker directly (run > "/lib/ld-linux.so.2" to get help output or see man page). Thank you! Not finding the loader was the problem. I think this makes sense since classic confinement only mounts the bin directories from the snap packages, other directories, e.g. /lib, use the host directory. Just for the record, the following works for me: $ export HOSTFS=$SNAP $ export LD_LIBRARY_PATH="$HOSTFS/usr/lib/i386-linux-gnu/libfakeroot:$HOSTFS/usr/local/lib:$HOSTFS/lib/i386-linux-gnu:$HOSTFS/usr/lib/i386-linux-gnu:$HOSTFS/usr/lib/i386-linux-gnu/mesa-egl:$HOSTFS/usr/lib/i386-linux-gnu/mesa:$HOSTFS/lib32:$HOSTFS/usr/lib32:$LD_LIBRARY_PATH" $ export PATH="$HOSTFS/usr/local/sbin:$HOSTFS/usr/local/bin:$HOSTFS/usr/sbin:$HOSTFS/usr/bin:$HOSTFS/sbin:$HOSTFS/bin:$HOSTFS/usr/games:$HOSTFS/usr/local/games:$PATH" $ $SNAP/lib/ld-linux.so.2 $SNAP/usr/bin/pharo-vm/pharo --version On Tue, Apr 04, 2017 at 03:17:05PM +0000, Sergio Schvezov wrote: > I am not sure how the low levels work here wrt to program loaders and > 32bit versus 64bit support, if they are different, there is currently > no support in snapcraft for this, which for classic confined snaps > sets the program loader to a specific binary, you can of course > override this with a combination of LDFLAGS to set the loader to > something more appropriate (just make sure the loader comes from the > core snap or you won't be cross distro or even cross series on > Ubuntu). This is what I'll try next. pharo isn't working properly at the moment because it looks for files relative to the executable, and manually loading pharo using ld-linux.so.2 is confusing that code. But this needs further investigation on my part (just setting the dynamic-linker in LDFLAGS isn't working). > > The project is at: https://github.com/akgrant43/pharo-snap > > I'm just changing the confinement to classic to reproduce the problems. > > You can't just switch the confinement value, you will need to rebuild. Yep, I'm doing this. Thanks again, Alistair From adam.heavens at falconelectric.co.uk Wed Apr 5 16:43:56 2017 From: adam.heavens at falconelectric.co.uk (Adam Heavens) Date: Wed, 5 Apr 2017 16:43:56 +0000 Subject: snapcraft mir-kiosk-apps errno 21 Message-ID: Hi, Thanks to the mailing list and bug report I am now able to run mir-kiosk. Thank you again for your help with that. I am now working on the next step of our POC which is developing a Qt based app running on mir-kiosk. I am looking to modify the mir-kiosk-apps demo to start with to learn more about Qt, mir and creating/updating snaps. First I wanted to create a snap without any modifications, However I can't get the snap to generate using the following instructions $ git clone -b master https://git.launchpad.net/mir-kiosk-apps $ cd mir-kiosk-apps $ snapcraft This results in the following errno21 message rather than generating a .snap Skipping stage mir-demos (already ran) Skipping pull qmldemo (already ran) Skipping build qmldemo (already ran) Skipping stage qmldemo (already ran) Skipping prime qmldemo (already ran) Skipping pull qtubuntu (already ran) Skipping build qtubuntu (already ran) Skipping stage qtubuntu (already ran) Skipping pull qt-examples (already ran) Skipping build qt-examples (already ran) Skipping stage qt-examples (already ran) Skipping pull qtchooser-config (already ran) Skipping build qtchooser-config (already ran) Skipping stage qtchooser-config (already ran) Skipping prime qtchooser-config (already ran) Skipping pull glue (already ran) Skipping build glue (already ran) Skipping stage glue (already ran) Priming inotify-tools Priming app-wrappers Priming mir-demos Priming qtubuntu [Errno 21] Is a directory: '/home/adamheavens/mir-kiosk-apps/prime/etc/xdg' What am I doing wrong? Thanks Adam From pat.mcgowan at canonical.com Wed Apr 5 17:33:34 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Wed, 5 Apr 2017 13:33:34 -0400 Subject: snapcraft mir-kiosk-apps errno 21 In-Reply-To: References: Message-ID: It built fine here on Xenial. Did it fail the same way on the previous run? What happens if you "snapcraft clean" and "snapcraft"? Which version is your desktop? What version of snapcraft? Pat On Wed, Apr 5, 2017 at 12:43 PM, Adam Heavens < adam.heavens at falconelectric.co.uk> wrote: > Hi, > > Thanks to the mailing list and bug report I am now able to run mir-kiosk. > Thank you again for your help with that. > > I am now working on the next step of our POC which is developing a Qt > based app running on mir-kiosk. I am looking to modify the mir-kiosk-apps > demo to start with to learn more about Qt, mir and creating/updating snaps. > > First I wanted to create a snap without any modifications, However I can't > get the snap to generate using the following instructions > > $ git clone -b master https://git.launchpad.net/mir-kiosk-apps > $ cd mir-kiosk-apps > $ snapcraft > > This results in the following errno21 message rather than generating a > .snap > > Skipping stage mir-demos (already ran) > Skipping pull qmldemo (already ran) > Skipping build qmldemo (already ran) > Skipping stage qmldemo (already ran) > Skipping prime qmldemo (already ran) > Skipping pull qtubuntu (already ran) > Skipping build qtubuntu (already ran) > Skipping stage qtubuntu (already ran) > Skipping pull qt-examples (already ran) > Skipping build qt-examples (already ran) > Skipping stage qt-examples (already ran) > Skipping pull qtchooser-config (already ran) > Skipping build qtchooser-config (already ran) > Skipping stage qtchooser-config (already ran) > Skipping prime qtchooser-config (already ran) > Skipping pull glue (already ran) > Skipping build glue (already ran) > Skipping stage glue (already ran) > Priming inotify-tools > Priming app-wrappers > Priming mir-demos > Priming qtubuntu > [Errno 21] Is a directory: '/home/adamheavens/mir-kiosk- > apps/prime/etc/xdg' > > What am I doing wrong? > > Thanks > > Adam > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From adam.heavens at falconelectric.co.uk Wed Apr 5 17:54:37 2017 From: adam.heavens at falconelectric.co.uk (Adam Heavens) Date: Wed, 5 Apr 2017 17:54:37 +0000 Subject: snapcraft mir-kiosk-apps errno 21 In-Reply-To: References: Message-ID: Thanks Pat, I am using 16.10, I will build a 16.04 VM and try on that I have version 2.28+16.10 of Snapcraft installed I get the same error message if I do a fresh git clone or rerun and Snapcraft clean and then snapcraft produces the same error message. Thanks Adam -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Pat McGowan Sent: 05 April 2017 18:34 To: Snapcraft Subject: Re: snapcraft mir-kiosk-apps errno 21 It built fine here on Xenial. Did it fail the same way on the previous run? What happens if you "snapcraft clean" and "snapcraft"? Which version is your desktop? What version of snapcraft? Pat On Wed, Apr 5, 2017 at 12:43 PM, Adam Heavens < adam.heavens at falconelectric.co.uk> wrote: > Hi, > > Thanks to the mailing list and bug report I am now able to run mir-kiosk. > Thank you again for your help with that. > > I am now working on the next step of our POC which is developing a Qt > based app running on mir-kiosk. I am looking to modify the > mir-kiosk-apps demo to start with to learn more about Qt, mir and creating/updating snaps. > > First I wanted to create a snap without any modifications, However I > can't get the snap to generate using the following instructions > > $ git clone -b master https://git.launchpad.net/mir-kiosk-apps > $ cd mir-kiosk-apps > $ snapcraft > > This results in the following errno21 message rather than generating a > .snap > > Skipping stage mir-demos (already ran) Skipping pull qmldemo (already > ran) Skipping build qmldemo (already ran) Skipping stage qmldemo > (already ran) Skipping prime qmldemo (already ran) Skipping pull > qtubuntu (already ran) Skipping build qtubuntu (already ran) Skipping > stage qtubuntu (already ran) Skipping pull qt-examples (already ran) > Skipping build qt-examples (already ran) Skipping stage qt-examples > (already ran) Skipping pull qtchooser-config (already ran) Skipping > build qtchooser-config (already ran) Skipping stage qtchooser-config > (already ran) Skipping prime qtchooser-config (already ran) Skipping > pull glue (already ran) Skipping build glue (already ran) Skipping > stage glue (already ran) Priming inotify-tools Priming app-wrappers > Priming mir-demos Priming qtubuntu [Errno 21] Is a directory: > '/home/adamheavens/mir-kiosk- apps/prime/etc/xdg' > > What am I doing wrong? > > Thanks > > Adam > -- > 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 From adam.heavens at falconelectric.co.uk Wed Apr 5 18:46:32 2017 From: adam.heavens at falconelectric.co.uk (Adam Heavens) Date: Wed, 5 Apr 2017 18:46:32 +0000 Subject: snapcraft mir-kiosk-apps errno 21 In-Reply-To: References: Message-ID: Created a 16.04 VM and get the similar error message for another directory this time Building qmldemo Preparing to build qt-examples Building qt-examples Preparing to build qtchooser-config Building qtchooser-config Preparing to build qtubuntu Building qtubuntu Staging mir-demos Staging inotify-tools Staging app-wrappers Staging glue Staging qmldemo Staging qt-examples Staging qtchooser-config Staging qtubuntu Priming mir-demos Priming inotify-tools Priming app-wrappers Priming glue Priming qmldemo Priming qt-examples [Errno 2] No such file or directory: '/home/adamheavens/mir-kiosk-apps/stage/qt-demos/photoviewer/photoviewer' adamheavens at ubuntu:~/mir-kiosk-apps$ adamheavens at ubuntu:~/mir-kiosk-apps$ apt-cache policy snapcraft snapcraft: Installed: 2.28 Candidate: 2.28 Thanks Adam -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Adam Heavens Sent: 05 April 2017 18:55 To: Snapcraft Subject: RE: snapcraft mir-kiosk-apps errno 21 [This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] Thanks Pat, I am using 16.10, I will build a 16.04 VM and try on that I have version 2.28+16.10 of Snapcraft installed I get the same error message if I do a fresh git clone or rerun and Snapcraft clean and then snapcraft produces the same error message. Thanks Adam -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Pat McGowan Sent: 05 April 2017 18:34 To: Snapcraft Subject: Re: snapcraft mir-kiosk-apps errno 21 It built fine here on Xenial. Did it fail the same way on the previous run? What happens if you "snapcraft clean" and "snapcraft"? Which version is your desktop? What version of snapcraft? Pat On Wed, Apr 5, 2017 at 12:43 PM, Adam Heavens < adam.heavens at falconelectric.co.uk> wrote: > Hi, > > Thanks to the mailing list and bug report I am now able to run mir-kiosk. > Thank you again for your help with that. > > I am now working on the next step of our POC which is developing a Qt > based app running on mir-kiosk. I am looking to modify the > mir-kiosk-apps demo to start with to learn more about Qt, mir and creating/updating snaps. > > First I wanted to create a snap without any modifications, However I > can't get the snap to generate using the following instructions > > $ git clone -b master https://git.launchpad.net/mir-kiosk-apps > $ cd mir-kiosk-apps > $ snapcraft > > This results in the following errno21 message rather than generating a > .snap > > Skipping stage mir-demos (already ran) Skipping pull qmldemo (already > ran) Skipping build qmldemo (already ran) Skipping stage qmldemo > (already ran) Skipping prime qmldemo (already ran) Skipping pull > qtubuntu (already ran) Skipping build qtubuntu (already ran) Skipping > stage qtubuntu (already ran) Skipping pull qt-examples (already ran) > Skipping build qt-examples (already ran) Skipping stage qt-examples > (already ran) Skipping pull qtchooser-config (already ran) Skipping > build qtchooser-config (already ran) Skipping stage qtchooser-config > (already ran) Skipping prime qtchooser-config (already ran) Skipping > pull glue (already ran) Skipping build glue (already ran) Skipping > stage glue (already ran) Priming inotify-tools Priming app-wrappers > Priming mir-demos Priming qtubuntu [Errno 21] Is a directory: > '/home/adamheavens/mir-kiosk- apps/prime/etc/xdg' > > What am I doing wrong? > > Thanks > > Adam > -- > 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 -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From joseph.wakeling at webdrake.net Wed Apr 5 20:41:27 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 5 Apr 2017 22:41:27 +0200 Subject: Error with Launchpad uploading 403 Client Error: Forbidden Message-ID: Hello all, Recently I was able to successfully set up Launchpad builds for my ldc2 snap. However, auto-upload to the store failed with a 403 Client Error: Forbidden. The error messages are no more informative than this, so anyone have any idea what's going on? Note that I haven't specified any particular channels or tracks to release to, since I assumed there was a difference between uploading and releasing. Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Wed Apr 5 20:45:13 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Wed, 5 Apr 2017 22:45:13 +0200 Subject: Tracks for ldc2 snap package Message-ID: <9f3fef76-b49f-c587-4127-696b3fbab0dd@webdrake.net> Hello all, If I understand https://snapcraft.io/docs/reference/channels right, I'm supposed to ask here about this -- please let me know if I'm wrong :-) Could I please request for two tracks, named 1.1 and 1.2, to be enabled for the ldc2 snap package? Thanks and best wishes, -- Joe From pat.mcgowan at canonical.com Wed Apr 5 21:05:34 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Wed, 5 Apr 2017 17:05:34 -0400 Subject: snapcraft mir-kiosk-apps errno 21 In-Reply-To: References: Message-ID: Adam I'd suggest you get on either https://rocket.ubuntu.com/channel/snapcraft or IRC to enlist some help debugging it. Pat On Wed, Apr 5, 2017 at 2:46 PM, Adam Heavens < adam.heavens at falconelectric.co.uk> wrote: > Created a 16.04 VM and get the similar error message for another directory > this time > > Building qmldemo > Preparing to build qt-examples > Building qt-examples > Preparing to build qtchooser-config > Building qtchooser-config > Preparing to build qtubuntu > Building qtubuntu > Staging mir-demos > Staging inotify-tools > Staging app-wrappers > Staging glue > Staging qmldemo > Staging qt-examples > Staging qtchooser-config > Staging qtubuntu > Priming mir-demos > Priming inotify-tools > Priming app-wrappers > Priming glue > Priming qmldemo > Priming qt-examples > [Errno 2] No such file or directory: '/home/adamheavens/mir-kiosk- > apps/stage/qt-demos/photoviewer/photoviewer' > adamheavens at ubuntu:~/mir-kiosk-apps$ > > adamheavens at ubuntu:~/mir-kiosk-apps$ apt-cache policy snapcraft > snapcraft: > Installed: 2.28 > Candidate: 2.28 > > Thanks > > Adam > > -----Original Message----- > From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces@ > lists.snapcraft.io] On Behalf Of Adam Heavens > Sent: 05 April 2017 18:55 > To: Snapcraft > Subject: RE: snapcraft mir-kiosk-apps errno 21 > > [This sender failed our fraud detection checks and may not be who they > appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing] > > Thanks Pat, > > I am using 16.10, I will build a 16.04 VM and try on that > > I have version 2.28+16.10 of Snapcraft installed > > I get the same error message if I do a fresh git clone or rerun and > Snapcraft clean and then snapcraft produces the same error message. > > Thanks > > Adam > > -----Original Message----- > From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces@ > lists.snapcraft.io] On Behalf Of Pat McGowan > Sent: 05 April 2017 18:34 > To: Snapcraft > Subject: Re: snapcraft mir-kiosk-apps errno 21 > > It built fine here on Xenial. > Did it fail the same way on the previous run? What happens if you > "snapcraft clean" and "snapcraft"? > Which version is your desktop? > What version of snapcraft? > > Pat > > On Wed, Apr 5, 2017 at 12:43 PM, Adam Heavens < > adam.heavens at falconelectric.co.uk> wrote: > > > Hi, > > > > Thanks to the mailing list and bug report I am now able to run mir-kiosk. > > Thank you again for your help with that. > > > > I am now working on the next step of our POC which is developing a Qt > > based app running on mir-kiosk. I am looking to modify the > > mir-kiosk-apps demo to start with to learn more about Qt, mir and > creating/updating snaps. > > > > First I wanted to create a snap without any modifications, However I > > can't get the snap to generate using the following instructions > > > > $ git clone -b master https://git.launchpad.net/mir-kiosk-apps > > $ cd mir-kiosk-apps > > $ snapcraft > > > > This results in the following errno21 message rather than generating a > > .snap > > > > Skipping stage mir-demos (already ran) Skipping pull qmldemo (already > > ran) Skipping build qmldemo (already ran) Skipping stage qmldemo > > (already ran) Skipping prime qmldemo (already ran) Skipping pull > > qtubuntu (already ran) Skipping build qtubuntu (already ran) Skipping > > stage qtubuntu (already ran) Skipping pull qt-examples (already ran) > > Skipping build qt-examples (already ran) Skipping stage qt-examples > > (already ran) Skipping pull qtchooser-config (already ran) Skipping > > build qtchooser-config (already ran) Skipping stage qtchooser-config > > (already ran) Skipping prime qtchooser-config (already ran) Skipping > > pull glue (already ran) Skipping build glue (already ran) Skipping > > stage glue (already ran) Priming inotify-tools Priming app-wrappers > > Priming mir-demos Priming qtubuntu [Errno 21] Is a directory: > > '/home/adamheavens/mir-kiosk- apps/prime/etc/xdg' > > > > What am I doing wrong? > > > > Thanks > > > > Adam > > -- > > 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 > > -- > 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 > From timonmailinglist at gmail.com Thu Apr 6 07:14:47 2017 From: timonmailinglist at gmail.com (=?UTF-8?Q?Simon_St=c3=bcrz?=) Date: Thu, 6 Apr 2017 09:14:47 +0200 Subject: ubuntu core + snap + gpios In-Reply-To: <1484732031.4288.1.camel@ubuntu.com> References: <1484732031.4288.1.camel@ubuntu.com> Message-ID: Hi, are there any updates on this? I am facing the same issue with snapd running on debian armhf! Is this a snapd bug or a core snap issue? Also the serial-port interface and i2c interface are missing. My snap is blocked :-( Thanks in advance, Simon On 2017-01-18 10:33, Oliver Grawert wrote: > hi, > Am Dienstag, den 17.01.2017, 23:31 +0000 schrieb Luís Martins: >> Hi, I was trying to build a simple snap to test the ubuntu core >> raspberry pi 3 gpios [1] but for some reason the app does not seem >> allowed to write into /sys/class/gpio/ within my snap. >> >> I declared the "plugs: [gpio]" in the snapcraft.yaml and the app is a >> simple qt5/c++ program using std::ifstream/std::ofstream to >> read/write to the files. >> >> However, using the latest stable ubuntu core image, the "snap >> interfaces" command does not list the "gpio" as an available >> interface, is this normal ? >> > no, this is a bug, i have something nearly ready and can land it later > today in the edge channel, i'll notify the list once it is there and > also trigger a rebuild of the daily images (so you dont need to roll > your own image) > > ciao > oli > > From jose.pekkarinen at canonical.com Thu Apr 6 11:26:05 2017 From: jose.pekkarinen at canonical.com (=?ISO-8859-1?Q?Jos=E9?= Pekkarinen) Date: Thu, 06 Apr 2017 14:26:05 +0300 Subject: Big snaps on ubuntu store. Message-ID: <2028008.2PCf9JTJzv@ant> Hi list, I was trying to upload a clang snap to the ubuntu store today. To my surprise there seems to be a limit in how big the snap is: $ snapcraft push clang-git_0.1_amd64.snap Pushing 'clang-git_0.1_amd64.snap' to the store. Uploading clang-git_0.1_amd64.snap [ ] 0% Uploading clang-git_0.1_amd64.snap [=====================================================================================================================================================================================================================================] 100% There was an error uploading the package. Reason: 'INTERNAL SERVER ERROR' Text: '

Server Error (500)

How much is the limit, and how can we fit it? $ du -h clang-git_0.1_amd64.snap 3.8G clang-git_0.1_amd64.snap Best regards. José. From john.lenton at canonical.com Thu Apr 6 11:34:35 2017 From: john.lenton at canonical.com (John Lenton) Date: Thu, 6 Apr 2017 12:34:35 +0100 Subject: Big snaps on ubuntu store. In-Reply-To: <2028008.2PCf9JTJzv@ant> References: <2028008.2PCf9JTJzv@ant> Message-ID: I expect the store sent an X-Oops-Id header with that; maybe snapcraft should print it in these cases, to help with debugging? On 6 April 2017 at 12:26, José Pekkarinen wrote: > Hi list, > > I was trying to upload a clang snap to the ubuntu store today. To my > surprise there seems to be a limit in how big the snap is: > > $ snapcraft push clang-git_0.1_amd64.snap > Pushing 'clang-git_0.1_amd64.snap' to the store. > Uploading clang-git_0.1_amd64.snap [ > ] 0% > Uploading clang-git_0.1_amd64.snap > [=====================================================================================================================================================================================================================================] > 100% > There was an error uploading the package. > Reason: 'INTERNAL SERVER ERROR' > Text: '

Server Error (500)

> > How much is the limit, and how can we fit it? > > $ du -h clang-git_0.1_amd64.snap > 3.8G clang-git_0.1_amd64.snap > > Best regards. > > José. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From bret.barker at canonical.com Thu Apr 6 12:50:07 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Thu, 6 Apr 2017 08:50:07 -0400 Subject: Big snaps on ubuntu store. In-Reply-To: References: <2028008.2PCf9JTJzv@ant> Message-ID: <20170406125006.GM2659@abitrandom.net> José, Can you file a bug at https://bugs.launchpad.net/snapstore ? We have tested with snaps of around 1.5GB and generally this should work - we'll dig into it. Meanwhile, that's going to be quite a snap for users to install, even with delta downloads they'll get hit hard the first time. Is there any amount of slimming to be done there? Thanks, -bret On Thu, Apr 06, 2017 at 12:34:35PM +0100, John Lenton wrote: > I expect the store sent an X-Oops-Id header with that; maybe snapcraft > should print it in these cases, to help with debugging? > > On 6 April 2017 at 12:26, José Pekkarinen wrote: > > Hi list, > > > > I was trying to upload a clang snap to the ubuntu store today. To my > > surprise there seems to be a limit in how big the snap is: > > > > $ snapcraft push clang-git_0.1_amd64.snap > > Pushing 'clang-git_0.1_amd64.snap' to the store. > > Uploading clang-git_0.1_amd64.snap [ > > ] 0% > > Uploading clang-git_0.1_amd64.snap > > [=====================================================================================================================================================================================================================================] > > 100% > > There was an error uploading the package. > > Reason: 'INTERNAL SERVER ERROR' > > Text: '

Server Error (500)

> > > > How much is the limit, and how can we fit it? > > > > $ du -h clang-git_0.1_amd64.snap > > 3.8G clang-git_0.1_amd64.snap > > > > Best regards. > > > > José. > > > > -- > > 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 -- --* bret barker --* irc: noise From bret.barker at canonical.com Thu Apr 6 12:55:51 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Thu, 6 Apr 2017 08:55:51 -0400 Subject: Tracks for ldc2 snap package In-Reply-To: <9f3fef76-b49f-c587-4127-696b3fbab0dd@webdrake.net> References: <9f3fef76-b49f-c587-4127-696b3fbab0dd@webdrake.net> Message-ID: <20170406125551.GN2659@abitrandom.net> Joe, I've added these tracks for you, let me know if you have any troubles or questions. -bret On Wed, Apr 05, 2017 at 10:45:13PM +0200, Joseph Rushton Wakeling wrote: > Hello all, > > If I understand https://snapcraft.io/docs/reference/channels right, I'm > supposed to ask here about this -- please let me know if I'm wrong :-) > > Could I please request for two tracks, named 1.1 and 1.2, to be enabled for > the ldc2 snap package? > > Thanks and best wishes, > > -- Joe From jose.pekkarinen at canonical.com Thu Apr 6 12:57:20 2017 From: jose.pekkarinen at canonical.com (Jose Pekkarinen) Date: Thu, 6 Apr 2017 15:57:20 +0300 Subject: Big snaps on ubuntu store. In-Reply-To: <20170406125006.GM2659@abitrandom.net> References: <2028008.2PCf9JTJzv@ant> <20170406125006.GM2659@abitrandom.net> Message-ID: I'll do later today with the bug report. Yes it's possible to slim it, as this is bringing all clang targets with all the bells and whistles the git code brings, however I see no way how to put some targets in a slimmer snap without duplicating the common part in all the others. I'm open to suggestions. Best regards. José On 6 Apr 2017 15:50, "Bret A. Barker" wrote: > José, > > Can you file a bug at https://bugs.launchpad.net/snapstore ? We have > tested with snaps of around 1.5GB and generally this should work - we'll > dig into it. > > Meanwhile, that's going to be quite a snap for users to install, even with > delta downloads they'll get hit hard the first time. Is there any amount of > slimming to be done there? > > Thanks, > -bret > > On Thu, Apr 06, 2017 at 12:34:35PM +0100, John Lenton wrote: > > I expect the store sent an X-Oops-Id header with that; maybe snapcraft > > should print it in these cases, to help with debugging? > > > > On 6 April 2017 at 12:26, José Pekkarinen > wrote: > > > Hi list, > > > > > > I was trying to upload a clang snap to the ubuntu store today. > To my > > > surprise there seems to be a limit in how big the snap is: > > > > > > $ snapcraft push clang-git_0.1_amd64.snap > > > Pushing 'clang-git_0.1_amd64.snap' to the store. > > > Uploading clang-git_0.1_amd64.snap [ > > > ] 0% > > > Uploading clang-git_0.1_amd64.snap > > > [=========================================================== > ============================================================ > ============================================================ > ==================================================] > > > 100% > > > There was an error uploading the package. > > > Reason: 'INTERNAL SERVER ERROR' > > > Text: '

Server Error (500)

> > > > > > How much is the limit, and how can we fit it? > > > > > > $ du -h clang-git_0.1_amd64.snap > > > 3.8G clang-git_0.1_amd64.snap > > > > > > Best regards. > > > > > > José. > > > > > > -- > > > 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 > > -- > --* bret barker > --* irc: noise > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From cjwatson at ubuntu.com Thu Apr 6 16:07:30 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Thu, 6 Apr 2017 17:07:30 +0100 Subject: Error with Launchpad uploading 403 Client Error: Forbidden In-Reply-To: References: Message-ID: <20170406160730.GA22283@riva.ucam.org> On Wed, Apr 05, 2017 at 10:41:27PM +0200, Joseph Rushton Wakeling wrote: > Recently I was able to successfully set up Launchpad builds for my ldc2 > snap. However, auto-upload to the store failed with a 403 Client Error: > Forbidden. > > The error messages are no more informative than this, so anyone have any > idea what's going on? It's not 100% clear what's going on, but my guess is that either you haven't agreed to the developer terms and conditions (https://myapps.developer.ubuntu.com/dev/tos/) or haven't set a short namespace in your developer profile (https://myapps.developer.ubuntu.com/dev/account/) for the account that you used to authorise Launchpad to upload this snap to the store. Could you check those two things? If it's not either of those then we'll need to investigate further, probably by way of adding more logging and getting you to try again. In those two cases above, it's a bug that the error isn't presented clearly in the Launchpad UI; I don't think it's been filed, so it would be worth it for somebody affected by it to do so. -- Colin Watson [cjwatson at ubuntu.com] From manik.taneja at canonical.com Thu Apr 6 16:16:04 2017 From: manik.taneja at canonical.com (Manik Taneja) Date: Thu, 6 Apr 2017 09:16:04 -0700 Subject: Big snaps on ubuntu store. In-Reply-To: References: <2028008.2PCf9JTJzv@ant> <20170406125006.GM2659@abitrandom.net> Message-ID: On Thu, Apr 6, 2017 at 5:57 AM, Jose Pekkarinen < jose.pekkarinen at canonical.com> wrote: > I'll do later today with the bug report. > > Yes it's possible to slim it, as this is bringing all clang targets with > all the bells and whistles the git code brings, however I see no way how to > put some targets in a slimmer snap without duplicating the common part in > all the others. I'm open to suggestions. > you can put the common part in 1 snap and share it via the content interface with all the other snaps. since you are the publisher of these snaps, the interfaces can also be auto-connected on installation. the only issue i see is that users will have to install at least 2 different snaps (if not more). /manik From mabnhdev at gmail.com Thu Apr 6 16:26:39 2017 From: mabnhdev at gmail.com (MikeB) Date: Thu, 6 Apr 2017 12:26:39 -0400 Subject: Snap issue with python daemon Message-ID: I'm using the python-package to daemonize a python command. In my snapcraft, I list my command as a forking daemon. When I run the command directly from command line, it does exactly what I expect, it damonizes and runs forever while the parent exits. When I try to install the snap, the installation hangs starting the snap until it finally times out. I see my command running during the start up - I see it logging to syslog as expected. Interestingly, it leaves the command running after the timeout. I have to manually kill it. A simple example of the snapcraft.yaml and the test-daemon can be found at https://gist.github.com/mabnhdev/121154d3c6fd830d60a60eaee3c33c7b It seems as if the default behavior of the python-daemon package is not sufficient for snappy. What else needs to happen? Regards, Mike From jose.pekkarinen at canonical.com Thu Apr 6 16:31:57 2017 From: jose.pekkarinen at canonical.com (=?ISO-8859-1?Q?Jos=E9?= Pekkarinen) Date: Thu, 06 Apr 2017 19:31:57 +0300 Subject: Big snaps on ubuntu store. In-Reply-To: References: <2028008.2PCf9JTJzv@ant> Message-ID: <1959295.Wq7FfZkGWF@ant> > > you can put the common part in 1 snap and share it via the content interface > with all the other snaps. since you are the publisher of these snaps, the > interfaces can also be auto-connected on installation. the only issue i see > is that users will have to install at least 2 different snaps (if not > more). > Hi, That sounds a really great idea, is there any documentation in how to do it? For instance how to tell a snap to expose the content plug and how to tell the remaining snaps that it has to take the plug provided by the previous one? Thanks! José. From mabnhdev at gmail.com Thu Apr 6 17:47:12 2017 From: mabnhdev at gmail.com (MikeB) Date: Thu, 6 Apr 2017 13:47:12 -0400 Subject: Snap issue with python daemon In-Reply-To: References: Message-ID: As a follow-up, using the python-systemd package to change the daemon to 'notify' works in snappy - the snap is installed and the daemon is running as expected. http://gist.github.com/mabnhdev/17a8cb7bdc4df947a1c24d42c32b1daf Mike On Thu, Apr 6, 2017 at 12:26 PM, MikeB wrote: > I'm using the python-package to daemonize a python command. > > In my snapcraft, I list my command as a forking daemon. > > When I run the command directly from command line, it does exactly > what I expect, it damonizes and runs forever while the parent exits. > > When I try to install the snap, the installation hangs starting the > snap until it finally times out. > > I see my command running during the start up - I see it logging to > syslog as expected. Interestingly, it leaves the command running after > the timeout. I have to manually kill it. > > A simple example of the snapcraft.yaml and the test-daemon can be > found at https://gist.github.com/mabnhdev/121154d3c6fd830d60a60eaee3c33c7b > > It seems as if the default behavior of the python-daemon package is > not sufficient for snappy. What else needs to happen? > > Regards, Mike From bret.barker at canonical.com Thu Apr 6 18:02:41 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Thu, 6 Apr 2017 14:02:41 -0400 Subject: Big snaps on ubuntu store. In-Reply-To: <1959295.Wq7FfZkGWF@ant> References: <2028008.2PCf9JTJzv@ant> <1959295.Wq7FfZkGWF@ant> Message-ID: <20170406180240.GR2659@abitrandom.net> On Thu, Apr 06, 2017 at 07:31:57PM +0300, José Pekkarinen wrote: > > > > you can put the common part in 1 snap and share it via the content interface > > with all the other snaps. since you are the publisher of these snaps, the > > interfaces can also be auto-connected on installation. the only issue i see > > is that users will have to install at least 2 different snaps (if not > > more). > > > > Hi, > > That sounds a really great idea, is there any documentation in how to do > it? For instance how to tell a snap to expose the content plug and how to tell > the remaining snaps that it has to take the plug provided by the previous one? > > Thanks! > > José. > Not my area of expertise, but this ROS demo might help: https://github.com/snapcore/snapcraft/tree/master/demos/shared-ros -bret From joseph.wakeling at webdrake.net Thu Apr 6 20:48:32 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 6 Apr 2017 22:48:32 +0200 Subject: Tracks for ldc2 snap package In-Reply-To: <20170406125551.GN2659@abitrandom.net> References: <9f3fef76-b49f-c587-4127-696b3fbab0dd@webdrake.net> <20170406125551.GN2659@abitrandom.net> Message-ID: <5018bbdf-bd74-4e70-24e8-db1556ef0027@webdrake.net> On 06/04/17 14:55, Bret A. Barker wrote: > I've added these tracks for you, let me know if you have any troubles or questions. All seems good! Thank you very much :-) From brogeriofernandes at gmail.com Thu Apr 6 22:15:29 2017 From: brogeriofernandes at gmail.com (Bruno Rogerio Fernandes) Date: Thu, 6 Apr 2017 19:15:29 -0300 Subject: Exposing commands Message-ID: Hello everybody I'm not sure, but I think I'm doing it wrong. I would like to create snaps from scientific softwares. Initially I'm trying to build a gromacs snap. But gromacs has many binaries that I need to expose. I asked on IRC and I understood that I need to expose commands one by one. For now, I have something like that: --- snap/snapcraft.yaml: > name: gromacs > version: '4.5.5' > description: [...] > parts: > gromacs: > plugin: autotools > source: ftp://ftp.gromacs.org/pub/gromacs/gromacs-4.5.5.tar.gz > build-packages: [libfftw3-dev] > apps: > demux.pl: > command: bin/demux.pl > do_dssp: > command: bin/do_dssp > editconf: > command: bin/editconf > eneconv: > command: bin/eneconv > [ . . . ] > trjorder: > command: bin/trjorder > xplor2gmx.pl: > command: bin/xplor2gmx.pl > xpm2ps: > command: bin/xpm2ps There are one problem here: I cannot expose some binaries like demux.pl or do_dssp as they both have invalid characters on name, namely "." and "_" respectively. What should I do in that case? I have to expose all that commands, and I would like to have the possibility to call them in that way: gromacs455.do_dssp (for example) Am I missing something? Thanks for your attention From kyle.fazzari at canonical.com Thu Apr 6 22:59:10 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 6 Apr 2017 15:59:10 -0700 Subject: From ROS prototype to production on Ubuntu Core (part 1) Message-ID: Hey everyone, This is really for those on the list who are using ROS (Robot Operating System), but it may prove beneficial to others as well. I've been working on creating a blog/video series about taking a ROS prototype to production using snaps and Ubuntu Core. Barring any unforeseen circumstances, I plan to publish one part per week. Part 1 has been published, if you're interested in checking it out. Blog post: https://kyrofa.com/posts/from-ros-prototype-to-production-on-ubuntu-core-1-5 Video: https://youtu.be/x6BkzfwOZbc Thanks! -- 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 jose.pekkarinen at canonical.com Fri Apr 7 10:27:38 2017 From: jose.pekkarinen at canonical.com (=?ISO-8859-1?Q?Jos=E9?= Pekkarinen) Date: Fri, 07 Apr 2017 13:27:38 +0300 Subject: Big snaps on ubuntu store. In-Reply-To: <20170406180240.GR2659@abitrandom.net> References: <2028008.2PCf9JTJzv@ant> <1959295.Wq7FfZkGWF@ant> <20170406180240.GR2659@abitrandom.net> Message-ID: <1683183.6dzDjlEhp9@ant> > > Not my area of expertise, but this ROS demo might help: > https://github.com/snapcore/snapcraft/tree/master/demos/shared-ros > > -bret Great example, thanks so much Bret! José. From stephen.joseph at united-email.info Fri Apr 7 15:18:08 2017 From: stephen.joseph at united-email.info (Stephen Joseph) Date: Fri, 7 Apr 2017 10:18:08 -0500 Subject: Data processing Message-ID: Hi, Good day to you! My name is Stephen Joseph, the Business Development Manager at one of the leading email database providing companies. Our area of expertise lies specifically in the major industrial lists like: Agriculture, Business Services, Chambers of Commerce, Cities, Towns & Municipalities, Construction, Consumer Services, Cultural, Education, Energy, Utilities & Waste Treatment, Finance, Government, Healthcare, Hospitality, Insurance, Law Firms & Legal Services, Manufacturing, Media & Internet, Metals & Mining, Organizations, Real Estate, Retail, Software, Telecommunications, Transportation, etc. Building long term relationships with our clients is something we strongly believe in and we go to great lengths to ensure our valuable clients receive first rate service. Some of the most popular services we offer include: ü List service #1 - B2B & B2C Email Lists ü List service #2 -Data Processing & Email Appending ü List service #3 - Email Campaigning We’d welcome the opportunity to discuss your email list needs. Best Regards, Stephen Joseph | Business Development Associate | T: +1 610 572 4885 Global Business Data – Email Append – Data Append. If you are not interested in receiving further emails, please reply back with “LEAVEOUT” in the subject line”. From manik.taneja at canonical.com Fri Apr 7 17:31:21 2017 From: manik.taneja at canonical.com (Manik Taneja) Date: Fri, 7 Apr 2017 10:31:21 -0700 Subject: From ROS prototype to production on Ubuntu Core (part 1) In-Reply-To: References: Message-ID: Kyle, A big thank you for driving this and getting snaps and Ubuntu Core more visibility. This is very timely and serves to answer a lot of difficult questions people have been asking on the mailers on ROS and content sharing. Keep up the great work! Cheers, Manik On Thu, Apr 6, 2017 at 3:59 PM, Kyle Fazzari wrote: > Hey everyone, > > This is really for those on the list who are using ROS (Robot Operating > System), but it may prove beneficial to others as well. > > I've been working on creating a blog/video series about taking a ROS > prototype to production using snaps and Ubuntu Core. Barring any > unforeseen circumstances, I plan to publish one part per week. > > Part 1 has been published, if you're interested in checking it out. > > Blog post: > https://kyrofa.com/posts/from-ros-prototype-to-production- > on-ubuntu-core-1-5 > Video: https://youtu.be/x6BkzfwOZbc > > Thanks! > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > From joseph.wakeling at webdrake.net Sat Apr 8 16:51:29 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 8 Apr 2017 18:51:29 +0200 Subject: Snap packages as build dependencies of other snaps Message-ID: <537be203-5611-b70a-7dc5-b01a25b79dcc@webdrake.net> Hello folks, Is it possible to specify an existing snap package (by track and release channel) as a build dependency of a part of another snap package? I'm interested specifically in the case of using an existing snap package to provide a compiler used to build another snap. From what I understand from discussion around the go snapcraft plugin, there is some intention to allow this, but is it just for plugins? Thanks & best wishes, -- Joe From xiaoguo.liu at canonical.com Sat Apr 8 23:24:07 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Sun, 9 Apr 2017 07:24:07 +0800 Subject: Snap packages as build dependencies of other snaps In-Reply-To: <537be203-5611-b70a-7dc5-b01a25b79dcc@webdrake.net> References: <537be203-5611-b70a-7dc5-b01a25b79dcc@webdrake.net> Message-ID: can you do it by remote parts? you can find more info by: $ snapcraft update $ snapcraft search There are a number of existing parts there already. You can publish your own. Best regards, XiaoGuo On Sun, Apr 9, 2017 at 12:51 AM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello folks, > > Is it possible to specify an existing snap package (by track and release > channel) as a build dependency of a part of another snap package? > > I'm interested specifically in the case of using an existing snap package > to provide a compiler used to build another snap. From what I understand > from discussion around the go snapcraft plugin, there is some intention to > allow this, but is it just for plugins? > > Thanks & best wishes, > > -- Joe > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- XiaoGuo, Liu From joseph.wakeling at webdrake.net Sun Apr 9 00:06:39 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 9 Apr 2017 02:06:39 +0200 Subject: Snap packages as build dependencies of other snaps In-Reply-To: References: <537be203-5611-b70a-7dc5-b01a25b79dcc@webdrake.net> Message-ID: <1fe61371-5b53-6966-747f-92aa9fe9b1c8@webdrake.net> On 09/04/17 01:24, XiaoGuo Liu wrote: > can you do it by remote parts? you can find more info by: > > $ snapcraft update > $ snapcraft search > > There are a number of existing parts there already. You can publish your > own. That's a cool thing to know about. I'd consider it, but since the package I want to use as a dependency is one that I control, I'm not sure that I really gain anything over just copying the relevant parts instructions into the other snap package. The particular reason I would like to actually be able to use an existing snap package as a build package is really that it seems like a waste of effort to rebuild something that's already built (and takes some time to build). I read the discussion here: https://bugs.launchpad.net/snapcraft/+bug/1616985/comments/5 ... and was wondering if that kind of flexibility was likely to arrive soon. Note, I have a vested interest in this for a snapcraft plugin that I'd like to write myself, which has almost exactly the same use-case as the go plugin discussed in that issue. ;-) Anyway, thanks for letting me know about remote parts. But I think in this case I really would like to be able to ask for a snap package as something that can be used to build another snap. Thanks & best wishes, -- Joe From stuart.bishop at canonical.com Sun Apr 9 03:19:34 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Sun, 9 Apr 2017 13:19:34 +1000 Subject: Snap packages as build dependencies of other snaps In-Reply-To: <1fe61371-5b53-6966-747f-92aa9fe9b1c8@webdrake.net> References: <537be203-5611-b70a-7dc5-b01a25b79dcc@webdrake.net> <1fe61371-5b53-6966-747f-92aa9fe9b1c8@webdrake.net> Message-ID: On 9 April 2017 at 10:06, Joseph Rushton Wakeling wrote: > On 09/04/17 01:24, XiaoGuo Liu wrote: > The particular reason I would like to actually be able to use an existing > snap package as a build package is really that it seems like a waste of > effort to rebuild something that's already built (and takes some time to > build). I read the discussion here: > https://bugs.launchpad.net/snapcraft/+bug/1616985/comments/5 > > ... and was wondering if that kind of flexibility was likely to arrive soon. This is tracked at https://bugs.launchpad.net/bugs/1677974 I don't know the time frame. I'm primarily interested in Launchpad building my snaps, which will also need updating once snapcraft can somehow handle snap package build dependencies. -- Stuart Bishop From stuart.bishop at canonical.com Sun Apr 9 04:49:59 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Sun, 9 Apr 2017 14:49:59 +1000 Subject: Exposing commands In-Reply-To: References: Message-ID: On 7 April 2017 at 08:15, Bruno Rogerio Fernandes wrote: > There are one problem here: > I cannot expose some binaries like demux.pl or do_dssp as they both have > invalid characters on name, namely "." and "_" respectively. > What should I do in that case? I have to expose all that commands, and I > would like to have the possibility to call them in that way: > gromacs455.do_dssp (for example) > Am I missing something? > > Thanks for your attention Hi. You are not missing something. "_" is currently unsupported, per https://bugs.launchpad.net/bugs/1616507 . The issue pre-dates the command aliases feature, so the rationales forbidding them have probably changed. -- Stuart Bishop From joseph.wakeling at webdrake.net Sun Apr 9 07:50:04 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 9 Apr 2017 09:50:04 +0200 Subject: Snap packages as build dependencies of other snaps In-Reply-To: References: <537be203-5611-b70a-7dc5-b01a25b79dcc@webdrake.net> <1fe61371-5b53-6966-747f-92aa9fe9b1c8@webdrake.net> Message-ID: On 09/04/17 05:19, Stuart Bishop wrote: > This is tracked at https://bugs.launchpad.net/bugs/1677974 > > I don't know the time frame. I'm primarily interested in Launchpad > building my snaps, which will also need updating once snapcraft can > somehow handle snap package build dependencies. Thanks for the heads-up, I've added my use-case there. Obviously time-frames are for the developers, but if support lands in snapcraft master before the end of the month, it might give me an opportunity to show off the plugin I'm working on at the D programming language conference at the beginning of May in Berlin: http://dconf.org/2017/index.html ;-) From joseph.wakeling at webdrake.net Sun Apr 9 08:12:28 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 9 Apr 2017 10:12:28 +0200 Subject: Architecture-specific settings for snapcraft parts In-Reply-To: <0087f355-5b3a-b63e-e817-19b4e89c6a5e@webdrake.net> References: <0087f355-5b3a-b63e-e817-19b4e89c6a5e@webdrake.net> Message-ID: <7f935b93-dc3c-d869-e8aa-53be029ba6d8@webdrake.net> On 03/04/17 21:18, Joseph Rushton Wakeling wrote: > Recently I tried some ARM builds of the LDC snap package, and came across some > issues where one of the custom C flags used were not supported: > https://launchpadlibrarian.net/313662608/buildlog_snap_ubuntu_xenial_armhf_ldc2_BUILDING.txt.gz > > Is there any way to customize the settings for parts according to architecture? > In this case I'm looking to customize the cmake configflags. I wonder if I might ping on the above question? I actually have two use-cases: * different `configflags` for the cmake plugin depending on the architecture; * a different `source:` field for a plugin that downloads a prebuilt binary used in the build process (I obviously need a different binary for i386 versus amd64 builds). Thanks & best wishes, -- Joe From sergio.schvezov at canonical.com Sun Apr 9 14:12:35 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 9 Apr 2017 11:12:35 -0300 Subject: Architecture-specific settings for snapcraft parts In-Reply-To: <7f935b93-dc3c-d869-e8aa-53be029ba6d8@webdrake.net> References: <0087f355-5b3a-b63e-e817-19b4e89c6a5e@webdrake.net> <7f935b93-dc3c-d869-e8aa-53be029ba6d8@webdrake.net> Message-ID: On Sun, Apr 9, 2017 at 5:12 AM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 03/04/17 21:18, Joseph Rushton Wakeling wrote: > >> Recently I tried some ARM builds of the LDC snap package, and came across >> some >> issues where one of the custom C flags used were not supported: >> https://launchpadlibrarian.net/313662608/buildlog_snap_ubunt >> u_xenial_armhf_ldc2_BUILDING.txt.gz >> >> Is there any way to customize the settings for parts according to >> architecture? >> In this case I'm looking to customize the cmake configflags. >> > > I wonder if I might ping on the above question? I actually have two > use-cases: > > * different `configflags` for the cmake plugin depending on the > architecture; > > * a different `source:` field for a plugin that downloads a prebuilt > binary > used in the build process (I obviously need a different binary for i386 > versus amd64 builds). > We have a grammar engine for stage-packages in place which I wish to propose to extend every key attribute in snapcraft. From joseph.wakeling at webdrake.net Sun Apr 9 14:57:52 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 9 Apr 2017 16:57:52 +0200 Subject: Architecture-specific settings for snapcraft parts In-Reply-To: References: <0087f355-5b3a-b63e-e817-19b4e89c6a5e@webdrake.net> <7f935b93-dc3c-d869-e8aa-53be029ba6d8@webdrake.net> Message-ID: On 09/04/17 16:12, Sergio Schvezov wrote: > We have a grammar engine for stage-packages in place which I wish to > propose to extend every key attribute in snapcraft. Sounds cool! Will look forward to trying it out when it lands :-) From brogeriofernandes at gmail.com Sun Apr 9 20:24:26 2017 From: brogeriofernandes at gmail.com (Bruno Rogerio Fernandes) Date: Sun, 09 Apr 2017 20:24:26 +0000 Subject: Exposing commands In-Reply-To: References: Message-ID: Oh, thanks for the clarification. I would like to port some scientific apps to snaps, but for now I'm feeling a bit lost Thanks again Em dom, 9 de abr de 2017 às 01:50, Stuart Bishop < stuart.bishop at canonical.com> escreveu: > On 7 April 2017 at 08:15, Bruno Rogerio Fernandes > wrote: > > > There are one problem here: > > I cannot expose some binaries like demux.pl or do_dssp as they both have > > invalid characters on name, namely "." and "_" respectively. > > What should I do in that case? I have to expose all that commands, and I > > would like to have the possibility to call them in that way: > > gromacs455.do_dssp (for example) > > Am I missing something? > > > > Thanks for your attention > > Hi. > > You are not missing something. "_" is currently unsupported, per > https://bugs.launchpad.net/bugs/1616507 . > The issue pre-dates the command aliases feature, so the rationales > forbidding them have probably changed. > > -- > Stuart Bishop > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From gustavo.niemeyer at canonical.com Sun Apr 9 20:48:05 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Sun, 9 Apr 2017 17:48:05 -0300 Subject: Exposing commands In-Reply-To: References: Message-ID: Hi Bruno, You can solve some of those issues with aliases, which do allow a richer range of characters. On Apr 9, 2017 17:25, "Bruno Rogerio Fernandes" wrote: > Oh, thanks for the clarification. I would like to port some scientific apps > to snaps, but for now I'm feeling a bit lost > > Thanks again > > Em dom, 9 de abr de 2017 às 01:50, Stuart Bishop < > stuart.bishop at canonical.com> escreveu: > > > On 7 April 2017 at 08:15, Bruno Rogerio Fernandes > > wrote: > > > > > There are one problem here: > > > I cannot expose some binaries like demux.pl or do_dssp as they both > have > > > invalid characters on name, namely "." and "_" respectively. > > > What should I do in that case? I have to expose all that commands, and > I > > > would like to have the possibility to call them in that way: > > > gromacs455.do_dssp (for example) > > > Am I missing something? > > > > > > Thanks for your attention > > > > Hi. > > > > You are not missing something. "_" is currently unsupported, per > > https://bugs.launchpad.net/bugs/1616507 . > > The issue pre-dates the command aliases feature, so the rationales > > forbidding them have probably changed. > > > > -- > > Stuart Bishop > > > > -- > > 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 > From akgrant0710 at gmail.com Mon Apr 10 05:24:56 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Mon, 10 Apr 2017 07:24:56 +0200 Subject: Manual review request? Message-ID: Hi All, I registered the name Pharo and uploaded a snap on April 5. Pharo is a general purpose programming environment (Smalltalk), meaning that developers expect to be able to call any executable or load any library on their system, so the snap has classic confinement. I uploaded the snap to the edge channel and it immediately failed automatic review and is listed pending manual review. Would someone mind letting me know the normal manual review time, and is there anything else I need to provide to faciliate the review? More information on Pharo is available from: http://pharo.org Thanks! Alistair From evan.dandrea at canonical.com Mon Apr 10 09:49:56 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Mon, 10 Apr 2017 09:49:56 +0000 Subject: Manual review request? In-Reply-To: References: Message-ID: On Mon, 10 Apr 2017 at 06:25 Alistair Grant wrote: > Hi All, > > I registered the name Pharo and uploaded a snap on April 5. > > Pharo is a general purpose programming environment (Smalltalk), meaning > that developers expect to be able to call any executable or load any > library on their system, so the snap has classic confinement. > Agreed and approved. Being a full programming environment, IDE included, this needs access to arbitrary paths. Do you think we could have `snap install pharo` replace the existing go fast install instructions (`curl get.pharo.org | bash`)? From brogeriofernandes at gmail.com Mon Apr 10 11:40:58 2017 From: brogeriofernandes at gmail.com (Bruno Rogerio Fernandes) Date: Mon, 10 Apr 2017 11:40:58 +0000 Subject: Exposing commands In-Reply-To: References: Message-ID: Hi Gustavo Oh, this apparently solve my problem. I'm playing around just now with aliases, but a can't find in the docs if I can automatically activate all my aliases on snap install time. I mean, it would be great if upon snap install, the user has immediately access to snap app aliases. Is there something like that? Em dom, 9 de abr de 2017 às 17:48, Gustavo Niemeyer < gustavo.niemeyer at canonical.com> escreveu: > Hi Bruno, > > You can solve some of those issues with aliases, which do allow a richer > range of characters. > > On Apr 9, 2017 17:25, "Bruno Rogerio Fernandes" < > brogeriofernandes at gmail.com> > wrote: > > > Oh, thanks for the clarification. I would like to port some scientific > apps > > to snaps, but for now I'm feeling a bit lost > > > > Thanks again > > > > Em dom, 9 de abr de 2017 às 01:50, Stuart Bishop < > > stuart.bishop at canonical.com> escreveu: > > > > > On 7 April 2017 at 08:15, Bruno Rogerio Fernandes > > > wrote: > > > > > > > There are one problem here: > > > > I cannot expose some binaries like demux.pl or do_dssp as they both > > have > > > > invalid characters on name, namely "." and "_" respectively. > > > > What should I do in that case? I have to expose all that commands, > and > > I > > > > would like to have the possibility to call them in that way: > > > > gromacs455.do_dssp (for example) > > > > Am I missing something? > > > > > > > > Thanks for your attention > > > > > > Hi. > > > > > > You are not missing something. "_" is currently unsupported, per > > > https://bugs.launchpad.net/bugs/1616507 . > > > The issue pre-dates the command aliases feature, so the rationales > > > forbidding them have probably changed. > > > > > > -- > > > Stuart Bishop > > > > > > -- > > > 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 > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From daniel.manrique at canonical.com Mon Apr 10 13:57:43 2017 From: daniel.manrique at canonical.com (Daniel Manrique) Date: Mon, 10 Apr 2017 09:57:43 -0400 Subject: Exposing commands In-Reply-To: References: Message-ID: On Mon, Apr 10, 2017 at 7:40 AM, Bruno Rogerio Fernandes wrote: > Hi Gustavo > Oh, this apparently solve my problem. I'm playing around just now with > aliases, but a can't find in the docs if I can automatically activate all > my aliases on snap install time. > I mean, it would be great if upon snap install, the user has immediately > access to snap app aliases. Is there something like that? Hello, Snap reviewers can set up automatic alias activation (a feature called "auto-aliases"). You can ask on this list for your snap to be allowed automatic alias activation, a reviewer will verify your request to ensure there are no conflicts and if so, enable this feature for your snap. Technically this will be in the snap-declaration for your snap, but that's handled by the Ubuntu store. I suggest you do so on a new thread/message titled something like "auto-alias request for YOUR SNAP" to ease tracking and avoid burying information in other threads. Cheers, - Daniel > > Em dom, 9 de abr de 2017 às 17:48, Gustavo Niemeyer < > gustavo.niemeyer at canonical.com> escreveu: > >> Hi Bruno, >> >> You can solve some of those issues with aliases, which do allow a richer >> range of characters. >> >> On Apr 9, 2017 17:25, "Bruno Rogerio Fernandes" < >> brogeriofernandes at gmail.com> >> wrote: >> >> > Oh, thanks for the clarification. I would like to port some scientific >> apps >> > to snaps, but for now I'm feeling a bit lost >> > >> > Thanks again >> > >> > Em dom, 9 de abr de 2017 às 01:50, Stuart Bishop < >> > stuart.bishop at canonical.com> escreveu: >> > >> > > On 7 April 2017 at 08:15, Bruno Rogerio Fernandes >> > > wrote: >> > > >> > > > There are one problem here: >> > > > I cannot expose some binaries like demux.pl or do_dssp as they both >> > have >> > > > invalid characters on name, namely "." and "_" respectively. >> > > > What should I do in that case? I have to expose all that commands, >> and >> > I >> > > > would like to have the possibility to call them in that way: >> > > > gromacs455.do_dssp (for example) >> > > > Am I missing something? >> > > > >> > > > Thanks for your attention >> > > >> > > Hi. >> > > >> > > You are not missing something. "_" is currently unsupported, per >> > > https://bugs.launchpad.net/bugs/1616507 . >> > > The issue pre-dates the command aliases feature, so the rationales >> > > forbidding them have probably changed. >> > > >> > > -- >> > > Stuart Bishop >> > > >> > > -- >> > > 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 >> > >> -- >> 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 From kyle.fazzari at canonical.com Mon Apr 10 14:33:45 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 10 Apr 2017 07:33:45 -0700 Subject: Exposing commands In-Reply-To: References: Message-ID: On 04/10/2017 06:57 AM, Daniel Manrique wrote: > On Mon, Apr 10, 2017 at 7:40 AM, Bruno Rogerio Fernandes > wrote: >> Hi Gustavo >> Oh, this apparently solve my problem. I'm playing around just now with >> aliases, but a can't find in the docs if I can automatically activate all >> my aliases on snap install time. >> I mean, it would be great if upon snap install, the user has immediately >> access to snap app aliases. Is there something like that? > > Hello, > > Snap reviewers can set up automatic alias activation (a feature called > "auto-aliases"). You can ask on this list for your snap to be allowed > automatic alias activation, a reviewer will verify your request to > ensure there are no conflicts and if so, enable this feature for your > snap. Technically this will be in the snap-declaration for your snap, > but that's handled by the Ubuntu store. > > I suggest you do so on a new thread/message titled something like > "auto-alias request for YOUR SNAP" to ease tracking and avoid burying > information in other threads. Before doing that, you might want to read up on how that behavior is changing: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/7 -- 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 gustavo.niemeyer at canonical.com Mon Apr 10 14:42:02 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 10 Apr 2017 11:42:02 -0300 Subject: Exposing commands In-Reply-To: References: Message-ID: Yes, I'd suggest following that thread and waiting just a little bit. We're hoping to get these changes landed as soon as snapd 2.25. On Mon, Apr 10, 2017 at 11:33 AM, Kyle Fazzari wrote: > > > On 04/10/2017 06:57 AM, Daniel Manrique wrote: > > On Mon, Apr 10, 2017 at 7:40 AM, Bruno Rogerio Fernandes > > wrote: > >> Hi Gustavo > >> Oh, this apparently solve my problem. I'm playing around just now with > >> aliases, but a can't find in the docs if I can automatically activate > all > >> my aliases on snap install time. > >> I mean, it would be great if upon snap install, the user has immediately > >> access to snap app aliases. Is there something like that? > > > > Hello, > > > > Snap reviewers can set up automatic alias activation (a feature called > > "auto-aliases"). You can ask on this list for your snap to be allowed > > automatic alias activation, a reviewer will verify your request to > > ensure there are no conflicts and if so, enable this feature for your > > snap. Technically this will be in the snap-declaration for your snap, > > but that's handled by the Ubuntu store. > > > > I suggest you do so on a new thread/message titled something like > > "auto-alias request for YOUR SNAP" to ease tracking and avoid burying > > information in other threads. > > Before doing that, you might want to read up on how that behavior is > changing: > > https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/7 > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > 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 From akgrant0710 at gmail.com Mon Apr 10 19:17:43 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Mon, 10 Apr 2017 19:17:43 +0000 Subject: Manual review request? In-Reply-To: References: Message-ID: <20170410191743.GA1225@1e4e4777663c> Hi Evan, On Mon, Apr 10, 2017 at 09:49:56AM +0000, Evan Dandrea wrote: > On Mon, 10 Apr 2017 at 06:25 Alistair Grant wrote: > > > Hi All, > > > > I registered the name Pharo and uploaded a snap on April 5. > > > > Pharo is a general purpose programming environment (Smalltalk), meaning > > that developers expect to be able to call any executable or load any > > library on their system, so the snap has classic confinement. > > > > Agreed and approved. Being a full programming environment, IDE included, > this needs access to arbitrary paths. Thanks very much for approving this. > Do you think we could have `snap install pharo` replace the existing go > fast install instructions (`curl get.pharo.org | bash`)? That's my goal. First steps, of course, are to get wider testing within our community, have it added as an installation option, and then made the primary installation method. Thanks again, Alistair From alan.pope at canonical.com Thu Apr 13 09:04:55 2017 From: alan.pope at canonical.com (Alan Pope) Date: Thu, 13 Apr 2017 10:04:55 +0100 Subject: Snapcraft Video Series Message-ID: Hello! I've started a series of videos which are being released over the coming weeks. The goal is to get new people up to speed on snaps and our tools. The first one, linked below is just a brief overview. More detailed ones will follow, but they'll all be pretty short, no hour-long snooze-fests :slight_smile: Subscribe to the [snapcraft.io YouTube channel at https://www.youtube.com/channel/UCcH6oAZ0FOSVUMUAojHtFBg to get notified when new videos come out! If you have any requests for particular aspects of snaps / snapcraft, let me know and I'll see what we can do! https://www.youtube.com/watch?v=DLxqdf89hRo Cheers, -- Alan Pope Snap Advocate Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From joerlend.schinstad at gmail.com Thu Apr 13 09:18:10 2017 From: joerlend.schinstad at gmail.com (Jo-Erlend Schinstad) Date: Thu, 13 Apr 2017 11:18:10 +0200 Subject: Snapcraft Video Series In-Reply-To: References: Message-ID: Great video! I'm really looking forward to seeing more of them. Great job. Thanks. On 13 April 2017 at 11:04, Alan Pope wrote: > Hello! I've started a series of videos which are being released over > the coming weeks. The goal is to get new people up to speed on snaps > and our tools. The first one, linked below is just a brief overview. > More detailed ones will follow, but they'll all be pretty short, no > hour-long snooze-fests :slight_smile: > > Subscribe to the [snapcraft.io YouTube channel at > https://www.youtube.com/channel/UCcH6oAZ0FOSVUMUAojHtFBg to get > notified when new videos come out! If you have any requests for > particular aspects of snaps / snapcraft, let me know and I'll see what > we can do! > > https://www.youtube.com/watch?v=DLxqdf89hRo > > Cheers, > -- > Alan Pope > Snap Advocate > > Canonical - Ubuntu Engineering and Services > +44 (0) 7973 620 164 > alan.pope at canonical.com > http://ubuntu.com/ > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From kyle.fazzari at canonical.com Thu Apr 13 15:14:29 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 13 Apr 2017 08:14:29 -0700 Subject: ROS Production part 2: Our prototype Message-ID: <6f2999d6-58d5-44b8-0570-39a5b811d20e@canonical.com> The second blog and video of the series has been posted, where we created the ROS prototype that will be used throughout the rest of the series. Blog post:https://kyrofa.com/posts/ros-production-our-prototype-2-5 Video: https://youtu.be/QFrOXd2avfo -- 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 stephenbhope at gmail.com Thu Apr 13 17:20:31 2017 From: stephenbhope at gmail.com (Stephen Hope) Date: Thu, 13 Apr 2017 13:20:31 -0400 Subject: Snapcraft Digest, Vol 12, Issue 18 In-Reply-To: References: Message-ID: I just watched both videos on the channel, good stuff! I had taken an initial look at snapcraft, ran into some difficulties, i.e. not reading enough of the documentation ... and subscribed to this mailing list. The video was enough to inspire me to a proper look at snapcraft. I look forward to more Steve On 2017-04-13 08:00 AM, snapcraft-request at lists.snapcraft.io Alan Pope wrote: Subscribe to the [snapcraft.io YouTube channel at https://www.youtube.com/channel/UCcH6oAZ0FOSVUMUAojHtFBg to get notified when new videos come out! If you have any requests for particular aspects of snaps / snapcraft, let me know and I'll see what we can do! https://www.youtube.com/watch?v=DLxqdf89hRo From denisnone at gmail.com Fri Apr 14 13:11:30 2017 From: denisnone at gmail.com (Denis S) Date: Fri, 14 Apr 2017 16:11:30 +0300 Subject: ERROR cannot finish core installation, there was a rollback across reboot Message-ID: Hello, I have a custom board where I've installed Ubuntu Core with a self-made kernel snap and a gadget snap. It seems that it works but the core snap doesn't get updated. I've changed ubuntu-image parameters to switch from stable channel to edge channel. The problem persists but at least there is a log info at the end of "snap change" command in the "edge" version of the core snap. RaspberyPi3 can switch core snaps without problems (using standard image with 4.4 xenial kernel). It hangs "Doing" setup security profiles (phase 2) but after the planned reboot it shows that every stage was successful, even phase 2. My platforms hangs on the same stage but after reboot I see a rollback. Hang doesn't mean at all. The symbol [/] keeps spinning but never finishes before 10 min reboot timeout. My kernel is: $ uname -a Linux localhost.localdomain 4.10.1-dac_cpu+ #1 SMP Mon Apr 10 13:07:34 CEST 2017 armv7l armv7l armv7l GNU/Linux I've tried a custom kernel – had problems with AppArmor. It seems like kernels derived from mainline kernels without Ubuntu patches doesn't have an option to bypass AppArmor for processes started by systemd. In that case I could not even install Avahi snap – AppArmor denied all system level hooks of Avahi. Tried Xenial kernel – doesn't boot. Didn't have enough time to investigate but all in all 4.4 is not an option as I need some commits incorporated in 4.8. Backporting them to 4.4 would've be an enormous work. But then I decided to try a Zesty kernel from a master branch. It works pretty well, Avahi installs and works. Initial boot installs all snaps, even core snap but then afterwards the core snap can't be updated when a new version comes out. Can it be related to kernel? Or maybe because of a failed device initialization when it was said "ERROR cannot retrieve request-id for making a request for a serial"? Something else? –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– $ snap change 23 Status Spawn Ready Summary Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Download snap "core" (1709) from channel "edge" Done 2017-04-14T10:09:36Z 2017-04-13T13:44:17Z Fetch and check assertions for snap "core" (1709) Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:21Z Mount snap "core" (1709) Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:20Z Stop snap "core" services Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:20Z Remove aliases for snap "core" Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Make current revision for snap "core" unavailable Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Copy snap "core" data Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Setup snap "core" (1709) security profiles Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:17Z Make snap "core" (1709) available to the system Error 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Setup snap "core" (1709) security profiles (phase 2) Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Set automatic aliases for snap "core" Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Setup snap "core" aliases Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Start snap "core" (1709) services Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Clean up "core" (1709) install Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Run configure hook of "core" snap if present ...................................................................... Setup snap "core" (1709) security profiles 2017-04-14T10:11:58Z INFO cannot auto connect network-manager:ppp to core:ppp: (slot auto-connection), existing connection state "network-manager:ppp core:ppp" in the way 2017-04-13T13:44:18Z INFO cannot auto connect core:core-support-plug to core:core-support: (plug auto-connection), existing connection state "core:core-support-plug core:core-support" in the way 2017-04-13T13:44:18Z INFO cannot auto connect alsa-utils:alsa to core:alsa: (slot auto-connection), existing connection state "alsa-utils:alsa core:alsa" in the way 2017-04-13T13:44:18Z INFO cannot auto connect core:core-support-plug to core:core-support: (slot auto-connection), existing connection state "core:core-support-plug core:core-support" in the way 2017-04-13T13:44:18Z INFO cannot auto connect network-manager:firewall-control to core:firewall-control: (slot auto-connection), existing connection state "network-manager:firewall-control core:firewall-control" in the way 2017-04-13T13:44:18Z INFO cannot auto connect avahi:network to core:network: (slot auto-connection), existing connection state "avahi:network core:network" in the way 2017-04-13T13:44:18Z INFO cannot auto connect avahi:network-bind to core:network-bind: (slot auto-connection), existing connection state "avahi:network-bind core:network-bind" in the way 2017-04-13T13:44:18Z INFO cannot auto connect avahi:network-control to core:network-control: (slot auto-connection), existing connection state "avahi:network-control core:network-control" in the way 2017-04-13T13:44:18Z INFO cannot auto connect network-manager:network-setup-observe to core:network-setup-observe: (slot auto-connection), existing connection state "network-manager:network-setup-observe core:network-setup-observe" in the way 2017-04-13T13:44:18Z INFO cannot auto connect network-manager:ppp to core:ppp: (slot auto-connection), existing connection state "network-manager:ppp core:ppp" in the way ...................................................................... Make snap "core" (1709) available to the system 2017-04-14T10:12:01Z INFO Requested system restart. ...................................................................... Setup snap "core" (1709) security profiles (phase 2) 2017-04-14T10:12:01Z INFO Waiting for restart... 2017-04-14T10:14:33Z INFO Waiting for restart... 2017-04-14T10:19:33Z INFO Waiting for restart... 2017-04-13T13:44:16Z ERROR cannot finish core installation, there was a rollback across reboot Best regards, Denis S denisnone at gmail.com From eloy.garcia.pca at gmail.com Sun Apr 16 21:13:45 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Sun, 16 Apr 2017 23:13:45 +0200 Subject: Executing a script inside snap package. Is this possible? Message-ID: Hello everybody. I develop a graphical java-based application which is published in the Ubuntu Store as a snap package (sctrict confinment) called wallpaperdownloader to download, manage and set desktop wallpapers. I'm developing version 2.7 which will bring KDE support, but for this I need to execute a shell script from Java. In classic confinement and natively, this script is executed without problems. I use this code to do it: process = Runtime.getRuntime().exec("/bin/sh " + WDUtilities.getAppPath() + WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " + wallpaperPath); As you can see, I use /bin/sh command to run the script. This is the content of the script: #!/bin/bash # Changing wallpaper qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript "var allDesktops = desktops();print (allDesktops);for (i=0;i References: Message-ID: Running a script inside of your snap with either /bin/sh or /bin/bash should be no problem at all. However looking at your script I see that you're making dbus calls out to the Plasma Shell, and that *will* be blocked by the strict confinement. You will probably need to get a snapd interface created to support this dbus interface, or maybe you can use the generic 'dbus' interface and specify this service, which would have to be manuall connected. I'm hoping someone from the snapd or security teams can chime in and be more specific about what your options are here. Michael Hall mhall119 at ubuntu.com On 04/16/2017 05:13 PM, Eloy García (PC Actual) wrote: > Hello everybody. > > I develop a graphical java-based application which is published in the > Ubuntu Store as a snap package (sctrict confinment) called > wallpaperdownloader to download, manage and set desktop wallpapers. > > I'm developing version 2.7 which will bring KDE support, but for this I > need to execute a shell script from Java. In classic confinement and > natively, this script is executed without problems. I use this code to do > it: > > process = Runtime.getRuntime().exec("/bin/sh " + WDUtilities.getAppPath() + > WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " + wallpaperPath); > > As you can see, I use /bin/sh command to run the script. This is the > content of the script: > > #!/bin/bash > > # Changing wallpaper > qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript > "var allDesktops = desktops();print (allDesktops);for > (i=0;i allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup = > Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image', > 'file://"$1"')}" > > This command changes the current wallpaper for version 5.8 or higher in > Plasma. > > When this part is executed within the snap package (strict confinement), > nothing happens. I have tried to include bash and dash pacakges as > stage-packages but it doesn work. Is this something that can be achieved > using the snap package system? > > Thank you very much! > > Best, > > Eloy > From eloy.garcia.pca at gmail.com Mon Apr 17 04:55:04 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Mon, 17 Apr 2017 06:55:04 +0200 Subject: Executing a script inside snap package. Is this possible? In-Reply-To: References: Message-ID: Thank you very much for your answer Michel. I hope somebody from snapd or security team can help too :) El 17 abr. 2017 3:07 a. m., "Michael Hall" escribió: > Running a script inside of your snap with either /bin/sh or /bin/bash > should be no problem at all. However looking at your script I see that > you're making dbus calls out to the Plasma Shell, and that *will* be > blocked by the strict confinement. > > You will probably need to get a snapd interface created to support this > dbus interface, or maybe you can use the generic 'dbus' interface and > specify this service, which would have to be manuall connected. I'm > hoping someone from the snapd or security teams can chime in and be more > specific about what your options are here. > > Michael Hall > mhall119 at ubuntu.com > > On 04/16/2017 05:13 PM, Eloy García (PC Actual) wrote: > > Hello everybody. > > > > I develop a graphical java-based application which is published in the > > Ubuntu Store as a snap package (sctrict confinment) called > > wallpaperdownloader to download, manage and set desktop wallpapers. > > > > I'm developing version 2.7 which will bring KDE support, but for this I > > need to execute a shell script from Java. In classic confinement and > > natively, this script is executed without problems. I use this code to do > > it: > > > > process = Runtime.getRuntime().exec("/bin/sh " + > WDUtilities.getAppPath() + > > WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " + > wallpaperPath); > > > > As you can see, I use /bin/sh command to run the script. This is the > > content of the script: > > > > #!/bin/bash > > > > # Changing wallpaper > > qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell. > evaluateScript > > "var allDesktops = desktops();print (allDesktops);for > > (i=0;i > allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup > = > > Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image', > > 'file://"$1"')}" > > > > This command changes the current wallpaper for version 5.8 or higher in > > Plasma. > > > > When this part is executed within the snap package (strict confinement), > > nothing happens. I have tried to include bash and dash pacakges as > > stage-packages but it doesn work. Is this something that can be achieved > > using the snap package system? > > > > Thank you very much! > > > > Best, > > > > Eloy > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From roberto.escandon at canonical.com Mon Apr 17 08:17:46 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Mon, 17 Apr 2017 10:17:46 +0200 Subject: Executing a script inside snap package. Is this possible? In-Reply-To: References: Message-ID: Hey Eloy, Maybe you have already tried this, but just in case, you can debug the snap in confined mode [1], to see if there are some apparmor or seccomp denials. That would give you some clues about what is causing snap not to work and suggested solution. sudo snap install snappy-debug sudo snappy-debug.security scanlog Take a look also at /var/log/syslog Cheers. [1] https://snapcraft.io/docs/build-snaps/debugging On 16/04/17 23:13, Eloy García (PC Actual) wrote: > Hello everybody. > > I develop a graphical java-based application which is published in the > Ubuntu Store as a snap package (sctrict confinment) called > wallpaperdownloader to download, manage and set desktop wallpapers. > > I'm developing version 2.7 which will bring KDE support, but for this I > need to execute a shell script from Java. In classic confinement and > natively, this script is executed without problems. I use this code to do > it: > > process = Runtime.getRuntime().exec("/bin/sh " + WDUtilities.getAppPath() + > WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " + wallpaperPath); > > As you can see, I use /bin/sh command to run the script. This is the > content of the script: > > #!/bin/bash > > # Changing wallpaper > qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell.evaluateScript > "var allDesktops = desktops();print (allDesktops);for > (i=0;i allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup = > Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image', > 'file://"$1"')}" > > This command changes the current wallpaper for version 5.8 or higher in > Plasma. > > When this part is executed within the snap package (strict confinement), > nothing happens. I have tried to include bash and dash pacakges as > stage-packages but it doesn work. Is this something that can be achieved > using the snap package system? > > Thank you very much! > > Best, > > Eloy > -- -- . Roberto Mier Escandón. . Software Engineer . . Canonical - Solutions Engineering -- From eloy.garcia.pca at gmail.com Mon Apr 17 12:24:52 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Mon, 17 Apr 2017 14:24:52 +0200 Subject: Executing a script inside snap package. Is this possible? In-Reply-To: References: Message-ID: Hi Roberto, Thanks for the hint. No, I have never used the snappy debugger, but I'll try when I have time. Thanks again!!! Eloy 2017-04-17 10:17 GMT+02:00 Roberto Mier Escandón  < roberto.escandon at canonical.com>: > Hey Eloy, > > Maybe you have already tried this, but just in case, you can debug the > snap in confined mode [1], to see if there are some apparmor or seccomp > denials. That would give you some clues about what is causing snap not > to work and suggested solution. > > sudo snap install snappy-debug > sudo snappy-debug.security scanlog > > Take a look also at /var/log/syslog > > Cheers. > > [1] https://snapcraft.io/docs/build-snaps/debugging > > On 16/04/17 23:13, Eloy García (PC Actual) wrote: > > Hello everybody. > > > > I develop a graphical java-based application which is published in the > > Ubuntu Store as a snap package (sctrict confinment) called > > wallpaperdownloader to download, manage and set desktop wallpapers. > > > > I'm developing version 2.7 which will bring KDE support, but for this I > > need to execute a shell script from Java. In classic confinement and > > natively, this script is executed without problems. I use this code to do > > it: > > > > process = Runtime.getRuntime().exec("/bin/sh " + > WDUtilities.getAppPath() + > > WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " + > wallpaperPath); > > > > As you can see, I use /bin/sh command to run the script. This is the > > content of the script: > > > > #!/bin/bash > > > > # Changing wallpaper > > qdbus org.kde.plasmashell /PlasmaShell org.kde.PlasmaShell. > evaluateScript > > "var allDesktops = desktops();print (allDesktops);for > > (i=0;i > allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup > = > > Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image', > > 'file://"$1"')}" > > > > This command changes the current wallpaper for version 5.8 or higher in > > Plasma. > > > > When this part is executed within the snap package (strict confinement), > > nothing happens. I have tried to include bash and dash pacakges as > > stage-packages but it doesn work. Is this something that can be achieved > > using the snap package system? > > > > Thank you very much! > > > > Best, > > > > Eloy > > > > -- > -- > . Roberto Mier Escandón. > . Software Engineer > . > . Canonical - Solutions Engineering > -- > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- Eloy García Almadén From jamie at canonical.com Mon Apr 17 14:13:52 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 17 Apr 2017 09:13:52 -0500 Subject: Executing a script inside snap package. Is this possible? In-Reply-To: References: Message-ID: <1492438432.4546.1.camel@canonical.com> On Sun, 2017-04-16 at 21:06 -0400, Michael Hall wrote: > Running a script inside of your snap with either /bin/sh or /bin/bash > should be no problem at all. However looking at your script I see that > you're making dbus calls out to the Plasma Shell, and that *will* be > blocked by the strict confinement. > > You will probably need to get a snapd interface created to support this > dbus interface, or maybe you can use the generic 'dbus' interface and > specify this service, which would have to be manuall connected. I'm > hoping someone from the snapd or security teams can chime in and be more > specific about what your options are here. > It looks like your script is using qdbus to tell the PlasmaShell to run a script for changing the wallpaper to something your snap specifies. Assuming your snap ships qdbus, then the 'only' thing that would be required would be to add a snappy interface to allow access to this dbus call. A few things things: 1. today we have the 'unity7' interface for use on classic distributions. We'll  be introducing gnome and plasma interfaces for running snaps under those DEs 2. it looks like your qdbus command is sending a script over for PlasmaShell to  execute. Since plasma shell runs the script in the context of plasma (ie,  unconfined), this would allow breaking out of application confinement. If  this snappy interface was added, it would be considered a privileged  interface 3. is there another wallpaper API or standard KDE command line utility that can  be used instead of plasmashell that doesn't allow breaking out of  confinement? If so, I recommend using that instead-- then perhaps we can add  a 'desktop-wallpaper' interface. For now, feel free to use 'confinement: devmode' in your snap and please file a bug (with the 'snapd-interface' tag) here to request your interface addition: https://bugs.launchpad.net/snapd/+filebug > Michael Hall > mhall119 at ubuntu.com > > On 04/16/2017 05:13 PM, Eloy García (PC Actual) wrote: > > Hello everybody. > > > > I develop a graphical java-based application which is published in the > > Ubuntu Store as a snap package (sctrict confinment) called > > wallpaperdownloader to download, manage and set desktop wallpapers. > > > > I'm developing version 2.7 which will bring KDE support, but for this I > > need to execute a shell script from Java. In classic confinement and > > natively, this script is executed without problems. I use this code to do > > it: > > > > process = Runtime.getRuntime().exec("/bin/sh " + WDUtilities.getAppPath() + > > WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " +  wallpaperPath); > > > > As you can see, I use /bin/sh command to run the script. This is the > > content of the script: > > > > #!/bin/bash > > > > # Changing wallpaper > > qdbus org.kde.plasmashell /PlasmaShell > > org.kde.PlasmaShell.evaluateScript > > "var allDesktops = desktops();print (allDesktops);for > > (i=0;i > allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup = > > Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image', > > 'file://"$1"')}" > > > > This command changes the current wallpaper for version 5.8 or higher in > > Plasma. > > > > When this part is executed within the snap package (strict confinement), > > nothing happens. I have tried to include bash and dash pacakges as > > stage-packages but it doesn work. Is this something that can be achieved > > using the snap package system? > > > > Thank you very much! > > > > Best, > > > > Eloy > > > > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From eloy.garcia.pca at gmail.com Tue Apr 18 13:14:33 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 18 Apr 2017 15:14:33 +0200 Subject: Executing a script inside snap package. Is this possible? In-Reply-To: <1492438432.4546.1.camel@canonical.com> References: <1492438432.4546.1.camel@canonical.com> Message-ID: Hi Jamie! Thanks for the response. i'll come back to you later when I can check and test some of the suggestions you have made :) Best, Eloy 2017-04-17 16:13 GMT+02:00 Jamie Strandboge : > On Sun, 2017-04-16 at 21:06 -0400, Michael Hall wrote: > > Running a script inside of your snap with either /bin/sh or /bin/bash > > should be no problem at all. However looking at your script I see that > > you're making dbus calls out to the Plasma Shell, and that *will* be > > blocked by the strict confinement. > > > > You will probably need to get a snapd interface created to support this > > dbus interface, or maybe you can use the generic 'dbus' interface and > > specify this service, which would have to be manuall connected. I'm > > hoping someone from the snapd or security teams can chime in and be more > > specific about what your options are here. > > > It looks like your script is using qdbus to tell the PlasmaShell to run a > script > for changing the wallpaper to something your snap specifies. Assuming your > snap > ships qdbus, then the 'only' thing that would be required would be to add a > snappy interface to allow access to this dbus call. > > A few things things: > > 1. today we have the 'unity7' interface for use on classic distributions. > We'll > be introducing gnome and plasma interfaces for running snaps under > those DEs > 2. it looks like your qdbus command is sending a script over for > PlasmaShell to > execute. Since plasma shell runs the script in the context of plasma > (ie, > unconfined), this would allow breaking out of application confinement. > If > this snappy interface was added, it would be considered a privileged > interface > 3. is there another wallpaper API or standard KDE command line utility > that can > be used instead of plasmashell that doesn't allow breaking out of > confinement? If so, I recommend using that instead-- then perhaps we > can add > a 'desktop-wallpaper' interface. > > For now, feel free to use 'confinement: devmode' in your snap and please > file a > bug (with the 'snapd-interface' tag) here to request your interface > addition: > > https://bugs.launchpad.net/snapd/+filebug > > > > Michael Hall > > mhall119 at ubuntu.com > > > > On 04/16/2017 05:13 PM, Eloy García (PC Actual) wrote: > > > Hello everybody. > > > > > > I develop a graphical java-based application which is published in the > > > Ubuntu Store as a snap package (sctrict confinment) called > > > wallpaperdownloader to download, manage and set desktop wallpapers. > > > > > > I'm developing version 2.7 which will bring KDE support, but for this I > > > need to execute a shell script from Java. In classic confinement and > > > natively, this script is executed without problems. I use this code to > do > > > it: > > > > > > process = Runtime.getRuntime().exec("/bin/sh " + > WDUtilities.getAppPath() + > > > WDUtilities.URL_SLASH + WDUtilities.PLASMA_SCRIPT + " " > + wallpaperPath); > > > > > > As you can see, I use /bin/sh command to run the script. This is the > > > content of the script: > > > > > > #!/bin/bash > > > > > > # Changing wallpaper > > > qdbus org.kde.plasmashell /PlasmaShell > > > org.kde.PlasmaShell.evaluateScript > > > "var allDesktops = desktops();print (allDesktops);for > > > (i=0;i > > allDesktops[i];d.wallpaperPlugin = 'org.kde.image';d.currentConfigGroup > = > > > Array('Wallpaper', 'org.kde.image', 'General');d.writeConfig('Image', > > > 'file://"$1"')}" > > > > > > This command changes the current wallpaper for version 5.8 or higher in > > > Plasma. > > > > > > When this part is executed within the snap package (strict > confinement), > > > nothing happens. I have tried to include bash and dash pacakges as > > > stage-packages but it doesn work. Is this something that can be > achieved > > > using the snap package system? > > > > > > Thank you very much! > > > > > > Best, > > > > > > Eloy > > > > > > > > -- > Jamie Strandboge | http://www.canonical.com > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Eloy García Almadén From denisnone at gmail.com Tue Apr 18 16:13:47 2017 From: denisnone at gmail.com (Denis S) Date: Tue, 18 Apr 2017 19:13:47 +0300 Subject: ERROR cannot finish core installation, there was a rollback across reboot Message-ID: <5C313A26-ECB3-4B79-8BE6-29B52A982EAD@gmail.com> Hello, I have a custom board where I've installed Ubuntu Core with a self-made kernel snap and a gadget snap. It seems that it works but the core snap doesn't get updated. I've changed ubuntu-image parameters to switch from stable channel to edge channel. The problem persists but at least there is a log info at the end of "snap change" command in the "edge" version of the core snap. RaspberyPi3 can switch core snaps without problems (using standard image with 4.4 xenial kernel). It hangs "Doing" setup security profiles (phase 2) but after the planned reboot it shows that every stage was successful, even phase 2. My platforms hangs on the same stage but after reboot I see a rollback. Hang doesn't mean at all. The symbol [/] keeps spinning but never finishes before 10 min reboot timeout. My kernel is: $ uname -a Linux localhost.localdomain 4.10.1-dac_cpu+ #1 SMP Mon Apr 10 13:07:34 CEST 2017 armv7l armv7l armv7l GNU/Linux I've tried a custom kernel – had problems with AppArmor. It seems like kernels derived from mainline kernels without Ubuntu patches doesn't have an option to bypass AppArmor for processes started by systemd. In that case I could not even install Avahi snap – AppArmor denied all system level hooks of Avahi. Tried Xenial kernel – doesn't boot. Didn't have enough time to investigate but all in all 4.4 is not an option as I need some commits incorporated in 4.8. Backporting them to 4.4 would've be an enormous work. But then I decided to try a Zesty kernel from a master branch. It works pretty well, Avahi installs and works. Initial boot installs all snaps, even core snap but then afterwards the core snap can't be updated when a new version comes out. Can it be related to kernel? Or maybe because of a failed device initialization when it was said "ERROR cannot retrieve request-id for making a request for a serial"? Something else? –––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– $ snap change 23 Status Spawn Ready Summary Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Download snap "core" (1709) from channel "edge" Done 2017-04-14T10:09:36Z 2017-04-13T13:44:17Z Fetch and check assertions for snap "core" (1709) Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:21Z Mount snap "core" (1709) Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:20Z Stop snap "core" services Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:20Z Remove aliases for snap "core" Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Make current revision for snap "core" unavailable Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Copy snap "core" data Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:19Z Setup snap "core" (1709) security profiles Undone 2017-04-14T10:09:36Z 2017-04-13T13:44:17Z Make snap "core" (1709) available to the system Error 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Setup snap "core" (1709) security profiles (phase 2) Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Set automatic aliases for snap "core" Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Setup snap "core" aliases Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Start snap "core" (1709) services Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Clean up "core" (1709) install Hold 2017-04-14T10:09:36Z 2017-04-13T13:44:16Z Run configure hook of "core" snap if present ...................................................................... Setup snap "core" (1709) security profiles 2017-04-14T10:11:58Z INFO cannot auto connect network-manager:ppp to core:ppp: (slot auto-connection), existing connection state "network-manager:ppp core:ppp" in the way 2017-04-13T13:44:18Z INFO cannot auto connect core:core-support-plug to core:core-support: (plug auto-connection), existing connection state "core:core-support-plug core:core-support" in the way 2017-04-13T13:44:18Z INFO cannot auto connect alsa-utils:alsa to core:alsa: (slot auto-connection), existing connection state "alsa-utils:alsa core:alsa" in the way 2017-04-13T13:44:18Z INFO cannot auto connect core:core-support-plug to core:core-support: (slot auto-connection), existing connection state "core:core-support-plug core:core-support" in the way 2017-04-13T13:44:18Z INFO cannot auto connect network-manager:firewall-control to core:firewall-control: (slot auto-connection), existing connection state "network-manager:firewall-control core:firewall-control" in the way 2017-04-13T13:44:18Z INFO cannot auto connect avahi:network to core:network: (slot auto-connection), existing connection state "avahi:network core:network" in the way 2017-04-13T13:44:18Z INFO cannot auto connect avahi:network-bind to core:network-bind: (slot auto-connection), existing connection state "avahi:network-bind core:network-bind" in the way 2017-04-13T13:44:18Z INFO cannot auto connect avahi:network-control to core:network-control: (slot auto-connection), existing connection state "avahi:network-control core:network-control" in the way 2017-04-13T13:44:18Z INFO cannot auto connect network-manager:network-setup-observe to core:network-setup-observe: (slot auto-connection), existing connection state "network-manager:network-setup-observe core:network-setup-observe" in the way 2017-04-13T13:44:18Z INFO cannot auto connect network-manager:ppp to core:ppp: (slot auto-connection), existing connection state "network-manager:ppp core:ppp" in the way ...................................................................... Make snap "core" (1709) available to the system 2017-04-14T10:12:01Z INFO Requested system restart. ...................................................................... Setup snap "core" (1709) security profiles (phase 2) 2017-04-14T10:12:01Z INFO Waiting for restart... 2017-04-14T10:14:33Z INFO Waiting for restart... 2017-04-14T10:19:33Z INFO Waiting for restart... 2017-04-13T13:44:16Z ERROR cannot finish core installation, there was a rollback across reboot Best regards, Denis S denisnone at gmail.com From vinzjobard at gmail.com Tue Apr 18 21:10:49 2017 From: vinzjobard at gmail.com (Vincent JOBARD) Date: Tue, 18 Apr 2017 21:10:49 +0000 Subject: Issues creating webapps snaps with stric confinement In-Reply-To: References: Message-ID: Hi all, It seems that's a proxy issue since the webapps works well at home. Is there a way to use a webapp through a proxy by the way ? The one I use at work is very specific I have to use cntlm to go to Internet Thx for your the answers you gave me Cheers Winael On Tue, Apr 4, 2017 at 1:40 PM XiaoGuo Liu wrote: > Hi Winael, > > Have you seen the tutorial at > https://tutorials.ubuntu.com/tutorial/snap-a-website#0? > > Best regards, > XiaoGuo > > On Fri, Mar 31, 2017 at 9:28 PM, Vincent JOBARD > wrote: > > > Hi Everyone > > > > I just try to follow the tutorial to learn how to create webapps snaps > > using snapcraft. ( > > https://developer.ubuntu.com/en/phone/web/ubuntu-webapps-guide/, very > nice > > tutorial by the way) > > > > Unfortunately, when I try to create my snap with strict confinement, I > have > > a network Error page, but all works fine in devmode. > > > > I'm at work behind a proxy with cntlm authentification. could it be > related > > ? > > > > Thx for your answers guys > > > > Cheers > > Winael > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > > mailman/listinfo/snapcraft > > > > > > -- > XiaoGuo, Liu > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From james.jesudason at canonical.com Wed Apr 19 08:42:55 2017 From: james.jesudason at canonical.com (James Jesudason) Date: Wed, 19 Apr 2017 09:42:55 +0100 Subject: Issues creating webapps snaps with stric confinement In-Reply-To: References: Message-ID: I'm not sure where the documentation for proxies is, but you need to configure the proxy on the machine in either one or two places: - /etc/systemd/system/snapd.service.d/snap_layer_proxy.conf - /var/snap//common/config I haven't seen full confirmation of this anywhere, but I think that the first setting is for snapd itself i.e. so it can use the proxy to access the store (for refreshing snaps). The second seems to be the proxy for the application. You can see examples of these in a couple of charms: - https://github.com/stub42/layer-snap/blob/master/reactive/snap.py#L86 - https://git.launchpad.net/canonical-livepatch-charm/tree/reactive/canonical_livepatch.py#n106 After the config changes, a daemon-reload and snapd.service restart is required (you can see that in the charms). On 18 April 2017 at 22:10, Vincent JOBARD wrote: > Hi all, > > It seems that's a proxy issue since the webapps works well at home. Is > there a way to use a webapp through a proxy by the way ? > > The one I use at work is very specific I have to use cntlm to go to > Internet > > Thx for your the answers you gave me > > Cheers > Winael > > On Tue, Apr 4, 2017 at 1:40 PM XiaoGuo Liu > wrote: > >> Hi Winael, >> >> Have you seen the tutorial at >> https://tutorials.ubuntu.com/tutorial/snap-a-website#0? >> >> Best regards, >> XiaoGuo >> >> On Fri, Mar 31, 2017 at 9:28 PM, Vincent JOBARD >> wrote: >> >> > Hi Everyone >> > >> > I just try to follow the tutorial to learn how to create webapps snaps >> > using snapcraft. ( >> > https://developer.ubuntu.com/en/phone/web/ubuntu-webapps-guide/, very >> nice >> > tutorial by the way) >> > >> > Unfortunately, when I try to create my snap with strict confinement, I >> have >> > a network Error page, but all works fine in devmode. >> > >> > I'm at work behind a proxy with cntlm authentification. could it be >> related >> > ? >> > >> > Thx for your answers guys >> > >> > Cheers >> > Winael >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> > mailman/listinfo/snapcraft >> > >> >> >> >> -- >> XiaoGuo, Liu >> -- >> 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 From olivier.tilloy at canonical.com Wed Apr 19 10:01:59 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Wed, 19 Apr 2017 12:01:59 +0200 Subject: Issues creating webapps snaps with stric confinement In-Reply-To: References: Message-ID: On Tue, Apr 18, 2017 at 11:10 PM, Vincent JOBARD wrote: > Hi all, > > It seems that's a proxy issue since the webapps works well at home. Is > there a way to use a webapp through a proxy by the way ? webapp-launcher, being based on oxide, should be proxy-aware if the correct environment variables are set within the snap’s environment (HTTP_PROXY or ALL_PROXY). > The one I use at work is very specific I have to use cntlm to go to > Internet > > Thx for your the answers you gave me > > Cheers > Winael > > On Tue, Apr 4, 2017 at 1:40 PM XiaoGuo Liu > wrote: > >> Hi Winael, >> >> Have you seen the tutorial at >> https://tutorials.ubuntu.com/tutorial/snap-a-website#0? >> >> Best regards, >> XiaoGuo >> >> On Fri, Mar 31, 2017 at 9:28 PM, Vincent JOBARD >> wrote: >> >> > Hi Everyone >> > >> > I just try to follow the tutorial to learn how to create webapps snaps >> > using snapcraft. ( >> > https://developer.ubuntu.com/en/phone/web/ubuntu-webapps-guide/, very >> nice >> > tutorial by the way) >> > >> > Unfortunately, when I try to create my snap with strict confinement, I >> have >> > a network Error page, but all works fine in devmode. >> > >> > I'm at work behind a proxy with cntlm authentification. could it be >> related >> > ? >> > >> > Thx for your answers guys >> > >> > Cheers >> > Winael >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> > mailman/listinfo/snapcraft >> > >> >> >> >> -- >> XiaoGuo, Liu >> -- >> 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 From kyle.fazzari at canonical.com Wed Apr 19 16:55:57 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 19 Apr 2017 09:55:57 -0700 Subject: ROS Production part 3: Our prototype as a snap Message-ID: The third blog and video of the series has been posted, where we package the ROS prototype we created in part 2 as a snap. Blog post: https://kyrofa.com/posts/ros-production-our-prototype-as-a-snap-3-5 Video: https://youtu.be/Dw1aqbucPbY?list=PL1LO5F1-Jh8K6R1Ba23irALtey6CRFFYu -- 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 gustavo.niemeyer at canonical.com Wed Apr 19 21:27:16 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 19 Apr 2017 18:27:16 -0300 Subject: Snapcraft list integrated into forum Message-ID: Hello all, We're almost done integrating the traditional snapcraft mailing list and the forum. You may still use it via email if that's your preference. For details please see this topic: https://forum.snapcraft.io/t/integration-of-snapcraft-mailing-list/330 -- gustavo @ http://niemeyer.net