From james.henstridge at canonical.com Wed Mar 1 00:37:08 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Wed, 1 Mar 2017 08:37:08 +0800 Subject: Experimental Python interpreter snap In-Reply-To: References: <20170221103712.71207030@subdivisions.wooz.org> Message-ID: On 23 February 2017 at 19:34, Stuart Bishop wrote: > On 23 February 2017 at 14:45, James Henstridge > wrote: > >> So if I installed a package to $SNAP_USER_DATA for my >> "python36-jamesh.python3" interpreter, the files would end up >> somewhere under ~/snap/python36-jamesh/. >> >> If we then look at my simple hello-world example snap that uses the >> content interface to access the interpreter, $SNAP_USER_DATA now >> points to a location under ~/snap/hello-world/. So it wouldn't see >> the additional packages installed for "python36-jamesh.python3". In >> fact, the hello-world snap doesn't even have permission to read files >> under ~/snap/python36-jamesh, even if I put that directory on >> sys.path. > > Yes, exactly. If I use the python36-jamesh.python3 interpreter from my > main shell, I can pip install libraries into $SNAP_USER_DATA and use > them. They will not be seen or cause conflicts if I use the > /usr/bin/python3, which is what I'm suggesting is an improvement. And > they will not be seen by or cause conflicts with snaps using the > content interface, no matter if they are confined or classic, which is > also a good thing because they will be embedding their dependencies. I put together a new build of my snap that should cover the developer use case a bit better. You can install it in an unconfined mode with the following command: $ snap install --edge --classic python36-jamesh python36-jamesh (edge) 3.6.0 from 'jamesh' installed It has a usable pip3 (provided you do a --user install): $ python36-jamesh.pip3 install --user django Collecting django Downloading Django-1.10.5-py2.py3-none-any.whl (6.8MB) 100% |################################| 6.8MB 173kB/s Installing collected packages: django Successfully installed django-1.10.5 Which results in the package being installed to the python36-jamesh package's $SNAP_USER_COMMON directory: $ python36-jamesh.python3 Python 3.6.0 (default, Feb 28 2017, 23:29:31) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import django >>> django.__file__ '/home/james/snap/python36-jamesh/common/lib/python3.6/django/__init__.py' >>> When used via content interface by other snaps, it should act the same as the previous build. And from a security perspective, it doesn't matter whether the interpreter is installed with --classic or not, since it will use the plug snap's policies when used via content interface. I also managed to get this update to build across all of i386, amd64, armhf, and arm64 by building with a backported version of patchelf: the package was missing for armhf on xenial due to a test failure. James. From michael.hudson at canonical.com Wed Mar 1 02:11:54 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Wed, 1 Mar 2017 15:11:54 +1300 Subject: getting $LDFLAGS for a classic snap build in the plugin Message-ID: Hi, The magic of classic confinement snaps is all in passing special flags when linking an executable. If I've read things right, snapcraft does this by wrapping any command you execute with BasePlugin.run() with some shell code that sets LDFLAGS. Unfortunately, for the go classic snap the underlying tool does not care at all about LDFLAGS. What I do is create a wrapper: #!/bin/sh exec gcc $LDFLAGS "$@" and point the go tool at that. This works but it would be a lot cleaner if I could just get at the linker flags in my snap's plugin. Any chance that could be added? Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Wed Mar 1 08:11:00 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Wed, 1 Mar 2017 09:11:00 +0100 Subject: snapcraft 2.27 has been released In-Reply-To: References: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> Message-ID: <50bb021f-0973-3da2-578b-4c339f4043e3@canonical.com> Yes, that's what I'am doing. So, the conclusion I get from this is that environment is only valuable in the need of setting a few additional env vars. Btw, forget my last mail about the stop command not taking those values. It is working perfectly. Thanks, Cheers! On 01/03/17 00:37, XiaoGuo Liu wrote: > Hi Roberto, > > In that case, you can just run your own script in the command in stead of > directly launching your app. In your script, just do whatever thing there. > > Best regards, > XiaoGuo > > On Tue, Feb 28, 2017 at 9:51 PM, Roberto Mier Escandón  < > roberto.escandon at canonical.com> wrote: > >> Hey guys, >> >> Couldn't we have environment property pointing also to a file script as >> in the case of scriptlets. In the case of needing to set a bunch of >> things before launching app I'd prefer having it in that way. >> >> Cheers. >> >> On 24/02/17 20:05, Kyle Fazzari wrote: >>> >>> >>> On 02/24/2017 10:49 AM, Claudio André wrote: >>>> >>>> 2017-02-17 10:49 GMT-02:00 Sergio Schvezov >>>> >: >>>> >>>> Hello snapcrafters! >>>> >>>> ## Setting up environment >>>> >>>> No more wrapper scripts just to setup on environment entry, this is >>>> now tied into an app entry in `apps`. Here's a quick example: >>>> >>>> ```yaml >>>> apps: >>>> vim: >>>> command: bin/vim >>>> environment: >>>> VIMRUNTIME: $SNAP/share/vim/vim80 >>>> ``` >>>> >>>> >>>> Hi, I tried to append to path (see below). It is not supported. >>>> >>>> ```yaml >>>> environment: >>>> PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" >>>> ``` >>>> >>>> I'm ok with it. But, in case this is not by design, I'm mailing you >> guys. >>> >>> I can verify this. To clarify, this builds and runs fine, but actually >>> results in the PATH including the string `$PATH` instead of expanding it. >>> >>> Can a snapd dev comment on this? Is that intended? >>> >>> >>> >> >> -- >> 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 Wed Mar 1 10:37:58 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Wed, 1 Mar 2017 11:37:58 +0100 Subject: weird behaviour related with fonts in a snap Message-ID: <8c0e52e3-4af3-43e1-16c0-57823fcdba90@canonical.com> Hey guys, I'm hitting a weird problem related with fonts in collabora office online snap. This product is a kind of libre office google drive, for you to take a reference how it works as user. If I confine the snap in classic mode all works perfectly. However, if I deploy it in devmode, some parts of the document dissapear depending on the font they are using. Also, If I change the font, the selected font disapears in most of cases (depends on the font to change to). Same if I try to set it as bold. However underline or italic works ok. I've set FONTCONFIG_FILE and FONTCONFIG_PATH to fonts.conf and conf.d respectively and fonts are taken from a path accesible by the snap configured in fonts.conf. Also cachedir is set to a snap internal path. Actually, if fonts where not found, one of the daemons wouldn't start and it does. In source code I don't see any reference to any path related with fonts, however something else outside of the snap is needed and I cannot find what. Anybody has hit any issue with fonts in a snap or something similar to this? Thanks. From james.henstridge at canonical.com Wed Mar 1 10:51:41 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Wed, 1 Mar 2017 18:51:41 +0800 Subject: HOWTO: How to snap timg (text image viewer) In-Reply-To: <0973522F-225F-4D43-9583-AE73CB76349B@canonical.com> References: <0973522F-225F-4D43-9583-AE73CB76349B@canonical.com> Message-ID: On 1 March 2017 at 07:13, Michi Henning wrote: > >> Upon further thinking, I believe that I did not have to use a fresh >> LXD container, because the "strict" confinement would preclude anyway >> the snap from using any of my desktop's existing system libraries. >> Isn't that indeed the case? > > I don’ think so. System libraries are visible even with strict confinement, as far as I know. That's not true. When a command or daemon in a strict mode snap gets executed, it runs in a different mount namespace where the file system root is the contents of the "core" snap. You can verify this by executing the following: snap run --shell command_name .. and use that shell to inspect the file system as seen by that particular command. James. From michi.henning at canonical.com Wed Mar 1 11:11:20 2017 From: michi.henning at canonical.com (Michi Henning) Date: Wed, 1 Mar 2017 21:11:20 +1000 Subject: HOWTO: How to snap timg (text image viewer) In-Reply-To: References: <0973522F-225F-4D43-9583-AE73CB76349B@canonical.com> Message-ID: <80B33C75-EB9E-4934-85DC-0E59C924FDE1@canonical.com> > > That's not true. When a command or daemon in a strict mode snap gets > executed, it runs in a different mount namespace where the file system > root is the contents of the "core" snap. You can verify this by > executing the following: > > snap run --shell command_name > > .. and use that shell to inspect the file system as seen by that > particular command. Ah, OK, I stand corrected. I was probably running in devmode when I picked up system libs. Michi. From jamie at canonical.com Wed Mar 1 14:22:37 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 01 Mar 2017 08:22:37 -0600 Subject: HOWTO: How to snap timg (text image viewer) In-Reply-To: <80B33C75-EB9E-4934-85DC-0E59C924FDE1@canonical.com> References: <0973522F-225F-4D43-9583-AE73CB76349B@canonical.com> <80B33C75-EB9E-4934-85DC-0E59C924FDE1@canonical.com> Message-ID: <1488378157.3921.31.camel@canonical.com> On Wed, 2017-03-01 at 21:11 +1000, Michi Henning wrote: > > > > > > That's not true.  When a command or daemon in a strict mode snap gets > > executed, it runs in a different mount namespace where the file system > > root is the contents of the "core" snap.  You can verify this by > > executing the following: > > > >    snap run --shell command_name > > > > .. and use that shell to inspect the file system as seen by that > > particular command. > Ah, OK, I stand corrected. I was probably running in devmode when I picked up > system libs. > To be clear, wrt the mount namespace, devmode and strict mode are identical. Perhaps you were working with classic confinement where the mount namespace is not setup. -- 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 thibault at jochem.fr Wed Mar 1 14:32:29 2017 From: thibault at jochem.fr (Thibault Jochem) Date: Wed, 1 Mar 2017 15:32:29 +0100 Subject: Advice for non connected ubuntu-core/snap update scenario Message-ID: Hello, I'm studying the possibility tu use ubuntu-core and snaps as base OS / app framework for embedded computers with no access to internet. We can connect to those systems with a maintenance laptop, and I was thinking that this laptop could host a snapd server to push the updates once connected. Is it a good idea or is there a better way to handle such scenario ? Best regards, -- Thibault Jochem Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.curalli at domotz.com Wed Mar 1 15:11:10 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Wed, 1 Mar 2017 15:11:10 +0000 Subject: revoke a gpg key for signing assertions Message-ID: Hi, I hit a problem with key registration e deregistration workflow. I registered a key for my first assertion, then I received a mail from Ubuntu store with the command able to remove a gpg key from backend: snapcraft revoke-key name_of_key This command don't work and produces the following output: snapcraft revoke-key name_of_key Usage: snapcraft [options] [--enable-geoip --no-parallel-build] snapcraft [options] init snapcraft [options] pull [ ...] [--enable-geoip] snapcraft [options] build [ ...] [--no-parallel-build] snapcraft [options] stage [ ...] snapcraft [options] prime [ ...] snapcraft [options] strip [ ...] snapcraft [options] clean [ ...] [--step ] snapcraft [options] snap [ --output ] snapcraft [options] cleanbuild [--remote=] snapcraft [options] login snapcraft [options] logout snapcraft [options] list-registered snapcraft [options] registered snapcraft [options] list-keys snapcraft [options] keys snapcraft [options] create-key [] snapcraft [options] register-key [] snapcraft [options] register [--private] snapcraft [options] sign-build [--key-name=] [--local] snapcraft [options] upload snapcraft [options] push [--release ] snapcraft [options] release snapcraft [options] status [--series=] [--arch=] snapcraft [options] history [--series=] [--arch=] snapcraft [options] close ... snapcraft [options] list-plugins snapcraft [options] plugins snapcraft [options] tour [] snapcraft [options] update snapcraft [options] gated snapcraft [options] validate ... [--key-name=] snapcraft [options] define snapcraft [options] search [ ...] snapcraft [options] enable-ci [] [--refresh] snapcraft [options] help (topics | | ) [--devel] snapcraft (-h | --help) snapcraft --version Snapcraft Launchpad page don't show any bug about this problem. My question: revoke-key function is implemented? Nicolino From kyle.fazzari at canonical.com Wed Mar 1 16:08:17 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 1 Mar 2017 08:08:17 -0800 Subject: snapcraft 2.27 has been released In-Reply-To: <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> References: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> <95825db8-64a1-cc50-8e83-2f2cb62fb685@canonical.com> Message-ID: On 02/28/2017 05:51 AM, Roberto Mier Escandón  wrote: > Hey guys, > > Couldn't we have environment property pointing also to a file script as > in the case of scriptlets. In the case of needing to set a bunch of > things before launching app I'd prefer having it in that way. That's a question for the snapd folks (as that's where the `environment` feature is actually implemented). I will say that running a script before running the app is not quite the same as defining environment variables since a script can do whatever it wants (it may have nothing to do with the environment). In my opinion, a keyword called `environment` is probably not the best place for such a feature. -- 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 me at jamescooke.info Wed Mar 1 21:25:34 2017 From: me at jamescooke.info (James Cooke) Date: Wed, 01 Mar 2017 21:25:34 +0000 Subject: Using docker image to run snapd Message-ID: <1488403534.2815622.897329160.49E32ECA@webmail.messagingengine.com> Hi there, I've been struggling to get an Ubuntu 16.04 based docker image to run `snapd` - TL;DR I now know it is because systemd is not running in the image. As per Geoffroy VanCutsem's message here (https://lists.ubuntu.com/archives/snapcraft/2017-February/003013.html) I can see that one alternative might be to... > start my daemons/services outside of systemd, from a simple script invoked by CMD in my Dockerfile. Could someone point me at a list of services that need to be running to be able to make a `snap install`? And / or any guidance on the commands required to run those services? If anyone is interested in the error that I'm getting it's like this, in a clean `rastasheep/ubuntu-sshd:16.04` instance where I've sshed in as root: root at be16d952b015:~# apt-get install -y snapd Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: apparmor busybox-initramfs cpio initramfs-tools initramfs-tools-bin initramfs-tools-core klibc-utils kmod libapparmor-perl libklibc liblzo2-2 linux-base snap-confine squashfs-tools udev ... Processing triggers for systemd (229-4ubuntu16) ... Processing triggers for libc-bin (2.23-0ubuntu5) ... Processing triggers for initramfs-tools (0.122ubuntu8.8) ... root at be16d952b015:~# snap install hello-world 2017/03/01 20:37:40.864580 main.go:220: WARNING: cannot create syslog logger error: cannot communicate with server: Post http://localhost/v2/snaps/hello-world: dial unix /run/snapd-snap.socket: connect: no such file or directory This appears to be the same error as asked about here: http://askubuntu.com/questions/849859/error-when-trying-to-run-snap-install-from-ubuntu-on-docker (that's me in the comments). Thanks, James -- James Cooke Backend software developer CV PDF: http://jamescooke.info/docs/james_cooke_cv.pdf Website: http://jamescooke.info/ From leo.arias at canonical.com Wed Mar 1 21:56:48 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 1 Mar 2017 15:56:48 -0600 Subject: revoke a gpg key for signing assertions In-Reply-To: References: Message-ID: Hello! Thanks for your report. Can you please report that as a bug? https://bugs.launchpad.net/snapstore From leo.arias at canonical.com Thu Mar 2 00:31:11 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 1 Mar 2017 18:31:11 -0600 Subject: detect video player In-Reply-To: <3c8695a2-0382-11fa-f9b5-cdca0f914e7f@gmail.com> References: <3c8695a2-0382-11fa-f9b5-cdca0f914e7f@gmail.com> Message-ID: So, you want to know from the application itself if it's being run from inside a snap, or not? I don't know if we have something for that, but it certainly seems to be useful. You could check if some of the environment variables are set, but well, of course that can be cheated by exporting the var before running the application. ubuntu at juju-07fb34-remote-devel-0:~$ echo $SNAP ubuntu at juju-07fb34-remote-devel-0:~$ snap run --shell ipfs ubuntu at juju-07fb34-remote-devel-0:/home/ubuntu$ echo $SNAP /snap/ipfs/x1 From leo.arias at canonical.com Thu Mar 2 02:01:01 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 1 Mar 2017 20:01:01 -0600 Subject: Creating and running tests for a snapcraft plugin In-Reply-To: References: Message-ID: Hello! Thanks for working on a new plugin. On Thu, Feb 23, 2017 at 5:13 PM, Joseph Rushton Wakeling wrote: > Is there a simple way to run the tests for a single plugin, rather than the > whole body of tests? The snapcraft HACKING.md doesn't offer any advice on > this point. To run all the tests related to python, for example, you can do something like this: ./runtests.sh unit *python* ./runtests.sh integration *python* That filter is by file name. You can do fancier things with python's discovery: https://docs.python.org/3.5/library/unittest.html#unittest-test-discovery pura vida. From facundo.batista at canonical.com Thu Mar 2 02:06:33 2017 From: facundo.batista at canonical.com (Facundo Batista) Date: Wed, 1 Mar 2017 23:06:33 -0300 Subject: Reading /etc Message-ID: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> Hola! When calling pip from inside a snap, it (while investigating the system it's in) tries to os.listdir("/etc") which is denied to it: Mar 1 15:44:04 tanquita kernel: [16153.906524] audit: type=1400 audit(1488393844.939:99): apparmor="DENIED" operation="open" namespace="root//lxd-fadestest_" profile="snap.fades.fades" name="/etc/" pid=10606 comm="python" requested_mask="r" denied_mask="r" fsuid=165536 ouid=165536 Which interface should I add to the snap for it to have read only access to /etc? Thanks! -- . Facundo . Canonical - Online Services From marco.ceppi at canonical.com Thu Mar 2 02:29:27 2017 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Thu, 02 Mar 2017 02:29:27 +0000 Subject: Reading /etc In-Reply-To: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> References: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> Message-ID: I don't have an answer for you, but wanted to add some color to the problem. The issue lies within a dependency of the latest version of pip. Previously they vendored in a small library to do rudimentary distribution checking. In later versions, they've included the nir0s/distro python package, which does more aggressive checks against things like /etc and is hard coded. I submitted a patch to the distro repo https://github.com/nir0s/distro/issues/149 and it's landed, but it needs to be pulled into pip and release. Once that's done, UNIXCONFDIR environment variable could be used to override where to find `/etc`. For my snap, I ended up moving to classic confinement as it fit better with the tool (a system utility). Marco On Wed, Mar 1, 2017 at 9:07 PM Facundo Batista < facundo.batista at canonical.com> wrote: > Hola! > > When calling pip from inside a snap, it (while investigating the system > it's in) tries to os.listdir("/etc") which is > denied to it: > > Mar 1 15:44:04 tanquita kernel: [16153.906524] audit: type=1400 > audit(1488393844.939:99): apparmor="DENIED" > operation="open" namespace="root//lxd-fadestest_" > profile="snap.fades.fades" name="/etc/" > pid=10606 comm="python" requested_mask="r" denied_mask="r" > fsuid=165536 ouid=165536 > > Which interface should I add to the snap for it to have read only access > to /etc? > > Thanks! > > -- > . Facundo > . > Canonical - Online Services > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vasilisc777 at gmail.com Thu Mar 2 05:02:53 2017 From: vasilisc777 at gmail.com (Vasilisc) Date: Thu, 2 Mar 2017 08:02:53 +0300 Subject: detect video player In-Reply-To: References: <3c8695a2-0382-11fa-f9b5-cdca0f914e7f@gmail.com> Message-ID: <93c61889-9fe5-4fdf-6b47-28ee12cd37a5@gmail.com> 02.03.2017 03:31, Leo Arias пишет: > So, you want to know from the application itself if it's being run > from inside a snap, or not? The program (in snap) needs to find a videoplayers in system. For example, vlc come from snap package (location /snap/vlc/current/...), smplayer - from deb package (location /usr/bin/smplayer). How to find available a video players in host system? > I don't know if we have something for that, but it certainly seems to be useful. > You could check if some of the environment variables are set, but > well, of course that can be cheated by exporting the var before > running the application. > > ubuntu at juju-07fb34-remote-devel-0:~$ echo $SNAP > > ubuntu at juju-07fb34-remote-devel-0:~$ snap run --shell ipfs > ubuntu at juju-07fb34-remote-devel-0:/home/ubuntu$ echo $SNAP > /snap/ipfs/x1 > -- Best regards, vasilisc From seth.arnold at canonical.com Thu Mar 2 06:58:07 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Wed, 1 Mar 2017 22:58:07 -0800 Subject: detect video player In-Reply-To: <93c61889-9fe5-4fdf-6b47-28ee12cd37a5@gmail.com> References: <3c8695a2-0382-11fa-f9b5-cdca0f914e7f@gmail.com> <93c61889-9fe5-4fdf-6b47-28ee12cd37a5@gmail.com> Message-ID: <20170302065807.GH11554@hunt> On Thu, Mar 02, 2017 at 08:02:53AM +0300, Vasilisc wrote: > For example, > vlc come from snap package (location /snap/vlc/current/...), > smplayer - from deb package (location /usr/bin/smplayer). > > How to find available a video players in host system? Can you trust the PATH to be useful and just blindly call execlp() with the names of the players you support, each in turn, until you succeed or fail? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From mark at ubuntu.com Thu Mar 2 07:04:27 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Mar 2017 08:04:27 +0100 Subject: Advice for non connected ubuntu-core/snap update scenario In-Reply-To: References: Message-ID: <07e1f8ae-0306-bfc8-0251-fcfa123c3617@ubuntu.com> On 01/03/17 15:32, Thibault Jochem wrote: > I'm studying the possibility tu use ubuntu-core and snaps as base OS / > app framework for embedded computers with no access to internet. Yes, we will explicitly support this scenario, and there is quite a lot of deep design and engineering work already in place to do so. > We can connect to those systems with a maintenance laptop, and I was > thinking that this laptop could host a snapd server to push the > updates once connected. > > Is it a good idea or is there a better way to handle such scenario ? In a few releases, you should be able to connect a USB stick to the device and have it detect the updates, verify signatures on all the files, and apply them. No need for an internet connection or maintenance laptop. Presenting the updates by USB stick or other attached storage will be exactly the same as connecting to the store. Since every update is signed, a machine can determine that the updates are valid without being online. The core structure to support this is designed into snapd and already exists, but we haven't prioritised all of the details (things like the CLI to trigger the update scan). I expect this will be available during the course of the year, is that soon enough for your device? If the timing of your device is sensitive then feel free to follow-up off-list. Mark From selene.scriven at canonical.com Thu Mar 2 08:15:52 2017 From: selene.scriven at canonical.com (Selene Scriven) Date: Thu, 2 Mar 2017 01:15:52 -0700 Subject: Snap refresh or new install stuck at 'Run configure hook of "core" snap if present' In-Reply-To: References: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> Message-ID: <20170302081552.GA26326@mutt.xyzz.org> * Joseph Rushton Wakeling wrote: > On 24/02/17 14:08, Martin Winter wrote: > >Curious if anyone has seen the same. All my Ubuntu 16.04 > >Servers have this issue. (Approx 10 Servers which are part of > >my CI system) > > Saw the same on a Debian Sid install that I was using to test > my ldc2 snap package a couple of days ago. However, it didn't > persist -- a few minutes ago I was able to successfully install > the core and ldc2 snaps. I'm not sure if it's the same thing, but one of my devices got stuck for a while yesterday. Every snap command got stuck for about 8 minutes, and I found this in the syslog right before that started: Mar 1 05:55:33 localhost /usr/lib/snapd/snapd[1371]: taskrunner.go:353: DEBUG: Running task 29 on Do: Generate device key After that finished, snapd started responding again and other snap commands were able to complete. Not sure what was on the console at the time. I noticed this because my automated tests froze while trying to get in contact with a fresh-flashed device... ssh was already confirmed to work, and it stopped while attempting to run "snap version". -- Selene From alberto.mardegan at canonical.com Thu Mar 2 08:27:55 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Thu, 2 Mar 2017 11:27:55 +0300 Subject: weird behaviour related with fonts in a snap In-Reply-To: <8c0e52e3-4af3-43e1-16c0-57823fcdba90@canonical.com> References: <8c0e52e3-4af3-43e1-16c0-57823fcdba90@canonical.com> Message-ID: <1067fe1f-3571-32db-906e-7e2d47665a90@canonical.com> On 01/03/2017 13:37, Roberto Mier Escandón  wrote: > In source code I don't see any reference to any path related with fonts, > however something else outside of the snap is needed and I cannot find > what. Anybody has hit any issue with fonts in a snap or something > similar to this? No, but it sounds like it's a confinement issue. Do you see any apparmor denials in the syslog? Ciao, Alberto From thibault at jochem.fr Thu Mar 2 08:32:04 2017 From: thibault at jochem.fr (Thibault Jochem) Date: Thu, 2 Mar 2017 09:32:04 +0100 Subject: Advice for non connected ubuntu-core/snap update scenario In-Reply-To: <07e1f8ae-0306-bfc8-0251-fcfa123c3617@ubuntu.com> References: <07e1f8ae-0306-bfc8-0251-fcfa123c3617@ubuntu.com> Message-ID: On Thu, Mar 2, 2017 at 8:04 AM, Mark Shuttleworth wrote: > On 01/03/17 15:32, Thibault Jochem wrote: > > I'm studying the possibility tu use ubuntu-core and snaps as base OS / > > app framework for embedded computers with no access to internet. > > Yes, we will explicitly support this scenario, and there is quite a lot > of deep design and engineering work already in place to do so. > > > We can connect to those systems with a maintenance laptop, and I was > > thinking that this laptop could host a snapd server to push the > > updates once connected. > > > > Is it a good idea or is there a better way to handle such scenario ? > > In a few releases, you should be able to connect a USB stick to the > device and have it detect the updates, verify signatures on all the > files, and apply them. No need for an internet connection or maintenance > laptop. Presenting the updates by USB stick or other attached storage > will be exactly the same as connecting to the store. Since every update > is signed, a machine can determine that the updates are valid without > being online. > > The core structure to support this is designed into snapd and already > exists, but we haven't prioritised all of the details (things like the > CLI to trigger the update scan). I expect this will be available during > the course of the year, is that soon enough for your device? If the > timing of your device is sensitive then feel free to follow-up off-list. > That's a wonderful news ! It's more of a long term evolution for existing devices so I will keep an eye on this feature ! (And I'll learn the rope of ubutu-core/snaps on other projects of mine ;) ) Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Thu Mar 2 08:35:13 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 2 Mar 2017 09:35:13 +0100 Subject: weird behaviour related with fonts in a snap In-Reply-To: <1067fe1f-3571-32db-906e-7e2d47665a90@canonical.com> References: <8c0e52e3-4af3-43e1-16c0-57823fcdba90@canonical.com> <1067fe1f-3571-32db-906e-7e2d47665a90@canonical.com> Message-ID: <05d0a3bf-8ef7-7275-f756-865cb0a3798d@canonical.com> Not sure if about denials, as in devmode is either working. Actually, I've just discovered that doesn't work the same way in classic if using default fonts folder (/usr/share/fonts) or pointing to another location. Maybe upstream developers know something that I don't.. Thanks. On 02/03/17 09:27, Alberto Mardegan wrote: > On 01/03/2017 13:37, Roberto Mier Escandón  wrote: >> In source code I don't see any reference to any path related with fonts, >> however something else outside of the snap is needed and I cannot find >> what. Anybody has hit any issue with fonts in a snap or something >> similar to this? > > No, but it sounds like it's a confinement issue. Do you see any apparmor > denials in the syslog? > > Ciao, > Alberto > > From ogra at ubuntu.com Thu Mar 2 09:01:13 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 02 Mar 2017 10:01:13 +0100 Subject: Snap refresh or new install stuck at 'Run configure hook of "core" snap if present' In-Reply-To: <20170302081552.GA26326@mutt.xyzz.org> References: <05EA4346-34FB-4329-8BD4-CE5AFAC35728@opensourcerouting.org> <20170302081552.GA26326@mutt.xyzz.org> Message-ID: <1488445273.17360.38.camel@ubuntu.com> hi, Am Donnerstag, den 02.03.2017, 01:15 -0700 schrieb Selene Scriven: >  > I'm not sure if it's the same thing, but one of my devices got  > stuck for a while yesterday.  Every snap command got stuck for  > about 8 minutes, and I found this in the syslog right before that  > started: > > Mar  1 05:55:33 localhost /usr/lib/snapd/snapd[1371]: > taskrunner.go:353: DEBUG: Running task 29 on Do: Generate device key > > After that finished, snapd started responding again and other  > snap commands were able to complete.  Not sure what was on the  > console at the time. > > I noticed this because my automated tests froze while trying to  > get in contact with a fresh-flashed device...  ssh was already  > confirmed to work, and it stopped while attempting to run "snap  > version". > sounds like https://bugs.launchpad.net/bugs/1638537 ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From facundo.batista at canonical.com Thu Mar 2 12:27:09 2017 From: facundo.batista at canonical.com (Facundo Batista) Date: Thu, 2 Mar 2017 09:27:09 -0300 Subject: Reading /etc In-Reply-To: References: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> Message-ID: <8666b5e2-850f-e988-e00f-07f2ff4748c1@canonical.com> El 01/03/17 a las 23:29, Marco Ceppi escribió: > I don't have an answer for you, but wanted to add some color to the problem. The issue lies within a dependency of the > latest version of pip. Previously they vendored in a small library to do rudimentary distribution checking. In later > versions, they've included the nir0s/distro python package, which does more aggressive checks against things like /etc > and is hard coded. Yeap, they check "/etc" directly. > I submitted a patch to the distro repo https://github.com/nir0s/distro/issues/149 and it's landed, but it needs to be > pulled into pip and release. Once that's done, UNIXCONFDIR environment variable could be used to override where to find > `/etc`. For my snap, I ended up moving to classic confinement as it fit better with the tool (a system utility). Ah! Using classic confinement is a nice trick that I can also apply to fades [0]. Thanks!! [0] http://fades.readthedocs.io/ -- . Facundo . Canonical - Online Services From didier.roche at canonical.com Thu Mar 2 13:37:59 2017 From: didier.roche at canonical.com (Didier Roche) Date: Thu, 2 Mar 2017 14:37:59 +0100 Subject: A couple of new snap tutorials are now available! Message-ID: <78850b02-cf6d-5620-3784-951b94bc67ea@canonical.com> Following last few weeks announcement, we do have a couple of new tutorials available for snaps! More info are available at https://insights.ubuntu.com/2017/03/02/a-couple-of-new-snap-tutorials-are-now-available/, but I want to give a big round of applause to Simos, present on this list, making excellent community contributions (and planning on more!) If you want to get involved, do not hesitate to reach out to me, either on the list, or directly to me :) See you at your next tutorial! Didier From jamie at canonical.com Thu Mar 2 13:56:10 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 02 Mar 2017 07:56:10 -0600 Subject: Reading /etc In-Reply-To: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> References: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> Message-ID: <1488462970.3473.28.camel@canonical.com> On Wed, 2017-03-01 at 23:06 -0300, Facundo Batista wrote: > Hola! > > When calling pip from inside a snap, it (while investigating the system it's > in) tries to  os.listdir("/etc")  which is > denied to it: > > Mar  1 15:44:04 tanquita kernel: [16153.906524] audit: type=1400 > audit(1488393844.939:99): apparmor="DENIED" > operation="open" namespace="root//lxd-fadestest_" > profile="snap.fades.fades" name="/etc/" >         pid=10606 comm="python" requested_mask="r" denied_mask="r" > fsuid=165536 ouid=165536 > > Which interface should I add to the snap for it to have read only access to > /etc? There isn't a rule in the policy for os.listdir("/etc") atm. Allowing that wouldn't be the worst thing in the world (it would constitute a small information leak), but I suspect you are going to need more access than just "/etc" that may or may not be useful. Importantly, if this is because of what Marco said and this has to do with OS detection, then the snap may end up being mislead (is being discussed in https://github.com/snapcore/snapd/pull/2947). I suggest following the wiki[1] and then filing a bug with the accesses you want, and we can go from there. If you want me to help you get to the bottom of this, just file the bug now or contact me on irc. [1]https://github.com/snapcore/snapd/wiki/Security#interface-development-and-sec urity-policy -- 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 xiaoguo.liu at canonical.com Thu Mar 2 15:16:56 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Thu, 2 Mar 2017 23:16:56 +0800 Subject: Is there any way to choose the arch to build on build.snapcraft.io? Message-ID: Hi, I just tried to use build.snapcraft.io to build my application. The build was successful. However, the app was meant for amd64. After I chose my repos, it built for armhf and amd64 at the same time. The both versions were published. How can I choose the arch to publish? Thanks & best regards, XiaoGuo -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From n.curalli at domotz.com Thu Mar 2 15:25:23 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Thu, 2 Mar 2017 15:25:23 +0000 Subject: revoke a gpg key for signing assertions References: Message-ID: Hi The bug report link: https://bugs.launchpad.net/snapstore/+bug/1669471 Il 01/03/2017 22:57, Leo Arias ha scritto: > Hello! > > Thanks for your report. > Can you please report that as a bug? https://bugs.launchpad.net/snapstore > From cjwatson at ubuntu.com Thu Mar 2 15:38:00 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Thu, 2 Mar 2017 15:38:00 +0000 Subject: Is there any way to choose the arch to build on build.snapcraft.io? In-Reply-To: References: Message-ID: <20170302153800.GC26149@riva.ucam.org> On Thu, Mar 02, 2017 at 11:16:56PM +0800, XiaoGuo Liu wrote: > I just tried to use build.snapcraft.io to build my application. The build > was successful. Great! > However, the app was meant for amd64. After I chose my repos, it built > for armhf and amd64 at the same time. The both versions were > published. How can I choose the arch to publish? This isn't configurable right now. We do expect to make this configurable at some point in the future once we work out the best place to do it. Both architectures being published shouldn't actually be a problem; snapd will pick the correct one when installing on a given architecture. However, if it's a serious problem for some reason then I can manually configure it for you for now; let me know. -- Colin Watson [cjwatson at ubuntu.com] From alfonso.sanchez-beato at canonical.com Thu Mar 2 16:41:01 2017 From: alfonso.sanchez-beato at canonical.com (Alfonso Sanchez-Beato) Date: Thu, 2 Mar 2017 17:41:01 +0100 Subject: [System Enablement] New releases March 2nd 2017 Message-ID: Hello everyone, new releases of the following snaps were pushed into the candidate channel. modem-manager 1.6.2-3: * Big upgrade to mm upstream version 1.6, from 1.4 * Rename of our "dell" plugin to "plano" so there is no conflict with "dell" upstream plugin. * Add alias for mmcli * Warn user if they are running mmcli without being root * Execute upstream unit tests during snap build * Much smaller snap canonical-se-engineering-tests 6: * udisks2 test cases have improved test steps * tmp test cases have fixed snap connect plug/slot commands wifi-ap 14: * Don't fail when we can't determine the current used channel but print a warning * Improved documentation If you have any questions feel free to ping me on irc. Br, Alfonso -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.nitzsche at canonical.com Thu Mar 2 18:33:46 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Thu, 2 Mar 2017 13:33:46 -0500 Subject: content interface, DENIED mounting $SNAP/mydir Message-ID: Hi, I am trying to use the wifi-ap content sharing interface. It is DENIED (see below) when I try to use a $SNAP directory. It works when I instead use $SNAP_DATA directory for the content sharing. But, I have to create that directory at run time: I can't figure out so far how to create (from snapcraft.yaml) an empty dir in $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve my problem.) To auto connect the interface (via a store snap declaration), I suppose the directory must be present at install time. So creating the dir at run time does not seem sufficient for the auto-connect requirement. Help appreciated. == Details when trying to use SNAP dir for content sharing: snapcraft.yaml snippet: apps: wifi-ap: command: bin/wifi-ap plugs: [control, content] plugs: control: interface: content content: socket-directory target: $SNAP/sockets parts: controldir: plugin: dump source: . prime: - sockets I connect my snap to the interface apparently successfully: $ sudo snap connect serv:control wifi-ap:control Verify connection: $ snap interfaces | grep serv | grep "wifi-ap:" wifi-ap:control serv But the bind mount was DENIED: Mar 02 18:01:02 localhost.localdomain kernel: audit: type=1400 audit(1488477662.292:350110): apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine" name="/snap/serv/x3/sockets/" pid=11461 comm="snap-confine" srcname="/var/snap/wifi-ap/94/sockets/" flags="rw, bind" Both wifi-ap snap and my snap seem to have the required directories: $ ls /var/snap/wifi-ap/94/sockets/ control knitzsche at localhost:~$ ls /snap/serv/x3/ bin command-run.wrapper command-scan.wrapper command-wifi-ap.wrapper meta snap sockets Cheers, kyleN From michael.hudson at canonical.com Thu Mar 2 21:20:29 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Fri, 3 Mar 2017 10:20:29 +1300 Subject: a little script: snapdiff In-Reply-To: <699928dd-7aee-85db-90dd-6a94211c000c@canonical.com> References: <699928dd-7aee-85db-90dd-6a94211c000c@canonical.com> Message-ID: On 10 February 2017 at 19:16, Simon Fels wrote: > On 10.02.2017 01:44, Michael Hudson-Doyle wrote: > > Very much inspired by debdiff, I wrote a little script to compare two > > snaps. It looks like this: > > > > (master)mwhudson at aeglos:/opt/opensource/snaps/go$ snapdiff > > go-17-mwhudson_1.snap go-17-mwhudson_2.snap > > Only in second snap, go-17-mwhudson_2.snap: > > > > -rw-rw-r-- root/root 839 2017-02-03 11:14 > > test/fixedbugs/issue16331.go > > -rw-rw-r-- root/root 686 2017-02-03 11:14 > > test/fixedbugs/issue18410.go > > > > Differences in meta directory: > > > > diff -Nur meta1/snap.yaml meta2/snap.yaml > > --- meta1/snap.yaml2017-01-11 11:49:30.000000000 +1300 > > +++ meta2/snap.yaml2017-02-03 11:16:07.000000000 +1300 > > @@ -13,4 +13,4 @@ > > grade: devel > > name: go-17-mwhudson > > summary: Go programming language compiler, linker, stdlib > > -version: 1.7.4 > > +version: 1.7.5 > > > > It's implemented in perl (for no very good reason) and you can get it > > here: http://paste.ubuntu.com/23963902/ > > That is really nice! > > Having a classic snap for it would be awesome :-) > I've finally pushed this, needs review of course. It's also on github at https://github.com/mwhudson/snapdiff now. Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Thu Mar 2 21:20:51 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 2 Mar 2017 22:20:51 +0100 Subject: Snaps in production? In-Reply-To: <438a4720-1fde-76d1-2132-a6558c6a0e10@gmx.ch> References: <43E841D1CB23514783B81EFDF97705013EB47F8D@bgb01xud1004> <438a4720-1fde-76d1-2132-a6558c6a0e10@gmx.ch> Message-ID: <1b345a37-f6c5-7f83-911d-6df01a902e53@ubuntu.com> On 27/02/17 14:56, Lara Lauer wrote: > On 27.02.2017 11:30, Sam Nicholson wrote: >> developed on Ubuntu and packaged for Debian, onto our CentOS-based production infrastructure. > To my knowledge CentOS does not support Snaps. There is a snapd package > for Fedora [1]. Yes, we have some work to do for fully-confined snaps on CentOS. Classic snaps working should be straightforward, strict confinement for CentOS/RHEL/Fedora is on the roadmap. Mark From michi.henning at canonical.com Fri Mar 3 00:06:37 2017 From: michi.henning at canonical.com (Michi Henning) Date: Fri, 3 Mar 2017 10:06:37 +1000 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: References: Message-ID: > On 3 Mar 2017, at 4:33 , knitzsche wrote: > > Hi, > > I am trying to use the wifi-ap content sharing interface. > > It is DENIED (see below) when I try to use a $SNAP directory. > > It works when I instead use $SNAP_DATA directory for the content sharing. But, I have to create that directory at run time: I can't figure out so far how to create (from snapcraft.yaml) an empty dir in $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve my problem.) We do this to create a directory: install: | # Make sure we have a mount point for ubuntu-app-platform mkdir -p $SNAPCRAFT_PART_INSTALL/ubuntu-app-platform -------------- next part -------------- An HTML attachment was scrubbed... URL: From facundo.batista at canonical.com Fri Mar 3 01:42:43 2017 From: facundo.batista at canonical.com (Facundo Batista) Date: Thu, 2 Mar 2017 22:42:43 -0300 Subject: Reading /etc In-Reply-To: <1488462970.3473.28.camel@canonical.com> References: <19b19d4a-077c-3190-728d-da39c4b40a25@canonical.com> <1488462970.3473.28.camel@canonical.com> Message-ID: <1d171e15-f8e7-de89-5985-7bb1e9c50a35@canonical.com> El 02/03/17 a las 10:56, Jamie Strandboge escribió: > On Wed, 2017-03-01 at 23:06 -0300, Facundo Batista wrote: >> Which interface should I add to the snap for it to have read only access to >> /etc? > > There isn't a rule in the policy for os.listdir("/etc") atm. Allowing that > wouldn't be the worst thing in the world (it would constitute a small > information leak), but I suspect you are going to need more access than just > "/etc" that may or may not be useful. Importantly, if this is because of what > Marco said and this has to do with OS detection, then the snap may end up being > mislead (is being discussed in https://github.com/snapcore/snapd/pull/2947). And that access depends on what PIP is trying to do (of which I'm not fully aware) > I suggest following the wiki[1] and then filing a bug with the accesses you > want, and we can go from there. If you want me to help you get to the bottom of > this, just file the bug now or contact me on irc. I'm currently trying to use "classic" confinement. But this "need to read /etc" is a wall everybody trying to use PIP from inside a snap will hit (which may not be common at all, though). Thanks! -- . Facundo . Canonical - Online Services From simon.fels at canonical.com Fri Mar 3 07:06:39 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 3 Mar 2017 08:06:39 +0100 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: References: Message-ID: <678a9e03-375b-4154-077e-062ddea882e4@canonical.com> On 03.03.2017 01:06, Michi Henning wrote: > >> On 3 Mar 2017, at 4:33 , knitzsche > > wrote: >> >> Hi, >> >> I am trying to use the wifi-ap content sharing interface. >> >> It is DENIED (see below) when I try to use a $SNAP directory. >> >> It works when I instead use $SNAP_DATA directory for the content >> sharing. But, I have to create that directory at run time: I can't >> figure out so far how to create (from snapcraft.yaml) an empty dir in >> $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve >> my problem.) > > > We do this to create a directory: > > install: | > # Make sure we have a mount point for ubuntu-app-platform > mkdir -p $SNAPCRAFT_PART_INSTALL/ubuntu-app-platform That doesn't help much here as we're bind-mounting read/write data and that seems to be not possible to go into somewhere below $SNAP. I fear the only answer to this problem are interface hooks which would allow us to create the relevant directory before the bind-mount happens inside $SNAP_DATA. regards, Simon From xiaoguo.liu at canonical.com Fri Mar 3 07:37:26 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Fri, 3 Mar 2017 15:37:26 +0800 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: <678a9e03-375b-4154-077e-062ddea882e4@canonical.com> References: <678a9e03-375b-4154-077e-062ddea882e4@canonical.com> Message-ID: Can we use the configure hook to create the directory at installation? On Fri, Mar 3, 2017 at 3:06 PM, Simon Fels wrote: > On 03.03.2017 01:06, Michi Henning wrote: > > > >> On 3 Mar 2017, at 4:33 , knitzsche >> > wrote: > >> > >> Hi, > >> > >> I am trying to use the wifi-ap content sharing interface. > >> > >> It is DENIED (see below) when I try to use a $SNAP directory. > >> > >> It works when I instead use $SNAP_DATA directory for the content > >> sharing. But, I have to create that directory at run time: I can't > >> figure out so far how to create (from snapcraft.yaml) an empty dir in > >> $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve > >> my problem.) > > > > > > We do this to create a directory: > > > > install: | > > # Make sure we have a mount point for ubuntu-app-platform > > mkdir -p $SNAPCRAFT_PART_INSTALL/ubuntu-app-platform > > That doesn't help much here as we're bind-mounting read/write data and > that seems to be not possible to go into somewhere below $SNAP. > > I fear the only answer to this problem are interface hooks which would > allow us to create the relevant directory before the bind-mount happens > inside $SNAP_DATA. > > regards, > Simon > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Fri Mar 3 08:43:41 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 3 Mar 2017 09:43:41 +0100 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: References: Message-ID: <3122d799-9b8d-965f-14cd-8d6bcabcf2da@canonical.com> Hey Kyle, If this is of help, you can check how I did it in the case of Collabora Office snap [1] using Nextcloud [2] docs in write mode. I created the target folder into "snap/" and then I referred it in snapcraft.yaml plug skipping "snap" parent, like this: target: though the folder was indeed at $SNAP/snap/ in CODE snapcraft.yaml you'll find plugs: nextcloud-data: content: nextcloud-documents default-provider: nextcloud interface: content target: nextcloud-data in Nextcloud .yaml you'll find slots: nextcloud-data: content: nextcloud-documents interface: content write: - $SNAP_COMMON/nextcloud/data Cheers. [1] https://github.com/rmescandon/loolwsd-snap/blob/master/snap/snapcraft.yaml [2] https://github.com/rmescandon/nextcloud-snap/blob/content-share/snapcraft.yaml On 02/03/17 19:33, knitzsche wrote: > Hi, > > I am trying to use the wifi-ap content sharing interface. > > It is DENIED (see below) when I try to use a $SNAP directory. > > It works when I instead use $SNAP_DATA directory for the content > sharing. But, I have to create that directory at run time: I can't > figure out so far how to create (from snapcraft.yaml) an empty dir in > $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve my > problem.) > > To auto connect the interface (via a store snap declaration), I suppose > the directory must be present at install time. So creating the dir at > run time does not seem sufficient for the auto-connect requirement. > > Help appreciated. > > == Details when trying to use SNAP dir for content sharing: > > snapcraft.yaml snippet: > > apps: > wifi-ap: > command: bin/wifi-ap > plugs: [control, content] > > plugs: > control: > interface: content > content: socket-directory > target: $SNAP/sockets > parts: > controldir: > plugin: dump > source: . > prime: > - sockets > > I connect my snap to the interface apparently successfully: > $ sudo snap connect serv:control wifi-ap:control > > Verify connection: > $ snap interfaces | grep serv | grep "wifi-ap:" > wifi-ap:control serv > > But the bind mount was DENIED: > Mar 02 18:01:02 localhost.localdomain kernel: audit: type=1400 > audit(1488477662.292:350110): apparmor="DENIED" operation="mount" > info="failed srcname match" error=-13 > profile="/usr/lib/snapd/snap-confine" name="/snap/serv/x3/sockets/" > pid=11461 comm="snap-confine" srcname="/var/snap/wifi-ap/94/sockets/" > flags="rw, bind" > > Both wifi-ap snap and my snap seem to have the required directories: > $ ls /var/snap/wifi-ap/94/sockets/ > control > knitzsche at localhost:~$ ls /snap/serv/x3/ > bin command-run.wrapper command-scan.wrapper command-wifi-ap.wrapper > meta snap sockets > > Cheers, > kyleN > > > > From simon.fels at canonical.com Fri Mar 3 10:07:55 2017 From: simon.fels at canonical.com (Simon Fels) Date: Fri, 3 Mar 2017 11:07:55 +0100 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: References: <678a9e03-375b-4154-077e-062ddea882e4@canonical.com> Message-ID: On 03.03.2017 08:37, XiaoGuo Liu wrote: > Can we use the configure hook to create the directory at installation? No, as it runs after the automatic connection of plugs/slots defined in the snap-declaration. regards, Simon From ogra at ubuntu.com Fri Mar 3 10:35:55 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 03 Mar 2017 11:35:55 +0100 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: References: Message-ID: <1488537355.17360.49.camel@ubuntu.com> hi, Am Donnerstag, den 02.03.2017, 13:33 -0500 schrieb knitzsche: > > It is DENIED (see below) when I try to use a $SNAP directory. the $SNAP directory is root owned and readonly (it is the mounted squashfs), the $SNAP_DATA dir is likewise root owned (but indeed writable). even if you have a dir in either of them serving as mountpoint and confinement allowed mounting you'd still need sudo for the command to overcome the filesystem permission blocking... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From hochglanz at gmail.com Fri Mar 3 11:33:43 2017 From: hochglanz at gmail.com (Harald Nikolisin) Date: Fri, 3 Mar 2017 12:33:43 +0100 Subject: First Snap ktouch - no success Message-ID: Hi all, According to the site https://www.ubuntu.com/desktop/snappy I just installed my first snap - which was ktouch - simply with sudo snap install ktouch The I just run the application ("which ktouch" informs me that the path is /snap/bin/ktouch), but it immediately aborts with ktouch: error while loading shared libraries: libQt5Sql.so.5: cannot open shared object file: No such file or directory I expected that such problems should be avoided with an snap? Because I'm not sure where to send a bugreport (launchpad is probably not the proper address) I send it to your mailing list, maybe someone has a hint. Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Mar 3 11:53:42 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 03 Mar 2017 12:53:42 +0100 Subject: First Snap ktouch - no success In-Reply-To: References: Message-ID: <1488542022.17360.51.camel@ubuntu.com> hi, Am Freitag, den 03.03.2017, 12:33 +0100 schrieb Harald Nikolisin: > Hi all, > > According to the site  https://www.ubuntu.com/desktop/snappy > I just installed my first snap - which was ktouch - simply with > sudo snap install ktouch > > The I just run the application  ("which ktouch" informs me that the > path is /snap/bin/ktouch), but it immediately aborts with > > ktouch: error while loading shared libraries: libQt5Sql.so.5: cannot > open shared object file: No such file or directory > > I expected that such problems should be avoided with an snap?  > Because I'm not sure where to send a bugreport (launchpad is probably > not the proper address) I send it to your mailing list, maybe someone > has a hint. > snapcraft bugs go to: https://bugs.launchpad.net/snapcraft/+filebug that said though ... it looks rather like you did not add libqt5sql5 to your stage-packages in snapcraft.yaml ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Fri Mar 3 12:02:48 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 03 Mar 2017 13:02:48 +0100 Subject: First Snap ktouch - no success In-Reply-To: <1488542022.17360.51.camel@ubuntu.com> References: <1488542022.17360.51.camel@ubuntu.com> Message-ID: <1488542568.17360.55.camel@ubuntu.com> hi, Am Freitag, den 03.03.2017, 12:53 +0100 schrieb Oliver Grawert: > hi, > Am Freitag, den 03.03.2017, 12:33 +0100 schrieb Harald Nikolisin: > >  > > According to the site  https://www.ubuntu.com/desktop/snappy > > I just installed my first snap - which was ktouch - simply with > > sudo snap install ktouch > >  > snapcraft bugs go to: > https://bugs.launchpad.net/snapcraft/+filebug > > that said though ... it looks rather like you did not add libqt5sql5 > to > your stage-packages in snapcraft.yaml ... oops, sorry, i mis-read ... obviously you want to use an existing snap, not build one, sorry ...  actually snapd should have told you that you need to install and connect the right platform snap for this (i think the generic desktop helpers usually do print such a message, seems ktouch does not use that bit) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From hochglanz at gmail.com Fri Mar 3 12:03:16 2017 From: hochglanz at gmail.com (Harald Nikolisin) Date: Fri, 3 Mar 2017 13:03:16 +0100 Subject: First Snap ktouch - no success In-Reply-To: <1488542022.17360.51.camel@ubuntu.com> References: <1488542022.17360.51.camel@ubuntu.com> Message-ID: @oli: Thx for the link! you said "looks rather like you did not add libqt5sql5 to your stage-packages in snapcraft.yaml ..." That is a task for the creator/maintainer of the snap, or is it a task for the user? Harald Am 03.03.2017 um 12:53 schrieb Oliver Grawert: > hi, > Am Freitag, den 03.03.2017, 12:33 +0100 schrieb Harald Nikolisin: >> Hi all, >> >> According to the site https://www.ubuntu.com/desktop/snappy >> I just installed my first snap - which was ktouch - simply with >> sudo snap install ktouch >> >> The I just run the application ("which ktouch" informs me that the >> path is /snap/bin/ktouch), but it immediately aborts with >> >> ktouch: error while loading shared libraries: libQt5Sql.so.5: cannot >> open shared object file: No such file or directory >> >> I expected that such problems should be avoided with an snap? >> Because I'm not sure where to send a bugreport (launchpad is probably >> not the proper address) I send it to your mailing list, maybe someone >> has a hint. >> > snapcraft bugs go to: > https://bugs.launchpad.net/snapcraft/+filebug > > that said though ... it looks rather like you did not add libqt5sql5 to > your stage-packages in snapcraft.yaml ... > > ciao > oli > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.escandon at canonical.com Fri Mar 3 12:37:24 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 3 Mar 2017 13:37:24 +0100 Subject: plugins in snap? Message-ID: Hi, Maybe one silly question: I've moved plugins to be in snap/plugins path. All works fine, but I see them included in the snap package. Is there any way to avoid this?. I don't want the plugins there. Thanks. From alberto.mardegan at canonical.com Fri Mar 3 14:02:00 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Fri, 3 Mar 2017 17:02:00 +0300 Subject: Running xdg-open Message-ID: Hi all! Currently the xdg-open tool is provided by the core snap, which has it located in its /usr/local/bin/ path. Unfortunately, this means that other snaps cannot run it, unless they have /usr/local/bin in their PATH. Consequently, I filed a bug against the desktop helpers script [1] requesting a modification to include that path into PATH. Didier asked me to write here, to get a better understanding of the plans: is the core snap to be updated and have the xdg-open tool in /bin or /usr/bin? If so, do you have a bug or would you like to have one filed? :-) I've seen the xdg-open tool mentioned a few times in the past here in the mailing list, but I haven't found a definite answer. Ciao, Alberto [1] https://github.com/ubuntu/snapcraft-desktop-helpers/pull/58 From mark at ubuntu.com Fri Mar 3 14:22:00 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 3 Mar 2017 15:22:00 +0100 Subject: Running xdg-open In-Reply-To: References: Message-ID: <941c58c5-2610-e2bf-c5af-6de1758183c4@ubuntu.com> On 03/03/17 15:02, Alberto Mardegan wrote: > Currently the xdg-open tool is provided by the core snap, which has it > located in its /usr/local/bin/ path. Will it not always be available at /snap/core/current/usr/local/bin/ ? Mark From ogra at ubuntu.com Fri Mar 3 14:22:15 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 03 Mar 2017 15:22:15 +0100 Subject: Running xdg-open In-Reply-To: References: Message-ID: <1488550935.17360.60.camel@ubuntu.com> hi, Am Freitag, den 03.03.2017, 17:02 +0300 schrieb Alberto Mardegan: > Hi all! >   Currently the xdg-open tool is provided by the core snap, which has > it > located in its /usr/local/bin/ path. > Unfortunately, this means that other snaps cannot run it, unless they > have /usr/local/bin in their PATH. Consequently, I filed a bug > against > the desktop helpers script [1] requesting a modification to include > that > path into PATH. that was https://bugs.launchpad.net/snapcraft/+bug/1661023 fixed by https://github.com/snapcore/snapd/pull/2765 so any snap should use the "fake" xdg-open by default and hand the request to the outside of the confinement to the dbus service shipped by the snapd-xdg-open deb on the desktop. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From honeycuttaaron3 at gmail.com Fri Mar 3 14:25:53 2017 From: honeycuttaaron3 at gmail.com (Aaron Honeycutt) Date: Fri, 3 Mar 2017 09:25:53 -0500 Subject: First Snap ktouch - no success In-Reply-To: References: <1488542022.17360.51.camel@ubuntu.com> Message-ID: I believe there is a KDE snap that has all the libraries needed by KDE apps. Something like frameworks. On Mar 3, 2017 7:04 AM, "Harald Nikolisin" wrote: > @oli: Thx for the link! > > you said "looks rather like you did not add libqt5sql5 to > your stage-packages in snapcraft.yaml ..." > > That is a task for the creator/maintainer of the snap, or is it a task for > the user? > > Harald > > Am 03.03.2017 um 12:53 schrieb Oliver Grawert: > > hi, > Am Freitag, den 03.03.2017, 12:33 +0100 schrieb Harald Nikolisin: > > Hi all, > > According to the site https://www.ubuntu.com/desktop/snappy > I just installed my first snap - which was ktouch - simply with > sudo snap install ktouch > > The I just run the application ("which ktouch" informs me that the > path is /snap/bin/ktouch), but it immediately aborts with > > ktouch: error while loading shared libraries: libQt5Sql.so.5: cannot > open shared object file: No such file or directory > > I expected that such problems should be avoided with an snap? > Because I'm not sure where to send a bugreport (launchpad is probably > not the proper address) I send it to your mailing list, maybe someone > has a hint. > > > snapcraft bugs go to:https://bugs.launchpad.net/snapcraft/+filebug > > that said though ... it looks rather like you did not add libqt5sql5 to > your stage-packages in snapcraft.yaml ... > > ciao > oli > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Mar 3 14:54:03 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 03 Mar 2017 15:54:03 +0100 Subject: Running xdg-open In-Reply-To: <941c58c5-2610-e2bf-c5af-6de1758183c4@ubuntu.com> References: <941c58c5-2610-e2bf-c5af-6de1758183c4@ubuntu.com> Message-ID: <1488552843.17360.70.camel@ubuntu.com> hi, Am Freitag, den 03.03.2017, 15:22 +0100 schrieb Mark Shuttleworth: > On 03/03/17 15:02, Alberto Mardegan wrote: > > > >   Currently the xdg-open tool is provided by the core snap, which > > has it > > located in its /usr/local/bin/ path. > Will it not always be available at /snap/core/current/usr/local/bin/ > ? yes, and it has been there since day one (of the core 16 series at least). the fix for handling the PATH in snap-confine is only in snapd 2.23 which has only just made it into xenial-proposed. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From didrocks at ubuntu.com Fri Mar 3 15:10:18 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 3 Mar 2017 16:10:18 +0100 Subject: Running xdg-open In-Reply-To: <1488552843.17360.70.camel@ubuntu.com> References: <941c58c5-2610-e2bf-c5af-6de1758183c4@ubuntu.com> <1488552843.17360.70.camel@ubuntu.com> Message-ID: <09834afa-bb47-604a-1a35-7851606f825d@ubuntu.com> Le 03/03/2017 à 15:54, Oliver Grawert a écrit : > hi, > Am Freitag, den 03.03.2017, 15:22 +0100 schrieb Mark Shuttleworth: >> On 03/03/17 15:02, Alberto Mardegan wrote: >>> Currently the xdg-open tool is provided by the core snap, which >>> has it >>> located in its /usr/local/bin/ path. >> Will it not always be available at /snap/core/current/usr/local/bin/ >> ? > yes, and it has been there since day one (of the core 16 series at > least). > > the fix for handling the PATH in snap-confine is only in snapd 2.23 > which has only just made it into xenial-proposed. Indeed, we only discussed the last point: /usr/local/bin was in the snap $PATH in the past, but there has been a regression (I guess due to the move to snap-confine or a new core snap) where it's not anymore. /usr/local/bin is not in the user's path, nor in the snap $PATH as it used to be. Didier From hochglanz at gmail.com Fri Mar 3 15:56:44 2017 From: hochglanz at gmail.com (Harald Nikolisin) Date: Fri, 3 Mar 2017 16:56:44 +0100 Subject: First Snap ktouch - no success In-Reply-To: References: <1488542022.17360.51.camel@ubuntu.com> Message-ID: <582eac13-b549-6f73-940b-f9b8265356f9@gmail.com> Ok, I searched and found kde-frameworks-5 and installed it. But still the same problem. However - my naive expectation on snaps is that I install only(!) the application without bothering which other SW is needed to run it. Am I wrong with that? Am 03.03.2017 um 15:25 schrieb Aaron Honeycutt: > I believe there is a KDE snap that has all the libraries needed by KDE > apps. Something like frameworks. > > On Mar 3, 2017 7:04 AM, "Harald Nikolisin" > wrote: > > @oli: Thx for the link! > > you said "looks rather like you did not add libqt5sql5 to > your stage-packages in snapcraft.yaml ..." > > That is a task for the creator/maintainer of the snap, or is it a > task for the user? > > Harald > > Am 03.03.2017 um 12:53 schrieb Oliver Grawert: >> hi, >> Am Freitag, den 03.03.2017, 12:33 +0100 schrieb Harald Nikolisin: >>> Hi all, >>> >>> According to the site https://www.ubuntu.com/desktop/snappy >>> >>> I just installed my first snap - which was ktouch - simply with >>> sudo snap install ktouch >>> >>> The I just run the application ("which ktouch" informs me that the >>> path is /snap/bin/ktouch), but it immediately aborts with >>> >>> ktouch: error while loading shared libraries: libQt5Sql.so.5: cannot >>> open shared object file: No such file or directory >>> >>> I expected that such problems should be avoided with an snap? >>> Because I'm not sure where to send a bugreport (launchpad is probably >>> not the proper address) I send it to your mailing list, maybe someone >>> has a hint. >>> >> snapcraft bugs go to: >> https://bugs.launchpad.net/snapcraft/+filebug >> >> >> that said though ... it looks rather like you did not add libqt5sql5 to >> your stage-packages in snapcraft.yaml ... >> >> ciao >> oli >> > -- Snapcraft mailing list Snapcraft at lists.snapcraft.io > Modify settings or > unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri Mar 3 16:05:37 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 3 Mar 2017 17:05:37 +0100 Subject: First Snap ktouch - no success In-Reply-To: <582eac13-b549-6f73-940b-f9b8265356f9@gmail.com> References: <1488542022.17360.51.camel@ubuntu.com> <582eac13-b549-6f73-940b-f9b8265356f9@gmail.com> Message-ID: On 03/03/17 16:56, Harald Nikolisin wrote: > However - my naive expectation on snaps is that I install only(!) the > application without bothering which other SW is needed to run it. Am I > wrong with that? Snaps allow for completely self-contained apps, yes. But they also allow the publisher of the app to CHOOSE if they want to consume some libraries from the core snap (common) or from another snap (less common). The benefits in snap size are very substantial when you have a large and very well maintained piece of infrastructure like KDE, but it does mean you have to trust that upstream to do the maintenance very well. The use of such a dependency is a choice we leave to the respective communities. Since this capability is new we have not added the code to bring in such frameworks automatically, but once we understand the patterns of behaviour for both users and publishers then I think we will do so. One last thing - there is a mechanism for publishers to *validate* a framework, which means that you will know the app has been tested with that version of the framework. Mark From jamie at canonical.com Fri Mar 3 16:20:39 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 03 Mar 2017 10:20:39 -0600 Subject: First Snap ktouch - no success In-Reply-To: <582eac13-b549-6f73-940b-f9b8265356f9@gmail.com> References: <1488542022.17360.51.camel@ubuntu.com> <582eac13-b549-6f73-940b-f9b8265356f9@gmail.com> Message-ID: <1488558039.4393.8.camel@canonical.com> On Fri, 2017-03-03 at 16:56 +0100, Harald Nikolisin wrote: > Ok, I searched and found kde-frameworks-5 and installed it. > But still the same problem. > You likely are now experiencing a different bug where the snap is not connected and/or the mount namespace is not properly set up because you installed the framework after the app snap. This is: https://bugs.launchpad.net/snappy/+bug/1645731 and comment #2 describes how to workaround it. > However - my naive expectation on snaps is that I install only(!) the > application without bothering which other SW is needed to run it. Am I > wrong with that? This isn't a naive expectation at all! :) IIRC, the design is if ktouch plugs a content snap and you do 'snap install ktouch', then the default-provider for the content snap should automatically be installed along with the ktouch snap. Unfortunately this isn't implemented just yet but it is definitely on the roadmap (perhaps someone from the snappy team can comment on the priority?).  > > Am 03.03.2017 um 15:25 schrieb Aaron Honeycutt: > > > > I believe there is a KDE snap that has all the libraries needed by KDE > > apps. Something like frameworks. > > > > On Mar 3, 2017 7:04 AM, "Harald Nikolisin" > > wrote: > > > >     @oli: Thx for the link! > > > >     you said "looks rather like you did not add libqt5sql5 to > >     your stage-packages in snapcraft.yaml ..." > > > >     That is a task for the creator/maintainer of the snap, or is it a > >     task for the user? > > > >     Harald > > > >     Am 03.03.2017 um 12:53 schrieb Oliver Grawert: > > > > > >     hi, > > >     Am Freitag, den 03.03.2017, 12:33 +0100 schrieb Harald Nikolisin: > > > > > > > >     Hi all, > > > > > > > >     According to the site  https://www.ubuntu.com/desktop/snappy > > > >      > > > >     I just installed my first snap - which was ktouch - simply with > > > >     sudo snap install ktouch > > > > > > > >     The I just run the application  ("which ktouch" informs me that the > > > >     path is /snap/bin/ktouch), but it immediately aborts with > > > > > > > >     ktouch: error while loading shared libraries: libQt5Sql.so.5: cannot > > > >     open shared object file: No such file or directory > > > > > > > >     I expected that such problems should be avoided with an snap?  > > > >     Because I'm not sure where to send a bugreport (launchpad is > > > > probably > > > >     not the proper address) I send it to your mailing list, maybe > > > > someone > > > >     has a hint. > > > > > > >     snapcraft bugs go to: > > >     https://bugs.launchpad.net/snapcraft/+filebug > > >      > > > > > >     that said though ... it looks rather like you did not add libqt5sql5 > > > to > > >     your stage-packages in snapcraft.yaml ... > > > > > >     ciao > > >      oli > > > > >     -- Snapcraft mailing list Snapcraft at lists.snapcraft.io > >      Modify settings or > >     unsubscribe at: > >     https://lists.ubuntu.com/mailman/listinfo/snapcraft > >       > > > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/s > napcraft -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From michael.vogt at canonical.com Fri Mar 3 17:14:09 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Fri, 3 Mar 2017 18:14:09 +0100 Subject: New snapd 2.23 release Message-ID: <20170303171409.GL15361@bod> Hi, The snappy team is happy to announce the new snapd 2.23 release! The new release is available in the "core" (and "ubuntu-core") snap on the "candidate" channel and also in the Ubuntu 14.04, 16.04, 16.10 "proposed" pockets and in 17.04. To install this new release you need to run the following command: $ sudo snap refresh --beta core On the classic distribution you can help testing by enabling -proposed and then installing snapd [1]. Some highlights: - add support for seeding on classic - all interfaces support send*,recv* syscalls now - xdelta3 is used from the core snap - `snap info` shows contact information - support for galliumos, serena - shell completion for connect - move auto-refresh inside snapd - create "current" symlink in user-data dir - UI improvements - many bugfixes - New interfaces: - thumbnailer, classic-support, network-setup-control, linux-frame-buffer, unity8 - Interface improvements: - screen-inhibit-control, network-control, firewall-control, unity7, default, serial, core-support, hardware-observe, kernel-module-control, udisks2 Please let us know if you experience any issues or if you have suggestions! Enjoy the new release, Michael (on behalf of the snappy team) [1] https://wiki.ubuntu.com/Testing/EnableProposed From claudioandre.br at gmail.com Fri Mar 3 19:32:29 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=C3=A9?=) Date: Fri, 3 Mar 2017 16:32:29 -0300 Subject: Snaps and the latest 16.04 kernel (problem?) Message-ID: Hi, one of my snaps stopped to work properly today [1]. Trying to debug it, I find out that: - If I boot using the previous 4.4.0-64 kernel, I can successfully run the snap. - If I let GRUB do its job (kernel 4.4.0-65), the snap cannot start properly and I can see new apparmor="DENIED" on logs. - I tried to keep my computer as a "regular user computer". Anyway, feel free to ask for more information. - I did nothing special yesterday. I tried to restart the computer 3 times to feel confident about this e-mail message. But, I'm really eager to confirm this [2]. [1] Yesterday, I accept a kernel update. [2] I'm sorry, I don't have any 'extra' hardware. Thank you for your time. Claudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Fri Mar 3 19:41:13 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 3 Mar 2017 13:41:13 -0600 Subject: plugins in snap? In-Reply-To: References: Message-ID: Hello Roberto, On Fri, Mar 3, 2017 at 6:37 AM, Roberto Mier Escandón  wrote: > Maybe one silly question: I've moved plugins to be in snap/plugins path. > All works fine, but I see them included in the snap package. Is there > any way to avoid this?. I don't want the plugins there. We are trying to define what goes into the snap. For example, we want the snapcraft.yaml some times in there, and if the snapcraft.yaml has references to a custom plugin, maybe it makes sense to include that plugin too. What we have currently is inconsistent, and thus a bug of course. Your question is not silly at all, we need to improve there. Take a look at the discussion in https://bugs.launchpad.net/snapcraft/+bug/1660890, and if you have something to add, please leave a comment in there. pura vida. From jamie at canonical.com Fri Mar 3 20:44:43 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 03 Mar 2017 14:44:43 -0600 Subject: Snaps and the latest 16.04 kernel (problem?) In-Reply-To: References: Message-ID: <1488573883.4393.11.camel@canonical.com> On Fri, 2017-03-03 at 16:32 -0300, Claudio André wrote: > Hi, one of my snaps stopped to work properly today [1]. Trying to debug it, > I find out that: > > - If I boot using the previous 4.4.0-64 kernel, I can successfully run the > snap. > - If I let GRUB do its job (kernel 4.4.0-65), the snap cannot start > properly and I can see new apparmor="DENIED" on logs. > - I tried to keep my computer as a "regular user computer". Anyway, feel > free to ask for more information. > - I did nothing special yesterday. > > I tried to restart the computer 3 times to feel confident about this e-mail > message. But, I'm really eager to confirm this [2]. > > [1] Yesterday, I accept a kernel update. > [2] I'm sorry, I don't have any 'extra' hardware. > Could it be this bug: https://bugs.launchpad.net/snapd/+bug/1666897 If not, can you file a new bug here: https://bugs.launchpad.net/snapd/+filebug Please include the denials you are seeing. -- 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 max.brustkern at canonical.com Fri Mar 3 21:06:02 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Fri, 3 Mar 2017 16:06:02 -0500 Subject: auto-import of system-user assertion on vm Message-ID: I'm attempting to run a virtual machine with an ubuntu core image and an additional image containing a system-user assertion attached as a usb device. The auto-import mechanism appears to find the assertion, but does not seem actually succeed at creating the user. To verify this, I'm creating a user in the console to get in and get the syslog, so if I reboot again, the system is already managed and the user creation fails, but on the first run, I don't see what's failing. Is there an additional log I can check? Mar 3 20:51:04 localhost /usr/lib/snapd/snapd[1321]: daemon.go:176: DEBUG: uid=0;@ POST /v2/assertions 1.954349145s 200 Mar 3 20:51:04 localhost /usr/bin/snap[1322]: cmd_auto_import.go:141: imported /run/snapd/auto-import/IXSFJDrt5ning-nk9fSN0I0zkJJC6FoQnFrSIsYTQVRScWLjlwUTcIMHfWROLi6l.assert Mar 3 20:51:04 localhost snap[1322]: 2017/03/03 20:51:04.558539 cmd_auto_import.go:141: imported /run/snapd/auto-import/IXSFJDrt5ning-nk9fSN0I0zkJJC6FoQnFrSIsYTQVRScWLjlwUTcIMHfWROLi6l.assert Mar 3 20:51:04 localhost /usr/lib/snapd/snapd[1321]: daemon.go:176: DEBUG: uid=0;@ POST /v2/create-user 364.779µs 200 Mar 3 20:51:04 localhost systemd[1]: Started Auto import assertions from block devices. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: syslog Type: application/octet-stream Size: 94829 bytes Desc: not available URL: From roberto.escandon at canonical.com Fri Mar 3 21:57:10 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Fri, 3 Mar 2017 22:57:10 +0100 Subject: plugins in snap? In-Reply-To: References: Message-ID: Thanks Leo, I didn't know about that discussion. I'll take a look. On 03/03/17 20:41, Leo Arias wrote: > Hello Roberto, > > On Fri, Mar 3, 2017 at 6:37 AM, Roberto Mier Escandón  > wrote: >> Maybe one silly question: I've moved plugins to be in snap/plugins path. >> All works fine, but I see them included in the snap package. Is there >> any way to avoid this?. I don't want the plugins there. > > We are trying to define what goes into the snap. For example, we want > the snapcraft.yaml some times in there, and if the snapcraft.yaml has > references to a custom plugin, maybe it makes sense to include that > plugin too. What we have currently is inconsistent, and thus a bug of > course. Your question is not silly at all, we need to improve there. > > Take a look at the discussion in > https://bugs.launchpad.net/snapcraft/+bug/1660890, and if you have > something to add, please leave a comment in there. > > pura vida. > From leo.arias at canonical.com Sat Mar 4 03:07:24 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 3 Mar 2017 21:07:24 -0600 Subject: sosreport and snaps In-Reply-To: <3df35514-5323-f788-26f0-092cadde5120@canonical.com> References: <3df35514-5323-f788-26f0-092cadde5120@canonical.com> Message-ID: Hello Louis! On Fri, Feb 17, 2017 at 11:35 AM, Louis Bouchard wrote: > If you have to diagnose a bug in the snappy ecosystem, what information will you > be asking for ? If some information is sensible, it can be obfuscated at > run-time so it is not included in the produced tarball. snap version, first. Then you probably want the audit lines in /var/log/syslog And the logs of the systemd daemons started when the snaps are installed. From leo.arias at canonical.com Sat Mar 4 03:55:56 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 3 Mar 2017 21:55:56 -0600 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: Hey Justin! On Wed, Feb 15, 2017 at 12:45 AM, Justin McPherson wrote: > I had a chance to take a quick look at this; see here > > > The plugin works in this case, with gist. But is not good enough to be a > general solution - no native extensions, probably need to clean up the > paths, etc. > > Happy to hear comments. Thanks, sounds like a good start. Why don't you send it upstream to snapcraft? We were discussing about flagging some plugins as experimental until we had a decent user base and a good number of real live projects building successfully. Even if this plugin only builds a few ruby projects, it serves us to get more people and projects interested and improving it. pura vida. From sunny.bhayani at einfochips.com Sat Mar 4 13:55:44 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Sat, 4 Mar 2017 13:55:44 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <1488289075.17360.26.camel@ubuntu.com> References: <1487755165.11513.51.camel@ubuntu.com>,<20170222102452.GA16955@harukaze> , <1488289075.17360.26.camel@ubuntu.com> Message-ID: Hi Oliver, Thank you for your reply. > hi, > Am Dienstag, den 28.02.2017, 13:03 +0000 schrieb Sunny Bhayani: > > > > But when we boot the kernel, we are getting stuck in kernel boot. It > > seems the kernel is not getting the initrd. The bootlogs are > > at: http://pastebin.com/eF2sCiyJ > > > looks fine to me > > ... > reading 96boards-kernel_x1.snap/initrd.img > 4821121 bytes read in 1315 ms (3.5 MiB/s) > ... > Unpacking initramfs... > Freeing initrd memory: 4708K (ffffffc004000000 - ffffffc004499000) > ... > > do you have a screen attached on HDMI ? We tried both: attaching HDMI Display on cold boot and cold boot without the HDMI out. But nothing comes on the display. We tried on two different HDMI Displays. > the kernel command line has: > > ... console=ttyMSM0,115200n8 console=tty0 ... > > which means that after firing up the kernel with serial console the > system will switch to tty0 for any further boot output. > (if everything works you should get a "please press enter" message > after a while on serial though) We waited for more than 30 minutes, but no message comes. We have a question. In earlier reply, Paolo told that over kernel is not xenial kernel. So is there a way, wherein you can point us to the kernel where the Dragonboard prebuilt images where built from, so that we can at least get to a point of the already released prebuilt images, and proceed further. 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. ************************************************************************************************************************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Sun Mar 5 12:56:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 5 Mar 2017 04:56:11 -0800 Subject: Using docker image to run snapd In-Reply-To: <1488403534.2815622.897329160.49E32ECA@webmail.messagingengine.com> References: <1488403534.2815622.897329160.49E32ECA@webmail.messagingengine.com> Message-ID: On Wed, Mar 1, 2017 at 1:25 PM, James Cooke wrote: > Hi there, > Hey! > > This appears to be the same error as asked about here: > http://askubuntu.com/questions/849859/error-when- > trying-to-run-snap-install-from-ubuntu-on-docker > (that's me in the comments). > I took a shot at trying to answer that directly on askubuntu -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Sun Mar 5 13:10:14 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 5 Mar 2017 05:10:14 -0800 Subject: Further ABI-related issues for ldc2 snap on 14.04 ... ? In-Reply-To: References: Message-ID: On Thu, Feb 23, 2017 at 12:18 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello all, > > I've encountered a couple of further issues with the ldc2 compiler snap > when it's installed on a 14.04 system. I'm sharing here to confirm if > these are indeed ABI issues which might be fixable in terms of how > snapcraft constructs the package. > > The first [1] relates to zlib, which is included as part of the D standard > library. This is built from a copy of the zlib C source and linked in to > the rest of the library. > > However, if I try to build a program that makes use of the zlib library > modules, linking fails with the following error: > > /usr/bin/gcc zlibtest.o -o zlibtest -L/snap/ldc2/x1/bin/../lib > -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections -lrt -ldl -lpthread -lm -m64 > /usr/bin/ld: /snap/ldc2/x1/bin/../lib/libphobos2-ldc.a(zutil.c.o): > unrecognized relocation (0x2a) in section `.text' > /usr/bin/ld: final link failed: Bad value > collect2: error: ld returned 1 exit status > Error: /usr/bin/gcc failed with status: 1 > > This matches the error message observed in a past Ubuntu issue related to > binutils: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1545653 > > which would suggest that there's a problematic mismatch between the > binutils used to build snap packages versus the one available on 14.04. > > The second issue [2] relates to a plugin for the gold linker that is built > for LDC to enable it to use link-time optimization. This works fine on > 16.04, 16.10 and 17.04, but requesting LTO on 14.04 results in linking > failing: > > /usr/bin/gcc hello.o -o hello -Xlinker -plugin -Xlinker > /snap/ldc2/x1/lib/LLVMgold-ldc.so -Xlinker -plugin-opt=O0 > -L/snap/ldc2/x1/bin/../lib -lphobos2-ldc -ldruntime-ldc -Wl,--gc-sections > -lrt -ldl -lpthread -lm -m64 > /usr/bin/ld: /snap/ldc2/x1/lib/LLVMgold-ldc.so: error loading plugin: > /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0: symbol > __libc_vfork, version GLIBC_PRIVATE not defined in file libc.so.6 with link > time reference > collect2: error: ld returned 1 exit status > Error: /usr/bin/gcc failed with status: 1 > > ... which looks to me like it is probably a mismatch between the libc used > to build the plugin, versus the libc of either the host system or the core > snap? > > I would presume that both the above would need a fix either snapcraft-side > or core snap side ... ? Can anyone advise/assist? > > I think you have come to a cross roads where you will need to choose to either always use the linker from the core snap and link to things from your snap or provide multiple zlib targets for different versions of glibc (or any other library you want to link with and provide it in your snap). If you are going to have things like /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 you would certainly want to use the linker in core. If you are going to use /usr/bin/gcc you probably shouldn't include libraries from `/snap/...`. I am sorry that I cannot help you more without deep diving into your project. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Sun Mar 5 13:48:24 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 5 Mar 2017 05:48:24 -0800 Subject: getting $LDFLAGS for a classic snap build in the plugin In-Reply-To: References: Message-ID: On Tue, Feb 28, 2017 at 6:11 PM, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > Hi, > > The magic of classic confinement snaps is all in passing special flags > when linking an executable. If I've read things right, snapcraft does this > by wrapping any command you execute with BasePlugin.run() with some shell > code that sets LDFLAGS. > > Unfortunately, for the go classic snap the underlying tool does not care > at all about LDFLAGS. What I do is create a wrapper: > > #!/bin/sh > exec gcc $LDFLAGS "$@" > > and point the go tool at that. This works but it would be a lot cleaner if > I could just get at the linker flags in my snap's plugin. Any chance that > could be added? > Hi there, I am sort of confused by the wording here, can you expand a bit on what you want. When you say "snap's plugin", what do you mean? I fear I am being dull but I honestly don't understand the question and given that it has gone unanswered for a couple of days maybe others are having issues parsing this as well (or maybe discussed on IRC and already taken care of). -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hudson at canonical.com Sun Mar 5 21:05:07 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Mon, 6 Mar 2017 10:05:07 +1300 Subject: getting $LDFLAGS for a classic snap build in the plugin In-Reply-To: References: Message-ID: On 6 March 2017 at 02:48, Sergio Schvezov wrote: > On Tue, Feb 28, 2017 at 6:11 PM, Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: > >> Hi, >> >> The magic of classic confinement snaps is all in passing special flags >> when linking an executable. If I've read things right, snapcraft does this >> by wrapping any command you execute with BasePlugin.run() with some shell >> code that sets LDFLAGS. >> >> Unfortunately, for the go classic snap the underlying tool does not care >> at all about LDFLAGS. What I do is create a wrapper: >> >> #!/bin/sh >> exec gcc $LDFLAGS "$@" >> >> and point the go tool at that. This works but it would be a lot cleaner >> if I could just get at the linker flags in my snap's plugin. Any chance >> that could be added? >> > > Hi there, I am sort of confused by the wording here, can you expand a bit > on what you want. When you say "snap's plugin", what do you mean? > > I fear I am being dull but I honestly don't understand the question and > given that it has gone unanswered for a couple of days maybe others are > having issues parsing this as well (or maybe discussed on IRC and already > taken care of). > My snap uses a custom plugin to build, so by "my snap's plugin" I mean https://git.launchpad.net/~mwhudson/+git/gosnap/tree/snap/plugins/x_gobuild.py?h=go1.8. In that code, I want to access the flags that need to be passed to the linker to make classic snaps link against the core snap rather than the usual path (-Wl,-z,nodefib, -Wl,-rpath,xxx, etc). Currently, as I read things, it can't (well not without very silly hacks). Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Sun Mar 5 22:24:05 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 5 Mar 2017 22:24:05 +0000 Subject: getting $LDFLAGS for a classic snap build in the plugin In-Reply-To: References: Message-ID: On Mon, 6 Mar 2017 10:05:07 +1300, Michael Hudson-Doyle wrote: > On 6 March 2017 at 02:48, Sergio Schvezov > wrote: > >> On Tue, Feb 28, 2017 at 6:11 PM, Michael Hudson-Doyle < >> michael.hudson at canonical.com> wrote: >> >>> Hi, >>> >>> The magic of classic confinement snaps is all in passing special flags >>> when linking an executable. If I've read things right, >>> snapcraft does this >>> by wrapping any command you execute with BasePlugin.run() with some shell >>> code that sets LDFLAGS. >>> >>> Unfortunately, for the go classic snap the underlying tool does not care >>> at all about LDFLAGS. What I do is create a wrapper: >>> >>> #!/bin/sh >>> exec gcc $LDFLAGS "$@" >>> >>> and point the go tool at that. This works but it would be a lot cleaner >>> if I could just get at the linker flags in my snap's plugin. Any chance >>> that could be added? >>> >> >> Hi there, I am sort of confused by the wording here, can you expand a bit >> on what you want. When you say "snap's plugin", what do you mean? >> >> I fear I am being dull but I honestly don't understand the question and >> given that it has gone unanswered for a couple of days maybe others are >> having issues parsing this as well (or maybe discussed on IRC and already >> taken care of). >> > > > My snap uses a custom plugin to build, so by "my snap's plugin" I mean > https://git.launchpad.net/~mwhudson/+git/gosnap/tree/snap/plugins/x_gobuild.py?h=go1.8. > In that code, I want to access the flags that need to be passed to the > linker to make classic snaps link against the core snap rather than the > usual path (-Wl,-z,nodefib, -Wl,-rpath,xxx, etc). Currently, as I read > things, it can't (well not without very silly hacks). We can certainly add support for this. Please log me a bug and I'll get to it. -- Sent using Dekko from my Ubuntu device From mark.shuttleworth at canonical.com Sat Mar 4 14:38:19 2017 From: mark.shuttleworth at canonical.com (Mark Shuttleworth) Date: Sat, 4 Mar 2017 15:38:19 +0100 Subject: Request for etcdctl alias autoconnect Message-ID: Hi folks The etcd database includes a client utility, etcdctl, which is included in the etcd snap as etcd.etcdctl. I'm writing to the list to proposed that be aliased to the top-level etcdctl on installation of etcd by default. The name of the utility is very distinctive and highly unlikely to conflict with any other use of the name. Thank you, Mark From paolo.pisati at canonical.com Mon Mar 6 17:16:57 2017 From: paolo.pisati at canonical.com (Paolo Pisati) Date: Mon, 6 Mar 2017 18:16:57 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: <1487755165.11513.51.camel@ubuntu.com> <20170222102452.GA16955@harukaze> <1488289075.17360.26.camel@ubuntu.com> Message-ID: Here is the Xenial kernel src tree, checkout the snapdragon branch: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/ it already contains a snapcraft.yaml so you can generate a working kernel snap (though the firmware files are missing here). On Sat, Mar 4, 2017 at 2:55 PM, Sunny Bhayani wrote: > Hi Oliver, > > Thank you for your reply. > >> hi, >> Am Dienstag, den 28.02.2017, 13:03 +0000 schrieb Sunny Bhayani: >> > >> > But when we boot the kernel, we are getting stuck in kernel boot. It >> > seems the kernel is not getting the initrd. The bootlogs are >> > at: http://pastebin.com/eF2sCiyJ >> > >> looks fine to me >> >> ... >> reading 96boards-kernel_x1.snap/initrd.img >> 4821121 bytes read in 1315 ms (3.5 MiB/s) >> ... >> Unpacking initramfs... >> Freeing initrd memory: 4708K (ffffffc004000000 - ffffffc004499000) >> ... >> >> do you have a screen attached on HDMI ? > We tried both: attaching HDMI Display on cold boot and cold boot without the > HDMI out. But nothing comes on the display. > > We tried on two different HDMI Displays. > >> the kernel command line has: >> >> ... console=ttyMSM0,115200n8 console=tty0 ... >> >> which means that after firing up the kernel with serial console the >> system will switch to tty0 for any further boot output. >> (if everything works you should get a "please press enter" message >> after a while on serial though) > > We waited for more than 30 minutes, but no message comes. > > We have a question. In earlier reply, Paolo told that over kernel is not > xenial > kernel. > > So is there a way, wherein you can point us to the kernel where the > Dragonboard > prebuilt images where built from, so that we can at least get to a point of > the > already released prebuilt images, and proceed further. > > 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. > ************************************************************************************************************************************************************* -- bye, p. From charles.butler at canonical.com Mon Mar 6 17:26:13 2017 From: charles.butler at canonical.com (Charles Butler) Date: Mon, 06 Mar 2017 17:26:13 +0000 Subject: Request for etcdctl alias autoconnect In-Reply-To: References: Message-ID: Greetings, I think this in itself would be preferable. My concerns would be collision while the deb is still installed which is a short window in the charm path. I think `snap alias etcd.etcdctl etcdctl` is the desired outcome here, so we aren't changing commands. I've worked around this in the interim by setting aliases in layer.yaml for paths. I would prefer to drop this workaround in favor of aliases for the snap. All the best, Charles On Mon, Mar 6, 2017 at 7:45 AM Mark Shuttleworth < mark.shuttleworth at canonical.com> wrote: > Hi folks > > The etcd database includes a client utility, etcdctl, which is included > in the etcd snap as etcd.etcdctl. > > I'm writing to the list to proposed that be aliased to the top-level > etcdctl on installation of etcd by default. The name of the utility is > very distinctive and highly unlikely to conflict with any other use of > the name. > > Thank you, > > Mark > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- Juju Charmer Canonical Group Ltd. Ubuntu - Linux for human beings | www.ubuntu.com conjure-up canonical-kubernetes | jujucharms.com From charles.butler at canonical.com Mon Mar 6 17:49:56 2017 From: charles.butler at canonical.com (Charles Butler) Date: Mon, 06 Mar 2017 17:49:56 +0000 Subject: Request for etcdctl alias autoconnect In-Reply-To: <1488822241.3377.1.camel@canonical.com> References: <1488822241.3377.1.camel@canonical.com> Message-ID: On Mon, Mar 6, 2017 at 11:44 AM Jamie Strandboge wrote: > On Mon, 2017-03-06 at 17:26 +0000, Charles Butler wrote: > > Greetings, > > > > I think this in itself would be preferable. My concerns would be > collision > > while the deb is still installed which is a short window in the charm > path. > > > > I think `snap alias etcd.etcdctl etcdctl` is the desired outcome here, so > > we aren't changing commands. I've worked around this in the interim by > > setting aliases in layer.yaml for paths. I would prefer to drop this > > workaround in favor of aliases for the snap. > > > > Are you saying that you like that the alias is now automatically applied > or that > you want to remove the auto-alias and have the alias to continue to be > manually > applied? > > Correct me if i'm wrong here - i'm still pretty new to the feature. Auto-aliasing would return feedback if there is a detected collision correct? So I think requesting it at point of install automatically is the desired behavior. If you encounter a scenario where an etcdctl exists, you can handle that collision manually and then setup the alias 'snap alias etcd.etcdctl etcd'. I think this outlines how I expected it to work. Sorry if that was less clear in my prior mail. > > On Mon, Mar 6, 2017 at 7:45 AM Mark Shuttleworth < > > mark.shuttleworth at canonical.com> wrote: > > > > > > > > Hi folks > > > > > > The etcd database includes a client utility, etcdctl, which is included > > > in the etcd snap as etcd.etcdctl. > > > > > > I'm writing to the list to proposed that be aliased to the top-level > > > etcdctl on installation of etcd by default. The name of the utility is > > > very distinctive and highly unlikely to conflict with any other use of > > > the name. > > > > > > Thank you, > > > > > > Mark > > > > > > > > > > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > > Juju Charmer > > Canonical Group Ltd. > > Ubuntu - Linux for human beings | www.ubuntu.com > > conjure-up canonical-kubernetes | jujucharms.com > -- > Jamie Strandboge | http://www.canonical.com > > -- Juju Charmer Canonical Group Ltd. Ubuntu - Linux for human beings | www.ubuntu.com conjure-up canonical-kubernetes | jujucharms.com From tim.sueberkrueb at web.de Mon Mar 6 18:01:35 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Mon, 6 Mar 2017 19:01:35 +0100 Subject: Handling versioning of platform snaps Message-ID: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> Hey everyone, as a member of the Liri OS project I'm working with our team towards providing our applications as snap packages. All our apps depend Qt and our custom UI framework (Fluid). Because of that we considered creating a platform snap similar to the ubuntu-app-platform as a good way to bundle our dependencies and minimize disk space usage. To archive this we're using the content interface (see snapcraft.yaml ). However, while evaluating this option, we considered the following: It is inevitable that we will at some point have to break compatibility of the libraries present in our platform snap. Because of different release schedules it is unlikely though that we would update all apps at the same which would result in breaking them as soon as the user downloads an incompatible update of the platform snap. As discussed on rocket chat , we are looking for ways to solve this problem. Our initial assumption was that the content interface would allow having separate versions of the platform snap installed as long as one installed app requires it. But this appears to be not possible by design. However, it seems possible that tracks and channels could provide a solution to this problem. This would allow us to use a separate track for incompatible platform snap versions if there is a way to specify for the individual app snaps which track they expect for the content interface (like it is possible to set the "default-provider"). Is there such an option? If not, would this be a possible addition to snap in order to allow use cases like this? Or is there a better way to solve the detailed issue? Thanks in advance for your help! All the best, Tim From brian at ubuntu.com Tue Mar 7 00:16:27 2017 From: brian at ubuntu.com (Brian Murray) Date: Mon, 6 Mar 2017 16:16:27 -0800 Subject: systemd timers Message-ID: <20170307001627.GJ4268@murraytwins.com> I wanted to replicate a cronjob in a snap that I'm writing and ended up (per someone's suggestion in irc) writing a simple daemon that sleeps for 24 hours then does its thing. I'm wondering if there are any plans to implement systemd timers for snaps and if so when they might be available. Thanks! -- Brian Murray From leo.arias at canonical.com Tue Mar 7 04:28:01 2017 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 6 Mar 2017 22:28:01 -0600 Subject: Crowdtesting with the Ubuntu community: the case of IPFS Message-ID: I wrote about my experiment using IPFS to test the snappy workflow end-to-end, with the Ubuntu community of testers: http://elopio.net/blog/ipfs-crowdtesting/ -- ¡paz y baile! http://www.ubuntu.com From n.curalli at domotz.com Tue Mar 7 10:19:32 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 7 Mar 2017 10:19:32 +0000 Subject: workaround for connect no autoconnect interfaces without login on system References: Message-ID: Hi all, I implemented hints from James but it doesn't works. I create a new gadget snap based on pc gadget for amd64, adding a hook directory with a prepare-device hook script. I make this script executable. I build an image containg my gadget (domotz-pc), pc-kernel and nmap snap from store. The layout of my new gadget snap ( named domotz-pc ) just installed is : ./ -rwxr-xr-x 1 root root 753 Mar 7 00:04 meta/gadget.yaml -rw-r--r-- 1 root root 230 Mar 7 09:11 meta/snap.yaml meta/gui: -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png meta/hooks: -rwxr-xr-x 1 root root 134 Mar 7 09:09 prepare-device The prepare-device script content is: ---------- #!/bin/sh # enabling network-control interface slot for nmap network-control plug snap connect nmap:network-control :network-control ---------- After the registration of board by console-conf i find the following I find the following situation on interface side: :network nmap :network-bind nmap - nmap:network-control instead :network nmap :network-bind nmap :network-control nmap as I wish. I also have the following error from Apparmor: Mar 7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 77 on Do: Run prepare-device hook Mar 7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400 audit(1488853390.962:25): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1428 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Mar 7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied Mar 7 02:28:08 localhost systemd[1]: Starting Update resolvconf for networkd DNS... Mar 7 02:28:08 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. Mar 7 02:28:08 localhost systemd[1]: Started Update resolvconf for networkd DNS. Mar 7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). Mar 7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 80 on Do: Run prepare-device hook Mar 7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400 audit(1488853690.938:26): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1455 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Mar 7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:28:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied Mar 7 02:33:07 localhost systemd[1]: Starting Update resolvconf for networkd DNS... Mar 7 02:33:07 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. Mar 7 02:33:07 localhost systemd[1]: Started Update resolvconf for networkd DNS. Mar 7 02:33:07 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). Mar 7 02:33:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 83 on Do: Run prepare-device hook Mar 7 02:33:10 localhost kernel: [11351844019.491749] audit: type=1400 audit(1488853990.964:27): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1475 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 Mar 7 02:33:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:33:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied Mar 7 02:38:07 localhost systemd[1]: Starting Update resolvconf for networkd DNS... Mar 7 02:38:07 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. Mar 7 02:38:07 localhost systemd[1]: Started Update resolvconf for networkd DNS. Mar 7 02:38:07 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). Mar 7 02:38:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 86 on Do: Run prepare-device hook Mar 7 02:38:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:38:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied Mar 7 02:38:10 localhost kernel: [11351844319.456207] audit: type=1400 audit(1488854290.935:28): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1496 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 It seems that is not possible exec a core apps from gadget, then what is the path to the solution for my use case? Perhaps I miss some important thing in prepare-device script? Thanks in advance for each hints and contribution to solve this use case. Nicolino From john.lenton at canonical.com Tue Mar 7 11:05:36 2017 From: john.lenton at canonical.com (John Lenton) Date: Tue, 7 Mar 2017 11:05:36 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: note that in that log, snapd isn't running because snapd[2217]: fatal error: runtime: out of memory On 22 February 2017 at 07:52, Sunny Bhayani wrote: > Hi Ogra, > > Appreciate for your help. > >> hi, >> Am Freitag, den 17.02.2017, 10:06 +0000 schrieb Sunny Bhayani: >> > >> > >> > You are correct that in the prebuilt image (Ubuntu OS) for >> > Dragonboard, the Wifi >> > module is auto-loaded during boot. But in our case, this does not >> > happen. >> > >> > So can you please let us know, that in what part (plugin) of the >> > snapcraft.yaml >> > do we need to mention the kernel modules that needs to be auto-loaded >> > during the >> > kernel boot. >> > >> > We tried to add the kernel module in the snapcraft.yaml as below: >> > >> > kernel-initrd-modules: >> > - squashfs >> > - wcn36xx >> >> this would just pull the module into the initrd which would be useless, >> since we do not ship any userspace bits for WIFI support in there. >> if you can modprobe it it is obviously already in the right place in >> your /lib/modules dir on the booted system, so first of all remove it >> from the list above. having it already loaded from the initrd on boot >> might make it miss the right initialization since it wont find all the >> userspace bits that it needs in the initrd. >> >> also make sure you have the firmware in the right place on the booted >> rootfs, this is how it looks like on the official dragoboard image: >> >> http://paste.ubuntu.com/24012991/ >> > Yes, we have the /lib/modules and /lib/firmware populated as you have > mentioned > above. > >> > >> > Also, we went through the kernel-initrd-modules description: >> > https://snapcraft.io/docs/reference/plugins/kernel >> > >> > and there it is mentioned that the "kernel-initrd-modules" plugin is >> > used to >> > mention the modules required to mount the rootfs. >> >> this means filesystem or disk controller modules (squashfs, ext4 (if >> you do not compile it in), mmc support and the like), since your system >> boots to a rootfs already you should not need anything more than you >> currently have. >> >> > > > Yes, agreed as you have mentioned above for the "kernel-initrd-modules". > >> > >> > It would be great if you can please help us out on this front as well >> > for the >> > snap list / snap install for the Ubuntu OS. >> >> this definitely means that snapd did not start for some reason, like i >> mentioned before this could be caused by the firstboot initialization >> of the board having failed or by some missing feature that snapd >> expects from your kernel. >> >> does sudo journalctl -u snapd.service reveal anything ? >> do you find anything interesting in syslog in general ? >> > We are seeing error related to AppArmor patches in journalctl log. > The log is at: http://pastebin.com/vG9DQfTf > >> > >> > >> > Yes. We are using a USB to Ethernet module on dragonboard to use the >> > Ethernet. >> > >> did you check if the behaviour of the WLAN device changes when booting >> without the USB dongle attached ? >> > This we have not checked. Will update for this. > >> > While using the prebuilt image for Dragonboard, we are able to >> > configure the >> > access point for Wifi interface in the first boot screen, but then >> > while doing >> > ssh to the board, it is asking for password (during first boot). How >> > can we >> > resolve this ? >> > >> >> did console-conf (the first boot configuration UI) actually finish the >> user creation properly (did it tell you about it and give you info >> about how to ssh into the board) without any errors ? >> >> /var/log/console-conf/subiquity-debug.log might be informative here. >> > The subiquity-debug.log is at: http://pastebin.com/39zsb4nE > > The AppArmor patches that we ported from the > http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/tree/arch/arm/configs/snappy?h=snappy_v3.10 > > are for the linux kernel 3.10. > > But the kernel that we are referring to is from 96boards - linux kernel 4.4. > > Moreover, the prebuilt image is also built for linux kernel 4.4. > > So do you have a kernel source for AppArmor patches which are ported on > linux > kernel 4.4 like the prebuilt Ubuntu Core Image for Dragonboard410c. > > Please provide the patchset link for the latest kernel. > > 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. > ************************************************************************************************************************************************************* > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From mark at ubuntu.com Tue Mar 7 13:06:46 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 7 Mar 2017 05:06:46 -0800 Subject: Handling versioning of platform snaps In-Reply-To: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> References: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> Message-ID: Hi Tim Welcome aboard, and thank you, this is exactly the type of question we want to be solving together on this list. The simplest approach would be to insert a major version/ABI indcation in the platform snap name. Something like lirios3 and lirios4 would be a very explicit way to provided different versions of your libraries. It would have the major benefit that both platform snaps could be installed at the same time, too, enabling a more natural app transition (each app can choose when to hop from 3 to 4) rather than a big-bang flag day for each device. The downside would be the incremental size of having both installed at once during that transition, but we continually see that 'time is more precious than disk space' so giving users a low-friction way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk. It might be worth looking into the linking of apps to particular tracks, but this raises a lot of tricky questions that I suspect would be a swamp with more problems than solutions. Does that sound like a reasonable starting point? Mark On 06/03/17 10:01, Tim Süberkrüb wrote: > Hey everyone, > > as a member of the Liri OS project I'm > working with our team towards providing our applications as snap > packages. All our apps depend Qt and our custom UI framework (Fluid). > Because of that we considered creating a platform snap similar to the > ubuntu-app-platform > > as a good way to bundle our dependencies and minimize disk space > usage. To archive this we're using the content interface (see > snapcraft.yaml > ). > > > However, while evaluating this option, we considered the following: It > is inevitable that we will at some point have to break compatibility > of the libraries present in our platform snap. Because of different > release schedules it is unlikely though that we would update all apps > at the same which would result in breaking them as soon as the user > downloads an incompatible update of the platform snap. > > As discussed on rocket chat > , we are looking for ways > to solve this problem. Our initial assumption was that the content > interface would allow having separate versions of the platform snap > installed as long as one installed app requires it. But this appears > to be not possible by design. > > However, it seems possible that tracks and channels > could provide a > solution to this problem. This would allow us to use a separate track > for incompatible platform snap versions if there is a way to specify > for the individual app snaps which track they expect for the content > interface (like it is possible to set the "default-provider"). Is > there such an option? If not, would this be a possible addition to > snap in order to allow use cases like this? Or is there a better way > to solve the detailed issue? > > Thanks in advance for your help! > > All the best, > > Tim > From sergio.schvezov at canonical.com Tue Mar 7 13:55:45 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 7 Mar 2017 13:55:45 +0000 Subject: Handling versioning of platform snaps In-Reply-To: References: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> Message-ID: On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote: > Hi Tim > > Welcome aboard, and thank you, this is exactly the type of question we > want to be solving together on this list. > > The simplest approach would be to insert a major version/ABI indcation > in the platform snap name. Something like lirios3 and lirios4 would be a > very explicit way to provided different versions of your libraries. It > would have the major benefit that both platform snaps could be installed > at the same time, too, enabling a more natural app transition (each app > can choose when to hop from 3 to 4) rather than a big-bang flag day for > each device. The downside would be the incremental size of having both > installed at once during that transition, but we continually see that > 'time is more precious than disk space' so giving users a low-friction > way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk. > > It might be worth looking into the linking of apps to particular tracks, > but this raises a lot of tricky questions that I suspect would be a > swamp with more problems than solutions. > > Does that sound like a reasonable starting point? This is what I suggested during the rocket chat conversations and I agree it is the best way to move forward. What is interesting here is (once there is support to bring in default slot implemetations for an interface), to garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules). -- Sent using Dekko from my Ubuntu device From kyle.nitzsche at canonical.com Tue Mar 7 14:19:35 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Tue, 7 Mar 2017 09:19:35 -0500 Subject: workaround for connect no autoconnect interfaces without login on system In-Reply-To: References: Message-ID: I don't think the prepare-device script can be used to auto connect, probably because it runs confined. You can request the store to add an auto connection statement to the snap declaration assertion. Cheers kyleN On 03/07/2017 05:19 AM, Nicolino Curalli wrote: > Hi all, > I implemented hints from James but it doesn't works. > > I create a new gadget snap based on pc gadget for amd64, adding a hook directory with a prepare-device hook script. > I make this script executable. > I build an image containg my gadget (domotz-pc), pc-kernel and nmap snap from store. > > The layout of my new gadget snap ( named domotz-pc ) just installed is : > > ./ > > -rwxr-xr-x 1 root root 753 Mar 7 00:04 meta/gadget.yaml > -rw-r--r-- 1 root root 230 Mar 7 09:11 meta/snap.yaml > > meta/gui: > > -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png > > meta/hooks: > > -rwxr-xr-x 1 root root 134 Mar 7 09:09 prepare-device > > The prepare-device script content is: > > ---------- > #!/bin/sh > > # enabling network-control interface slot for nmap network-control plug > snap connect nmap:network-control :network-control > ---------- > > After the registration of board by console-conf i find the following I find the following situation on interface side: > > :network nmap > :network-bind nmap > - nmap:network-control > > instead > > :network nmap > :network-bind nmap > :network-control nmap > > as I wish. > > I also have the following error from Apparmor: > > Mar 7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 77 on Do: Run prepare-device hook > Mar 7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400 audit(1488853390.962:25): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1428 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > Mar 7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied > Mar 7 02:28:08 localhost systemd[1]: Starting Update resolvconf for networkd DNS... > Mar 7 02:28:08 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. > Mar 7 02:28:08 localhost systemd[1]: Started Update resolvconf for networkd DNS. > Mar 7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). > Mar 7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 80 on Do: Run prepare-device hook > Mar 7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400 audit(1488853690.938:26): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1455 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > Mar 7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:28:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied > Mar 7 02:33:07 localhost systemd[1]: Starting Update resolvconf for networkd DNS... > Mar 7 02:33:07 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. > Mar 7 02:33:07 localhost systemd[1]: Started Update resolvconf for networkd DNS. > Mar 7 02:33:07 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). > Mar 7 02:33:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 83 on Do: Run prepare-device hook > Mar 7 02:33:10 localhost kernel: [11351844019.491749] audit: type=1400 audit(1488853990.964:27): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1475 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > Mar 7 02:33:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:33:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied > Mar 7 02:38:07 localhost systemd[1]: Starting Update resolvconf for networkd DNS... > Mar 7 02:38:07 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. > Mar 7 02:38:07 localhost systemd[1]: Started Update resolvconf for networkd DNS. > Mar 7 02:38:07 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). > Mar 7 02:38:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 86 on Do: Run prepare-device hook > Mar 7 02:38:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:38:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied > Mar 7 02:38:10 localhost kernel: [11351844319.456207] audit: type=1400 audit(1488854290.935:28): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1496 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > It seems that is not possible exec a core apps from gadget, then what is the path to the solution for my use case? Perhaps I miss some important thing in prepare-device script? > > Thanks in advance for each hints and contribution to solve this use case. > > > Nicolino > > From n.curalli at domotz.com Tue Mar 7 15:05:04 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 7 Mar 2017 15:05:04 +0000 Subject: workaround for connect no autoconnect interfaces without login on system References: Message-ID: Hi kyleN thanks so much for the answer. A question for go ahead from my side: how can I request the store to add an auto connection statement to the snap declaration assertion ? Thanks a lot Nicolino Il 07/03/2017 15:20, knitzsche ha scritto: > I don't think the prepare-device script can be used to auto connect, > probably because it runs confined. > > You can request the store to add an auto connection statement to the > snap declaration assertion. > > Cheers > kyleN > > > On 03/07/2017 05:19 AM, Nicolino Curalli wrote: >> Hi all, >> I implemented hints from James but it doesn't works. >> >> I create a new gadget snap based on pc gadget for amd64, adding a hook directory with a prepare-device hook script. >> I make this script executable. >> I build an image containg my gadget (domotz-pc), pc-kernel and nmap snap from store. >> >> The layout of my new gadget snap ( named domotz-pc ) just installed is : >> >> ./ >> >> -rwxr-xr-x 1 root root 753 Mar 7 00:04 meta/gadget.yaml >> -rw-r--r-- 1 root root 230 Mar 7 09:11 meta/snap.yaml >> >> meta/gui: >> >> -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png >> >> meta/hooks: >> >> -rwxr-xr-x 1 root root 134 Mar 7 09:09 prepare-device >> >> The prepare-device script content is: >> >> ---------- >> #!/bin/sh >> >> # enabling network-control interface slot for nmap network-control plug >> snap connect nmap:network-control :network-control >> ---------- >> >> After the registration of board by console-conf i find the following I find the following situation on interface side: >> >> :network nmap >> :network-bind nmap >> - nmap:network-control >> >> instead >> >> :network nmap >> :network-bind nmap >> :network-control nmap >> >> as I wish. >> >> I also have the following error from Apparmor: >> >> Mar 7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 77 on Do: Run prepare-device hook >> Mar 7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400 audit(1488853390.962:25): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1428 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 >> Mar 7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied >> Mar 7 02:28:08 localhost systemd[1]: Starting Update resolvconf for networkd DNS... >> Mar 7 02:28:08 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. >> Mar 7 02:28:08 localhost systemd[1]: Started Update resolvconf for networkd DNS. >> Mar 7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). >> Mar 7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 80 on Do: Run prepare-device hook >> Mar 7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400 audit(1488853690.938:26): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1455 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 >> Mar 7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:28:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied >> Mar 7 02:33:07 localhost systemd[1]: Starting Update resolvconf for networkd DNS... >> Mar 7 02:33:07 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. >> Mar 7 02:33:07 localhost systemd[1]: Started Update resolvconf for networkd DNS. >> Mar 7 02:33:07 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). >> Mar 7 02:33:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 83 on Do: Run prepare-device hook >> Mar 7 02:33:10 localhost kernel: [11351844019.491749] audit: type=1400 audit(1488853990.964:27): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1475 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 >> Mar 7 02:33:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:33:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied >> Mar 7 02:38:07 localhost systemd[1]: Starting Update resolvconf for networkd DNS... >> Mar 7 02:38:07 localhost systemd-timesyncd[795]: Network configuration changed, trying to establish connection. >> Mar 7 02:38:07 localhost systemd[1]: Started Update resolvconf for networkd DNS. >> Mar 7 02:38:07 localhost systemd-timesyncd[795]: Synchronized to time server 91.189.94.4:123 (ntp.ubuntu.com). >> Mar 7 02:38:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: DEBUG: Running task 86 on Do: Run prepare-device hook >> Mar 7 02:38:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: 2017-03-07T02:38:10Z ERROR run hook "prepare-device": /snap/domotz-pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare-device: snap: Permission denied >> Mar 7 02:38:10 localhost kernel: [11351844319.456207] audit: type=1400 audit(1488854290.935:28): apparmor="DENIED" operation="exec" profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1496 comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 >> >> >> It seems that is not possible exec a core apps from gadget, then what is the path to the solution for my use case? Perhaps I miss some important thing in prepare-device script? >> >> Thanks in advance for each hints and contribution to solve this use case. >> >> >> Nicolino >> >> From mark at ubuntu.com Tue Mar 7 16:24:23 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 7 Mar 2017 08:24:23 -0800 Subject: workaround for connect no autoconnect interfaces without login on system In-Reply-To: References: Message-ID: <071c8e99-0fee-fe05-fedb-094edc2c1d6c@ubuntu.com> On 07/03/17 07:05, Nicolino Curalli wrote: > A question for go ahead from my side: > how can I request the store to add an auto connection statement to the > snap declaration assertion ? On this list, just outline: * the top-level binary name you think should be claimed * why that is unlikely to conflict with other potential snaps As an example, something like 'etcdctl' is very unlikely to conflict with anything other than a snap of etcd. And something like 'vi' is very likely to have a LOT of people thinking hard about how to manage conflicts. If in doubt, snap.command is still the best way to avoid conflicts altogether. Mark From mark at ubuntu.com Tue Mar 7 16:27:06 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 7 Mar 2017 08:27:06 -0800 Subject: systemd timers In-Reply-To: <20170307001627.GJ4268@murraytwins.com> References: <20170307001627.GJ4268@murraytwins.com> Message-ID: <22c467b9-60a3-95f4-5bd7-b1d6111a760c@ubuntu.com> I think scheduled tasks make sense as a first-class primitive. In the same way we don't simply embed systemd units, but rather describe what we want and have snapd generate the units accordingly, we probably want to describe a simple kind of schedule and have snapd map that to either cron or systemd depending on underlying OS. Mark From gustavo at niemeyer.net Tue Mar 7 16:57:32 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 7 Mar 2017 13:57:32 -0300 Subject: systemd timers In-Reply-To: <22c467b9-60a3-95f4-5bd7-b1d6111a760c@ubuntu.com> References: <20170307001627.GJ4268@murraytwins.com> <22c467b9-60a3-95f4-5bd7-b1d6111a760c@ubuntu.com> Message-ID: Yes, that's definitely what we want to do. Have a description in the app section in the yaml which allows recurring execution. On Tue, Mar 7, 2017 at 1:27 PM, Mark Shuttleworth wrote: > > I think scheduled tasks make sense as a first-class primitive. In the > same way we don't simply embed systemd units, but rather describe what > we want and have snapd generate the units accordingly, we probably want > to describe a simple kind of schedule and have snapd map that to either > cron or systemd depending on underlying OS. > > Mark > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net From tim.sueberkrueb at web.de Tue Mar 7 18:07:56 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Tue, 7 Mar 2017 19:07:56 +0100 Subject: Handling versioning of platform snaps In-Reply-To: References: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> Message-ID: <2764670f-1982-1415-9bea-9465a87a9d75@web.de> Hey Sergio and Mark, thanks very much for your help. After discussing different possible solutions in the team and the conversation on rocket chat I think that this is probably the best solution currently possible. We also considered other ways like placing different library versions in the platform snap but that would be in the end much more hassle and much more hacky than separating them. Nevertheless, I still think there could be a better and more convenient solution for this use case though - at least in theory. Sergio explained to me that it is not possible to have different versions of the same snap active, which is - I assume - the main reason why it's impossible to use different versions of the same runtime/platform snap, while Flatpak offers this functionality. I'm not familiar with the technical details of snap. There might be technical or other reasons why this is not something snap should offer. But if it is possible, I think it would be very reasonable to allow snaps to specify a specific version for a content interface plus being able to have separate versions of the same snap installed as long as another app depends on it. This would - if implemented flexible enough - not only benefit our specific use case but anyone who would like to control versioning of snaps connecting with the content interface (e.g. a snap that supports specific plugin versions of some sort of extension). Again, this is just a suggestion, that I as a user without much knowledge about the internals find reasonable. This might not fit in the concept of snaps for a good reason. Thanks for bearing with me! > [...] garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules I think that would be good to have! Have a nice day, Tim On 07.03.2017 14:55, Sergio Schvezov wrote: > On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote: >> Hi Tim >> >> Welcome aboard, and thank you, this is exactly the type of question we >> want to be solving together on this list. >> >> The simplest approach would be to insert a major version/ABI indcation >> in the platform snap name. Something like lirios3 and lirios4 would be a >> very explicit way to provided different versions of your libraries. It >> would have the major benefit that both platform snaps could be installed >> at the same time, too, enabling a more natural app transition (each app >> can choose when to hop from 3 to 4) rather than a big-bang flag day for >> each device. The downside would be the incremental size of having both >> installed at once during that transition, but we continually see that >> 'time is more precious than disk space' so giving users a low-friction >> way to 'just work' is more useful than saving 0.2 GB of their 1 TB disk. >> >> It might be worth looking into the linking of apps to particular tracks, >> but this raises a lot of tricky questions that I suspect would be a >> swamp with more problems than solutions. >> >> Does that sound like a reasonable starting point? > This is what I suggested during the rocket chat conversations and I agree it is the best way to move forward. What is interesting here is (once there is support to bring in default slot implemetations for an interface), to garbage collect all the liriosX-1 snaps that are not connected to anything (or whatever number makes sense with rollbacks and current garbage collection rules). > From jian.luo.cn at gmail.com Tue Mar 7 18:38:18 2017 From: jian.luo.cn at gmail.com (Jian LUO) Date: Tue, 7 Mar 2017 19:38:18 +0100 Subject: Configs are still available after snap is removed. Bug or feature? In-Reply-To: References: Message-ID: Hi list, I found out that if a certain snap got removed, its configuration set by snapctl is still accessible through 'snap get'. Is it a bug or a feature? And if it's a feature, what is the use case? Thanks, Jian From jcoates at extremenetworks.com Tue Mar 7 22:06:58 2017 From: jcoates at extremenetworks.com (Joe Coates) Date: Tue, 7 Mar 2017 22:06:58 +0000 Subject: snapcraft 2.27 has been released In-Reply-To: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> References: <38650668-de8e-d5a2-eb6c-1edf50ac5923@canonical.com> Message-ID: This thread got sidetracked to a different discussion, but I am seeing issues related to the original question. I have a simple test app which looks like this in snapcraft .yaml: apps: tester: command: usr/bin/echo-vars.sh environment: MY_RO_AREA: $SNAP MY_RO_AREA_BAD: $SNAP/etc/myro MY_RW_AREA: $SNAP_DATA MY_RW_AREA_BAD: $SNAP_DATA/myrw plugs: [ network, network-bind ] The command simply echos the values of those variables like this: echo "MY_RO_AREA = $MY_RO_AREA" On Ubuntu-core the literal part of the string is doubled: jwcoates at localhost:~$ snap run tester MY_RO_AREA = /snap/tester/x1 MY_RO_AREA_BAD = /snap/tester/x1/etc/myro/etc/myro <<<<<<<<< MY_RW_AREA = /var/snap/tester/x1 MY_RW_AREA_BAD = /var/snap/tester/x1/myrw/myrw <<<<<<<<< jwcoates at localhost:~$ snap --version snap 2.23 snapd 2.23 series 16 kernel 4.4.0-53-generic On Ubuntu classic the $SNAP variables are not expanded (exact same snap executed): netop at Snappy-Appliance:~$ sudo snap run tester MY_RO_AREA = $SNAP MY_RO_AREA_BAD = $SNAP/etc/myro MY_RW_AREA = $SNAP_DATA MY_RW_AREA_BAD = $SNAP_DATA/myrw netop at Snappy-Appliance:~$ snap --version snap 2.22.7 snapd 2.22.7 series 16 ubuntu 16.04 kernel 4.4.0-65-generic Anyone else seeing this ? Thanks, Joe Coates -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Kyle Fazzari Sent: Friday, February 24, 2017 2:06 PM To: snapcraft at lists.snapcraft.io Subject: Re: snapcraft 2.27 has been released On 02/24/2017 10:49 AM, Claudio André wrote: > > 2017-02-17 10:49 GMT-02:00 Sergio Schvezov > >: > > Hello snapcrafters! > > ## Setting up environment > > No more wrapper scripts just to setup on environment entry, this is > now tied into an app entry in `apps`. Here's a quick example: > > ```yaml > apps: > vim: > command: bin/vim > environment: > VIMRUNTIME: $SNAP/share/vim/vim80 > ``` > > > Hi, I tried to append to path (see below). It is not supported. > > ```yaml > environment: > PATH: "$SNAP/usr/lib/jvm/default-java/bin:$PATH" > ``` > > I'm ok with it. But, in case this is not by design, I'm mailing you guys. I can verify this. To clarify, this builds and runs fine, but actually results in the PATH including the string `$PATH` instead of expanding it. Can a snapd dev comment on this? Is that intended? -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. From pat.mcgowan at canonical.com Tue Mar 7 22:24:36 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Tue, 7 Mar 2017 17:24:36 -0500 Subject: Configs are still available after snap is removed. Bug or feature? In-Reply-To: References: Message-ID: On Tue, Mar 7, 2017 at 1:38 PM, Jian LUO wrote: > Hi list, > > I found out that if a certain snap got removed, its configuration set by > snapctl is still accessible through 'snap get'. Is it a bug or a feature? > And if it's a feature, what is the use case? > Jian See https://bugs.launchpad.net/snapd/+bug/1636934 Pat > > Thanks, > > Jian > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From jian.luo.cn at gmail.com Tue Mar 7 22:47:25 2017 From: jian.luo.cn at gmail.com (Jian LUO) Date: Tue, 7 Mar 2017 23:47:25 +0100 Subject: Configs are still available after snap is removed. Bug or feature? In-Reply-To: References: Message-ID: Thanks Pat. Should try searching on Launchpad first.😅 Cheers, Jian Am 07.03.2017 11:25 nachm. schrieb "Pat McGowan" : On Tue, Mar 7, 2017 at 1:38 PM, Jian LUO wrote: > Hi list, > > I found out that if a certain snap got removed, its configuration set by > snapctl is still accessible through 'snap get'. Is it a bug or a feature? > And if it's a feature, what is the use case? > Jian See https://bugs.launchpad.net/snapd/+bug/1636934 Pat > > Thanks, > > Jian > -- > 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/mailm an/listinfo/snapcraft From pawel.stolowski at canonical.com Wed Mar 8 08:05:54 2017 From: pawel.stolowski at canonical.com (Pawel Stolowski) Date: Wed, 8 Mar 2017 09:05:54 +0100 Subject: Configs are still available after snap is removed. Bug or feature? In-Reply-To: References: Message-ID: Hi, Yes, it's a bug https://bugs.launchpad.net/snapd/+bug/1636934 Cheers, Pawel On 07.03.2017 19:38, Jian LUO wrote: > Hi list, > > I found out that if a certain snap got removed, its configuration set by > snapctl is still accessible through 'snap get'. Is it a bug or a feature? > And if it's a feature, what is the use case? > > Thanks, > > Jian From renat2017 at gmail.com Wed Mar 8 09:43:44 2017 From: renat2017 at gmail.com (=?UTF-8?B?0KDQtdC90LDRgiDQk9Cw0LvQuNC80L7Qsg==?=) Date: Wed, 8 Mar 2017 12:43:44 +0300 Subject: Updating a gadget snap Message-ID: Hi, everyone. We need a way to make "snap.yaml," hooks and, possibly, other stuff of our gadget snap updateable. The only way now I see is to provide a hook, which will download or get files from the filesystem and replace files on the image by them, but such a solution seem dangerous to me, because of the violation of the snaps rollback idea. Is there anything related to the gadget snaps update planned, or, maybe, somebody already resolved the issue? Thank you, Renat From jamie.bennett at canonical.com Wed Mar 8 10:06:05 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Wed, 8 Mar 2017 10:06:05 +0000 Subject: Updating a gadget snap In-Reply-To: References: Message-ID: Hi Renat, We are working on making parts of the gadget snap updatable for example, on RPi, updating config.txt makes sense, but as you say this is a dangerous area to be playing with as bricking the device is possible. Michael knows more as he has be directly working on this lately. Regards, Jamie. On Wed, Mar 8, 2017 at 9:43 AM, Ренат Галимов wrote: > Hi, everyone. > > We need a way to make "snap.yaml," hooks and, possibly, other stuff of our > gadget snap updateable. > > The only way now I see is to provide a hook, which will download or get > files from the filesystem and replace files on the image by them, but such > a solution seem dangerous to me, because of the violation of the snaps > rollback idea. > > Is there anything related to the gadget snaps update planned, or, maybe, > somebody already resolved the issue? > > > Thank you, > Renat > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From renat2017 at gmail.com Wed Mar 8 10:54:55 2017 From: renat2017 at gmail.com (=?UTF-8?B?0KDQtdC90LDRgiDQk9Cw0LvQuNC80L7Qsg==?=) Date: Wed, 8 Mar 2017 13:54:55 +0300 Subject: Updating a gadget snap In-Reply-To: References: Message-ID: Thanks, Jamie. The reason we need this feature is to deliver a product to out customers as soon as possible and then apply changes made in the rpi3 gadget snap as they become ready. Best regards, Renat On Wed, Mar 8, 2017 at 1:06 PM, Jamie Bennett wrote: > Hi Renat, > > We are working on making parts of the gadget snap updatable for example, on > RPi, updating config.txt makes sense, but as you say this is a dangerous > area to be playing with as bricking the device is possible. Michael knows > more as he has be directly working on this lately. > > Regards, > Jamie. > > On Wed, Mar 8, 2017 at 9:43 AM, Ренат Галимов wrote: > > > Hi, everyone. > > > > We need a way to make "snap.yaml," hooks and, possibly, other stuff of > our > > gadget snap updateable. > > > > The only way now I see is to provide a hook, which will download or get > > files from the filesystem and replace files on the image by them, but > such > > a solution seem dangerous to me, because of the violation of the snaps > > rollback idea. > > > > Is there anything related to the gadget snaps update planned, or, maybe, > > somebody already resolved the issue? > > > > > > Thank you, > > Renat > > -- > > 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 mark at ubuntu.com Wed Mar 8 12:48:47 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 8 Mar 2017 04:48:47 -0800 Subject: Handling versioning of platform snaps In-Reply-To: <2764670f-1982-1415-9bea-9465a87a9d75@web.de> References: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> <2764670f-1982-1415-9bea-9465a87a9d75@web.de> Message-ID: <83b34ead-3b1a-7a6b-7cfe-975d6a424f5c@ubuntu.com> Snaps have a much stronger sense of identity. They *own* /snap/foo and that means you can build a much more predictable and reliable view of their behavior. Versioning is a key part of the snap story, it gives the user and the publiisher of the software a really *great* way to describe what they are releasing or what they are conuming on any particular device. The upstreams and the users that I have talked to generally say they *love* it. The fact that we know exactly where a snap is allows for rich interplay between snaps, like the way snaps can use the core snap, or other snaps through content interfaces. However, all of these things also required that we choose not to mount snaps in arbitrary locations. That ends up driving the requirement that you have administrative rights on a device if you want to change the set of installed snaps, and also that you can only have one active version at a time. In the case of libraries and frameworks, you don't have to worry about persistent data that can or cannot be shared between the two versions. You would need to know the two paths of the two versions *anyway* in order to use them. THere is no semantic difference in your code between /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be more complex one way or the other. Mark On 07/03/17 10:07, Tim Süberkrüb wrote: > Hey Sergio and Mark, > > thanks very much for your help. > > After discussing different possible solutions in the team and the > conversation on rocket chat I think that this is probably the best > solution currently possible. We also considered other ways like > placing different library versions in the platform snap but that would > be in the end much more hassle and much more hacky than separating them. > > Nevertheless, I still think there could be a better and more > convenient solution for this use case though - at least in theory. > Sergio explained to me that it is not possible to have different > versions of the same snap active, which is - I assume - the main > reason why it's impossible to use different versions of the same > runtime/platform snap, while Flatpak offers this functionality. > > I'm not familiar with the technical details of snap. There might be > technical or other reasons why this is not something snap should > offer. But if it is possible, I think it would be very reasonable to > allow snaps to specify a specific version for a content interface plus > being able to have separate versions of the same snap installed as > long as another app depends on it. > > This would - if implemented flexible enough - not only benefit our > specific use case but anyone who would like to control versioning of > snaps connecting with the content interface (e.g. a snap that supports > specific plugin versions of some sort of extension). > > Again, this is just a suggestion, that I as a user without much > knowledge about the internals find reasonable. This might not fit in > the concept of snaps for a good reason. > > Thanks for bearing with me! > > > [...] garbage collect all the liriosX-1 snaps that are not connected > to anything (or whatever number makes sense with rollbacks and current > garbage collection rules > > I think that would be good to have! > > Have a nice day, > > Tim > > On 07.03.2017 14:55, Sergio Schvezov wrote: >> On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote: >>> Hi Tim >>> >>> Welcome aboard, and thank you, this is exactly the type of question we >>> want to be solving together on this list. >>> >>> The simplest approach would be to insert a major version/ABI indcation >>> in the platform snap name. Something like lirios3 and lirios4 would >>> be a >>> very explicit way to provided different versions of your libraries. It >>> would have the major benefit that both platform snaps could be >>> installed >>> at the same time, too, enabling a more natural app transition (each app >>> can choose when to hop from 3 to 4) rather than a big-bang flag day for >>> each device. The downside would be the incremental size of having both >>> installed at once during that transition, but we continually see that >>> 'time is more precious than disk space' so giving users a low-friction >>> way to 'just work' is more useful than saving 0.2 GB of their 1 TB >>> disk. >>> >>> It might be worth looking into the linking of apps to particular >>> tracks, >>> but this raises a lot of tricky questions that I suspect would be a >>> swamp with more problems than solutions. >>> >>> Does that sound like a reasonable starting point? >> This is what I suggested during the rocket chat conversations and I >> agree it is the best way to move forward. What is interesting here is >> (once there is support to bring in default slot implemetations for an >> interface), to garbage collect all the liriosX-1 snaps that are not >> connected to anything (or whatever number makes sense with rollbacks >> and current garbage collection rules). >> > > From tim.sueberkrueb at web.de Wed Mar 8 17:04:01 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Wed, 8 Mar 2017 18:04:01 +0100 Subject: Handling versioning of platform snaps In-Reply-To: <83b34ead-3b1a-7a6b-7cfe-975d6a424f5c@ubuntu.com> References: <76e34c83-638b-6444-ada4-b33dbbecab34@web.de> <2764670f-1982-1415-9bea-9465a87a9d75@web.de> <83b34ead-3b1a-7a6b-7cfe-975d6a424f5c@ubuntu.com> Message-ID: <0b8df6ea-ea6a-820c-a754-0664c4054304@web.de> Hey Mark, thank you for explaining this, the reasons are clearer to me now. > In the case of libraries and frameworks, you don't have to worry about > persistent data that can or cannot be shared between the two versions. > You would need to know the two paths of the two versions *anyway* in > order to use them. THere is no semantic difference in your code between > /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be > more complex one way or the other. You're right, that's a good point. The only difference is that it's slightly harder to maintain because instead of maintaining different versions of one package we need to maintain different versions of different packages. And for each new version, a new name has to be registered which is probably going to be harder to automate. Nevertheless, I agree, it is not such a big deal. As for Liri, we're now discussing different options inside of our team. I'm generally very happy with the developer experience of snapcraft and the user experience of snap and I'm really looking forward to see snaps running on Ubuntu phones & tablets. Thanks again for taking your time to help us! All the best, Tim On 08.03.2017 13:48, Mark Shuttleworth wrote: > Snaps have a much stronger sense of identity. They *own* /snap/foo and > that means you can build a much more predictable and reliable view of > their behavior. Versioning is a key part of the snap story, it gives the > user and the publiisher of the software a really *great* way to describe > what they are releasing or what they are conuming on any particular > device. The upstreams and the users that I have talked to generally say > they *love* it. > > The fact that we know exactly where a snap is allows for rich interplay > between snaps, like the way snaps can use the core snap, or other snaps > through content interfaces. > > However, all of these things also required that we choose not to mount > snaps in arbitrary locations. That ends up driving the requirement that > you have administrative rights on a device if you want to change the set > of installed snaps, and also that you can only have one active version > at a time. > > In the case of libraries and frameworks, you don't have to worry about > persistent data that can or cannot be shared between the two versions. > You would need to know the two paths of the two versions *anyway* in > order to use them. THere is no semantic difference in your code between > /snap/foo-4.7 and snap/foo/4.7 so your own app code isn't going to be > more complex one way or the other. > > Mark > > On 07/03/17 10:07, Tim Süberkrüb wrote: >> Hey Sergio and Mark, >> >> thanks very much for your help. >> >> After discussing different possible solutions in the team and the >> conversation on rocket chat I think that this is probably the best >> solution currently possible. We also considered other ways like >> placing different library versions in the platform snap but that would >> be in the end much more hassle and much more hacky than separating them. >> >> Nevertheless, I still think there could be a better and more >> convenient solution for this use case though - at least in theory. >> Sergio explained to me that it is not possible to have different >> versions of the same snap active, which is - I assume - the main >> reason why it's impossible to use different versions of the same >> runtime/platform snap, while Flatpak offers this functionality. >> >> I'm not familiar with the technical details of snap. There might be >> technical or other reasons why this is not something snap should >> offer. But if it is possible, I think it would be very reasonable to >> allow snaps to specify a specific version for a content interface plus >> being able to have separate versions of the same snap installed as >> long as another app depends on it. >> >> This would - if implemented flexible enough - not only benefit our >> specific use case but anyone who would like to control versioning of >> snaps connecting with the content interface (e.g. a snap that supports >> specific plugin versions of some sort of extension). >> >> Again, this is just a suggestion, that I as a user without much >> knowledge about the internals find reasonable. This might not fit in >> the concept of snaps for a good reason. >> >> Thanks for bearing with me! >> >>> [...] garbage collect all the liriosX-1 snaps that are not connected >> to anything (or whatever number makes sense with rollbacks and current >> garbage collection rules >> >> I think that would be good to have! >> >> Have a nice day, >> >> Tim >> >> On 07.03.2017 14:55, Sergio Schvezov wrote: >>> On Tue, 7 Mar 2017 05:06:46 -0800, Mark Shuttleworth wrote: >>>> Hi Tim >>>> >>>> Welcome aboard, and thank you, this is exactly the type of question we >>>> want to be solving together on this list. >>>> >>>> The simplest approach would be to insert a major version/ABI indcation >>>> in the platform snap name. Something like lirios3 and lirios4 would >>>> be a >>>> very explicit way to provided different versions of your libraries. It >>>> would have the major benefit that both platform snaps could be >>>> installed >>>> at the same time, too, enabling a more natural app transition (each app >>>> can choose when to hop from 3 to 4) rather than a big-bang flag day for >>>> each device. The downside would be the incremental size of having both >>>> installed at once during that transition, but we continually see that >>>> 'time is more precious than disk space' so giving users a low-friction >>>> way to 'just work' is more useful than saving 0.2 GB of their 1 TB >>>> disk. >>>> >>>> It might be worth looking into the linking of apps to particular >>>> tracks, >>>> but this raises a lot of tricky questions that I suspect would be a >>>> swamp with more problems than solutions. >>>> >>>> Does that sound like a reasonable starting point? >>> This is what I suggested during the rocket chat conversations and I >>> agree it is the best way to move forward. What is interesting here is >>> (once there is support to bring in default slot implemetations for an >>> interface), to garbage collect all the liriosX-1 snaps that are not >>> connected to anything (or whatever number makes sense with rollbacks >>> and current garbage collection rules). >>> >> > > From michael.vogt at canonical.com Thu Mar 9 08:30:43 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Thu, 9 Mar 2017 09:30:43 +0100 Subject: New snapd 2.23.1 release Message-ID: <20170309083043.GL23539@bod> Hi all, on top of 2.23 we released a small bugfix release: 2.23.1. We noticed that an incompatiblity in the content interface slipped into the 2.23 release and this is fixed now in 2.23.1. We used the opportunity to fix some more small bugs in 2.23.1, most importantly a bug that can result in an upgrade failure for snaps with hooks. The new release is available in the "core" (and "ubuntu-core") snap on the "candidate" channel and also in the Ubuntu 14.04, 16.04, 16.10 "proposed" pockets and in 17.04. More distributions will follow at their own pace. To install this new release you need to run the following command: $ sudo snap refresh --candidate core On the classic distribution you can help testing by enabling -proposed and then installing snapd [1]. Please let us know if you experience any issues or if you have suggestions! Enjoy the new release, Michael (on behalf of the snappy team) [1] https://wiki.ubuntu.com/Testing/EnableProposed From kyle.nitzsche at canonical.com Thu Mar 9 15:26:50 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Thu, 9 Mar 2017 10:26:50 -0500 Subject: content interface, DENIED mounting $SNAP/mydir In-Reply-To: References: Message-ID: <5800981d-e655-c9df-4c10-459c1f2c3c82@canonical.com> I'd like to propose adding a way to declare in snapcraft.yaml that a folder under SNAP_COMMON (or SNAP_DATA) be created if it does not exist. Even though interface hooks (future) would seem to support this, it seems a common case so a simpler solution seems apt. The particular issue it would solve is auto connecting to a content interface mount. Currently, one needs to create the SNAP_COMMON/dir (into which the content is mounted) *before* connecting the interface, and it is hard to do that when the interface is auto-connected. Cheers, kyleN On 03/02/2017 01:33 PM, knitzsche wrote: > Hi, > > I am trying to use the wifi-ap content sharing interface. > > It is DENIED (see below) when I try to use a $SNAP directory. > > It works when I instead use $SNAP_DATA directory for the content > sharing. But, I have to create that directory at run time: I can't > figure out so far how to create (from snapcraft.yaml) an empty dir in > $SNAP_COMMON or $SNAP_DATA at install time. (Knowing this would solve my > problem.) > > To auto connect the interface (via a store snap declaration), I suppose > the directory must be present at install time. So creating the dir at > run time does not seem sufficient for the auto-connect requirement. > > Help appreciated. > > == Details when trying to use SNAP dir for content sharing: > > snapcraft.yaml snippet: > > apps: > wifi-ap: > command: bin/wifi-ap > plugs: [control, content] > > plugs: > control: > interface: content > content: socket-directory > target: $SNAP/sockets > parts: > controldir: > plugin: dump > source: . > prime: > - sockets > > I connect my snap to the interface apparently successfully: > $ sudo snap connect serv:control wifi-ap:control > > Verify connection: > $ snap interfaces | grep serv | grep "wifi-ap:" > wifi-ap:control serv > > But the bind mount was DENIED: > Mar 02 18:01:02 localhost.localdomain kernel: audit: type=1400 > audit(1488477662.292:350110): apparmor="DENIED" operation="mount" > info="failed srcname match" error=-13 > profile="/usr/lib/snapd/snap-confine" name="/snap/serv/x3/sockets/" > pid=11461 comm="snap-confine" srcname="/var/snap/wifi-ap/94/sockets/" > flags="rw, bind" > > Both wifi-ap snap and my snap seem to have the required directories: > $ ls /var/snap/wifi-ap/94/sockets/ > control > knitzsche at localhost:~$ ls /snap/serv/x3/ > bin command-run.wrapper command-scan.wrapper command-wifi-ap.wrapper > meta snap sockets > > Cheers, > kyleN > > > > From kyle.nitzsche at canonical.com Thu Mar 9 16:38:54 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Thu, 9 Mar 2017 11:38:54 -0500 Subject: Updating a gadget snap In-Reply-To: References: Message-ID: Hi, Is there a description/understanding of to expect with a time frame? This information would help Renat and others who want to be sure that products made today have an upgrade path in the field. Cheers, kyleN On 03/08/2017 05:54 AM, Ренат Галимов wrote: > Thanks, Jamie. > > The reason we need this feature is to deliver a product to out customers as > soon as possible > and then apply changes made in the rpi3 gadget snap as they become ready. > > Best regards, > Renat > > On Wed, Mar 8, 2017 at 1:06 PM, Jamie Bennett > wrote: > >> Hi Renat, >> >> We are working on making parts of the gadget snap updatable for example, on >> RPi, updating config.txt makes sense, but as you say this is a dangerous >> area to be playing with as bricking the device is possible. Michael knows >> more as he has be directly working on this lately. >> >> Regards, >> Jamie. >> >> On Wed, Mar 8, 2017 at 9:43 AM, Ренат Галимов wrote: >> >>> Hi, everyone. >>> >>> We need a way to make "snap.yaml," hooks and, possibly, other stuff of >> our >>> gadget snap updateable. >>> >>> The only way now I see is to provide a hook, which will download or get >>> files from the filesystem and replace files on the image by them, but >> such >>> a solution seem dangerous to me, because of the violation of the snaps >>> rollback idea. >>> >>> Is there anything related to the gadget snaps update planned, or, maybe, >>> somebody already resolved the issue? >>> >>> >>> Thank you, >>> Renat >>> -- >>> 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 leo.arias at canonical.com Thu Mar 9 16:49:21 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 9 Mar 2017 10:49:21 -0600 Subject: no option for unrevisioned home Message-ID: Hello! I have seen a couple of projects that would suffer by having a revisioned $HOME, mainly because they store big files in there so during an update it would be a problem if we copy ~/snap/project/x1/ to ~/snap/project/x2. Now I'm working on the bitcoin snap, and it would mean copying 110GB, so more than a problem it becomes a blocker. For $reasons, bitcoin offers no good way to store the blockchain in $SNAP_USER_COMMON. I had to patch the source code, which is a pretty ugly old-world kind of solution [1]. I think it would be really useful if we could offer an option to point $HOME to $SNAP_USER_COMMON instead of $SNAP_USER_DATA. This would leave us with unrevisioned config and data files, which is the same we have currently in all distros, so I think it will be useful for a good number of project in addition to bitcoin. What do you think? Would it make sense? [1] https://github.com/elopio/blockchain-snaps/blob/master/bitcoin/snap/snapcraft.yaml#L39 -- ¡paz y baile! http://www.ubuntu.com From renat2017 at gmail.com Thu Mar 9 17:03:55 2017 From: renat2017 at gmail.com (=?UTF-8?B?0KDQtdC90LDRgiDQk9Cw0LvQuNC80L7Qsg==?=) Date: Thu, 9 Mar 2017 20:03:55 +0300 Subject: Updating a gadget snap In-Reply-To: References: Message-ID: Hi, Also, forgot to mention that also we need a way to update the raspberry pi firmware files. Updating those files may cause the node to fail to boot. A/B system for those files is also necessary, in my opinion. Thanks, Renat On Thu, Mar 9, 2017 at 7:38 PM, knitzsche wrote: > Hi, > > Is there a description/understanding of to expect with a time frame? > > This information would help Renat and others who want to be sure that > products made today have an upgrade path in the field. > > Cheers, > kyleN > > > On 03/08/2017 05:54 AM, Ренат Галимов wrote: > >> Thanks, Jamie. >> >> The reason we need this feature is to deliver a product to out customers >> as >> soon as possible >> and then apply changes made in the rpi3 gadget snap as they become ready. >> >> Best regards, >> Renat >> >> On Wed, Mar 8, 2017 at 1:06 PM, Jamie Bennett < >> jamie.bennett at canonical.com> >> wrote: >> >> Hi Renat, >>> >>> We are working on making parts of the gadget snap updatable for example, >>> on >>> RPi, updating config.txt makes sense, but as you say this is a dangerous >>> area to be playing with as bricking the device is possible. Michael knows >>> more as he has be directly working on this lately. >>> >>> Regards, >>> Jamie. >>> >>> On Wed, Mar 8, 2017 at 9:43 AM, Ренат Галимов >>> wrote: >>> >>> Hi, everyone. >>>> >>>> We need a way to make "snap.yaml," hooks and, possibly, other stuff of >>>> >>> our >>> >>>> gadget snap updateable. >>>> >>>> The only way now I see is to provide a hook, which will download or get >>>> files from the filesystem and replace files on the image by them, but >>>> >>> such >>> >>>> a solution seem dangerous to me, because of the violation of the snaps >>>> rollback idea. >>>> >>>> Is there anything related to the gadget snaps update planned, or, maybe, >>>> somebody already resolved the issue? >>>> >>>> >>>> Thank you, >>>> Renat >>>> -- >>>> 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/mailm > an/listinfo/snapcraft > From justin.mcpherson at canonical.com Fri Mar 10 07:46:39 2017 From: justin.mcpherson at canonical.com (Justin McPherson) Date: Fri, 10 Mar 2017 17:46:39 +1000 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: On Sat, Mar 4, 2017 at 1:55 PM, Leo Arias wrote: > Hey Justin! > > On Wed, Feb 15, 2017 at 12:45 AM, Justin McPherson > wrote: > > I had a chance to take a quick look at this; see here > > > > > > The plugin works in this case, with gist. But is not good enough to be a > > general solution - no native extensions, probably need to clean up the > > paths, etc. > > > > Happy to hear comments. > > Thanks, sounds like a good start. Why don't you send it upstream to > snapcraft? We were discussing about flagging some plugins as > experimental until we had a decent user base and a good number of real > live projects building successfully. Even if this plugin only builds a > few ruby projects, it serves us to get more people and projects > interested and improving it. > > I have uploaded the changes to a fork < https://github.com/justincan/snapcraft>. The gist snapcraft.yaml is here < https://gist.github.com/justincan/81ba9d61d37e84033d4e270b4cef5ddd>. - Seems to work fine A rails snapcraft.yaml is here < https://gist.github.com/justincan/f217ae081b7da090de5dc03f19f995f5> - This is for the rails framework, not a rails app. - Need to alias bundle after install - Bundler affected by chown issue. - Need to add (+use) gcc, etc - because the included bundler will want to install gems that have native extensions In general, native extensions now seem to work. - Justin From john.lenton at canonical.com Fri Mar 10 09:22:45 2017 From: john.lenton at canonical.com (John Lenton) Date: Fri, 10 Mar 2017 09:22:45 +0000 Subject: Request for help / ideas to debug issue Message-ID: Hello! We're seeing a weird issue with either go, pthreads, or the kernel. If you're knowledgeable about one or more of those things, could you take a look? Thank you. The issue manifests as nasty warnings from the "snap run" command, which is also the first step into a snapped app or service. It looks like runtime/cgo: pthread_create failed: Resource temporarily unavailable a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/ build that, run it in a loop, and you'll see a bunch of those messages (and some weirder ones, but let's take it one step at a time). if you comment out the 'import "C"' line the message will change but still happen, which makes me think that at least in part this is a Go issue (or that we're holding it wrong). Note that the exec does work; the warning seems to come from a different thread than the one doing the Exec (the other clue that points in this direction is that sometimes the message is truncated). You can verify the fact that it does run by changing the /bin/true to /bin/echo os.Args[1], but because this issue is obviously a race somewhere, this change makes it less likely to happen (from ~10% down to ~.5% of runs, in my machines). One thing that makes this harder to debug is that strace'ing the process hangs (hard, kill -9 of strace to get out) before reproducing the issue. This probably means we need to trace it at a lower level, and I don't know enough about tracing a process group from inside the kernel to be able to do that; what I can find about kernel-level tracing is around syscalls or devices. Ideas? From sergio.schvezov at canonical.com Fri Mar 10 12:12:22 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 10 Mar 2017 12:12:22 +0000 Subject: Request for help / ideas to debug issue In-Reply-To: References: Message-ID: <6k1s9k.omllwr.1hge199-qmf@smtp.googlemail.com> On Fri, 10 Mar 2017 09:22:45 +0000, John Lenton wrote: > Hello! > > We're seeing a weird issue with either go, pthreads, or the kernel. If > you're knowledgeable about one or more of those things, could you take > a look? Thank you. > > The issue manifests as nasty warnings from the "snap run" command, > which is also the first step into a snapped app or service. It looks > like > > runtime/cgo: pthread_create failed: Resource temporarily unavailable > > a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/ > > build that, run it in a loop, and you'll see a bunch of those messages > (and some weirder ones, but let's take it one step at a time). > > if you comment out the 'import "C"' line the message will change but > still happen, which makes me think that at least in part this is a Go > issue (or that we're holding it wrong). > > Note that the exec does work; the warning seems to come from a > different thread than the one doing the Exec (the other clue that > points in this direction is that sometimes the message is truncated). > You can verify the fact that it does run by changing the /bin/true to > /bin/echo os.Args[1], but because this issue is obviously a race > somewhere, this change makes it less likely to happen (from ~10% down > to ~.5% of runs, in my machines). > > One thing that makes this harder to debug is that strace'ing the > process hangs (hard, kill -9 of strace to get out) before reproducing > the issue. This probably means we need to trace it at a lower level, > and I don't know enough about tracing a process group from inside the > kernel to be able to do that; what I can find about kernel-level > tracing is around syscalls or devices. > > Ideas? Aside from being able to reproduce what you see I have done no analysis against this but may I sugges using bcc[1] instead of strace? There's a snap for it too ;-) [1] https://github.com/iovisor/bcc -- Sent using Dekko from my Ubuntu device From jamie at canonical.com Fri Mar 10 12:20:24 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 10 Mar 2017 06:20:24 -0600 Subject: workaround for connect no autoconnect interfaces without login on system In-Reply-To: <1488897380.3377.15.camel@canonical.com> References: <1488897380.3377.15.camel@canonical.com> Message-ID: <1489148424.3377.88.camel@canonical.com> Resending since this (and a few other emails) got caught up in a filter that was recently activated for this list. On Tue, 2017-03-07 at 08:36 -0600, Jamie Strandboge wrote: > On Tue, 2017-03-07 at 09:19 -0500, knitzsche wrote: > > > > I don't think the prepare-device script can be used to auto connect,  > > probably because it runs confined. > > > > You can request the store to add an auto connection statement to the  > > snap declaration assertion. > Well, that is a technical solution but this is a big hammer since it means all > users of the snap don't have a say in the connection of the interface[1] > (things > are set to manually connect for a reason :). > > Gadget developers are supposed to have a voice in what is autoconnected on > their > devices and it seems that Nicolino is asking for advice on how to make that > happen. This comes up from time to time so once there is a definitive answer, > this sounds like a great opportunity for some documentation. :) > > [1] of course they can manually disconnect after the fact, but users need to > know to do this > > > > > > > On 03/07/2017 05:19 AM, Nicolino Curalli wrote: > > > > > > > > > Hi all, > > > I implemented hints from James but it doesn't works. > > > > > > I create a new gadget snap based on pc gadget for amd64, adding a hook > > > directory with a prepare-device hook script. > > > I make this script executable. > > > I build  an image containg my gadget (domotz-pc), pc-kernel and nmap snap > > > from store. > > > > > > The layout of my new gadget snap ( named domotz-pc )  just installed is : > > > > > > ./ > > > > > > -rwxr-xr-x 1 root root 753 Mar  7 00:04 meta/gadget.yaml > > > -rw-r--r-- 1 root root 230 Mar  7 09:11 meta/snap.yaml > > > > > > meta/gui: > > > > > > -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png > > > > > > meta/hooks: > > > > > > -rwxr-xr-x 1 root root 134 Mar  7 09:09 prepare-device > > > > > > The prepare-device script content is: > > > > > > ---------- > > > #!/bin/sh > > > > > > # enabling network-control interface slot for nmap network-control plug > > > snap connect nmap:network-control :network-control > > > ---------- > > > > > > After the registration of board by console-conf i find the following I > > > find > > > the following situation on interface side: > > > > > > :network       nmap > > > :network-bind  nmap > > > -              nmap:network-control > > > > > > instead > > > > > > :network       nmap > > > :network-bind  nmap > > > :network-control  nmap > > > > > > as I wish. > > > > > > I also  have  the following error from Apparmor: > > > > > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > DEBUG: Running task 77 on Do: Run prepare-device hook > > > Mar  7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400 > > > audit(1488853390.962:25): apparmor="DENIED" operation="exec" > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1428 > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz- > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare- > > > device: snap: Permission denied > > > Mar  7 02:28:08 localhost systemd[1]: Starting Update resolvconf for > > > networkd DNS... > > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Network configuration > > > changed, trying to establish connection. > > > Mar  7 02:28:08 localhost systemd[1]: Started Update resolvconf for > > > networkd > > > DNS. > > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time > > > server 91.189.94.4:123 (ntp.ubuntu.com). > > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > DEBUG: Running task 80 on Do: Run prepare-device hook > > > Mar  7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400 > > > audit(1488853690.938:26): apparmor="DENIED" operation="exec" > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1455 > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > 2017-03-07T02:28:10Z ERROR run hook "prepare-device": /snap/domotz- > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare- > > > device: snap: Permission denied > > > Mar  7 02:33:07 localhost systemd[1]: Starting Update resolvconf for > > > networkd DNS... > > > Mar  7 02:33:07 localhost systemd-timesyncd[795]: Network configuration > > > changed, trying to establish connection. > > > Mar  7 02:33:07 localhost systemd[1]: Started Update resolvconf for > > > networkd > > > DNS. > > > Mar  7 02:33:07 localhost systemd-timesyncd[795]: Synchronized to time > > > server 91.189.94.4:123 (ntp.ubuntu.com). > > > Mar  7 02:33:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > DEBUG: Running task 83 on Do: Run prepare-device hook > > > Mar  7 02:33:10 localhost kernel: [11351844019.491749] audit: type=1400 > > > audit(1488853990.964:27): apparmor="DENIED" operation="exec" > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1475 > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > Mar  7 02:33:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > 2017-03-07T02:33:10Z ERROR run hook "prepare-device": /snap/domotz- > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare- > > > device: snap: Permission denied > > > Mar  7 02:38:07 localhost systemd[1]: Starting Update resolvconf for > > > networkd DNS... > > > Mar  7 02:38:07 localhost systemd-timesyncd[795]: Network configuration > > > changed, trying to establish connection. > > > Mar  7 02:38:07 localhost systemd[1]: Started Update resolvconf for > > > networkd > > > DNS. > > > Mar  7 02:38:07 localhost systemd-timesyncd[795]: Synchronized to time > > > server 91.189.94.4:123 (ntp.ubuntu.com). > > > Mar  7 02:38:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > DEBUG: Running task 86 on Do: Run prepare-device hook > > > Mar  7 02:38:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > 2017-03-07T02:38:10Z ERROR run hook "prepare-device": /snap/domotz- > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz-pc/x1/meta/hooks/prepare- > > > device: snap: Permission denied > > > Mar  7 02:38:10 localhost kernel: [11351844319.456207] audit: type=1400 > > > audit(1488854290.935:28): apparmor="DENIED" operation="exec" > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" pid=1496 > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > > > > > > > It seems that is not possible exec a core apps from gadget, then what is > > > the > > > path to the solution for my use case? Perhaps I miss some important thing > > > in > > > prepare-device script? > > > > > > Thanks in advance for each hints and contribution to solve this use case. > > > > > > > > > Nicolino > > > > > > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From jamie at canonical.com Fri Mar 10 12:28:48 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 10 Mar 2017 06:28:48 -0600 Subject: workaround for connect no autoconnect interfaces without login on system In-Reply-To: <1488915698.3377.26.camel@canonical.com> References: <1488915698.3377.26.camel@canonical.com> Message-ID: <1489148928.3377.94.camel@canonical.com> On Tue, 2017-03-07 at 13:41 -0600, Jamie Strandboge wrote: > On Tue, 2017-03-07 at 15:05 +0000, Nicolino Curalli wrote: > > > > Hi kyleN > > thanks so much for the answer. > > > > A question for go ahead from my side: > > how can I request the store to add an auto connection statement to the > > snap declaration assertion ? > Just ask on this list. :) > > Looking at your previous email, it seems you would like to have the nmap snap > auto-connected. The nmap snap is requesting a lot of privilege by plugging the > 'network-control' interface and the snap is not coming from a trusted upstream > or publisher. I therefore think that it correctly requires the user to > explicitly connect the interface by default. > > Based on your previous email (and my previous response) it sounds like you are > developing a gadget snap for a particular device though. The gadget auto- > connect  > mechanism is therefore what you want to use since gadget snaps have a voice in > auto-connection. I expect someone to respond to my previous email on how you > can > do this. > The above email mistakenly was discarded by the mailing list server. Hopefully resending this now will allow the conversation to pick up again. > > > > > > Il 07/03/2017 15:20, knitzsche ha scritto: > > > > > > > > > I don't think the prepare-device script can be used to auto connect,  > > > probably because it runs confined. > > > > > > You can request the store to add an auto connection statement to the  > > > snap declaration assertion. > > > > > > Cheers > > > kyleN > > > > > > > > > On 03/07/2017 05:19 AM, Nicolino Curalli wrote: > > > > > > > > > > > > Hi all, > > > > I implemented hints from James but it doesn't works. > > > > > > > > I create a new gadget snap based on pc gadget for amd64, adding a hook > > > > directory with a prepare-device hook script. > > > > I make this script executable. > > > > I build  an image containg my gadget (domotz-pc), pc-kernel and nmap > > > > snap > > > > from store. > > > > > > > > The layout of my new gadget snap ( named domotz-pc )  just installed is > > > > : > > > > > > > > ./ > > > > > > > > -rwxr-xr-x 1 root root 753 Mar  7 00:04 meta/gadget.yaml > > > > -rw-r--r-- 1 root root 230 Mar  7 09:11 meta/snap.yaml > > > > > > > > meta/gui: > > > > > > > > -rwxr-xr-x 1 root root 39908 Nov 30 08:18 icon.png > > > > > > > > meta/hooks: > > > > > > > > -rwxr-xr-x 1 root root 134 Mar  7 09:09 prepare-device > > > > > > > > The prepare-device script content is: > > > > > > > > ---------- > > > > #!/bin/sh > > > > > > > > # enabling network-control interface slot for nmap network-control plug > > > > snap connect nmap:network-control :network-control > > > > ---------- > > > > > > > > After the registration of board by console-conf i find the following I > > > > find the following situation on interface side: > > > > > > > > :network       nmap > > > > :network-bind  nmap > > > > -              nmap:network-control > > > > > > > > instead > > > > > > > > :network       nmap > > > > :network-bind  nmap > > > > :network-control  nmap > > > > > > > > as I wish. > > > > > > > > I also  have  the following error from Apparmor: > > > > > > > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > > DEBUG: Running task 77 on Do: Run prepare-device hook > > > > Mar  7 02:23:10 localhost kernel: [11351843419.508357] audit: type=1400 > > > > audit(1488853390.962:25): apparmor="DENIED" operation="exec" > > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" > > > > pid=1428 > > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > > Mar  7 02:23:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > > 2017-03-07T02:23:10Z ERROR run hook "prepare-device": /snap/domotz- > > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz- > > > > pc/x1/meta/hooks/prepare- > > > > device: snap: Permission denied > > > > Mar  7 02:28:08 localhost systemd[1]: Starting Update resolvconf for > > > > networkd DNS... > > > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Network configuration > > > > changed, trying to establish connection. > > > > Mar  7 02:28:08 localhost systemd[1]: Started Update resolvconf for > > > > networkd DNS. > > > > Mar  7 02:28:08 localhost systemd-timesyncd[795]: Synchronized to time > > > > server 91.189.94.4:123 (ntp.ubuntu.com). > > > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > > DEBUG: Running task 80 on Do: Run prepare-device hook > > > > Mar  7 02:28:10 localhost kernel: [11351843719.476882] audit: type=1400 > > > > audit(1488853690.938:26): apparmor="DENIED" operation="exec" > > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" > > > > pid=1455 > > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > > Mar  7 02:28:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > > 2017-03-07T02:28:10Z ERROR run hook "prepare-device": /snap/domotz- > > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz- > > > > pc/x1/meta/hooks/prepare- > > > > device: snap: Permission denied > > > > Mar  7 02:33:07 localhost systemd[1]: Starting Update resolvconf for > > > > networkd DNS... > > > > Mar  7 02:33:07 localhost systemd-timesyncd[795]: Network configuration > > > > changed, trying to establish connection. > > > > Mar  7 02:33:07 localhost systemd[1]: Started Update resolvconf for > > > > networkd DNS. > > > > Mar  7 02:33:07 localhost systemd-timesyncd[795]: Synchronized to time > > > > server 91.189.94.4:123 (ntp.ubuntu.com). > > > > Mar  7 02:33:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > > DEBUG: Running task 83 on Do: Run prepare-device hook > > > > Mar  7 02:33:10 localhost kernel: [11351844019.491749] audit: type=1400 > > > > audit(1488853990.964:27): apparmor="DENIED" operation="exec" > > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" > > > > pid=1475 > > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > > Mar  7 02:33:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > > 2017-03-07T02:33:10Z ERROR run hook "prepare-device": /snap/domotz- > > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz- > > > > pc/x1/meta/hooks/prepare- > > > > device: snap: Permission denied > > > > Mar  7 02:38:07 localhost systemd[1]: Starting Update resolvconf for > > > > networkd DNS... > > > > Mar  7 02:38:07 localhost systemd-timesyncd[795]: Network configuration > > > > changed, trying to establish connection. > > > > Mar  7 02:38:07 localhost systemd[1]: Started Update resolvconf for > > > > networkd DNS. > > > > Mar  7 02:38:07 localhost systemd-timesyncd[795]: Synchronized to time > > > > server 91.189.94.4:123 (ntp.ubuntu.com). > > > > Mar  7 02:38:10 localhost /usr/lib/snapd/snapd[936]: taskrunner.go:353: > > > > DEBUG: Running task 86 on Do: Run prepare-device hook > > > > Mar  7 02:38:10 localhost /usr/lib/snapd/snapd[936]: task.go:303: DEBUG: > > > > 2017-03-07T02:38:10Z ERROR run hook "prepare-device": /snap/domotz- > > > > pc/x1/meta/hooks/prepare-device: 4: /snap/domotz- > > > > pc/x1/meta/hooks/prepare- > > > > device: snap: Permission denied > > > > Mar  7 02:38:10 localhost kernel: [11351844319.456207] audit: type=1400 > > > > audit(1488854290.935:28): apparmor="DENIED" operation="exec" > > > > profile="snap.domotz-pc.hook.prepare-device" name="/usr/bin/snap" > > > > pid=1496 > > > > comm="prepare-device" requested_mask="x" denied_mask="x" fsuid=0 ouid=0 > > > > > > > > > > > > It seems that is not possible exec a core apps from gadget, then what is > > > > the path to the solution for my use case? Perhaps I miss some important > > > > thing in prepare-device script? > > > > > > > > Thanks in advance for each hints and contribution to solve this use > > > > case. > > > > > > > > > > > > Nicolino > > > > > > > > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.nitzsche at canonical.com Fri Mar 10 12:57:58 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Fri, 10 Mar 2017 07:57:58 -0500 Subject: workaround for connect no autoconnect interfaces without login on system In-Reply-To: <1489148424.3377.88.camel@canonical.com> References: <1488897380.3377.15.camel@canonical.com> <1489148424.3377.88.camel@canonical.com> Message-ID: <2fdf1cd5-f0b3-1eb4-ce86-2450d1155c61@canonical.com> Hi Jamie On 03/10/2017 07:20 AM, Jamie Strandboge wrote: > Gadget developers are supposed to have a voice in what is autoconnected on > their > devices and it seems that Nicolino is asking for advice on how to make that > happen. This comes up from time to time so once there is a definitive answer, > this sounds like a great opportunity for some documentation. :) Do you, or does anyone, know how to auto connect from a gadget snap? Cheers, Kyle From alfonso.sanchez-beato at canonical.com Fri Mar 10 13:58:22 2017 From: alfonso.sanchez-beato at canonical.com (Alfonso Sanchez-Beato) Date: Fri, 10 Mar 2017 14:58:22 +0100 Subject: Request for help / ideas to debug issue In-Reply-To: References: Message-ID: On Fri, Mar 10, 2017 at 10:22 AM, John Lenton wrote: > Hello! > > We're seeing a weird issue with either go, pthreads, or the kernel. If > you're knowledgeable about one or more of those things, could you take > a look? Thank you. > > The issue manifests as nasty warnings from the "snap run" command, > which is also the first step into a snapped app or service. It looks > like > > runtime/cgo: pthread_create failed: Resource temporarily unavailable > > a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/ > > build that, run it in a loop, and you'll see a bunch of those messages > (and some weirder ones, but let's take it one step at a time). > > if you comment out the 'import "C"' line the message will change but > still happen, which makes me think that at least in part this is a Go > issue (or that we're holding it wrong). > > Note that the exec does work; the warning seems to come from a > different thread than the one doing the Exec (the other clue that > points in this direction is that sometimes the message is truncated). > You can verify the fact that it does run by changing the /bin/true to > /bin/echo os.Args[1], but because this issue is obviously a race > somewhere, this change makes it less likely to happen (from ~10% down > to ~.5% of runs, in my machines). > > One thing that makes this harder to debug is that strace'ing the > process hangs (hard, kill -9 of strace to get out) before reproducing > the issue. This probably means we need to trace it at a lower level, > and I don't know enough about tracing a process group from inside the > kernel to be able to do that; what I can find about kernel-level > tracing is around syscalls or devices. > > Ideas? > I found this related thread: https://groups.google.com/forum/#!msg/golang-nuts/8gszDBRZh_4/lhROTfN9TxIJ << I believe this can happen on GNU/Linux if your program uses cgo and if thread A is in the Go runtime starting up a new thread B while thread C is execing a program. The underlying cause is that while one thread is calling exec the Linux kernel will fail attempts by other threads to call clone by returning EAGAIN. (Look for uses of the in_exec field in the kernel sources.) >> Something like adding a little sleep removes the traces, for instance: http://paste.ubuntu.com/24151637/ where the program run sleep for 1ms before calling Exec. For smaller units (say, 20 us) the issue still happens. It looks to me that right before running main(), go creates some threads, calling clone() and probably getting the race described in the thread. As anyway you are running Exec I guess the traces are harmless, you do not need the go threads. Nonetheless, I think that the go run time should retry instead of printing that trace. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From barry at ubuntu.com Fri Mar 10 15:14:04 2017 From: barry at ubuntu.com (Barry Warsaw) Date: Fri, 10 Mar 2017 10:14:04 -0500 Subject: Class confinement for Python snaps Message-ID: <20170308180005.05e4efb1@subdivisions.wooz.org> I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm running into some problems. ubuntu-image is a Python 3 application, and I'm using snapcraft 2.27.1+17.4 on Zesty. The first problem I'm having is I think directly related to LP: #1670749. I ended up reopening this because while Corey found that he ultimately only needed to set the $PATH environment variable, I still also had to $PYTHONPATH and I had to make sure the snap versions come before the system versions: environment: PATH: $SNAP/bin/:$PATH PYTHONPATH: $SNAP/lib/python3.5/site-packages:$PYTHONPATH This gets me pretty close, but then I run into my second problem which is that we depend on pyparted, in Ubuntu as python3-pyparted. This package contains both Python source and an extension module and to further complicate things, its tarball is only released on GitHub, not on PyPI, so adding it to python-packages in the ubuntu-image part doesn't work. Further, it doesn't help to add python3-parted to stage-packages because it appears that with classic confinement, none of those Python packages end up in the snap. I tried to add a scriptlet to copy things over, but that also fails. E.g.: parts: ubuntu-image: plugin: python source: https://github.com/CanonicalLtd/ubuntu-image.git source-type: git python-packages: - PyYAML - attrs - voluptuous prime: - bin/ubuntu-image - usr - lib - sbin stage-packages: - e2fsprogs - mtools - python3-debian - python3-parted - util-linux install: | cp -a ../install/usr/lib/python3/dist-packages/parted ../stage/lib/python3.5/site-packages cp -a ../install/usr/lib/python3/dist-packages/pyparted-*.egg-info ../stage/lib/python3.5/site-packages $ snapcraft ... /home/barry/projects/ubuntu/allsnappy/ubuntu-image/parts/ubuntu-image/build cp: cannot create directory '../stage/lib/python3.5/site-packages': No such file or directory cp: cannot create regular file '../stage/lib/python3.5/site-packages': No such file or directory Command '['/bin/sh', '/tmp/tmpfeczxcco', '/tmp/tmp2__1bdau']' returned non-zero exit status 1 This happens because ./stage/ is empty at the point that the install scriptlet is run. I can think of a couple of approaches that might be useful. * Allow python-packages specifications to pip install from repositories other than PyPI. * Allow python-packages to come from git and/or https URLs (I tried this and it didn't work). * Integrate dirtbike and wheels into the Python parts building phases. (dirtbike is a tool that Debian/Ubuntu uses in very limited cases to turn installed distro packages into .whl files.) * Provide a scriptlet hook that runs after the normal part installation step. My current WIP snapcraft.yaml file is here: https://github.com/CanonicalLtd/ubuntu-image/blob/lp1638645/snapcraft.yaml I'm going to keep trying a few things, but any suggestions are welcome. I'm happy to file bugs as needed. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From didier.roche at canonical.com Fri Mar 10 15:52:08 2017 From: didier.roche at canonical.com (Didier Roche) Date: Fri, 10 Mar 2017 16:52:08 +0100 Subject: Class confinement for Python snaps In-Reply-To: <20170308180005.05e4efb1@subdivisions.wooz.org> References: <20170308180005.05e4efb1@subdivisions.wooz.org> Message-ID: Le 10/03/2017 à 16:14, Barry Warsaw a écrit : > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm > running into some problems. ubuntu-image is a Python 3 application, and I'm > using snapcraft 2.27.1+17.4 on Zesty. > > The first problem I'm having is I think directly related to LP: #1670749. Hey Barry, Note as well that I opened https://bugs.launchpad.net/snapcraft/+bug/1670388 against the snapcraft project a couple of days ago. I think snapcraft should at least fail the build to warn you about this. Cheers, Didier > I > ended up reopening this because while Corey found that he ultimately only > needed to set the $PATH environment variable, I still also had to $PYTHONPATH > and I had to make sure the snap versions come before the system versions: > > environment: > PATH: $SNAP/bin/:$PATH > PYTHONPATH: $SNAP/lib/python3.5/site-packages:$PYTHONPATH > > This gets me pretty close, but then I run into my second problem which is that > we depend on pyparted, in Ubuntu as python3-pyparted. This package contains > both Python source and an extension module and to further complicate things, > its tarball is only released on GitHub, not on PyPI, so adding it to > python-packages in the ubuntu-image part doesn't work. Further, it doesn't > help to add python3-parted to stage-packages because it appears that with > classic confinement, none of those Python packages end up in the snap. > > I tried to add a scriptlet to copy things over, but that also fails. E.g.: > > parts: > ubuntu-image: > plugin: python > source: https://github.com/CanonicalLtd/ubuntu-image.git > source-type: git > python-packages: > - PyYAML > - attrs > - voluptuous > prime: > - bin/ubuntu-image > - usr > - lib > - sbin > stage-packages: > - e2fsprogs > - mtools > - python3-debian > - python3-parted > - util-linux > install: | > cp -a ../install/usr/lib/python3/dist-packages/parted ../stage/lib/python3.5/site-packages > cp -a ../install/usr/lib/python3/dist-packages/pyparted-*.egg-info ../stage/lib/python3.5/site-packages > > $ snapcraft > ... > /home/barry/projects/ubuntu/allsnappy/ubuntu-image/parts/ubuntu-image/build > cp: cannot create directory '../stage/lib/python3.5/site-packages': No such file or directory > cp: cannot create regular file '../stage/lib/python3.5/site-packages': No such file or directory > Command '['/bin/sh', '/tmp/tmpfeczxcco', '/tmp/tmp2__1bdau']' returned non-zero exit status 1 > > This happens because ./stage/ is empty at the point that the install scriptlet > is run. > > I can think of a couple of approaches that might be useful. > > * Allow python-packages specifications to pip install from repositories other > than PyPI. > > * Allow python-packages to come from git and/or https URLs (I tried this and > it didn't work). > > * Integrate dirtbike and wheels into the Python parts building phases. > (dirtbike is a tool that Debian/Ubuntu uses in very limited cases to turn > installed distro packages into .whl files.) > > * Provide a scriptlet hook that runs after the normal part installation step. > > My current WIP snapcraft.yaml file is here: > > https://github.com/CanonicalLtd/ubuntu-image/blob/lp1638645/snapcraft.yaml > > I'm going to keep trying a few things, but any suggestions are welcome. I'm > happy to file bugs as needed. > > Cheers, > -Barry > > From sergio.schvezov at canonical.com Fri Mar 10 16:02:54 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 10 Mar 2017 16:02:54 +0000 Subject: Class confinement for Python snaps In-Reply-To: <20170308180005.05e4efb1@subdivisions.wooz.org> References: <20170308180005.05e4efb1@subdivisions.wooz.org> Message-ID: On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote: > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm > running into some problems. ubuntu-image is a Python 3 application, and I'm > using snapcraft 2.27.1+17.4 on Zesty. Any reaosn you are moving from devmode to classic? The progression should be classic->devmode->strict It is however unfortunate that classic confined snaps can make it to the stable channel while devmode ones cannot, maybe we need an alias for devmode (which would be as secure as classic confinment but with the common root as root) as in some cases it is an improvement over classic (not needing to deal with libraries and installable on Ubuntu Core). -- Sent using Dekko from my Ubuntu device From barry at ubuntu.com Fri Mar 10 16:17:58 2017 From: barry at ubuntu.com (Barry Warsaw) Date: Fri, 10 Mar 2017 11:17:58 -0500 Subject: Class confinement for Python snaps In-Reply-To: References: <20170308180005.05e4efb1@subdivisions.wooz.org> Message-ID: <20170310111758.4c905837@subdivisions.wooz.org> On Mar 10, 2017, at 04:02 PM, Sergio Schvezov wrote: >Any reaosn you are moving from devmode to classic? The progression should be >classic->devmode->strict A couple of reasons. Probably the most problematic one is that /tmp inside the snap is not the same as /tmp outside the snap, and we have a bunch of crufty workarounds to fail early (when possible) if those directories are used to communicate information across the boundaries. ubuntu-image builds core images. People like to put their extra snaps, or their models in /tmp, or write the resulting images to /tmp. All of that works with the u-i deb but doesn't work with the u-i snap. I *think* we've identified most of the places where this happens, so we can issue an error and exit, but it's an unfortunate asymmetry between the snap and the deb. (And I'm not 100% sure we've identified all the cases; and it makes the code more complicated, etc.) >It is however unfortunate that classic confined snaps can make it to the >stable channel while devmode ones cannot That's another limitation I was hoping to eliminate with the switch to classic. Currently we use edge as our "beta" release channel, then we do any manual QA against that, and promote to beta for our blessed release. I'd love to be able to push the blessed version to stable, since it's way more discoverable. >, maybe we need an alias for devmode (which would be as secure as classic >confinment but with the common root as root) as in some cases it is an >improvement over classic (not needing to deal with libraries and installable >on Ubuntu Core). Isn't classic supposed to be a more or less replacement for traditional debs? I probably misunderstand its purpose but our thinking was that we could bundle it up as a classic snap as a possible, eventual, replacement for SRUing the debs back to X and Y (and soon, Z also). I didn't realize that classic is viewed as the first stepping stone to strict confinement. Cheers, -Barry From barry at ubuntu.com Fri Mar 10 16:22:04 2017 From: barry at ubuntu.com (Barry Warsaw) Date: Fri, 10 Mar 2017 11:22:04 -0500 Subject: Class confinement for Python snaps In-Reply-To: References: <20170308180005.05e4efb1@subdivisions.wooz.org> Message-ID: <20170310112204.3a37ad22@subdivisions.wooz.org> On Mar 10, 2017, at 04:52 PM, Didier Roche wrote: >Note as well that I opened https://bugs.launchpad.net/snapcraft/+bug/1670388 >against the snapcraft project a couple of days ago. I think snapcraft should >at least fail the build to warn you about this. Thanks, subscribed! -Barry From jamie at canonical.com Fri Mar 10 16:44:06 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 10 Mar 2017 10:44:06 -0600 Subject: Class confinement for Python snaps In-Reply-To: References: <20170308180005.05e4efb1@subdivisions.wooz.org> Message-ID: <1489164246.19528.1.camel@canonical.com> On Fri, 2017-03-10 at 16:02 +0000, Sergio Schvezov wrote: > On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote: > > > > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm > > running into some problems.  ubuntu-image is a Python 3 application, and I'm > > using snapcraft 2.27.1+17.4 on Zesty. > Any reaosn you are moving from devmode to classic? The progression should be > classic->devmode->strict > > It is however unfortunate that classic confined snaps can make it to the > stable channel while devmode ones cannot, maybe we need an alias for devmode > (which would be as secure as classic confinment but with the common root as > root) as in some cases it is an improvement over classic (not needing to deal > with libraries and installable on Ubuntu Core). While classic can make it to stable, do note that use of classic requires human review where devmode does not. -- 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.stokes at canonical.com Fri Mar 10 18:13:48 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Fri, 10 Mar 2017 18:13:48 +0000 Subject: kpi dashboard available? Message-ID: Is there an available kpi dashboard I can take a look at? I'm interested to see where conjure-up sits in the snap statistics. Thanks Adam From steve.langasek at canonical.com Fri Mar 10 18:35:39 2017 From: steve.langasek at canonical.com (Steve Langasek) Date: Fri, 10 Mar 2017 10:35:39 -0800 Subject: Class confinement for Python snaps In-Reply-To: References: <20170308180005.05e4efb1@subdivisions.wooz.org> Message-ID: <20170310183539.taecix6qvxejvud4@virgil.dodds.net> On Fri, Mar 10, 2017 at 04:02:54PM +0000, Sergio Schvezov wrote: > On Fri, 10 Mar 2017 10:14:04 -0500, Barry Warsaw wrote: > > I'm converting ubuntu-image from a devmode snap to a classic snap, but I'm > > running into some problems. ubuntu-image is a Python 3 application, and I'm > > using snapcraft 2.27.1+17.4 on Zesty. > Any reaosn you are moving from devmode to classic? The progression should > be classic->devmode->strict ubuntu-image is a commandline tool that operates on arbitrary files on the filesystem at the user's instruction. This seems to be in the wheelhouse for classic snaps - and certainly, the /tmp issue is very confusing for users and AFAICS isn't truly solvable outside of classic mode. Given this, I don't see any reason we would want to move ubuntu-image from classic to strict mode. Do you disagree? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek at ubuntu.com vorlon at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From evan.dandrea at canonical.com Fri Mar 10 20:17:22 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Fri, 10 Mar 2017 20:17:22 +0000 Subject: kpi dashboard available? In-Reply-To: References: Message-ID: On Fri, 10 Mar 2017 at 10:14 Adam Stokes wrote: Is there an available kpi dashboard I can take a look at? I'm interested to see where conjure-up sits in the snap statistics. Hi Adam, Your best bet today is the Stats page on https://myapps.developer.ubuntu.com/, but we're working to provide a much richer set of metrics going forward. For example, you'll be able to see unique active installs broken down by channel, architecture, and revision. From joseph.wakeling at webdrake.net Fri Mar 10 22:01:58 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 10 Mar 2017 23:01:58 +0100 Subject: Further ABI-related issues for ldc2 snap on 14.04 ... ? In-Reply-To: References: Message-ID: On 05/03/17 14:10, Sergio Schvezov wrote: > I think you have come to a cross roads where you will need to choose to either > always use the linker from the core snap and link to things from your snap or > provide multiple zlib targets for different versions of glibc (or any other > library you want to link with and provide it in your snap). > > If you are going to have things like > /snap/core/current/lib/x86_64-linux-gnu/libpthread.so.0 you would certainly want > to use the linker in core. If you are going to use /usr/bin/gcc you probably > shouldn't include libraries from `/snap/...`. > > I am sorry that I cannot help you more without deep diving into your project. First off, no need for apologies. This is obviously quite an esoteric issue, and I shared it more with the thought that it might be interesting than with any expectation that anyone would be able to help. You've already been super generous with your time and support! I'm not sure I follow what you mean by "use the linker from the core snap". AFAICS the core snap doesn't contain ld or gcc or any toolchain ... ? If you mean when building the contents of the snap, I'm just doing a regular `snapcraft cleanbuild`, no special magic to select particular gcc or binutils versions. From michael.hudson at canonical.com Sun Mar 12 08:37:38 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Sun, 12 Mar 2017 21:37:38 +1300 Subject: Request for help / ideas to debug issue In-Reply-To: References: Message-ID: Before we get into this, what is the actual problem here? Just the ugly messages? On 11 March 2017 at 02:58, Alfonso Sanchez-Beato < alfonso.sanchez-beato at canonical.com> wrote: > On Fri, Mar 10, 2017 at 10:22 AM, John Lenton > wrote: > > > Hello! > > > > We're seeing a weird issue with either go, pthreads, or the kernel. If > > you're knowledgeable about one or more of those things, could you take > > a look? Thank you. > > > > The issue manifests as nasty warnings from the "snap run" command, > > which is also the first step into a snapped app or service. It looks > > like > > > > runtime/cgo: pthread_create failed: Resource temporarily unavailable > > > > a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/ > > > > build that, run it in a loop, and you'll see a bunch of those messages > > (and some weirder ones, but let's take it one step at a time) > Turns out this was fixed in Go 1.8: https://go-review.googlesource.com/c/33894/ > > if you comment out the 'import "C"' line the message will change but > > still happen, which makes me think that at least in part this is a Go > > issue (or that we're holding it wrong). > ... but only in the non-cgo case, you can (occasionally) still get messages like: runtime: failed to create new OS thread (have 5 already; errno=11) runtime: may need to increase max user processes (ulimit -u) fatal error: newosproc if you comment out the import "C". I guess we should report that upstream. > > Note that the exec does work; the warning seems to come from a > > different thread than the one doing the Exec (the other clue that > > points in this direction is that sometimes the message is truncated). > > You can verify the fact that it does run by changing the /bin/true to > > /bin/echo os.Args[1], but because this issue is obviously a race > > somewhere, this change makes it less likely to happen (from ~10% down > > to ~.5% of runs, in my machines). > > > > One thing that makes this harder to debug is that strace'ing the > > process hangs (hard, kill -9 of strace to get out) before reproducing > > the issue. This probably means we need to trace it at a lower level, > > and I don't know enough about tracing a process group from inside the > > kernel to be able to do that; what I can find about kernel-level > > tracing is around syscalls or devices. > > > > Ideas? > > > > I found this related thread: > > https://groups.google.com/forum/#!msg/golang-nuts/8gszDBRZh_4/lhROTfN9TxIJ > > << > I believe this can happen on GNU/Linux if your program uses cgo and if > thread A is in the Go runtime starting up a new thread B while thread > C is execing a program. The underlying cause is that while one thread > is calling exec the Linux kernel will fail attempts by other threads > to call clone by returning EAGAIN. (Look for uses of the in_exec > field in the kernel sources.) > >> > Yeah, this seems to be very accurate. It's also why it seems this is a cosmetic problem only, some thread not calling exec fails, but well, the thread is about to die anyway. > Something like adding a little sleep removes the traces, for instance: > > http://paste.ubuntu.com/24151637/ > > where the program run sleep for 1ms before calling Exec. For smaller units > (say, 20 us) the issue still happens. > > It looks to me that right before running main(), go creates some threads, > calling clone() and probably getting the race described in the thread. As > anyway you are running Exec I guess the traces are harmless, you do not > need the go threads. Nonetheless, I think that the go run time should retry > instead of printing that trace. Cheers, mwh From michael.hudson at canonical.com Sun Mar 12 08:38:25 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Sun, 12 Mar 2017 21:38:25 +1300 Subject: Request for help / ideas to debug issue In-Reply-To: References: Message-ID: PS: I guess I should back port that Go fix to all supported Go releases? On 12 March 2017 at 21:37, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > Before we get into this, what is the actual problem here? Just the ugly > messages? > > On 11 March 2017 at 02:58, Alfonso Sanchez-Beato canonical.com> wrote: > >> On Fri, Mar 10, 2017 at 10:22 AM, John Lenton >> wrote: >> >> > Hello! >> > >> > We're seeing a weird issue with either go, pthreads, or the kernel. If >> > you're knowledgeable about one or more of those things, could you take >> > a look? Thank you. >> > >> > The issue manifests as nasty warnings from the "snap run" command, >> > which is also the first step into a snapped app or service. It looks >> > like >> > >> > runtime/cgo: pthread_create failed: Resource temporarily unavailable >> > >> > a very stripped-down reproducer is http://pastebin.ubuntu.com/24150663/ >> > >> > build that, run it in a loop, and you'll see a bunch of those messages >> > (and some weirder ones, but let's take it one step at a time) >> > > Turns out this was fixed in Go 1.8: https://go-review. > googlesource.com/c/33894/ > > >> > if you comment out the 'import "C"' line the message will change but >> > still happen, which makes me think that at least in part this is a Go >> > issue (or that we're holding it wrong). >> > > ... but only in the non-cgo case, you can (occasionally) still get > messages like: > > runtime: failed to create new OS thread (have 5 already; errno=11) > runtime: may need to increase max user processes (ulimit -u) > fatal error: newosproc > > if you comment out the import "C". I guess we should report that upstream. > > >> > Note that the exec does work; the warning seems to come from a >> > different thread than the one doing the Exec (the other clue that >> > points in this direction is that sometimes the message is truncated). >> > You can verify the fact that it does run by changing the /bin/true to >> > /bin/echo os.Args[1], but because this issue is obviously a race >> > somewhere, this change makes it less likely to happen (from ~10% down >> > to ~.5% of runs, in my machines). >> > >> > One thing that makes this harder to debug is that strace'ing the >> > process hangs (hard, kill -9 of strace to get out) before reproducing >> > the issue. This probably means we need to trace it at a lower level, >> > and I don't know enough about tracing a process group from inside the >> > kernel to be able to do that; what I can find about kernel-level >> > tracing is around syscalls or devices. >> > >> > Ideas? >> > >> >> I found this related thread: >> >> https://groups.google.com/forum/#!msg/golang-nuts/8gszDBRZh_ >> 4/lhROTfN9TxIJ >> >> << >> I believe this can happen on GNU/Linux if your program uses cgo and if >> thread A is in the Go runtime starting up a new thread B while thread >> C is execing a program. The underlying cause is that while one thread >> is calling exec the Linux kernel will fail attempts by other threads >> to call clone by returning EAGAIN. (Look for uses of the in_exec >> field in the kernel sources.) >> >> >> > > Yeah, this seems to be very accurate. It's also why it seems this is a > cosmetic problem only, some thread not calling exec fails, but well, the > thread is about to die anyway. > > >> Something like adding a little sleep removes the traces, for instance: >> >> http://paste.ubuntu.com/24151637/ >> >> where the program run sleep for 1ms before calling Exec. For smaller units >> (say, 20 us) the issue still happens. >> >> It looks to me that right before running main(), go creates some threads, >> calling clone() and probably getting the race described in the thread. As >> anyway you are running Exec I guess the traces are harmless, you do not >> need the go threads. Nonetheless, I think that the go run time should >> retry >> instead of printing that trace. > > > Cheers, > mwh > From joseph.wakeling at webdrake.net Sun Mar 12 17:15:21 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 12 Mar 2017 18:15:21 +0100 Subject: Removing an unreleased package revision Message-ID: Hello folks, Is there a mechanism for removing an unreleased package revision from the store? I'd like to get rid of revision 7 of the ldc2 snap, which has some issues on 16.10 that make it unsuitable for release (even to the Edge channel). Thanks & best wishes, -- Joe From jin.hsieh at canonical.com Mon Mar 13 08:29:20 2017 From: jin.hsieh at canonical.com (Jin Hsieh) Date: Mon, 13 Mar 2017 16:29:20 +0800 Subject: To get the environment variables in snapping Message-ID: Hello guys, We are making a workable mail solution snap, the selected back-end services are Postfix(SMTP) and Dovecot(POP3/IMAP). For those services as you known they have some dependencies with classic paths, for example the /etc/postfix/main.cf and /etc/dovecot/dovecot.conf so we made some changes on the upstream code, to get the environment variables such as SNAP, SNAP_DATA/SNAP_COMMON by getenv(), then replace the classic one into $SNAP_DATA/etc/postfix/* to make it works properly. Also, for a bigger snap like this, the component(one of the parts) will execute external command to trigger another one, in such the case Postfix forks its child process: pipe to call dovecot-lda (which is a sub-process of Dovecot), to complete the mail retrieving function, now I would say *it is lucky to have a useful configuration parameter* "export_environment" in Postfix, so that we can make sure the commands could be executed correctly in our snap world with specific $SNAP exported. http://www.postfix.org/postconf.5.html But you could recognize the modification we made *is hard to upstream guys to accept/merge the changes into their trunk*, so many getenv("SNAP") in the code or in where the code flow uses clean_env() we also need to cache the SNAP-related variables, I am wondering if we have a better way to do this, for example an interface or environment-sharing could make the life easier? 1. then have the chances to make the upstream code up without getenv("SNAP") to make their code snap-adaptive 2. then have a much regular way to export environment when one component calls another one externally without "export_environment" support Any feedback would be welcomed, many thanks. BR. Jin From john.lenton at canonical.com Mon Mar 13 10:11:51 2017 From: john.lenton at canonical.com (John Lenton) Date: Mon, 13 Mar 2017 10:11:51 +0000 Subject: Request for help / ideas to debug issue In-Reply-To: References: Message-ID: Thank you Alfonso for that link (I didn't find that when I looked, so kudos), and thank you Michael and Zyga for all your work on this! On 12 March 2017 at 08:38, Michael Hudson-Doyle wrote: > PS: I guess I should back port that Go fix to all supported Go releases? that would be very nice. Does that include trusty? And how far can it reach in Debian? Zyga, what are our chances of patching Go on other distros? Michael, WRT the non-cgo case, can you report it upstream? Would you rather I did? I'm off to try to find a reproducer for the "oops i lost the suid bit" bug :-D From john.lenton at canonical.com Mon Mar 13 12:59:32 2017 From: john.lenton at canonical.com (John Lenton) Date: Mon, 13 Mar 2017 12:59:32 +0000 Subject: Part 2! Request for help / ideas to debug issue Message-ID: This one is slightly more interesting. You need 1.8 (or patched <1.8 as per the previous thread) for this one to make sense; without it you're just going to get drowned in warning messages and not see the real issue. This one is the real issue :-) In go, when calling syscall.Exec to a setuid root binary, sometimes (about 4% of the times, on my machine, but it's hardware- and load-dependent), the exec'ed process will find itself running with effective uid different to zero. That is, a setuid root binary will find itself running as non-root. As the process that sets up confinement is setuid root (in distros where setuid is favoured over capabilities), this means the snap app falls on its face. TODO: check if something similar happens when using caps This is *probably* a bug in Go, but it only seems to arise when using syscall.Exec, which as far as I can tell is unsupported (the whole syscall package is unsupported -- not covered by the go1 compatibility promise -- and its replacement, golang.org/x/sys/unix, is ominously missing Exec). Having said that, it might be a bug in the kernel ;-) And I say this because if you pin the process to a single cpu, the issue doesn't arise. Anyway, code to repro this is at https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 on my machine, $ for i in `seq -w 9999`; do ./a_c; done | wc -l 0 $ for i in `seq -w 9999`; do ./a_go; done | wc -l 394 And, $ for i in `seq -w 9999`; do taskset 2 ./a_go; done | wc -l 0 Gnarly! From gustavo.niemeyer at canonical.com Mon Mar 13 13:35:10 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 13 Mar 2017 10:35:10 -0300 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: Thanks for finding and debugging this John. I can't see how this one would be in Go. I can't think of any related action that would disable the setuid bit on the exec syscall. Perhaps someone from the kernel team can help here? On Mon, Mar 13, 2017 at 9:59 AM, John Lenton wrote: > This one is slightly more interesting. > > You need 1.8 (or patched <1.8 as per the previous thread) for this one > to make sense; without it you're just going to get drowned in warning > messages and not see the real issue. > > This one is the real issue :-) > > In go, when calling syscall.Exec to a setuid root binary, sometimes > (about 4% of the times, on my machine, but it's hardware- and > load-dependent), the exec'ed process will find itself running with > effective uid different to zero. That is, a setuid root binary will > find itself running as non-root. As the process that sets up > confinement is setuid root (in distros where setuid is favoured over > capabilities), this means the snap app falls on its face. > > TODO: check if something similar happens when using caps > > This is *probably* a bug in Go, but it only seems to arise when using > syscall.Exec, which as far as I can tell is unsupported (the whole > syscall package is unsupported -- not covered by the go1 compatibility > promise -- and its replacement, golang.org/x/sys/unix, is ominously > missing Exec). > > Having said that, it might be a bug in the kernel ;-) > And I say this because if you pin the process to a single cpu, the > issue doesn't arise. > > Anyway, code to repro this is at > https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 > > on my machine, > > $ for i in `seq -w 9999`; do ./a_c; done | wc -l > 0 > $ for i in `seq -w 9999`; do ./a_go; done | wc -l > 394 > > And, > > $ for i in `seq -w 9999`; do taskset 2 ./a_go; done | wc -l > 0 > > Gnarly! > > -- > 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 gustavo.niemeyer at canonical.com Mon Mar 13 13:53:09 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 13 Mar 2017 10:53:09 -0300 Subject: Request for help / ideas to debug issue In-Reply-To: References: Message-ID: Thanks for your help on this, Michael. Yes, the fix seems pretty simple and porting to older Go releases will ensure people are not getting those super awkward messages randomly. I have created a Trello card with a checklist so we can track all the distributions that we need to fix, and included you, John, and Zygmunt. On Sun, Mar 12, 2017 at 5:38 AM, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > PS: I guess I should back port that Go fix to all supported Go releases? > > On 12 March 2017 at 21:37, Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: > > > Before we get into this, what is the actual problem here? Just the ugly > > messages? > > > > On 11 March 2017 at 02:58, Alfonso Sanchez-Beato > canonical.com> wrote: > > > >> On Fri, Mar 10, 2017 at 10:22 AM, John Lenton < > john.lenton at canonical.com> > >> wrote: > >> > >> > Hello! > >> > > >> > We're seeing a weird issue with either go, pthreads, or the kernel. If > >> > you're knowledgeable about one or more of those things, could you take > >> > a look? Thank you. > >> > > >> > The issue manifests as nasty warnings from the "snap run" command, > >> > which is also the first step into a snapped app or service. It looks > >> > like > >> > > >> > runtime/cgo: pthread_create failed: Resource temporarily unavailable > >> > > >> > a very stripped-down reproducer is http://pastebin.ubuntu.com/ > 24150663/ > >> > > >> > build that, run it in a loop, and you'll see a bunch of those messages > >> > (and some weirder ones, but let's take it one step at a time) > >> > > > > Turns out this was fixed in Go 1.8: https://go-review. > > googlesource.com/c/33894/ > > > > > >> > if you comment out the 'import "C"' line the message will change but > >> > still happen, which makes me think that at least in part this is a Go > >> > issue (or that we're holding it wrong). > >> > > > > ... but only in the non-cgo case, you can (occasionally) still get > > messages like: > > > > runtime: failed to create new OS thread (have 5 already; errno=11) > > runtime: may need to increase max user processes (ulimit -u) > > fatal error: newosproc > > > > if you comment out the import "C". I guess we should report that > upstream. > > > > > >> > Note that the exec does work; the warning seems to come from a > >> > different thread than the one doing the Exec (the other clue that > >> > points in this direction is that sometimes the message is truncated). > >> > You can verify the fact that it does run by changing the /bin/true to > >> > /bin/echo os.Args[1], but because this issue is obviously a race > >> > somewhere, this change makes it less likely to happen (from ~10% down > >> > to ~.5% of runs, in my machines). > >> > > >> > One thing that makes this harder to debug is that strace'ing the > >> > process hangs (hard, kill -9 of strace to get out) before reproducing > >> > the issue. This probably means we need to trace it at a lower level, > >> > and I don't know enough about tracing a process group from inside the > >> > kernel to be able to do that; what I can find about kernel-level > >> > tracing is around syscalls or devices. > >> > > >> > Ideas? > >> > > >> > >> I found this related thread: > >> > >> https://groups.google.com/forum/#!msg/golang-nuts/8gszDBRZh_ > >> 4/lhROTfN9TxIJ > >> > >> << > >> I believe this can happen on GNU/Linux if your program uses cgo and if > >> thread A is in the Go runtime starting up a new thread B while thread > >> C is execing a program. The underlying cause is that while one thread > >> is calling exec the Linux kernel will fail attempts by other threads > >> to call clone by returning EAGAIN. (Look for uses of the in_exec > >> field in the kernel sources.) > >> >> > >> > > > > Yeah, this seems to be very accurate. It's also why it seems this is a > > cosmetic problem only, some thread not calling exec fails, but well, the > > thread is about to die anyway. > > > > > >> Something like adding a little sleep removes the traces, for instance: > >> > >> http://paste.ubuntu.com/24151637/ > >> > >> where the program run sleep for 1ms before calling Exec. For smaller > units > >> (say, 20 us) the issue still happens. > >> > >> It looks to me that right before running main(), go creates some > threads, > >> calling clone() and probably getting the race described in the thread. > As > >> anyway you are running Exec I guess the traces are harmless, you do not > >> need the go threads. Nonetheless, I think that the go run time should > >> retry > >> instead of printing that trace. > > > > > > Cheers, > > mwh > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net From bret.barker at canonical.com Mon Mar 13 15:08:41 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Mon, 13 Mar 2017 11:08:41 -0400 Subject: Removing an unreleased package revision In-Reply-To: References: Message-ID: <20170313150841.GC59562@abitrandom.net> On Sun, Mar 12, 2017 at 06:15:21PM +0100, Joseph Rushton Wakeling wrote: > Hello folks, > > Is there a mechanism for removing an unreleased package revision from the > store? I'd like to get rid of revision 7 of the ldc2 snap, which has some > issues on 16.10 that make it unsuitable for release (even to the Edge > channel). > We don't generally remove revisions, but it shouldn't impact your ability to push and release newer revisions. -bret From michael.hudson at canonical.com Mon Mar 13 21:05:05 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Tue, 14 Mar 2017 10:05:05 +1300 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: On 14 March 2017 at 01:59, John Lenton wrote: > This one is slightly more interesting. > > You need 1.8 (or patched <1.8 as per the previous thread) for this one > to make sense; without it you're just going to get drowned in warning > messages and not see the real issue. > > This one is the real issue :-) > Ah _hah_! > In go, when calling syscall.Exec to a setuid root binary, sometimes > (about 4% of the times, on my machine, but it's hardware- and > load-dependent), the exec'ed process will find itself running with > effective uid different to zero. That is, a setuid root binary will > find itself running as non-root. As the process that sets up > confinement is setuid root (in distros where setuid is favoured over > capabilities), this means the snap app falls on its face. > > TODO: check if something similar happens when using caps > > This is *probably* a bug in Go, but it only seems to arise when using > syscall.Exec, which as far as I can tell is unsupported (the whole > syscall package is unsupported -- not covered by the go1 compatibility > promise -- and its replacement, golang.org/x/sys/unix, is ominously > missing Exec). > > Having said that, it might be a bug in the kernel ;-) > And I say this because if you pin the process to a single cpu, the > issue doesn't arise. > > Anyway, code to repro this is at > https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 > > on my machine, > > $ for i in `seq -w 9999`; do ./a_c; done | wc -l > 0 > $ for i in `seq -w 9999`; do ./a_go; done | wc -l > 394 > > And, > > $ for i in `seq -w 9999`; do taskset 2 ./a_go; done | wc -l > 0 > > Gnarly! > That's pretty exciting. I bet this is going to have the same underlying cause as the other bug: something some other thread in the go process is doing is causing the kernel to ignore the setuid bit. If I add a time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit is respected every time. It doesn't help that setuid is ignored when tracing or that strace likes to hang when you trace a_go. I spent a while staring at the kernel source but I don't really have any idea how this might be happening. It might be this code https://github.com/torvalds/linux/blob/master/security/commoncap.c#L549-L561, but I don't know how to be sure (well, without building kernels to do debugging-via-kprint or whatever). Cheers, mwh From michael.hudson at canonical.com Mon Mar 13 22:26:26 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Tue, 14 Mar 2017 11:26:26 +1300 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: On 14 March 2017 at 10:05, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > > On 14 March 2017 at 01:59, John Lenton wrote: > >> This one is slightly more interesting. >> >> You need 1.8 (or patched <1.8 as per the previous thread) for this one >> to make sense; without it you're just going to get drowned in warning >> messages and not see the real issue. >> >> This one is the real issue :-) >> > > Ah _hah_! > > >> In go, when calling syscall.Exec to a setuid root binary, sometimes >> (about 4% of the times, on my machine, but it's hardware- and >> load-dependent), the exec'ed process will find itself running with >> effective uid different to zero. That is, a setuid root binary will >> find itself running as non-root. As the process that sets up >> confinement is setuid root (in distros where setuid is favoured over >> capabilities), this means the snap app falls on its face. >> >> TODO: check if something similar happens when using caps >> >> This is *probably* a bug in Go, but it only seems to arise when using >> syscall.Exec, which as far as I can tell is unsupported (the whole >> syscall package is unsupported -- not covered by the go1 compatibility >> promise -- and its replacement, golang.org/x/sys/unix, is ominously >> missing Exec). >> >> Having said that, it might be a bug in the kernel ;-) >> And I say this because if you pin the process to a single cpu, the >> issue doesn't arise. >> >> Anyway, code to repro this is at >> https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 >> >> on my machine, >> >> $ for i in `seq -w 9999`; do ./a_c; done | wc -l >> 0 >> $ for i in `seq -w 9999`; do ./a_go; done | wc -l >> 394 >> >> And, >> >> $ for i in `seq -w 9999`; do taskset 2 ./a_go; done | wc -l >> 0 >> >> Gnarly! >> > > That's pretty exciting. I bet this is going to have the same underlying > cause as the other bug: something some other thread in the go process is > doing is causing the kernel to ignore the setuid bit. If I add a > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit > is respected every time. It doesn't help that setuid is ignored when > tracing or that strace likes to hang when you trace a_go. > > I spent a while staring at the kernel source but I don't really have any > idea how this might be happening. It might be this code > https://github.com/torvalds/linux/blob/master/ > security/commoncap.c#L549-L561, but I don't know how to be sure (well, > without building kernels to do debugging-via-kprint or whatever). > > Perhaps unsurprisingly, I think what the other go threads are doing that is causing the problem is -- as before -- calling clone(). I can reproduce with a C program I wrote to call it as much as possible: mwhudson at aeglos:/opt/opensource/go-test-cases/setuid-lossage$ cat a_c2.c #include #include #include #include void* nothing(void *p) { return NULL; } void run_do_nothing_thread() { pthread_t t; if (pthread_create(&t, NULL, nothing, NULL) == 0) { pthread_join(t, NULL); } } void* target(void *p) { while (1) { run_do_nothing_thread(); } return NULL; } void run_spinner_thread() { pthread_t t; pthread_create(&t, NULL, target, NULL); } int main() { struct timespec tv; for (int i = 0; i < 10; i++) { run_spinner_thread(); } tv.tv_sec = 0; tv.tv_nsec = 100000; nanosleep(&tv, NULL); int rv = execl("./b", "./b", NULL); printf("WHAAT! %d\n", rv); return 0; } mwhudson at aeglos:/opt/opensource/go-test-cases/setuid-lossage$ cc -Wall a_c2.c -o a_c2 -lpthread mwhudson at aeglos:/opt/opensource/go-test-cases/setuid-lossage$ for i in `seq 1000`; do ./a_c2; done | wc -l 23 Looking at the kernel again, I think it might be some kind of race between all the copying of kernel structures that happens in the clone syscall and the checking that happens around exec? Pretty hairy though. Cheers, mwh From john.lenton at canonical.com Mon Mar 13 23:21:47 2017 From: john.lenton at canonical.com (John Lenton) Date: Mon, 13 Mar 2017 23:21:47 +0000 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: On 13 March 2017 at 21:05, Michael Hudson-Doyle wrote: > If I add a > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit > is respected every time. on my way to bed, I'll give your response a proper read in the morning, but note that my reproducer causes the issue a lot more frequently than in "the real world" (snap run calling snap-confine calling snap-exec), where delays are happening naturally (because the programs aren't just calling exec, they actually have work to do :-p). I don't have numbers for how often it happens in snappy; it's a lot less frequent, but often enough to be annoying when working interactively (and there are bug reports with these warnings/errors in lp already). From michael.hudson at canonical.com Mon Mar 13 23:33:41 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Tue, 14 Mar 2017 12:33:41 +1300 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: On 14 March 2017 at 12:21, John Lenton wrote: > On 13 March 2017 at 21:05, Michael Hudson-Doyle > wrote: > > If I add a > > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit > > is respected every time. > > on my way to bed, I'll give your response a proper read in the > morning, but note that my reproducer causes the issue a lot more > frequently than in "the real world" (snap run calling snap-confine > calling snap-exec), where delays are happening naturally (because the > programs aren't just calling exec, they actually have work to do :-p). > I don't have numbers for how often it happens in snappy; it's a lot > less frequent, but often enough to be annoying when working > interactively (and there are bug reports with these warnings/errors in > lp already). Oh yes, the sleep was just to allow the other threads to settle in the test case program. It's not a solution for the real world at all. Cheers, mwh From manik at canonical.com Tue Mar 14 02:16:39 2017 From: manik at canonical.com (Manik Taneja) Date: Mon, 13 Mar 2017 19:16:39 -0700 Subject: To get the environment variables in snapping In-Reply-To: References: Message-ID: jin, i wonder if this would be better confined as classic? /manik On Mon, Mar 13, 2017 at 1:29 AM, Jin Hsieh wrote: > Hello guys, > > We are making a workable mail solution snap, > the selected back-end services are Postfix(SMTP) and Dovecot(POP3/IMAP). > > For those services as you known they have some dependencies with classic > paths, > for example the /etc/postfix/main.cf and /etc/dovecot/dovecot.conf so we > made some changes on the upstream code, > to get the environment variables such as SNAP, SNAP_DATA/SNAP_COMMON by > getenv(), > then replace the classic one into $SNAP_DATA/etc/postfix/* to make it works > properly. > > Also, for a bigger snap like this, > the component(one of the parts) will execute external command to trigger > another one, > in such the case Postfix forks its child process: pipe to call dovecot-lda > (which is a sub-process of Dovecot), > to complete the mail retrieving function, now I would say *it is lucky to > have a useful configuration parameter* "export_environment" in Postfix, > so that we can make sure the commands could be executed correctly in our > snap world with specific $SNAP exported. > http://www.postfix.org/postconf.5.html > > > But you could recognize the modification we made *is hard to upstream guys > to accept/merge the changes into their trunk*, > so many getenv("SNAP") in the code or in where the code flow uses > clean_env() we also need to cache the SNAP-related variables, > I am wondering if we have a better way to do this, for example an interface > or environment-sharing could make the life easier? > 1. then have the chances to make the upstream code up without > getenv("SNAP") to make their code snap-adaptive > 2. then have a much regular way to export environment when one > component calls another one externally without "export_environment" support > > Any feedback would be welcomed, > many thanks. > > BR. > Jin > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From n.curalli at domotz.com Tue Mar 14 09:42:50 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 14 Mar 2017 09:42:50 +0000 Subject: Netplan replug function is incompatible with ath9k_htc module Message-ID: Hi all, we ( my work team and I ) are porting an allwinner H3 with wireless chip Atheros AR9271 to Ubuntu Core 16. We hit the following problem about the interaction between netplan and the ath9k_htc module, controlling the chip Atheros AR9271. If you run the following command netplan --debug apply or you use console-conf for setting the network interfaces we get the following messages : ** (generate:2261): DEBUG: Processing input file //etc/netplan/00-snapd-config.yaml.. ** (generate:2261): DEBUG: eth0: setting default backend to 1 ** (generate:2261): DEBUG: Generating output files.. ** (generate:2261): DEBUG: NetworkManager: definition eth0 is not for us (backend 1) DEBUG:netplan generated networkd configuration exists, restarting networkd DEBUG:no netplan generated NM configuration exists DEBUG:device lo operstate is unknown, not replugging DEBUG:device eth0 operstate is up, not replugging DEBUG:replug wlan0: unbinding 4-1:1.0 from /sys/bus/usb/drivers/ath9k_htc DEBUG:replug wlan0: rebinding 4-1:1.0 to /sys/bus/usb/drivers/ath9k_htc The last two row show two consecutive actions, one soon after the other: unbind and bind the usb device on usb hub. The module ath9k_htc doesn't work fine in this situation: the wireless interface disappears. Our problem can be fixed by using the same approcch used for mac80211_hwsim e mwifiex_pcie modules. We had a look at the netplan code. Our problem is testing our simple patch before open the bug report for netplat project: the problematic file is src/netplan. How can we repack a core snap with different code per netplan? How long does it take to have a patch like this to be accepted in core snap code? Cheers, Nicolino From loic.minier at ubuntu.com Tue Mar 14 10:29:04 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 14 Mar 2017 11:29:04 +0100 Subject: Netplan replug function is incompatible with ath9k_htc module In-Reply-To: References: Message-ID: Hi, On Tue, Mar 14, 2017 at 10:42 AM, Nicolino Curalli wrote: > Our problem is testing our simple patch before open the bug report for > netplat project: the problematic file is src/netplan. > (So you want to test an updated netplan binary.) How can we repack a core snap with different code per netplan? > You can either run netplan on Ubuntu classic, or you can simply run it by hand on top of Ubuntu Core (e.g. from your home directory). How long does it take to have a patch like this to be accepted in core snap > code? > It can be fast, but there are ~3-4 steps: 1) merge proposal against netplan 2) netplan upload to latest Ubuntu 3) backport to LTS / PPA against which Core images are built 4) next image build (every ~2w?) Cheers, - Loïc Minier From john.lenton at canonical.com Tue Mar 14 10:56:00 2017 From: john.lenton at canonical.com (John Lenton) Date: Tue, 14 Mar 2017 10:56:00 +0000 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: As a followup, I added a mutex around pthread_create, and around the exec syscall, and the problem went away. This all in go's runtime; not a huge diff but they probably don't want the overhead (and that seems reasonable to me). Next I'm going to try to find a kernel person to take a look at this. On 13 March 2017 at 23:33, Michael Hudson-Doyle wrote: > On 14 March 2017 at 12:21, John Lenton wrote: > >> On 13 March 2017 at 21:05, Michael Hudson-Doyle >> wrote: >> > If I add a >> > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit >> > is respected every time. >> >> on my way to bed, I'll give your response a proper read in the >> morning, but note that my reproducer causes the issue a lot more >> frequently than in "the real world" (snap run calling snap-confine >> calling snap-exec), where delays are happening naturally (because the >> programs aren't just calling exec, they actually have work to do :-p). >> I don't have numbers for how often it happens in snappy; it's a lot >> less frequent, but often enough to be annoying when working >> interactively (and there are bug reports with these warnings/errors in >> lp already). > > > Oh yes, the sleep was just to allow the other threads to settle in the test > case program. It's not a solution for the real world at all. > > Cheers, > mwh > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From n.curalli at domotz.com Tue Mar 14 14:56:59 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 14 Mar 2017 14:56:59 +0000 Subject: Netplan replug function is incompatible with ath9k_htc module References: Message-ID: Thanks Loïc, I reported the bug and proposed a patch. Cheers, Nicolino Il 14/03/2017 11:29, Loïc Minier ha scritto: > Hi, > > On Tue, Mar 14, 2017 at 10:42 AM, Nicolino Curalli > wrote: > >> Our problem is testing our simple patch before open the bug report for >> netplat project: the problematic file is src/netplan. >> > (So you want to test an updated netplan binary.) > > How can we repack a core snap with different code per netplan? > You can either run netplan on Ubuntu classic, or you can simply run it by > hand on top of Ubuntu Core (e.g. from your home directory). > > How long does it take to have a patch like this to be accepted in core snap >> code? >> > It can be fast, but there are ~3-4 steps: > 1) merge proposal against netplan > 2) netplan upload to latest Ubuntu > 3) backport to LTS / PPA against which Core images are built > 4) next image build (every ~2w?) > > Cheers, > - Loïc Minier From john.lenton at canonical.com Tue Mar 14 18:12:01 2017 From: john.lenton at canonical.com (John Lenton) Date: Tue, 14 Mar 2017 18:12:01 +0000 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: I've filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1672819 and https://github.com/golang/go/issues/19546 (the latter more of an FYI than a bug) On 14 March 2017 at 10:56, John Lenton wrote: > As a followup, I added a mutex around pthread_create, and around the > exec syscall, and the problem went away. This all in go's runtime; not > a huge diff but they probably don't want the overhead (and that seems > reasonable to me). > Next I'm going to try to find a kernel person to take a look at this. > > On 13 March 2017 at 23:33, Michael Hudson-Doyle > wrote: >> On 14 March 2017 at 12:21, John Lenton wrote: >> >>> On 13 March 2017 at 21:05, Michael Hudson-Doyle >>> wrote: >>> > If I add a >>> > time.Sleep(1*time.Millisecond) to a_go.go before the exec, the setuid bit >>> > is respected every time. >>> >>> on my way to bed, I'll give your response a proper read in the >>> morning, but note that my reproducer causes the issue a lot more >>> frequently than in "the real world" (snap run calling snap-confine >>> calling snap-exec), where delays are happening naturally (because the >>> programs aren't just calling exec, they actually have work to do :-p). >>> I don't have numbers for how often it happens in snappy; it's a lot >>> less frequent, but often enough to be annoying when working >>> interactively (and there are bug reports with these warnings/errors in >>> lp already). >> >> >> Oh yes, the sleep was just to allow the other threads to settle in the test >> case program. It's not a solution for the real world at all. >> >> Cheers, >> mwh >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From manik at canonical.com Tue Mar 14 23:39:56 2017 From: manik at canonical.com (Manik Taneja) Date: Tue, 14 Mar 2017 16:39:56 -0700 Subject: RAID on NextCloud Message-ID: hi there, an interesting question came up on askubuntu- https://askubuntu.com/questions/888404/ubuntu-core-with-raid-1?rq=1 is the best solution to package mdadm as a snap with core providing an interface to /dev/md*? are there alternate solutions? /manik From simon.fels at canonical.com Wed Mar 15 06:13:48 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 15 Mar 2017 07:13:48 +0100 Subject: RAID on NextCloud In-Reply-To: References: Message-ID: On 15.03.2017 00:39, Manik Taneja wrote: > hi there, > > an interesting question came up on askubuntu- > > https://askubuntu.com/questions/888404/ubuntu-core-with-raid-1?rq=1 > > is the best solution to package mdadm as a snap with core providing > an interface to /dev/md*? are there alternate solutions? We had a pretty active discussion a while back when we implemented the udisks2 interface in snapd. The outcome was that we don't want to give arbitrary snaps access to block devices and added all access for those directly into the udisks2 interface (see [0]). udisks2 offers a mediated way for all other snaps to deal with block devices and generally also allows working with RAIDs. I say generally, because this is a feature we didn't verified yet that it is working with the udisks2 snap currently in the store. If support for RAIDs in udisks2 works users should be able to mount a RAID on a directory in /media via an dbus API call. One downside is that the udisks2 interface explicitly denies plug connections as it still gives kind of privileged access to the system. Every mount done via udisks2 will appear below /media and every snap using the removable-media interface will get access to devices mounted there, regardless if it's the system partition or not. So even the plug side is a very privileged thing. That said, snaps can ask for a snap-declaration on the store side to get connections to udisks2. Another feature we support with the udisks2 snap is auto-mounting. This allows a device to say that it wants removable devices like USB storage device to be automatically mounted in /media as you know it from consumer oriented devices like the Ubuntu Desktop. Depending on how the RAID is setup this might be able to get the the RAID mounted on boot into /media. Requirements for the automounter to consider a device are currently: * Device is not a system device (meaning its not a partition on the device we're booting the system from) * Device is not already mounted * Device is a removable devices (USB, CD/DVD) For a very simple, unconfined solution you could just install the udisks2 snap (given that it detects and works well with RAID devices) and create a systemd unit in /etc/systemd/system/mount-my-raid.service [Unit] Description=Mount my RAID [Service] Exec=/snap/bin/udisks2.udisksctl mount -b /path/to/block/device [Install] WantedBy=multi-user.target Then activate it via $ sudo systemctl enable mount-my-raid.service and the RAID should be automatically mounted below /media on the next system reboot. I hope this helps. Btw. I will post this as an answer to the askubuntu.com question too. regards, Simon [0]: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/udisks2.go From jacek.nykis at canonical.com Wed Mar 15 11:56:27 2017 From: jacek.nykis at canonical.com (Jacek Nykis) Date: Wed, 15 Mar 2017 11:56:27 +0000 Subject: How to bump ulimit? Message-ID: <77643ad1-fa56-6512-533c-ba0e6d954706@canonical.com> Hello, I have a server application that hit max open files limit, which by default is set to 1024. I'd like to bump that limit significantly but it appears that I can only go as high as 4096. When I try with value 4097 I'm getting this: 7: ulimit: error setting limit (Operation not permitted) Is there a way to increase ulimit values beyond 4096? -- Regards, Jacek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: OpenPGP digital signature URL: From janekolszak at gmail.com Wed Mar 15 13:29:14 2017 From: janekolszak at gmail.com (Jan Olszak) Date: Wed, 15 Mar 2017 14:29:14 +0100 Subject: Connecting snap to keyring Message-ID: Hi there! Is there anything like "Secret Service" interface? An interface to gnome-keyring or maybe any other keyring? Thanks, Jan From kyle.fazzari at canonical.com Wed Mar 15 16:13:59 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 15 Mar 2017 09:13:59 -0700 Subject: Connecting snap to keyring In-Reply-To: References: Message-ID: On Mar 15, 2017 06:45, "Jan Olszak" wrote: Hi there! Is there anything like "Secret Service" interface? An interface to gnome-keyring or maybe any other keyring? Not yet: https://bugs.launchpad.net/snapd/+bug/1653769 From luke.williams at canonical.com Wed Mar 15 19:29:44 2017 From: luke.williams at canonical.com (Luke Williams) Date: Wed, 15 Mar 2017 12:29:44 -0700 Subject: Best Practice for building modules and including them in Kernel Snap Message-ID: Hello, What are the best practices for building and including kernel modules with kernel snaps? Prior to snapcraft 2.25, when building kernel snaps, the modules would be located in parts/kernel/install/lib/modules// so that if I needed to add custom modules, I could put them in this path and then run depmod -a -b parts/kernel/install/ and it would update the modules dependancies and symbols and then I could run snapcraft snap and package everything up. Now that the modules and firmware directories fall under parts/kernel/install the depmod -b doesn't work anymore. What I have done to make this work is I create a symlink to install as lib and then I can run the depmod command, then I remove the lib symlink and then run snapcraft snap and everything is good. This seems kind of kludgy and not the right way to do this. Is there a recommended way that this should be handled? -- Thanks, Luke Williams - Technical Partner Manager, Network Switches and Ubuntu-Core luke.williams at canonical.com www.canonical.com || www.ubuntu.com From mrsingh at ssni.com Wed Mar 15 20:14:54 2017 From: mrsingh at ssni.com (Mritunjai Singh) Date: Wed, 15 Mar 2017 20:14:54 +0000 Subject: bluepy-helper not being built using Message-ID: Hello, I am trying to use the sensortag snap available on github [https://github.com/mectors/sensortag] to get the data from TI sensor and posting these sensor data to cloud using our proprietary SDK APIs. I am successfully able to build and install the sensortag snap and also connected the snap to bluetooth-control to make sure that the snap has bluetooth-control. I am following the README.md available with the snap. - Build and install of the sensortag snap successful. - sensortag.sensortag-init 7C:01:91:72:63:32 successful - sensortag.sensortag-in giving error messages shown below: Traceback (most recent call last): File "/snap/sensortag/x1/bin/sensortag", line 11, in sys.exit(main()) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 416, in main tag = SensorTag(arg.host) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 331, in __init__ Peripheral.__init__(self,addr) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 318, in __init__ self.connect(deviceAddr, addrType, iface) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 353, in connect self._startHelper() File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 210, in _startHelper universal_newlines=True) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 947, in __init__ restore_signals, start_new_session) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child raise child_exception_type(errno_num, err_msg) FileNotFoundError: [Errno 2] No such file or directory: '/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/bluepy-helper' After some research it looks like that snap is not able to build the the "sensortag/parts/bluepy/buildbluepy-helper.c" and thus the bluepy-helper object is not created during the install of bluepy. I can see that there is a bluepy-helper.c file but no object. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluez-5.29 btle.py __init__.py __pycache__ uuids.json If I run make manually within the folder the objects are created. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluepy-helper bluez-5.29 btle.py __init__.py __pycache__ uuids.json Compiling bluepy-helper works as expected but it is not copied to the build directory and thus not installed. It seems to be known issue as shown in links below: https://github.com/IanHarvey/bluepy/issues/158 https://github.com/IanHarvey/bluepy/issues/139 Can anyone help me resolve this issue. Regards, Mritunjai From manik at canonical.com Wed Mar 15 22:18:15 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 15 Mar 2017 15:18:15 -0700 Subject: RAID on NextCloud In-Reply-To: References: Message-ID: much appreciated simon! On Tue, Mar 14, 2017 at 11:13 PM, Simon Fels wrote: > On 15.03.2017 00:39, Manik Taneja wrote: > > hi there, > > > > an interesting question came up on askubuntu- > > > > https://askubuntu.com/questions/888404/ubuntu-core-with-raid-1?rq=1 > > > > is the best solution to package mdadm as a snap with core providing > > an interface to /dev/md*? are there alternate solutions? > > We had a pretty active discussion a while back when we implemented the > udisks2 interface in snapd. The outcome was that we don't want to give > arbitrary snaps access to block devices and added all access for those > directly into the udisks2 interface (see [0]). > > udisks2 offers a mediated way for all other snaps to deal with block > devices and generally also allows working with RAIDs. I say generally, > because this is a feature we didn't verified yet that it is working with > the udisks2 snap currently in the store. > > If support for RAIDs in udisks2 works users should be able to mount a > RAID on a directory in /media via an dbus API call. > > One downside is that the udisks2 interface explicitly denies plug > connections as it still gives kind of privileged access to the system. > Every mount done via udisks2 will appear below /media and every snap > using the removable-media interface will get access to devices mounted > there, regardless if it's the system partition or not. So even the plug > side is a very privileged thing. That said, snaps can ask for a > snap-declaration on the store side to get connections to udisks2. > > Another feature we support with the udisks2 snap is auto-mounting. This > allows a device to say that it wants removable devices like USB storage > device to be automatically mounted in /media as you know it from > consumer oriented devices like the Ubuntu Desktop. Depending on how the > RAID is setup this might be able to get the the RAID mounted on boot > into /media. Requirements for the automounter to consider a device are > currently: > > * Device is not a system device (meaning its not a partition on the > device we're booting the system from) > * Device is not already mounted > * Device is a removable devices (USB, CD/DVD) > > For a very simple, unconfined solution you could just install the > udisks2 snap (given that it detects and works well with RAID devices) > and create a systemd unit in /etc/systemd/system/mount-my-raid.service > > [Unit] > Description=Mount my RAID > > [Service] > Exec=/snap/bin/udisks2.udisksctl mount -b /path/to/block/device > > [Install] > WantedBy=multi-user.target > > Then activate it via > > $ sudo systemctl enable mount-my-raid.service > > and the RAID should be automatically mounted below /media on the next > system reboot. > > I hope this helps. > > Btw. I will post this as an answer to the askubuntu.com question too. > > regards, > Simon > > > [0]: > https://github.com/snapcore/snapd/blob/master/interfaces/ > builtin/udisks2.go > > -- > 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 Thu Mar 16 07:17:57 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Thu, 16 Mar 2017 07:17:57 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: , Message-ID: Hi John, Thank you for the finding. > note that in that log, snapd isn't running because > > snapd[2217]: fatal error: runtime: out of memory > But there is no process invoked explicitly from our end. So is there something that we can check for this error ? @paolo.pisati and @ogra: We downloaded the xenial kernel that is used for Dragonboard410c prebuilt binaries as you mentioned earlier: git clone git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial We added dtsi and firmware options in snapcraft.yaml. Here is our snapcraft.yaml: http://pastebin.com/QBKLGkfu We are getting wifi interface in the first boot console, and all the modules are automatically loaded (insmod) when rootfs is mounted. It would be great if you can address the below issues / queries (This would really get us going ahead): 1. "snap list" does not show any snaps. However, we have observed that there are times when "snap list" shows just core.snap. But this is very rare. 2. "snap install hello-world" gives this error: http://pastebin.com/HV4fWzGk 3. When we build the linaro linux kernel, once we generate the uImage, we build the boot.img which has the DTB + uImage + cmdline args + initrd. So if we want to change the cmdline arguments to kernel in Ubuntu-Core, then how can we change it from snapcraft.yaml ? Awaiting your reply. Thanks & Regards, 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 serge.borovkov at gmail.com Thu Mar 16 08:32:17 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Thu, 16 Mar 2017 11:32:17 +0300 Subject: Simple daemon settings Message-ID: Hello, I am running service using daemon: simple in snapcraft. Is there any way to configure how systemd handles restarting in the snapcraft.yaml? Current behavior is that it restarts the service when it exits with non zero exit code. But it does not get restarted otherwise. Can this be tweaked? From ara.pulido at canonical.com Thu Mar 16 08:41:35 2017 From: ara.pulido at canonical.com (Ara Pulido) Date: Thu, 16 Mar 2017 09:41:35 +0100 Subject: Simple daemon settings In-Reply-To: References: Message-ID: On Thu, Mar 16, 2017 at 9:32 AM, Sergey Borovkov wrote: > Hello, > I am running service using daemon: simple in snapcraft. Is there any way > to configure how systemd handles restarting in the snapcraft.yaml? Current > behavior is that it restarts the service when it exits with non zero exit > code. But it does not get restarted otherwise. Can this be tweaked? > I believe you can add: daemon: simple restart-condition: always Regards, Ara. From roberto.escandon at canonical.com Thu Mar 16 09:00:39 2017 From: roberto.escandon at canonical.com (=?UTF-8?Q?Roberto_Mier_Escand=c3=b3n_=ee=83=bf?=) Date: Thu, 16 Mar 2017 10:00:39 +0100 Subject: Simple daemon settings In-Reply-To: References: Message-ID: <7cfbb467-096e-5d6a-8ff9-b3a5ec4c4203@canonical.com> You can find all the restart conditions here [1] Basically it says: # Condition to restart the daemon under. Defaults to on-failure. # See the systemd.service manual on Restart for details. restart-condition: \ on-failure | on-success | on-abnormal | on-abort | always | never Cheers. [1] https://snapcraft.io/docs/snaps/metadata On 16/03/17 09:41, Ara Pulido wrote: > On Thu, Mar 16, 2017 at 9:32 AM, Sergey Borovkov > wrote: > >> Hello, >> I am running service using daemon: simple in snapcraft. Is there any way >> to configure how systemd handles restarting in the snapcraft.yaml? Current >> behavior is that it restarts the service when it exits with non zero exit >> code. But it does not get restarted otherwise. Can this be tweaked? >> > > I believe you can add: > > daemon: simple > restart-condition: always > > Regards, > Ara. > -- -- . Roberto Mier Escandón. . Software Engineer . . Canonical - Solutions Engineering -- From serge.borovkov at gmail.com Thu Mar 16 09:09:55 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Thu, 16 Mar 2017 12:09:55 +0300 Subject: Simple daemon settings In-Reply-To: <7cfbb467-096e-5d6a-8ff9-b3a5ec4c4203@canonical.com> References: <7cfbb467-096e-5d6a-8ff9-b3a5ec4c4203@canonical.com> Message-ID: Thanks, just what I needed. On 16 March 2017 at 12:00, Roberto Mier Escandón  < roberto.escandon at canonical.com> wrote: > > You can find all the restart conditions here [1] > > Basically it says: > > # Condition to restart the daemon under. Defaults to on-failure. > # See the systemd.service manual on Restart for details. > restart-condition: \ > on-failure | on-success | on-abnormal | on-abort | always | never > > Cheers. > > [1] https://snapcraft.io/docs/snaps/metadata > > On 16/03/17 09:41, Ara Pulido wrote: > > On Thu, Mar 16, 2017 at 9:32 AM, Sergey Borovkov < > serge.borovkov at gmail.com> > > wrote: > > > >> Hello, > >> I am running service using daemon: simple in snapcraft. Is there any way > >> to configure how systemd handles restarting in the snapcraft.yaml? > Current > >> behavior is that it restarts the service when it exits with non zero > exit > >> code. But it does not get restarted otherwise. Can this be tweaked? > >> > > > > I believe you can add: > > > > daemon: simple > > restart-condition: always > > > > Regards, > > Ara. > > > > -- > -- > . Roberto Mier Escandón. > . Software Engineer > . > . Canonical - Solutions Engineering > -- > From jin.hsieh at canonical.com Thu Mar 16 09:14:46 2017 From: jin.hsieh at canonical.com (Jin Hsieh) Date: Thu, 16 Mar 2017 17:14:46 +0800 Subject: To get the environment variables in snapping In-Reply-To: References: Message-ID: Hey Manik, Thanks for the reply! Right, we considered that before it is obviously okay if we snap it as a classic one, but now we are trying to deploy such the services into Ubuntu Core. (the services in this case: Postfix, Dovecot, ...etc.) So you may understand what we did becomes to give those modifications to make it works with Ubuntu Core, and the patches we delivered are hard to sync with the upstream master branches. (now we have a trick to apply local patch in our launching script to override the upstream code, but the way is not very flexible if any updates occurred from upstream, only prefer in using a specific version/repo) And this is also why I want to have this discussion maybe with snapd/snapcraft team to manage a cooler way for doing this... But anyway, thanks :) BR. Jin On Tue, Mar 14, 2017 at 10:16 AM, Manik Taneja wrote: > jin, > > i wonder if this would be better confined as classic? > > /manik > > On Mon, Mar 13, 2017 at 1:29 AM, Jin Hsieh > wrote: > > > Hello guys, > > > > We are making a workable mail solution snap, > > the selected back-end services are Postfix(SMTP) and Dovecot(POP3/IMAP). > > > > For those services as you known they have some dependencies with classic > > paths, > > for example the /etc/postfix/main.cf and /etc/dovecot/dovecot.conf so we > > made some changes on the upstream code, > > to get the environment variables such as SNAP, SNAP_DATA/SNAP_COMMON by > > getenv(), > > then replace the classic one into $SNAP_DATA/etc/postfix/* to make it > works > > properly. > > > > Also, for a bigger snap like this, > > the component(one of the parts) will execute external command to trigger > > another one, > > in such the case Postfix forks its child process: pipe to call > dovecot-lda > > (which is a sub-process of Dovecot), > > to complete the mail retrieving function, now I would say *it is lucky to > > have a useful configuration parameter* "export_environment" in Postfix, > > so that we can make sure the commands could be executed correctly in our > > snap world with specific $SNAP exported. > > http://www.postfix.org/postconf.5.html > > > > > > But you could recognize the modification we made *is hard to upstream > guys > > to accept/merge the changes into their trunk*, > > so many getenv("SNAP") in the code or in where the code flow uses > > clean_env() we also need to cache the SNAP-related variables, > > I am wondering if we have a better way to do this, for example an > interface > > or environment-sharing could make the life easier? > > 1. then have the chances to make the upstream code up without > > getenv("SNAP") to make their code snap-adaptive > > 2. then have a much regular way to export environment when one > > component calls another one externally without "export_environment" > support > > > > Any feedback would be welcomed, > > many thanks. > > > > BR. > > Jin > > -- > > 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 michal.sawicz at canonical.com Thu Mar 16 10:34:40 2017 From: michal.sawicz at canonical.com (=?UTF-8?Q?Micha=c5=82_Sawicz?=) Date: Thu, 16 Mar 2017 11:34:40 +0100 Subject: Shared UI Themes Message-ID: Hi all, One of the interfaces we listed as things to be done to support UI applications proper was UI themes. Albert had a stab [1] at approaching this, but I'd like to discuss what we want here long-term, how flexible we want this to be. Right now the approach he's taken was to have a single snap (ubuntu-app-themes) that content-shares our preferred themes, and have the desktop helpers look there unconditionally. While this works, it feels like it'd be quite limiting, so we thought we discuss this in a wider forum. Ideally, I think, we should have per-toolkit, versioned, theme interfaces (gtk3-theme, qt5-theme). Can this be achieved with properties of the content interface? One problem with that is that approach is we wouldn't have a way to change the theme globally, for all snaps, unless we change the connections when the user selects a different theme. Question is, how do we tell apps which theme to use or where to find it? If a user connects a particular snap to a different theme, how do we tell the snapped app to use it? I'm thinking interface hooks here, the plugging snap would have to store some environment variables on connection. Alternatively, a launch helper could check the connected slot and modify the environment based on that? Each theme could then be snapped separately (we could also have bundles of themes - say, matching themes for multiple toolkits, or a group of themes from the same source?). On Ubuntu, we'd auto-connect our themes, other platforms would likely want to auto-connect some others? [1] https://github.com/ubuntu/snapcraft-desktop-helpers/pull/30 Cheers, -- Michał Sawicz Canonical Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: OpenPGP digital signature URL: From john.lenton at canonical.com Thu Mar 16 11:02:16 2017 From: john.lenton at canonical.com (John Lenton) Date: Thu, 16 Mar 2017 11:02:16 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: Message-ID: Hi Sunny, I don't understand what's going on with your system: * snapd is running out of memory. snapd should be using about 20MB of resident memory. How much was it trying to use when it ran out? How much is available? What does dmesg say about this crash? * snapd on a core system that doesn't list any snaps makes no sense at all. It needs to have at least three snaps at first boot: core, kernel, and gadget, otherwise you wouldn't get there. How are you building the image that you are booting? What's in /var/lib/snapd/state.json? (don't just pastebin that file if you have credentials in it!) What's in /snap? What's in /var/lib/snapd/seed/? And in seed.yaml? What's in /var/lib/snapd/snaps? What's in /etc/os-release? On 16 March 2017 at 07:17, Sunny Bhayani wrote: > Hi John, > > Thank you for the finding. > >> note that in that log, snapd isn't running because >> >> snapd[2217]: fatal error: runtime: out of memory >> > But there is no process invoked explicitly from our end. > > So is there something that we can check for this error ? > > @paolo.pisati and @ogra: > We downloaded the xenial kernel that is used for Dragonboard410c prebuilt > binaries as you mentioned earlier: > git clone > git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial > > We added dtsi and firmware options in snapcraft.yaml. > Here is our snapcraft.yaml: http://pastebin.com/QBKLGkfu > > We are getting wifi interface in the first boot console, and all the modules > are automatically loaded (insmod) when rootfs is mounted. > > It would be great if you can address the below issues / queries > (This would really get us going ahead): > > 1. "snap list" does not show any snaps. > However, we have observed that there are times when "snap list" shows > just core.snap. But this is very rare. > > 2. "snap install hello-world" gives this error: http://pastebin.com/HV4fWzGk > > 3. When we build the linaro linux kernel, once we generate the uImage, > we build the boot.img which has the DTB + uImage + cmdline args + initrd. > > So if we want to change the cmdline arguments to kernel in Ubuntu-Core, > then how can we change it from snapcraft.yaml ? > > Awaiting your reply. > > Thanks & Regards, > 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 michi.henning at canonical.com Thu Mar 16 13:06:47 2017 From: michi.henning at canonical.com (Michi Henning) Date: Thu, 16 Mar 2017 23:06:47 +1000 Subject: How to bump ulimit? In-Reply-To: <77643ad1-fa56-6512-533c-ba0e6d954706@canonical.com> References: <77643ad1-fa56-6512-533c-ba0e6d954706@canonical.com> Message-ID: Typing "ubuntu more than 4096 file descriptors” into Google worked well for me. Michi. > On 15 Mar 2017, at 21:56 , Jacek Nykis wrote: > > Hello, > > I have a server application that hit max open files limit, which by > default is set to 1024. > > I'd like to bump that limit significantly but it appears that I can only > go as high as 4096. When I try with value 4097 I'm getting this: > > 7: ulimit: error setting limit (Operation not permitted) > > Is there a way to increase ulimit values beyond 4096? > > -- > Regards, > Jacek > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From jacek.nykis at canonical.com Thu Mar 16 13:18:10 2017 From: jacek.nykis at canonical.com (Jacek Nykis) Date: Thu, 16 Mar 2017 13:18:10 +0000 Subject: How to bump ulimit? In-Reply-To: References: <77643ad1-fa56-6512-533c-ba0e6d954706@canonical.com> Message-ID: <69c0292d-c9ec-3bbd-7f0a-eaab3ff94686@canonical.com> Hi, Would you mind pasting exact command that worked for you from inside a snap? In my case ulimit works just fine outside of confinement. For example: jacek at laptop:~$ ulimit -n 10240 jacek at laptop:~$ ulimit -n 10240 But when I try the same when confined I can only go as high as 4096. -- Jacek On 16/03/17 13:06, Michi Henning wrote: > Typing "ubuntu more than 4096 file descriptors” into Google worked well for me. > > Michi. > > >> On 15 Mar 2017, at 21:56 , Jacek Nykis wrote: >> >> Hello, >> >> I have a server application that hit max open files limit, which by >> default is set to 1024. >> >> I'd like to bump that limit significantly but it appears that I can only >> go as high as 4096. When I try with value 4097 I'm getting this: >> >> 7: ulimit: error setting limit (Operation not permitted) >> >> Is there a way to increase ulimit values beyond 4096? >> >> -- >> Regards, >> Jacek >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: OpenPGP digital signature URL: From madper.xie at canonical.com Thu Mar 16 13:22:02 2017 From: madper.xie at canonical.com (Madper Xie) Date: Thu, 16 Mar 2017 21:22:02 +0800 Subject: How to convert the initrd.img during buiding the kernel snap. Message-ID: Hi all, My u-boot do not support the format of the initrd.img. So I need to manually convert it via mkimage every time. I tried to use scriptlet to convert the initrd.img file but failed. ``` install: | mkimage -n 'RamdiskImage' -A arm -O linux -T ramdisk -C gzip -d initrd.img ramfs.img rm initrd.img ``` I got: mkimage: Can't open initrd.img: No such file or directory rm: cannot remove 'initrd.img': No such file or directory It seems the scriptlet executed before downloading the initrd.img. Do we have any way to run a command after downloading the initrd.img? Thanks a lot, Madper From kyle.fazzari at canonical.com Thu Mar 16 15:47:26 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 16 Mar 2017 08:47:26 -0700 Subject: To get the environment variables in snapping In-Reply-To: References: Message-ID: On Mar 13, 2017 1:30 AM, "Jin Hsieh" wrote: But you could recognize the modification we made *is hard to upstream guys to accept/merge the changes into their trunk*, so many getenv("SNAP") in the code or in where the code flow uses clean_env() we also need to cache the SNAP-related variables, I am wondering if we have a better way to do this, for example an interface or environment-sharing could make the life easier? 1. then have the chances to make the upstream code up without getenv("SNAP") to make their code snap-adaptive 2. then have a much regular way to export environment when one component calls another one externally without "export_environment" support I'm not sure how an interface would help with the environment here. The codebase would still need to use it. Maybe I'm missing something. I hear you about the difficulty in upstreaming necessary changes, though. I find it helps to not make it snap-specific. "Hey, these paths are hard-coded. In my project I need them elsewhere. How would you feel about a PR that adds support for more flexibility there?" Then instead of having $SNAP everywhere, use something specific to the upstream project, like $POSTFIX_CONFIG or something. That still works for your snap, but makes the project feel more generally flexible as opposed to littered with code to support snaps. Kyle From sebastien.bacher at canonical.com Thu Mar 16 16:34:54 2017 From: sebastien.bacher at canonical.com (Sebastien Bacher) Date: Thu, 16 Mar 2017 17:34:54 +0100 Subject: Shared UI Themes In-Reply-To: References: Message-ID: <18960c7a-e1f4-1749-00ec-afa19ddbf4b9@canonical.com> Hey Michał, Thanks for the email, that's indeed a topic that had been pending for a while. Just for reference we have https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1576300 which is a similar topic Le 16/03/2017 à 11:34, Michał Sawicz a écrit : > On Ubuntu, we'd auto-connect our themes One other issue is that snaps are per-system and theme are per-user-session/desktop. You could have different users login into different desktop environment on your laptop, how do we handle them needing different themes? Cheers, Sebastien Bacher From michal.sawicz at canonical.com Thu Mar 16 17:28:16 2017 From: michal.sawicz at canonical.com (=?UTF-8?Q?Micha=c5=82_Sawicz?=) Date: Thu, 16 Mar 2017 18:28:16 +0100 Subject: Shared UI Themes In-Reply-To: <18960c7a-e1f4-1749-00ec-afa19ddbf4b9@canonical.com> References: <18960c7a-e1f4-1749-00ec-afa19ddbf4b9@canonical.com> Message-ID: W dniu 16.03.2017 o 17:34, Sebastien Bacher pisze: > One other issue is that snaps are per-system and theme are > per-user-session/desktop. You could have different users login into > different desktop environment on your laptop, how do we handle them > needing different themes? Sounds like we'd need the ability to connect to multiple theme snaps and then have the user's environment choose the right one? Is it even possible to plug into multiple slots? -- Michał Sawicz Canonical Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: OpenPGP digital signature URL: From tim.sueberkrueb at web.de Thu Mar 16 17:41:06 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Thu, 16 Mar 2017 18:41:06 +0100 Subject: Store - Organizations/Namespaces/Transfer packages Message-ID: <56ea69d3-49af-bae9-5868-a69848511a81@web.de> Hey everyone, I have some questions about best practices for organizations (like our Liri Project) regarding the store. 1. Accounts: Is it possible to have a "pure" organization account in the store where several people have full or partial access? The only option I can see right now would be someone from the team having to create a new Ubuntu One account (with a yet unregistered email address) who would have full access and could only grant rights to others for every individual package. What is recommended for organizations here/are there plans for the future? 2. Namespaces: If we'd choose the namespace "liri" and would register a new name in the store "liri-app", what would happen if someone else would try to register that name? Do we own "liri-app" because we were first or would users - in case of multiple "liri-app." packages have to install it using "liri-app.liri"? 3. Transferring Packages Is it possible to transfer packages from user1 to user2 (or from my personal account to a possible future Liri Account) or would I have to delete the package and create a new one? Thanks in advance :) All the best, Tim Süberkrüb From mhall119 at ubuntu.com Thu Mar 16 18:22:22 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Thu, 16 Mar 2017 14:22:22 -0400 Subject: Store - Organizations/Namespaces/Transfer packages In-Reply-To: <56ea69d3-49af-bae9-5868-a69848511a81@web.de> References: <56ea69d3-49af-bae9-5868-a69848511a81@web.de> Message-ID: On 03/16/2017 01:41 PM, Tim Süberkrüb wrote: > Hey everyone, > > I have some questions about best practices for organizations (like our > Liri Project) regarding the store. > > 1. Accounts: > > Is it possible to have a "pure" organization account in the store where > several people have full or partial access? The only option I can see > right now would be someone from the team having to create a new Ubuntu > One account (with a yet unregistered email address) who would have full > access and could only grant rights to others for every individual > package. What is recommended for organizations here/are there plans for > the future? > You are correct, this is the best way to handle this situation right now. You can use the + trick (realaddress+alias at domain.com) in your email address if you don't have a convenient one to use. Once you set it up and assign collaborators, you can proceed with your regular account. > 2. Namespaces: > > If we'd choose the namespace "liri" and would register a new name in the > store "liri-app", what would happen if someone else would try to > register that name? Do we own "liri-app" because we were first or would > users - in case of multiple "liri-app." packages have to > install it using "liri-app.liri"? > Package names are guaranteed to be unique in the snap store, so if you register liri-app then you're the only one who can publish a package by that name. > 3. Transferring Packages > > Is it possible to transfer packages from user1 to user2 (or from my > personal account to a possible future Liri Account) or would I have to > delete the package and create a new one? > There is a mechanism to dispute the ownership of a package name. You can use this to transfer a registered name from one publisher account to another. > Thanks in advance :) > > All the best, > > Tim Süberkrüb > > Michael Hall mhall119 at ubuntu.com From tim.sueberkrueb at web.de Thu Mar 16 19:17:31 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Thu, 16 Mar 2017 20:17:31 +0100 Subject: Store - Organizations/Namespaces/Transfer packages In-Reply-To: References: <56ea69d3-49af-bae9-5868-a69848511a81@web.de> Message-ID: <83e3afed-6cad-7690-2191-e9026a5762fe@web.de> Hey Michael, thanks for your reply! On 16.03.2017 19:22, Michael Hall wrote: > On 03/16/2017 01:41 PM, Tim Süberkrüb wrote: >> Hey everyone, >> >> I have some questions about best practices for organizations (like our >> Liri Project) regarding the store. >> >> 1. Accounts: >> >> Is it possible to have a "pure" organization account in the store where >> several people have full or partial access? The only option I can see >> right now would be someone from the team having to create a new Ubuntu >> One account (with a yet unregistered email address) who would have full >> access and could only grant rights to others for every individual >> package. What is recommended for organizations here/are there plans for >> the future? >> > You are correct, this is the best way to handle this situation right > now. You can use the + trick (realaddress+alias at domain.com) in your > email address if you don't have a convenient one to use. Once you set it > up and assign collaborators, you can proceed with your regular account. Okay. I'd personally really love to see something like organization accounts (maybe comparable to how GitHub handles organizations) in the future because I think this is a common use case. >> 2. Namespaces: >> >> If we'd choose the namespace "liri" and would register a new name in the >> store "liri-app", what would happen if someone else would try to >> register that name? Do we own "liri-app" because we were first or would >> users - in case of multiple "liri-app." packages have to >> install it using "liri-app.liri"? >> > Package names are guaranteed to be unique in the snap store, so if you > register liri-app then you're the only one who can publish a package by > that name. Oh, I see, so I was wrong with my assumptions (probably because I thought about how namespaces worked with click). So a snap "namespace" is not really a namespace but rather an unique id/name for the developer? >> 3. Transferring Packages >> >> Is it possible to transfer packages from user1 to user2 (or from my >> personal account to a possible future Liri Account) or would I have to >> delete the package and create a new one? >> > There is a mechanism to dispute the ownership of a package name. You can > use this to transfer a registered name from one publisher account to > another. Okay, great. Thanks for taking the time to answer my questions. Have a nice day, Tim Süberkrüb From michi.henning at canonical.com Fri Mar 17 02:40:23 2017 From: michi.henning at canonical.com (Michi Henning) Date: Fri, 17 Mar 2017 12:40:23 +1000 Subject: How to bump ulimit? In-Reply-To: <69c0292d-c9ec-3bbd-7f0a-eaab3ff94686@canonical.com> References: <77643ad1-fa56-6512-533c-ba0e6d954706@canonical.com> <69c0292d-c9ec-3bbd-7f0a-eaab3ff94686@canonical.com> Message-ID: <5AB7A0ED-E39B-490A-A3F9-1153555AAC58@canonical.com> > Would you mind pasting exact command that worked for you from inside a snap? > > In my case ulimit works just fine outside of confinement. For example: > jacek at laptop:~$ ulimit -n 10240 > jacek at laptop:~$ ulimit -n > 10240 > > But when I try the same when confined I can only go as high as 4096. $ cat /proc/sys/fs/file-max 1624349 $ ulimit -Hn 65536 $ ulimit -Sn 1024 $ ulimit -Sn 65536 $ ulimit -Sn 65536 This works for me when running a confined shell: $ snap run —shell mysnap.mycommand Michi. > > -- > Jacek > > > On 16/03/17 13:06, Michi Henning wrote: >> Typing "ubuntu more than 4096 file descriptors” into Google worked well for me. >> >> Michi. >> >> >>> On 15 Mar 2017, at 21:56 , Jacek Nykis wrote: >>> >>> Hello, >>> >>> I have a server application that hit max open files limit, which by >>> default is set to 1024. >>> >>> I'd like to bump that limit significantly but it appears that I can only >>> go as high as 4096. When I try with value 4097 I'm getting this: >>> >>> 7: ulimit: error setting limit (Operation not permitted) >>> >>> Is there a way to increase ulimit values beyond 4096? >>> >>> -- >>> Regards, >>> Jacek >>> >>> -- >>> 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 didrocks at ubuntu.com Fri Mar 17 08:06:35 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 17 Mar 2017 09:06:35 +0100 Subject: Shared UI Themes In-Reply-To: References: <18960c7a-e1f4-1749-00ec-afa19ddbf4b9@canonical.com> Message-ID: <141717f9-097d-e393-883d-d6400161a87b@ubuntu.com> Le 16/03/2017 à 18:28, Michał Sawicz a écrit : > W dniu 16.03.2017 o 17:34, Sebastien Bacher pisze: >> One other issue is that snaps are per-system and theme are >> per-user-session/desktop. You could have different users login into >> different desktop environment on your laptop, how do we handle them >> needing different themes? > Sounds like we'd need the ability to connect to multiple theme snaps and > then have the user's environment choose the right one? > > Is it even possible to plug into multiple slots? AFAIK it's not possible and my last email on the topic (which wasn't the first one) didn't get traction: "One snap to connect them all (or: the plugin story)". You can as well have a look at https://bugs.launchpad.net/snapd/+bug/1655125 to subscribe and follow the status. Cheers, Didier From jacek.nykis at canonical.com Fri Mar 17 09:01:22 2017 From: jacek.nykis at canonical.com (Jacek Nykis) Date: Fri, 17 Mar 2017 09:01:22 +0000 Subject: How to bump ulimit? In-Reply-To: <5AB7A0ED-E39B-490A-A3F9-1153555AAC58@canonical.com> References: <77643ad1-fa56-6512-533c-ba0e6d954706@canonical.com> <69c0292d-c9ec-3bbd-7f0a-eaab3ff94686@canonical.com> <5AB7A0ED-E39B-490A-A3F9-1153555AAC58@canonical.com> Message-ID: <0f040999-2432-ed93-9e19-5f00ef096b93@canonical.com> On 17/03/17 02:40, Michi Henning wrote: > >> Would you mind pasting exact command that worked for you from inside a snap? >> >> In my case ulimit works just fine outside of confinement. For example: >> jacek at laptop:~$ ulimit -n 10240 >> jacek at laptop:~$ ulimit -n >> 10240 >> >> But when I try the same when confined I can only go as high as 4096. > > $ cat /proc/sys/fs/file-max > 1624349 > $ ulimit -Hn > 65536 > $ ulimit -Sn > 1024 > $ ulimit -Sn 65536 > $ ulimit -Sn > 65536 > > This works for me when running a confined shell: > > $ snap run —shell mysnap.mycommand Interesting. This worked for me too with snap run --shell. I wonder if hard limit for my daemon is different than the one I get when I snap run --shell? Anyway I'll dig a big deeper and file a bug if needed, thanks for help. -- Jacek -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 299 bytes Desc: OpenPGP digital signature URL: From evan.dandrea at canonical.com Fri Mar 17 09:35:23 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Fri, 17 Mar 2017 09:35:23 +0000 Subject: Store - Organizations/Namespaces/Transfer packages In-Reply-To: <83e3afed-6cad-7690-2191-e9026a5762fe@web.de> References: <56ea69d3-49af-bae9-5868-a69848511a81@web.de> <83e3afed-6cad-7690-2191-e9026a5762fe@web.de> Message-ID: On Thu, 16 Mar 2017 at 19:18 Tim Süberkrüb wrote: > > > You are correct, this is the best way to handle this situation right > > now. You can use the + trick (realaddress+alias at domain.com) in your > > email address if you don't have a convenient one to use. Once you set it > > up and assign collaborators, you can proceed with your regular account. > > Okay. I'd personally really love to see something like organization > accounts (maybe comparable to how GitHub handles organizations) in the > future because I think this is a common use case. > Hi Tim, Good timing, we're exploring exactly this. :) There are a few options under consideration, but all involve letting you treat organisation members as collaborators on a snap. Of course we'll announce it here. If you start with a developer account to hold your organisation identity, you'll be able to transfer over when the time comes. From sunny.bhayani at einfochips.com Fri Mar 17 12:18:52 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Fri, 17 Mar 2017 12:18:52 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: , Message-ID: Hi John, Thanks you for your reply. > I don't understand what's going on with your system: > * snapd is running out of memory. snapd should be using about 20MB of > resident memory. How much was it trying to use when it ran out? How > much is available? What does dmesg say about this crash? We are not able to reproduce this error again. If we get this error, we will post details for this. While doing "snap install", it gives error. But doing "snap login" again, from the command prompt (shell), we are able to install the application via "snap install". But this method also is not 100% successful. Sometimes we get error. Here is the dmesg logs for the error case: http://pastebin.com/rAa8Zvfb The above log has two trial logs. In the First trial, we have prepared the SDCard and have setup the first boot console config. In the Second trial, we did "snap login". We obsereved that whenever we do a "snap install", irrespective of it being successful or fail, we get the below message repeatedly and the board reboots automatically after 15-20 minutes: "Broadcast message from root at localhost.localdomain (Thu 2017-03-16 12:31:13 UTC): reboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c' The system is going down for reboot at Thu 2017-03-16 12:39:13 UTC!" This is how it looks like when board is automatically reboot: http://pastebin.com/e2s6y3qc After the reboot is done (which takes around 5 minutes), thie above reboot message does not come. It would be great, if you can provide any comments. > * snapd on a core system that doesn't list any snaps makes no sense at > all. It needs to have at least three snaps at first boot: core, > kernel, and gadget, otherwise you wouldn't get there. Yes snapd on a core system does not list any snaps: http://pastebin.com/rAa8Zvfb > How are you building the image that you are booting? Here are the steps to building Ubuntu-Core Image: http://pastebin.com/0x52ATXi > What's in /var/lib/snapd/state.json? (don't just pastebin that file if you have > credentials in it!) What's in /snap? What's in /var/lib/snapd/seed/? > And in seed.yaml? What's in /var/lib/snapd/snaps? What's in > /etc/os-release? Here we listed various snaps directory as you asked: http://pastebin.com/DRXDvAQQ The state.json file is at: http://pastebin.com/0KyvECtz It would be more helpful to us if you provide some pointers. Thank you. 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 tim.sueberkrueb at web.de Fri Mar 17 16:13:04 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Fri, 17 Mar 2017 17:13:04 +0100 Subject: Store - Organizations/Namespaces/Transfer packages In-Reply-To: References: <56ea69d3-49af-bae9-5868-a69848511a81@web.de> <83e3afed-6cad-7690-2191-e9026a5762fe@web.de> Message-ID: <68e0bac7-b799-0602-bf74-1e7a13426a2c@web.de> Hey Evan, this is fantastic (/me is also watching https://github.com/canonical-ols/build.snapcraft.io/issues/132) :) Looking forward to this! All the best, Tim On 17.03.2017 10:35, Evan Dandrea wrote: > On Thu, 16 Mar 2017 at 19:18 Tim Süberkrüb > wrote: > > > > You are correct, this is the best way to handle this situation right > > now. You can use the + trick (realaddress+alias at domain.com > ) in your > > email address if you don't have a convenient one to use. Once > you set it > > up and assign collaborators, you can proceed with your regular > account. > > Okay. I'd personally really love to see something like organization > accounts (maybe comparable to how GitHub handles organizations) in the > future because I think this is a common use case. > > > Hi Tim, > > Good timing, we're exploring exactly this. :) There are a few options > under consideration, but all involve letting you treat organisation > members as collaborators on a snap. > > Of course we'll announce it here. If you start with a developer > account to hold your organisation identity, you'll be able to transfer > over when the time comes. From tim.sueberkrueb at web.de Fri Mar 17 18:13:45 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Fri, 17 Mar 2017 19:13:45 +0100 Subject: Contributing cloud parts Message-ID: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> Hey, what is the process of contributing a cloud part to https://wiki.ubuntu.com/snapcraft/parts (is it open for community contributions?)? Are there any plans for having a real parts repository instead of a wiki page for cloud parts? I think something like parts.snapcraft.io would be pretty cool :) All the best, Tim Süberkrüb From barry at ubuntu.com Fri Mar 17 21:25:03 2017 From: barry at ubuntu.com (Barry Warsaw) Date: Fri, 17 Mar 2017 17:25:03 -0400 Subject: Adventures in classic Python snaps, part II Message-ID: <20170317172503.3f5193cf@subdivisions.wooz.org> A few days I asked about classic snaps and problems I was having turning ubuntu-image into a classic snap (from devmode). For the recently released u-i 1.0 I thought I'd solved the problem, and had an autopkgtest to prove it. Since then I realized the problem was *not* solved and the autopkgtest had some dependency pollution that caused it to succeed when it should have failed. I've fixed that, but now I'm finding that classic Python snaps don't work -at least not in the way I'd expect. For reference, here's a baseline snapcraft.yaml that "works": -----snip snip----- name: ubuntu-image summary: Create Ubuntu images description: | Use this tool to create Ubuntu images. version: 1.0+snap2 grade: stable confinement: classic apps: ubuntu-image: command: usr/bin/ubuntu-image environment: PATH: $SNAP/usr/bin:$PATH parts: ubuntu-image: plugin: python source: . python-packages: - PyYAML - attrs - voluptuous prime: - usr - lib - sbin stage-packages: - e2fsprogs - mtools - python3-debian - python3-parted - util-linux - ubuntu-image snapd: plugin: go source: https://github.com/snapcore/snapd source-type: git go-importpath: github.com/snapcore/snapd prime: - bin/snap -----snip snip----- I was pointed to LP: #1670388 which helped me understand that I have to set $PATH (as seen in the `environment` section) so that the 'python3' found in the script's shebang is the one inside the snap, not the one in the system. That's good enough to not *also* require $PYTHONPATH afaict. This only works for Zesty; it fails in Yakkety and Xenial, presumably because of LP: #1665756. The bug says this is fixed in snapd 2.23, which is available atm only in zesty, yakkety-proposed, and xenial-proposed. There are a few other things to note. I don't think we need the snapd part. Isn't it guaranteed that if someone is running a classic snap, that /usr/bin/snap *must* be installed on their system? It does seem to work when I remove that part, but I want to make sure that autopktest package pollution isn't causing a false positive. There's one big cheat here. I had to put ubuntu-image in stage-packages because afaict, for classic snaps, the Python snapcraft plugin does not arrange for the ubuntu_image Python package to live in stage, and thus it doesn't get into prime. I don't think there's anything you could add to a `stage` section that would make that work. After experimenting (the documentation is unclear) files listed in stage are relative to the part's installation directory: modified snapcraft.yaml @@ -21,6 +21,8 @@ parts: - PyYAML - attrs - voluptuous + stage: + - stageme prime: - usr - lib Staging ubuntu-image [Errno 2] No such file or directory: '/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1/parts/ubuntu-image/install/stageme' root at autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1# find parts/ubuntu-image/install -name ubuntu_image root at autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1# ls parts/ubuntu-image/install/usr/lib/python3/dist-packages/ chardet _ped.cpython-35m-x86_64-linux-gnu.so chardet-2.3.0.egg-info pkg_resources deb822.py pyparted-3.10.7.egg-info debian python_debian-0.1.30.egg-info debian_bundle six-1.10.0.egg-info parted six.py You can see that the ubuntu_image package doesn't end up in the part's dist-packages, and there's nothing that can be staged. I haven't yet tried to play with scriptlets or other workaround. Obviously, we don't want to snap up the ubuntu-image that's in the archive, but instead the one in the current source directory. This seems like a bug, but I wanted to get some feedback before I filed a bug report. Cheers, -Barry -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From sergio.schvezov at canonical.com Fri Mar 17 22:51:56 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 17 Mar 2017 22:51:56 +0000 Subject: Adventures in classic Python snaps, part II In-Reply-To: <20170317172503.3f5193cf@subdivisions.wooz.org> References: <20170317172503.3f5193cf@subdivisions.wooz.org> Message-ID: On Fri, 17 Mar 2017 17:25:03 -0400, Barry Warsaw wrote: > A few days I asked about classic snaps and problems I was having turning > ubuntu-image into a classic snap (from devmode). For the recently released > u-i 1.0 I thought I'd solved the problem, and had an > autopkgtest to prove it. > Since then I realized the problem was *not* solved and the autopkgtest had > some dependency pollution that caused it to succeed when it should have > failed. I've fixed that, but now I'm finding that classic > Python snaps don't > work -at least not in the way I'd expect. > > For reference, here's a baseline snapcraft.yaml that "works": > > -----snip snip----- > name: ubuntu-image > summary: Create Ubuntu images > description: | > Use this tool to create Ubuntu images. > version: 1.0+snap2 > grade: stable > confinement: classic > > apps: > ubuntu-image: > command: usr/bin/ubuntu-image > > environment: > PATH: $SNAP/usr/bin:$PATH > > parts: > ubuntu-image: > plugin: python > source: . > python-packages: > - PyYAML > - attrs > - voluptuous > prime: > - usr > - lib > - sbin > stage-packages: > - e2fsprogs > - mtools > - python3-debian > - python3-parted > - util-linux > - ubuntu-image > snapd: > plugin: go > source: https://github.com/snapcore/snapd > source-type: git > go-importpath: github.com/snapcore/snapd > prime: > - bin/snap > -----snip snip----- > > I was pointed to LP: #1670388 which helped me understand that I have to set > $PATH (as seen in the `environment` section) so that the 'python3' found in > the script's shebang is the one inside the snap, not the one in the system. > That's good enough to not *also* require $PYTHONPATH afaict. We have a custom sitecustomize.py that takes care of the magic now. You don't need to set PATH though, alternatively in command you can do ``` command: /usr/bin/env $SNAP/usr/bin/python3 $SNAP/usr/bin/ubuntu-image ``` Next week I am going to be giving the python plugin some love. > This only works for Zesty; it fails in Yakkety and Xenial, > presumably because > of LP: #1665756. The bug says this is fixed in snapd 2.23, > which is available > atm only in zesty, yakkety-proposed, and xenial-proposed. Yes, this is the case. > There are a few other things to note. > > I don't think we need the snapd part. Isn't it guaranteed that > if someone is > running a classic snap, that /usr/bin/snap *must* be installed on their > system? It does seem to work when I remove that part, but I > want to make sure > that autopktest package pollution isn't causing a false positive. It can be in a different path though. > There's one big cheat here. I had to put ubuntu-image in stage-packages > because afaict, for classic snaps, the Python snapcraft plugin does not > arrange for the ubuntu_image Python package to live in stage, and thus it > doesn't get into prime. I don't think there's anything you could add to a > `stage` section that would make that work. After experimenting (the > documentation is unclear) files listed in stage are relative to the part's > installation directory: I don't understand this fully, but I am way past EOD so I will look with fresh eyes on monday, but is this exclusive to classic confinement? > modified snapcraft.yaml > @@ -21,6 +21,8 @@ parts: > - PyYAML > - attrs > - voluptuous > + stage: > + - stageme > prime: > - usr > - lib > > Staging ubuntu-image > [Errno 2] No such file or directory: > '/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1/parts/ubuntu-image/install/stageme' > > root at autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1# > find parts/ubuntu-image/install -name ubuntu_image > root at autopkgtest:/tmp/autopkgtest.LgVE5q/build.9QK/ubuntu-image-1.1+17.04ubuntu1# > ls parts/ubuntu-image/install/usr/lib/python3/dist-packages/ > chardet _ped.cpython-35m-x86_64-linux-gnu.so > chardet-2.3.0.egg-info pkg_resources > deb822.py pyparted-3.10.7.egg-info > debian python_debian-0.1.30.egg-info > debian_bundle six-1.10.0.egg-info > parted six.py > > You can see that the ubuntu_image package doesn't end up in the part's > dist-packages, and there's nothing that can be staged. It should end up in $SNAP/lib/site-packages if not using stage-packages. > I haven't yet tried to play with scriptlets or other workaround. Obviously, > we don't want to snap up the ubuntu-image that's in the archive, but instead > the one in the current source directory. > > This seems like a bug, but I wanted to get some feedback before > I filed a bug > report. -- Sent using Dekko from my Ubuntu device From joseph.wakeling at webdrake.net Fri Mar 17 23:32:38 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 00:32:38 +0100 Subject: Status of snapd on Arch Linux Message-ID: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> Hello folks, Is there anyone here working on snapd on Arch? I ask because I recently tried it out on a fresh Arch install and ran into some issues. Installing snaps works fine in itself, and snap list is able to find the installed snaps. However, these issues arose as soon as I started trying to use them: * snap --version lists 'unknown' for snap, snapd and arch * all snap-related stuff is placed in /var/lib/snapd/snap instead of /snap (fine in itself), but the PATH still contains /snap/bin rather than /var/lib/snapd/snap/bin. - according to https://wiki.archlinux.org/index.php/Snapd#Installing, installing a snap should cause it to be mounted to /snap/snapname but this doesn't appear to be happening * installing my ldc2 snap (`snap install --classic --candidate ldc2`) worked fine (it shows up in `snap list` as expected) but if I try to run /var/lib/snapd/snap/bin/ldc2 directly I get an error message: execv failed: No such file or directory * attempting to run the actual underlying binary within the snap, i.e. /var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other binaries there) results in a similar error message: -bash: ./ldc2: No such file or directory Running `file ldc2` on the binary reveals what I would assume is correct information: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /snap/core/current/lib/x86_64-linux/gnu/ld-2.23.so, for GNU/Linux 2.6.32, BuildID[sha1]=[I'm not typing this out], not stripped, with debug_info ... and uname -m gives x86_64, so I don't think it can be an issue like trying to run a 32-bit package on a 64-bit system (or vice versa). For comparison I tried installing both hello-world and Michael Hudson-Doyle's go snap. hello-world ran fine (but it is after all only a shell script underneath). The go snap ran into the same issues as my ldc2 snap. I assume these are known issues, but can anyone advise on what are the fundamental problems here and on whether it's expected to be addressed soon? Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Fri Mar 17 23:49:15 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 00:49:15 +0100 Subject: build.snapcraft.io and GitHub groups Message-ID: Hello all, I thought I'd give build.snapcraft.io a go for my ldc2 snap. Signing in was fine, and I was asked to give permission both for accessing my account and the ldc-developers group which I'm part of (where the ldc2 snap is managed). However, when being asked to choose a GitHub repo, I was presented only with repos from my own personal GitHub, and none belonging to ldc-developers -- so I couldn't add the official repo of the ldc2 snap. This was a little bit surprising given that I was explicitly asked to OK access by build.snapcraft.io to the ldc-developers group, so ... any chance this could be addressed? :-) Assuming it might not be soon, I assume the best option would be to use Launchpad as documented here: https://snapcraft.io/docs/build-snaps/ci-integration ... but is it possible to do this via a project registered on behalf of a team, instead of an individual user account? Thanks & best wishes, -- Joe From mark at ubuntu.com Sat Mar 18 00:29:28 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 17 Mar 2017 17:29:28 -0700 Subject: build.snapcraft.io and GitHub groups In-Reply-To: References: Message-ID: On 17/03/17 16:49, Joseph Rushton Wakeling wrote: > ... but is it possible to do this via a project registered on behalf > of a team, instead of an individual user account? It *should* be, so if it isn't, thanks for the bug report :) From manik at canonical.com Sat Mar 18 01:00:26 2017 From: manik at canonical.com (Manik Taneja) Date: Fri, 17 Mar 2017 18:00:26 -0700 Subject: build.snapcraft.io and GitHub groups In-Reply-To: References: Message-ID: On Fri, Mar 17, 2017 at 4:49 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello all, > > I thought I'd give build.snapcraft.io a go for my ldc2 snap. Signing in > was fine, and I was asked to give permission both for accessing my account > and the ldc-developers group which I'm part of (where the ldc2 snap is > managed). > > However, when being asked to choose a GitHub repo, I was presented only > with repos from my own personal GitHub, and none belonging to > ldc-developers -- so I couldn't add the official repo of the ldc2 snap. > > This was a little bit surprising given that I was explicitly asked to OK > access by build.snapcraft.io to the ldc-developers group, so ... any > chance this could be addressed? :-) > > Assuming it might not be soon, I assume the best option would be to use > Launchpad as documented here: > https://snapcraft.io/docs/build-snaps/ci-integration > > ... but is it possible to do this via a project registered on behalf of a > team, instead of an individual user account? > Yes, OpenHAB project is doing exactly that- https://code.launchpad.net/~openhab/openhab-snap/+git/master Cheers, Manik From loic.minier at ubuntu.com Sat Mar 18 01:10:47 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Sat, 18 Mar 2017 02:10:47 +0100 Subject: build.snapcraft.io and GitHub groups In-Reply-To: References: Message-ID: Hi! Support for Github orgs in build.snapcraft.io is still WIP: https://github.com/canonical-ols/build.snapcraft.io/issues/132 Cheers, - Loïc Minier On Sat, Mar 18, 2017 at 12:49 AM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello all, > > I thought I'd give build.snapcraft.io a go for my ldc2 snap. Signing in > was fine, and I was asked to give permission both for accessing my account > and the ldc-developers group which I'm part of (where the ldc2 snap is > managed). > > However, when being asked to choose a GitHub repo, I was presented only > with repos from my own personal GitHub, and none belonging to > ldc-developers -- so I couldn't add the official repo of the ldc2 snap. > > This was a little bit surprising given that I was explicitly asked to OK > access by build.snapcraft.io to the ldc-developers group, so ... any > chance this could be addressed? :-) > > Assuming it might not be soon, I assume the best option would be to use > Launchpad as documented here: > https://snapcraft.io/docs/build-snaps/ci-integration > > ... but is it possible to do this via a project registered on behalf of a > team, instead of an individual user account? > > 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 > -- - Loïc From cjwatson at ubuntu.com Sat Mar 18 01:42:19 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Sat, 18 Mar 2017 01:42:19 +0000 Subject: build.snapcraft.io and GitHub groups In-Reply-To: References: Message-ID: <20170318014219.GB28975@riva.ucam.org> On Sat, Mar 18, 2017 at 12:49:15AM +0100, Joseph Rushton Wakeling wrote: > I thought I'd give build.snapcraft.io a go for my ldc2 snap. Signing in was > fine, and I was asked to give permission both for accessing my account and > the ldc-developers group which I'm part of (where the ldc2 snap is managed). > > However, when being asked to choose a GitHub repo, I was presented only with > repos from my own personal GitHub, and none belonging to ldc-developers -- > so I couldn't add the official repo of the ldc2 snap. > > This was a little bit surprising given that I was explicitly asked to OK > access by build.snapcraft.io to the ldc-developers group, so ... any chance > this could be addressed? :-) As others have mentioned, this is definitely in our backlog. It's tricky to map the different models together in a way that doesn't end up locking people out just because (e.g.) a previous administrator of their GitHub organisation once created a snap for a repository and later deleted it, but I'm sure we'll get there in the end. (We actually don't intentionally ask for organisation access at the moment; I guess perhaps GitHub does that as part of admin:repo_hook? Anyway, it's immaterial since we'll need it eventually.) > Assuming it might not be soon, I assume the best option would be to use > Launchpad as documented here: > https://snapcraft.io/docs/build-snaps/ci-integration > > ... but is it possible to do this via a project registered on behalf of a > team, instead of an individual user account? The "Create a new snap package" page in Launchpad allows you to select an owner for the snap, which can be yourself or any team you're a member of. This will allow anyone in that team to modify that snap in Launchpad (including requesting builds of it). You still need to authorise this for upload to the snap store on behalf of an individual user, though: the store doesn't have an equivalent of organisations. It's possible (though I don't know the exact details) to add other team members as collaborators, allowing them to publish new versions of that snap too. Cheers, -- Colin Watson [cjwatson at ubuntu.com] From joseph.wakeling at webdrake.net Sat Mar 18 10:56:29 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 11:56:29 +0100 Subject: build.snapcraft.io and GitHub groups In-Reply-To: References: Message-ID: <1c9b795e-45d4-0de5-a96b-e39bd6c9a5c0@webdrake.net> On 18/03/17 01:29, Mark Shuttleworth wrote: > On 17/03/17 16:49, Joseph Rushton Wakeling wrote: >> ... but is it possible to do this via a project registered on behalf >> of a team, instead of an individual user account? > > It *should* be, so if it isn't, thanks for the bug report :) It's all working fine AFAICT, with the new ldc-developers team and a couple of snap package builds in the pipeline :-) From joseph.wakeling at webdrake.net Sat Mar 18 11:30:20 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 12:30:20 +0100 Subject: build.snapcraft.io and GitHub groups In-Reply-To: <20170318014219.GB28975@riva.ucam.org> References: <20170318014219.GB28975@riva.ucam.org> Message-ID: On 18/03/17 02:42, Colin Watson wrote: > As others have mentioned, this is definitely in our backlog. It's > tricky to map the different models together in a way that doesn't end up > locking people out just because (e.g.) a previous administrator of their > GitHub organisation once created a snap for a repository and later > deleted it, but I'm sure we'll get there in the end. That's great to hear. I have things set up with Launchpad for now in any case (which was a super-friendly experience). My builds seem to have run into git-clone issues related to my using `git://` urls instead of `https://`, but that should be straightforward enough to fix in the snap package definition ;-) > (We actually don't intentionally ask for organisation access at the > moment; I guess perhaps GitHub does that as part of admin:repo_hook? > Anyway, it's immaterial since we'll need it eventually.) Yes, I would guess that GitHub defaults to offering hooks into everything a user can access with the option to exclude certain groups from the offering. > The "Create a new snap package" page in Launchpad allows you to select > an owner for the snap, which can be yourself or any team you're a member > of. This will allow anyone in that team to modify that snap in > Launchpad (including requesting builds of it). > > You still need to authorise this for upload to the snap store on behalf > of an individual user, though: the store doesn't have an equivalent of > organisations. It's possible (though I don't know the exact details) to > add other team members as collaborators, allowing them to publish new > versions of that snap too. Yes, this is the approach I took, although it would be great at some point if snap packages in the store could have actual team ownership. Minor usability note on that: I added my 'regular' user account as a collaborator on the ldc2 snap, but have never uploaded using that account. The snap store insisted that I add a 'unique short namespace' to my account details and I was worried that would be used for the published snap instead of that of the account that really owns the package. Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Sat Mar 18 13:46:02 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 14:46:02 +0100 Subject: git clone and Launchpad build system Message-ID: Is there an issue with using git source for parts of snap packages when using the Launchpad build system? I'm having consistent build failures for this; originally I tried switching from `git://` URLS to `https://`, but I'm still seeing the same errors, see e.g. https://launchpadlibrarian.net/311390659/buildlog_snap_ubuntu_xenial_amd64_ldc2_BUILDING.txt.gz: Command '['git', 'clone', '--recursive', '--branch', 'v0.17.3', 'https://github.com/ldc-developers/ldc.git', '/build/ldc2/parts/ldc-bootstrap/src']' returned non-zero exit status 128 Traceback (most recent call last): File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 202, in main builder.pull() File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 139, in pull env=env) File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 92, in run_build_command self.chroot(["/bin/sh", "-c", command], echo=echo) File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 66, in chroot "/usr/bin/sudo", "/usr/sbin/chroot", self.chroot_path] + args) File "/usr/lib/python2.7/subprocess.py", line 541, in check_call raise CalledProcessError(retcode, cmd) CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-28577/chroot-autobuild', 'linux64', '/bin/sh', '-c', 'cd /build/ldc2 && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_SETUP_CORE=1 http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 Revoking proxy token... RUN: /usr/share/launchpad-buildd/slavebin/scan-for-processes ['scan-for-processes', 'SNAPBUILD-28577'] Scanning for processes to kill in build /home/buildd/build-SNAPBUILD-28577/chroot-autobuild... RUN: /usr/share/launchpad-buildd/slavebin/umount-chroot ['umount-chroot', 'SNAPBUILD-28577'] Unmounting chroot for build SNAPBUILD-28577... RUN: /usr/share/launchpad-buildd/slavebin/remove-build ['remove-build', 'SNAPBUILD-28577'] The corresponding part of the snapcraft.yaml: https://github.com/ldc-developers/ldc2.snap/blob/da18a99f4c66c219b4cf9d06b4087a5fe9acce79/snap/snapcraft.yaml#L53-L55 ldc-bootstrap: source: https://github.com/ldc-developers/ldc.git source-tag: v0.17.3 From loic.minier at ubuntu.com Sat Mar 18 16:43:38 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Sat, 18 Mar 2017 17:43:38 +0100 Subject: Triggering CI/snap builds on changes to snapcraft parts Message-ID: Hi! Currently, setting up a snap build from a git branch in Launchpad or via build.snapcraft.io is a pleasure, and this allows for an easy CI whenever a change is pushed to the repo. But non-trivial projects have multiple components to build to deliver the snap, with chains of build-deps. What's the best practice to trigger snap builds/CI builds when changes are pushed to build-dependencies / parts of a snap? Should there be a way to parse part sources in snapcraft.yaml and check whether these have changed? Thanks! - Loïc Minier From joseph.wakeling at webdrake.net Sat Mar 18 20:28:19 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 21:28:19 +0100 Subject: git clone and Launchpad build system In-Reply-To: References: Message-ID: <61a6d918-e5de-1790-d79e-3a3b20a852b8@webdrake.net> On 18/03/17 14:46, Joseph Rushton Wakeling wrote: > Is there an issue with using git source for parts of snap packages when using > the Launchpad build system? I'm having consistent build failures for this; > originally I tried switching from `git://` URLS to `https://`, but I'm still > seeing the same errors, see e.g. > https://launchpadlibrarian.net/311390659/buildlog_snap_ubuntu_xenial_amd64_ldc2_BUILDING.txt.gz: Still failing despite updating to make sure the `source-type` is explicitly specified as git. The same snap package builds fine for me with a `snapcraft cleanbuild`. I'm a bit baffled here because I compared to the openhab snap, which also uses git source and seems to build fine in Launchpad: https://git.launchpad.net/~openhab/openhab-snap/+git/master/tree/snapcraft.yaml From gregory.lutostanski at canonical.com Sat Mar 18 21:11:08 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Sat, 18 Mar 2017 16:11:08 -0500 Subject: git clone and Launchpad build system In-Reply-To: <61a6d918-e5de-1790-d79e-3a3b20a852b8@webdrake.net> References: <61a6d918-e5de-1790-d79e-3a3b20a852b8@webdrake.net> Message-ID: Launchpad builders have an issue with git where they do not proxy that connection, only https. Here the issue is that that github repo has submodules specified with the git: url schema (and its doing a recursive checkout of the source). The bug is https://bugs.launchpad.net/launchpad-buildd/+bug/1663920 As a workaround you can change the submodules to https: rather than git: annoying indeed, that is what I had to go with personally. Dunno if anybody else has other ideas. --Greg On Sat, Mar 18, 2017 at 3:28 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 18/03/17 14:46, Joseph Rushton Wakeling wrote: > >> Is there an issue with using git source for parts of snap packages when >> using >> the Launchpad build system? I'm having consistent build failures for >> this; >> originally I tried switching from `git://` URLS to `https://`, but I'm >> still >> seeing the same errors, see e.g. >> https://launchpadlibrarian.net/311390659/buildlog_snap_ubunt >> u_xenial_amd64_ldc2_BUILDING.txt.gz: >> > > Still failing despite updating to make sure the `source-type` is > explicitly specified as git. The same snap package builds fine for me with > a `snapcraft cleanbuild`. > > I'm a bit baffled here because I compared to the openhab snap, which also > uses git source and seems to build fine in Launchpad: > https://git.launchpad.net/~openhab/openhab-snap/+git/master/ > tree/snapcraft.yaml > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > From joseph.wakeling at webdrake.net Sat Mar 18 21:11:36 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 22:11:36 +0100 Subject: git clone and Launchpad build system In-Reply-To: <61a6d918-e5de-1790-d79e-3a3b20a852b8@webdrake.net> References: <61a6d918-e5de-1790-d79e-3a3b20a852b8@webdrake.net> Message-ID: <6dc36bf0-ff18-40cf-1a2d-fbe7f4238cfa@webdrake.net> On 18/03/17 21:28, Joseph Rushton Wakeling wrote: > On 18/03/17 14:46, Joseph Rushton Wakeling wrote: >> Is there an issue with using git source for parts of snap packages when using >> the Launchpad build system? I'm having consistent build failures for this; >> originally I tried switching from `git://` URLS to `https://`, but I'm still >> seeing the same errors, see e.g. >> https://launchpadlibrarian.net/311390659/buildlog_snap_ubuntu_xenial_amd64_ldc2_BUILDING.txt.gz: >> > > Still failing despite updating to make sure the `source-type` is explicitly > specified as git. The same snap package builds fine for me with a `snapcraft > cleanbuild`. A look a bit further back in the build log reveals what I think may be the problem: the submodules of one of the git repositories have their URLs specified using `git://` URLs: Submodule 'druntime' (git://github.com/ldc-developers/druntime.git) registered for path 'runtime/druntime' Submodule 'phobos' (git://github.com/ldc-developers/phobos.git) registered for path 'runtime/phobos' Submodule 'tests/d2/dmd-testsuite' (git://github.com/ldc-developers/dmd-testsuite.git) registered for path 'tests/d2/dmd-testsuite' Cloning into 'runtime/druntime'... fatal: unable to connect to github.com: github.com: Name or service not known fatal: clone of 'git://github.com/ldc-developers/druntime.git' into submodule path 'runtime/druntime' failed Are `git://` URLS genuinely not supported by the launchpad build system? And if so, is there a chance this could be addressed? From joseph.wakeling at webdrake.net Sat Mar 18 21:34:36 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 18 Mar 2017 22:34:36 +0100 Subject: git clone and Launchpad build system In-Reply-To: References: <61a6d918-e5de-1790-d79e-3a3b20a852b8@webdrake.net> Message-ID: <40739335-0779-4cb8-8b95-b3f88581e629@webdrake.net> On 18/03/17 22:11, Gregory Lutostanski wrote: > Launchpad builders have an issue with git where they do not proxy that > connection, only https. Here the issue is that that github repo has > submodules specified with the git: url schema (and its doing a recursive > checkout of the source). > > The bug is https://bugs.launchpad.net/launchpad-buildd/+bug/1663920 Ah, cheers. I'd looked through the bug list and seen that one, but not realized the submodules were using `git://` URLs until just before your email arrived. > As a workaround you can change the submodules to https: rather than git: > annoying indeed, that is what I had to go with personally. Dunno if anybody > else has other ideas. Yup. It's a bit finnicky for me to do that given that the submodules are defined by my upstream (I can send them a patch, but it's a PITA to ask them to make a patch release just to deal with this issue). I did look into just downloading a tarball of the source, but that has some issues of its own -- since the CMakeLists.txt of the project I'm building defines some rules for comparing the version number against the output of `git describe`, I run into some rather nasty issues where the git history compared to is that of the snap package itself (!). I'll follow up with my upstream and see what I can do, anyway. Thanks again for the help and advice! From tiago.herrmann at canonical.com Sun Mar 19 14:50:54 2017 From: tiago.herrmann at canonical.com (Tiago Herrmann) Date: Sun, 19 Mar 2017 11:50:54 -0300 Subject: FreePBX snap Message-ID: Hey guys, Over the past few weeks I have been working on a FreePBX snap in my spare time. My motivation is that I have a raspberry pi at home running asterisk for about 2 years now, and would like to switch to ubuntu core at some point. I used the nextcloud snap as a starting point and finally got the basic features working. (Access to the web administration interface, create extensions, make calls, and access to the voicemail) https://github.com/tiagosh/freepbx-snap After installing the snap, FreePBX will be available at http://127.0.0.1/admin/index.php I had to workaround a couple of things to get all the pieces confined (asterisk and freepbx mainly), so I will report some of them here. I am still learning snap so I bet there are better ways to do it. 1) Asterisk running fine right after snap installation, but failing afterwards. After a lot of debugging I figured asterisk was crashing with SIGSYS, and found that the asterisk binary tries to call chown(), setgid() and other syscalls that are only allowed during installation (which explains the behavior I was seeing). My workaround was to add these calls to the snacraft-preload part that Sergio wrote and preload asterisk with it. These calls always return success for now just to keep asterisk happy. If you guys know a better way to workaround it, I would be happy to remove this hack. 2) Asterisk crashes trying to acess alsa directly. I found this alsa wrapper from Jamie, and it fixed the crash: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5 3) Hardcoded paths in FreePBX. I had to manually change most of the code to prepend a prefix to the paths. The prefix is retrieved from an environment variable that is exported in the wrapper scripts. The modified code is temporarily hosted in my github and retrieved as a remote part. 4) Asterisk configuration files moved to $SNAP_DATA. While this could become a security issue, freepbx has to overwrite asterisk configuration files in runtime. I did not find a better way to do it so far. 5) Long time to get the FreePBX fully installed/available. During the first launch I am running the FreePBX installation scripts. Sometimes it can take up to 5 minutes to get everything in place and to get the web administration tool available. 6) FreePBX signs all files and prints in the UI a security warning informing the admin if any file is different from upstream. For now the web administration interface shows a security warning showing all files I changed to make it work as a snap. It won't impact the functionality, but maybe I will need to find some way to re-sign all files. 7) CDR reports still not working. This needs further investigation. 8) I have been testing this snap only on amd64. I quickly tested it on arm64 a few weeks ago and asterisk failed to run. Fixing this issue is my next priority for now. Any help would be appreciated. Thank you Tiago From ogra at ubuntu.com Sun Mar 19 21:41:26 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Sun, 19 Mar 2017 22:41:26 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: , Message-ID: <1489959686.29433.9.camel@ubuntu.com> hi, On Fr, 2017-03-17 at 12:18 +0000, Sunny Bhayani wrote: >  > The above log has two trial logs. In the First trial, we have > prepared the  > SDCard and have setup the first boot console config. In the Second > trial,   > we did "snap login". > > We obsereved that whenever we do a "snap install", irrespective of > it  > being successful or fail, we get the below message repeatedly and > the  > board reboots automatically after 15-20 minutes:  > >     "Broadcast message from root at localhost.localdomain (Thu 2017-03- > 16 12:31:13 UTC): ... > > It would be great, if you can provide any comments. > the image has not properly being initialized ... else you would only get the reboot notifications after the first upgrade of the core snap (i.e. your root filesystem)... normally a "snap list" should list the gadget (dragonboard), core and the kernel snap (ubuntu-snapdragon-kernel) you described in your model assertion, even before you installed anything. > > How are you building the image that you are booting?  > > Here are the steps to building Ubuntu-Core Image: http://pastebin.com > /0x52ATXi >  ...and here we have your issue... you need to use a proper authority id and brand id in your assertion file, else the initial setup (before console-conf) will not happen, you used the:  "authority-id": "", "brand-id": "", boilerplate values in your json file ... you can get the data for your auth-id from your account info via: https://myapps.developer.ubuntu.com/dev/account/ ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From michael.hudson at canonical.com Mon Mar 20 00:37:36 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Mon, 20 Mar 2017 13:37:36 +1300 Subject: Part 2! Request for help / ideas to debug issue In-Reply-To: References: Message-ID: On 14 March 2017 at 23:56, John Lenton wrote: > As a followup, I added a mutex around pthread_create, and around the > exec syscall, and the problem went away. This all in go's runtime; not > a huge diff but they probably don't want the overhead (and that seems > reasonable to me). > Next I'm going to try to find a kernel person to take a look at this. > Having looked at the kernel a bit, I'm not sure that a mutex is that crazy an idea :-) Does it impact performance in any noticeable way? clone is fairly expensive I guess and Go programs only run ~GOMAXPROCS OS threads anyway. Would be interested in what any proper people you can round up would have to say though. Cheers, mwh From sunny.bhayani at einfochips.com Mon Mar 20 06:04:26 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Mon, 20 Mar 2017 06:04:26 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <1489959686.29433.9.camel@ubuntu.com> References: , , <1489959686.29433.9.camel@ubuntu.com> Message-ID: Hi Oliver, Thank you for your reply. > hi, > the image has not properly being initialized ... else you would only > get the reboot notifications after the first upgrade of the core snap > (i.e. your root filesystem)... > > normally a "snap list" should list the gadget (dragonboard), core and > the kernel snap (ubuntu-snapdragon-kernel) you described in your model > assertion, even before you installed anything. > We are not getting the above three snaps listed even though we get through the initial conf setup. So can you point to a possible error ? > > > How are you building the image that you are booting? > > > > Here are the steps to building Ubuntu-Core Image: http://pastebin.com > > /0x52ATXi > > > > ...and here we have your issue... > > you need to use a proper authority id and brand id in your assertion > file, else the initial setup (before console-conf) will not happen, you > used the: > > "authority-id": "", > "brand-id": "", > > boilerplate values in your json file ... > > you can get the data for your auth-id from your account info via: > > https://myapps.developer.ubuntu.com/dev/account/ > We are populating the "authority-id" and "brand-id" fields in the json file from the above link that you have mentioned i.e. https://myapps.developer.ubuntu.com/dev/account/ The "authority-id" field and "brand-id" is populated as "Account-Id" found in the above link which is a 32-letter (Alpha-numeric). Please do let us know if we are missing anything. Also, as you mentioned that without proper authority id and brand id in the assertion file, initial setup (before console-conf) will not happen. But we are able to do the initial setup (profile setup) and then we get the shell prompt. So can the initial setup be done if assertion model is not correct ? If possible, this is to request you that if you can build the xenial sources (branch "snapdragon") once and check if you are facing these errors like we are ? We had only changed the snapcraft.yaml to get the dtb and firmware built. 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 didrocks at ubuntu.com Mon Mar 20 08:42:24 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Mon, 20 Mar 2017 09:42:24 +0100 Subject: Contributing cloud parts In-Reply-To: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> Message-ID: <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : > Hey, Hey Tim, > > what is the process of contributing a cloud part to > https://wiki.ubuntu.com/snapcraft/parts (is it open for community > contributions?)? > > Are there any plans for having a real parts repository instead of a > wiki page for cloud parts? I think something like parts.snapcraft.io > would be pretty cool :) > There isn't any process as of now AFAIK. It is open for community contributions, so feel free to edit the wiki page adding your awesome cloud part :) snapcraft update && snapcraft search should list your part within the next hour (the importer runs hourly AFAIK). I agree some way to see/check metrics on parts popularity, getting user's feedback and such would be pretty cool! Cheers, Didier From ogra at ubuntu.com Mon Mar 20 09:55:24 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Mar 2017 10:55:24 +0100 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: References: , ,<1489959686.29433.9.camel@ubuntu.com> Message-ID: <1490003724.10484.35.camel@ubuntu.com> hi, Am Montag, den 20.03.2017, 06:04 +0000 schrieb Sunny Bhayani: > Hi Oliver, > > Thank you for your reply. > > > hi, > > the image has not properly being initialized ... else you would > only > > get the reboot notifications after the first upgrade of the core > snap > > (i.e. your root filesystem)... > >  > > normally a "snap list" should list the gadget (dragonboard), core > and > > the kernel snap (ubuntu-snapdragon-kernel) you described in your > model > > assertion, even before you installed anything. > >  > We are not getting the above three snaps listed even though we get > through  > the initial conf setup. So can you point to a possible error ? yes, the broken assertion file will prevent the verification of the snaps in the firstboot setup. this happens during first boot way before you can interact with the system. it will then (amongst other things) add these snaps to the state.json file (which is why john asked for the content i guess). >  > We are populating the "authority-id" and "brand-id" fields in the > json file  > from the above link that you have mentioned i.e. > https://myapps.developer.ubuntu.com/dev/account/ > > The "authority-id" field and "brand-id" is populated as "Account-Id" > found  > in the above link which is a 32-letter (Alpha-numeric). > > Please do let us know if we are missing anything. with that it should work if the account the assertion gets signed with is identical to the one in the store  > > Also, as you mentioned that without proper authority id and brand id > in the  > assertion file, initial setup (before console-conf) will not happen. > But we are  > able to do the initial setup (profile setup) and then we get the > shell prompt. > > So can the initial setup be done if assertion model is not correct ? yes, this is probably a usability bug a failed firstboot configuration should at least spill a readable error or show it failed in the console-conf UI. > > If possible, this is to request you that if you can build the xenial > sources (branch "snapdragon") > once and check if you are facing these errors like we are ? > > We had only changed the snapcraft.yaml to get the dtb and firmware > built. i'm a bit short on time this week but i'll see what i can do :) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From evan.dandrea at canonical.com Mon Mar 20 10:37:57 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Mon, 20 Mar 2017 10:37:57 +0000 Subject: Triggering CI/snap builds on changes to snapcraft parts In-Reply-To: References: Message-ID: Do you need better than day-level resolution? If not, I'd suggest using Travis' cron feature to create nightly builds: https://docs.travis-ci.com/user/cron-jobs/ From sunny.bhayani at einfochips.com Mon Mar 20 10:51:52 2017 From: sunny.bhayani at einfochips.com (Sunny Bhayani) Date: Mon, 20 Mar 2017 10:51:52 +0000 Subject: [Dragonboard410c] Ubuntu OS Build Issues, and Support In-Reply-To: <1490003724.10484.35.camel@ubuntu.com> References: , ,<1489959686.29433.9.camel@ubuntu.com> , <1490003724.10484.35.camel@ubuntu.com> Message-ID: Hi Oliver, Thank you for your reply. > with that it should work if the account the assertion gets signed with > is identical to the one in the store We sign the assertion-model by the below command: cat dragon-model.json | snap sign -k sh &> dragonboard.model Is there a way where in we can check if the "snap sign" command failed ? > yes, this is probably a usability bug a failed firstboot configuration > should at least spill a readable error or show it failed in the > console-conf UI. Please advice if we can check any logs for this failure ? > 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). 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 alan.pope at canonical.com Mon Mar 20 10:52:52 2017 From: alan.pope at canonical.com (Alan Pope) Date: Mon, 20 Mar 2017 10:52:52 +0000 Subject: Status of snapd on Arch Linux In-Reply-To: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> Message-ID: Hi Joseph, On 17 March 2017 at 23:32, Joseph Rushton Wakeling wrote: > I ask because I recently tried it out on a fresh Arch install and ran into > some issues. > I tested on a VM of Antergos I have here, and confirmed all your findings. Thanks for raising the issue. Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From ogra at ubuntu.com Mon Mar 20 12:26:40 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Mar 2017 13:26:40 +0100 Subject: How to convert the initrd.img during buiding the kernel snap. In-Reply-To: References: Message-ID: <1490012800.29433.12.camel@ubuntu.com> hi, On Do, 2017-03-16 at 21:22 +0800, Madper Xie wrote: > Hi all, > > My u-boot do not support the format of the initrd.img. So I need to > manually convert it via mkimage every time. > > I tried to use scriptlet to convert the initrd.img file but failed. > > ``` >     install: | >       mkimage -n 'RamdiskImage' -A arm -O linux -T ramdisk -C gzip -d > initrd.img ramfs.img >       rm initrd.img > ``` > > I got: > mkimage: Can't open initrd.img: No such file or directory > rm: cannot remove 'initrd.img': No such file or directory > > It seems the scriptlet executed before downloading the initrd.img. > Do we have any way to run a command after downloading the initrd.img? >  please fix your u-boot instead, one of the required uboot config options we have is: #define CONFIG_SUPPORT_RAW_INITRD in your include/configs/.h file ... the others are: #define CONFIG_ENV_IS_IN_FAT #define CONFIG_SYS_REDUNDAND_ENVIRONMENT and  #define CONFIG_ENV_SIZE                        SZ_128K to make the rollback function work. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Mar 20 12:33:44 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Mar 2017 13:33:44 +0100 Subject: Best Practice for building modules and including them in Kernel Snap In-Reply-To: References: Message-ID: <1490013224.29433.13.camel@ubuntu.com> hi, On Mi, 2017-03-15 at 12:29 -0700, Luke Williams wrote: > Hello, > > What are the best practices for building and including kernel modules > with > kernel snaps? > > Prior to snapcraft 2.25, when building kernel snaps, the modules > would be > located in parts/kernel/install/lib/modules// so that if > I > needed to add custom modules, I could put them in this path and then > run > depmod -a -b parts/kernel/install/ and it would update > the > modules dependancies and symbols and then I could run snapcraft snap > and > package everything up. > > Now that the modules and firmware directories fall under > parts/kernel/install the depmod -b doesn't work anymore. > > What I have done to make this work is I create a symlink to install > as lib > and then I can run the depmod command, then I remove the lib symlink > and > then run snapcraft snap and everything is good. > > This seems kind of kludgy and not the right way to do this. Is there > a > recommended way that this should be handled? > >  i suspect the symlink is the best workaround today unless you want to patch depmod :) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Mon Mar 20 12:37:01 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 20 Mar 2017 13:37:01 +0100 Subject: Netplan replug function is incompatible with ath9k_htc module In-Reply-To: References: Message-ID: <1490013421.29433.16.camel@ubuntu.com> hi, On Di, 2017-03-14 at 11:29 +0100, Loïc Minier wrote: >  > (So you want to test an updated netplan binary.) > > How can we repack a core snap with different code per netplan? add netplan to a PPA you own ... branch https://github.com/snapcore/core edit the Makefile and add an entry for your PPA to teh EXTRA_PPAS variable at "ENV" line ... run "sudo snapcraft" in the top level of your cloned dir... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From mrsingh at ssni.com Fri Mar 17 22:51:39 2017 From: mrsingh at ssni.com (Mritunjai Singh) Date: Fri, 17 Mar 2017 22:51:39 +0000 Subject: bluepy-helper not being built using Message-ID: Kindly confirm if anyone has got sensortag snap[https://github.com/mectors/sensortag] working on Raspberry Pi Board with Ubuntu Core as I am struggling to make it work using snap as that snap is not building the bluepy-helper. Can anyone suggest the alternative approach to resolve the issue. Any help will be appreciated. Regards, Mritunjai From: Mritunjai Singh Sent: Wednesday, March 15, 2017 1:15 PM To: 'Snapcraft at lists.snapcraft.io' Subject: bluepy-helper not being built using Hello, I am trying to use the sensortag snap available on github [https://github.com/mectors/sensortag] to get the data from TI sensor and posting these sensor data to cloud using our proprietary SDK APIs. I am successfully able to build and install the sensortag snap and also connected the snap to bluetooth-control to make sure that the snap has bluetooth-control. I am following the README.md available with the snap. - Build and install of the sensortag snap successful. - sensortag.sensortag-init 7C:01:91:72:63:32 successful - sensortag.sensortag-in giving error messages shown below: Traceback (most recent call last): File "/snap/sensortag/x1/bin/sensortag", line 11, in sys.exit(main()) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 416, in main tag = SensorTag(arg.host) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 331, in __init__ Peripheral.__init__(self,addr) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 318, in __init__ self.connect(deviceAddr, addrType, iface) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 353, in connect self._startHelper() File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 210, in _startHelper universal_newlines=True) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 947, in __init__ restore_signals, start_new_session) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child raise child_exception_type(errno_num, err_msg) FileNotFoundError: [Errno 2] No such file or directory: '/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/bluepy-helper' After some research it looks like that snap is not able to build the the "sensortag/parts/bluepy/buildbluepy-helper.c" and thus the bluepy-helper object is not created during the install of bluepy. I can see that there is a bluepy-helper.c file but no object. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluez-5.29 btle.py __init__.py __pycache__ uuids.json If I run make manually within the folder the objects are created. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluepy-helper bluez-5.29 btle.py __init__.py __pycache__ uuids.json Compiling bluepy-helper works as expected but it is not copied to the build directory and thus not installed. It seems to be known issue as shown in links below: https://github.com/IanHarvey/bluepy/issues/158 https://github.com/IanHarvey/bluepy/issues/139 Can anyone help me resolve this issue. Regards, Mritunjai From ernestp at dafstb.de Sun Mar 19 14:21:05 2017 From: ernestp at dafstb.de (Mr. Ernest Pinto) Date: Sun, 19 Mar 2017 07:21:05 -0700 Subject: Private Placement Message-ID: Good day, Welcome to our Private Placement Portfolio. I am a Staff of a Venture Capital Firm specializing in Growth Capital Investments/Loans.We seek to invest in Projects with Public and Private sectors in a broad range of areas including Real estate, Agriculture, Energy, Oil and Gas, emerging markets and high-technology. Within the technology sector, the firm focuses on communications, software, digital content and services. We have the capacity to invest a considerable amount of funds in any viable project(s) that your company requires funding for on an investment capacity/Loan Application. Upon the review of your company's Project Business Plan we shall determine on the project(s) possible funding. This will be form of a silent and Private Placement Investments. Endeavor to respond promptly if the investment proposal meets your company's approval. Kind Regards, Ernest Pinto From kornelix at posteo.de Sat Mar 18 10:56:54 2017 From: kornelix at posteo.de (Mike Cornelison) Date: Sat, 18 Mar 2017 11:56:54 +0100 Subject: Fotoxx snap package Message-ID: Apparently more complex than your tutorial. Any help on this? Here is my .yaml file and the result when trying to execute the snap. --------------------------------------------------------------------------------------- name: fotoxx-snap version: '17.04' summary: edit photos and manage a large collection description: | Survey a large image collection using a thumbnail browser and navigator. etc. grade: devel confinement: devmode parts: main: source: /home2/mico/programs/fotoxx/packs/fotoxx-17.04.tar.gz plugin: make apps: fotoxx-snap: command: usr/bin/fotoxx ------------------------------------------------------------------------------- fotoxx-17.04 initz. clutter and GTK ... (process:4083): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. Gtk-Message: Failed to load module "unity-gtk-module" (fotoxx:4083): GdkPixbuf-WARNING **: Cannot open pixbuf loader module file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory This likely means that your installation is broken. Try running the command gdk-pixbuf-query-loaders > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache to make things work again for the time being. Gtk-Message: Failed to load module "canberra-gtk-module" Gtk-Message: Failed to load module "canberra-gtk-module" (fotoxx:4083): Clutter-WARNING **: Locale not supported by C library. Using the fallback 'C' locale. (fotoxx:4083): Clutter-CRITICAL **: Unable to initialize Clutter: Unable to initialize the Clutter backend: no available drivers found. fotoxx-snap $: ------------------------------------------------------------------------------- Here are the debian package dependencies: Depends: libimage-exiftool-perl, libc6, libchamplain-gtk-0.12-0, libclutter-gtk-1.0-0 ----------------------------------------------------------------------------------- Question: why not make a snap package automatically from a debian package? All the needed information is present, it seems. Referenced libraries can be obtained from the executable. From loic.minier at ubuntu.com Mon Mar 20 13:21:21 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Mon, 20 Mar 2017 14:21:21 +0100 Subject: udev rules Message-ID: Hi! I saw a couple of software pieces that rely on udev rules to work; I guess these use cases need design to be supported in snaps; I wanted to share some specifics below. 1) aksusbd is a Gemalto daemon to assert presence of a license USB dongle; it requires USB access, and also these udev rules that call binaries on addition/removal of devices and create /dev symlinks: http://www.feflow.info/download/FEFLOW/linux/dongle-2.41/linux_dinst/hasp.rules This is a dependency of e.g. Quortus EPC (4G core network). It could be delivered as a part or more likely as a separate snap since Quortus can operate in different modes. 2) LimeSDR is SDR hardware that comes in USB and PCI form-factor. It might be used from desktop apps, e.g. Gqrx is a spectrum exploration tool and typically a desktop app that runs as non-root. This is the set of udev rules that upstream recommends installing: https://github.com/myriadrf/LimeSuite/blob/master/udev-rules/64-limesuite.rules These two use cases (triggering commands when devices are plugged / unplugged and granting permissions to desktop users to a new /dev node) don't seem possible right now. I think the former is probably covered in hotplugging requirements, not sure about the latter. Perhaps I should add these to some existing design doc? Thanks, - Loïc Minier From george.kraft at canonical.com Mon Mar 20 14:45:43 2017 From: george.kraft at canonical.com (George Kraft) Date: Mon, 20 Mar 2017 09:45:43 -0500 Subject: Snap tracks for Kubernetes Message-ID: Hey folks, We're working on a collection of snaps for Kubernetes that we'd like to have tracks added to: - kubectl - kube-apiserver - kube-controller-manager - kube-scheduler - kubelet - kube-proxy - cdk-addons All of these need tracks for 1.5, 1.6, and 1.7. Can someone create these for us? Thanks! George From daniel.manrique at canonical.com Mon Mar 20 15:21:07 2017 From: daniel.manrique at canonical.com (Daniel Manrique) Date: Mon, 20 Mar 2017 11:21:07 -0400 Subject: Snap tracks for Kubernetes In-Reply-To: References: Message-ID: On Mon, Mar 20, 2017 at 10:45 AM, George Kraft wrote: > Hey folks, > > We're working on a collection of snaps for Kubernetes that we'd like to > have tracks added to: > - kubectl > - kube-apiserver > - kube-controller-manager > - kube-scheduler > - kubelet > - kube-proxy > - cdk-addons > > All of these need tracks for 1.5, 1.6, and 1.7. Can someone create these > for us? Hello George, I've created all 21 tracks (3 each for your 7 snaps). They should be usable now. Do let me know if anything looks odd. I can also add a "version pattern" as a mild preventive measure against releasing a snap under the wrong track. This is a regex which will be matched against your upload's "version" value and if it doesn't match, releasing to that track will not be allowed. This helps humans avoid mistakenly releasing a snap in an undesired track/channel. Let me know if you find this useful and I can set it up for you. Cheers, - Daniel > > Thanks! > George > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From janekolszak at gmail.com Mon Mar 20 15:23:37 2017 From: janekolszak at gmail.com (Jan Olszak) Date: Mon, 20 Mar 2017 16:23:37 +0100 Subject: Connecting snap to keyring Message-ID: Hi there! Is there anything like "Secret Service" interface? An interface to gnome-keyring or maybe any other keyring? Thanks, Jan From kyle.fazzari at canonical.com Mon Mar 20 15:53:21 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 20 Mar 2017 08:53:21 -0700 Subject: systemd-resolved and snaps In-Reply-To: <20170223222628.rmu2ukrmez3sfeay@virgil.dodds.net> References: <3623545f-b2e3-bf3a-bb9c-6df763b57c02@canonical.com> <20170223222628.rmu2ukrmez3sfeay@virgil.dodds.net> Message-ID: On 02/23/2017 02:26 PM, Steve Langasek wrote: > Hi Kyle, > > On Thu, Feb 23, 2017 at 01:58:07PM -0800, Kyle Fazzari wrote: >> Hey all. > >> I've received a bug report on a snap where the user was running a 16.10 >> Server install with the snap in question, and getting DNS errors. I've >> distilled the problem as much as I can but I cannot for the life of me >> figure out what's happening, so I thought maybe the list could point me >> in the right direction. > >> Prerequisites >> ============= >> >> I have a demo snap (a standalone snapcraft.yaml) that will demonstrate >> this issue[1]. >> >> Ubuntu 16.10 Server uses systemd-resolved, which means its >> /etc/resolv.conf contains a single nameserver: >> >> nameserver 127.0.0.53 >> >> If you have others there, comment them out for the time being. >> >> >> Steps to reproduce >> ================== >> >> 1. Build and install the `resolved-test` snap[1]. It exposes two apps, >> `test` (which is a python2 script uses the requests lib) and `host` >> which is just the `host` utility from bind9-host. >> >> 2. With 127.0.0.53 as the only nameserver, run `resolved-test.test`. >> Note that it fails with "Name or service not known." > > acme-staging.api.letsencrypt.org is a CNAME. You are hitting bug #1647031, > which we encountered when trying to roll out systemd-resolved by default for > 17.04. This took a while to work through, but the fix has finally landed in > zesty as of a week ago; we should now SRU the upstream change back to > yakkety. (We should also SRU it back to xenial, but xenial needs a more > complete backport of fixes to resolved, not just a cherry-pick of this one > fix.) > > Dimitri, could you handle this backport to yakkety? Since unlike the > Desktop, Ubuntu Server does not use dnsmasq by default (which would override > resolved), this is a rather important bug there. Hey guys, this still seems to be an issue for Yakkety. Any idea of the timeframe we're looking at for this SRU? -- 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 kyle.fazzari at canonical.com Mon Mar 20 16:07:32 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 20 Mar 2017 09:07:32 -0700 Subject: Connecting snap to keyring In-Reply-To: References: Message-ID: <50dfb55d-ca70-a1fb-1711-20447cc1dae0@canonical.com> On 03/20/2017 08:23 AM, Jan Olszak wrote: > Hi there! > Is there anything like "Secret Service" interface? An interface to > gnome-keyring or maybe any other keyring? Not yet[1]. If you're by any chance familiar with that API, I doubt the interface would be difficult to write. [1]: https://bugs.launchpad.net/snapd/+bug/1653769 -- 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 mhall119 at ubuntu.com Mon Mar 20 18:14:56 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Mon, 20 Mar 2017 14:14:56 -0400 Subject: Fotoxx snap package In-Reply-To: References: Message-ID: It sounds like you probably want to use the desktop-gtk3 helper part, it will pull in all the necessary dependencies for a Gtk3 app, plus give you a desktop-launch script that will setup any needed paths or environment variables for your app to run. Here's an article that explains what desktop helpers are and how to use them: https://insights.ubuntu.com/2016/07/06/ubuntu-app-developer-blog-announcing-new-snap-desktop-launchers/ The tl;dr is this: 1) add "after: [desktop-gtk3]" to the end of your main part 2) Change your app's command to "desktop-launch usr/bin/fotoxx" If that doesn't fix it all for you, join us on rocket.ubuntu.com to get realtime help in the #snapcraft channel. Michael Hall mhall119 at ubuntu.com On 03/18/2017 06:56 AM, Mike Cornelison wrote: > Apparently more complex than your tutorial. Any help on this? > > Here is my .yaml file and the result when trying to execute the snap. > > --------------------------------------------------------------------------------------- > > name: fotoxx-snap > version: '17.04' > summary: edit photos and manage a large collection > description: | > Survey a large image collection using a thumbnail browser and > navigator. > etc. > grade: devel > confinement: devmode > parts: > main: > source: /home2/mico/programs/fotoxx/packs/fotoxx-17.04.tar.gz > plugin: make > apps: > fotoxx-snap: > command: usr/bin/fotoxx > ------------------------------------------------------------------------------- > > fotoxx-17.04 > initz. clutter and GTK ... > (process:4083): Gtk-WARNING **: Locale not supported by C library. > Using the fallback 'C' locale. > Gtk-Message: Failed to load module "unity-gtk-module" > > (fotoxx:4083): GdkPixbuf-WARNING **: Cannot open pixbuf loader module > file '/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache': No > such file or directory > > This likely means that your installation is broken. > Try running the command > gdk-pixbuf-query-loaders > > /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache > to make things work again for the time being. > Gtk-Message: Failed to load module "canberra-gtk-module" > Gtk-Message: Failed to load module "canberra-gtk-module" > > (fotoxx:4083): Clutter-WARNING **: Locale not supported by C library. > Using the fallback 'C' locale. > > (fotoxx:4083): Clutter-CRITICAL **: Unable to initialize Clutter: Unable > to initialize the Clutter backend: no available drivers found. > fotoxx-snap $: > > ------------------------------------------------------------------------------- > > Here are the debian package dependencies: > > Depends: libimage-exiftool-perl, libc6, libchamplain-gtk-0.12-0, > libclutter-gtk-1.0-0 > > ----------------------------------------------------------------------------------- > > Question: why not make a snap package automatically from a debian > package? > All the needed information is present, it seems. > Referenced libraries can be obtained from the executable. > From jamie at canonical.com Mon Mar 20 19:08:45 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 20 Mar 2017 14:08:45 -0500 Subject: FreePBX snap In-Reply-To: References: Message-ID: <1490036925.5413.4.camel@canonical.com> On Sun, 2017-03-19 at 11:50 -0300, Tiago Herrmann wrote: ... > 1) Asterisk running fine right after snap installation, but failing > afterwards. > After a lot of debugging I figured asterisk was crashing with SIGSYS, > and found that the asterisk binary tries to call chown(), setgid() and > other syscalls that are only allowed during installation (which > explains the behavior I was seeing). My workaround was to add these > calls to the snacraft-preload part that Sergio wrote and preload > asterisk with it. These calls always return success for now just to > keep asterisk happy. If you guys know a better way to workaround it, I > would be happy to remove this hack. This is https://bugs.launchpad.net/snapcraft/+bug/1617314 and is progress to allow use of the 'daemon' user and group. Also, per-snap users and groups is covered in https://bugs.launchpad.net/snappy/+bug/1606510 (but I don't know the priority of that work). -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Mon Mar 20 19:21:26 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 20 Mar 2017 19:21:26 +0000 Subject: Status of snapd on Arch Linux In-Reply-To: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> Message-ID: <42d4ig.on4ofy.1hge199-qmf@smtp.googlemail.com> On Sat, 18 Mar 2017 00:32:38 +0100, Joseph Rushton Wakeling wrote: > * installing my ldc2 snap (`snap install --classic > --candidate ldc2`) worked > fine (it shows up in `snap list` as expected) but if I try to run > /var/lib/snapd/snap/bin/ldc2 directly I get an error message: > > execv failed: No such file or directory > > * attempting to run the actual underlying binary within the snap, i.e. > /var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other binaries > there) results in a similar error message: > > -bash: ./ldc2: No such file or directory Does it work if you create a symlink of /var/lib/snapd/snap to /snap? One of the things classic confined snaps require is a fixed path to ld in core -- Sent using Dekko from my Ubuntu device From jamie at canonical.com Mon Mar 20 19:29:59 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 20 Mar 2017 14:29:59 -0500 Subject: udev rules In-Reply-To: References: Message-ID: <1490038199.5413.18.camel@canonical.com> On Mon, 2017-03-20 at 14:21 +0100, Loïc Minier wrote: > Hi! > > I saw a couple of software pieces that rely on udev rules to work; I guess > these use cases need design to be supported in snaps; I wanted to share > some specifics below. > > 1) aksusbd is a Gemalto daemon to assert presence of a license USB dongle; > it requires USB access, and also these udev rules that call binaries on > addition/removal of devices and create /dev symlinks: > http://www.feflow.info/download/FEFLOW/linux/dongle-2.41/linux_dinst/hasp.rule > s > > This is a dependency of e.g. Quortus EPC (4G core network). It could be > delivered as a part or more likely as a separate snap since Quortus can > operate in different modes. > > 2) LimeSDR is SDR hardware that comes in USB and PCI form-factor. It might > be used from desktop apps, e.g. Gqrx is a spectrum exploration tool and > typically a desktop app that runs as non-root. This is the set of udev > rules that upstream recommends installing: > https://github.com/myriadrf/LimeSuite/blob/master/udev-rules/64-limesuite.rule > s > > These two use cases (triggering commands when devices are plugged / > unplugged and granting permissions to desktop users to a new /dev node) > don't seem possible right now. That's correct. The aksusbd case seems like it could be covered by existing interface techniques. The providing snap slots the hasp interface and that interface could add udev rules that point to (the snappy command aliased) /snap/bin/aksusbd. There is probably a little thought to be had there since it assumes the aksusbd alias and that might be somewhat awkward for different slot implementations. This would all work for gadget snaps that provide the /dev files (like with serial-port, etc) and won't work for classic/hotplugging. The non-root LimeSDR case is not currently handled. To me, this is clearly another interface (eg, 'xillybus'), but we may want to change the GROUP and not use mode 666 if someone were going to add this interface today. What is needed to properly handle this are device acls. This is being tracked in https://bugs.l aunchpad.net/snappy/+bug/1646144 and additional discussion in https://bugs.launc hpad.net/snappy/+bug/1606510/comments/14 (but I don't know the priority of this work). > I think the former is probably covered in > hotplugging requirements, not sure about the latter. Perhaps I should add > these to some existing design doc? > That seems wise for both cases (though the device acls is somewhat orthogonal). I'm not sure where the hotplugging design doc is (iirc, Gustavo may have the details). -- 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 joseph.wakeling at webdrake.net Mon Mar 20 20:30:34 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 20 Mar 2017 21:30:34 +0100 Subject: Status of snapd on Arch Linux In-Reply-To: <42d4ig.on4ofy.1hge199-qmf@smtp.googlemail.com> References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> <42d4ig.on4ofy.1hge199-qmf@smtp.googlemail.com> Message-ID: <6201975f-e8c7-979d-b736-140b885b780d@webdrake.net> On 20/03/17 20:21, Sergio Schvezov wrote: > Does it work if you create a symlink of /var/lib/snapd/snap to /snap? One of the things classic confined snaps require is a fixed path to ld in core Unfortunately not: still 'execv failed: No such file or directory' :-( From joseph.wakeling at webdrake.net Mon Mar 20 20:34:10 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 20 Mar 2017 21:34:10 +0100 Subject: Triggering CI/snap builds on changes to snapcraft parts In-Reply-To: References: Message-ID: <1219ea12-ffa8-babf-ccd7-8899d93154d8@webdrake.net> On 20/03/17 11:37, Evan Dandrea wrote: > Do you need better than day-level resolution? If not, I'd suggest using > Travis' cron feature to create nightly builds: > https://docs.travis-ci.com/user/cron-jobs/ Does that actually solve the problem described, though? I ask because as Loïc stated it, it's one that I'm interested in too. Suppose a security update arrives for a deb package that my snap lists as a build-package or a stage-package. Ideally CI would recognize that the dependencies have updated since the snap was last built, build a new package, and auto-upload (and maybe publish) it. Do nightly builds actually address this? Most of the time there will be no changes to the dependencies, so how does one identify the times when the published package needs updating? From gustavo at niemeyer.net Mon Mar 20 20:39:23 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 20 Mar 2017 17:39:23 -0300 Subject: Status of snapd on Arch Linux In-Reply-To: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> Message-ID: On Fri, Mar 17, 2017 at 8:32 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello folks, > > Is there anyone here working on snapd on Arch? > > I ask because I recently tried it out on a fresh Arch install and ran into > some issues. > > Installing snaps works fine in itself, and snap list is able to find the > installed snaps. However, these issues arose as soon as I started trying > to use them: > > * snap --version lists 'unknown' for snap, snapd and arch > > * all snap-related stuff is placed in /var/lib/snapd/snap instead of > /snap > (fine in itself), but the PATH still contains /snap/bin rather than > /var/lib/snapd/snap/bin. > > - according to https://wiki.archlinux.org/index.php/Snapd#Installing > , > installing a snap should cause it to be mounted to /snap/snapname > but this doesn't appear to be happening > Looks like the package changed recently then, after the rdocumentation was written. Do we have details on who's done that and why? /snap still feels so much better. * installing my ldc2 snap (`snap install --classic --candidate ldc2`) > worked > fine (it shows up in `snap list` as expected) but if I try to run > /var/lib/snapd/snap/bin/ldc2 directly I get an error message: > > execv failed: No such file or directory > What is it pointing to? * attempting to run the actual underlying binary within the snap, i.e. > /var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other > binaries > there) results in a similar error message: > > -bash: ./ldc2: No such file or directory > This was never supposed to be done. Exposed content is supposed to work as done above. Running `file ldc2` on the binary reveals what I would assume is correct > information: > > ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically > linked, interpreter /snap/core/current/lib/x86_64-linux/gnu/ld-2.23.so > , > for GNU/Linux 2.6.32, BuildID[sha1]=[I'm not typing this out], not > stripped, with debug_info > > ... and uname -m gives x86_64, so I don't think it can be an issue like > trying to run a 32-bit package on a 64-bit system (or vice versa). > > For comparison I tried installing both hello-world and Michael > Hudson-Doyle's go snap. hello-world ran fine (but it is after all only a > shell script underneath). The go snap ran into the same issues as my ldc2 > snap. > > I assume these are known issues, but can anyone advise on what are the > fundamental problems here and on whether it's expected to be addressed soon? > Most of these issues seem to be related to the move out of /snap, perhaps done too quickly. I'd suggest returning /snap to its place, at least until those issues are sorted out there. gustavo @ http://niemeyer.net From joseph.wakeling at webdrake.net Mon Mar 20 21:09:25 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 20 Mar 2017 22:09:25 +0100 Subject: Setting environment variables from within snapcraft.yaml Message-ID: Hello folks, Is it possible to set environment variables to be used when creating a part of a snap? I guess one could use the `prepare:` scriptlet to do something like `export MY_VAR=whatever` but I'd like the environment variable to be set before I even pull the source. (If you're wondering why: I'm considering whether I can use git environment variables to work around the launchpad-buildd constraints on support for git:// URLs.) I'm not seeing anything relevant in https://snapcraft.io/docs/build-snaps/parts, hence why I ask here. Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Mon Mar 20 21:17:49 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 20 Mar 2017 22:17:49 +0100 Subject: Status of snapd on Arch Linux In-Reply-To: References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> Message-ID: <7ac4eca9-21cf-1d44-f3b5-9022c6d8467f@webdrake.net> On 20/03/17 21:39, Gustavo Niemeyer wrote: > * installing my ldc2 snap (`snap install --classic --candidate ldc2`) >> worked >> fine (it shows up in `snap list` as expected) but if I try to run >> /var/lib/snapd/snap/bin/ldc2 directly I get an error message: >> >> execv failed: No such file or directory >> > > What is it pointing to? /var/lib/snapd/snap/bin/ldc2 is pointing to /usr/bin/snap (as are all the entries in /var/lib/snapd/snap/bin/). > * attempting to run the actual underlying binary within the snap, i.e. >> /var/lib/snapd/snap/ldc2/current/bin/ldc2 (or any of the other >> binaries >> there) results in a similar error message: >> >> -bash: ./ldc2: No such file or directory >> > > This was never supposed to be done. Exposed content is supposed to work as > done above. I do recognize that, but in the circumstances I thought I'd try it to see if it shed any light on the situation. > Most of these issues seem to be related to the move out of /snap, perhaps > done too quickly. > > I'd suggest returning /snap to its place, at least until those issues are > sorted out there. Note that simply putting a /snap symlink to /var/lib/snapd/snap doesn't work (cf. my response to Sergio). From gustavo at niemeyer.net Mon Mar 20 22:14:39 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 20 Mar 2017 19:14:39 -0300 Subject: Status of snapd on Arch Linux In-Reply-To: <7ac4eca9-21cf-1d44-f3b5-9022c6d8467f@webdrake.net> References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> <7ac4eca9-21cf-1d44-f3b5-9022c6d8467f@webdrake.net> Message-ID: On Mon, Mar 20, 2017 at 6:17 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > > Note that simply putting a /snap symlink to /var/lib/snapd/snap doesn't > work (cf. my response to Sergio). Most likely the snap was partly configured to run elsewhere, but not entirely. We really need to have someone looking into this package, preferably just restoring the standard /snap path. Can you rebuild the package and try that out? Would be a nice data point. If you can't or don't want to, that's okay. I'm sure the package maintainer will look into that. gustavo @ http://niemeyer.net From joseph.wakeling at webdrake.net Mon Mar 20 22:41:27 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Mon, 20 Mar 2017 23:41:27 +0100 Subject: Status of snapd on Arch Linux In-Reply-To: References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> <7ac4eca9-21cf-1d44-f3b5-9022c6d8467f@webdrake.net> Message-ID: <8d492bc9-0392-543c-9111-883e348a1093@webdrake.net> On 20/03/17 23:14, Gustavo Niemeyer wrote: > Most likely the snap was partly configured to run elsewhere, but not > entirely. > > We really need to have someone looking into this package, preferably just > restoring the standard /snap path. > > Can you rebuild the package and try that out? Would be a nice data point. > If you can't or don't want to, that's okay. I'm sure the package maintainer > will look into that. Well, I'm not an Arch user typically; I just installed it into a VM (actually, my first ever Arch install) to check out whether snap packages I've created would work. I can try to take a look, but I'm not sure I'll get there before the maintainer does ;-) From gustavo at niemeyer.net Tue Mar 21 00:48:12 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 20 Mar 2017 21:48:12 -0300 Subject: Status of snapd on Arch Linux In-Reply-To: <8d492bc9-0392-543c-9111-883e348a1093@webdrake.net> References: <970926f0-773e-2a9a-ad79-66eb789c667e@webdrake.net> <7ac4eca9-21cf-1d44-f3b5-9022c6d8467f@webdrake.net> <8d492bc9-0392-543c-9111-883e348a1093@webdrake.net> Message-ID: Ah, please don't worry then! Thanks for the report. We'll get this sorted out and get back to you. On Mon, Mar 20, 2017 at 7:41 PM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > On 20/03/17 23:14, Gustavo Niemeyer wrote: > >> Most likely the snap was partly configured to run elsewhere, but not >> entirely. >> >> We really need to have someone looking into this package, preferably just >> restoring the standard /snap path. >> >> Can you rebuild the package and try that out? Would be a nice data point. >> If you can't or don't want to, that's okay. I'm sure the package >> maintainer >> will look into that. >> > > Well, I'm not an Arch user typically; I just installed it into a VM > (actually, my first ever Arch install) to check out whether snap packages > I've created would work. > > I can try to take a look, but I'm not sure I'll get there before the > maintainer does ;-) > > > -- > 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 jin.hsieh at canonical.com Tue Mar 21 07:44:14 2017 From: jin.hsieh at canonical.com (Jin Hsieh) Date: Tue, 21 Mar 2017 15:44:14 +0800 Subject: Setting environment variables from within snapcraft.yaml In-Reply-To: References: Message-ID: Hello Joseph, As you said we generally export env. variables in launching script to deploy a customized part, not pretty sure we now have a plugin or something to support this "before pull the source"... BR. Jin On Tue, Mar 21, 2017 at 5:09 AM, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello folks, > > Is it possible to set environment variables to be used when creating a > part of a snap? > > I guess one could use the `prepare:` scriptlet to do something like > `export MY_VAR=whatever` but I'd like the environment variable to be set > before I even pull the source. (If you're wondering why: I'm considering > whether I can use git environment variables to work around the > launchpad-buildd constraints on support for git:// URLs.) > > I'm not seeing anything relevant in https://snapcraft.io/docs/buil > d-snaps/parts, hence why I ask here. > > 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 > From madper.xie at canonical.com Tue Mar 21 10:13:52 2017 From: madper.xie at canonical.com (Madper Xie) Date: Tue, 21 Mar 2017 18:13:52 +0800 Subject: How to convert the initrd.img during buiding the kernel snap. In-Reply-To: <1490012800.29433.12.camel@ubuntu.com> References: <1490012800.29433.12.camel@ubuntu.com> Message-ID: Hi Ogra, After adding the `#define CONFIG_SUPPORT_RAW_INITRD` the uboot still complains `Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid` ... Is there any other macros should be defined? BR, Madper On Mon, Mar 20, 2017 at 8:26 PM, Oliver Grawert wrote: > hi, > On Do, 2017-03-16 at 21:22 +0800, Madper Xie wrote: > > Hi all, > > > > My u-boot do not support the format of the initrd.img. So I need to > > manually convert it via mkimage every time. > > > > I tried to use scriptlet to convert the initrd.img file but failed. > > > > ``` > > install: | > > mkimage -n 'RamdiskImage' -A arm -O linux -T ramdisk -C gzip -d > > initrd.img ramfs.img > > rm initrd.img > > ``` > > > > I got: > > mkimage: Can't open initrd.img: No such file or directory > > rm: cannot remove 'initrd.img': No such file or directory > > > > It seems the scriptlet executed before downloading the initrd.img. > > Do we have any way to run a command after downloading the initrd.img? > > > > please fix your u-boot instead, one of the required uboot config > options we have is: > > #define CONFIG_SUPPORT_RAW_INITRD > > in your include/configs/.h file ... > > the others are: > > #define CONFIG_ENV_IS_IN_FAT > #define CONFIG_SYS_REDUNDAND_ENVIRONMENT > and > #define CONFIG_ENV_SIZE SZ_128K > > to make the rollback function work. > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > From maarten.ectors at canonical.com Tue Mar 21 10:15:28 2017 From: maarten.ectors at canonical.com (Maarten Ectors) Date: Tue, 21 Mar 2017 10:15:28 +0000 Subject: bluepy-helper not being built using In-Reply-To: References: Message-ID: Hi Mritunjai, I made the snap for an IoT Berlin demo. I remember making several Bluetooth sensortag intends before I got one working. Not sure it was this snap or another one I got working. I must admit that Bluetooth hasn't been playing nice during my snap efforts :-( Maarten On 20 Mar 2017 12:56 p.m., "Mritunjai Singh" wrote: Kindly confirm if anyone has got sensortag snap[https://github.com/ mectors/sensortag] working on Raspberry Pi Board with Ubuntu Core as I am struggling to make it work using snap as that snap is not building the bluepy-helper. Can anyone suggest the alternative approach to resolve the issue. Any help will be appreciated. Regards, Mritunjai From: Mritunjai Singh Sent: Wednesday, March 15, 2017 1:15 PM To: 'Snapcraft at lists.snapcraft.io' Subject: bluepy-helper not being built using Hello, I am trying to use the sensortag snap available on github [ https://github.com/mectors/sensortag] to get the data from TI sensor and posting these sensor data to cloud using our proprietary SDK APIs. I am successfully able to build and install the sensortag snap and also connected the snap to bluetooth-control to make sure that the snap has bluetooth-control. I am following the README.md available with the snap. - Build and install of the sensortag snap successful. - sensortag.sensortag-init 7C:01:91:72:63:32 successful - sensortag.sensortag-in giving error messages shown below: Traceback (most recent call last): File "/snap/sensortag/x1/bin/sensortag", line 11, in sys.exit(main()) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 416, in main tag = SensorTag(arg.host) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 331, in __init__ Peripheral.__init__(self,addr) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 318, in __init__ self.connect(deviceAddr, addrType, iface) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 353, in connect self._startHelper() File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 210, in _startHelper universal_newlines=True) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 947, in __init__ restore_signals, start_new_session) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child raise child_exception_type(errno_num, err_msg) FileNotFoundError: [Errno 2] No such file or directory: '/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/bluepy-helper' After some research it looks like that snap is not able to build the the "sensortag/parts/bluepy/buildbluepy-helper.c" and thus the bluepy-helper object is not created during the install of bluepy. I can see that there is a bluepy-helper.c file but no object. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluez-5.29 btle.py __init__.py __pycache__ uuids.json If I run make manually within the folder the objects are created. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluepy-helper bluez-5.29 btle.py __init__.py __pycache__ uuids.json Compiling bluepy-helper works as expected but it is not copied to the build directory and thus not installed. It seems to be known issue as shown in links below: https://github.com/IanHarvey/bluepy/issues/158 https://github.com/IanHarvey/bluepy/issues/139 Can anyone help me resolve this issue. Regards, Mritunjai -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/ mailman/listinfo/snapcraft From ogra at ubuntu.com Tue Mar 21 10:20:22 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Mar 2017 11:20:22 +0100 Subject: How to convert the initrd.img during buiding the kernel snap. In-Reply-To: References: <1490012800.29433.12.camel@ubuntu.com> Message-ID: <1490091622.5758.3.camel@ubuntu.com> hi, Am Dienstag, den 21.03.2017, 18:13 +0800 schrieb Madper Xie: > Hi Ogra, > > After adding the `#define CONFIG_SUPPORT_RAW_INITRD` the uboot still > complains `Wrong Ramdisk Image Format Ramdisk image is corrupt or > invalid` > ... > > Is there any other macros should be defined? well, your initrd.img needs to indeed just be that, not an uInitrd, the boot command your board uses (bootm, booti, bootz or whatever) will need to use the right syntax (usually you need to pass the size)...  also a look at your boot.env.in and a serial log might be useful ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Tue Mar 21 10:21:30 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Mar 2017 11:21:30 +0100 Subject: How to convert the initrd.img during buiding the kernel snap. In-Reply-To: <1490091622.5758.3.camel@ubuntu.com> References: <1490012800.29433.12.camel@ubuntu.com> <1490091622.5758.3.camel@ubuntu.com> Message-ID: <1490091690.5758.4.camel@ubuntu.com> hi, Am Dienstag, den 21.03.2017, 11:20 +0100 schrieb Oliver Grawert: >  > also a look at your boot.env.in indeed i meant uboot.env.in  :) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From madper.xie at canonical.com Tue Mar 21 10:26:08 2017 From: madper.xie at canonical.com (Madper Xie) Date: Tue, 21 Mar 2017 18:26:08 +0800 Subject: How to convert the initrd.img during buiding the kernel snap. In-Reply-To: <1490091622.5758.3.camel@ubuntu.com> References: <1490012800.29433.12.camel@ubuntu.com> <1490091622.5758.3.camel@ubuntu.com> Message-ID: Hi Ogra, On Tue, Mar 21, 2017 at 6:20 PM, Oliver Grawert wrote: > hi, > Am Dienstag, den 21.03.2017, 18:13 +0800 schrieb Madper Xie: > > Hi Ogra, > > > > After adding the `#define CONFIG_SUPPORT_RAW_INITRD` the uboot still > > complains `Wrong Ramdisk Image Format Ramdisk image is corrupt or > > invalid` > > ... > > > > Is there any other macros should be defined? > > well, your initrd.img needs to indeed just be that, not an uInitrd, the > boot command your board uses (bootm, booti, bootz or whatever) will > need to use the right syntax (usually you need to pass the size)... > > Yes I noticed that in the README.txt. So I modified the boot cmd to `autoboot=bootz ${loadaddr} ${ramdisk_addr}:1c5 ${fdt_addr}` ... Still doesn't boot. > also a look at your boot.env.in and a serial log might be useful ... > The serial log doesn't provide useful message: ``` Booting from mmc ... file_prefix: /hummingboard-kernel_x1.snap/ 4648094 bytes read in 262 ms (16.9 MiB/s) Loaded initrd.img loading fdt: /hummingboard-kernel_x1.snap/dtbs/imx6q-hummingboard.dtb 38636 bytes read in 21 ms (1.8 MiB/s) Loaded imx6q-hummingboard.dtb Kernel image @ 0x10800000 [ 0x000000 - 0x5fa120 ] Wrong Ramdisk Image Format Ramdisk image is corrupt or invalid ``` > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > From n.curalli at domotz.com Tue Mar 21 10:27:02 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 21 Mar 2017 10:27:02 +0000 Subject: Netplan replug function is incompatible with ath9k_htc module References: <1490013421.29433.16.camel@ubuntu.com> Message-ID: hi Oli, thanks a lot for the answer. how could i rebuild a new image with my new core snap , built with procedure that your show me, by ubuntu-image? Ciao Nicolino Il 20/03/2017 13:37, Oliver Grawert ha scritto: > hi, > On Di, 2017-03-14 at 11:29 +0100, Loïc Minier wrote: >> >> (So you want to test an updated netplan binary.) >> >> How can we repack a core snap with different code per netplan? > add netplan to a PPA you own ... > > branch https://github.com/snapcore/core > > edit the Makefile and add an entry for your PPA to teh EXTRA_PPAS > variable at "ENV" line ... > > run "sudo snapcraft" in the top level of your cloned dir... > > ciao > oli From ogra at ubuntu.com Tue Mar 21 10:36:18 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Mar 2017 11:36:18 +0100 Subject: Netplan replug function is incompatible with ath9k_htc module In-Reply-To: References: <1490013421.29433.16.camel@ubuntu.com> Message-ID: <1490092578.5758.7.camel@ubuntu.com> hi, Am Dienstag, den 21.03.2017, 10:27 +0000 schrieb Nicolino Curalli: > hi Oli, > thanks a lot for the answer. > > how could i rebuild a new image with my new core snap , built with > procedure that your show me, by ubuntu-image? you can follow the normal image building process [1] and use the  --extra-snaps option to point to the path of your local core snap (iirc it wont be upgradeable as the core snap will be marked sideloaded but it should be fine for testing your change) ciao oli [1] https://docs.ubuntu.com/core/en/guides/build-device/image-building -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From ogra at ubuntu.com Tue Mar 21 10:42:31 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Mar 2017 11:42:31 +0100 Subject: How to convert the initrd.img during buiding the kernel snap. In-Reply-To: References: <1490012800.29433.12.camel@ubuntu.com> <1490091622.5758.3.camel@ubuntu.com> Message-ID: <1490092951.5758.13.camel@ubuntu.com> hi, Am Dienstag, den 21.03.2017, 18:26 +0800 schrieb Madper Xie: >  > > Yes I noticed that in the README.txt. So I modified the boot cmd to > `autoboot=bootz ${loadaddr} ${ramdisk_addr}:1c5 ${fdt_addr}`  ... > Still > doesn't boot. where does that 1c5 come from ? please take a look at [1] where we use: loadinitrd=fatload mmc 1:8 ${ramdisk_addr}\ ${snap_kernel}/${initrd_file}; setenv initrd_size ${filesize} and: booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_addr} that way the initrd_size variable has the correct value... > > > > > also a look at your boot.env.in and a serial log might be useful > > ... > > > The serial log doesn't provide useful message: > heh, i was hoping for a full log so i could also see your uboot version etc :) perhaps it is to old and does not support raw initrds yet. ciao oli [1] https://github.com/snapcore/dragonboard-gadget/blob/master/prebuilt /uboot.env.in -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From tim.sueberkrueb at web.de Tue Mar 21 11:08:39 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Tue, 21 Mar 2017 12:08:39 +0100 Subject: Contributing cloud parts In-Reply-To: <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> Message-ID: <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> Hey Didier, I see, thanks for your answer! All the best, Tim Süberkrüb On 20.03.2017 09:42, Didier Roche wrote: > Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : >> Hey, > > Hey Tim, >> >> what is the process of contributing a cloud part to >> https://wiki.ubuntu.com/snapcraft/parts (is it open for community >> contributions?)? >> >> Are there any plans for having a real parts repository instead of a >> wiki page for cloud parts? I think something like parts.snapcraft.io >> would be pretty cool :) >> > > There isn't any process as of now AFAIK. It is open for community > contributions, so feel free to edit the wiki page adding your awesome > cloud part :) > snapcraft update && snapcraft search should list your part within the > next hour (the importer runs hourly AFAIK). > > I agree some way to see/check metrics on parts popularity, getting > user's feedback and such would be pretty cool! > Cheers, > Didier > From n.curalli at domotz.com Tue Mar 21 11:23:03 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 21 Mar 2017 11:23:03 +0000 Subject: Netplan replug function is incompatible with ath9k_htc module References: <1490013421.29433.16.camel@ubuntu.com> <1490092578.5758.7.camel@ubuntu.com> Message-ID: Hi Oli an further step: is it possibile to publish my new core snap on store, then permit to upgrade it to my new version of it? Ciao Nicolino Il 21/03/2017 11:36, Oliver Grawert ha scritto: > hi, > Am Dienstag, den 21.03.2017, 10:27 +0000 schrieb Nicolino Curalli: >> hi Oli, >> thanks a lot for the answer. >> >> how could i rebuild a new image with my new core snap , built with >> procedure that your show me, by ubuntu-image? > you can follow the normal image building process [1] and use the > --extra-snaps option to point to the path of your local core snap (iirc > it wont be upgradeable as the core snap will be marked sideloaded but > it should be fine for testing your change) > > ciao > oli > > [1] https://docs.ubuntu.com/core/en/guides/build-device/image-building From ogra at ubuntu.com Tue Mar 21 11:26:53 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 21 Mar 2017 12:26:53 +0100 Subject: Netplan replug function is incompatible with ath9k_htc module In-Reply-To: References: <1490013421.29433.16.camel@ubuntu.com> <1490092578.5758.7.camel@ubuntu.com> Message-ID: <1490095613.5758.15.camel@ubuntu.com> hi, Am Dienstag, den 21.03.2017, 11:23 +0000 schrieb Nicolino Curalli: > Hi Oli > an further step: > is it possibile to publish my new core snap on store, then permit to > upgrade it to my new version of it? > no, we do not allow other core snaps, to make sure every snap sees the same execution environment ...  this is solely for testing a change, the fix then needs to go into the actual package you fixed (or into the build scripts of core if it does not belong into any package) ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From loic.minier at ubuntu.com Tue Mar 21 17:11:43 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 21 Mar 2017 18:11:43 +0100 Subject: udev rules In-Reply-To: <1490038199.5413.18.camel@canonical.com> References: <1490038199.5413.18.camel@canonical.com> Message-ID: Hi! On Mon, Mar 20, 2017 at 8:29 PM, Jamie Strandboge wrote: > The aksusbd case seems like it could be covered by existing interface > techniques. The providing snap slots the hasp interface and that interface > could > add udev rules that point to (the snappy command aliased) > /snap/bin/aksusbd. > There is probably a little thought to be had there since it assumes the > aksusbd > alias and that might be somewhat awkward for different slot > implementations. > Would it make sense to point at a hook for this? The command to handle udev events doesn't necessarily need to pollute the PATH namespace. > This would all work for gadget snaps that provide the /dev files (like with > serial-port, etc) and won't work for classic/hotplugging. > Are you saying these rules would be limited to /dev files described in the gadget? Why wouldn't this work for classic/hotplugging? Cheers, - Loïc From mrsingh at ssni.com Tue Mar 21 16:36:10 2017 From: mrsingh at ssni.com (Mritunjai Singh) Date: Tue, 21 Mar 2017 16:36:10 +0000 Subject: bluepy-helper not being built using In-Reply-To: References: Message-ID: Hi Maarten, Thanks for your response. I would be grateful if you can spare some time to check which snap(sensortag) you got working, if possible can you forward that working snapcraft.yaml file. Waiting eagerly for your response. Regards, Mritunjai -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Maarten Ectors Sent: Tuesday, March 21, 2017 3:15 AM To: Snapcraft Subject: RE: bluepy-helper not being built using Hi Mritunjai, I made the snap for an IoT Berlin demo. I remember making several Bluetooth sensortag intends before I got one working. Not sure it was this snap or another one I got working. I must admit that Bluetooth hasn't been playing nice during my snap efforts :-( Maarten On 20 Mar 2017 12:56 p.m., "Mritunjai Singh" wrote: Kindly confirm if anyone has got sensortag snap[https://github.com/ mectors/sensortag] working on Raspberry Pi Board with Ubuntu Core as I am struggling to make it work using snap as that snap is not building the bluepy-helper. Can anyone suggest the alternative approach to resolve the issue. Any help will be appreciated. Regards, Mritunjai From: Mritunjai Singh Sent: Wednesday, March 15, 2017 1:15 PM To: 'Snapcraft at lists.snapcraft.io' Subject: bluepy-helper not being built using Hello, I am trying to use the sensortag snap available on github [ https://github.com/mectors/sensortag] to get the data from TI sensor and posting these sensor data to cloud using our proprietary SDK APIs. I am successfully able to build and install the sensortag snap and also connected the snap to bluetooth-control to make sure that the snap has bluetooth-control. I am following the README.md available with the snap. - Build and install of the sensortag snap successful. - sensortag.sensortag-init 7C:01:91:72:63:32 successful - sensortag.sensortag-in giving error messages shown below: Traceback (most recent call last): File "/snap/sensortag/x1/bin/sensortag", line 11, in sys.exit(main()) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 416, in main tag = SensorTag(arg.host) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/sensortag.py", line 331, in __init__ Peripheral.__init__(self,addr) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 318, in __init__ self.connect(deviceAddr, addrType, iface) File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 353, in connect self._startHelper() File "/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/btle.py", line 210, in _startHelper universal_newlines=True) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 947, in __init__ restore_signals, start_new_session) File "/snap/sensortag/x1/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child raise child_exception_type(errno_num, err_msg) FileNotFoundError: [Errno 2] No such file or directory: '/snap/sensortag/x1/lib/python3.5/site-packages/bluepy/bluepy-helper' After some research it looks like that snap is not able to build the the "sensortag/parts/bluepy/buildbluepy-helper.c" and thus the bluepy-helper object is not created during the install of bluepy. I can see that there is a bluepy-helper.c file but no object. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluez-5.29 btle.py __init__.py __pycache__ uuids.json If I run make manually within the folder the objects are created. blescan.py bluepy-helper.c bluez-src.tgz get_services.py Makefile sensortag.py bluepy-helper bluez-5.29 btle.py __init__.py __pycache__ uuids.json Compiling bluepy-helper works as expected but it is not copied to the build directory and thus not installed. It seems to be known issue as shown in links below: https://github.com/IanHarvey/bluepy/issues/158 https://github.com/IanHarvey/bluepy/issues/139 Can anyone help me resolve this issue. Regards, Mritunjai -- 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 jamie at canonical.com Tue Mar 21 21:52:15 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 21 Mar 2017 16:52:15 -0500 Subject: udev rules In-Reply-To: References: <1490038199.5413.18.camel@canonical.com> Message-ID: <1490133135.19515.24.camel@canonical.com> On Tue, 2017-03-21 at 18:11 +0100, Loïc Minier wrote: > Hi! > > On Mon, Mar 20, 2017 at 8:29 PM, Jamie Strandboge > wrote: > > > > > The aksusbd case seems like it could be covered by existing interface > > techniques. The providing snap slots the hasp interface and that interface > > could > > add udev rules that point to (the snappy command aliased) > > /snap/bin/aksusbd. > > There is probably a little thought to be had there since it assumes the > > aksusbd > > alias and that might be somewhat awkward for different slot > > implementations. > > > Would it make sense to point at a hook for this? The command to handle udev > events doesn't necessarily need to pollute the PATH namespace. > It could-- that would need design. /snap/bin is already there now, so I mentioned it *could* be done that way. Adding something to the udev backend in snapd so that you can specify a command to run seems plausible; just needs design. > > > > > This would all work for gadget snaps that provide the /dev files (like with > > serial-port, etc) and won't work for classic/hotplugging. > > > Are you saying these rules would be limited to /dev files described in the > gadget? > > Why wouldn't this work for classic/hotplugging? I just meant *today* it will work for gadgets and not classic/hotplugging. We should absolutely make classic/hotplugging work, so please add your use cases to the discussion. -- 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 akgrant0710 at gmail.com Wed Mar 22 09:02:05 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Wed, 22 Mar 2017 10:02:05 +0100 Subject: snapcraft in docker container fails Message-ID: Hi All, I've been building snap packages within a docker container successfully. Up to now all the containers have been built with devmode, but I would now like to build one with classic confinement (for a development application). Building the package fails because the core snap isn't installed, attempting to install the core package results in: root at 2bd7fd92945f:/# snap install core 2017/03/22 08:36:31.602176 main.go:220: WARNING: cannot create syslog logger 2017/03/22 08:36:31.604709 api.go:890: Installing snap "core" revision unset error: cannot perform the following tasks: - Mount snap "core" (1441) ([daemon-reload] failed with exit status 1: Failed to connect to bus: No such file or directory ) I understand that I'm trying to push docker past its intended usage (syslog, dbus, etc), but does anyone have a workaround for this? Thanks very much, Alistair From marco.ceppi at canonical.com Wed Mar 22 12:01:28 2017 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Wed, 22 Mar 2017 12:01:28 +0000 Subject: snapcraft in docker container fails In-Reply-To: References: Message-ID: Hi Alistair, We had a similar issue in our project, we found this: docker run -it -v $PWD:/root/snap -w /root/snap -e SNAPCRAFT_SETUP_CORE=1 snapcraft/xenial-amd64 /bin/bash Where, when using that flag, the core snap will already be installed. Thanks, Marco Ceppi On Wed, Mar 22, 2017 at 5:03 AM Alistair Grant wrote: > Hi All, > > I've been building snap packages within a docker container successfully. > Up to now all the containers have been built with devmode, but I would > now like to build one with classic confinement (for a development > application). > > Building the package fails because the core snap isn't installed, > attempting to install the core package results in: > > root at 2bd7fd92945f:/# snap install core > 2017/03/22 08:36:31.602176 main.go:220: WARNING: cannot create syslog > logger > 2017/03/22 08:36:31.604709 api.go:890: Installing snap "core" revision > unset > error: cannot perform the following tasks: > - Mount snap "core" (1441) ([daemon-reload] failed with exit status 1: > Failed to connect to bus: No such file or directory > ) > > > I understand that I'm trying to push docker past its intended usage > (syslog, dbus, etc), but does anyone have a workaround for this? > > Thanks very much, > Alistair > > -- > 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 Mar 22 13:23:25 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Wed, 22 Mar 2017 14:23:25 +0100 Subject: snapcraft in docker container fails In-Reply-To: References: Message-ID: Hi Marco, On 22 March 2017 at 13:01, Marco Ceppi wrote: > Hi Alistair, > > We had a similar issue in our project, we found this: > > docker run -it -v $PWD:/root/snap -w /root/snap -e SNAPCRAFT_SETUP_CORE=1 > snapcraft/xenial-amd64 /bin/bash > > Where, when using that flag, the core snap will already be installed. Thanks! That allows me to build the snap package. Now changing the confinement from devmode to classic breaks the application - it's 32 bits and my guess is that it isn't able to load for some reason. But that's another problem. Thanks again, Alistair From max.brustkern at canonical.com Thu Mar 23 14:06:09 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Thu, 23 Mar 2017 10:06:09 -0400 Subject: Automated testing and auto-refresh Message-ID: I'm running automated tests the involve refreshing a VM setup using the released ubuntu-core-16 image with candidate snaps. I install core and reboot first, since otherwise attempting to refresh a snap with no changes exits with an error. After the reboot, auto-refresh starts. When the test script attempts to refresh the kernel snap, we get an error: nuclearbob at localhost:~$ sudo snap changes ID Status Spawn Ready Summary 3 Error 2017-02-16T18:05:19Z 2017-02-16T18:05:49Z Refresh all snaps in the system 4 Done 2017-03-22T17:00:19Z 2017-03-22T17:00:37Z Refresh "core" snap from "candidate" channel 5 Doing 2017-03-22T17:01:34Z - Auto-refresh snap "pc-kernel" 6 Done 2017-03-22T17:01:37Z 2017-03-22T17:01:37Z Refresh "pc" snap from "candidate" channel nuclearbob at localhost:~$ sudo snap refresh --candidate pc-kernel error: cannot refresh "pc-kernel": snap "pc-kernel" has changes in progress nuclearbob at localhost:~$ echo $? 1 This causes the test runner script to exit, as the refresh fails. However, if I wait a bit, the auto-refresh seems to fail as well, and then if I retry the manual refresh, it succeeds: nuclearbob at localhost:~$ sudo snap changes ID Status Spawn Ready Summary 3 Error 2017-02-16T18:05:19Z 2017-02-16T18:05:49Z Refresh all snaps in the system 4 Done 2017-03-22T17:00:19Z 2017-03-22T17:00:37Z Refresh "core" snap from "candidate" channel 5 Error 2017-03-22T17:01:34Z 2017-03-22T17:03:04Z Auto-refresh snap "pc-kernel" 6 Done 2017-03-22T17:01:37Z 2017-03-22T17:01:37Z Refresh "pc" snap from "candidate" channel nuclearbob at localhost:~$ sudo snap refresh --candidate pc-kernel [/] Setup snap "pc-kernel" (59) security profiles Broadcast message from root at localhost.localdomain (Wed 2017-03-22 17:04:02 UTC): reboot scheduled to update the system - temporarily cancel with 'sudo shutdown -c' The system is going down for reboot at Wed 2017-03-22 17:14:02 UTC! pc-kernel (candidate) 4.4.0-67.88 from 'canonical' refreshed Is the best way to handle this just grepping the output of snap changes for "Doing" and "pc-kernel" until there's nothing listed for that, and then retrying the refresh in case it failed before? Is there a better programmatic way to interact with the API? Thanks, Max From n.curalli at domotz.com Thu Mar 23 16:38:20 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Thu, 23 Mar 2017 16:38:20 +0000 Subject: clarification about review process Message-ID: Hi all, i would like to know more about the process review. I found only these explanations ( https://developer.ubuntu.com/en/publish/application-states/?_ga=1.222351067.1125065666.1487610661). is there a more accurate description? Cheers, Nicolino From jenny.murphy at episensor.com Thu Mar 23 17:36:32 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 23 Mar 2017 17:36:32 +0000 Subject: Inter and Intra Snap communication Message-ID: Hi, I currently have a java application running in a snap. As part of some added functionality my java application will need to communicate with a C program executable. We are weighing up the options of how this would work. The probably obvious way is to build a new snap which contains the C program executable. Then we need some way of inter snap communication. So my first question is what is recommend for INTER snap communication, how is it supposed to work? Alternatively could one snap contain two binaries? In this way could traditional linux inter process communication methods be used? This is my second question. Thanks in advance. -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com From sergio.schvezov at canonical.com Thu Mar 23 18:16:09 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 23 Mar 2017 18:16:09 +0000 Subject: Inter and Intra Snap communication In-Reply-To: References: Message-ID: On Thu, 23 Mar 2017 17:36:32 +0000, Jenny Murphy wrote: > Hi, > I currently have a java application running in a snap. As part of some > added functionality my java application will need to communicate with a C > program executable. We are weighing up the options of how this would work. > The probably obvious way is to build a new snap which contains the C > program executable. Then we need some way of inter snap communication. > > So my first question is what is recommend for INTER snap communication, how > is it supposed to work? Some form of stable IPC would provide the best robustness. There are alternatives using the content interface but that provides a level of coupling you might not want. Either of these might need an interface. > Alternatively could one snap contain two binaries? In this way could > traditional linux inter process communication methods be used? This is my > second question. Yes, there are many cases for this already. A good example is lxd, it bundles the lxc client and the lxd daemon. You can start this way and if your C application becomes a shared resource among many other snaps you can consider moving over to a two-snap model with some form of IPC and an interface. -- Sent using Dekko from my Ubuntu device From gustavo at niemeyer.net Thu Mar 23 18:20:31 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Thu, 23 Mar 2017 15:20:31 -0300 Subject: Inter and Intra Snap communication In-Reply-To: References: Message-ID: Hi Jenny, Yes, what you want to do is really to have both of them in the same snap. That's super simple, and it's fine that they are different languages, different processes, etc. On Thu, Mar 23, 2017 at 2:36 PM, Jenny Murphy wrote: > Hi, > I currently have a java application running in a snap. As part of some > added functionality my java application will need to communicate with a C > program executable. We are weighing up the options of how this would work. > The probably obvious way is to build a new snap which contains the C > program executable. Then we need some way of inter snap communication. > > So my first question is what is recommend for INTER snap communication, how > is it supposed to work? > > > Alternatively could one snap contain two binaries? In this way could > traditional linux inter process communication methods be used? This is my > second question. > > Thanks in advance. > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 w | http://www.episensor.com > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net From mhall119 at ubuntu.com Thu Mar 23 18:41:43 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Thu, 23 Mar 2017 14:41:43 -0400 Subject: Inter and Intra Snap communication In-Reply-To: References: Message-ID: Hi Jenny, Here's a link to the documentation showing how to include more than one executable in your snap package, as Sergio and Gustavo already mentioned: https://snapcraft.io/docs/build-snaps/metadata In it you will see that the apps: stanza can have multiple children, one for each executable you want to expose outside of your snap. These will take the form of /snap/bin/. and can be called from the command-line. If == it will condense down to just /snap/bin/ to be cleaner. Michael Hall mhall119 at ubuntu.com On 03/23/2017 02:20 PM, Gustavo Niemeyer wrote: > Hi Jenny, > > Yes, what you want to do is really to have both of them in the same snap. > That's super simple, and it's fine that they are different languages, > different processes, etc. > > > On Thu, Mar 23, 2017 at 2:36 PM, Jenny Murphy > wrote: > >> Hi, >> I currently have a java application running in a snap. As part of some >> added functionality my java application will need to communicate with a C >> program executable. We are weighing up the options of how this would work. >> The probably obvious way is to build a new snap which contains the C >> program executable. Then we need some way of inter snap communication. >> >> So my first question is what is recommend for INTER snap communication, how >> is it supposed to work? >> >> >> Alternatively could one snap contain two binaries? In this way could >> traditional linux inter process communication methods be used? This is my >> second question. >> >> Thanks in advance. >> >> -- >> *Jenny Murphy* >> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >> jenny.murphy at episensor.com t | +353 (0) 61 >> 512 511 w | http://www.episensor.com >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/snapcraft >> > > > From jenny.murphy at episensor.com Thu Mar 23 21:08:06 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 23 Mar 2017 21:08:06 +0000 Subject: Inter and Intra Snap communication In-Reply-To: References: Message-ID: Hi, Thanks, yes it definitely seems one snap multiple binaries is the way to go. I will have a look now at the link. Thanks for the fast responses. Jenny On 23 Mar 2017 18:42, "Michael Hall" wrote: > Hi Jenny, > > Here's a link to the documentation showing how to include more than one > executable in your snap package, as Sergio and Gustavo already mentioned: > > https://snapcraft.io/docs/build-snaps/metadata > > In it you will see that the apps: stanza can have multiple children, one > for each executable you want to expose outside of your snap. These will > take the form of /snap/bin/. and can be called from the > command-line. If == it will condense down to just > /snap/bin/ to be cleaner. > > > Michael Hall > mhall119 at ubuntu.com > > On 03/23/2017 02:20 PM, Gustavo Niemeyer wrote: > > Hi Jenny, > > > > Yes, what you want to do is really to have both of them in the same snap. > > That's super simple, and it's fine that they are different languages, > > different processes, etc. > > > > > > On Thu, Mar 23, 2017 at 2:36 PM, Jenny Murphy < > jenny.murphy at episensor.com> > > wrote: > > > >> Hi, > >> I currently have a java application running in a snap. As part of some > >> added functionality my java application will need to communicate with a > C > >> program executable. We are weighing up the options of how this would > work. > >> The probably obvious way is to build a new snap which contains the C > >> program executable. Then we need some way of inter snap communication. > >> > >> So my first question is what is recommend for INTER snap communication, > how > >> is it supposed to work? > >> > >> > >> Alternatively could one snap contain two binaries? In this way could > >> traditional linux inter process communication methods be used? This is > my > >> second question. > >> > >> Thanks in advance. > >> > >> -- > >> *Jenny Murphy* > >> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > >> jenny.murphy at episensor.com t | +353 (0) > 61 > >> 512 511 w | http://www.episensor.com > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ > >> mailman/listinfo/snapcraft > >> > > > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From n.curalli at domotz.com Fri Mar 24 05:09:28 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Fri, 24 Mar 2017 05:09:28 +0000 Subject: clarification about review process References: Message-ID: Hi all perhaps my question is not so understaandable. I want to build a CI pipeline for test my snap for the fundamental requirements to pass the review process before uploading it on store. Where could i find something to help me to build this pipeline? Cheers, Nicolino Il 23/03/2017 17:38, 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, > > i would like to know more about the process review. > > I found only these explanations ( https://developer.ubuntu.com/en/publish/application-states/?_ga=1.222351067.1125065666.1487610661). > > is there a more accurate description? > > > Cheers, > > Nicolino > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From seth.arnold at canonical.com Fri Mar 24 06:36:11 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Thu, 23 Mar 2017 23:36:11 -0700 Subject: clarification about review process In-Reply-To: References: Message-ID: <20170324063611.GA32304@hunt> On Fri, Mar 24, 2017 at 05:09:28AM +0000, Nicolino Curalli wrote: > I want to build a CI pipeline for test my snap for the fundamental > requirements to pass the review process before uploading it on store. > Where could i find something to help me to build this pipeline? Hi Nicolino, Is this what you are looking for? https://code.launchpad.net/~store-reviewers/click-reviewers-tools/trunk Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From n.curalli at domotz.com Fri Mar 24 07:56:09 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Fri, 24 Mar 2017 07:56:09 +0000 Subject: clarification about review process References: <20170324063611.GA32304@hunt> Message-ID: hi Seth it seem what i need. Thanks a lot Nicolino Il 24/03/2017 07:36, Seth Arnold ha scritto: > On Fri, Mar 24, 2017 at 05:09:28AM +0000, Nicolino Curalli wrote: >> I want to build a CI pipeline for test my snap for the fundamental >> requirements to pass the review process before uploading it on store. >> Where could i find something to help me to build this pipeline? > Hi Nicolino, > > Is this what you are looking for? > > https://code.launchpad.net/~store-reviewers/click-reviewers-tools/trunk > > Thanks From woodrow.shen at canonical.com Fri Mar 24 08:10:34 2017 From: woodrow.shen at canonical.com (Woodrow Shen) Date: Fri, 24 Mar 2017 16:10:34 +0800 Subject: vim snap issue with bad system call Message-ID: Hello, In order to fit my habit for better experiences (e.g. bundle), I tried to snapcraft the vim snap [1], but after installing the snap and connecting the home interface, I got the weird error of bad system call when vim was closed with ":wq" for write. Another thing I noticed that .vim and .vimrc should be placed in the $HOME/snap/demo-vim/current/, however, I still got the same error there, even if I added undo/backup/swap dirs inside .vimrc. So currently I don't find any clues from syslog about this. Just give me some suggestions if anyone interests vim snap. Here's my .vimrc (just simply test): *set undodir=/home/admin/snap/demo-vim/current/.vim/.undo//* *set backupdir=/home/admin/snap/demo-vim/current/.vim/.backup//* *set directory=/home/admin/snap/demo-vim/current/.vim/.swp//* *set viminfo="NONE"* [1] https://github.com/woodrow-shen/snapcraft-vim.git Thanks, Woodrow -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/m ailman/listinfo/snapcraft From dmitrii.shcherbakov at canonical.com Fri Mar 24 17:49:06 2017 From: dmitrii.shcherbakov at canonical.com (Dmitrii Shcherbakov) Date: Fri, 24 Mar 2017 20:49:06 +0300 Subject: Strategy for Snaps with Debugging Symbols Message-ID: Hi everybody, My question is in the context of a libvirt & qemu snap but I think it is worthwhile to discuss that for any software written in C, C++ or other compiled languages for which debugging symbols can be generated. A lot of debugging tasks can be solved by looking at logs and {s,l}tracing but sometimes this is not enough. With Debian packages the approaches are: 1) to provide your own -dbg package; 2) let https://launchpad.net/ubuntu/+source/pkg-create-dbgsym generate it and add a ddebs.ubuntu.com repo on demand. https://wiki.ubuntu.com/Debug%20Symbol%20Packages https://wiki.ubuntu.com/AptElfDebugSymbols https://wiki.debian.org/AutomaticDebugPackages One idea for snaps is to use -dbg tracks which are going to contain snaps with embedded debugging symbols. Of course, some snaps may contain a number of services so you'd have to customize your build process and create additional automation around snapcraft to make it more manageable. https://snapcraft.io/docs/reference/channels Another issue is that with separate snaps that would have debugging symbols you'd have to replace a non-debug snap with a debug snap which would complicate things if you had a certain state already and did not want a transactional erase of the state you wanted to debug. In the case of ddebs you can just download symbols and use them with an existing application while with a separate snap you need to perform a replacement. I was wondering if anybody thought about it yet and, if not, to start this discussion here. Thanks in advance! Best Regards, Dmitrii Shcherbakov From n.curalli at domotz.com Fri Mar 24 21:13:33 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Fri, 24 Mar 2017 21:13:33 +0000 Subject: is it the gadget snap upgradable? Message-ID: hi all, I have a doubt. It seem that a gadget can't be upgraded during the lifetime of a supported board. I don't find anything in the snap framework for making it in a transational manner: is my mindset wrong? Thank in advance for any clarification. Nicolino From alberto.mardegan at canonical.com Fri Mar 24 21:33:15 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Sat, 25 Mar 2017 00:33:15 +0300 Subject: Snapping scientific software Message-ID: <93329e77-a557-9568-149d-4b363c68731e@canonical.com> Hi there! Please bear with my boasting for a while. :-) I just wrote a blog post [1] on my experience with snapping photogrammetry software, that is software which can build a 3D model out of a set of 2D photographs. I also made a video overview of the process: https://www.youtube.com/watch?v=ELHOjC_V-FE What might be of interest to the readers of this mailing list, is that there is a multitude of software tools out there which are not packaged for Linux, mostly because their authors are more interested in programming than in software distribution. That is certainly the case for scientific software, where authors are researchers who excel in their field but who often happen not to be interested in software distribution (presumably because they target other university researchers, who are anyway supposed to hack on the sources). Sometimes they are also not even very good programmers, which can make building their software harder than what it could be. Snapcraft and snaps can be of enormous help in this case. I enjoyed writing those snaps, and despite being initially totally indifferent about these projects, I've ended up contributing to them with pleasure. The bottom line is: if you have time, and are looking for some cool software to snap, have a look for scientific and academic projects. Chances are that they are not packaged for Linux, and that their popularity can benefit a lot from being snapped. At the same time, you'll be making snap more popular, which is always a win. :-) Ciao, Alberto [1]: http://blog.mardy.it/2017/03/making-snap-packages-of-photogrammetry.html From joseph.wakeling at webdrake.net Fri Mar 24 22:41:55 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 24 Mar 2017 23:41:55 +0100 Subject: Meta-packages for snaps Message-ID: <8250ac22-6c5b-51f3-5b1f-e3fc5ab0faab@webdrake.net> Hello folks, Is it possible -- or are there plans for -- snap 'meta-packages' whose only job is to make sure that multiple related snap packages get installed together? The use-case I'm thinking of is a collective 'dlang' meta-package that would install a group of snaps each providing a different tool relating to the D programming language. Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Fri Mar 24 23:18:06 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 25 Mar 2017 00:18:06 +0100 Subject: Defining multiple (external) snap packages in a single git repo Message-ID: <85a98a1b-a21c-f8e5-e088-e432ab8725bf@webdrake.net> Hello all, I've been discussing with some of the D language developers about how to move forward with snap packages for the core D tools. The D language project has a dedicated git repo for building packages for various targets [1] and the obvious place to define snap packages would be there. However, would this be able to work with snap-package CI such as build.snapcraft.io or the Launchpad build tools? They both seem rather biased towards the assumption that a single git repo defines a single snap package. An alternative would of course be for D's own CI tools to run `snapcraft cleanbuild` and upload the resulting packages to the store. Any advice on how this could me made workable ... ? Thanks & best wishes, -- Joe [1] https://github.com/dlang/installer From mhall119 at gmail.com Fri Mar 24 23:27:08 2017 From: mhall119 at gmail.com (mhall119) Date: Fri, 24 Mar 2017 19:27:08 -0400 Subject: Meta-packages for snaps In-Reply-To: <8250ac22-6c5b-51f3-5b1f-e3fc5ab0faab@webdrake.net> References: <8250ac22-6c5b-51f3-5b1f-e3fc5ab0faab@webdrake.net> Message-ID: Usually you would include all related tools in the same snap. Is there a need to having them separate if they all need to be installed together? On Mar 24, 2017 6:42 PM, "Joseph Rushton Wakeling" < joseph.wakeling at webdrake.net> wrote: > Hello folks, > > Is it possible -- or are there plans for -- snap 'meta-packages' whose > only job is to make sure that multiple related snap packages get installed > together? > > The use-case I'm thinking of is a collective 'dlang' meta-package that > would install a group of snaps each providing a different tool relating to > the D programming language. > > 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 > From joseph.wakeling at webdrake.net Fri Mar 24 23:40:01 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 25 Mar 2017 00:40:01 +0100 Subject: Meta-packages for snaps In-Reply-To: References: <8250ac22-6c5b-51f3-5b1f-e3fc5ab0faab@webdrake.net> Message-ID: <87c124c1-0489-4158-af6b-57870d9405ee@webdrake.net> On 25/03/17 00:27, mhall119 wrote: > Usually you would include all related tools in the same snap. Is there a > need to having them separate if they all need to be installed together? Mostly that they don't technically _need_ to all be together. I mean, why not split stuff up if its components can be provided independently, allowing the user to pick what bits they want (or not)? Maybe I'm hanging on too much to the deb world, but multiple independent packages with a meta-package to provide the recommended collection, seems like a good pattern in general. But from your answer, I take it that it's not currently possible? From marcus.tomlinson at canonical.com Sat Mar 25 05:44:17 2017 From: marcus.tomlinson at canonical.com (Marcus Tomlinson) Date: Sat, 25 Mar 2017 07:44:17 +0200 Subject: Snapping scientific software In-Reply-To: <93329e77-a557-9568-149d-4b363c68731e@canonical.com> References: <93329e77-a557-9568-149d-4b363c68731e@canonical.com> Message-ID: Thanks for this mardy. A very interesting read (& video)! > On 24 Mar 2017, at 23:33, Alberto Mardegan wrote: > > Hi there! > Please bear with my boasting for a while. :-) I just wrote a blog > post [1] on my experience with snapping photogrammetry software, that is > software which can build a 3D model out of a set of 2D photographs. > > I also made a video overview of the process: > https://www.youtube.com/watch?v=ELHOjC_V-FE > > > What might be of interest to the readers of this mailing list, is that > there is a multitude of software tools out there which are not packaged > for Linux, mostly because their authors are more interested in > programming than in software distribution. > That is certainly the case for scientific software, where authors are > researchers who excel in their field but who often happen not to be > interested in software distribution (presumably because they target > other university researchers, who are anyway supposed to hack on the > sources). > Sometimes they are also not even very good programmers, which can make > building their software harder than what it could be. > > Snapcraft and snaps can be of enormous help in this case. > > I enjoyed writing those snaps, and despite being initially totally > indifferent about these projects, I've ended up contributing to them > with pleasure. > > The bottom line is: if you have time, and are looking for some cool > software to snap, have a look for scientific and academic projects. > Chances are that they are not packaged for Linux, and that their > popularity can benefit a lot from being snapped. > > At the same time, you'll be making snap more popular, which is always a > win. :-) > > Ciao, > Alberto > > > [1]: > http://blog.mardy.it/2017/03/making-snap-packages-of-photogrammetry.html > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From mark at ubuntu.com Sat Mar 25 09:00:39 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 25 Mar 2017 09:00:39 +0000 Subject: Defining multiple (external) snap packages in a single git repo In-Reply-To: <85a98a1b-a21c-f8e5-e088-e432ab8725bf@webdrake.net> References: <85a98a1b-a21c-f8e5-e088-e432ab8725bf@webdrake.net> Message-ID: On 24/03/17 23:18, Joseph Rushton Wakeling wrote: > I've been discussing with some of the D language developers about how > to move forward with snap packages for the core D tools. > > The D language project has a dedicated git repo for building packages > for various targets [1] and the obvious place to define snap packages > would be there. However, would this be able to work with snap-package > CI such as build.snapcraft.io or the Launchpad build tools? They both > seem rather biased towards the assumption that a single git repo > defines a single snap package. > > An alternative would of course be for D's own CI tools to run > `snapcraft cleanbuild` and upload the resulting packages to the > store. Any advice on how this could me made workable ... ? We could host multiple snapcraft.yamls in a repo, using some sort of snapcraft.*.yaml scheme, for example. So: snapcraft builds all snaps snapcraft snap foo builds snapcraft.foo.yaml Mark From mark at ubuntu.com Sat Mar 25 09:09:38 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 25 Mar 2017 09:09:38 +0000 Subject: is it the gadget snap upgradable? In-Reply-To: References: Message-ID: On 24/03/17 21:13, Nicolino Curalli wrote: > I have a doubt. That is my third favourite line in my favourite movie :) > It seem that a gadget can't be upgraded during the lifetime of a > supported board. > > I don't find anything in the snap framework for making it in a > transational manner: is my mindset wrong? > > Thank in advance for any clarification. All snaps are just snaps, they can all be upgraded. That is the vision, but there may be bugs :) The gadget snap is of course special which means we may need additional logic in snapd during upgrades. But it is very definitely our intent that you can upgrade the gadget snap for your device just as easily as any app on the device. Note though that it is the *kernel* snap that I would associate with the *board*. The gadget snap is more for the specific device in question. As an example, you might see a robot, and a drone, and a switch, and a GPS all using an Intel Joule board or a Raspberry Pi. They could all have the same *kernel* snap because they are all the same board. But they would have different gadget snaps which describe for example the pattern of GPIO breakouts or the specific usage of particular serial ports. The gadget snap would know for example "there is a GPS on ttyS1" but the kernel snap doesn't because the board is general but the device is specific. Mark From joseph.wakeling at webdrake.net Sat Mar 25 10:29:31 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 25 Mar 2017 11:29:31 +0100 Subject: Defining multiple (external) snap packages in a single git repo In-Reply-To: References: <85a98a1b-a21c-f8e5-e088-e432ab8725bf@webdrake.net> Message-ID: On 25/03/17 10:00, Mark Shuttleworth wrote: > We could host multiple snapcraft.yamls in a repo, using some sort of > snapcraft.*.yaml scheme, for example. > > So: > > snapcraft > > builds all snaps > > snapcraft snap foo > > builds snapcraft.foo.yaml Hmm, to be honest, I was thinking of a simpler setup where you'd have something like, base_dir/ foo/ snap/ snapcraft.yaml bar/ snap/ snapcraft.yaml etc... i.e. just there would be multiple folders containing independent snap package definitions. This wouldn't require any tweaks to snapcraft, but would it be possible to integrate with CI in line with what's described here? https://snapcraft.io/docs/build-snaps/ci-integration I'm anticipating it might be easier with Travis than with Launchpad but only because I don't know to what extent it's straightforward to define custom build jobs on Launchpad. The dlang installer project already uses Travis (but currently only for testing) so that might be a viable option. Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Sat Mar 25 10:53:43 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 25 Mar 2017 11:53:43 +0100 Subject: Reserved project names and cooperative transfer of ownership Message-ID: <56200b12-b9cb-7533-6dc5-7efacd57c75e@webdrake.net> ... yes, more questions :-) First, how problematic is it to organize a cooperative transfer of ownership of a reserved name between one snap publisher and another? I'm thinking of a case where a package might start as a 3rd-party project (read: yours truly) and then be made official later. I know the recommended practice is to define a different name, like `appname-whatever`, but I'm wondering what the options and difficulties might be if that wasn't wanted. Second, we discussed a while back about the possibility of reserving names for multiple apps provided by a single snap, so that instead of `snapname.appname` being the exposed command, it could just be `appname`. Even if that's not technically possible right now, is it possible to reserve those names ahead of time in anticipation of that change ... ? Thanks & best wishes, -- Joe From gustavo at niemeyer.net Sat Mar 25 19:10:04 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Sat, 25 Mar 2017 16:10:04 -0300 Subject: Request for etcdctl alias autoconnect In-Reply-To: References: Message-ID: Sounds sane. Bret, Natalia, who's the best person to handle such requests after approval? I know Jamie can edit the declarations, so he could easily do it, but that's not entirely security related. Should we just abuse ask whether Jamie would mind to handle those requests for now or is there a better person with privileged access to those declarations already? On Sat, Mar 4, 2017 at 11:38 AM, Mark Shuttleworth < mark.shuttleworth at canonical.com> wrote: > Hi folks > > The etcd database includes a client utility, etcdctl, which is included > in the etcd snap as etcd.etcdctl. > > I'm writing to the list to proposed that be aliased to the top-level > etcdctl on installation of etcd by default. The name of the utility is > very distinctive and highly unlikely to conflict with any other use of > the name. > > Thank you, > > Mark > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net From tim.sueberkrueb at web.de Sun Mar 26 13:34:36 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Sun, 26 Mar 2017 15:34:36 +0200 Subject: Contributing cloud parts In-Reply-To: <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> Message-ID: <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> Hey, I finally had the time to create the cloud part. It seems like I don't have sufficient permissions to edit the wiki page though: "You are not allowed to edit this page!" How do I request edit permissions for this page? All the best, Tim Süberkrüb On 21.03.2017 12:08, Tim Süberkrüb wrote: > Hey Didier, > > I see, thanks for your answer! > > All the best, > > Tim Süberkrüb > > > On 20.03.2017 09:42, Didier Roche wrote: >> Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : >>> Hey, >> >> Hey Tim, >>> >>> what is the process of contributing a cloud part to >>> https://wiki.ubuntu.com/snapcraft/parts (is it open for community >>> contributions?)? >>> >>> Are there any plans for having a real parts repository instead of a >>> wiki page for cloud parts? I think something like parts.snapcraft.io >>> would be pretty cool :) >>> >> >> There isn't any process as of now AFAIK. It is open for community >> contributions, so feel free to edit the wiki page adding your awesome >> cloud part :) >> snapcraft update && snapcraft search should list your part within the >> next hour (the importer runs hourly AFAIK). >> >> I agree some way to see/check metrics on parts popularity, getting >> user's feedback and such would be pretty cool! >> Cheers, >> Didier >> > > From leo.arias at canonical.com Sun Mar 26 14:30:50 2017 From: leo.arias at canonical.com (Leo Arias) Date: Sun, 26 Mar 2017 08:30:50 -0600 Subject: Contributing cloud parts In-Reply-To: <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> Message-ID: Hello Tim, On Sun, Mar 26, 2017 at 7:34 AM, Tim Süberkrüb wrote: > Hey, > > I finally had the time to create the cloud part. > > It seems like I don't have sufficient permissions to edit the wiki page > though: > > "You are not allowed to edit this page!" > > How do I request edit permissions for this page? > > All the best, > > Tim Süberkrüb I don't know how to answer your question, but while somebody gives you an answer you can share your part here and I'll put it in the wiki. pura vida -- ¡paz y baile! http://www.ubuntu.com From tim.sueberkrueb at web.de Sun Mar 26 15:08:57 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Sun, 26 Mar 2017 17:08:57 +0200 Subject: Contributing cloud parts In-Reply-To: References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> Message-ID: <5b34d71e-1ca9-92e6-9a24-47aca3551596@web.de> Hey Leo, thank you! I wanted to add the following part: --- origin: https://github.com/tim-sueberkrueb/liri-snapcraft-part.git maintainer: Tim Süberkrüb description: | Helper for Liri Apps depending on the Liri Platform snap. Includes a specific launcher and Snapcraft configuration to deduplicate build configurations. parts: [liri-app] --- All the best, Tim Süberkrüb On 26.03.2017 16:30, Leo Arias wrote: > Hello Tim, > > On Sun, Mar 26, 2017 at 7:34 AM, Tim Süberkrüb wrote: >> Hey, >> >> I finally had the time to create the cloud part. >> >> It seems like I don't have sufficient permissions to edit the wiki page >> though: >> >> "You are not allowed to edit this page!" >> >> How do I request edit permissions for this page? >> >> All the best, >> >> Tim Süberkrüb > I don't know how to answer your question, but while somebody gives you > an answer you can share your part here and I'll put it in the wiki. > > pura vida From leo.arias at canonical.com Sun Mar 26 15:15:14 2017 From: leo.arias at canonical.com (Leo Arias) Date: Sun, 26 Mar 2017 09:15:14 -0600 Subject: Contributing cloud parts In-Reply-To: <5b34d71e-1ca9-92e6-9a24-47aca3551596@web.de> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> <5b34d71e-1ca9-92e6-9a24-47aca3551596@web.de> Message-ID: Done. But note that the parser runs every hour, so you will have to wait to see it. If everything goes well, a little after the hour you can run snapcraft update && snapcraft search liri to check it. We know that our remote parts workflow is lacking. If you have suggestions or complaints, filing bugs for those would be really useful: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=wiki thanks Tim! From tim.sueberkrueb at web.de Sun Mar 26 15:26:01 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Sun, 26 Mar 2017 17:26:01 +0200 Subject: Contributing cloud parts In-Reply-To: References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> <5b34d71e-1ca9-92e6-9a24-47aca3551596@web.de> Message-ID: Thanks Leo! > We know that our remote parts workflow is lacking. If you have > suggestions or complaints, filing bugs for those would be really > useful: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=wiki What I could imagine as a proper solution would be something like "parts.snapcraft.io", similar or as part of "build.snapcraft.io" where developers could authenticate with their Ubuntu One and/or GitHub accounts and upload, manage and search for cloud parts. That would be really fantastic :) But that's just an idea. All the best, Tim On 26.03.2017 17:15, Leo Arias wrote: > Done. But note that the parser runs every hour, so you will have to > wait to see it. If everything goes well, a little after the hour you > can run snapcraft update && snapcraft search liri to check it. > > We know that our remote parts workflow is lacking. If you have > suggestions or complaints, filing bugs for those would be really > useful: https://bugs.launchpad.net/snapcraft/+bugs?field.tag=wiki > > thanks Tim! > From mhall119 at ubuntu.com Mon Mar 27 02:33:11 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Sun, 26 Mar 2017 22:33:11 -0400 Subject: Meta-packages for snaps In-Reply-To: <87c124c1-0489-4158-af6b-57870d9405ee@webdrake.net> References: <8250ac22-6c5b-51f3-5b1f-e3fc5ab0faab@webdrake.net> <87c124c1-0489-4158-af6b-57870d9405ee@webdrake.net> Message-ID: <0043a93d-9c8b-e8f4-3489-e67ee468b619@ubuntu.com> On 03/24/2017 07:40 PM, Joseph Rushton Wakeling wrote: > On 25/03/17 00:27, mhall119 wrote: >> Usually you would include all related tools in the same snap. Is there a >> need to having them separate if they all need to be installed together? > > Mostly that they don't technically _need_ to all be together. I mean, > why not split stuff up if its components can be provided independently, > allowing the user to pick what bits they want (or not)? > > Maybe I'm hanging on too much to the deb world, but multiple independent > packages with a meta-package to provide the recommended collection, > seems like a good pattern in general. But from your answer, I take it > that it's not currently possible? > Because your snap is going to pull in all of your dependencies, doing one snap per tool will likely result in more duplication and thus more disk space than providing it all as a single package. If your users are likely to want more than one of these tools, I would recommend just providing them all in one package. That way it's still easy for them to install with a single command, and they will have everything they might want already there. Michael Hall mhall119 at ubuntu.com From mhall119 at ubuntu.com Mon Mar 27 02:34:51 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Sun, 26 Mar 2017 22:34:51 -0400 Subject: Contributing cloud parts In-Reply-To: <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> Message-ID: <273118fb-82bc-bfa3-d97a-6bf39e680ebb@ubuntu.com> Have you logged out and back in to the wiki after being added to the wiki-editors group on Launchpad? Michael Hall mhall119 at ubuntu.com On 03/26/2017 09:34 AM, Tim Süberkrüb wrote: > Hey, > > I finally had the time to create the cloud part. > > It seems like I don't have sufficient permissions to edit the wiki page > though: > > "You are not allowed to edit this page!" > > How do I request edit permissions for this page? > > All the best, > > Tim Süberkrüb > > > On 21.03.2017 12:08, Tim Süberkrüb wrote: >> Hey Didier, >> >> I see, thanks for your answer! >> >> All the best, >> >> Tim Süberkrüb >> >> >> On 20.03.2017 09:42, Didier Roche wrote: >>> Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : >>>> Hey, >>> >>> Hey Tim, >>>> >>>> what is the process of contributing a cloud part to >>>> https://wiki.ubuntu.com/snapcraft/parts (is it open for community >>>> contributions?)? >>>> >>>> Are there any plans for having a real parts repository instead of a >>>> wiki page for cloud parts? I think something like parts.snapcraft.io >>>> would be pretty cool :) >>>> >>> >>> There isn't any process as of now AFAIK. It is open for community >>> contributions, so feel free to edit the wiki page adding your awesome >>> cloud part :) >>> snapcraft update && snapcraft search should list your part within the >>> next hour (the importer runs hourly AFAIK). >>> >>> I agree some way to see/check metrics on parts popularity, getting >>> user's feedback and such would be pretty cool! >>> Cheers, >>> Didier >>> >> >> > From mhall119 at ubuntu.com Mon Mar 27 02:46:53 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Sun, 26 Mar 2017 22:46:53 -0400 Subject: Reserved project names and cooperative transfer of ownership In-Reply-To: <56200b12-b9cb-7533-6dc5-7efacd57c75e@webdrake.net> References: <56200b12-b9cb-7533-6dc5-7efacd57c75e@webdrake.net> Message-ID: <6253fc12-0abc-651a-bdb1-5e0ba4ed6d59@ubuntu.com> On 03/25/2017 06:53 AM, Joseph Rushton Wakeling wrote: > ... yes, more questions :-) > > First, how problematic is it to organize a cooperative transfer of > ownership of a reserved name between one snap publisher and another? > I'm thinking of a case where a package might start as a 3rd-party > project (read: yours truly) and then be made official later. > > I know the recommended practice is to define a different name, like > `appname-whatever`, but I'm wondering what the options and difficulties > might be if that wasn't wanted. > IIRC, it's a manual process still, so it's not really problematic but it won't scale well if it becomes a very common occurrence. For now though, as long as you have the original developer's blessing to use the package name, you should be good to go ahead. We will hopefully have a more scalable solution in place before it becomes a burden on us. > Second, we discussed a while back about the possibility of reserving > names for multiple apps provided by a single snap, so that instead of > `snapname.appname` being the exposed command, it could just be > `appname`. Even if that's not technically possible right now, is it > possible to reserve those names ahead of time in anticipation of that > change ... ? > Good news, that's already there! In each appname section in your "apps:" definitions you can add a property names "aliases" that takes a yaml list of names you want to use. For example: name: snapname apps: appname: command: foo aliases: [bar] By default this will give you /snap/bin/snapname.appname But then if you run the command: "snap alias mysnap bar" you will get /snap/bin/bar which you can invoke with just "bar" from the commandline. Instead of "bar" you can use "appname" or anything else you want to make an alias for that app. This still requires a manual step after installing your snap to enable the alias, but we're working out a process to allow it to be auto-enabled, which I'm sure will be announced on this list once it's available. Michael Hall mhall119 at ubuntu.com From eloy.garcia.pca at gmail.com Mon Mar 27 07:22:03 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Mon, 27 Mar 2017 09:22:03 +0200 Subject: Moving from strict to classic confinement Message-ID: Hello everybody. I currently have a snap package published on the store. It is called wallpaperdownloader and it is a Java-based application. So far, it has been packaged using the strict confinement. The application basically downloads wallpapers from the Internet and sets the wallpaper when the user requests it. Because there are a lot of desktop environments, I have ended up using a lot of Linux commands from the java application in order to achieve these goals. For some DE there is no problem at all: for example, using gsettings interface, GNOME Shell and Unity change the background flawlessly. MATE is working properly too (I had to include mate-desktop-common as stage package) but XFCE and KDE... no way. In addition, some of the most simple features (open a file explorer for example) don't work. I have been testing the classic confinement and all these features work! In addition, I don't need to include some dependencies like desktop-gtk3 or use a shell script wrapper to launch the application. Then, I'm considering to move my snap package from stric to classic confinement but i don't know the possible implications: 1.- Are the interfaces still needed when using classic confinement? 2.- From the user point of view: if wallpaperdownloader is already installed and I change the confinement, when snapd upgrades it, will it work flawlessly? I mean, the upgrade process will be automatic or it will require manual intervention from the user? 3.- As I see classic confinement, it is a feature to make snap packages more easily but they only will work on a "classic" Ubuntu system. If Ubuntu is finally migrated to a Snappy system, I guess classic confinement won't work and all these packages should be migrated to strict confinement again, am I right? Thank you all for your time :) Best, Eloy -- Eloy García Almadén From akgrant0710 at gmail.com Mon Mar 27 07:32:21 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Mon, 27 Mar 2017 09:32:21 +0200 Subject: Moving from strict to classic confinement In-Reply-To: References: Message-ID: Hi Eloy, Your readme mentions problems with xdg-open. Take a look at: https://github.com/snapcore/snapd-xdg-open which may help. Note that the host has to have snapd-xdg-open installed. Cheers, Alistair On 27 March 2017 at 09:22, Eloy García (PC Actual) wrote: > Hello everybody. > > I currently have a snap package published on the store. It is called > wallpaperdownloader and it is a Java-based application. So far, it has been > packaged using the strict confinement. The application basically downloads > wallpapers from the Internet and sets the wallpaper when the user requests > it. Because there are a lot of desktop environments, I have ended up using > a lot of Linux commands from the java application in order to achieve these > goals. For some DE there is no problem at all: for example, using gsettings > interface, GNOME Shell and Unity change the background flawlessly. MATE is > working properly too (I had to include mate-desktop-common as stage > package) but XFCE and KDE... no way. In addition, some of the most simple > features (open a file explorer for example) don't work. > > I have been testing the classic confinement and all these features work! In > addition, I don't need to include some dependencies like desktop-gtk3 or > use a shell script wrapper to launch the application. Then, I'm considering > to move my snap package from stric to classic confinement but i don't know > the possible implications: > > 1.- Are the interfaces still needed when using classic confinement? > 2.- From the user point of view: if wallpaperdownloader is already > installed and I change the confinement, when snapd upgrades it, will it > work flawlessly? I mean, the upgrade process will be automatic or it will > require manual intervention from the user? > 3.- As I see classic confinement, it is a feature to make snap packages > more easily but they only will work on a "classic" Ubuntu system. If Ubuntu > is finally migrated to a Snappy system, I guess classic confinement won't > work and all these packages should be migrated to strict confinement again, > am I right? > > Thank you all for your time :) > > Best, > > Eloy > -- > Eloy García Almadén > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From eloy.garcia.pca at gmail.com Mon Mar 27 07:59:59 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Mon, 27 Mar 2017 09:59:59 +0200 Subject: Moving from strict to classic confinement In-Reply-To: References: Message-ID: Hi Alistair! Thanks for the tip, but this is not a problem anymore. Yep, I used "the bridge" provided by Ubuntu Core for xdg-open and it works if the user installs snapd-xdg-open :) Best, Eloy 2017-03-27 9:32 GMT+02:00 Alistair Grant : > Hi Eloy, > > Your readme mentions problems with xdg-open. Take a look at: > > https://github.com/snapcore/snapd-xdg-open > > which may help. Note that the host has to have snapd-xdg-open installed. > > Cheers, > Alistair > > On 27 March 2017 at 09:22, Eloy García (PC Actual) > wrote: > > Hello everybody. > > > > I currently have a snap package published on the store. It is called > > wallpaperdownloader and it is a Java-based application. So far, it has > been > > packaged using the strict confinement. The application basically > downloads > > wallpapers from the Internet and sets the wallpaper when the user > requests > > it. Because there are a lot of desktop environments, I have ended up > using > > a lot of Linux commands from the java application in order to achieve > these > > goals. For some DE there is no problem at all: for example, using > gsettings > > interface, GNOME Shell and Unity change the background flawlessly. MATE > is > > working properly too (I had to include mate-desktop-common as stage > > package) but XFCE and KDE... no way. In addition, some of the most simple > > features (open a file explorer for example) don't work. > > > > I have been testing the classic confinement and all these features work! > In > > addition, I don't need to include some dependencies like desktop-gtk3 or > > use a shell script wrapper to launch the application. Then, I'm > considering > > to move my snap package from stric to classic confinement but i don't > know > > the possible implications: > > > > 1.- Are the interfaces still needed when using classic confinement? > > 2.- From the user point of view: if wallpaperdownloader is already > > installed and I change the confinement, when snapd upgrades it, will it > > work flawlessly? I mean, the upgrade process will be automatic or it will > > require manual intervention from the user? > > 3.- As I see classic confinement, it is a feature to make snap packages > > more easily but they only will work on a "classic" Ubuntu system. If > Ubuntu > > is finally migrated to a Snappy system, I guess classic confinement won't > > work and all these packages should be migrated to strict confinement > again, > > am I right? > > > > Thank you all for your time :) > > > > Best, > > > > Eloy > > -- > > Eloy García Almadén > > -- > > 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 > -- Eloy García Almadén From tim.sueberkrueb at web.de Mon Mar 27 10:22:51 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Mon, 27 Mar 2017 12:22:51 +0200 Subject: Contributing cloud parts In-Reply-To: <273118fb-82bc-bfa3-d97a-6bf39e680ebb@ubuntu.com> References: <4c9caeef-e57c-b7ce-3717-c34fa57f6249@web.de> <322e114e-463d-a043-0b22-ee0629a9f52b@ubuntu.com> <101835ad-c9ce-2992-bc3a-eee706875a16@web.de> <020d0ccb-757b-b135-0e42-b6518b01aadb@web.de> <273118fb-82bc-bfa3-d97a-6bf39e680ebb@ubuntu.com> Message-ID: <63373e08-56db-d857-f98f-d9c614aa796a@web.de> Hey Michael, that was the reason! Thank you! Have a nice day, Tim Süberkrüb On 27.03.2017 04:34, Michael Hall wrote: > Have you logged out and back in to the wiki after being added to the > wiki-editors group on Launchpad? > > Michael Hall > mhall119 at ubuntu.com > > On 03/26/2017 09:34 AM, Tim Süberkrüb wrote: >> Hey, >> >> I finally had the time to create the cloud part. >> >> It seems like I don't have sufficient permissions to edit the wiki page >> though: >> >> "You are not allowed to edit this page!" >> >> How do I request edit permissions for this page? >> >> All the best, >> >> Tim Süberkrüb >> >> >> On 21.03.2017 12:08, Tim Süberkrüb wrote: >>> Hey Didier, >>> >>> I see, thanks for your answer! >>> >>> All the best, >>> >>> Tim Süberkrüb >>> >>> >>> On 20.03.2017 09:42, Didier Roche wrote: >>>> Le 17/03/2017 à 19:13, Tim Süberkrüb a écrit : >>>>> Hey, >>>> Hey Tim, >>>>> what is the process of contributing a cloud part to >>>>> https://wiki.ubuntu.com/snapcraft/parts (is it open for community >>>>> contributions?)? >>>>> >>>>> Are there any plans for having a real parts repository instead of a >>>>> wiki page for cloud parts? I think something like parts.snapcraft.io >>>>> would be pretty cool :) >>>>> >>>> There isn't any process as of now AFAIK. It is open for community >>>> contributions, so feel free to edit the wiki page adding your awesome >>>> cloud part :) >>>> snapcraft update && snapcraft search should list your part within the >>>> next hour (the importer runs hourly AFAIK). >>>> >>>> I agree some way to see/check metrics on parts popularity, getting >>>> user's feedback and such would be pretty cool! >>>> Cheers, >>>> Didier >>>> >>> From davebracan at yandex.com Wed Mar 22 13:47:40 2017 From: davebracan at yandex.com (Brian) Date: Wed, 22 Mar 2017 14:47:40 +0100 Subject: prevent slips and falls Message-ID: <94e2b02d998018e95d5f079224b75886@harborfreight.com> Hello again, Do you own or manage a restaurant, hotel, hospital, etc? Slip fall accidents are the 2nd leading cause of accidental death in the U.S. after automobile accidents. We can make your floors slip-resistant and safe with one 30 minute treatment and it will last at least 4 years. In doors or out doors. Do it yourself or our technicians can do it for you. 30 minutes to apply. Ready to walk on immediately. Regards, Brian Hayes From bret.barker at canonical.com Mon Mar 27 12:51:42 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Mon, 27 Mar 2017 08:51:42 -0400 Subject: Reserved project names and cooperative transfer of ownership In-Reply-To: <6253fc12-0abc-651a-bdb1-5e0ba4ed6d59@ubuntu.com> References: <56200b12-b9cb-7533-6dc5-7efacd57c75e@webdrake.net> <6253fc12-0abc-651a-bdb1-5e0ba4ed6d59@ubuntu.com> Message-ID: <20170327125141.GL34265@abitrandom.net> On Sun, Mar 26, 2017 at 10:46:53PM -0400, Michael Hall wrote: > On 03/25/2017 06:53 AM, Joseph Rushton Wakeling wrote: > > ... yes, more questions :-) > > > > First, how problematic is it to organize a cooperative transfer of > > ownership of a reserved name between one snap publisher and another? > > I'm thinking of a case where a package might start as a 3rd-party > > project (read: yours truly) and then be made official later. > > > > I know the recommended practice is to define a different name, like > > `appname-whatever`, but I'm wondering what the options and difficulties > > might be if that wasn't wanted. > > > > IIRC, it's a manual process still, so it's not really problematic but it > won't scale well if it becomes a very common occurrence. For now though, > as long as you have the original developer's blessing to use the package > name, you should be good to go ahead. We will hopefully have a more > scalable solution in place before it becomes a burden on us. > This work is well underway and will make it painless for the existing publisher of a snap to transfer it over to another developer. We will announce the details here when it is ready. Meanwhile, if you are just testing things out we recommend using appname-username pattern, or if you intend to steward the snap and commit to regular quality releases then you can request ownership of the base appname via the name registration process. -bret From jamie at canonical.com Mon Mar 27 13:11:25 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 27 Mar 2017 08:11:25 -0500 Subject: [Fwd: Re: Request for etcdctl alias autoconnect] References: <1488813402.4393.14.camel@canonical.com> Message-ID: <1490620285.3809.29.camel@canonical.com> This got caught up in an issue with the mailing list server and never made it to the list. Resending now-- sorry for the delay in response to the list. -------- Forwarded Message -------- From: Jamie Strandboge To: Mark Shuttleworth Cc: Snapcraft Subject: Re: Request for etcdctl alias autoconnect Date: Mon, 06 Mar 2017 09:16:42 -0600 On Sat, 2017-03-04 at 15:38 +0100, Mark Shuttleworth wrote: > > Hi folks > Hi > The etcd database includes a client utility, etcdctl, which is included > in the etcd snap as etcd.etcdctl. > > I'm writing to the list to proposed that be aliased to the top-level > etcdctl on installation of etcd by default. The name of the utility is > very distinctive and highly unlikely to conflict with any other use of > the name. Granted. This should be in effect immediately. --  Jamie Strandboge             | http://www.canonical.com -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Mon Mar 27 13:14:15 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 27 Mar 2017 13:14:15 +0000 Subject: Moving from strict to classic confinement In-Reply-To: References: Message-ID: On Mon, 27 Mar 2017 09:22:03 +0200, Eloy García (PC Actual) wrote: > Hello everybody. > > I currently have a snap package published on the store. It is called > wallpaperdownloader and it is a Java-based application. So far, it has been > packaged using the strict confinement. The application basically downloads > wallpapers from the Internet and sets the wallpaper when the user requests > it. Because there are a lot of desktop environments, I have ended up using > a lot of Linux commands from the java application in order to achieve these > goals. For some DE there is no problem at all: for example, using gsettings > interface, GNOME Shell and Unity change the background flawlessly. MATE is > working properly too (I had to include mate-desktop-common as stage > package) but XFCE and KDE... no way. In addition, some of the most simple > features (open a file explorer for example) don't work. > > I have been testing the classic confinement and all these features work! In > addition, I don't need to include some dependencies like desktop-gtk3 or > use a shell script wrapper to launch the application. Then, I'm considering > to move my snap package from stric to classic confinement but i don't know > the possible implications: > > 1.- Are the interfaces still needed when using classic confinement? No, they are not. > 2.- From the user point of view: if wallpaperdownloader is already > installed and I change the confinement, when snapd upgrades it, will it > work flawlessly? I mean, the upgrade process will be automatic or it will > require manual intervention from the user? They will need updating. HOME in strict confinement points to the segregated data stores, in classic it is the traditional home. > 3.- As I see classic confinement, it is a feature to make snap packages > more easily but they only will work on a "classic" Ubuntu system. If Ubuntu > is finally migrated to a Snappy system, I guess classic confinement won't > work and all these packages should be migrated to strict confinement again, > am I right? This is correct, a pure snappy based system is not a classic system so classic confinement does not apply. > Thank you all for your time :) A few more considerations: - I would stick to strict having gotten this far and just work on unblocking yourself with interfaces or other means. - strict confinment means you have a stable base (core), while classic means you will have an unstable one (well, not unstable, just different depending on the system where the snap is installed), which means you will have a different set of bugs to deal with depending on the base classic system where the snap is installed. - you shouldn't rely on libraries on classic systems, not all of them with have gtk3 nor will all of them be ABI compatible with the glibc stuff your snap uses (this might be a different story with java). - There is a missing feature in snapd/snap-confine to restrict the library paths the classic confined snap can see, so you need to make sure this is the case for you. This can be mitigated in snapcraft if you build all runnables from parts (in your case the jre which I bet wouldn't be easy). - I am going to be talking again a bout classic confined snaps in one of the upcoming Ubuntu Testing days, so if interested, keep an eye on that ;-) Cheers Sergio -- Sent using Dekko from my Ubuntu device From jamie at canonical.com Mon Mar 27 13:20:16 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 27 Mar 2017 08:20:16 -0500 Subject: Request for etcdctl alias autoconnect In-Reply-To: References: Message-ID: <1490620816.3809.31.camel@canonical.com> On Sat, 2017-03-25 at 16:10 -0300, Gustavo Niemeyer wrote: > Sounds sane. > > Bret, Natalia, who's the best person to handle such requests after > approval?  I know Jamie can edit the declarations, so he could easily do > it, but that's not entirely security related. Should we just abuse ask > whether Jamie would mind to handle those requests for now or is there a > better person with privileged access to those declarations already? > I actually did this some time ago but due to mailing list issues, my reply was not seen: https://lists.ubuntu.com/archives/snapcraft/2017-March/003669.html I'm of course fine with other reviewers granting auto aliases in the future. -- 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 renato.filho at canonical.com Mon Mar 27 13:31:40 2017 From: renato.filho at canonical.com (Renato Filho) Date: Mon, 27 Mar 2017 10:31:40 -0300 Subject: Moving from strict to classic confinement In-Reply-To: References: Message-ID: 2017-03-27 4:22 GMT-03:00 Eloy García (PC Actual) : > Hello everybody. > > I currently have a snap package published on the store. It is called > wallpaperdownloader and it is a Java-based application. So far, it has been > packaged using the strict confinement. The application basically downloads > wallpapers from the Internet and sets the wallpaper when the user requests > it. Because there are a lot of desktop environments, I have ended up using > a lot of Linux commands from the java application in order to achieve these > goals. For some DE there is no problem at all: for example, using gsettings > interface, GNOME Shell and Unity change the background flawlessly. MATE is > working properly too (I had to include mate-desktop-common as stage > package) but XFCE and KDE... no way. In addition, some of the most simple > features (open a file explorer for example) don't work. I am not sure what exactly the problem that you have to change KDE wallpapers but it can be related with the fact that you are using "desktop-gtk3", because this only prepare the environment for gtk apps. Some environment vars will be missing for Qt apps. The options that you have are: 1 - create a wrapper file and export the vars by yourself. 2 - Use "ubuntu-app-platform" that contains libraries and a launcher compatible with most gtk and qt apps. I hope this help From n.curalli at domotz.com Mon Mar 27 13:50:51 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Mon, 27 Mar 2017 13:50:51 +0000 Subject: some console-conf start-up traceback Message-ID: Hi all, we have a strange output on console after the first boot: the first boot go straight without any traceback. We use our kernel snap on a orangepi plus 2e board (kernel 4.9). The traceback is the following: [ OK ] Reached target Login Prompts. [ OK ] Started OpenBSD Secure Shell server. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Starting Update UTMP about System Runlevel Changes... [ OK ] Started Update UTMP about System Runlevel Changes. Traceback (most recent call last): File "/usr/share/subiquity/console-conf-write-login-details", line 21, in sys.exit(write_login_details_standalone()) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 136, in write_login_details_standalone write_login_details(sys.stdout, owner['username'], ips) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 115, in write_login_details sshcommands=sshcommands, host_key_info=host_key_info(), tty_name=tty_name, first_ip=ips[0])) IndexError: list index out of range Traceback (most recent call last): File "/usr/share/subiquity/console-conf-write-login-details", line 21, in sys.exit(write_login_details_standalone()) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 136, in write_login_details_standalone write_login_details(sys.stdout, owner['username'], ips) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 115, in write_login_details sshcommands=sshcommands, host_key_info=host_key_info(), tty_name=tty_name, first_ip=ips[0])) IndexError: list index out of range IndexError: list index out of range Traceback (most recent call last): File "/usr/share/subiquity/console-conf-write-login-details", line 21, in sys.exit(write_login_details_standalone()) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 136, in write_login_details_standalone write_login_details(sys.stdout, owner['username'], ips) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 115, in write_login_details sshcommands=sshcommands, host_key_info=host_key_info(), tty_name=tty_name, first_ip=ips[0])) IndexError: list index out of range Traceback (most recent call last): File "/usr/share/subiquity/console-conf-write-login-details", line 21, in sys.exit(write_login_details_standalone()) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 136, in write_login_details_standalone write_login_details(sys.stdout, owner['username'], ips) File "/usr/share/subiquity/console_conf/controllers/identity.py", line 115, in write_login_details sshcommands=sshcommands, host_key_info=host_key_info(), tty_name=tty_name, first_ip=ips[0])) IndexError: list index out of range Ubuntu Core 16 on 192.168.5.107 (ttyS0) The host key fingerprints are: ...... To login: ssh domotz at 192.168.5.107 The number of traceback block seem completely random. The board networking works fine and we can login on system. Some ideas about explanation of this strange output? Thanks, Nicolino From dmitrii.shcherbakov at canonical.com Mon Mar 27 19:13:43 2017 From: dmitrii.shcherbakov at canonical.com (Dmitrii Shcherbakov) Date: Mon, 27 Mar 2017 22:13:43 +0300 Subject: Modular Application Updates: Libvirt and QEMU Message-ID: Hi everybody, 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. The update process is not graceful as all processes are terminated (SIGTERM) or killed (SIGKILL) by snapd if termination was not successful - this will result in a file system corruption for VMs due to caches not being dropped. Using 2 separate snaps does not solve the problem. ---- I gave an example of libvirt and qemu but this problem is very generic if you think more about it. Both QEMU and Libvirt are quite complex and use many Linux kernel mechanisms, therefore, they are a good example of something complicated when it comes to snapping. Libvirt/qemu context: 1 libvirt has many drivers for domain creation, one of them being QEMU; 2 libvirt communicates with QEMU via a unix socket. QEMU creates that socket upon startup and talks with anybody over QEMU Machine Protocol (you can kill libvirt and use that text protocol yourself via nc utility - nothing prevents you from doing that); 3 QEMU instances are daemonized so a given qemu process is not a child of libvirt - pid 1 is its parent - yet another reason to stay alive if libvirtd is dead; 4 It is not mandatory to have a running libvirtd process for QEMU operation; 5 Libvirt may use cgroups to constrain qemu processes (https://libvirt.org/cgroups.html#systemdLayout). A single pid can only belong to one cgroup in a given cgroupv1 hierarchy; 6 QEMU binary and shared object updates done by a package manager (via mv) do not require QEMU processes to be killed; 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. How a systemd unit of a combined libvirt & qemu snap looks like: snap.libvirt.libvirt-bin.service - Service for snap application libvirt.libvirt-bin Loaded: loaded (/etc/systemd/system/snap.libvirt.libvirt-bin.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2017-03-26 03:29:06 MSK; 1 day 16h ago Main PID: 17128 (rundaemon) Tasks: 23 (limit: 4915) Memory: 56.1M CPU: 16min 1.435s CGroup: /system.slice/snap.libvirt.libvirt-bin.service ├─17128 /bin/sh /snap/libvirt/x1/bin/rundaemon sbin/libvirtd /snap/libvirt/current/bin /snap/libvirt/current/usr/bin ├─17155 /snap/libvirt/x1/sbin/libvirtd └─17357 /snap/libvirt/current/bin/qemu-system-x86_64 -name guest=ubuntu-xenial,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/snap/libvirt/current/lib/libvirt/qemu/domain-1-ubuntu-xenial/master-key ----------- In the snapd code, this is how updates are implemented with regards to process lifetime: https://paste.ubuntu.com/24262077/ 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 (new 'dlopen's or 'open's before restart will, of course, use the new files); 3 The old and the new files reside on the same file system (a package may have files on multiple file systems but for each individual old file/new file pairs the file system remains the same). With snaps this is completely different: 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; 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). ----------- It is hardly possible to separate QEMU and Libvirt into different snaps so that QEMU processes are not in the same cgroup used by systemd to kill all unit-related processes. Even if I hacked my way to do this by some sort of an executor process on the QEMU snap side which libvirt would run, it still wouldn't be the same: all qemu processes would be in the same cgroup and would be killed on QEMU snap updates (which would be better than on a combined snap updates but still not good enough). The bottom line is that packaging these two applications as snaps results in a serious change of application behavior. Other applications are potentially affected (lxd comes to mind). Any feedback/ideas with regards to the above? It doesn't look right to force a certain application behavior due to a packaging system change (in this case - VM downtime and fs corruption). Best Regards, Dmitrii Shcherbakov Field Software Engineer IRC (freenode): Dmitrii-Sh From michael.hudson at canonical.com Mon Mar 27 21:38:41 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Tue, 28 Mar 2017 10:38:41 +1300 Subject: some console-conf start-up traceback In-Reply-To: References: Message-ID: On 28 March 2017 at 02:50, Nicolino Curalli wrote: > Hi all, > > we have a strange output on console after the first boot: the first boot > go straight without any traceback. > > We use our kernel snap on a orangepi plus 2e board (kernel 4.9). > > The traceback is the following: > > > [ OK ] Reached target Login Prompts. > [ OK ] Started OpenBSD Secure Shell server. > [ OK ] Reached target Multi-User System. > [ OK ] Reached target Graphical Interface. > Starting Update UTMP about System Runlevel Changes... > [ OK ] Started Update UTMP about System Runlevel Changes. > > Traceback (most recent call last): > File "/usr/share/subiquity/console-conf-write-login-details", line 21, > in > sys.exit(write_login_details_standalone()) > File "/usr/share/subiquity/console_conf/controllers/identity.py", line > 136, in write_login_details_standalone > write_login_details(sys.stdout, owner['username'], ips) > File "/usr/share/subiquity/console_conf/controllers/identity.py", line > 115, in write_login_details > sshcommands=sshcommands, host_key_info=host_key_info(), > tty_name=tty_name, first_ip=ips[0])) > IndexError: list index out of range > Ah, this would be a bug. The script that generates the "ssh domotz at 192.168.5.107" page is clearly running before the system gets an IP address (via DHCP I guess?) and crash looping until the system does have an IP address. I'll see what I can come up with to fix this. Cheers, mwh From brian at ubuntu.com Mon Mar 27 22:47:05 2017 From: brian at ubuntu.com (Brian Murray) Date: Mon, 27 Mar 2017 15:47:05 -0700 Subject: Cleaning up on snap removal Message-ID: <20170327224704.GJ4213@murraytwins.com> I'm working on a snap of apport and when it is installed a daemon is run that modifies "/proc/sys/kernel/core_pattern". How can I modify that file back to what it originally was when the snap is removed? Thanks! -- Brian Murray -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From kyle.fazzari at canonical.com Mon Mar 27 22:56:26 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 27 Mar 2017 15:56:26 -0700 Subject: Cleaning up on snap removal In-Reply-To: <20170327224704.GJ4213@murraytwins.com> References: <20170327224704.GJ4213@murraytwins.com> Message-ID: <59c795b2-6ba2-a287-503b-7a402f79d1cd@canonical.com> On 03/27/2017 03:47 PM, Brian Murray wrote: > I'm working on a snap of apport and when it is installed a daemon is run > that modifies "/proc/sys/kernel/core_pattern". How can I modify that > file back to what it originally was when the snap is removed? That sounds like the justification behind a feature request for an uninstall hook: https://bugs.launchpad.net/snapd/+bug/1661126 . -- 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 michal.sawicz at canonical.com Mon Mar 27 23:07:59 2017 From: michal.sawicz at canonical.com (=?UTF-8?Q?Micha=c5=82_Sawicz?=) Date: Tue, 28 Mar 2017 01:07:59 +0200 Subject: Cleaning up on snap removal In-Reply-To: <59c795b2-6ba2-a287-503b-7a402f79d1cd@canonical.com> References: <20170327224704.GJ4213@murraytwins.com> <59c795b2-6ba2-a287-503b-7a402f79d1cd@canonical.com> Message-ID: <6eec3013-3225-44ff-efb8-25d9f489a43f@canonical.com> W dniu 28.03.2017 o 00:56, Kyle Fazzari pisze: > On 03/27/2017 03:47 PM, Brian Murray wrote: >> I'm working on a snap of apport and when it is installed a daemon is run >> that modifies "/proc/sys/kernel/core_pattern". How can I modify that >> file back to what it originally was when the snap is removed? > That sounds like the justification behind a feature request for an > uninstall hook: https://bugs.launchpad.net/snapd/+bug/1661126 . Shouldn't that get cleaned up on daemon stop in this case, though? -- Michał Sawicz Canonical Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: OpenPGP digital signature URL: From brian at ubuntu.com Mon Mar 27 23:23:28 2017 From: brian at ubuntu.com (Brian Murray) Date: Mon, 27 Mar 2017 16:23:28 -0700 Subject: Cleaning up on snap removal In-Reply-To: <6eec3013-3225-44ff-efb8-25d9f489a43f@canonical.com> References: <20170327224704.GJ4213@murraytwins.com> <59c795b2-6ba2-a287-503b-7a402f79d1cd@canonical.com> <6eec3013-3225-44ff-efb8-25d9f489a43f@canonical.com> Message-ID: <20170327232328.GK4213@murraytwins.com> On Tue, Mar 28, 2017 at 01:07:59AM +0200, Michał Sawicz wrote: > W dniu 28.03.2017 o 00:56, Kyle Fazzari pisze: > > On 03/27/2017 03:47 PM, Brian Murray wrote: > >> I'm working on a snap of apport and when it is installed a daemon is run > >> that modifies "/proc/sys/kernel/core_pattern". How can I modify that > >> file back to what it originally was when the snap is removed? > > That sounds like the justification behind a feature request for an > > uninstall hook: https://bugs.launchpad.net/snapd/+bug/1661126 . > > Shouldn't that get cleaned up on daemon stop in this case, though? In my particular case the daemon is not a long running one and using stop-command ended up immediately reverting the change in /proc. -- Brian Murray -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From michael.hudson at canonical.com Tue Mar 28 02:58:00 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Tue, 28 Mar 2017 15:58:00 +1300 Subject: some console-conf start-up traceback In-Reply-To: References: Message-ID: On 28 March 2017 at 10:38, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > > On 28 March 2017 at 02:50, Nicolino Curalli wrote: > >> Hi all, >> >> we have a strange output on console after the first boot: the first boot >> go straight without any traceback. >> >> We use our kernel snap on a orangepi plus 2e board (kernel 4.9). >> >> The traceback is the following: >> >> >> [ OK ] Reached target Login Prompts. >> [ OK ] Started OpenBSD Secure Shell server. >> [ OK ] Reached target Multi-User System. >> [ OK ] Reached target Graphical Interface. >> Starting Update UTMP about System Runlevel Changes... >> [ OK ] Started Update UTMP about System Runlevel Changes. >> >> Traceback (most recent call last): >> File "/usr/share/subiquity/console-conf-write-login-details", line 21, >> in >> sys.exit(write_login_details_standalone()) >> File "/usr/share/subiquity/console_conf/controllers/identity.py", line >> 136, in write_login_details_standalone >> write_login_details(sys.stdout, owner['username'], ips) >> File "/usr/share/subiquity/console_conf/controllers/identity.py", line >> 115, in write_login_details >> sshcommands=sshcommands, host_key_info=host_key_info(), >> tty_name=tty_name, first_ip=ips[0])) >> IndexError: list index out of range >> > > Ah, this would be a bug. The script that generates the "ssh > domotz at 192.168.5.107" page is clearly running before the system gets an > IP address (via DHCP I guess?) and crash looping until the system does have > an IP address. > > I'll see what I can come up with to fix this. > Hi again, this should be fixed by https://github.com/CanonicalLtd/subiquity/pull/209 (which I don't expect you to try, I'll let you know when it reaches the core snap in the edge channel). By far the hardest part of this was figuring out a way to test it! Thanks for the report. Cheers, mwh From alfonso.sanchez-beato at canonical.com Tue Mar 28 06:13:24 2017 From: alfonso.sanchez-beato at canonical.com (Alfonso Sanchez-Beato) Date: Tue, 28 Mar 2017 08:13:24 +0200 Subject: Strategy for Snaps with Debugging Symbols In-Reply-To: References: Message-ID: On Fri, Mar 24, 2017 at 6:49 PM, Dmitrii Shcherbakov < dmitrii.shcherbakov at canonical.com> wrote: > Hi everybody, > > My question is in the context of a libvirt & qemu snap but I think it is > worthwhile to discuss that for any software written in C, C++ or other > compiled languages for which debugging symbols can be generated. > > A lot of debugging tasks can be solved by looking at logs and {s,l}tracing > but sometimes this is not enough. > > With Debian packages the approaches are: > > 1) to provide your own -dbg package; > 2) let https://launchpad.net/ubuntu/+source/pkg-create-dbgsym generate it > and add a ddebs.ubuntu.com repo on demand. > > https://wiki.ubuntu.com/Debug%20Symbol%20Packages > https://wiki.ubuntu.com/AptElfDebugSymbols > https://wiki.debian.org/AutomaticDebugPackages > > One idea for snaps is to use -dbg tracks which are going to contain snaps > with embedded debugging symbols. Of course, some snaps may contain a number > of services so you'd have to customize your build process and create > additional automation around snapcraft to make it more manageable. > I would love to see this, it would ease a lot the debugging pain for snaps. IMHO using a debugging track makes lots of sense, provided gdbserver/gdb in Ubuntu Core can be configured to find the symbols automatically. > > https://snapcraft.io/docs/reference/channels > > Another issue is that with separate snaps that would have debugging symbols > you'd have to replace a non-debug snap with a debug snap which would > complicate things if you had a certain state already and did not want a > transactional erase of the state you wanted to debug. > > In the case of ddebs you can just download symbols and use them with an > existing application while with a separate snap you need to perform a > replacement. > > I was wondering if anybody thought about it yet and, if not, to start this > discussion here. > > Thanks in advance! > > Best Regards, > Dmitrii Shcherbakov > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From christian.ehrhardt at canonical.com Tue Mar 28 07:44:41 2017 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 28 Mar 2017 09:44:41 +0200 Subject: Strategy for Snaps with Debugging Symbols In-Reply-To: References: Message-ID: On Tue, Mar 28, 2017 at 8:13 AM, Alfonso Sanchez-Beato < alfonso.sanchez-beato at canonical.com> wrote: > > One idea for snaps is to use -dbg tracks which are going to contain snaps > > with embedded debugging symbols. Of course, some snaps may contain a > number > > of services so you'd have to customize your build process and create > > additional automation around snapcraft to make it more manageable. > > > > I would love to see this, it would ease a lot the debugging pain for snaps. > IMHO using a debugging track makes lots of sense, provided gdbserver/gdb in > Ubuntu Core can be configured to find the symbols automatically. It might come down to teach gdb and co certain path. On the classic packaging is is about /usr/lib/debug prefixing the canonical path of the binary. So lib and lib+debug symbols are: $ file /usr/lib/debug/usr/lib/libvirt/connection-driver/libvirt_driver_interface.so /usr/lib/debug/usr/lib/libvirt/connection-driver/libvirt_driver_interface.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1d163a878a64d3f180806e713ad0cb9363492316, not stripped $ file /usr/lib/libvirt/connection-driver/libvirt_driver_interface.so /usr/lib/libvirt/connection-driver/libvirt_driver_interface.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=1d163a878a64d3f180806e713ad0cb9363492316, stripped The matching flag build-id in there make sure programs can check they match and pick it up automatically [1]. Now a binary of a snap appears like in a versioned path, but there is the current link which should be stable. So the binary of e.g. the latest vlc snap is always in: /snap/vlc/current/bin/vlc That would mean if there would be symbols at "/usr/lib/debug/snap/vlc/current/bin/vlc.debug" would likely work as of today in case you want to link yourself something up. Actually I think it would be fair that snaps could "own" the snap subdir of the global debug dir being "/usr/lib/debug/snap" and mirror the snap layout there but populated with the debug symbols. Also I agree that this should not be a manual task of some sort, just like the .deb packaging an optional -dbg snap or such could fall out of any build that does contain the non-stripped binaries. All that is true for a classic gdb, but a snapped gdb will itself run confined and in its local path to some extend - that has to be considered as well going forward. Also the whole command semantic has to be sound and tasteful for those who want to use it, while not distracting non debugging snap users too much. As the debug snaps clearly have a reduced subset of actions (e.g. no interfaces) maybe one option would be to hide that reduced subset all behind one subcommand like: "snap dbg [find|list|install|...]" ? [1]: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd From christian.ehrhardt at canonical.com Tue Mar 28 08:26:08 2017 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Tue, 28 Mar 2017 10:26:08 +0200 Subject: Modular Application Updates: Libvirt and QEMU In-Reply-To: References: Message-ID: 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. 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/ From n.curalli at domotz.com Tue Mar 28 09:31:32 2017 From: n.curalli at domotz.com (Nicolino Curalli) Date: Tue, 28 Mar 2017 09:31:32 +0000 Subject: a mechanism to make the snap kernel updrade failed Message-ID: 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 From timonmailinglist at gmail.com Tue Mar 28 09:35:31 2017 From: timonmailinglist at gmail.com (=?UTF-8?Q?Simon_St=c3=bcrz?=) Date: Tue, 28 Mar 2017 11:35:31 +0200 Subject: Install snaps in armhf chroot Message-ID: <408c8c07-4487-6ec5-9c69-1e3ccd6a50bc@gmail.com> Hi everyone! I'm currently building an armhf system using live-build and running snapd on it. I wanted to pre-install snaps during the image build process and run into several problems. Using qemu-arm-static in the chroot I get following error: $ snap install core fatal error: rt_sigaction failure runtime stack: runtime.throw(0xf6d56af9, 0x14) /usr/lib/go-1.7/src/runtime/panic.go:566 +0x80 runtime.setsigstack(0x21) /usr/lib/go-1.7/src/runtime/os_linux.go:426 +0xf4 runtime.initsig(0xf6febc00) /usr/lib/go-1.7/src/runtime/signal1_unix.go:78 +0x1b8 runtime.mstart1() /usr/lib/go-1.7/src/runtime/proc.go:1122 +0xf0 runtime.mstart() /usr/lib/go-1.7/src/runtime/proc.go:1096 +0x84 goroutine 1 [runnable]: runtime.main() /usr/lib/go-1.7/src/runtime/proc.go:106 runtime.goexit() /usr/lib/go-1.7/src/runtime/asm_arm.s:998 +0x4 goroutine 17 [syscall, locked to thread]: runtime.goexit() /usr/lib/go-1.7/src/runtime/asm_arm.s:998 +0x4 Looks like this is go / qemu-arm bug and I have found several bug reports on this issue without any helping information: https://bugs.launchpad.net/ubuntu/+source/golang/+bug/1501651 https://bugs.launchpad.net/ubuntu/+source/golang-1.6/+bug/1603846 Then I checked how the ubuntu-image tool works and pre-install snaps (but I didn't get the trick): https://git.launchpad.net/ubuntu-image/tree/ubuntu_image/builder.py?h=xenial#n117 https://git.launchpad.net/ubuntu-image/tree/ubuntu_image/helpers.py?h=xenial#n102 Is there any other possibility to install snaps in a armhf chroot? Thanks in advance, Simon From john.lenton at canonical.com Tue Mar 28 09:58:37 2017 From: john.lenton at canonical.com (John Lenton) Date: Tue, 28 Mar 2017 10:58:37 +0100 Subject: Install snaps in armhf chroot In-Reply-To: <408c8c07-4487-6ec5-9c69-1e3ccd6a50bc@gmail.com> References: <408c8c07-4487-6ec5-9c69-1e3ccd6a50bc@gmail.com> Message-ID: On 28 March 2017 at 10:35, Simon Stürz wrote: > > I'm currently building an armhf system using live-build and running > snapd on it. I wanted to pre-install snaps during the image build > process and run into several problems. > Using qemu-arm-static in the chroot I get following error: the go developers decided to not support being run in qemu: https://github.com/golang/go/issues/13024 “As beefy arm boards are widely available, I don't think we should invest into qemu usermode emulation any more. It's slower than the more powerful arm boards, and it doesn't support multithreaded programs well.” From timonmailinglist at gmail.com Tue Mar 28 10:18:21 2017 From: timonmailinglist at gmail.com (=?UTF-8?Q?Simon_St=c3=bcrz?=) Date: Tue, 28 Mar 2017 12:18:21 +0200 Subject: Install snaps in armhf chroot In-Reply-To: References: <408c8c07-4487-6ec5-9c69-1e3ccd6a50bc@gmail.com> Message-ID: <9e53e896-5b96-3dac-9e5a-dd14b64c1990@gmail.com> Hi John, thanks for the quick reply! So building the image in a native armhf environment should do the trick. Regards, Simon On 2017-03-28 11:58, John Lenton wrote: > On 28 March 2017 at 10:35, Simon Stürz wrote: >> I'm currently building an armhf system using live-build and running >> snapd on it. I wanted to pre-install snaps during the image build >> process and run into several problems. >> Using qemu-arm-static in the chroot I get following error: > the go developers decided to not support being run in qemu: > > https://github.com/golang/go/issues/13024 > > “As beefy arm boards are widely available, I don't think we should > invest into qemu usermode emulation any more. It's slower than the > more powerful arm boards, and it doesn't support multithreaded > programs well.” > From eloy.garcia.pca at gmail.com Tue Mar 28 13:26:31 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 28 Mar 2017 15:26:31 +0200 Subject: Moving from strict to classic confinement In-Reply-To: References: Message-ID: 2017-03-27 15:14 GMT+02:00 Sergio Schvezov : > On Mon, 27 Mar 2017 09:22:03 +0200, Eloy García (PC Actual) wrote: > > Hello everybody. > > > > I currently have a snap package published on the store. It is called > > wallpaperdownloader and it is a Java-based application. So far, it has > been > > packaged using the strict confinement. The application basically > downloads > > wallpapers from the Internet and sets the wallpaper when the user > requests > > it. Because there are a lot of desktop environments, I have ended up > using > > a lot of Linux commands from the java application in order to achieve > these > > goals. For some DE there is no problem at all: for example, using > gsettings > > interface, GNOME Shell and Unity change the background flawlessly. MATE > is > > working properly too (I had to include mate-desktop-common as stage > > package) but XFCE and KDE... no way. In addition, some of the most simple > > features (open a file explorer for example) don't work. > > > > I have been testing the classic confinement and all these features work! > In > > addition, I don't need to include some dependencies like desktop-gtk3 or > > use a shell script wrapper to launch the application. Then, I'm > considering > > to move my snap package from stric to classic confinement but i don't > know > > the possible implications: > > > > 1.- Are the interfaces still needed when using classic confinement? > > No, they are not. > > > 2.- From the user point of view: if wallpaperdownloader is already > > installed and I change the confinement, when snapd upgrades it, will it > > work flawlessly? I mean, the upgrade process will be automatic or it will > > require manual intervention from the user? > > They will need updating. HOME in strict confinement points to the > segregated data stores, in classic it is the traditional home. > > > 3.- As I see classic confinement, it is a feature to make snap packages > > more easily but they only will work on a "classic" Ubuntu system. If > Ubuntu > > is finally migrated to a Snappy system, I guess classic confinement won't > > work and all these packages should be migrated to strict confinement > again, > > am I right? > > This is correct, a pure snappy based system is not a classic system so > classic confinement does not apply. > > > Thank you all for your time :) > > A few more considerations: > > - I would stick to strict having gotten this far and just work on > unblocking yourself with interfaces or other means. > Ok Sergio, you convinced me :) It is true. i have had to deal with a lot of problems until getting an almost totally functional snap for my application, and if the user should have to upgrade manually the snap... I'll stick on strict mode! :D > - strict confinment means you have a stable base (core), while classic > means you will have an unstable one (well, not unstable, just different > depending on the system where the snap is installed), which means you will > have a different set of bugs to deal with depending on the base classic > system where the snap is installed. > - you shouldn't rely on libraries on classic systems, not all of them with > have gtk3 nor will all of them be ABI compatible with the glibc stuff your > snap uses (this might be a different story with java). > The "problem" with wallpaperdownloader is that I try to be fully compatible with the main Desktop Environments in Linux (at the moment, the application works fine with Unity 7, Gnome Shell. Mate, XFCE and KDE (not yet for vesion 2.6 but I'm implementing it for version 2.7)). In order to tell the DE to change the wallpaper I have to use some tools and commands which are available only for this DE and snap packaging is a challenge for me in order to take into account all this environments if I cannot "rely on" the host DE itself (I don't know if I'm expressing myself clearly, sorry for that) > - There is a missing feature in snapd/snap-confine to restrict the library > paths the classic confined snap can see, so you need to make sure this is > the case for you. This can be mitigated in snapcraft if you build all > runnables from parts (in your case the jre which I bet wouldn't be easy). > - I am going to be talking again a bout classic confined snaps in one of > the upcoming Ubuntu Testing days, so if interested, keep an eye on that ;-) > > I'll keep an eye on, for sure! Thank you very much!! Best, Eloy -- Eloy García Almadén From eloy.garcia.pca at gmail.com Tue Mar 28 13:32:01 2017 From: eloy.garcia.pca at gmail.com (=?UTF-8?B?RWxveSBHYXJjw61hIChQQyBBY3R1YWwp?=) Date: Tue, 28 Mar 2017 15:32:01 +0200 Subject: Moving from strict to classic confinement In-Reply-To: References: Message-ID: Hi Renato, 2017-03-27 15:31 GMT+02:00 Renato Filho : > 2017-03-27 4:22 GMT-03:00 Eloy García (PC Actual) < > eloy.garcia.pca at gmail.com>: > > Hello everybody. > > > > I currently have a snap package published on the store. It is called > > wallpaperdownloader and it is a Java-based application. So far, it has > been > > packaged using the strict confinement. The application basically > downloads > > wallpapers from the Internet and sets the wallpaper when the user > requests > > it. Because there are a lot of desktop environments, I have ended up > using > > a lot of Linux commands from the java application in order to achieve > these > > goals. For some DE there is no problem at all: for example, using > gsettings > > interface, GNOME Shell and Unity change the background flawlessly. MATE > is > > working properly too (I had to include mate-desktop-common as stage > > package) but XFCE and KDE... no way. In addition, some of the most simple > > features (open a file explorer for example) don't work. > > I am not sure what exactly the problem that you have to change KDE > wallpapers but it can be related with the fact that you are using > "desktop-gtk3", because this only prepare the environment for gtk > apps. Some environment vars will be missing for Qt apps. > > My main problem is that, first, I need to know Plasma version. in the native installation, I execute, form Java, "plasmashell --version" command, which gives me this version. This command in the snap confinement doesn't exit. > The options that you have are: > > 1 - create a wrapper file and export the vars by yourself. > 2 - Use "ubuntu-app-platform" that contains libraries and a launcher > compatible with most gtk and qt apps. > > Do you think that using ubuntu-app-platform part could have, for example, the command I described above?. In order to change the wallpaper I have to invoke qdbus. Same problem here. Using this part will the command be available? > I hope this help > > Thank you very much!!! :) > -- > 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 dmitrii.shcherbakov at canonical.com Tue Mar 28 13:35:55 2017 From: dmitrii.shcherbakov at canonical.com (Dmitrii Shcherbakov) Date: Tue, 28 Mar 2017 16:35:55 +0300 Subject: Strategy for Snaps with Debugging Symbols In-Reply-To: References: Message-ID: Just wanted to add that if we went for the approach where we replace an application with its debug version, another issue is that complex applications may behave differently depending on added instrumentation in a debug build. For example, if you added debugging code that slows down an application in general it may stop triggering race conditions or certain code paths. In other words, there is a difference between running a 'debugging build' and a 'release build with some debugging symbols loaded'. Best Regards, Dmitrii Shcherbakov Dmitrii Shcherbakov | Canonical Field Software Engineer dmitrii.shcherbakov at canonical.com IRC (freenode): Dmitrii-Sh On Tue, Mar 28, 2017 at 10:44 AM, Christian Ehrhardt wrote: > > On Tue, Mar 28, 2017 at 8:13 AM, Alfonso Sanchez-Beato > wrote: >> >> > One idea for snaps is to use -dbg tracks which are going to contain >> > snaps >> > with embedded debugging symbols. Of course, some snaps may contain a >> > number >> > of services so you'd have to customize your build process and create >> > additional automation around snapcraft to make it more manageable. >> > >> >> I would love to see this, it would ease a lot the debugging pain for >> snaps. >> IMHO using a debugging track makes lots of sense, provided gdbserver/gdb >> in >> Ubuntu Core can be configured to find the symbols automatically. > > > It might come down to teach gdb and co certain path. > On the classic packaging is is about /usr/lib/debug prefixing the canonical > path of the binary. > > So lib and lib+debug symbols are: > $ file > /usr/lib/debug/usr/lib/libvirt/connection-driver/libvirt_driver_interface.so > /usr/lib/debug/usr/lib/libvirt/connection-driver/libvirt_driver_interface.so: > ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, > BuildID[sha1]=1d163a878a64d3f180806e713ad0cb9363492316, not stripped > $ file /usr/lib/libvirt/connection-driver/libvirt_driver_interface.so > /usr/lib/libvirt/connection-driver/libvirt_driver_interface.so: ELF 64-bit > LSB shared object, x86-64, version 1 (SYSV), dynamically linked, > BuildID[sha1]=1d163a878a64d3f180806e713ad0cb9363492316, stripped > > The matching flag build-id in there make sure programs can check they match > and pick it up automatically [1]. > > Now a binary of a snap appears like in a versioned path, but there is the > current link which should be stable. > So the binary of e.g. the latest vlc snap is always in: > /snap/vlc/current/bin/vlc > > That would mean if there would be symbols at > "/usr/lib/debug/snap/vlc/current/bin/vlc.debug" would likely work as of > today in case you want to link yourself something up. > Actually I think it would be fair that snaps could "own" the snap subdir of > the global debug dir being "/usr/lib/debug/snap" and mirror the snap layout > there but populated with the debug symbols. > > Also I agree that this should not be a manual task of some sort, just like > the .deb packaging an optional -dbg snap or such could fall out of any > build that does contain the non-stripped binaries. > > All that is true for a classic gdb, but a snapped gdb will itself run > confined and in its local path to some extend - that has to be considered as > well going forward. > > Also the whole command semantic has to be sound and tasteful for those who > want to use it, while not distracting non debugging snap users too much. > As the debug snaps clearly have a reduced subset of actions (e.g. no > interfaces) maybe one option would be to hide that reduced subset all behind > one subcommand like: "snap dbg [find|list|install|...]" ? > > [1]: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html > > -- > Christian Ehrhardt > Software Engineer, Ubuntu Server > Canonical Ltd From leo.arias at canonical.com Tue Mar 28 17:20:41 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 28 Mar 2017 11:20:41 -0600 Subject: No subject Message-ID: Hello, It has never been easier, snapcraft and profit! For a couple of weeks we have been figuring out how to confine bitcoin. This is one of the most important use cases of the snap security because you don't want any program messing with your digital wallet. And when there's a vulnerability in the code, all the clients should be updated as fast as possible to keep the network sane. With snaps, just push a fixed version and see everybody update without any work from their side. We now need help testing the snap before making it public: $ sudo snap install bitcoin --candidate Then launch it from the dash or running the bitcoin.qt command. This was built from the tag of the latest released bitcoin and pushed to the store, all automatically by travis. But, be warned, you will be the first users so we might still find unforeseen problems. Use your bitcoins with caution during the candidate phase, or just test without any of your money. Here are the sources for the snap and CI scripts, in case you want to verify them or build it yourself: https://github.com/elopio/blockchain-snaps/blob/master/bitcoin/snap/snapcraft.yaml Another interesting detail is that most of the cryptocurrencies out there are forks of the bitcoin source code, so they will all need a similar snapcraft.yaml. The other one we pushed is bitcoin-unlimited, which is promoting a hard fork of the bitcoin network to remove the block size limit. You can have both snaps installed to give them a try and choose the network you want to support, because both will be fully confined and independent: $ sudo snap install bitcoin-unlimited --candidate Of course, this would require twice the time and space to download both blockchains. Thanks to Gal Buki (torusJKL) for his help. Expect more options in the store soon. pura vida -- ¡paz y baile! http://www.ubuntu.com From manik.taneja at canonical.com Tue Mar 28 17:53:29 2017 From: manik.taneja at canonical.com (Manik Taneja) Date: Tue, 28 Mar 2017 10:53:29 -0700 Subject: No subject In-Reply-To: References: Message-ID: this is really cool leo. thanks for sharing. i'll definitely give it a try. /manik On Tue, Mar 28, 2017 at 10:20 AM, Leo Arias wrote: > Hello, > > It has never been easier, snapcraft and profit! > > For a couple of weeks we have been figuring out how to confine > bitcoin. This is one of the most important use cases of the snap > security because you don't want any program messing with your digital > wallet. And when there's a vulnerability in the code, all the clients > should be updated as fast as possible to keep the network sane. With > snaps, just push a fixed version and see everybody update without any > work from their side. > > We now need help testing the snap before making it public: > > $ sudo snap install bitcoin --candidate > > Then launch it from the dash or running the bitcoin.qt command. > > This was built from the tag of the latest released bitcoin and pushed > to the store, all automatically by travis. But, be warned, you will be > the first users so we might still find unforeseen problems. Use your > bitcoins with caution during the candidate phase, or just test without > any of your money. > > Here are the sources for the snap and CI scripts, in case you want to > verify them or build it yourself: > https://github.com/elopio/blockchain-snaps/blob/master/ > bitcoin/snap/snapcraft.yaml > > Another interesting detail is that most of the cryptocurrencies out > there are forks of the bitcoin source code, so they will all need a > similar snapcraft.yaml. The other one we pushed is bitcoin-unlimited, > which is promoting a hard fork of the bitcoin network to remove the > block size limit. You can have both snaps installed to give them a try > and choose the network you want to support, because both will be fully > confined and independent: > > $ sudo snap install bitcoin-unlimited --candidate > > Of course, this would require twice the time and space to download > both blockchains. > > Thanks to Gal Buki (torusJKL) for his help. > > Expect more options in the store soon. > > pura vida > -- > ¡paz y baile! > http://www.ubuntu.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > From seth.arnold at canonical.com Tue Mar 28 22:49:09 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 28 Mar 2017 15:49:09 -0700 Subject: your mail In-Reply-To: References: Message-ID: <20170328224909.GC23177@hunt> On Tue, Mar 28, 2017 at 11:20:41AM -0600, Leo Arias wrote: > Here are the sources for the snap and CI scripts, in case you want to > verify them or build it yourself: > https://github.com/elopio/blockchain-snaps/blob/master/bitcoin/snap/snapcraft.yaml Hi Leo, it looks like you've documented this fairly well but I'm not familiar enough with the details of snap packaging to know how it actually works in practice. This might serve as a good example for the snap community: - At what point do you download the blockchain? - Where does the blockchain get stored? - How are interrupted downloads handled? - How are package upgrades handled? Is a copy of the blockchain made? - How are package downgrades handled? Is a copy of the blockchain made? - Have you run into problems moving BDB forward or backwards when upgrading or downgrading? Is BDB used in the storage of the blockchain or is it used for 'simpler' snap storage? It feels like bitcoin's 100-ish gigabyte blob makes an interesting constraint that many simpler tools may not need to address. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From leo.arias at canonical.com Wed Mar 29 02:56:25 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 28 Mar 2017 20:56:25 -0600 Subject: your mail In-Reply-To: <20170328224909.GC23177@hunt> References: <20170328224909.GC23177@hunt> Message-ID: Hello Seth, In many things, this works just like the tar.gz that you download from the bitcoin website. On Tue, Mar 28, 2017 at 4:49 PM, Seth Arnold wrote: > - At what point do you download the blockchain? It will download the blockchain when you open the qt client. > - Where does the blockchain get stored? It's stored in $SNAP_USER_COMMON, ~/snap/bitcoin/common. This was the only ugly part. There are some bugs in bitcoin reported to allow more control over the data files. But currently, it stores everything in $HOME, which inside the snap is redirected to $SNAP_USER_DATA. This path is versioned, but we don't want to copy the entire blockchain every time the snap is updated. A few days ago I proposed an option to have an unversioned home [1], but it seems this problem is not yet affecting anyone else. So, for now we are patching bitcoin's default data dir [2]. > - How are interrupted downloads handled? Nothing specific to the snap here, bitcoin handles it. You close the app or get disconnected and the download stops. You open the app or reconnect and it resumes. > - How are package upgrades handled? Is a copy of the blockchain made? No, it's kept in the common dir, unversioned. > - How are package downgrades handled? Is a copy of the blockchain made? Nothing specific to the snap here yet. Currently, if the upgrade is not backwards compatible, the same will happen as if you open an older bitcoin version with a directory holding newer data. We could do fancier things on upgrades and downgrades with the epoch work, but that's not yet documented, I'm not even sure if it's complete. > - Have you run into problems moving BDB forward or backwards when > upgrading or downgrading? Is BDB used in the storage of the blockchain > or is it used for 'simpler' snap storage? I'm not sure what do you mean with simpler snap storage. There's no storage specific to the snap. Where the bitcoin code uses the default data dir, that's unversioned. Where it uses HOME or XDG dirs directly, that data is versioned. I don't have high hopes for better data handling because the bugs I found were from a couple of years ago, and mentioned the split of the wallet code that was supposed to happen soon at that time, but never happened. We haven't had problems with updates and downgrades, but well, this is the first version pushed to the store, no much room for failure there. What's cool with the snap is that we get a new version pushed to edge each day, so we can catch any potential breakages right after they are introduced. And as soon as upstream starts tagging candidates for the 0.14.1 release we can move them to the candidate channel and easily test updates from 0.14 with snap refresh bitcoin --candidate. However, these checks are not yet automated, so the success of the snap depends on the community testing before we push to stable. That's the reason for this call for testing. During the experiments with IPFS [3] we already had 3 or 4 successful stable updates, and the process is just lovely and it has worked without any incidents. That's why I'm interested in this more complex scenario with bitcoin. > It feels like bitcoin's 100-ish gigabyte blob makes an interesting > constraint that many simpler tools may not need to address. That was precisely my thinking. Would you like to help us maintaining the snap until we make the transfer upstream? It would be great to increase our bus factor, and more hands will make it easier to improve the packaging. pura vida. [1] https://lists.ubuntu.com/archives/snapcraft/2017-March/003494.html [2] https://github.com/elopio/blockchain-snaps/blob/master/bitcoin/snap/patches/default_data_dir.patch [3] http://elopio.net/blog/ipfs-crowdtesting/ From seth.arnold at canonical.com Wed Mar 29 03:51:32 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Tue, 28 Mar 2017 20:51:32 -0700 Subject: your mail In-Reply-To: References: <20170328224909.GC23177@hunt> Message-ID: <20170329035132.GA16378@hunt> Hi Leo, great response, On Tue, Mar 28, 2017 at 08:56:25PM -0600, Leo Arias wrote: > It's stored in $SNAP_USER_COMMON, ~/snap/bitcoin/common. > This was the only ugly part. There are some bugs in bitcoin reported > [...] > problem is not yet affecting anyone else. So, for now we are patching > bitcoin's default data dir [2]. bitcoin may be the most extreme example I can think of quickly but surely it's not alone in this. > > - Have you run into problems moving BDB forward or backwards when > > upgrading or downgrading? Is BDB used in the storage of the blockchain > > or is it used for 'simpler' snap storage? > > I'm not sure what do you mean with simpler snap storage. There's no > storage specific to the snap. Where the bitcoin code uses the default > data dir, that's unversioned. Where it uses HOME or XDG dirs directly, > that data is versioned. I don't have high hopes for better data > handling because the bugs I found were from a couple of years ago, and > mentioned the split of the wallet code that was supposed to happen > soon at that time, but never happened. I was mostly curious if BDB was being used for the blockchain or user preferences or other metadata; I had some impression many years ago that BDB was touchy, so I wondered if you had run into trouble. > > It feels like bitcoin's 100-ish gigabyte blob makes an interesting > > constraint that many simpler tools may not need to address. > > That was precisely my thinking. Would you like to help us maintaining > the snap until we make the transfer upstream? It would be great to > increase our bus factor, and more hands will make it easier to improve > the packaging. Thanks for the invitation but I'm already feeling vastly oversubscribed. :( Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From christian.isler at solutions.endress.com Wed Mar 29 10:24:49 2017 From: christian.isler at solutions.endress.com (christian.isler at solutions.endress.com) Date: Wed, 29 Mar 2017 12:24:49 +0200 Subject: Configuration Hook get/set. Message-ID: hi all, i have a few  questions regarding the baviour of the configuration option if i do snap set "mySnap" "myOption=77 everthing works as expected. i can read the option with snap get or in the configuration hook with snapctl get. after snap remove "mySnap" i still can access the option i set before. is this the desired baviour? where are these values stored? whats the best way for setting default values for the intial setup? best regards christian Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such. From pat.mcgowan at canonical.com Wed Mar 29 13:04:32 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Wed, 29 Mar 2017 09:04:32 -0400 Subject: Configuration Hook get/set. In-Reply-To: References: Message-ID: On Wed, Mar 29, 2017 at 6:24 AM, wrote: > > > hi all, > i have a few questions regarding the baviour of the configuration option > > if i do > snap set "mySnap" "myOption=77 > everthing works as expected. i can read the option with snap get or in the > configuration hook with snapctl get. > after snap remove "mySnap" i still can access the option i set before. > > is this the desired baviour? > Nope, thats https://bugs.launchpad.net/snapd/+bug/1636934 > where are these values stored? > /var/lib/snapd/state.json > whats the best way for setting default values for the intial setup? > A request for an install time hook is discussed in https://bugs.launchpad.net/snapd/+bug/1661126 Until then your snap or configure hook will need to provide the logic. Pat > > best regards > christian > > > > Disclaimer: > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities other than the intended recipient is prohibited. If you receive > this in error, please contact the sender and delete the material from any > computer. This e-mail does not constitute a contract offer, a contract > amendment, or an acceptance of a contract offer unless explicitly and > conspicuously designated or stated as such. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > From pawel.stolowski at canonical.com Wed Mar 29 15:48:04 2017 From: pawel.stolowski at canonical.com (Pawel Stolowski) Date: Wed, 29 Mar 2017 17:48:04 +0200 Subject: Configuration Hook get/set. In-Reply-To: References: Message-ID: <0befb955-9d90-dc4c-d9c3-9216228afcd9@canonical.com> The fix for this bug landed today and should be available in the next release. Pawel On 29.03.2017 15:04, Pat McGowan wrote: > On Wed, Mar 29, 2017 at 6:24 AM, > wrote: > >> >> hi all, >> i have a few questions regarding the baviour of the configuration option >> >> if i do >> snap set "mySnap" "myOption=77 >> everthing works as expected. i can read the option with snap get or in the >> configuration hook with snapctl get. >> after snap remove "mySnap" i still can access the option i set before. >> >> is this the desired baviour? >> > Nope, thats https://bugs.launchpad.net/snapd/+bug/1636934 > > >> where are these values stored? >> > /var/lib/snapd/state.json > > >> whats the best way for setting default values for the intial setup? >> > A request for an install time hook is discussed in > https://bugs.launchpad.net/snapd/+bug/1661126 > Until then your snap or configure hook will need to provide the logic. > > Pat > > >> best regards >> christian >> >> >> >> Disclaimer: >> >> The information transmitted is intended only for the person or entity to >> which it is addressed and may contain confidential, proprietary, and/or >> privileged >> material. Any review, retransmission, dissemination or other use of, or >> taking of any action in reliance upon, this information by persons or >> entities other than the intended recipient is prohibited. If you receive >> this in error, please contact the sender and delete the material from any >> computer. This e-mail does not constitute a contract offer, a contract >> amendment, or an acceptance of a contract offer unless explicitly and >> conspicuously designated or stated as such. >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> From simon.fels at canonical.com Wed Mar 29 16:40:57 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 29 Mar 2017 18:40:57 +0200 Subject: Desktop snaps are not working in KDE Message-ID: <4d098f2d-cd71-0726-8d7f-24cffd76a8bb@canonical.com> Hey everyone, we currently see bug reports (e.g. https://bugzilla.opensuse.org/show_bug.cgi?id=1031501) that certain snaps are not working in KDE on openSUSE (42.2 / Tumbleweed). On the same distribution, when I run the snaps within Gnome, everything works as it should and the applications are starting up. I didn't looked much into the details yet. keepassxc is one of the snaps which fail to start: simon at linux-82h5:~> keepassxc No protocol specified QXcbConnection: Could not connect to display :0 Aborted As those snaps include Qt/GTK libraries from Ubuntu I can only guess that there are some incompatibilities between KDE on openSUSE and the libraries we ship. Also there is no wayland in the game. I verified both Gnome and KDE are running under X11. Anyone has a good idea what could be wrong here? regards, Simon From michael.hudson at canonical.com Wed Mar 29 19:59:29 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Thu, 30 Mar 2017 08:59:29 +1300 Subject: some console-conf start-up traceback In-Reply-To: References: Message-ID: On 28 March 2017 at 15:58, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > > On 28 March 2017 at 10:38, Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: > >> >> >> On 28 March 2017 at 02:50, Nicolino Curalli wrote: >> >>> Hi all, >>> >>> we have a strange output on console after the first boot: the first boot >>> go straight without any traceback. >>> >>> We use our kernel snap on a orangepi plus 2e board (kernel 4.9). >>> >>> The traceback is the following: >>> >>> >>> [ OK ] Reached target Login Prompts. >>> [ OK ] Started OpenBSD Secure Shell server. >>> [ OK ] Reached target Multi-User System. >>> [ OK ] Reached target Graphical Interface. >>> Starting Update UTMP about System Runlevel Changes... >>> [ OK ] Started Update UTMP about System Runlevel Changes. >>> >>> Traceback (most recent call last): >>> File "/usr/share/subiquity/console-conf-write-login-details", line >>> 21, in >>> sys.exit(write_login_details_standalone()) >>> File "/usr/share/subiquity/console_conf/controllers/identity.py", >>> line 136, in write_login_details_standalone >>> write_login_details(sys.stdout, owner['username'], ips) >>> File "/usr/share/subiquity/console_conf/controllers/identity.py", >>> line 115, in write_login_details >>> sshcommands=sshcommands, host_key_info=host_key_info(), >>> tty_name=tty_name, first_ip=ips[0])) >>> IndexError: list index out of range >>> >> >> Ah, this would be a bug. The script that generates the "ssh >> domotz at 192.168.5.107" page is clearly running before the system gets an >> IP address (via DHCP I guess?) and crash looping until the system does have >> an IP address. >> >> I'll see what I can come up with to fix this. >> > > Hi again, this should be fixed by https://github.com/ > CanonicalLtd/subiquity/pull/209 (which I don't expect you to try, I'll > let you know when it reaches the core snap in the edge channel). By far the > hardest part of this was figuring out a way to test it! > > Thanks for the report. > 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 joseph.wakeling at webdrake.net Thu Mar 30 00:16:38 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 30 Mar 2017 02:16:38 +0200 Subject: Reserved project names and cooperative transfer of ownership In-Reply-To: <6253fc12-0abc-651a-bdb1-5e0ba4ed6d59@ubuntu.com> References: <56200b12-b9cb-7533-6dc5-7efacd57c75e@webdrake.net> <6253fc12-0abc-651a-bdb1-5e0ba4ed6d59@ubuntu.com> Message-ID: <80952e12-33a4-c4c6-f9c0-12790ad15be6@webdrake.net> On 27/03/17 04:46, Michael Hall wrote: > Good news, that's already there! In each appname section in your "apps:" > definitions you can add a property names "aliases" that takes a yaml > list of names you want to use. For example: > > name: snapname > apps: > appname: > command: foo > aliases: [bar] > > By default this will give you /snap/bin/snapname.appname > > But then if you run the command: "snap alias mysnap bar" you will get > /snap/bin/bar which you can invoke with just "bar" from the commandline. > Instead of "bar" you can use "appname" or anything else you want to make > an alias for that app. > > This still requires a manual step after installing your snap to enable > the alias, but we're working out a process to allow it to be > auto-enabled, which I'm sure will be announced on this list once it's > available. Sounds cool! But what if the 'alias' I want is ... just `foo` itself? I take it that for now I still need to create the `aliases` section, just repeating the existing app command name? From joseph.wakeling at webdrake.net Thu Mar 30 00:24:34 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 30 Mar 2017 02:24:34 +0200 Subject: Meta-packages for snaps In-Reply-To: <0043a93d-9c8b-e8f4-3489-e67ee468b619@ubuntu.com> References: <8250ac22-6c5b-51f3-5b1f-e3fc5ab0faab@webdrake.net> <87c124c1-0489-4158-af6b-57870d9405ee@webdrake.net> <0043a93d-9c8b-e8f4-3489-e67ee468b619@ubuntu.com> Message-ID: <813b40b4-5703-7035-0aea-6b56f6f1e758@webdrake.net> On 27/03/17 04:33, Michael Hall wrote: > Because your snap is going to pull in all of your dependencies, doing > one snap per tool will likely result in more duplication and thus more > disk space than providing it all as a single package. That's a very good point. On the other hand, the disk space issue isn't likely to be so great in the grand scheme of things, whereas providing tools separately may allow greater freedom in updating their individual versions (these are not things all deriving from one repo or one release series). > If your users are likely to want more than one of these tools, I would > recommend just providing them all in one package. That way it's still > easy for them to install with a single command, and they will have > everything they might want already there. Fair enough. This actually dovetails quite nicely with the planned use-case, which is snap packages for all the core D utilities: the D core devs I'm talking with are probably in favour of a single snap providing all the utilities. I will probably follow up on this soon :-) Overall, though, I still think it'd be nice to have the flexibility (as a publisher) to choose between a single snap with multiple commands, versus a meta-snap that ensures multiple different independent snaps are installed. From akgrant0710 at gmail.com Thu Mar 30 06:10:26 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Thu, 30 Mar 2017 08:10:26 +0200 Subject: classic 32 bit application Message-ID: 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? Thanks very much, Alistair From christian.isler at solutions.endress.com Thu Mar 30 12:00:07 2017 From: christian.isler at solutions.endress.com (christian.isler at solutions.endress.com) Date: Thu, 30 Mar 2017 14:00:07 +0200 Subject: Configuration Hook get/set Message-ID: Thanks a lot for your answers. Good to know that the bug is already fixed christian >The fix for this bug landed today and should be available in the next >release. > >Pawel > >On 29.03.2017 15:04, Pat McGowan wrote: >> On Wed, Mar 29, 2017 at 6:24 AM, >> wrote: >> >>> >>> hi all, >>> i have a few  questions regarding the baviour of the configuration option >>> >>> if i do >>> snap set "mySnap" "myOption=77 >>> everthing works as expected. i can read the option with snap get or in the >>> configuration hook with snapctl get. >>> after snap remove "mySnap" i still can access the option i set before. >>> >>> is this the desired baviour? >>> >> Nope, thats https://bugs.launchpad.net/snapd/+bug/1636934 >> >> >>> where are these values stored? >>> >> /var/lib/snapd/state.json >> >> >>> whats the best way for setting default values for the intial setup? >>> >> A request for an install time hook is discussed in >> https://bugs.launchpad.net/snapd/+bug/1661126 >> Until then your snap or configure hook will need to provide the logic. >> >> Pat >> >> >>> best regards >>> christian >>> >>> >>> <>> Disclaimer: >>> <>> The information transmitted is intended only for the person or entity to >>> which it is addressed and may contain confidential, proprietary, and/or >> privileged >>> material. Any review, retransmission, dissemination or other use of, or >>> taking of any action in reliance upon, this information by persons or >>> entities other than the intended recipient is prohibited. If you receive >>> this in error, please contact the sender and delete the material from any >>> computer. This e-mail does not constitute a contract offer, a contract >>> amendment, or an acceptance of a contract offer unless explicitly and >>> conspicuously designated or stated as such. >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> > > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft Disclaimer: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such. From simon.fels at canonical.com Thu Mar 30 13:07:43 2017 From: simon.fels at canonical.com (Simon Fels) Date: Thu, 30 Mar 2017 15:07:43 +0200 Subject: Desktop snaps are not working in KDE In-Reply-To: <4d098f2d-cd71-0726-8d7f-24cffd76a8bb@canonical.com> References: <4d098f2d-cd71-0726-8d7f-24cffd76a8bb@canonical.com> Message-ID: <6d31e8c6-0875-cbe1-dee4-7167bffaa6cc@canonical.com> On 29.03.2017 18:40, Simon Fels wrote: > Hey everyone, > > we currently see bug reports (e.g. > https://bugzilla.opensuse.org/show_bug.cgi?id=1031501) that certain > snaps are not working in KDE on openSUSE (42.2 / Tumbleweed). On the > same distribution, when I run the snaps within Gnome, everything works > as it should and the applications are starting up. > > I didn't looked much into the details yet. keepassxc is one of the snaps > which fail to start: > > simon at linux-82h5:~> keepassxc > No protocol specified > QXcbConnection: Could not connect to display :0 > Aborted > > As those snaps include Qt/GTK libraries from Ubuntu I can only guess > that there are some incompatibilities between KDE on openSUSE and the > libraries we ship. Also there is no wayland in the game. I verified both > Gnome and KDE are running under X11. > > Anyone has a good idea what could be wrong here? I've found the reason for this now. See https://bugs.launchpad.net/snapd/+bug/1677513 for a summary. In the end the problem is that XAUTHORITY refers to a xauth file in /tmp which isn't accessible within the snap environment. I will create a fix for this as part of my cross-distro work. regards, Simon From sergio.schvezov at canonical.com Thu Mar 30 13:36:53 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 30 Mar 2017 13:36:53 +0000 Subject: classic 32 bit application In-Reply-To: References: Message-ID: On Thu, 30 Mar 2017 08:10:26 +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? Are you on a 32 bit system? Did you just switch confinement type without rebuilding? -- Sent using Dekko from my Ubuntu device From akgrant0710 at gmail.com Thu Mar 30 14:36:26 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Thu, 30 Mar 2017 16:36:26 +0200 Subject: classic 32 bit application In-Reply-To: References: Message-ID: Hi Sergio, Thanks for your reply. On 30 March 2017 at 15:36, Sergio Schvezov wrote: > On Thu, 30 Mar 2017 08:10:26 +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? > > Did you just switch confinement type without rebuilding? The build environment is docker snapcraft/xenial-amd64. I rebuilt the package from scratch, i.e. in the docker container: $ cd /path/to/pharo-snap $ snapcraft clean $ snapcraft prime Then on the host (Ubuntu 4.8.0-45.48~16.04.1-generic 4.8.17): $ sudo snap try /path/to/pharo-snap/prime --classic $ pharo --version > Are you on a 32 bit system? No, does this mean that 32 bit snap'd applications don't work on 64 bit systems with classic containment? Thanks, Alistair From spencertparkin at gmail.com Thu Mar 30 15:49:55 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Thu, 30 Mar 2017 09:49:55 -0600 Subject: desktop-gtk3 Message-ID: Here is my current .yaml file... name: twistypuzzle version: "1.0" summary: A 3D simulator for a variety of twisty puzzles. description: Blah... confinement: strict apps: twistypuzzle: command: env UBUNTU_MENUPROXY=0 desktop-launch $SNAP/bin/TwistyPuzzle plugs: [home, x11, unity7, opengl] parts: twistypuzzle: plugin: scons source: https://github.com/spencerparkin/TwistyPuzzle.git source-branch: stable-release after: - desktop-gtk3 - fontsystem - 3dmath - permutationgroup - rapidjson fontsystem: plugin: scons source: https://github.com/spencerparkin/FontSystem.git source-branch: master 3dmath: plugin: scons source: https://github.com/spencerparkin/3DMath.git source-branch: master permutationgroup: plugin: scons source: https://github.com/spencerparkin/PermutationGroup.git source-branch: master rapidjson: plugin: dump source: https://github.com/miloyip/rapidjson.git source-branch: master I am getting an error when I try to snapcraft this .yaml file. It's complaining about the "desktop-gtk3" line, and saying that there is a syntax error here. I don't have the exact error message with me at the moment. I can reply with that tonight. The error, as I recall, said that it expected something after the part. Does anyone have any ideas as to what might be wrong with this .yaml file? If I remove the "desktop-gtk3" line, then the snap will build just fine, but it won't be valid, because there won't be any GTK3 support. Thanks, --Spencer From spencertparkin at gmail.com Thu Mar 30 17:09:00 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Thu, 30 Mar 2017 11:09:00 -0600 Subject: desktop-gtk3 In-Reply-To: <3502320.28Fj99hbr4@ant> References: <3223609.znxCVdYBjG@ant> <3502320.28Fj99hbr4@ant> Message-ID: Take a look at the following .yaml file. https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/demos/gtk3/snapcraft.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é. > From jose.pekkarinen at canonical.com Thu Mar 30 17:21:12 2017 From: jose.pekkarinen at canonical.com (=?ISO-8859-1?Q?Jos=E9?= Pekkarinen) Date: Thu, 30 Mar 2017 20:21:12 +0300 Subject: desktop-gtk3 In-Reply-To: References: <3502320.28Fj99hbr4@ant> Message-ID: <5432201.hknf6qD210@ant> 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é. From sergio.schvezov at canonical.com Thu Mar 30 19:54:34 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 30 Mar 2017 19:54:34 +0000 Subject: ANN: snapcraft 2.28 has been released Message-ID: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> Prettier version of the release notes can be found on https://github.com/snapcore/snapcraft/releases/tag/2.28 -- Hello snapcrafters! We are pleased to announce the release snapcraft `2.28`: https://launchpad.net/snapcraft/+milestone/2.28 # Contributions This release has seen some contributions from outside of the snapcraft core team, so we want to give a shout out to these folks, here's a team thank you for: - Colin Watson - Jonathan Cave - Michael Hudson-Doyle - Olivier Tilloy - Paolo Pisati - pachulo # New in this release ## Core ### snapcraft snap snapcraft can now properly build as a snap and does the right thing. Starting 2.28 snapcraft should eventually be able to be installed from the store, currently in the `edge` channel. ### repo The repo module in snapcraft, which deals with `stage-packages` entries and host distro specific packaging has been moved to a more modular python packge inside snapcraft allowing contributors to add support for other mechanisms such as support for rpm. ### cleanbuild The logic for cleanbuild has been reworked to properly detect when lxd (the lxc client actually) is installed as a snap or manually compiled. This change also comes into play for cross distro snapcraft support. ### classic confinement With this release it should be now possible to use launchpad builders to build for other architectures than `amd64` as the detection logic for the dynamic linker in core has been fixed. ### sources Sources, thanks to an external contributor, can now make use of a new entry, `source-checksum` which can be added to sources that can be hashed, the format is the following: `source-checksum: /`. These are the supported algorithms: - `md5` - `sha1` - `sha224` - `sha256` - `sha384` - `sha3_256` - `sha3_384` (recommended) - `sha3_512` ## Plugins ### python Projects that use `pbr`, mostly openstack, now correctly setup their `console_scripts` defined in `entry_points` when using `setup.cfg`. When building with python provided as a part, headers are now correctly setup to do the right thing for python packages that need to build code requiring these headers. ### kernel The `kernel` and `kbuild` plugins have received some needed attention for this release providing for better out of the box kernel builds. The demos have been setup to now build proper bootable kernels with todays Ubuntu Core module dependency. The plugin itself: - The plugin itself has added better support to the logic that adds and traces module dependencies when needing them added to initrd. - For the case of architectures that use dtbs, if no dtb is specified, all dtbs are installed to make sure the system could boot by default. - The kernel target, if not provided is now decided by the plugin depending on the build architecture. - When building, custom `MAKEFLAGS` no longer affect the build. And to add to that, there is now a test plan for the kernel plugin that tracks the supported kernels. ### catkin The plugin has been expanded to support underlays, the benefit here is that it is now easy to build ROS projects that make use of the `content` interface. Check out the [demo code](https://github.com/snapcore/snapcraft/tree/master/demos/shared-ros). ## Store integration Delta uploads are now enabled for every `snapcraft push` done, a welcome bandwith saving addition. Every store request now sends a proper User Agent string so the store can behave accordingly to the version of snapcraft in use and properly determine when deprecated APIs can go out the door. The `history` command has been deprecated in favor of `list-revisions` with an alias of `revisions`. An explanation of the reasoning can be read on the deprecation notice [DN4](http://snapcraft.io/docs/deprecation-notices/dn4) The `status`, `close` and `list-revisions` commands have been updated to show track information when used. ## Others For the full list of things available on 2.28 feel free to check https://launchpad.net/snapcraft/+milestone/2.28 # Final Notes To get the source for this release check it out at https://github.com/snapcore/snapcraft/releases/tag/2.28 A great place to collaborate and discuss features, bugs and ideas on snapcraft is snapcraft at lists.snapcraft.io mailing list or on the snapcraft channel on Rocket Chat https://rocket.ubuntu.com/channel/snapcraft To file bugs, please go to https://bugs.launchpad.net/snapcraft/+filebug. Happy snapcrafting! -- Sergio and the team -- Sent using Dekko from my Ubuntu device From seth.arnold at canonical.com Thu Mar 30 21:38:22 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Thu, 30 Mar 2017 14:38:22 -0700 Subject: classic 32 bit application In-Reply-To: References: Message-ID: <20170330213822.GA5109@hunt> 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? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From joseph.wakeling at webdrake.net Thu Mar 30 22:21:41 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 31 Mar 2017 00:21:41 +0200 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> Message-ID: On 30/03/17 21:54, Sergio Schvezov wrote: > Prettier version of the release notes can be found on https://github.com/snapcore/snapcraft/releases/tag/2.28 Big thanks for this one! More specifically ... > ### classic confinement > > With this release it should be now possible to use launchpad builders to build for other architectures than `amd64` as the detection logic for the dynamic linker in core has been fixed. I can confirm that Launchpad was able to successfully complete both amd64 and i386 builds of the current development branch of my ldc2 snap. Armhf and arm64 builds are currently under way and are looking fine so far (if anything goes wrong I would anticipate it being an LDC issue). Couldn't have come at a better time as far as I'm concerned. Thanks again and best wishes, -- Joe From spencertparkin at gmail.com Fri Mar 31 03:55:16 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Thu, 30 Mar 2017 21:55:16 -0600 Subject: desktop-gtk3 In-Reply-To: <5432201.hknf6qD210@ant> References: <3502320.28Fj99hbr4@ant> <5432201.hknf6qD210@ant> Message-ID: 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. 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é. > > > From akgrant0710 at gmail.com Fri Mar 31 05:02:32 2017 From: akgrant0710 at gmail.com (Alistair Grant) Date: Fri, 31 Mar 2017 07:02:32 +0200 Subject: classic 32 bit application In-Reply-To: <20170330213822.GA5109@hunt> References: <20170330213822.GA5109@hunt> Message-ID: On 30 March 2017 at 23: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 think so. Since this is being used by developers, I've got no way of knowing which executables they'll want to call, which libraries will be loaded, etc. This also seems to fit in with https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/ which says that classic confinement is typically used "for all your scripting and tooling needs". If you were packaging python or java for use by developers on their desktop, would you use strict or classic? Thanks, Alistair From didrocks at ubuntu.com Fri Mar 31 07:06:34 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 31 Mar 2017 09:06:34 +0200 Subject: desktop-gtk3 In-Reply-To: References: <3502320.28Fj99hbr4@ant> <5432201.hknf6qD210@ant> Message-ID: <268b3ae1-198c-2140-c65e-cee90d6eca78@ubuntu.com> 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é. >> >> From james.henstridge at canonical.com Fri Mar 31 07:08:39 2017 From: james.henstridge at canonical.com (James Henstridge) Date: Fri, 31 Mar 2017 15:08:39 +0800 Subject: classic 32 bit application In-Reply-To: <20170330213822.GA5109@hunt> References: <20170330213822.GA5109@hunt> Message-ID: 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. From mark at ubuntu.com Fri Mar 31 10:22:50 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 31 Mar 2017 11:22:50 +0100 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> Message-ID: What a great release, thank you! Only one request: On 30/03/17 20:54, Sergio Schvezov wrote: > ### sources > > Sources, thanks to an external contributor, can now make use of a new entry, `source-checksum` which can be added to sources that can be hashed, the format is the following: `source-checksum: /`. These are the supported algorithms: > > - `md5` > - `sha1` > - `sha224` > - `sha256` Please cull those from the acceptable digests, they are the Fake News of cryptographic reassurance ;) Mark From cjwatson at ubuntu.com Fri Mar 31 10:37:44 2017 From: cjwatson at ubuntu.com (Colin Watson) Date: Fri, 31 Mar 2017 11:37:44 +0100 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> Message-ID: <20170331103744.GA21800@riva.ucam.org> On Fri, Mar 31, 2017 at 11:22:50AM +0100, Mark Shuttleworth wrote: > On 30/03/17 20:54, Sergio Schvezov wrote: > > ### sources > > > > Sources, thanks to an external contributor, can now make use of a new entry, `source-checksum` which can be added to sources that can be hashed, the format is the following: `source-checksum: /`. These are the supported algorithms: > > > > - `md5` > > - `sha1` > > - `sha224` > > - `sha256` > > Please cull those from the acceptable digests, they are the Fake News of > cryptographic reassurance ;) Seriously? MD5 and SHA-1 of course yes, but there's no particular evidence that SHA256 is problematic, and as yet it's far more popular as an advertised tarball hash than anything based on SHA-3 or BLAKE2. (I don't know about SHA224, but it's at least also in the SHA-2 family.) Current NIST policy recommends SHA256 as a minimum, and says "Currently there is no need to transition applications from SHA-2 to SHA-3", dated 2015-08-05 (http://csrc.nist.gov/groups/ST/hash/policy.html). Of course it's always important to retain hash algorithm agility and usually wise to prefer more recent standards in new applications, but it's IMO far too early to regard SHA256 as unacceptable. -- Colin Watson [cjwatson at ubuntu.com] From vinzjobard at gmail.com Fri Mar 31 13:28:52 2017 From: vinzjobard at gmail.com (Vincent JOBARD) Date: Fri, 31 Mar 2017 13:28:52 +0000 Subject: Issues creating webapps snaps with stric confinement Message-ID: 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 From serge.borovkov at gmail.com Fri Mar 31 14:55:14 2017 From: serge.borovkov at gmail.com (Sergey Borovkov) Date: Fri, 31 Mar 2017 17:55:14 +0300 Subject: Issues using dbus in strict Message-ID: 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 kyle.fazzari at canonical.com Fri Mar 31 14:58:16 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Fri, 31 Mar 2017 07:58:16 -0700 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: <20170331103744.GA21800@riva.ucam.org> References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> <20170331103744.GA21800@riva.ucam.org> Message-ID: <03a8b2a8-c786-2be2-abaa-1bcc01d36657@canonical.com> On 03/31/2017 03:37 AM, Colin Watson wrote: > On Fri, Mar 31, 2017 at 11:22:50AM +0100, Mark Shuttleworth wrote: >> On 30/03/17 20:54, Sergio Schvezov wrote: >>> ### sources >>> >>> Sources, thanks to an external contributor, can now make use of a new entry, `source-checksum` which can be added to sources that can be hashed, the format is the following: `source-checksum: /`. These are the supported algorithms: >>> >>> - `md5` >>> - `sha1` >>> - `sha224` >>> - `sha256` >> >> Please cull those from the acceptable digests, they are the Fake News of >> cryptographic reassurance ;) > > Seriously? MD5 and SHA-1 of course yes, but there's no particular > evidence that SHA256 is problematic, and as yet it's far more popular as > an advertised tarball hash than anything based on SHA-3 or BLAKE2. (I > don't know about SHA224, but it's at least also in the SHA-2 family.) Indeed, looking at what upstream provides for a few projects I use in my snaps: - Nextcloud: MD5 and SHA256 (https://nextcloud.com/install/#instructions-server) - Apache: PGP sig or MD5 (https://www.apache.org/dyn/closer.cgi#verify) - PHP: MD5 or SHA256 (https://secure.php.net/downloads.php) - Redis: SHA1 and SHA256 (https://github.com/antirez/redis-hashes/blob/master/README) - Ubuntu itself: SHA256 (it seems that it also supports MD5 and SHA1 (https://www.ubuntu.com/download/how-to-verify) I think supporting commonly-used ones here is important, or this becomes difficult to use. -- 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 loic.minier at ubuntu.com Fri Mar 31 15:20:03 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Fri, 31 Mar 2017 17:20:03 +0200 Subject: Issues creating webapps snaps with stric confinement In-Reply-To: References: Message-ID: Hi Vincent, What plugs did you use? This is a quick&dirty snap I assembled recently which I tested successfully on top of X11: https://github.com/lool/soracom-console-snap/blob/master/snapcraft.yaml Cheers, - Loïc On Fri, Mar 31, 2017 at 3: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 > -- - Loïc From kyle.nitzsche at canonical.com Fri Mar 31 15:34:21 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Fri, 31 Mar 2017 11:34:21 -0400 Subject: Issues using dbus in strict In-Reply-To: References: Message-ID: <9463f752-f03a-ffe7-637b-ef4d2100a3d5@canonical.com> Hi folks, any tips here to unblock this critical 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 tim.sueberkrueb at web.de Fri Mar 31 16:22:08 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Fri, 31 Mar 2017 18:22:08 +0200 Subject: Updating cloud part Message-ID: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Hey, I made some changes to the Liri cloud part few hours earlier, but parts.snapcraft.io still hasn't updated. Is there a problem with my changes or am I just too impatient? ;) All the best, Tim From joe.talbott at canonical.com Fri Mar 31 16:24:42 2017 From: joe.talbott at canonical.com (Joe Talbott) Date: Fri, 31 Mar 2017 12:24:42 -0400 Subject: Updating cloud part In-Reply-To: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> References: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Message-ID: I see 'liri-app' here https://parts.snapcraft.io/v1/parts.yaml Make sure you run 'snapcraft update' to download the latest parts.yaml file. Joe On Fri, Mar 31, 2017 at 12:22 PM, Tim Süberkrüb wrote: > Hey, > > I made some changes to the Liri cloud part few hours earlier, but > parts.snapcraft.io still hasn't updated. > > Is there a problem with my changes or am I just too impatient? ;) > > > All the best, > > Tim > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft From tim.sueberkrueb at web.de Fri Mar 31 16:26:39 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Fri, 31 Mar 2017 18:26:39 +0200 Subject: Updating cloud part In-Reply-To: References: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Message-ID: Hey Joe, thanks for your reply. Yeah, I know but I updated it here: https://wiki.ubuntu.com/snapcraft/parts (see entry at the very bottom). I already checked snapcraft update/search and the API url. All the best, Tim On 31.03.2017 18:24, Joe Talbott wrote: > I see 'liri-app' here https://parts.snapcraft.io/v1/parts.yaml > > Make sure you run 'snapcraft update' to download the latest parts.yaml file. > > Joe > > On Fri, Mar 31, 2017 at 12:22 PM, Tim Süberkrüb wrote: >> Hey, >> >> I made some changes to the Liri cloud part few hours earlier, but >> parts.snapcraft.io still hasn't updated. >> >> Is there a problem with my changes or am I just too impatient? ;) >> >> >> All the best, >> >> Tim >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft From joe.talbott at canonical.com Fri Mar 31 16:37:31 2017 From: joe.talbott at canonical.com (Joe Talbott) Date: Fri, 31 Mar 2017 12:37:31 -0400 Subject: Updating cloud part In-Reply-To: References: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Message-ID: Hi Tim, Don't use '/' in part names. Rename 'liri-platform/v0.10.0' to 'liri-platform-v0.10.0' and update the snapcraft.yaml at https://github.com/lirios/snapcraft-parts.git to use that as the part name not the nested naming you have there now. That should get things updated for you. Thanks, Joe On Fri, Mar 31, 2017 at 12:26 PM, Tim Süberkrüb wrote: > Hey Joe, > > thanks for your reply. > > Yeah, I know but I updated it here: https://wiki.ubuntu.com/snapcraft/parts > (see entry at the very bottom). > > I already checked snapcraft update/search and the API url. > > All the best, > > Tim > > > > On 31.03.2017 18:24, Joe Talbott wrote: >> >> I see 'liri-app' here https://parts.snapcraft.io/v1/parts.yaml >> >> Make sure you run 'snapcraft update' to download the latest parts.yaml >> file. >> >> Joe >> >> On Fri, Mar 31, 2017 at 12:22 PM, Tim Süberkrüb >> wrote: >>> >>> Hey, >>> >>> I made some changes to the Liri cloud part few hours earlier, but >>> parts.snapcraft.io still hasn't updated. >>> >>> Is there a problem with my changes or am I just too impatient? ;) >>> >>> >>> All the best, >>> >>> Tim >>> >>> -- >>> 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 tim.sueberkrueb at web.de Fri Mar 31 16:41:48 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Fri, 31 Mar 2017 18:41:48 +0200 Subject: Updating cloud part In-Reply-To: References: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Message-ID: Hey Joe, ah, thanks for that info. So I guess '/' in part names has been deprecated? Some docs for cloud parts in general would be nice ;) All the best, Tim On 31.03.2017 18:37, Joe Talbott wrote: > Hi Tim, > > Don't use '/' in part names. Rename 'liri-platform/v0.10.0' to > 'liri-platform-v0.10.0' and update the snapcraft.yaml at > https://github.com/lirios/snapcraft-parts.git to use that as the part > name not the nested naming you have there now. > > That should get things updated for you. > > Thanks, > Joe > > On Fri, Mar 31, 2017 at 12:26 PM, Tim Süberkrüb wrote: >> Hey Joe, >> >> thanks for your reply. >> >> Yeah, I know but I updated it here: https://wiki.ubuntu.com/snapcraft/parts >> (see entry at the very bottom). >> >> I already checked snapcraft update/search and the API url. >> >> All the best, >> >> Tim >> >> >> >> On 31.03.2017 18:24, Joe Talbott wrote: >>> I see 'liri-app' here https://parts.snapcraft.io/v1/parts.yaml >>> >>> Make sure you run 'snapcraft update' to download the latest parts.yaml >>> file. >>> >>> Joe >>> >>> On Fri, Mar 31, 2017 at 12:22 PM, Tim Süberkrüb >>> wrote: >>>> Hey, >>>> >>>> I made some changes to the Liri cloud part few hours earlier, but >>>> parts.snapcraft.io still hasn't updated. >>>> >>>> Is there a problem with my changes or am I just too impatient? ;) >>>> >>>> >>>> All the best, >>>> >>>> Tim >>>> >>>> -- >>>> 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 alan.pope at canonical.com Fri Mar 31 16:51:32 2017 From: alan.pope at canonical.com (Alan Pope) Date: Fri, 31 Mar 2017 17:51:32 +0100 Subject: Updating cloud part In-Reply-To: References: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Message-ID: On 31 March 2017 at 17:41, Tim Süberkrüb wrote: > ah, thanks for that info. So I guess '/' in part names has been deprecated? > Yes. > Some docs for cloud parts in general would be nice ;) > Agreed. https://github.com/CanonicalLtd/snappy-docs/issues/54 :) -- Alan Pope Snap Advocate Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From tim.sueberkrueb at web.de Fri Mar 31 17:07:09 2017 From: tim.sueberkrueb at web.de (=?UTF-8?B?VGltIFPDvGJlcmtyw7xi?=) Date: Fri, 31 Mar 2017 19:07:09 +0200 Subject: Updating cloud part In-Reply-To: References: <2597f773-1e8f-2b95-3f88-ffae5b15ca89@web.de> Message-ID: <61acc981-4dd8-7c5f-48e4-ef3357388cf7@web.de> +1, thanks, Alan! On 31.03.2017 18:51, Alan Pope wrote: > On 31 March 2017 at 17:41, Tim Süberkrüb wrote: >> ah, thanks for that info. So I guess '/' in part names has been deprecated? >> > Yes. > >> Some docs for cloud parts in general would be nice ;) >> > Agreed. https://github.com/CanonicalLtd/snappy-docs/issues/54 > > :) > From gregory.lutostanski at canonical.com Fri Mar 31 19:57:13 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Fri, 31 Mar 2017 14:57:13 -0500 Subject: Getting snapcraft.yaml version from a script Message-ID: 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. Thanks, Greg From gregory.lutostanski at canonical.com Fri Mar 31 19:57:13 2017 From: gregory.lutostanski at canonical.com (Gregory Lutostanski) Date: Fri, 31 Mar 2017 14:57:13 -0500 Subject: Getting snapcraft.yaml version from a script Message-ID: 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. Thanks, Greg From mark at ubuntu.com Fri Mar 31 18:26:27 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 31 Mar 2017 19:26:27 +0100 Subject: ANN: snapcraft 2.28 has been released In-Reply-To: <20170331103744.GA21800@riva.ucam.org> References: <9of3l9.onn8n6.1hge199-qmf@smtp.googlemail.com> <20170331103744.GA21800@riva.ucam.org> Message-ID: On 31/03/17 11:37, Colin Watson wrote: > Current NIST policy recommends SHA256 as a minimum, Since we're starting something new, I would prefer us to be well off the minimum. > and says "Currently > there is no need to transition applications from SHA-2 to SHA-3", dated > 2015-08-05 (http://csrc.nist.gov/groups/ST/hash/policy.html). Of course > it's always important to retain hash algorithm agility and usually wise > to prefer more recent standards in new applications, but it's IMO far > too early to regard SHA256 as unacceptable. If these are easy for the snapcrafter to create, then I suggest we just use SHA2-384 or greater. If for some reason we are limited to things that upstreams already publish then we could include the lower SHA2's. But since the whole point is for snapcraft to fetch the blob, it seems trivial for the snapcrafter to use a longer one. It's highly likely they are cutting and pasting a long string, not typing it in from memory :) Mark From ngompa13 at gmail.com Fri Mar 31 20:52:58 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Fri, 31 Mar 2017 16:52:58 -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 Fri, Mar 31, 2017 at 2:26 PM, Mark Shuttleworth wrote: > On 31/03/17 11:37, Colin Watson wrote: >> Current NIST policy recommends SHA256 as a minimum, > > Since we're starting something new, I would prefer us to be well off the > minimum. > >> and says "Currently >> there is no need to transition applications from SHA-2 to SHA-3", dated >> 2015-08-05 (http://csrc.nist.gov/groups/ST/hash/policy.html). Of course >> it's always important to retain hash algorithm agility and usually wise >> to prefer more recent standards in new applications, but it's IMO far >> too early to regard SHA256 as unacceptable. > > If these are easy for the snapcrafter to create, then I suggest we just > use SHA2-384 or greater. If for some reason we are limited to things > that upstreams already publish then we could include the lower SHA2's. > But since the whole point is for snapcraft to fetch the blob, it seems > trivial for the snapcrafter to use a longer one. It's highly likely they > are cutting and pasting a long string, not typing it in from memory :) > > Mark > I'd recommend no lower than SHA256. In Fedora, we've transitioned our lookaside cache (which stores upstream tarballs) to SHA 512, but we definitely don't want to use less than SHA256 for snaps. Personally, I'd recommend: * SHA2 256, 384, 512 * SHA3 256, 384, 512 * BLAKE2s, BLAKE2b -- 真実はいつも一つ！/ Always, there's only one truth!