From gareth.france at cliftonts.co.uk Sun Jan 1 21:09:21 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Sun, 1 Jan 2017 21:09:21 +0000 Subject: Issues generating snap Message-ID: Firstly as a new member of the group I'd like to say hi and sorry if this is not the correct place for this sort of question, if not please do point me in the right direction. I've installed snapcraft and I'm just running through the tour which in step on confidently claims my system will ' interpret this file, fetch and install everything that is needed, build it, and give you a snap' Unfortunately mine simply generates an error and quits: /tmp/tmpk3k1eoco: 3: export: Files/Programming/Python/RokuTerm/snapcraft-tour/00-SNAPCRAFT/01-easy-start/stage/usr/share/perl5/: bad variable name Command '['/bin/sh', '/tmp/tmpk3k1eoco', './configure', '--prefix=']' returned non-zero exit status 2 Does anybody have any suggestion as to what is going wrong here? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Sun Jan 1 21:14:25 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sun, 1 Jan 2017 18:14:25 -0300 Subject: Issues generating snap In-Reply-To: References: Message-ID: El 01/01/17 a las 18:09, Gareth France escribió: > > Firstly as a new member of the group I'd like to say hi and sorry if > this is not the correct place for this sort of question, if not please > do point me in the right direction. > Hello! > I've installed snapcraft and I'm just running through the tour which > in step on confidently claims my system will ' interpret this file, > fetch and install everything that is needed, build it, and give you a > snap' > > Unfortunately mine simply generates an error and quits: > > /tmp/tmpk3k1eoco: 3: export: > Files/Programming/Python/RokuTerm/snapcraft-tour/00-SNAPCRAFT/01-easy-start/stage/usr/share/perl5/: > bad variable name > Command '['/bin/sh', '/tmp/tmpk3k1eoco', './configure', '--prefix=']' > returned non-zero exit status 2 > > Does anybody have any suggestion as to what is going wrong here? > More information to help out would be appreciated, such as version, what you are trying to build (is it really the 01 dir from the tour), what release you are on, other information you can think of. Is this the full length of the output? It seems something in your build is calling perl and bailing for some reason. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Sun Jan 1 21:18:12 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Sun, 1 Jan 2017 21:18:12 +0000 Subject: Issues generating snap In-Reply-To: References: Message-ID: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> Snapcraft version 2.24+16.10 Ubuntu version 16.10 I am building the hello world example from the snap tour. Below is the full output: snapcraft "grade" property not specified: defaulting to "stable" Use of build-properties in the schema is deprecated. Plugins should now implement get_build_properties Preparing to pull gnu-hello Pulling gnu-hello Downloading 'hello-2.10.tar.gz'[==========================================] 100% Preparing to build gnu-hello Building gnu-hello ./configure --prefix= /tmp/tmpagub9i4k: 3: export: Files/Programming/Python/RokuTerm/snapcraft-tour/00-SNAPCRAFT/01-easy-start/stage/usr/share/perl5/: bad variable name Command '['/bin/sh', '/tmp/tmpagub9i4k', './configure', '--prefix=']' returned non-zero exit status 2 On 01/01/17 21:14, Sergio Schvezov wrote: > More information to help out would be appreciated, such as version, > what you are trying to build (is it really the 01 dir from the tour), > what release you are on, other information you can think of. > > Is this the full length of the output? It seems something in your > build is calling perl and bailing for some reason. From gareth.france at cliftonts.co.uk Sun Jan 1 22:29:30 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Sun, 1 Jan 2017 22:29:30 +0000 Subject: Issues generating snap In-Reply-To: References: Message-ID: <0d5d9440-3c5b-16b2-cd2c-05103d264da2@cliftonts.co.uk> > More information to help out would be appreciated, such as version, > what you are trying to build (is it really the 01 dir from the tour), > what release you are on, other information you can think of. > > Is this the full length of the output? It seems something in your > build is calling perl and bailing for some reason. > > Ok, so having read ahead a little more I have managed to use an example of a python script being packaged to package the script I wanted to. The result installs perfectly but then tells me that I do not have permission to run the command when I try to run my installed program. A little tinkering and then it just tells me that it can't determine the dependancies for many things during the compilation of the snap, then tells me that it has completed successfully but when I try to run the installed program it tells me python isn't installed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timo.jyrinki at gmail.com Mon Jan 2 08:05:55 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Mon, 2 Jan 2017 10:05:55 +0200 Subject: Shared content example - ubuntu-app-platform In-Reply-To: <44aa89c5-dda0-c462-72d8-bf26f1d310df@canonical.com> References: <44aa89c5-dda0-c462-72d8-bf26f1d310df@canonical.com> Message-ID: 2016-12-08 2:56 GMT+02:00 knitzsche : > How do consumers (snap devs) know the lib/API versions contained? On touch > we had the concept of a "framework", whose version implied a set of API > commitments. Since this puts QT together with other (Ubuntu &etc) libs, > what's the reasonable expectation? Right now the versioning we have is the "content:" field, currently at ubuntu-app-platform1. This was recommended to me in October. The idea would be to increment that so that apps using ubuntu-app-platform1 continue to fetch an older platform snap from the store providing that version, while people can update their apps to the newer version at their pace. This is the theory, I'm not sure about the implementation status for things like 1) fetching older version with matching "content:" value in case the newest snap in store has incremented value, 2) co-installing different versions with different "content:" value. We may need to change snap itself or introduce a new method for the versioning if this is not the final way. -Timo From olivier.tilloy at canonical.com Mon Jan 2 15:34:33 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Mon, 2 Jan 2017 16:34:33 +0100 Subject: snapd and semaphores Message-ID: Hi everyone, and happy new year! I’m snapping an app that makes use of semaphores¹ and seeing an apparmor denial. The glibc implementation of sem_open calls SHM_GET_NAME(EINVAL,SEM_FAILED,SEM_SHM_PREFIX) where SEM_SHM_PREFIX is "sem.", so it tries to create /dev/shm/sem.{name}, which fails because snapd only allows /dev/shm/snap.@{SNAP_NAME}.**. At a quick glance, there’s no mechanism (e.g. env var) to customize the prefix ("sem."). Is this an issue others have run into? Is there a recommended solution? Thanks in advance! Olivier ¹ http://man7.org/linux/man-pages/man7/sem_overview.7.html From dank at kegel.com Mon Jan 2 19:57:45 2017 From: dank at kegel.com (Dan Kegel) Date: Mon, 2 Jan 2017 11:57:45 -0800 Subject: lxc not working in classic on pi? Message-ID: I have a script from a classic ubuntu environment that wants to be able to create lxc containers on the fly. I tried running it on ubuntu core on the pi3, in the classic environment, but it failed: (classic)user at localhost:~$ sudo apt install lxc ... (classic)user at localhost:~$ sudo lxc-create -n foo -t download lxc-create: utils.c: get_template_path: 1394 No such file or directory - bad template: download (classic)user at localhost:~$ sudo apt install lxc-templates (classic)user at localhost:~$ sudo lxc-create -n foo -t download lxc-create: lxccontainer.c: create_run_template: 1290 container creation template for foo failed I guess I can live without isolating my jobs in lxc when running on pi for now, but this seems like a fidelity problem in the classic environment. From dank at kegel.com Tue Jan 3 00:11:30 2017 From: dank at kegel.com (Dan Kegel) Date: Mon, 2 Jan 2017 16:11:30 -0800 Subject: gnu screen does not work in classic? Message-ID: I tried to use 'screen' as usual to start a long-running job inside classic, but it failed because /proc/self/fd/0 was owned by root: $ ssh user at host Welcome to Ubuntu Core 16 (GNU/Linux 4.4.0-1030-raspi2 armv7l) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage Welcome to Snappy Ubuntu Core, a transactionally updated Ubuntu. * See https://ubuntu.com/snappy It's a brave new world here in Snappy Ubuntu Core! This machine does not use apt-get or deb packages. Please see 'snap --help' for app installation and transactional updates. Last login: Tue Jan 3 00:06:36 2017 from 10.10.150.120 user at host:~$ sudo classic mount: devpts is already mounted or /dev/pts busy devpts is already mounted on /dev/pts (classic)user at host:~$ ls -lL /proc/self/fd/0 crw------- 1 root root 136, 1 Jan 3 00:08 /proc/self/fd/0 (classic)user at host:~$ screen Cannot open your terminal '/dev/pts/1' - please check. (classic)user at host:~$ ls -l /proc/self/fd/0 lrwx------ 1 user user 64 Jan 3 00:08 /proc/self/fd/0 -> /dev/pts/1 (classic)user at host:~$ ls -l /dev/pts/1 crw------- 1 root root 136, 1 Jan 3 00:08 /dev/pts/1 From nick.moffitt at canonical.com Tue Jan 3 00:46:54 2017 From: nick.moffitt at canonical.com (Nick Moffitt) Date: Tue, 3 Jan 2017 00:46:54 +0000 Subject: gnu screen does not work in classic? In-Reply-To: References: Message-ID: <20170103004654.GG29257@zork.net> Dan Kegel: > I tried to use 'screen' as usual to start a long-running job > inside classic, but it failed because /proc/self/fd/0 was > owned by root: As a workaround, you can use /usr/bin/script from the bsdutils package to give you a fresh pty that screen won't get upset about. Something like this should do the trick: script -c 'screen -RAD' /dev/null -- Nick Moffitt From dank at kegel.com Tue Jan 3 00:55:56 2017 From: dank at kegel.com (Dan Kegel) Date: Mon, 2 Jan 2017 16:55:56 -0800 Subject: gnu screen does not work in classic? In-Reply-To: <20170103004654.GG29257@zork.net> References: <20170103004654.GG29257@zork.net> Message-ID: That sounds handy. tmux works fine, though. On Mon, Jan 2, 2017 at 4:46 PM, Nick Moffitt wrote: > Dan Kegel: >> I tried to use 'screen' as usual to start a long-running job >> inside classic, but it failed because /proc/self/fd/0 was >> owned by root: > > As a workaround, you can use /usr/bin/script from the bsdutils package > to give you a fresh pty that screen won't get upset about. Something > like this should do the trick: > > script -c 'screen -RAD' /dev/null > > -- > Nick Moffitt > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From elfgoh at yahoo.com Tue Jan 3 08:24:18 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 3 Jan 2017 08:24:18 +0000 (UTC) Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> Message-ID: <652919146.5148434.1483431858868@mail.yahoo.com> I did a filter of armhf packages for Ubuntu Core 16 snap packages, and found there to be less than 120. I did a search for nginx based on the mentioned filter and did not find any results. The impression left upon me is that there is a clear scarcity of snap packages right now, at least in the Ubuntu Store. This has lead me to wonder if a deploying snap on top of a classic install, say Debian, is a much better idea, at least in the short term, before the snap ecosystem is sufficiently matured and mainstream. Any thoughts on this? Thanks -- Luther From elfgoh at yahoo.com Tue Jan 3 08:39:54 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 3 Jan 2017 08:39:54 +0000 (UTC) Subject: Interface management in the context of snap in a classical Debian install References: <1533731758.5175031.1483432794299.ref@mail.yahoo.com> Message-ID: <1533731758.5175031.1483432794299@mail.yahoo.com> I am considering the scenario where snap is installed in a classical Debian install. I intend to package my golang web service in a snap. The web service may have some dependencies that are present in the debian repository, but not available as a snap. Examples could be a database like influxdb, or a reverse proxy like nginx. My question is: how will the snap be interfacing with non snap software in the context of interfaces[1]? Is there an example? I understand that it will be more ideal if the dependencies are also snaps, but this may not be possible in the near future. Please advise implications and other alternative implementations. Thanks. -- Luther [1] http://snapcraft.io/docs/core/interfaces From mark at ubuntu.com Tue Jan 3 09:12:47 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 3 Jan 2017 11:12:47 +0200 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <652919146.5148434.1483431858868@mail.yahoo.com> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> Message-ID: <277b6dc1-6c51-08fe-b3bb-bce3d4378c0e@ubuntu.com> On 03/01/17 10:24, Luther Goh Lu Feng wrote: > This has lead me to wonder if a deploying snap on top of a classic install, say Debian, is a much better idea, at least in the short term, before the snap ecosystem is sufficiently matured and mainstream. Any thoughts on this? Thanks Snaps on Ubuntu Classic or Debian are a nice way to transition, yes, until all the snaps are in place for your device. If you are shipping many devices to the field, then the management cost of a pure-snap approach should be dramatically lower than the cost of a mixed classic+snap approach. Mark From mark at ubuntu.com Tue Jan 3 09:14:37 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 3 Jan 2017 11:14:37 +0200 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <652919146.5148434.1483431858868@mail.yahoo.com> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> Message-ID: Also, something to be aware of, is that snaps are built by the upstream or vendor, not by the distribution. That means that architecture choices are up to the upstream. We do make cross-architecture build services available through Launchpad but vendors are not obliged to use those, and if they are using a third-party build service (for example on Travis as part of their CI) then architecture availability will be determined by those services. Mark From elfgoh at yahoo.com Tue Jan 3 09:42:04 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 3 Jan 2017 09:42:04 +0000 (UTC) Subject: Package naming clashes References: <268797910.5193126.1483436524541.ref@mail.yahoo.com> Message-ID: <268797910.5193126.1483436524541@mail.yahoo.com> I am sure that there is precedence and guidelines in place, but I couldn't to find the search result. Say someone in the community builds a snap for nginx, and later doesnt keep the snap up to date. Then another person builds a more updated nginx snap. How are the package names chosen so that there would be collisions, and people know that they are installing the latest working version? Is there some sort of handing and taking over for the package name from maintainer to maintainer? How is it done with Ubuntu deb packages at the moment? Thanks -- Luther From silver.bullet at zoho.com Tue Jan 3 09:47:42 2017 From: silver.bullet at zoho.com (Ralf Mardorf) Date: Tue, 3 Jan 2017 10:47:42 +0100 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> Message-ID: <20170103104742.72b68290@utnubu> On Tue, 3 Jan 2017 11:14:37 +0200, Mark Shuttleworth wrote: >Also, something to be aware of, is that snaps are built by the upstream >or vendor, not by the distribution. First of all, happy new year! Now to something unpleasant. Using snaps and allowed to ask for support by an official channel of a distribution is bound to a distribution. For example, http://snapcraft.io/ mentions Arch Linux. It's available by Arch repository, but frowned upon by Arch developers, as well as the majority of Arch users, if not by all Arch users. If an Arch user would use snaps, there would be no mailing list available to request help. I suspect not many distributions will help with snaps. There were at least two discussions on the Arch general mailing list. At least Arch Linux doesn't support it and it's very important, that in addition snaps are frowned upon, for a long list of very good reasons. Btw. it would be nice to remove Arch Linux from this list at http://snapcraft.io/ . I will not post links. I would welcome, if Mark would ask for an opinion at https://lists.archlinux.org//listinfo/arch-general and maybe on other distribution's mailing lists. The impression that upstream and vendors will provide snaps for installation on a huge amount of distros is wrong. Perhaps a minority of upstream developers is willing to contribute snaps for Ubuntu. Most common is that upstream supports no packages at all, or a DEB and/or a RPM, e.g. by installing the software to /opt without using shared libraries. Regards, Ralf From ogra at ubuntu.com Tue Jan 3 10:11:18 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 03 Jan 2017 11:11:18 +0100 Subject: gnu screen does not work in classic? In-Reply-To: <20170103004654.GG29257@zork.net> References: <20170103004654.GG29257@zork.net> Message-ID: <1483438278.18985.27.camel@ubuntu.com> hi, Am Dienstag, den 03.01.2017, 00:46 +0000 schrieb Nick Moffitt: > Dan Kegel: > > > > I tried to use 'screen' as usual to start a long-running job > > inside classic, but it failed because /proc/self/fd/0 was > > owned by root: > As a workaround, you can use /usr/bin/script from the bsdutils > package > to give you a fresh pty that screen won't get upset about.  Something > like this should do the trick: > >     script -c 'screen -RAD' /dev/null > if you look at /snap/classic/current/bin/classic you will notice that we already do this: ... # FIXME: workaround for https://bugs.launchpad.net/snappy/+bug/1611493 SCRIPT="script --quiet --return --command \"$SUDOCMD\" /dev/null" CMD="$DEVPTS; $SCRIPT" systemd-run --quiet --scope --unit=classic-$$.scope -- description="Classic shell" chroot "$ROOT" sh -c "$CMD" ... i assume the "/dev/pts already mounted" error is the issue here, seems systemd-run does not properly clean up on the stzop event and you keep the former pts instance around. i filed http://pad.lv/1653648 for this and will dig into it ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Tue Jan 3 11:07:59 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 3 Jan 2017 08:07:59 -0300 Subject: lxc not working in classic on pi? In-Reply-To: References: Message-ID: El 02/01/17 a las 16:57, Dan Kegel escribió: > I have a script from a classic ubuntu environment > that wants to be able to create lxc containers > on the fly. I tried running it on ubuntu core on the pi3, > in the classic environment, but it failed: > > (classic)user at localhost:~$ sudo apt install lxc > ... > (classic)user at localhost:~$ sudo lxc-create -n foo -t download > lxc-create: utils.c: get_template_path: 1394 No such file or directory > - bad template: download > (classic)user at localhost:~$ sudo apt install lxc-templates > (classic)user at localhost:~$ sudo lxc-create -n foo -t download > lxc-create: lxccontainer.c: create_run_template: 1290 container > creation template for foo failed > > I guess I can live without isolating my jobs in lxc > when running on pi for now, but this seems like a fidelity problem in > the classic environment. > For isolation might I suggest `snap install lxd` and manage your containers with that instead. From ogra at ubuntu.com Tue Jan 3 11:21:25 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 03 Jan 2017 12:21:25 +0100 Subject: lxc not working in classic on pi? In-Reply-To: References: Message-ID: <1483442485.18985.30.camel@ubuntu.com> hi, Am Montag, den 02.01.2017, 11:57 -0800 schrieb Dan Kegel: > I have a script from a classic ubuntu environment > that wants to be able to create lxc containers > on the fly.  I tried running it on ubuntu core on the pi3, > in the classic environment, but it failed: i dont think running lxc inside chroots (which the classic env is) is possible at all ...  like sergio said already, it might be better to use the lxc snap, though there we still have an open issue with group management that i am currently looking at ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Tue Jan 3 11:22:22 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 3 Jan 2017 08:22:22 -0300 Subject: Package naming clashes In-Reply-To: <268797910.5193126.1483436524541@mail.yahoo.com> References: <268797910.5193126.1483436524541.ref@mail.yahoo.com> <268797910.5193126.1483436524541@mail.yahoo.com> Message-ID: Hi! El 03/01/17 a las 06:42, Luther Goh Lu Feng escribió: > I am sure that there is precedence and guidelines in place, but I couldn't to find the search result. > > Say someone in the community builds a snap for nginx, and later doesnt keep the snap up to date. Then another person builds a more updated nginx snap. How are the package names chosen so that there would be collisions, and people know that they are installing the latest working version? Snap names that are really popular are all marked as reserved, so when you try to `snapcraft register` it you will get a "The name '' is reserved" and a link to a dispute form. A similar workflow for an already registered name exists. > Is there some sort of handing and taking over for the package name from maintainer to maintainer? How is it done with Ubuntu deb packages at the moment? Thanks There are mechanisms to share or transfer responsibility. Other new workflows to enhance the experience are coming. Are you facing a specific problem already? In the case of debs, it is mostly free for all if you are a core developer or you can sign up to be a maintainer using the appropriate channels[1]. There is one caveat, it is rather easy while the distribution series is under development but if not, you need to go through the SRUing process [2]. [1] https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess [2] https://wiki.ubuntu.com/StableReleaseUpdates From james.page at ubuntu.com Tue Jan 3 11:37:38 2017 From: james.page at ubuntu.com (James Page) Date: Tue, 03 Jan 2017 11:37:38 +0000 Subject: New 2.20 snapd release In-Reply-To: <20161216090900.GF15361@bod> References: <20161216090900.GF15361@bod> Message-ID: Hi Michael On Fri, 16 Dec 2016 at 09:09 Michael Vogt wrote: > My personal hightlight of this release is the "alias" support. As you > are probably aware, snaps usually provide secondary commands as > "$snap.$app", e.g. mongo32.dump. While this is great and it means you > can have monogo26 and mongo32 installed at the same time without > command conflicts, the downside is that scripts that assume the top > level mongodump command will not work. Aliases solve this problem by > allowing a snap developer to setup well-defined aliases like > mongo32.dump to mongodump, and users to control which aliases to > enable. In the near future, we'll also introduce default aliases which > are automatically setup unless the user explicitly disables them. > Great release and a great feature - already trying this out with some of the OpenStack snaps as it will make switching existing deployment tooling to snaps much easier. One question - are there any plans to apply the same aliases approach to the name of systemd units provided by a snap? This would avoid a whole lot of rewriting of things like: glance-api -> snap.glance.api in some of the uses cases I've been looking at. Cheers James -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Tue Jan 3 11:57:37 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 3 Jan 2017 09:57:37 -0200 Subject: New 2.20 snapd release In-Reply-To: References: <20161216090900.GF15361@bod> Message-ID: Will systemd handle multiple services with the same name without complaining? How would it disambiguate? We can pull off snap aliases because the binary paths are separate (not /usr/bin), and thus won't actually conflict even if system packages and snaps define the same name. On Tue, Jan 3, 2017 at 9:37 AM, James Page wrote: > Hi Michael > > On Fri, 16 Dec 2016 at 09:09 Michael Vogt > wrote: > >> My personal hightlight of this release is the "alias" support. As you >> are probably aware, snaps usually provide secondary commands as >> "$snap.$app", e.g. mongo32.dump. While this is great and it means you >> can have monogo26 and mongo32 installed at the same time without >> command conflicts, the downside is that scripts that assume the top >> level mongodump command will not work. Aliases solve this problem by >> allowing a snap developer to setup well-defined aliases like >> mongo32.dump to mongodump, and users to control which aliases to >> enable. In the near future, we'll also introduce default aliases which >> are automatically setup unless the user explicitly disables them. >> > > Great release and a great feature - already trying this out with some of > the OpenStack snaps as it will make switching existing deployment tooling > to snaps much easier. > > One question - are there any plans to apply the same aliases approach to > the name of systemd units provided by a snap? This would avoid a whole lot > of rewriting of things like: > > glance-api -> snap.glance.api > > in some of the uses cases I've been looking at. > > Cheers > > James > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Tue Jan 3 12:00:53 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 3 Jan 2017 20:00:53 +0800 Subject: Package naming clashes In-Reply-To: <268797910.5193126.1483436524541@mail.yahoo.com> References: <268797910.5193126.1483436524541.ref@mail.yahoo.com> <268797910.5193126.1483436524541@mail.yahoo.com> Message-ID: Hi Luther, Some of the package names are reserved like "google". For normal snaps, you need to use: $ snapcraft register snap-name to make sure your name is successfully registered. For more info, please refer to: https://github.com/snapcore/snapcraft/blob/master/docs/upload-your-snap.md Best regards, XiaoGuo On Tue, Jan 3, 2017 at 5:42 PM, Luther Goh Lu Feng wrote: > I am sure that there is precedence and guidelines in place, but I couldn't > to find the search result. > > Say someone in the community builds a snap for nginx, and later doesnt > keep the snap up to date. Then another person builds a more updated nginx > snap. How are the package names chosen so that there would be collisions, > and people know that they are installing the latest working version? > > Is there some sort of handing and taking over for the package name from > maintainer to maintainer? How is it done with Ubuntu deb packages at the > moment? Thanks > > > -- Luther > > -- > 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 sergio.schvezov at canonical.com Tue Jan 3 12:14:37 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 3 Jan 2017 09:14:37 -0300 Subject: Issues generating snap In-Reply-To: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> Message-ID: <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> El 01/01/17 a las 18:18, Gareth France escribió: > Snapcraft version 2.24+16.10 > Ubuntu version 16.10 > I am building the hello world example from the snap tour. Below is the > full output: > > snapcraft > "grade" property not specified: defaulting to "stable" > Use of build-properties in the schema is deprecated. > Plugins should now implement get_build_properties > Preparing to pull gnu-hello > Pulling gnu-hello > Downloading > 'hello-2.10.tar.gz'[==========================================] 100% > Preparing to build gnu-hello > Building gnu-hello > ./configure --prefix= > /tmp/tmpagub9i4k: 3: export: > Files/Programming/Python/RokuTerm/snapcraft-tour/00-SNAPCRAFT/01-easy-start/stage/usr/share/perl5/: > bad variable name > Command '['/bin/sh', '/tmp/tmpagub9i4k', './configure', '--prefix=']' > returned non-zero exit status 2 Well it eases me to know that we test this as an autopackage test and I just ran this in a clean yakkety container to double check http://paste.ubuntu.com/23733207/ Is there some missing bit of information here? From james.page at ubuntu.com Tue Jan 3 12:15:54 2017 From: james.page at ubuntu.com (James Page) Date: Tue, 03 Jan 2017 12:15:54 +0000 Subject: New 2.20 snapd release In-Reply-To: References: <20161216090900.GF15361@bod> Message-ID: On Tue, 3 Jan 2017 at 11:58 Gustavo Niemeyer wrote: > Will systemd handle multiple services with the same name without > complaining? How would it disambiguate? > > We can pull off snap aliases because the binary paths are separate (not > /usr/bin), and thus won't actually conflict even if system packages and > snaps define the same name. > I could see how this might be a problem; an Alias can either be defined in the systemd unit file (in which case systemd will create an appropriate symlink), or by creating the symlink from alias->actual in /etc/systemd/system - I'll poke at things and see how that might break! > > On Tue, Jan 3, 2017 at 9:37 AM, James Page wrote: > > Hi Michael > > On Fri, 16 Dec 2016 at 09:09 Michael Vogt > wrote: > > My personal hightlight of this release is the "alias" support. As you > are probably aware, snaps usually provide secondary commands as > "$snap.$app", e.g. mongo32.dump. While this is great and it means you > can have monogo26 and mongo32 installed at the same time without > command conflicts, the downside is that scripts that assume the top > level mongodump command will not work. Aliases solve this problem by > allowing a snap developer to setup well-defined aliases like > mongo32.dump to mongodump, and users to control which aliases to > enable. In the near future, we'll also introduce default aliases which > are automatically setup unless the user explicitly disables them. > > > Great release and a great feature - already trying this out with some of > the OpenStack snaps as it will make switching existing deployment tooling > to snaps much easier. > > One question - are there any plans to apply the same aliases approach to > the name of systemd units provided by a snap? This would avoid a whole lot > of rewriting of things like: > > glance-api -> snap.glance.api > > in some of the uses cases I've been looking at. > > Cheers > > James > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.page at ubuntu.com Tue Jan 3 12:18:58 2017 From: james.page at ubuntu.com (James Page) Date: Tue, 03 Jan 2017 12:18:58 +0000 Subject: New 2.20 snapd release In-Reply-To: References: <20161216090900.GF15361@bod> Message-ID: On Tue, 3 Jan 2017 at 12:15 James Page wrote: > On Tue, 3 Jan 2017 at 11:58 Gustavo Niemeyer < > gustavo.niemeyer at canonical.com> wrote: > > Will systemd handle multiple services with the same name without > complaining? How would it disambiguate? > > We can pull off snap aliases because the binary paths are separate (not > /usr/bin), and thus won't actually conflict even if system packages and > snaps define the same name. > > > I could see how this might be a problem; an Alias can either be defined in > the systemd unit file (in which case systemd will create an appropriate > symlink), or by creating the symlink from alias->actual in > /etc/systemd/system - I'll poke at things and see how that might break! > It would appear that any symlink created in /etc/systemd/system masks anything provided by a deb package in /lib/systemd/system - so the glance-api alias from a snap would override the glance-api systemd unit file provided by a deb package installed on the same system I guess this also fits into the general question of how to transition an existing system from deb->snap in a elegant way as well :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Tue Jan 3 12:25:15 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 3 Jan 2017 10:25:15 -0200 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <20170103104742.72b68290@utnubu> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <20170103104742.72b68290@utnubu> Message-ID: On Tue, Jan 3, 2017 at 7:47 AM, Ralf Mardorf wrote: > On Tue, 3 Jan 2017 11:14:37 +0200, Mark Shuttleworth wrote: > >Also, something to be aware of, is that snaps are built by the upstream > >or vendor, not by the distribution. > > First of all, happy new year! > > Now to something unpleasant. > Welcome to the new year, and this looks like a fine conversation. Thanks for raising your concerns here. > Using snaps and allowed to ask for support by an official channel of a > distribution is bound to a distribution. > > For example, http://snapcraft.io/ mentions Arch Linux. It's available > by Arch repository, but frowned upon by Arch developers, as well as the > majority of Arch users, if not by all Arch users. > > If an Arch user would use snaps, there would be no mailing list > available to request help. > This mailing list is a fine place to ask for help about snaps on Arch or anywhere else. The topic here is snaps, snapcraft, and snapd, not a particular Linux distribution. I suspect not many distributions will help with snaps. There were at > least two discussions on the Arch general mailing list. At least Arch > Linux doesn't support it and it's very important, that in addition > snaps are frowned upon, for a long list of very good reasons. > > Btw. it would be nice to remove Arch Linux from this list at > http://snapcraft.io/ . (...) > While somebody is willing to help make snapd work on Arch, the listing seems appropriate. We're not asking or expecting you to contribute in particular, unless you're naturally inclined to do so (which would be most welcome, obviously). Thanks again for coming here. gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Tue Jan 3 12:48:24 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 3 Jan 2017 14:48:24 +0200 Subject: Package naming clashes In-Reply-To: <268797910.5193126.1483436524541@mail.yahoo.com> References: <268797910.5193126.1483436524541.ref@mail.yahoo.com> <268797910.5193126.1483436524541@mail.yahoo.com> Message-ID: <76c13d0c-1d4f-13d3-f3f4-720f9c85e063@ubuntu.com> On 03/01/17 11:42, Luther Goh Lu Feng wrote: > Is there some sort of handing and taking over for the package name from maintainer to maintainer? How is it done with Ubuntu deb packages at the moment? Thanks We are working on snap publisher transfer right now, yes. At the moment those snaps would need different names. In the deb world this is less of an issue because all packages are built centrally. Mark From silver.bullet at zoho.com Tue Jan 3 12:57:38 2017 From: silver.bullet at zoho.com (Ralf Mardorf) Date: Tue, 3 Jan 2017 13:57:38 +0100 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <20170103104742.72b68290@utnubu> Message-ID: <20170103135738.0ad60def@utnubu> On Tue, 3 Jan 2017 10:25:15 -0200, Gustavo Niemeyer wrote: >This mailing list is a fine place to ask for help about snaps on Arch >or anywhere else. Fair enough. I edited the Arch Wiki, https://wiki.archlinux.org/index.php/Snapd#Support . Regards, Ralf From silver.bullet at zoho.com Tue Jan 3 13:02:59 2017 From: silver.bullet at zoho.com (Ralf Mardorf) Date: Tue, 3 Jan 2017 14:02:59 +0100 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <20170103135738.0ad60def@utnubu> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <20170103104742.72b68290@utnubu> <20170103135738.0ad60def@utnubu> Message-ID: <20170103140259.273398ab@utnubu> On Tue, 3 Jan 2017 13:57:38 +0100, Ralf Mardorf wrote: >On Tue, 3 Jan 2017 10:25:15 -0200, Gustavo Niemeyer wrote: >>This mailing list is a fine place to ask for help about snaps on Arch >>or anywhere else. > >Fair enough. I edited the Arch Wiki, >https://wiki.archlinux.org/index.php/Snapd#Support . An important note by the Arch Wiki is "Warning: snap-confine is built with the --disable-apparmor option; full confinement relies on an AppArmor enabled kernel with Ubuntu's Linux 4.4 patchset applied and a related profile for the snap." - https://wiki.archlinux.org/index.php/Snapd#Installation I guess this is something upstream/vendors should know about snaps and other distros, at least about Arch Linux. Regards, Ralf From mark at ubuntu.com Tue Jan 3 13:08:26 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 3 Jan 2017 15:08:26 +0200 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <20170103140259.273398ab@utnubu> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <20170103104742.72b68290@utnubu> <20170103135738.0ad60def@utnubu> <20170103140259.273398ab@utnubu> Message-ID: On 03/01/17 15:02, Ralf Mardorf wrote: > An important note by the Arch Wiki is > "Warning: snap-confine is built with the --disable-apparmor option; > full confinement relies on an AppArmor enabled kernel with Ubuntu's > Linux 4.4 patchset applied and a related profile for the snap." - > https://wiki.archlinux.org/index.php/Snapd#Installation > > I guess this is something upstream/vendors should know about snaps and > other distros, at least about Arch Linux. My understanding is that Arch doesn't have a standard mac-based security framework enabled; if that's incorrect we'd be glad to work together to enable full security for confined snaps on Arch! Also, with the new 'classic' mode, there will be a range of utility snaps that are not sand-boxed on Ubuntu either, but are still very useful and no doubt just as useful to Arch users and developers as well. Mark From claudioandre.br at gmail.com Tue Jan 3 13:31:55 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=c3=a9?=) Date: Tue, 3 Jan 2017 11:31:55 -0200 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <20170103140259.273398ab@utnubu> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <20170103104742.72b68290@utnubu> <20170103135738.0ad60def@utnubu> <20170103140259.273398ab@utnubu> Message-ID: <4490fcea-b6ea-5c08-3895-88077b448a35@gmail.com> Em 03/01/2017 11:02, Ralf Mardorf escreveu: >> On Tue, 3 Jan 2017 10:25:15 -0200, Gustavo Niemeyer wrote: >>> This mailing list is a fine place to ask for help about snaps on Arch >>> or anywhere else. We fill in "Website" and " Support" fields in Ubuntu Store. This information should be available in snap list (or snap info/details/whatever). My point is: - If a snap works fine on 16.04 but not in distro X, Canonical, please, take a look at it. - But, if the user is wondering about SIMD support on ARM, he/she must contact upstream. > An important note by the Arch Wiki is > > "Warning: snap-confine is built with the --disable-apparmor option; > full confinement relies on an AppArmor enabled kernel with Ubuntu's > Linux 4.4 patchset applied and a related profile for the snap." - > https://wiki.archlinux.org/index.php/Snapd#Installation > > I guess this is something upstream/vendors should know about snaps and > other distros, at least about Arch Linux. +1, this information is quite important. Claudio -------------- next part -------------- An HTML attachment was scrubbed... URL: From silver.bullet at zoho.com Tue Jan 3 13:38:42 2017 From: silver.bullet at zoho.com (Ralf Mardorf) Date: Tue, 3 Jan 2017 14:38:42 +0100 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <20170103104742.72b68290@utnubu> <20170103135738.0ad60def@utnubu> <20170103140259.273398ab@utnubu> Message-ID: <20170103143842.106c25ce@utnubu> On Tue, 3 Jan 2017 15:08:26 +0200, Mark Shuttleworth wrote: >My understanding is that Arch doesn't have a standard mac-based >security framework enabled; if that's incorrect we'd be glad to work >together to enable full security for confined snaps on Arch! I'm neither an Arch developer, nor a trusted user. I'm just an Arch user who tested building a snap and who dislikes the concept. Most likely just a minority of Arch users is interested in snaps and similar approaches. Somebody familiar with snaps and Arch Linux could provide everything needed by https://aur.archlinux.org/ . https://aur.archlinux.org/packages/snapcraft/ has got 2 votes only and a comment "Is there any documentation on use Snapcraft on Arch? [snip]" I prefer building DEB packages for Ubuntu and to write Arch PKGBUILDs for Arch Linux. For my needs (real-time audio) it's not worth the effort to learn how to build snaps and to workaround issues that snaps might cause. Everybody is free to contribute to Arch Linux and it's easy to see how popular the contribution is, by taking a look at the votes. However, my concerns are about misinterpreting how good snaps are supported by other distros. For Gentoo it seems to be similar, as it is for Arch Linux. "An unofficial Gentoo Overlay that enables installation of Canonical's "Snappy" backbone." - https://github.com/zyga/gentoo-snappy Regards, Ralf From leo.arias at canonical.com Tue Jan 3 16:08:08 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 3 Jan 2017 10:08:08 -0600 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <652919146.5148434.1483431858868@mail.yahoo.com> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> Message-ID: Hello! On Tue, Jan 3, 2017 at 2:24 AM, Luther Goh Lu Feng wrote: > I did a filter of armhf packages for Ubuntu Core 16 snap packages, and found there to be less than 120. I did a search for nginx based on the mentioned filter and did not find any results. The impression left upon me is that there is a clear scarcity of snap packages right now, at least in the Ubuntu Store. During the past month we were focusing on the automated delivery of new versions from travis to the Ubuntu store. It has been an interesting way to polish our story; but travis cannot build for armhf. That's why you see less snaps in that architecture. Now, with the start of the new year and some nice improvements in the launchpad builders, we will be focusing on building the snaps for all the supported architectures. Expect the numbers for armhf to increase soon :) > This has lead me to wonder if a deploying snap on top of a classic install, say Debian, is a much better idea, at least in the short term, before the snap ecosystem is sufficiently matured and mainstream. Any thoughts on this? Thanks That sounds like a good solution. If debian works for you, we are working to release there every new version of snapd and to make sure that all the snaps work without a problem. If you install a classic debian or ubuntu armhf, you can mix snaps and debs according to your needs. Or you could also use an Ubuntu Core system, and enable the classic mode to install debs. pura vida. -- ¡paz y baile! http://www.ubuntu.com From elfgoh at yahoo.com Tue Jan 3 16:26:27 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 3 Jan 2017 16:26:27 +0000 (UTC) Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> Message-ID: <1426175213.5334661.1483460787786@mail.yahoo.com> On Wednesday, January 4, 2017 12:08 AM, Leo Arias wrote: > That sounds like a good solution. If debian works for you, we are working to release there every new version of snapd and to make sure that all the snaps work without a problem. If you install a classic debian or ubuntu armhf, you can mix snaps and debs according to your needs. Or you could also use an Ubuntu Core system, and enable the classic mode to install debs. Thanks for suggesting enabling Ubuntu classic mode to install debs. I most certainly haven't thought of that! I don't mean to be provocative, but aside from debian and ubuntu having differing philosophies, what are the very apparent pros and cons of a - Ubuntu core + snaps via classic mode - Debian + snaps via snap -- Luther From leo.arias at canonical.com Tue Jan 3 17:49:01 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 3 Jan 2017 11:49:01 -0600 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: <1426175213.5334661.1483460787786@mail.yahoo.com> References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <1426175213.5334661.1483460787786@mail.yahoo.com> Message-ID: On Tue, Jan 3, 2017 at 10:26 AM, Luther Goh Lu Feng wrote: > - Ubuntu core + snaps via classic mode If you install a deb in classic mode, it will not be able to affect the kernel, gadget or core snaps. It's isolated. The deb can break your classic chroot, but nothing else. You can just throw it away, and create it clean again. However, there are still things that will work on a classic ubuntu installation, but will not work in classic mode yet. Most of them are just bugs that need to be reported and somebody will fix them. I use classic mode to do prototyping and development while I get my software ready to work as a snap. And I find myself using it less every day, as new snaps are released to the store. > - Debian + snaps via snap This will give you a complete traditional system. Everything you learned in debian and ubuntu before will just work. So it could be a softer transition while you learn about snaps and your dependencies are shipped as snaps. You will not get all the benefits of a full snappy system, but you will get some by installing the snaps that are ready. As always, it's a trade-off. If you can give a try to both approaches, I would be really interested to hear your opinion. pura vida -- ¡paz y baile! http://www.ubuntu.com From dank at kegel.com Tue Jan 3 18:17:43 2017 From: dank at kegel.com (Dan Kegel) Date: Tue, 3 Jan 2017 10:17:43 -0800 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <1426175213.5334661.1483460787786@mail.yahoo.com> Message-ID: On Tue, Jan 3, 2017 at 9:49 AM, Leo Arias wrote: >> - Debian + snaps via snap > > This will give you a complete traditional system. Everything you > learned in debian and ubuntu before will just work. So it could be a > softer transition while you learn about snaps and your dependencies > are shipped as snaps. You will not get all the benefits of a full > snappy system, but you will get some by installing the snaps that are > ready. This seems like a really good tradeoff for the moment. Even if all our snaps are in devmode initially, it provides a nice way to package up apps in a way that is more atomic than a pile of debs. (Now, don't get me wrong, I love .debs. But atomic update of a whole stack solves a lot of problems. We've got the disk and bandwidth, may as well use it...) From gareth.france at cliftonts.co.uk Tue Jan 3 18:39:34 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Tue, 3 Jan 2017 18:39:34 +0000 Subject: Issues generating snap In-Reply-To: <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> Message-ID: On 03/01/17 12:14, Sergio Schvezov wrote: > Well it eases me to know that we test this as an autopackage test and > I just ran this in a clean yakkety container to double check > http://paste.ubuntu.com/23733207/ > > Is there some missing bit of information here? I don't know, you tell me. It has always frustrated me that it is physically not possible to package programs to release in the repositories. I tried, failed, paid someone to package it and somehow still managed to fail! When I started looking into snaps this week it seemed to be a much easier process but alas still it does not work and nobody seems to be able to tell me why. There does not seem to be any documentation on fault finding at all. The instructions tell me to install snapcraft and build-essential, then run snapcraft in the directory for this program. I have done this and provided the result here. I do not know anything more to add. From jamie at canonical.com Tue Jan 3 19:11:36 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 03 Jan 2017 13:11:36 -0600 Subject: Snapping applications that uses keyring In-Reply-To: <270cf142-76bf-1779-8981-3110224f5f2c@canonical.com> References: <270cf142-76bf-1779-8981-3110224f5f2c@canonical.com> Message-ID: <1483470696.3074.3.camel@canonical.com> On Wed, 2016-12-21 at 10:11 -0800, Kyle Fazzari wrote: > Hey all. > > Has anyone tried to snap an application that uses a keyring to store > passwords? I took a crack at the Nextcloud desktop client yesterday, and > as it stands right now I need to enter my Nextcloud password every time > I start it up as it has nowhere to save it. > > I know relatively little about the gnome-keyring-daemon, but I assume it > encrypts its keyring typically with the login password, and is unlocked > by pam as a side effect of logging in. Do we have an interface covering > access to the default keyring? Or do we need to embed > gnome-keyring-daemon inside our snaps? > Based on this email and responses, it sounds like you are interested in classic systems (ie, non-all snap systems, as opposed to 'confinement: classic') and using the user session's keyring manager, in this case, gnome-keyring. In that light, a 'gnome-keyring' interface needs to be implemented as an implicitClassicSlot. -- 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 Tue Jan 3 19:21:05 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 03 Jan 2017 13:21:05 -0600 Subject: snapd and semaphores In-Reply-To: References: Message-ID: <1483471265.3074.6.camel@canonical.com> On Mon, 2017-01-02 at 16:34 +0100, Olivier Tilloy wrote: > Hi everyone, and happy new year! > > I’m snapping an app that makes use of semaphores¹ and seeing an > apparmor denial. The glibc implementation of sem_open calls > SHM_GET_NAME(EINVAL,SEM_FAILED,SEM_SHM_PREFIX) where SEM_SHM_PREFIX is > "sem.", so it tries to create /dev/shm/sem.{name}, which fails because > snapd only allows /dev/shm/snap.@{SNAP_NAME}.**. > At a quick glance, there’s no mechanism (e.g. env var) to customize > the prefix ("sem."). > Is this an issue others have run into? Is there a recommended solution? > > Thanks in advance! > Reading sem_overview, it seems that we should also allow: '/dev/shm/sem.snap.@{SNAP_NAME}.*'. In this manner, we namespace /dev/shm/sem.* by snap name just like we do other parts of the OS. Please file a bug and we'll get this fixed. Thanks! -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kyle.fazzari at canonical.com Tue Jan 3 19:56:56 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 3 Jan 2017 11:56:56 -0800 Subject: Snapping applications that uses keyring In-Reply-To: <1483470696.3074.3.camel@canonical.com> References: <270cf142-76bf-1779-8981-3110224f5f2c@canonical.com> <1483470696.3074.3.camel@canonical.com> Message-ID: <10d042a7-5573-4189-d1ab-3a6d6acdc4a1@canonical.com> On 01/03/2017 11:11 AM, Jamie Strandboge wrote: > On Wed, 2016-12-21 at 10:11 -0800, Kyle Fazzari wrote: >> Hey all. >> >> Has anyone tried to snap an application that uses a keyring to store >> passwords? I took a crack at the Nextcloud desktop client yesterday, and >> as it stands right now I need to enter my Nextcloud password every time >> I start it up as it has nowhere to save it. >> >> I know relatively little about the gnome-keyring-daemon, but I assume it >> encrypts its keyring typically with the login password, and is unlocked >> by pam as a side effect of logging in. Do we have an interface covering >> access to the default keyring? Or do we need to embed >> gnome-keyring-daemon inside our snaps? >> > > Based on this email and responses, it sounds like you are interested in classic > systems (ie, non-all snap systems, as opposed to 'confinement: classic') and > using the user session's keyring manager, in this case, gnome-keyring. In that > light, a 'gnome-keyring' interface needs to be implemented as an > implicitClassicSlot. Indeed, you understand correctly, thanks for the information! I've logged the following bug for this: https://bugs.launchpad.net/snappy/+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 sergio.schvezov at canonical.com Tue Jan 3 20:33:09 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 3 Jan 2017 17:33:09 -0300 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> Message-ID: <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> El 03/01/17 a las 15:39, Gareth France escribió: > > > On 03/01/17 12:14, Sergio Schvezov wrote: >> Well it eases me to know that we test this as an autopackage test and >> I just ran this in a clean yakkety container to double check >> http://paste.ubuntu.com/23733207/ >> >> Is there some missing bit of information here? > I don't know, you tell me. It has always frustrated me that it is > physically not possible to package programs to release in the > repositories. I tried, failed, paid someone to package it and somehow > still managed to fail! When I started looking into snaps this week it > seemed to be a much easier process but alas still it does not work and > nobody seems to be able to tell me why. There does not seem to be any > documentation on fault finding at all. > > The instructions tell me to install snapcraft and build-essential, > then run snapcraft in the directory for this program. I have done this > and provided the result here. I do not know anything more to add. Do you add PPAs? Can you install lxd and create a yakkety container as I did in the paste and try from there? From gareth.france at cliftonts.co.uk Tue Jan 3 20:49:39 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Tue, 3 Jan 2017 20:49:39 +0000 Subject: Issues generating snap In-Reply-To: <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: On 03/01/17 20:33, Sergio Schvezov wrote: > Can you install lxd and create a yakkety container as I did in the > paste and try from there? Installed, but sorry, how do I do that? From leo.arias at canonical.com Wed Jan 4 01:35:22 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 3 Jan 2017 19:35:22 -0600 Subject: Source does not exist when using snapcraft In-Reply-To: References: Message-ID: Hello! On Mon, Dec 19, 2016 at 9:03 PM, Bo Dong wrote: > Hi, > > I'm now using snapcraft to pack the ros example in snapcraft-examples. But > it seem the source is not exist. Please view here. > https://pastebin.ubuntu.com/23656750/ > I'd like to know is there any possible I can change the source list manually > when using snapcraft? I'm sorry about that. We are working on enabling the snapcraft tests in different architectures, and we actually found an error in the ros sources: https://github.com/snapcore/snapcraft/pull/990/files#diff-3cc26b49a70ee86523598a96dd385301R110 This fix should land in the next snapcraft release, and with the new tests executions in armhf we'll make sure that it never happens again. If you can't wait for the release later in the week, you will have to use snapcraft from source, and patch that line. Let me know if you need a hand to set up your environment. pura vida. From xiaoguo.liu at canonical.com Wed Jan 4 04:13:46 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 4 Jan 2017 12:13:46 +0800 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: Hi Gareth, Based on sergio's scripts at http://paste.ubuntu.com/23733207/ , I have created a tutorial for it. Hopefully, it is useful to you. You may find it at: http://blog.csdn.net/ubuntutouch/article/details/54017425 Best regards, XiaoGuo On Wed, Jan 4, 2017 at 4:49 AM, Gareth France wrote: > > > On 03/01/17 20:33, Sergio Schvezov wrote: > >> Can you install lxd and create a yakkety container as I did in the paste >> and try from there? >> > > Installed, but sorry, how do I do that? > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Wed Jan 4 05:23:14 2017 From: manik at canonical.com (Manik Taneja) Date: Tue, 3 Jan 2017 21:23:14 -0800 Subject: store errors Message-ID: hi there, i am continuing to see the store timeout errors. they are happening way too frequently to require a deeper review. if they are indeed related to our CDN provider, can we re-visit the need for a different provider? [image: Inline image 1] cheers, manik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 151963 bytes Desc: not available URL: From gareth.france at cliftonts.co.uk Wed Jan 4 05:33:21 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Wed, 4 Jan 2017 05:33:21 +0000 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: On 04/01/17 04:13, XiaoGuo Liu wrote: > Hi Gareth, > > Based on sergio's scripts at http://paste.ubuntu.com/23733207/ > , I have created a tutorial for > it. Hopefully, it is useful to you. You may find it at: > > http://blog.csdn.net/ubuntutouch/article/details/54017425 > > Best regards, > XiaoGuo > That is wonderful, thank you. However I have encountered several issues. First your tutorial is in Chinese, second it is not clear how you are naming your container (the command to create it simply refers to it as yakkety but the responses to that command state creating and starting flying-snake). When adding a user mine simply returns to the command prompt it does not add user, group, home directory, request a password etc. Adding admin privilages same issue. Then you tell me to add something at the end of 'the file' but you have not said which file or how I should be accessing it. I decided to stop here as I doubt very much this is working at my end. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Wed Jan 4 06:34:30 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Wed, 4 Jan 2017 06:34:30 +0000 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: On 04/01/17 04:13, XiaoGuo Liu wrote: > Hi Gareth, > > Based on sergio's scripts at http://paste.ubuntu.com/23733207/ > , I have created a tutorial for > it. Hopefully, it is useful to you. You may find it at: > > http://blog.csdn.net/ubuntutouch/article/details/54017425 > > Best regards, > XiaoGuo I have got it working, which is amazing. I've been trying to package stuff for years with no success. However now when I run my installed snap I just get: /usr/bin/env: 'python': No such file or directory It is a python script I've packaged. Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhaines at ubuntu.com Wed Jan 4 06:39:06 2017 From: nhaines at ubuntu.com (Nathan Haines) Date: Tue, 3 Jan 2017 22:39:06 -0800 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: <72be3296-4c84-dc66-56c9-9f4e18d596dc@ubuntu.com> On 01/03/2017 09:33 PM, Gareth France wrote: > second it is not clear how you are > naming your container (the command to create it simply refers to it as > yakkety but the responses to that command state creating and starting > flying-snake). When you create a container, you specify the image to use as the template and then the container name. If you do not specify a container name, a random name will be used instead. So, to create a container based on Ubuntu 16.10 named foobar, you would run: $ lxc launch ubuntu:yakkety foobar The file to be edited is /etc/sudoers, and can be edited using your favorite text editor. Just start the command with: $ lxc exec foobar -- sudo and finish the line with your favorite editor plus the path /etc/sudoers. This and more is explained in the link provided in the tutorial: https://linuxcontainers.org/lxd/getting-started-cli/ -- Nathan Haines Ubuntu - http://www.ubuntu.com/ From gareth.france at cliftonts.co.uk Wed Jan 4 06:41:26 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Wed, 4 Jan 2017 06:41:26 +0000 Subject: Issues generating snap In-Reply-To: <72be3296-4c84-dc66-56c9-9f4e18d596dc@ubuntu.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <72be3296-4c84-dc66-56c9-9f4e18d596dc@ubuntu.com> Message-ID: <7f0a6877-b595-2325-4fff-1606f07580b9@cliftonts.co.uk> On 04/01/17 06:39, Nathan Haines wrote: > On 01/03/2017 09:33 PM, Gareth France wrote: >> second it is not clear how you are >> naming your container (the command to create it simply refers to it as >> yakkety but the responses to that command state creating and starting >> flying-snake). > > When you create a container, you specify the image to use as the > template and then the container name. If you do not specify a > container name, a random name will be used instead. > > So, to create a container based on Ubuntu 16.10 named foobar, you > would run: > > $ lxc launch ubuntu:yakkety foobar > > The file to be edited is /etc/sudoers, and can be edited using your > favorite text editor. Just start the command with: > > $ lxc exec foobar -- sudo > > and finish the line with your favorite editor plus the path /etc/sudoers. > > This and more is explained in the link provided in the tutorial: > > https://linuxcontainers.org/lxd/getting-started-cli/ > Thank you. There were some issues with the guide created but I have resolved them now. However my completed snap does not work. After installing running the command results in: /usr/bin/env: 'python': No such file or directory Any ideas? From mark at ubuntu.com Wed Jan 4 07:30:51 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 4 Jan 2017 09:30:51 +0200 Subject: Thinking of installing snap on Debian due to scarcity of snap packages for armhf In-Reply-To: References: <652919146.5148434.1483431858868.ref@mail.yahoo.com> <652919146.5148434.1483431858868@mail.yahoo.com> <1426175213.5334661.1483460787786@mail.yahoo.com> Message-ID: Leo, I think we're inadvertently confusing folks by talking about the two different kinds of "classic" in the same thread, although our use of the term "classic" for two different things is the root cause. Luther, there are two different 'classics' in play. Classic Ubuntu is the deb based Ubuntu, where you install a root filesystem which deb based, and where confinement is a mixed-proposition. Snaps can be installed on Classic Ubuntu, they get a crafted filesystem space that they see depending on the metadata properties of the snap (they can sometimes see the deb based filesystem, sometimes they can only see a core snap based filesystem, it depends on their properties). Ubuntu Core is the "pure snap" world, where *everything is a snap by default*. But on Ubuntu Core, you can create a special container (the "classic mode") where you can use debs. These two approaches serve different needs. For developer environments, or in the cloud, it's often convenient to use debs for the base system. You have a developer to look after the system and so totally automated updates aren't as important. Also, there's a high ratio of professionals-to-systems, so admin costs disappear in that budget (you don't think of yourself as paying a price for admining your own system, even if in fact there is a cost in time). So the Classic Ubuntu approach gives us snaps as a convenient delivery mechanism for newer apps on the older, but familiar and convenient, deb based filesystem. For devices, or for very simplistic cloud systems like container hosts, you want to have a base system that has the very low friction of snaps by default. Imagine having 10 million home routers out there. Each of them is very cheap to buy, but it would be expensive to SSH to them individually and resolve package conflicts. So a pure-snap base system for devices makes a lot of sense - you have a few apps that you care about, and you want the lowest possible friction across millions of those devices while preserving security and the ability to updates them easily. So Leo was talking about the "classic mode" (container) on a "pure-snap Ubuntu Core" device. I was talking about "snaps on a classic (deb-based root filesystem) Ubuntu". Make sense? In your case, I think my approach will be better for you. Use vanilla Ubuntu Server (deb based and familiar) then use snaps for fresher and auto-updating apps. Mark On 03/01/17 19:49, Leo Arias wrote: > On Tue, Jan 3, 2017 at 10:26 AM, Luther Goh Lu Feng wrote: >> - Ubuntu core + snaps via classic mode > If you install a deb in classic mode, it will not be able to affect > the kernel, gadget or core snaps. It's isolated. The deb can break > your classic chroot, but nothing else. You can just throw it away, and > create it clean again. > However, there are still things that will work on a classic ubuntu > installation, but will not work in classic mode yet. Most of them are > just bugs that need to be reported and somebody will fix them. > > I use classic mode to do prototyping and development while I get my > software ready to work as a snap. And I find myself using it less > every day, as new snaps are released to the store. > >> - Debian + snaps via snap > This will give you a complete traditional system. Everything you > learned in debian and ubuntu before will just work. So it could be a > softer transition while you learn about snaps and your dependencies > are shipped as snaps. You will not get all the benefits of a full > snappy system, but you will get some by installing the snaps that are > ready. > > As always, it's a trade-off. If you can give a try to both approaches, > I would be really interested to hear your opinion. > > pura vida From xiaoguo.liu at canonical.com Wed Jan 4 08:17:30 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 4 Jan 2017 16:17:30 +0800 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: Hi Gareth, Please see my comments below. I am sorry that some places might not be so clear to you. You can use google-translate to translate it. Best regards, XiaoGuo On Wed, Jan 4, 2017 at 1:33 PM, Gareth France wrote: > > > On 04/01/17 04:13, XiaoGuo Liu wrote: > > Hi Gareth, > > Based on sergio's scripts at http://paste.ubuntu.com/23733207/ , I have > created a tutorial for it. Hopefully, it is useful to you. You may find it > at: > > http://blog.csdn.net/ubuntutouch/article/details/54017425 > > Best regards, > XiaoGuo > > > That is wonderful, thank you. However I have encountered several issues. > First your tutorial is in Chinese, second it is not clear how you are > naming your container (the command to create it simply refers to it as > yakkety but the responses to that command state creating and starting > flying-snake). > The name "flying-snake" is automatically chosen during the process. For your case, it could be a different name. You have to replace it with your own container name. > > When adding a user mine simply returns to the command prompt it does not > add user, > You probably need to use your own container name instead of the one "flying-snake" in my blog. You may try it again. > group, home directory, request a password etc. Adding admin privilages > same issue. Then you tell me to add something at the end of 'the file' but > you have not said which file or how I should be accessing it. > $ lxc exec flying-snake -- visudo -- it will invoke an editor for editing some stuff there. > > > I decided to stop here as I doubt very much this is working at my end. > > -- > 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 ribalkin at gmail.com Wed Jan 4 08:30:49 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Wed, 4 Jan 2017 08:30:49 +0000 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: Hi, Is it possible to get snapcraft tool under Debian? We have some debian armhf build agents and we would like to build snaps on them as well as on Ubuntu amd64 agents. Our yaml is simple and contains only few daemon definitions and a dump plugin so I thought we can even create snap archive manually as snapcraft adds a little but it would be better to keep using snapcraft. https://github.com/syncloud/platform/blob/master/snap/snapcraft.yaml Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Wed Jan 4 08:49:30 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 4 Jan 2017 10:49:30 +0200 Subject: rqlite snap packaging In-Reply-To: References: <698792798.1461355.1482594928441.ref@mail.yahoo.com> <698792798.1461355.1482594928441@mail.yahoo.com> <237329980.1598326.1482641390909@mail.yahoo.com> <8b0fd70f-5d22-5130-05cb-53c5fa393c84@ubuntu.com> <1256590590.3895822.1483050315825@mail.yahoo.com> <4439b49f-4057-a1e8-c4a6-b87ce18dd665@canonical.com> <531280955.5664499.1483412265335@mail.yahoo.com> Message-ID: Happy New Year everyone, and I wanted to bounce this message to the list because the link has super-useful instructions for those of you setting up CI-based daily-release-to-edge. I think Travis is the right starting point if you are using Travis already, and the Launchpad Builder approach has the benefit for those of you wanting to provide multi-architecture snaps. Having an automatic push and release to the edge channel is a GREAT way to build your developer community, because it lets all your core contributors and users provide rapid feedback on the evolution of the tip of your master development branch. We currently have an edge channel that is suited for development trunk branches, but we will soon have additional channels with an edge that suits stable branches too. For now I would recommend just setting up a daily / CI-smoketest based trunk release to edge. Mark On 03/01/17 20:24, Evan Dandrea wrote: > Happy New Year, Phillip. > > You might also be interested in this documentation on how to use > Travis or Launchpad to automatically build and publish snaps for each > commit on Github: > > http://snapcraft.io/docs/build-snaps/ci-integration -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Wed Jan 4 09:58:14 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 4 Jan 2017 11:58:14 +0200 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: <8a4cc2e8-45f6-585d-4c47-17f715b1b2a2@ubuntu.com> On 04/01/17 10:30, Boris Rybalkin wrote: > Is it possible to get snapcraft tool under Debian? This should be the easiest possible adaptation, in principle, because Debian and Ubuntu are so well aligned. If there are patches needed they would be simple and you can count on us to accept them. Also happy to have some ongoing CI tests on snapcraft that test its operation on Debian. Mark From mark at ubuntu.com Wed Jan 4 10:23:30 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 4 Jan 2017 12:23:30 +0200 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> Message-ID: <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> On 04/01/17 08:34, Gareth France wrote: > > /usr/bin/env: 'python': No such file or directory > > It is a python script I've packaged. Any ideas? Try changing the shell invocation line (first line of the Python script) to /usr/bin/python3 rather than /usr/bin/env Python3 is included in the core snap, so it is available at that path for all devmode/strictly confined snaps. If you need python2 then you are best off using snapcraft which I think will bundle the interpreter and dependency python libraries in your snap for you. The core snap has python3 and a base set of well-maintained stable python libraries. You can if you want duplicate those in your snap but it's probably perfectly reasonable to trust the core snap maintainers (this is essentially all the same rules as Ubuntu's base packages). Mark From james.page at ubuntu.com Wed Jan 4 11:10:06 2017 From: james.page at ubuntu.com (James Page) Date: Wed, 04 Jan 2017 11:10:06 +0000 Subject: Process privileges and owners in snaps Message-ID: Hi All Happy New Year! Over the last few months we've been working towards having a core set of snaps for OpenStack running under strict mode. For the major of the control plane components, this was fairly trivial, and the latest snapd release (introducing network namespace management) has allowed us to *almost* run the hypervisor snap in strict mode. The (hopefully) final hurdle is related to processes trying to drop privileges on startup - for example, dnsmasq by default will always drop to the nobody user/group on startup, and a few other neutron managed processes do much the same thing. This made me reflect a little on the fact that everything in a snap also runs as root by default - which despite the sandboxing of the processes using apparmor and seccomp still makes me feel a little uncomfortable. I think there are two features here that might be nice to have: 1) creation and use of unprivileged users in snaps For example, the glance snap would declare a 'glance' user/group, and the snap could then use that in the apps section for daemons to run as: users: - glance groups: - glance apps: api: command: snap-openstack glance-api daemon: simple user: glance group: glance plugs: - network - network-bind We might want to propagate that information to the command as well using SNAP_USER SNAP_GROUP (or suchlike). 2) interface support for allowing processes to switch uid/gid I see support in some existing specific interfaces for setgroups/setgid/setuid etc.. but maybe that's something we could encapsulate in a standalone generalised interface as well. Most of that is related with dropping privs for processes - most bits of OpenStack assume the use of sudo for escalation of privs, which for now I've worked through by providing a fake 'sudo' shim as the calling process is already running as root (relying instead on the process sandboxing to control whats permitted), but that sniffs like another interface requirement to support use of sudo within the constraints of snap confinement rather than re-writing the world to work with snaps. Thoughts? James -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Wed Jan 4 11:40:13 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Wed, 04 Jan 2017 11:40:13 +0000 Subject: Issues generating snap In-Reply-To: <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> Message-ID: <1b91d316022f75aa9f0ea5d56a375bcc@cliftonts.co.uk> On 2017-01-04 10:23, Mark Shuttleworth wrote: > On 04/01/17 08:34, Gareth France wrote: > > /usr/bin/env: 'python': No such file or directory > > It is a python script I've packaged. Any ideas? > > Try changing the shell invocation line (first line of the Python > script) > to /usr/bin/python3 rather than /usr/bin/env > > Python3 is included in the core snap, so it is available at that path > for all devmode/strictly confined snaps. > > If you need python2 then you are best off using snapcraft which I think > will bundle the interpreter and dependency python libraries in your > snap > for you. > > The core snap has python3 and a base set of well-maintained stable > python libraries. You can if you want duplicate those in your snap but > it's probably perfectly reasonable to trust the core snap maintainers > (this is essentially all the same rules as Ubuntu's base packages). > > Mark Mark, Thank you, that makes perfect sense. I'd also like to say a quick thanks for revolutionising my life. Discovered Feisty 10 years back and haven't looked back since! From olivier.tilloy at canonical.com Wed Jan 4 12:39:49 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Wed, 4 Jan 2017 13:39:49 +0100 Subject: snapd and semaphores In-Reply-To: <1483471265.3074.6.camel@canonical.com> References: <1483471265.3074.6.camel@canonical.com> Message-ID: On Tue, Jan 3, 2017 at 8:21 PM, Jamie Strandboge wrote: > On Mon, 2017-01-02 at 16:34 +0100, Olivier Tilloy wrote: >> Hi everyone, and happy new year! >> >> I’m snapping an app that makes use of semaphores¹ and seeing an >> apparmor denial. The glibc implementation of sem_open calls >> SHM_GET_NAME(EINVAL,SEM_FAILED,SEM_SHM_PREFIX) where SEM_SHM_PREFIX is >> "sem.", so it tries to create /dev/shm/sem.{name}, which fails because >> snapd only allows /dev/shm/snap.@{SNAP_NAME}.**. >> At a quick glance, there’s no mechanism (e.g. env var) to customize >> the prefix ("sem."). >> Is this an issue others have run into? Is there a recommended solution? >> >> Thanks in advance! >> > > Reading sem_overview, it seems that we should also allow: > '/dev/shm/sem.snap.@{SNAP_NAME}.*'. In this manner, we namespace /dev/shm/sem.* > by snap name just like we do other parts of the OS. Please file a bug and we'll > get this fixed. This will require patching upstream apps, and is not likely to be easily merged by upstream projects, so not ideal, but I understand the need for namespacing /dev/shm/sem.* for true security. Here is the bug report: https://launchpad.net/bugs/1653955 Cheers, Olivier From mark at ubuntu.com Wed Jan 4 12:53:21 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 4 Jan 2017 14:53:21 +0200 Subject: Issues generating snap In-Reply-To: <1b91d316022f75aa9f0ea5d56a375bcc@cliftonts.co.uk> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> <1b91d316022f75aa9f0ea5d56a375bcc@cliftonts.co.uk> Message-ID: <93609d70-a974-a1cd-383c-aa4ea808e80b@ubuntu.com> On 04/01/17 13:40, gareth.france at cliftonts.co.uk wrote: > Thank you, that makes perfect sense. I'd also like to say a quick > thanks for revolutionising my life. Discovered Feisty 10 years back > and haven't looked back since! You're welcome, it takes a big community to make Ubuntu happen. I hope that you find snaps have just as big an impact :) It would be wonderful if we can really improve the flow of bits from upstreams to users, or even just make it easier for people to manage private apps that they are pushing around on their networks. Mark From simon.fels at canonical.com Wed Jan 4 13:51:07 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 4 Jan 2017 14:51:07 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 Message-ID: Hey everyone, A new release of the wifi-ap and pulseaudio snaps were pushed into the candidate channel. This release includes several improvements for both snaps. wifi-ap: * Switched to a unix domain socket instead of a local TCP endpoint to provide secure access to the management service REST API endpoint via a content interface based slot. * The management service now controls the access point process directly instead of both being two independent systemd service units. This makes coordination and application of configuration changes a lot easier. * New wifi-ap.status command is now available which shows the current status of the AP. * Improve configuration wizard which now has an auto mode as well which is executed directly after the installation of the snap to provide an out-of-the-box experience and directly spawn up an access point users can connect to. Wizard can be manually invoked too and guides the user through the configuration of the access point. * Added extensive testing of the whole snap via spread pulseaudio: This is the first release of the snap. We currently only support running pulseaudio in system mode and with that only support Ubuntu Core devices. Installing on classic desktop devices is possible but not yet supported. Please note that we require a kernel with ALSA support enabled which is not yet the case for all reference devices like the Raspberry Pi 2 or 3. --- An overview of which revisions / versions of the particular snaps are available in which channel is available at https://docs.google.com/ spreadsheets/d/1q2dmjPQ0Bam3p3frmmrX2WI3d1r8iusE0JTc0wm2jKM/edit#gid=0 The snaps have passed our engineering QA and will now be tested by the platform and commercial QA teams before the new versions are pushed to the stable channel. Bileto requests are: - wifi-ap: https://bileto.ubuntu.com/#/ticket/2333 - pulseaudio: https://bileto.ubuntu.com/#/ticket/2327 If you have any questions feel free to ping me. regards, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Wed Jan 4 13:57:05 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Wed, 04 Jan 2017 13:57:05 +0000 Subject: Issues generating snap In-Reply-To: <93609d70-a974-a1cd-383c-aa4ea808e80b@ubuntu.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> <1b91d316022f75aa9f0ea5d56a375bcc@cliftonts.co.uk> <93609d70-a974-a1cd-383c-aa4ea808e80b@ubuntu.com> Message-ID: > You're welcome, it takes a big community to make Ubuntu happen. I hope > that you find snaps have just as big an impact :) It would be wonderful > if we can really improve the flow of bits from upstreams to users, or > even just make it easier for people to manage private apps that they > are > pushing around on their networks. > > Mark Actually I developed a niche application for use on desktop, a product only really available on Windows. I packaged it over and over for deb but it seems impossible to do. I then paid for someone to package it and a year on I'm still waiting for the approval process in the developer portal to finish, but there doesn't seem to be anyone to approach about this. So I have been trying to package in deb format for at least 2 years. I built a snap in a night. Ok it didn't work but you have now told me why. I get the feeling I'm going to get along with your vision just fine. Expect to see a desktop remote control for roku and now TV boxes and PAT testing software appearing in the software store soon. From bret.barker at canonical.com Wed Jan 4 14:02:07 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Wed, 4 Jan 2017 09:02:07 -0500 Subject: store errors In-Reply-To: References: Message-ID: <20170104140206.GC1742@abitrandom.net> That's hitting the service to fetch assertions, nothing to do with the CDN. What version of snapd are you on? 2.20 includes more robust network error handling and retries. -bret On Tue, Jan 03, 2017 at 09:23:14PM -0800, Manik Taneja wrote: > hi there, > > i am continuing to see the store timeout errors. they are happening way too > frequently to require a deeper review. if they are indeed related to our > CDN provider, can we re-visit the need for a different provider? > > [image: Inline image 1] > > cheers, > manik From xiaoguo.liu at canonical.com Wed Jan 4 14:07:00 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Wed, 4 Jan 2017 22:07:00 +0800 Subject: Issues generating snap In-Reply-To: References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> <1b91d316022f75aa9f0ea5d56a375bcc@cliftonts.co.uk> <93609d70-a974-a1cd-383c-aa4ea808e80b@ubuntu.com> Message-ID: Hi Gareth, I would recommend looking at the example project at https://github.com/snapcore/snapcraft/tree/master/demos/py3-project. It is a working example for your reference. Best regards, XiaoGuo On Wed, Jan 4, 2017 at 9:57 PM, wrote: > > You're welcome, it takes a big community to make Ubuntu happen. I hope >> that you find snaps have just as big an impact :) It would be wonderful >> if we can really improve the flow of bits from upstreams to users, or >> even just make it easier for people to manage private apps that they are >> pushing around on their networks. >> >> Mark >> > > Actually I developed a niche application for use on desktop, a product > only really available on Windows. I packaged it over and over for deb but > it seems impossible to do. I then paid for someone to package it and a year > on I'm still waiting for the approval process in the developer portal to > finish, but there doesn't seem to be anyone to approach about this. > > So I have been trying to package in deb format for at least 2 years. I > built a snap in a night. Ok it didn't work but you have now told me why. I > get the feeling I'm going to get along with your vision just fine. Expect > to see a desktop remote control for roku and now TV boxes and PAT testing > software appearing in the software store soon. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Wed Jan 4 14:16:20 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Wed, 4 Jan 2017 14:16:20 +0000 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: On Wed, Jan 4, 2017 at 1:51 PM, Simon Fels wrote: > Hey everyone, > > A new release of the wifi-ap and pulseaudio snaps were pushed into the > candidate channel. This release includes several improvements for both > snaps. > > wifi-ap: > > * Switched to a unix domain socket instead of a local TCP endpoint to > provide secure access to the management service REST API endpoint via a > content interface based slot. > > * The management service now controls the access point process directly > instead of both being two independent systemd service units. This makes > coordination and application of configuration changes a lot easier. > > * New wifi-ap.status command is now available which shows the current status > of the AP. > > * Improve configuration wizard which now has an auto mode as well which is > executed directly after the installation of the snap to provide an > out-of-the-box experience and directly spawn up an access point users can > connect to. Wizard can be manually invoked too and guides the user through > the configuration of the access point. > > * Added extensive testing of the whole snap via spread This is great for initial configuration of a device and is what we are looking to use for SnapWeb, thanks. > pulseaudio: > > This is the first release of the snap. We currently only support running > pulseaudio in system mode and with that only support Ubuntu Core devices. > Installing on classic desktop devices is possible but not yet supported. > > Please note that we require a kernel with ALSA support enabled which is not > yet the case for all reference devices like the Raspberry Pi 2 or 3. Is there a reason why we do not have ALSA support enabled for these platforms? > > --- > > An overview of which revisions / versions of the particular snaps are > available in which channel is available at > https://docs.google.com/spreadsheets/d/1q2dmjPQ0Bam3p3frmmrX2WI3d1r8iusE0JTc0wm2jKM/edit#gid=0 > > The snaps have passed our engineering QA and will now be tested by the > platform and commercial QA teams before the new versions are pushed to the > stable channel. > > Bileto requests are: > - wifi-ap: https://bileto.ubuntu.com/#/ticket/2333 > - pulseaudio: https://bileto.ubuntu.com/#/ticket/2327 > > If you have any questions feel free to ping me. > > regards, > Simon > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From simon.fels at canonical.com Wed Jan 4 14:34:33 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 4 Jan 2017 15:34:33 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: <4e312f93-9132-18b9-647a-e3fdeeb613a7@canonical.com> On 04.01.2017 15:16, Jamie Bennett wrote: > On Wed, Jan 4, 2017 at 1:51 PM, Simon Fels wrote: >> Hey everyone, >> >> A new release of the wifi-ap and pulseaudio snaps were pushed into the >> candidate channel. This release includes several improvements for both >> snaps. >> >> wifi-ap: >> >> * Switched to a unix domain socket instead of a local TCP endpoint to >> provide secure access to the management service REST API endpoint via a >> content interface based slot. >> >> * The management service now controls the access point process directly >> instead of both being two independent systemd service units. This makes >> coordination and application of configuration changes a lot easier. >> >> * New wifi-ap.status command is now available which shows the current status >> of the AP. >> >> * Improve configuration wizard which now has an auto mode as well which is >> executed directly after the installation of the snap to provide an >> out-of-the-box experience and directly spawn up an access point users can >> connect to. Wizard can be manually invoked too and guides the user through >> the configuration of the access point. >> >> * Added extensive testing of the whole snap via spread > > This is great for initial configuration of a device and is what we are > looking to use for SnapWeb, thanks. > >> pulseaudio: >> >> This is the first release of the snap. We currently only support running >> pulseaudio in system mode and with that only support Ubuntu Core devices. >> Installing on classic desktop devices is possible but not yet supported. >> >> Please note that we require a kernel with ALSA support enabled which is not >> yet the case for all reference devices like the Raspberry Pi 2 or 3. > > Is there a reason why we do not have ALSA support enabled for these platforms? I don't know but it simply looks like we're missing a few kernel modules to get it properly working. Still have the item on my list to file a bug for this. regards, Simon From ogra at ubuntu.com Wed Jan 4 14:39:16 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 04 Jan 2017 15:39:16 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: <1483540756.17893.4.camel@ubuntu.com> hi, On Mi, 2017-01-04 at 14:16 +0000, Jamie Bennett wrote: >  > > pulseaudio: > > > > This is the first release of the snap. We currently only support > > running > > pulseaudio in system mode and with that only support Ubuntu Core > > devices. > > Installing on classic desktop devices is possible but not yet > > supported. > > > > Please note that we require a kernel with ALSA support enabled > > which is not > > yet the case for all reference devices like the Raspberry Pi 2 or > > 3. > > Is there a reason why we do not have ALSA support enabled for these > platforms? > well, we surely do have the right modules enabled ... snd-bcm2835.ko is definitely there in the rpi kernel package ...  but snd.ko seems to be compiled in ... i assume this combo wont work, my guess would be that either both have to be compiled in or both have to be modules ... (i'll look into this and talk to paolo about it) 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 Wed Jan 4 14:42:40 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 04 Jan 2017 15:42:40 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <4e312f93-9132-18b9-647a-e3fdeeb613a7@canonical.com> References: <4e312f93-9132-18b9-647a-e3fdeeb613a7@canonical.com> Message-ID: <1483540960.17893.6.camel@ubuntu.com> hi, On Mi, 2017-01-04 at 15:34 +0100, Simon Fels wrote: >  > > > > Is there a reason why we do not have ALSA support enabled for these > > platforms? > > I don't know but it simply looks like we're missing a few kernel > modules > to get it properly working. Still have the item on my list to file a > bug > for this. strike it off your list then ... i just filed http://pad.lv/1653988 ;) 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 simon.fels at canonical.com Wed Jan 4 14:43:20 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 4 Jan 2017 15:43:20 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483540756.17893.4.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> Message-ID: <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> On 04.01.2017 15:39, Oliver Grawert wrote: > hi, > On Mi, 2017-01-04 at 14:16 +0000, Jamie Bennett wrote: >> >>> pulseaudio: >>> >>> This is the first release of the snap. We currently only support >>> running >>> pulseaudio in system mode and with that only support Ubuntu Core >>> devices. >>> Installing on classic desktop devices is possible but not yet >>> supported. >>> >>> Please note that we require a kernel with ALSA support enabled >>> which is not >>> yet the case for all reference devices like the Raspberry Pi 2 or >>> 3. >> >> Is there a reason why we do not have ALSA support enabled for these >> platforms? >> > > well, we surely do have the right modules enabled ... > snd-bcm2835.ko is definitely there in the rpi kernel package ... > > but snd.ko seems to be compiled in ... i assume this combo wont work, > my guess would be that either both have to be compiled in or both have > to be modules ... > > (i'll look into this and talk to paolo about it) Thanks. When I looked at it the hardware specific module snd-bcm2835.ko wasn't automatically loaded and loading it didn't change much (nothing listed in /proc/asound/cards). regards, Simon From jamie at canonical.com Wed Jan 4 15:12:11 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 04 Jan 2017 09:12:11 -0600 Subject: Process privileges and owners in snaps In-Reply-To: References: Message-ID: <1483542731.3074.44.camel@canonical.com> On Wed, 2017-01-04 at 11:10 +0000, James Page wrote: > Hi All > > Happy New Year! > Happy New Year! :) > Over the last few months we've been working towards having a core set of > snaps for OpenStack running under strict mode. > > For the major of the control plane components, this was fairly trivial, and > the latest snapd release (introducing network namespace management) has > allowed us to *almost* run the hypervisor snap in strict mode. > > The (hopefully) final hurdle is related to processes trying to drop > privileges on startup - for example, dnsmasq by default will always drop to > the nobody user/group on startup, and a few other neutron managed processes > do much the same thing. > > This made me reflect a little on the fact that everything in a snap also > runs as root by default - which despite the sandboxing of the processes > using apparmor and seccomp still makes me feel a little uncomfortable. > > I think there are two features here that might be nice to have: > > 1) creation and use of unprivileged users in snaps > > For example, the glance snap would declare a 'glance' user/group, and the > snap could then use that in the apps section for daemons to run as: > > users: >    - glance > > groups: >    - glance > > apps: >   api: >     command: snap-openstack glance-api >     daemon: simple >     user: glance >     group: glance >     plugs: >       - network >       - network-bind > > We might want to propagate that information to the command as well using > SNAP_USER SNAP_GROUP (or suchlike). > FYI, this is: https://bugs.launchpad.net/snappy/+bug/1617314 https://bugs.launchpad.net/snappy/+bug/1606510 > 2) interface support for allowing processes to switch uid/gid > > I see support in some existing specific interfaces for > setgroups/setgid/setuid etc.. but maybe that's something we could > encapsulate in a standalone generalised interface as well. > It could be in a separate interface, but IMHO if we do something like what you describe in point '1' (ie, enumerate the users and groups and say what is going to use each group) then we don't need a separate interface. On install snapd creates these users and groups and then snap-confine can allow setuid(). snap-confine should also be modified to add an implicit rule to setuid/setgid/etc back to the uid/gid to allow regaining permissions after temporarily dropping them. I think the implementation should probably be a new interface backend for managing extrausers. Upon install, this backend looks at the snap yaml and generates the declared users and groups in /var/lib/extrausers. The seccomp default template is then updated to look at the snap yaml and if there are declared users and groups, it adds the arg filtered setuid/setgid/etc rules for these users and groups by default.  If you are planning on implementing this, please get the snap yaml changes approved and then discuss the implementation with the snappy interfaces virtual team (ie, Gustavo, Zygmunt and me). There are open questions as to namespacing these users and groups that need to be discussed with an architect (eg, Gustavo)-- eg, we need to handle system user/group collisions gracefully and securely and avoid snap user/group collisions in a way that doesn't require snap declaration changes for everyone using this mechanism (ie, perhaps allow 'user: SNAP_NAME' and 'user: SNAP_NAME.*' always but (perhaps?) allow use of 'user: NOT_SNAP_NAME' with a corresponding snap declaration). > Most of that is related with dropping privs for processes - most bits of > OpenStack assume the use of sudo for escalation of privs, which for now > I've worked through by providing a fake 'sudo' shim as the calling process > is already running as root (relying instead on the process sandboxing to > control whats permitted), but that sniffs like another interface > requirement to support use of sudo within the constraints of snap > confinement rather than re-writing the world to work with snaps. > This is https://bugs.launchpad.net/snappy/+bug/1607763. Technically, this is probably a 'sudo' interface for declaring the policy and a 'sudo' interface backend that creates sudoers policy in /etc/sudoers.d/snap.SNAP_NAME based on sudo interface declaration in the the snap yaml. This would of course be a very sensitive interface with base declaration constraints and would need architect, interface virtual team and security team input on the design and implementation. -- 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 leo.arias at canonical.com Wed Jan 4 15:37:34 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 4 Jan 2017 09:37:34 -0600 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: Hello! On Wed, Jan 4, 2017 at 2:30 AM, Boris Rybalkin wrote: > Is it possible to get snapcraft tool under Debian? That's doable, but would considerably increase our maintenance tasks. Please report it as a bug: https://bugs.launchpad.net/snapcraft/+filebug That way we can keep track of how many people are interested, to help us assign a priority to it. In the near future we want to have snapcraft as a snap. Then it will work in all the distros that support snaps, including debian. That might solve your problem. pura vida. From jim.hodapp at canonical.com Wed Jan 4 15:49:30 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Wed, 4 Jan 2017 10:49:30 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483540960.17893.6.camel@ubuntu.com> References: <4e312f93-9132-18b9-647a-e3fdeeb613a7@canonical.com> <1483540960.17893.6.camel@ubuntu.com> Message-ID: Thanks ogra, you rock man. On Wed, Jan 4, 2017 at 9:42 AM, Oliver Grawert wrote: > hi, > On Mi, 2017-01-04 at 15:34 +0100, Simon Fels wrote: > > > > > > > > Is there a reason why we do not have ALSA support enabled for these > > > platforms? > > > > I don't know but it simply looks like we're missing a few kernel > > modules > > to get it properly working. Still have the item on my list to file a > > bug > > for this. > > strike it off your list then ... i just filed http://pad.lv/1653988 > > ;) > > 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 leo.arias at canonical.com Wed Jan 4 16:23:19 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 4 Jan 2017 10:23:19 -0600 Subject: man: command not found In-Reply-To: <1319190040.126976.1481869494725@mail.yahoo.com> References: <1319190040.126976.1481869494725.ref@mail.yahoo.com> <1319190040.126976.1481869494725@mail.yahoo.com> Message-ID: Hello Luther, The man pages for snapcraft is an item in our backlog. I couldn't find a bug reported for it, so it would be great if you could report one: https://bugs.launchpad.net/snapcraft/+filebug thank you From sergio.schvezov at canonical.com Wed Jan 4 16:41:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 4 Jan 2017 13:41:00 -0300 Subject: man: command not found In-Reply-To: <1319190040.126976.1481869494725@mail.yahoo.com> References: <1319190040.126976.1481869494725.ref@mail.yahoo.com> <1319190040.126976.1481869494725@mail.yahoo.com> Message-ID: El 16/12/16 a las 03:24, Luther Goh Lu Feng escribió: > I was surprised that man wasn't present. Is this intended, and if so, what is the rationale. Thanks. Not present where? If you refer to Ubuntu Core, then that is correct, it is core after all and every bit/byte counts. This is one of the reasons we have a classic snap that enables all these familiar things. From a.rogovsky at gmail.com Wed Jan 4 16:57:08 2017 From: a.rogovsky at gmail.com (Andrey Rogovsky) Date: Wed, 4 Jan 2017 18:57:08 +0200 Subject: How to set arch for stage-packages? Message-ID: Hi! I need add few i386 packages to support my 32bit binary for amd64 systems: ... parts: packages: plugin: nil stage-packages: - libstdc++6:i386 ... But when I try pull - I get error: # snapcraft pull Skipping pull bluequest (already ran) Preparing to pull packages Hit http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial InRelease Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 kB] Hit http://ua.archive.ubuntu.com/ubuntu xenial InRelease Hit http://ua.archive.ubuntu.com/ubuntu xenial-updates InRelease Hit http://ua.archive.ubuntu.com/ubuntu xenial-backports InRelease Fetched 102 kB in 0s (0 B/s) Error downloading stage packages for part 'packages': no such package 'libstdc++6:i386' Please advice. P.S. I dont need build i386 package. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.melamut at canonical.com Wed Jan 4 16:41:15 2017 From: jon.melamut at canonical.com (Jon Melamut) Date: Wed, 4 Jan 2017 11:41:15 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: On Wednesday, January 4, 2017, Simon Fels wrote: > Hey everyone, > > A new release of the wifi-ap and pulseaudio snaps were pushed into the > candidate channel. This release includes several improvements for both > snaps. > > wifi-ap: > > * Switched to a unix domain socket instead of a local TCP endpoint to > provide secure access to the management service REST API endpoint via a > content interface based slot. > > * The management service now controls the access point process directly > instead of both being two independent systemd service units. This makes > coordination and application of configuration changes a lot easier. > > * New wifi-ap.status command is now available which shows the current > status of the AP. > > * Improve configuration wizard which now has an auto mode as well which is > executed directly after the installation of the snap to provide an > out-of-the-box experience and directly spawn up an access point users can > connect to. Wizard can be manually invoked too and guides the user through > the configuration of the access point. > Does the snap contain a wizard itself or is this support for a wizard to be written by another party to drive the setup & configuration process? > -- ​ Jon Melamut | VP, Devices, IoT Sales & Alliances | Canonical | +1.978.430.8359 | Skype: jonmelamut -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.melamut at canonical.com Wed Jan 4 16:10:35 2017 From: jon.melamut at canonical.com (Jon Melamut) Date: Wed, 4 Jan 2017 11:10:35 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: On Wednesday, January 4, 2017, Simon Fels wrote: > Hey everyone, > > A new release of the wifi-ap and pulseaudio snaps were pushed into the > candidate channel. This release includes several improvements for both > snaps. > > wifi-ap: > > * Switched to a unix domain socket instead of a local TCP endpoint to > provide secure access to the management service REST API endpoint via a > content interface based slot. > > * The management service now controls the access point process directly > instead of both being two independent systemd service units. This makes > coordination and application of configuration changes a lot easier. > > * New wifi-ap.status command is now available which shows the current > status of the AP. > > * Improve configuration wizard which now has an auto mode as well which is > executed directly after the installation of the snap to provide an > out-of-the-box experience and directly spawn up an access point users can > connect to. Wizard can be manually invoked too and guides the user through > the configuration of the access point. > Does the snap contain a wizard itself or is this support for a wizard to be written by another party to drive the setup & configuration process? > -- ​ Jon Melamut | VP, Devices, IoT Sales & Alliances | Canonical | +1.978.430.8359 | Skype: jonmelamut -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.hodapp at canonical.com Wed Jan 4 17:11:15 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Wed, 4 Jan 2017 12:11:15 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: On Wed, Jan 4, 2017 at 11:41 AM, Jon Melamut wrote: > > > On Wednesday, January 4, 2017, Simon Fels > wrote: > >> Hey everyone, >> >> A new release of the wifi-ap and pulseaudio snaps were pushed into the >> candidate channel. This release includes several improvements for both >> snaps. >> >> wifi-ap: >> >> * Switched to a unix domain socket instead of a local TCP endpoint to >> provide secure access to the management service REST API endpoint via a >> content interface based slot. >> >> * The management service now controls the access point process directly >> instead of both being two independent systemd service units. This makes >> coordination and application of configuration changes a lot easier. >> >> * New wifi-ap.status command is now available which shows the current >> status of the AP. >> >> * Improve configuration wizard which now has an auto mode as well which >> is executed directly after the installation of the snap to provide an >> out-of-the-box experience and directly spawn up an access point users can >> connect to. Wizard can be manually invoked too and guides the user through >> the configuration of the access point. >> > Does the snap contain a wizard itself or is this support for a wizard to > be written by another party to drive the setup & configuration process? > The snap contains a wizard itself that will guide the user through the basic initial setup. Simon, any additional details to add here? > > > -- > ​ > > Jon Melamut | VP, Devices, IoT Sales & Alliances | Canonical | +1. > 978.430.8359 <(978)%20430-8359> | Skype: jonmelamut > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Wed Jan 4 17:18:38 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 4 Jan 2017 18:18:38 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: <772b9b8c-ecff-faf3-8521-98139b01123f@canonical.com> On 04.01.2017 17:10, Jon Melamut wrote: > > > On Wednesday, January 4, 2017, Simon Fels > wrote: > > Hey everyone, > > A new release of the wifi-ap and pulseaudio snaps were pushed into > the candidate channel. This release includes several improvements > for both snaps. > > wifi-ap: > > * Switched to a unix domain socket instead of a local TCP endpoint > to provide secure access to the management service REST API endpoint > via a content interface based slot. > > * The management service now controls the access point process > directly instead of both being two independent systemd service > units. This makes coordination and application of configuration > changes a lot easier. > > * New wifi-ap.status command is now available which shows the > current status of the AP. > > * Improve configuration wizard which now has an auto mode as well > which is executed directly after the installation of the snap to > provide an out-of-the-box experience and directly spawn up an access > point users can connect to. Wizard can be manually invoked too and > guides the user through the configuration of the access point. > > Does the snap contain a wizard itself or is this support for a wizard to > be written by another party to drive the setup & configuration process? The snap provides a command line based wizard which can be run in either manual or auto mode. The manual mode will ask the user a few questions to set everything up and the auto mode will examine the system to take the right decision on which interfaces, IP configuration to use automatically. In the end the wizard uses the same REST API as every other client can use as well. So a 3rd party snap can create its own wizard implementation too. In the future (once snapcraft has support for hooks) we will add configuration to the snap itself as well to provide the ability for users to customize the configuration of the AP from the gadget snap (custom SSID, ...) Hope that helps. regards, Simon From daniel at bowlhat.net Wed Jan 4 17:40:44 2017 From: daniel at bowlhat.net (Daniel Llewellyn) Date: Wed, 04 Jan 2017 17:40:44 +0000 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: On Wed, 4 Jan 2017 at 15:38 Leo Arias wrote: > In the near future we want to have snapcraft as a snap. Then it will > work in all the distros that support snaps, including debian. That > might solve your problem. > I do so love to see these inception-dream-like combinations of using a technology to run something that makes stuff to run on the technology. like C compilers which self-host themselves and using docker to run docker and running docker in docker in snap and all sorts of fancy shenanigans. More on topic: it will be a great day when everything is available as transactionally upgradable snaps. and we can rely on everything "just working" -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Wed Jan 4 17:41:04 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 4 Jan 2017 14:41:04 -0300 Subject: How to set arch for stage-packages? In-Reply-To: References: Message-ID: El 04/01/17 a las 13:57, Andrey Rogovsky escribió: > Hi! > I need add few i386 packages to support my 32bit binary for amd64 systems: > ... > parts: > packages: > plugin: nil > stage-packages: > - libstdc++6:i386 > ... > But when I try pull - I get error: > # snapcraft pull > Skipping pull bluequest (already ran) > Preparing to pull packages > Hit http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial InRelease > Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 > kB] > Hit http://ua.archive.ubuntu.com/ubuntu xenial InRelease > Hit http://ua.archive.ubuntu.com/ubuntu xenial-updates InRelease > Hit http://ua.archive.ubuntu.com/ubuntu xenial-backports InRelease > Fetched 102 kB in 0s (0 B/s) > Error downloading stage packages for part 'packages': no such package > 'libstdc++6:i386' > > Please advice. > > P.S. I dont need build i386 package. I think we are lacking a split in our python apt code to support this, a matter of a .split(':') and passing the arch to our cache instance, mind logging a bug? From ngompa13 at gmail.com Wed Jan 4 17:46:11 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Wed, 4 Jan 2017 12:46:11 -0500 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: On Wed, Jan 4, 2017 at 10:37 AM, Leo Arias wrote: > Hello! > > On Wed, Jan 4, 2017 at 2:30 AM, Boris Rybalkin wrote: >> Is it possible to get snapcraft tool under Debian? > > That's doable, but would considerably increase our maintenance tasks. > Please report it as a bug: > https://bugs.launchpad.net/snapcraft/+filebug > > That way we can keep track of how many people are interested, to help > us assign a priority to it. > This is already covered by this bug: https://bugs.launchpad.net/snapcraft/+bug/1602258 Some reworking of how stage-packages and build-packages is required to handle this correctly. -- 真実はいつも一つ！/ Always, there's only one truth! From ribalkin at gmail.com Wed Jan 4 18:01:19 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Wed, 4 Jan 2017 18:01:19 +0000 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: Thanks for the replies. Would it be easier for now just to create a squashfs out of a prepared directory manually? >From what I see I do not need commands created by snapcraft out of daemon definitions. The rest looks like it is copied as is and snapcraft.yaml just got arch field added into snap.yaml. As you can see we are not really using any snapcraft feature except archiving. On 4 Jan 2017 17:47, "Neal Gompa" wrote: > On Wed, Jan 4, 2017 at 10:37 AM, Leo Arias > wrote: > > Hello! > > > > On Wed, Jan 4, 2017 at 2:30 AM, Boris Rybalkin > wrote: > >> Is it possible to get snapcraft tool under Debian? > > > > That's doable, but would considerably increase our maintenance tasks. > > Please report it as a bug: > > https://bugs.launchpad.net/snapcraft/+filebug > > > > That way we can keep track of how many people are interested, to help > > us assign a priority to it. > > > > This is already covered by this bug: > https://bugs.launchpad.net/snapcraft/+bug/1602258 > > Some reworking of how stage-packages and build-packages is required to > handle this correctly. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Wed Jan 4 18:06:50 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 4 Jan 2017 12:06:50 -0600 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: Yes, that should work. From ogra at ubuntu.com Wed Jan 4 18:11:57 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 04 Jan 2017 19:11:57 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> Message-ID: <1483553517.17893.11.camel@ubuntu.com> hi, On Mi, 2017-01-04 at 15:43 +0100, Simon Fels wrote: >  > > When I looked at it the hardware specific module snd-bcm2835.ko > wasn't > automatically loaded and loading it didn't change much (nothing > listed > in /proc/asound/cards). >  ok, i found the solution ... the complete audio stack is disabled in the device tree until you force-enable it via the config.txt file: ogra at pi3:~$ grep audio= /boot/uboot/config.txt  dtparam=audio=on ogra at pi3:~$ cat /proc/asound/cards  0 [ALSA           ]: bcm2835 - bcm2835 ALSA                       bcm2835 ALSA it also automatically loads the snd-bcm2835 now ... i'll make sure thats set as default with the next gadget upload ... 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 manik at canonical.com Wed Jan 4 18:15:45 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 4 Jan 2017 10:15:45 -0800 Subject: store errors In-Reply-To: <20170104140206.GC1742@abitrandom.net> References: <20170104140206.GC1742@abitrandom.net> Message-ID: On Wed, Jan 4, 2017 at 6:02 AM, Bret A. Barker wrote: > That's hitting the service to fetch assertions, nothing to do with the CDN. > > What version of snapd are you on? 2.20 includes more robust network error > handling and retries. > Thanks Bret. I was on 2.18 and just refreshed to 2.20. Will keep an eye out for this one. /Manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Wed Jan 4 18:29:44 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 4 Jan 2017 10:29:44 -0800 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: On 01/04/2017 10:01 AM, Boris Rybalkin wrote: > Thanks for the replies. > > Would it be easier for now just to create a squashfs out of a prepared > directory manually? > > From what I see I do not need commands created by snapcraft out of > daemon definitions. The rest looks like it is copied as is and > snapcraft.yaml just got arch field added into snap.yaml. > > As you can see we are not really using any snapcraft feature except > archiving. Yes that should work, just make sure you're using the correct mksquashfs parameters: mksquashfs -noappend -comp xz -no-xattrs -all-root -- 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 ribalkin at gmail.com Wed Jan 4 18:32:27 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Wed, 4 Jan 2017 18:32:27 +0000 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: Great, that is what I was looking for! Thanks. On 4 Jan 2017 18:30, "Kyle Fazzari" wrote: > On 01/04/2017 10:01 AM, Boris Rybalkin wrote: > > Thanks for the replies. > > > > Would it be easier for now just to create a squashfs out of a prepared > > directory manually? > > > > From what I see I do not need commands created by snapcraft out of > > daemon definitions. The rest looks like it is copied as is and > > snapcraft.yaml just got arch field added into snap.yaml. > > > > As you can see we are not really using any snapcraft feature except > > archiving. > > Yes that should work, just make sure you're using the correct mksquashfs > parameters: > > mksquashfs -noappend -comp xz -no-xattrs -all-root > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.hodapp at canonical.com Wed Jan 4 18:33:17 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Wed, 4 Jan 2017 13:33:17 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483553517.17893.11.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> Message-ID: On Wed, Jan 4, 2017 at 1:11 PM, Oliver Grawert wrote: > hi, > On Mi, 2017-01-04 at 15:43 +0100, Simon Fels wrote: > > > > > > When I looked at it the hardware specific module snd-bcm2835.ko > > wasn't > > automatically loaded and loading it didn't change much (nothing > > listed > > in /proc/asound/cards). > > > > ok, i found the solution ... the complete audio stack is disabled in > the device tree until you force-enable it via the config.txt file: > Again, you rock ogra. :) A beer for you at the next sprint! > > ogra at pi3:~$ grep audio= /boot/uboot/config.txt > dtparam=audio=on > > ogra at pi3:~$ cat /proc/asound/cards > 0 [ALSA ]: bcm2835 - bcm2835 ALSA > bcm2835 ALSA > > it also automatically loads the snd-bcm2835 now ... > > i'll make sure thats set as default with the next gadget upload ... > > 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 kyle.nitzsche at canonical.com Wed Jan 4 18:44:31 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Wed, 4 Jan 2017 13:44:31 -0500 Subject: scratch-qt project Message-ID: <767b4c25-c09f-aadc-7359-99022c046af5@canonical.com> Over the holidays, I scratched an itch to write a Qt/QML/C++ threaded app snapped with ubuntu-app-platform. Goals: * C++ backend using controller/worker thread approach so QML GUI is non-blocking when user taps buttons and backend methods run * Concurrent execution of backends * Easy to use custom QML item/C++ plugin supporting the above. So it's my approximation of a responsive and extensible dashboard style QML/C++ demo app based on ubuntu-app-platform libs. Explained here: http://kylenubuntu.blogspot.com/2017/01/scratch-qt-snap-with-ubuntu-app-platform.html Cheers, KyleN From dank at kegel.com Wed Jan 4 19:56:34 2017 From: dank at kegel.com (Dan Kegel) Date: Wed, 4 Jan 2017 11:56:34 -0800 Subject: /snap/bin not on PATH for noninteractive ssh? Message-ID: Does /etc/profile.d/apps-bin-path.sh not fire on noninteractive logins? Evidently not: $ ssh pi3 'echo $PATH' /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games Workaround #1: make it fire, dammit: --- .bashrc.orig 2017-01-04 19:55:33.105726685 +0000 +++ .bashrc 2017-01-04 19:54:11.505653043 +0000 @@ -5,7 +5,9 @@ # If not running interactively, don't do anything case $- in *i*) ;; - *) return;; + *) # Work around rsync snap PATH problem + . /etc/profile.d/apps-bin-path.sh + return;; esac # don't put duplicate lines or lines starting with space in the history. Workaround #2: invoke rsync with --rsync-path. Ugly. Long story: rsync doesn't seem to be provided in ubuntu core 16. (It's in classic, of course, but my world wants to be able to rsync to a host, and I have not yet tried arranging to start a classic environment automatically on boot and running an sshd.) Creating a snap for rsync appears to be a piece of cake (yay!): name: rsync version: '3.1.1' summary: fast, versatile, remote (and local) file-copying tool description: | rsync is a fast and versatile file-copying tool which can copy locally and to/from a remote host. It offers many options to control its behavior, and its remote-update protocol can minimize network traffic to make transferring updates between machines fast and efficient. . It is widely used for backups and mirroring and as an improved copy command for everyday use. grade: stable confinement: devmode parts: rsync-deb: plugin: nil stage-packages: - rsync apps: rsync: command: rsync Built and installed fine with sudo classic sudo apt install snapcraft snapcraft exit sudo snap install --dangerous --devmode rsync_3.1.1_armhf.snap But rsync to the machine still doesn't work, since it expects rsync to be on PATH on the remote machine, so you need one of the workarounds mentioned above. End of story :-) From dank at kegel.com Wed Jan 4 20:23:22 2017 From: dank at kegel.com (Dan Kegel) Date: Wed, 4 Jan 2017 12:23:22 -0800 Subject: snappy swap redux Message-ID: Hi all, the ol' oom killer is getting me down. What's the kosher way of setting up swap in ubuntu core 16 (on raspberry pi)? https://lists.ubuntu.com/archives/snappy-devel/2016-March/001632.html mentions it should be done in a gadget. Is there a gadget tutorial? https://lists.snapcraft.io/archives/devices/2016-September/000005.html mentions it a bit but seems stale. In the meantime, I guess I can just do swapon manually. From kyle.fazzari at canonical.com Wed Jan 4 20:55:08 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 4 Jan 2017 12:55:08 -0800 Subject: snappy swap redux In-Reply-To: References: Message-ID: <2001b677-6a4d-6e12-1f28-00b544ec0b2a@canonical.com> On 01/04/2017 12:23 PM, Dan Kegel wrote: > Hi all, > the ol' oom killer is getting me down. > What's the kosher way of setting up swap in ubuntu core 16 (on raspberry pi)? > https://lists.ubuntu.com/archives/snappy-devel/2016-March/001632.html > mentions it should be done in a gadget. Is there a gadget tutorial? > https://lists.snapcraft.io/archives/devices/2016-September/000005.html > mentions it a bit but seems stale. > > In the meantime, I guess I can just do swapon manually. Note that https://bugs.launchpad.net/snappy/+bug/1560942 was logged after that discussion. I don't believe it has been resolved (i.e. I don't believe a gadget currently supports this). -- 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 Wed Jan 4 20:57:36 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 4 Jan 2017 12:57:36 -0800 Subject: Snap try broken? Message-ID: <762b041d-dac0-1313-3c07-2621b146350f@canonical.com> Hey all. I'm on xenial classic: $ snap --version snap 2.17.1ubuntu1 snapd 2.17.1ubuntu1 series 16 ubuntu 16.04 I just tried to `snap try` my snap, and I get a whole lot of these in my syslog: cannot snap-exec: cannot read info for "nextcloud": stat /var/lib/snapd/snaps/nextcloud_x1.snap: permission denied /var/lib/snapd/snaps/nextcloud_x1.snap is a symlink to $HOME/src/nextcloud-snap/prime . I do have an encrypted home, but I seem to remember this working once upon a time. I know that hooks don't work (https://bugs.launchpad.net/snappy/+bug/1637596), but is this a different bug? -- 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 sergio.schvezov at canonical.com Wed Jan 4 21:09:42 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 4 Jan 2017 18:09:42 -0300 Subject: Snapcraft tool under debian armhf In-Reply-To: References: Message-ID: El 04/01/17 a las 15:32, Boris Rybalkin escribió: > Great, that is what I was looking for! If you want to however give snapcraft a try on debian you just need to git clone https://github.com/snapcore/snapcraft.git and read HACKING.md in there. From gareth.france at cliftonts.co.uk Wed Jan 4 21:11:53 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Wed, 4 Jan 2017 21:11:53 +0000 Subject: Issues generating snap In-Reply-To: <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> Message-ID: <62a74bed-5a51-64e6-e132-d19c2ed3d5f5@cliftonts.co.uk> On 04/01/17 10:23, Mark Shuttleworth wrote: > On 04/01/17 08:34, Gareth France wrote: >> /usr/bin/env: 'python': No such file or directory >> >> It is a python script I've packaged. Any ideas? > Try changing the shell invocation line (first line of the Python script) > to /usr/bin/python3 rather than /usr/bin/env Unfortunately this has not resolved my issue. Now the error is gone but when I run my program it simply loads the python interpreter. Errors are produced upon quitting as well, see below. Python 3.5.2 (default, Jul 5 2016, 12:43:10) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> quit() Bad system call /snap/rokuterm/x7/bin/rokuterm: 11: /snap/rokuterm/x7/bin/rokuterm: import: not found /snap/rokuterm/x7/bin/rokuterm: 12: /snap/rokuterm/x7/bin/rokuterm: import: not found /snap/rokuterm/x7/bin/rokuterm: 13: /snap/rokuterm/x7/bin/rokuterm: import: not found /snap/rokuterm/x7/bin/rokuterm: 14: /snap/rokuterm/x7/bin/rokuterm: import: not found /snap/rokuterm/x7/bin/rokuterm: 15: /snap/rokuterm/x7/bin/rokuterm: import: not found /snap/rokuterm/x7/bin/rokuterm: 16: /snap/rokuterm/x7/bin/rokuterm: Syntax error: "(" unexpected (expecting "then") I have also included the contents of my snapcraft.yaml file: http://paste.ubuntu.com/23741430/ Any suggestions gratefully received. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Wed Jan 4 22:24:22 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Wed, 4 Jan 2017 22:24:22 +0000 Subject: Issues generating snap In-Reply-To: <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> References: <49d19861-2a82-d19c-be19-67faac2ef785@cliftonts.co.uk> <5f2d1398-5f17-d9ef-8b79-1f109b473842@canonical.com> <5c9aea39-8e1f-169c-f8c6-08c11981231e@canonical.com> <53bf6c0f-7fd6-f2e1-db84-f502c343adf1@ubuntu.com> Message-ID: <38928217-301b-a630-39e2-fe93927693b3@cliftonts.co.uk> On 04/01/17 10:23, Mark Shuttleworth wrote: > Try changing the shell invocation line (first line of the Python script) > to /usr/bin/python3 rather than /usr/bin/env > > Python3 is included in the core snap, so it is available at that path > for all devmode/strictly confined snaps. Just a quick note to let everyone know that thanks to some first class help in the irc channel I now have a (mostly) working snap. Now all I need to do is set the restrictions. With a working example I'm now free to explore and master this art so thanks to everyone who helped. From leo.arias at canonical.com Thu Jan 5 05:01:16 2017 From: leo.arias at canonical.com (Leo Arias) Date: Wed, 4 Jan 2017 23:01:16 -0600 Subject: calls for testing Message-ID: Hello! Last year we started the Ubuntu Testing Days. Now that we have covered some basics about getting a clean and safe environment to run tests, we would like to complement the sessions with frequent calls for testing. If you want to contribute to Ubuntu and to the free software projects that are starting to take advantage of snaps, or if you want to learn about these cool technologies, you can join our QA community. We will be sending the calls for testing to the quality mailing list. To subscribe: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality For the first one of the year, we will be testing ipfs: https://lists.ubuntu.com/archives/ubuntu-quality/2017-January/006749.html And if you have a nice snap ready and would like to get more people testing it before pushing to the stable channel, let me know. We can organize a testing session together. pura vida. -- ¡paz y baile! http://www.ubuntu.com From a.rogovsky at gmail.com Thu Jan 5 08:46:53 2017 From: a.rogovsky at gmail.com (Andrey Rogovsky) Date: Thu, 5 Jan 2017 10:46:53 +0200 Subject: How to set arch for stage-packages? In-Reply-To: References: Message-ID: Hi! I'm try set ':' instead of : and get same error: # snapcraft ... Error downloading stage packages for part 'packages': no such package "libstdc++6':'i386" Also I got another bug. If set target arch to 32bit - snapcraft download 64bit packages instead 32bit I thinking problem is deeper than using ':'. There is posibble to set arch for stage-packages somewhere? 2017-01-04 19:41 GMT+02:00 Sergio Schvezov : > El 04/01/17 a las 13:57, Andrey Rogovsky escribió: > > Hi! >> I need add few i386 packages to support my 32bit binary for amd64 systems: >> ... >> parts: >> packages: >> plugin: nil >> stage-packages: >> - libstdc++6:i386 >> ... >> But when I try pull - I get error: >> # snapcraft pull >> Skipping pull bluequest (already ran) >> Preparing to pull packages >> Hit http://ppa.launchpad.net/snappy-dev/tools/ubuntu xenial InRelease >> Get:1 http://security.ubuntu.com/ubuntu xenial-security InRelease [102 >> kB] >> Hit http://ua.archive.ubuntu.com/ubuntu xenial InRelease >> Hit http://ua.archive.ubuntu.com/ubuntu xenial-updates InRelease >> Hit http://ua.archive.ubuntu.com/ubuntu xenial-backports InRelease >> Fetched 102 kB in 0s (0 B/s) >> Error downloading stage packages for part 'packages': no such package >> 'libstdc++6:i386' >> >> Please advice. >> >> P.S. I dont need build i386 package. >> > > I think we are lacking a split in our python apt code to support this, a > matter of a .split(':') and passing the arch to our cache instance, mind > logging a bug? > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.mardegan at canonical.com Thu Jan 5 12:31:12 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Thu, 5 Jan 2017 15:31:12 +0300 Subject: Can a snapcraft plugin bring in stage packages and declare plugs? Message-ID: Hi all! I'm working on simplifying the process for creating snaps of webapps. I've tried building a part, but that doesn't seem to work (see https://lists.ubuntu.com/archives/snapcraft/2016-December/002186.html -- comments welcome, by the way :-) ). Now I'm considering achieving the same goal by writing a snapcraft plugin. Before starting to dig into this, I'd like to know what exactly can be done by a plugin; in particular, are these tasks feasible? - Automatically adding stage-packages to the part - Declaring plugs (like setting up the ubuntu-app-platform plug) As I understand, the plug definitions are not part of any snapcraft part, that's why I wonder if a snapcraft plugin (which is usually attached to a part) can alter them. Ciao, Alberto From sergio.schvezov at canonical.com Thu Jan 5 12:39:02 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 5 Jan 2017 09:39:02 -0300 Subject: Can a snapcraft plugin bring in stage packages and declare plugs? In-Reply-To: References: Message-ID: <5d4ea940-cd34-5825-04e6-184e3f90e6e8@canonical.com> El 05/01/17 a las 09:31, Alberto Mardegan escribió: > Hi all! > > I'm working on simplifying the process for creating snaps of webapps. > I've tried building a part, but that doesn't seem to work (see > https://lists.ubuntu.com/archives/snapcraft/2016-December/002186.html -- > comments welcome, by the way :-) ). > > Now I'm considering achieving the same goal by writing a snapcraft > plugin. Before starting to dig into this, I'd like to know what exactly > can be done by a plugin; in particular, are these tasks feasible? > > - Automatically adding stage-packages to the part This is possible, look at the python plugin. There's a class attribute you can extend. > - Declaring plugs (like setting up the ubuntu-app-platform plug) This is not possible, we've toy'ed with these ideas so far (just for the sake of curiosity), some orthogonal to others, others not: - parts can declare apps - parts can declare environment that apps can reference - parts can declare satisfying components or procedures that a plugin for such part would otherwise take care off (through use of `after` and a new `provides` keyword if plugin would know how to treat). All these are a bit too early to introduce given that there are way too many concepts to deal with today; we might introduce some (or none) of these in some future. From ogra at ubuntu.com Thu Jan 5 13:31:20 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 05 Jan 2017 14:31:20 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483553517.17893.11.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> Message-ID: <1483623080.18985.33.camel@ubuntu.com> hi, Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert: > > ogra at pi3:~$ grep audio= /boot/uboot/config.txt  > dtparam=audio=on > FYI both gadgets for pi2 and pi3 have just been updated in the edge channel with this fix, would be good if they could be tested with the pulse snap now :) 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 gareth.france at cliftonts.co.uk Thu Jan 5 13:39:33 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Thu, 05 Jan 2017 13:39:33 +0000 Subject: Correct usage of snapcraft.yaml Message-ID: <81ce9fc4016f8610f3662bb5d2551864@cliftonts.co.uk> Once again please do forgive my lack of knowledge. Having managed to successfully release a snap I am now wondering what the correct thing to do is regarding github. My code is there for anyone to obtain, so should the snapcraft.yaml be included or is that something one would normally keep to themselves? Thanks Gareth From mark at ubuntu.com Thu Jan 5 13:48:19 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 5 Jan 2017 15:48:19 +0200 Subject: Correct usage of snapcraft.yaml In-Reply-To: <81ce9fc4016f8610f3662bb5d2551864@cliftonts.co.uk> References: <81ce9fc4016f8610f3662bb5d2551864@cliftonts.co.uk> Message-ID: <7b189865-c8bb-3466-e9d4-e8976648752e@ubuntu.com> On 05/01/17 15:39, gareth.france at cliftonts.co.uk wrote: > Once again please do forgive my lack of knowledge. Having managed to > successfully release a snap I am now wondering what the correct thing > to do is regarding github. My code is there for anyone to obtain, so > should the snapcraft.yaml be included or is that something one would > normally keep to themselves? Would encourage you to have the snapcraft.yaml in the git tree; it makes it easier for people to contribute to that. Also, if the code is evolving, would encourage you to setup Travis or other CI integration so that you get an automatic edge release for (edgy) users :) Mark From gareth.france at cliftonts.co.uk Thu Jan 5 13:54:43 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Thu, 05 Jan 2017 13:54:43 +0000 Subject: Correct usage of snapcraft.yaml In-Reply-To: <7b189865-c8bb-3466-e9d4-e8976648752e@ubuntu.com> References: <81ce9fc4016f8610f3662bb5d2551864@cliftonts.co.uk> <7b189865-c8bb-3466-e9d4-e8976648752e@ubuntu.com> Message-ID: On 2017-01-05 13:48, Mark Shuttleworth wrote: > On 05/01/17 15:39, gareth.france at cliftonts.co.uk wrote: > Once again please do forgive my lack of knowledge. Having managed to > successfully release a snap I am now wondering what the correct thing > to do is regarding github. My code is there for anyone to obtain, so > should the snapcraft.yaml be included or is that something one would > normally keep to themselves? > > Would encourage you to have the snapcraft.yaml in the git tree; it > makes > it easier for people to contribute to that. Also, if the code is > evolving, would encourage you to setup Travis or other CI integration > so > that you get an automatic edge release for (edgy) users :) > > Mark I'm afraid I know nothing of Travis or CI integration. I learned to code in basic and a bed experience with Visual Basic many years ago put me off looking at modern languages for a long time. The discovery of Python and Pearl taught me that my knowledge is still relevant and I can still do this but I have a lot of catching up to do. Some of my methods are perhaps outdated and there are times when I really do struggle to get some of it, I don't have anyone experienced I can tap into in person so sometimes it is difficult finding a thread to pull on to get me started. I've wanted to contribute to Ubuntu for years but this has held me back. I now have two published programs, one on the phone/tablet and one on desktop. The first look into a whole new world for me! From didrocks at ubuntu.com Thu Jan 5 14:06:06 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Thu, 5 Jan 2017 15:06:06 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483623080.18985.33.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> <1483623080.18985.33.camel@ubuntu.com> Message-ID: <79a93522-cb61-8767-d4e1-f092b0511286@ubuntu.com> Le 05/01/2017 à 14:31, Oliver Grawert a écrit : > hi, > Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert: >> ogra at pi3:~$ grep audio= /boot/uboot/config.txt >> dtparam=audio=on >> > FYI both gadgets for pi2 and pi3 have just been updated in the edge > channel with this fix, would be good if they could be tested with the > pulse snap now :) I guess you can now close https://bugs.launchpad.net/snappy/+bug/1645605 as well thus. (when I send a feedback email a couple of months ago stating exactly the same issue ;)). Thanks for fixing it now. Cheers, Didier From didrocks at ubuntu.com Thu Jan 5 15:01:47 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Thu, 5 Jan 2017 16:01:47 +0100 Subject: New 2.20 snapd release In-Reply-To: References: <20161216090900.GF15361@bod> Message-ID: Le 03/01/2017 à 13:18, James Page a écrit : > On Tue, 3 Jan 2017 at 12:15 James Page > wrote: > > On Tue, 3 Jan 2017 at 11:58 Gustavo Niemeyer > > wrote: > > Will systemd handle multiple services with the same name > without complaining? How would it disambiguate? > > We can pull off snap aliases because the binary paths are > separate (not /usr/bin), and thus won't actually conflict even > if system packages and snaps define the same name. > > > I could see how this might be a problem; an Alias can either be > defined in the systemd unit file (in which case systemd will > create an appropriate symlink), or by creating the symlink from > alias->actual in /etc/systemd/system - I'll poke at things and see > how that might break! > > > It would appear that any symlink created in /etc/systemd/system masks > anything provided by a deb package in /lib/systemd/system - so the > glance-api alias from a snap would override the glance-api systemd > unit file provided by a deb package installed on the same system > > I guess this also fits into the general question of how to transition > an existing system from deb->snap in a elegant way as well :-) > Indeed, systemd has aliases for years, and we should use similarly the Alias keyword in the unit file for those cases. This just create a symlink at the right place and ensure only one unit with this symlink can be enabled at a time. This is how things like display manager, where some alternatives but a fixed service name might be needed (for dependencies) are handled, fyi. Cheers, Didier -------------- next part -------------- An HTML attachment was scrubbed... URL: From n13m3y3r at gmail.com Thu Jan 5 15:08:51 2017 From: n13m3y3r at gmail.com (Gustavo Niemeyer) Date: Thu, 5 Jan 2017 13:08:51 -0200 Subject: New 2.20 snapd release In-Reply-To: References: <20161216090900.GF15361@bod> Message-ID: James Page's accounting makes it sound like we cannot use that feature without compromising the predefined system services. On Jan 5, 2017 1:02 PM, "Didier Roche" wrote: > Le 03/01/2017 à 13:18, James Page a écrit : > > On Tue, 3 Jan 2017 at 12:15 James Page wrote: > >> On Tue, 3 Jan 2017 at 11:58 Gustavo Niemeyer > com> wrote: >> >> Will systemd handle multiple services with the same name without >> complaining? How would it disambiguate? >> >> We can pull off snap aliases because the binary paths are separate (not >> /usr/bin), and thus won't actually conflict even if system packages and >> snaps define the same name. >> >> >> I could see how this might be a problem; an Alias can either be defined >> in the systemd unit file (in which case systemd will create an appropriate >> symlink), or by creating the symlink from alias->actual in >> /etc/systemd/system - I'll poke at things and see how that might break! >> > > It would appear that any symlink created in /etc/systemd/system masks > anything provided by a deb package in /lib/systemd/system - so the > glance-api alias from a snap would override the glance-api systemd unit > file provided by a deb package installed on the same system > > I guess this also fits into the general question of how to transition an > existing system from deb->snap in a elegant way as well :-) > > > Indeed, systemd has aliases for years, and we should use similarly the > Alias keyword in the unit file for those cases. > This just create a symlink at the right place and ensure only one unit > with this symlink can be enabled at a time. > > This is how things like display manager, where some alternatives but a > fixed service name might be needed (for dependencies) are handled, fyi. > Cheers, > Didier > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Thu Jan 5 15:40:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 5 Jan 2017 12:40:11 -0300 Subject: Using Launchpad to build snaps In-Reply-To: <20161130035417.GA13369@riva.ucam.org> References: <20161130035417.GA13369@riva.ucam.org> Message-ID: <1cde267d-f4ac-c384-05f7-fffa5a3a166c@canonical.com> El 30/11/16 a las 00:54, Colin Watson escribió: > On Wed, Nov 30, 2016 at 02:49:50AM +0000, Evan Dandrea wrote: >> Can you elaborate on what you mean by "a regular user cannot use Launchpad >> to build snap packages"? Is it just that your build needs to access the >> Internet outside of the snapcraft pull phase? > That is indeed the problem Claudio appears to be having, from > https://launchpad.net/~claudioandre.br/+snap/anatine. Claudio, snacraft 2.24 can make your snap much simpler just adding the snapcraft.yaml to the upstream. http://paste.ubuntu.com/23746620/ (I slightly demoed this in the last Ubuntu Testing Days of 2016). From claudioandre.br at gmail.com Thu Jan 5 15:46:07 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=C3=A9?=) Date: Thu, 5 Jan 2017 13:46:07 -0200 Subject: Using Launchpad to build snaps In-Reply-To: <1cde267d-f4ac-c384-05f7-fffa5a3a166c@canonical.com> References: <20161130035417.GA13369@riva.ucam.org> <1cde267d-f4ac-c384-05f7-fffa5a3a166c@canonical.com> Message-ID: Very good. Thank you! 2017-01-05 13:40 GMT-02:00 Sergio Schvezov : > El 30/11/16 a las 00:54, Colin Watson escribió: > >> On Wed, Nov 30, 2016 at 02:49:50AM +0000, Evan Dandrea wrote: >> >>> Can you elaborate on what you mean by "a regular user cannot use >>> Launchpad >>> to build snap packages"? Is it just that your build needs to access the >>> Internet outside of the snapcraft pull phase? >>> >> That is indeed the problem Claudio appears to be having, from >> https://launchpad.net/~claudioandre.br/+snap/anatine. >> > > Claudio, snacraft 2.24 can make your snap much simpler just adding the > snapcraft.yaml to the upstream. > http://paste.ubuntu.com/23746620/ > > (I slightly demoed this in the last Ubuntu Testing Days of 2016). > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.vogt at canonical.com Thu Jan 5 16:52:49 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Thu, 5 Jan 2017 17:52:49 +0100 Subject: New stable "core" and "ubuntu-core" snaps released Message-ID: <20170105165249.GA11679@bod> Hi, The Snappy Team are happy to announce that we have a new version of the "core" snap in the stable channel. It is based on snapd 2.20 and contains all the good features of 2.20 that got announced in [1]. We also updated the "ubuntu-core" snap in the stable to be better aligned with the "core" snap. Due to the power of Ubuntu Core, your devices will update and reboot automatically :) Focus now shifts to the snapd 2.21 releases. It is targeted for next Thursday (2017-01-12). Please let us know if you notice any issues and enjoy the new release! Cheers, Michael (on behalf of the snappy team) [1] https://lists.ubuntu.com/archives/snapcraft/2016-December/002095.html From leo.arias at canonical.com Thu Jan 5 17:25:17 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 5 Jan 2017 11:25:17 -0600 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: <20170105165249.GA11679@bod> References: <20170105165249.GA11679@bod> Message-ID: Could you please explain what is ubuntu-core and core? In an old machine I have ubuntu-core, and I can't get core installed in there. Thanks Michael. -- ¡paz y baile! http://www.ubuntu.com From leo.arias at canonical.com Thu Jan 5 17:32:05 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 5 Jan 2017 11:32:05 -0600 Subject: QNetworkManagerInterface error when launching a snap Message-ID: Hello, When launching the shadow snap, these errors are printed to the terminal: QNetworkManagerInterface::QNetworkManagerInterface(QObject*) propsReply "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.138\" (uid=1000 pid=7546 comm=\"/snap/shadow/x2/usr/local/bin/umbra \") interface=\"org.freedesktop.DBus.Properties\" member=\"GetAll\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=864 comm=\"/usr/sbin/NetworkManager --no-daemon \")" QNetworkManagerInterface::QNetworkManagerInterface(QObject*) nmReply "An AppArmor policy prevents this sender from sending this message to this recipient; type=\"method_call\", sender=\":1.138\" (uid=1000 pid=7546 comm=\"/snap/shadow/x2/usr/local/bin/umbra \") interface=\"org.freedesktop.NetworkManager\" member=\"GetDevices\" error name=\"(unset)\" requested_reply=\"0\" destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=864 comm=\"/usr/sbin/NetworkManager --no-daemon \")" snappy-debug doesn't mention anything about it. How can we fix that? Here is the snapcraft.yaml: https://github.com/shadowproject/shadow/blob/master/snapcraft.yaml -- ¡paz y baile! http://www.ubuntu.com From claudioandre.br at gmail.com Thu Jan 5 17:40:31 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=C3=A9?=) Date: Thu, 5 Jan 2017 15:40:31 -0200 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170105165249.GA11679@bod> Message-ID: > Could you please explain what is ubuntu-core and core? Maybe say something about the snapd deb package (that handles ubuntu-core) Thank you! 2017-01-05 15:25 GMT-02:00 Leo Arias : > Could you please explain what is ubuntu-core and core? > In an old machine I have ubuntu-core, and I can't get core installed in > there. > > Thanks Michael. > -- > ¡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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Thu Jan 5 17:56:50 2017 From: manik at canonical.com (Manik Taneja) Date: Thu, 5 Jan 2017 09:56:50 -0800 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170105165249.GA11679@bod> Message-ID: On Thu, Jan 5, 2017 at 9:25 AM, Leo Arias wrote: > Could you please explain what is ubuntu-core and core? > *ubuntu-core* has been renamed to just *core*. > In an old machine I have ubuntu-core, and I can't get core installed in > there. > i had a similar issue and the only way i could get this corrected was to explicity uninstall and reinstall snapd. /manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Thu Jan 5 17:57:58 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 05 Jan 2017 18:57:58 +0100 Subject: New stable "core" and "ubuntu-core" snaps released In-Reply-To: References: <20170105165249.GA11679@bod> Message-ID: <1483639078.18985.46.camel@ubuntu.com> hi, Am Donnerstag, den 05.01.2017, 11:25 -0600 schrieb Leo Arias: > Could you please explain what is ubuntu-core and core? > In an old machine I have ubuntu-core, and I can't get core installed > in there. core/ubuntu-core is the execution environment in which your snaps run. on a classic installation there are interfaces that give your snap access to the outside world from the cage that ubuntu-core/core is. on an actual ubuntu-core *image* interfaces can only be provided by other snaps and core/ubuntu-core is your actual root filesystem (this is why michael mentioned the reboot above). initially this environment was called ubuntu-core, but with the cross distro approach that seemed inappropriate so it was renamed to just be called core. if you try out a recent stable ubuntu-core image you will only find the core snap installed. if you install your first snap on a classic system you will also get the core snap installed now. on all installs that pre-date the rename ubuntu-core was installed and is currently kept around. recently all focus was on the core snap and ubuntu-core was a bit left behind (never touch a running system when it is stable etc). with todays update they are completely in sync with identical content again. hope that clearifies some bits ... if not, keep asking ;) 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 jamie at canonical.com Thu Jan 5 17:58:06 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 05 Jan 2017 11:58:06 -0600 Subject: snappy swap redux In-Reply-To: <2001b677-6a4d-6e12-1f28-00b544ec0b2a@canonical.com> References: <2001b677-6a4d-6e12-1f28-00b544ec0b2a@canonical.com> Message-ID: <1483639086.8977.9.camel@canonical.com> On Wed, 2017-01-04 at 12:55 -0800, Kyle Fazzari wrote: > On 01/04/2017 12:23 PM, Dan Kegel wrote: > > > > Hi all, > > the ol' oom killer is getting me down. > > What's the kosher way of setting up swap in ubuntu core 16 (on raspberry > > pi)? > > https://lists.ubuntu.com/archives/snappy-devel/2016-March/001632.html > > mentions it should be done in a gadget.  Is there a gadget tutorial? > > https://lists.snapcraft.io/archives/devices/2016-September/000005.html > > mentions it a bit but seems stale. > > > > In the meantime, I guess I can just do swapon manually. > Note that https://bugs.launchpad.net/snappy/+bug/1560942 was logged > after that discussion. I don't believe it has been resolved (i.e. I > don't believe a gadget currently supports this). > On one of my all snaps devices I had the need to create swap space but wanted it in place on reboot so I created a devmode snap: https://code.launchpad.net/~jdstrand/+git/swaps This is a throwaway snap for 'managing' (trying not to oversell this thing ;) swap files (as opposed to swap partitions) that I created for myself until snappy supported this properly but feel free to use/steal/improve it to unblock yourself. I'm not sure what the plans are here: whether it is a gadget thing, a snap config thing for the core snap or something else. If people think managing swap by 'type: app' snaps is useful as an interface (eg, 'swap-control') let me know and I can submit a PR. -- 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 Thu Jan 5 18:06:35 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 05 Jan 2017 12:06:35 -0600 Subject: QNetworkManagerInterface error when launching a snap In-Reply-To: References: Message-ID: <1483639595.8977.13.camel@canonical.com> On Thu, 2017-01-05 at 11:32 -0600, Leo Arias wrote: > Hello, > > When launching the shadow snap, these errors are printed to the terminal: > You aren't plugging the network-manager interface. Once you do, you'll need to connect it after install. > QNetworkManagerInterface::QNetworkManagerInterface(QObject*) > propsReply "An AppArmor policy prevents this sender from sending this > message to this recipient; type=\"method_call\", sender=\":1.138\" > (uid=1000 pid=7546 comm=\"/snap/shadow/x2/usr/local/bin/umbra \") > interface=\"org.freedesktop.DBus.Properties\" member=\"GetAll\" error > name=\"(unset)\" requested_reply=\"0\" > destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=864 > comm=\"/usr/sbin/NetworkManager --no-daemon \")" > QNetworkManagerInterface::QNetworkManagerInterface(QObject*) nmReply > "An AppArmor policy prevents this sender from sending this message to > this recipient; type=\"method_call\", sender=\":1.138\" (uid=1000 > pid=7546 comm=\"/snap/shadow/x2/usr/local/bin/umbra \") > interface=\"org.freedesktop.NetworkManager\" member=\"GetDevices\" > error name=\"(unset)\" requested_reply=\"0\" > destination=\"org.freedesktop.NetworkManager\" (uid=0 pid=864 > comm=\"/usr/sbin/NetworkManager --no-daemon \")" > > snappy-debug doesn't mention anything about it. How can we fix that? snappy-debug doesn't support dbus denials yet. This is planned. You need to 'grep DEN /var/log/syslog' for dbus denials when debugging for now. > Here is the snapcraft.yaml: > https://github.com/shadowproject/shadow/blob/master/snapcraft.yaml > --  > ¡paz y baile! > http://www.ubuntu.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 dank at kegel.com Thu Jan 5 18:22:15 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 10:22:15 -0800 Subject: snappy core: "reboot scheduled to update the system" Message-ID: Just noticed this message "reboot scheduled to update the system" during a long-running build. Fortunately I was there and could do shutdown -c. Presumably this is the gadget snap (raspberry pi 3), and a real appliance would control this so it doesn't happen during critical operations. Where can I read more about how to control this? 15 seconds of googling didn't find much, just one irc log from three weeks ago. From dank at kegel.com Thu Jan 5 18:39:51 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 10:39:51 -0800 Subject: Snap portability between different boards? Message-ID: Hi all, can snaps built on the pi run on the artik, and vice versa? A compatibility matrix might be handy. From dank at kegel.com Thu Jan 5 18:48:45 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 10:48:45 -0800 Subject: opengl on ubuntu core 16 on artik 10? Message-ID: Hi all, has anyone tried artik 10 with ubuntu core 16, and what's the story with opengl there? From zygmunt.krynicki at canonical.com Thu Jan 5 18:50:52 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Thu, 5 Jan 2017 19:50:52 +0100 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: Hey I don't have access to that hardware so I don't know personally. If the kernel and userspace contain the relevant code it should be OK in devmode. For confinement it is possible that some of those bits will try to access something that is not permitted by the base set of rules. Do you have any test code you can try? Thanks ZK On Thu, Jan 5, 2017 at 7:48 PM, Dan Kegel wrote: > Hi all, > has anyone tried artik 10 with ubuntu core 16, > and what's the story with opengl there? > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Thu Jan 5 18:50:52 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Thu, 5 Jan 2017 19:50:52 +0100 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: Hey I don't have access to that hardware so I don't know personally. If the kernel and userspace contain the relevant code it should be OK in devmode. For confinement it is possible that some of those bits will try to access something that is not permitted by the base set of rules. Do you have any test code you can try? Thanks ZK On Thu, Jan 5, 2017 at 7:48 PM, Dan Kegel wrote: > Hi all, > has anyone tried artik 10 with ubuntu core 16, > and what's the story with opengl there? > > -- > 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 Thu Jan 5 18:51:18 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 05 Jan 2017 19:51:18 +0100 Subject: snappy core: "reboot scheduled to update the system" In-Reply-To: References: Message-ID: <1483642278.17893.13.camel@ubuntu.com> hi, On Do, 2017-01-05 at 10:22 -0800, Dan Kegel wrote: > Just noticed this message >  "reboot scheduled to update the system" > during a long-running build.  Fortunately I was there and could do > shutdown -c. > Presumably this is the gadget snap (raspberry pi 3), and a real > appliance would control this so it doesn't happen during > critical operations. > Where can I read more about how to control this? > 15 seconds of googling didn't find much, just one irc log > from three weeks ago. > there is supposed to be a snap config option in the core snap for it at some point ...   today you can only really tinker with it directly via systemctl in case you need to change it or completely want to turn off upgrades, the unit is called snapd.refresh.timer ... 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 dank at kegel.com Thu Jan 5 19:05:56 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 11:05:56 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: On Thu, Jan 5, 2017 at 10:50 AM, Zygmunt Krynicki wrote: >> has anyone tried artik 10 with ubuntu core 16, >> and what's the story with opengl there? > > I don't have access to that hardware so I don't know personally. If the > kernel and userspace contain the relevant code it should be OK in devmode. > For confinement it is possible that some of those bits will try to access > something that is not permitted by the base set of rules. > > Do you have any test code you can try? First off, let me say that I'm an opengl novice, I know very little about it. https://github.com/ubuntu/snappy-playpen/tree/master/hellogl runs a trivial opengl app, but probably with the default opengl, which might not be the platform's high-performance opengl. https://github.com/penk/oxide-eglfs-snap/tree/rpi2 is a real app that bundles the raspberry pi's high-performance opengl userspace driver into the snap; that's the kind of thing I'm looking for. I would be impressed if someone did a single snap that did high performance opengl on both Pi 3 and Artik 10. Seems unlikely. I have a Pi but not an Artik myself, just looking around at the other hardware Ubuntu Core supports. From dank at kegel.com Thu Jan 5 19:05:56 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 11:05:56 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: On Thu, Jan 5, 2017 at 10:50 AM, Zygmunt Krynicki wrote: >> has anyone tried artik 10 with ubuntu core 16, >> and what's the story with opengl there? > > I don't have access to that hardware so I don't know personally. If the > kernel and userspace contain the relevant code it should be OK in devmode. > For confinement it is possible that some of those bits will try to access > something that is not permitted by the base set of rules. > > Do you have any test code you can try? First off, let me say that I'm an opengl novice, I know very little about it. https://github.com/ubuntu/snappy-playpen/tree/master/hellogl runs a trivial opengl app, but probably with the default opengl, which might not be the platform's high-performance opengl. https://github.com/penk/oxide-eglfs-snap/tree/rpi2 is a real app that bundles the raspberry pi's high-performance opengl userspace driver into the snap; that's the kind of thing I'm looking for. I would be impressed if someone did a single snap that did high performance opengl on both Pi 3 and Artik 10. Seems unlikely. I have a Pi but not an Artik myself, just looking around at the other hardware Ubuntu Core supports. From leo.arias at canonical.com Thu Jan 5 19:25:08 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 5 Jan 2017 13:25:08 -0600 Subject: Correct usage of snapcraft.yaml In-Reply-To: References: <81ce9fc4016f8610f3662bb5d2551864@cliftonts.co.uk> <7b189865-c8bb-3466-e9d4-e8976648752e@ubuntu.com> Message-ID: Hey Garret, I'd be happy to help you getting started with travis. Where is your repository? Feel free to jump into https://rocket.ubuntu.com/channel/snapcraft, where we can chat faster than by email. pura vida. From mark at ubuntu.com Thu Jan 5 19:29:07 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 5 Jan 2017 21:29:07 +0200 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: On 05/01/17 20:39, Dan Kegel wrote: > can snaps built on the pi run on the artik, and vice versa? They certainly should, yes. We have armhf and arm64 and from a user-space perspective, modulo things like OpenGL, they are identical. Mark From mark at ubuntu.com Thu Jan 5 19:29:07 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 5 Jan 2017 21:29:07 +0200 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: On 05/01/17 20:39, Dan Kegel wrote: > can snaps built on the pi run on the artik, and vice versa? They certainly should, yes. We have armhf and arm64 and from a user-space perspective, modulo things like OpenGL, they are identical. Mark From mark at ubuntu.com Thu Jan 5 19:30:01 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 5 Jan 2017 21:30:01 +0200 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: <3b36a930-e94f-4230-963a-9fca6e2162c3@ubuntu.com> ... when I say identical, I don't mean arm64 and armhf are identical to each other of course :) but rather that all armhf boards use the same userspace, and same for all arm64. Mark From mark at ubuntu.com Thu Jan 5 19:30:01 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 5 Jan 2017 21:30:01 +0200 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: <3b36a930-e94f-4230-963a-9fca6e2162c3@ubuntu.com> ... when I say identical, I don't mean arm64 and armhf are identical to each other of course :) but rather that all armhf boards use the same userspace, and same for all arm64. Mark From jamie.bennett at canonical.com Thu Jan 5 19:48:55 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Thu, 5 Jan 2017 19:48:55 +0000 Subject: snappy core: "reboot scheduled to update the system" In-Reply-To: <1483642278.17893.13.camel@ubuntu.com> References: <1483642278.17893.13.camel@ubuntu.com> Message-ID: <20170105194855.sovpujbbwbcldaea@golstein> On 05/01/17 at 07:51pm, Oliver Grawert wrote: > hi, > On Do, 2017-01-05 at 10:22 -0800, Dan Kegel wrote: > > Just noticed this message > >  "reboot scheduled to update the system" > > during a long-running build.  Fortunately I was there and could do > > shutdown -c. > > Presumably this is the gadget snap (raspberry pi 3), and a real > > appliance would control this so it doesn't happen during > > critical operations. > > Where can I read more about how to control this? > > 15 seconds of googling didn't find much, just one irc log > > from three weeks ago. > > > there is supposed to be a snap config option in the core snap for it at > some point ... >   > today you can only really tinker with it directly via systemctl in case > you need to change it or completely want to turn off upgrades, the unit > is called snapd.refresh.timer ... Right, today the only way to do this is to play with the above timer but very soon i.e. we are working on it now, you will be able to delay/schedule updates. > ciao > oli Regards, Jamie. > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From tiago.herrmann at canonical.com Thu Jan 5 20:41:22 2017 From: tiago.herrmann at canonical.com (Tiago Herrmann) Date: Thu, 5 Jan 2017 18:41:22 -0200 Subject: [NEWS] Kdenlive devel snap In-Reply-To: References: Message-ID: Sorry to revive this old thread, but this very same website just posted a tutorial [1] on how to manage snaps. The maintainer of this website is a friend of mine and he told me his goal was to write the most complete snap utilization tutorial available in Portuguese. He has been doing a great job on spreading news about ubuntu and snap here in Brazil. [1] http://www.diolinux.com.br/2017/01/ubuntu-snap-utilization-manual.html or google translation: https://translate.google.com/translate?hl=pt-BR&sl=pt&tl=en&u=http%3A%2F%2Fwww.diolinux.com.br%2F2017%2F01%2Fubuntu-snap-utilization-manual.html On Wed, Nov 9, 2016 at 1:34 PM, Michael Hall wrote: > It's in Portuguese[1], but Google Translate[2] works pretty well. > > "This is one of the interesting examples for comments regarding Snap, > with it, we do not need extra repositories to have a program in its > latest version, all without affecting the system base that ensures > stability in an LTS distribution such as Ubuntu 16.04." > > [1] http://www.diolinux.com.br/2016/11/editor-de-video-kdenlive-agora-e.html > > [2] > https://translate.google.com/translate?hl=en&sl=pt&tl=en&u=http%3A%2F%2Fwww.diolinux.com.br%2F2016%2F11%2Feditor-de-video-kdenlive-agora-e.html > > -- > Michael Hall > mhall119 at ubuntu.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From dank at kegel.com Thu Jan 5 21:30:57 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 13:30:57 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: I crossposted the question to https://developer.artik.io/forums/t/opengl-on-ubuntu-core-16-on-artik-10/2234 including a link to the userspace driver library that someone mentioned. From dank at kegel.com Thu Jan 5 21:30:57 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 13:30:57 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: I crossposted the question to https://developer.artik.io/forums/t/opengl-on-ubuntu-core-16-on-artik-10/2234 including a link to the userspace driver library that someone mentioned. From michael.vogt at canonical.com Thu Jan 5 22:13:00 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Thu, 5 Jan 2017 23:13:00 +0100 Subject: snapd 2.20 release available in {xenial,yakkety}-updates Message-ID: <20170105221300.GA16549@bod> Hi, the new snapd version 2.20 is now available for everyone on Ubuntu 16.04 and 16.10 via xenial-updates and yakkety-updates. It contains some nice improvements and fixes, see [1] for the details. The other distros will be updated shortly. The snapd 14.04 version is not quite ready yet, we are working on a seccomp filtering bug [2] on amd64 and also on a xserver related problem [3]. We hope to resolve those soon. Please let us know if you notice any issue. Happy snapping, Michael (on behalf of the snappy team) [1] https://lists.ubuntu.com/archives/snapcraft/2016-December/002095.html [2] https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487 [3] https://bugs.launchpad.net/snappy/+bug/1650389 From dank at kegel.com Thu Jan 5 22:22:11 2017 From: dank at kegel.com (Dan Kegel) Date: Thu, 5 Jan 2017 14:22:11 -0800 Subject: snapd 2.20 release available in {xenial,yakkety}-updates In-Reply-To: <20170105221300.GA16549@bod> References: <20170105221300.GA16549@bod> Message-ID: Can you say a few words about classic confinement? I didn't see doc... (Like the fact that you're supporting 14.04. Some large customers are stuck on that version still, could be handy.) On Thu, Jan 5, 2017 at 2:13 PM, Michael Vogt wrote: > Hi, > > > the new snapd version 2.20 is now available for everyone on Ubuntu > 16.04 and 16.10 via xenial-updates and yakkety-updates. It contains > some nice improvements and fixes, see [1] for the details. > > The other distros will be updated shortly. The snapd 14.04 version is > not quite ready yet, we are working on a seccomp filtering bug [2] on > amd64 and also on a xserver related problem [3]. We hope to resolve > those soon. > > Please let us know if you notice any issue. > > > Happy snapping, > Michael (on behalf of the snappy team) > > > [1] https://lists.ubuntu.com/archives/snapcraft/2016-December/002095.html > [2] https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487 > [3] https://bugs.launchpad.net/snappy/+bug/1650389 > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From davidc at framli.eu Thu Jan 5 23:43:29 2017 From: davidc at framli.eu (=?UTF-8?Q?David_Call=c3=a9?=) Date: Fri, 6 Jan 2017 00:43:29 +0100 Subject: snapd 2.20 release available in {xenial,yakkety}-updates In-Reply-To: References: <20170105221300.GA16549@bod> Message-ID: <2e67fa13-66b9-3ad0-b4f4-2d94672c3a67@framli.eu> On 05/01/2017 23:22, Dan Kegel wrote: > Can you say a few words about classic confinement? I didn't see doc... Hopefully, http://snapcraft.io/docs/reference/confinement will shed some light on the different confinement policies. David > > (Like the fact that you're supporting 14.04. Some large customers > are stuck on that version still, could be handy.) > > On Thu, Jan 5, 2017 at 2:13 PM, Michael Vogt wrote: >> Hi, >> >> >> the new snapd version 2.20 is now available for everyone on Ubuntu >> 16.04 and 16.10 via xenial-updates and yakkety-updates. It contains >> some nice improvements and fixes, see [1] for the details. >> >> The other distros will be updated shortly. The snapd 14.04 version is >> not quite ready yet, we are working on a seccomp filtering bug [2] on >> amd64 and also on a xserver related problem [3]. We hope to resolve >> those soon. >> >> Please let us know if you notice any issue. >> >> >> Happy snapping, >> Michael (on behalf of the snappy team) >> >> >> [1] https://lists.ubuntu.com/archives/snapcraft/2016-December/002095.html >> [2] https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487 >> [3] https://bugs.launchpad.net/snappy/+bug/1650389 >> >> -- >> 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 Thu Jan 5 23:50:05 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 05 Jan 2017 17:50:05 -0600 Subject: How do I share a namespace between snap commands? In-Reply-To: References: <1469638980.5406.135.camel@canonical.com> <82b76113-3b81-3e33-688b-36bca351c11a@ubuntu.com> Message-ID: <1483660205.8977.59.camel@canonical.com> On Wed, 2016-08-17 at 18:52 +0000, David Garrod wrote: > Unfortunately my bug report has not received any substantive replies so I'm > back here. Please could someone comment on the issue I'm having and/or give me > a pointer on where to look to try and diagnose the cause of the failure. This > problem is severely holding up our progress in SNAPifying OpenSwitch. > Hi Dave, As you probably saw in the bug updates[1] today and the release announcements, snapd 2.20 is now available on Ubuntu Core series 16 and 16.04 classic systems and it contains the features to allow you to manage network namespaces with 'ip netns' in either devmode or strict confinement by using the 'network-control' interface. While it took a while to get there[3], hopefully this will resolve your issues with snapping openswitch. If you have any issues, please don't hesitate to ask and/or file bugs. [1]https://bugs.launchpad.net/snappy/+bug/1611444 [2]https://bugs.launchpad.net/snappy/+bug/1624675 [3]https://bugs.launchpad.net/snappy/+bug/1611444/comments/36 > Thanks, > > Dave > > -----Original Message----- > From: David Garrod > Sent: Tuesday, August 09, 2016 12:32 PM > To: 'Didier Roche'; Jamie Strandboge; snapcraft at lists.ubuntu.com > Subject: RE: How do I share a namespace between snap commands? > > Re: > > > > > even if you continue posting here (which is good to trigger discussion), > > please file a bug against the snappy launchpad project: > > https://launchpad.net/snappy/ (even if I think this one may impact rather > > snap-confine, but it will be redirected) > > > > Didier > Thanks. I've followed your suggestion and have logged bug: > > https://bugs.launchpad.net/snappy/+bug/1611444 > > > ________________________________ > > DISCLAIMER: > This e-mail and any attachments to it may contain confidential and proprietary > material and is solely for the use of the intended recipient. Any review, use, > disclosure, distribution or copying of this transmittal is prohibited except > by or on behalf of the intended recipient. If you have received this > transmittal in error, please notify the sender and destroy this e-mail and any > attachments and all copies, whether electronic or printed. > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From xiaoguo.liu at canonical.com Fri Jan 6 00:59:35 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Fri, 6 Jan 2017 08:59:35 +0800 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: I think it should as long as they both have the same architecture (32bit or 64bit). If the app use any specific hardware, we need to make sure it exists on both platform, for example camera. On Fri, Jan 6, 2017 at 2:39 AM, Dan Kegel wrote: > Hi all, > can snaps built on the pi run on the artik, and vice versa? > A compatibility matrix might be handy. > > -- > 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 leo.arias at canonical.com Fri Jan 6 05:35:47 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 5 Jan 2017 23:35:47 -0600 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: This is interesting. I would like to write some snaps using gobot that work on raspberry pi and beaglebone black. The only difference should be the line where the adaptor is defined: https://github.com/hybridgroup/gobot/blob/master/examples/beaglebone_blink.go#L12 Can I query the snappy system to see which is the current gadget? That would let me define the adaptor in a conditional, and use a single codebase for both boards. From leo.arias at canonical.com Fri Jan 6 05:35:47 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 5 Jan 2017 23:35:47 -0600 Subject: Snap portability between different boards? In-Reply-To: References: Message-ID: This is interesting. I would like to write some snaps using gobot that work on raspberry pi and beaglebone black. The only difference should be the line where the adaptor is defined: https://github.com/hybridgroup/gobot/blob/master/examples/beaglebone_blink.go#L12 Can I query the snappy system to see which is the current gadget? That would let me define the adaptor in a conditional, and use a single codebase for both boards. From michael.vogt at canonical.com Fri Jan 6 08:48:47 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Fri, 6 Jan 2017 09:48:47 +0100 Subject: snapd 2.20 release available in {xenial,yakkety}-updates In-Reply-To: References: <20170105221300.GA16549@bod> Message-ID: <20170106084847.GI15361@bod> Hi Dan, On Thu, Jan 05, 2017 at 02:22:11PM -0800, Dan Kegel wrote: > Can you say a few words about classic confinement? I didn't see doc... Thanks for this reminder, I should have included the link that David provided to http://snapcraft.io/docs/reference/confinement In a nutshell classic make it very easy to provide snaps for traditional (classic) distributions like Ubuntu 16.04. It is currently not quite as polished as we would like it to be (we are actively working on fixing that!) but I think its a really nice feature. > (Like the fact that you're supporting 14.04. Some large customers > are stuck on that version still, could be handy.) We have good news here - we fixed the build problem and snapd 2.20 is now available in 14.04 in the "trusty-proposed" channel. I would suggest to use it in a server environment only currently until we had a chance to fix the xserver bug [3] (below). Cheers, Michael > On Thu, Jan 5, 2017 at 2:13 PM, Michael Vogt wrote: > > Hi, > > > > > > the new snapd version 2.20 is now available for everyone on Ubuntu > > 16.04 and 16.10 via xenial-updates and yakkety-updates. It contains > > some nice improvements and fixes, see [1] for the details. > > > > The other distros will be updated shortly. The snapd 14.04 version is > > not quite ready yet, we are working on a seccomp filtering bug [2] on > > amd64 and also on a xserver related problem [3]. We hope to resolve > > those soon. > > > > Please let us know if you notice any issue. > > > > > > Happy snapping, > > Michael (on behalf of the snappy team) > > > > > > [1] https://lists.ubuntu.com/archives/snapcraft/2016-December/002095.html > > [2] https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1653487 > > [3] https://bugs.launchpad.net/snappy/+bug/1650389 > > > > -- > > 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 ogra at ubuntu.com Fri Jan 6 12:18:53 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 06 Jan 2017 13:18:53 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483623080.18985.33.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> <1483623080.18985.33.camel@ubuntu.com> Message-ID: <1483705133.26677.4.camel@ubuntu.com> hi, Am Donnerstag, den 05.01.2017, 14:31 +0100 schrieb Oliver Grawert: > hi, > Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert: > > > > > > ogra at pi3:~$ grep audio= /boot/uboot/config.txt  > > dtparam=audio=on > > > FYI both gadgets for pi2 and pi3 have just been updated in the edge > channel with this fix, would be good if they could be tested with the > pulse snap now :) > so i tried to do some testing now that we have alsa enabled images ...  installing 8.0-3-12 from beta/candidate without --devmode makes the daemon fail on startup with a seccomp error trying to call setgroups32 and indeed you cant use any of the shipped commands like parec or paplay ...  if i install with --devmode from either channel, the daemon starts and the commands work fine though ... so seems we are close ;) 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 jamie at canonical.com Fri Jan 6 14:09:44 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 06 Jan 2017 08:09:44 -0600 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483705133.26677.4.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> <1483623080.18985.33.camel@ubuntu.com> <1483705133.26677.4.camel@ubuntu.com> Message-ID: <1483711784.8977.63.camel@canonical.com> On Fri, 2017-01-06 at 13:18 +0100, Oliver Grawert wrote: > hi, > Am Donnerstag, den 05.01.2017, 14:31 +0100 schrieb Oliver Grawert: > > > > hi, > > Am Mittwoch, den 04.01.2017, 19:11 +0100 schrieb Oliver Grawert: > > > > > > > > > > > > ogra at pi3:~$ grep audio= /boot/uboot/config.txt  > > > dtparam=audio=on > > > > > FYI both gadgets for pi2 and pi3 have just been updated in the edge > > channel with this fix, would be good if they could be tested with the > > pulse snap now :) > > > so i tried to do some testing now that we have alsa enabled images ...  > > installing 8.0-3-12 from beta/candidate without --devmode makes the > daemon fail on startup with a seccomp error trying to call setgroups32 > and indeed you cant use any of the shipped commands like parec or > paplay ...  > if i install with --devmode from either channel, the daemon starts and > the commands work fine though ... so seems we are close ;) > This seems like a bug in the pulseaudio interface which allows 'setgroups' but not 'setgroups32'. Can you add setgroups32 to /var/lib/snap/seccomp/profiles/snap.pulseaudio... then restart the daemon and see if that works for you? Can you file a bug if you haven't already? -- 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 arshidkv12 at gmail.com Fri Jan 6 02:53:33 2017 From: arshidkv12 at gmail.com (Muhammed Arshid KV) Date: Fri, 6 Jan 2017 08:23:33 +0530 Subject: App Developer Message-ID: Please add me -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Jan 6 15:12:34 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 06 Jan 2017 16:12:34 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483711784.8977.63.camel@canonical.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> <1483623080.18985.33.camel@ubuntu.com> <1483705133.26677.4.camel@ubuntu.com> <1483711784.8977.63.camel@canonical.com> Message-ID: <1483715554.26677.6.camel@ubuntu.com> hi, Am Freitag, den 06.01.2017, 08:09 -0600 schrieb Jamie Strandboge: >   > > if i install with --devmode from either channel, the daemon starts > > and > > the commands work fine though ... so seems we are close ;) > > > This seems like a bug in the pulseaudio interface which allows > 'setgroups' but > not 'setgroups32'. Can you add setgroups32 to > /var/lib/snap/seccomp/profiles/snap.pulseaudio... then restart the > daemon and > see if that works for you? Can you file a bug if you haven't already? > adding setgroups32 led to the next missing syscall ("send") ... adding support for send as well makes the daemon start fine then ... i filed http://pad.lv/1654585 and assigned it to you ...  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 daniel at bowlhat.net Fri Jan 6 16:10:08 2017 From: daniel at bowlhat.net (Daniel Llewellyn) Date: Fri, 06 Jan 2017 16:10:08 +0000 Subject: Accessing dbus (KDE Application) In-Reply-To: <1481826797.22365.7.camel@canonical.com> References: <95aba172-d5a7-4744-b1cf-cc0c09c26b3b@kdenlive.org> <772e31f7-034b-e313-e19b-5bd5c2c00915@ubuntu.com> <5f16df03-12af-4865-024d-f73196fc9d9b@canonical.com> <30fb12e8-d9f2-ae30-c222-1ac1bf47eacc@ubuntu.com> <962e6d91-7341-9aaa-57ce-627d5865c9bd@canonical.com> <1481826797.22365.7.camel@canonical.com> Message-ID: On Thu, 15 Dec 2016 at 18:33 Jamie Strandboge wrote: > FYI, the upcoming snapd 2.20 will support the 'dbus' interface. With this > you > can update your snap to include something like: > > slots: > dbus-corebird: > interface: dbus > bus: session > name: org.baedert.corebird > I've added that stanza to my snapcraft.yml and rebuilt using strict confinement on the new 2.20 snapd. That works perfectly, but on uploading my package to the store (corebird-diddledan.diddledan) I received an automated testing fail email reporting that: not allowed by 'deny-connection/slot-attributes' in base declaration declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus) Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From loic.minier at ubuntu.com Fri Jan 6 17:17:26 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Fri, 6 Jan 2017 18:17:26 +0100 Subject: Locally extending trusted certificates Message-ID: Hi, This question came up in the context of Docker registries with self-signed certificates: http://askubuntu.com/questions/868268/add-self-signed- certificate-in-ubuntu-core-16-04 this could be addressed in ways specific to the Docker snap, but I believe this touches a larger question: support for extending the list of system-trusted certificates. Our Ubuntu Core images ship with a set of trusted certificates. These are inherited from the .deb world where there is a mechanism to locally extend the list of trusted certificates (update-ca-certificates). This mechanism doesn't work with core images due to read-only directories (and perhaps other issues as well). Here are some possible options to address this: 1) fix the update-ca-certificates system to also work on core images; this might just be a matter of making some directories bind-mounts to the writable space 2) implement some kind of snapd keystore feature/configs/APIs (much like system keystores on mobile OSes); this is likely significant work, but opens interesting perspectives in providing new management APIs and a more secure implementation. For instance, one could design this to store secrets in hw-specific secure stores, or offer mechanisms to roll out new certificates/keys via assertions, or to disable some specific CAs 3) keep the list of system certificates as static and not locally configurable; this will likely result in some snaps developing alternate keystores I'm sure there are other options and I'd to hear how people think this should best be addressed in the snap/snapd world. Cheers, - Loïc Minier -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhall119 at gmail.com Fri Jan 6 17:24:21 2017 From: mhall119 at gmail.com (Michael Hall) Date: Fri, 6 Jan 2017 12:24:21 -0500 Subject: App Developer In-Reply-To: References: Message-ID: Hi Muhammed, You can subscribe to the mailing list here: https://lists.ubuntu.com/mailman/listinfo/snapcraft Michael Hall mhall119 at gmail.com On 01/05/2017 09:53 PM, Muhammed Arshid KV wrote: > Please add me > > > From jamie at canonical.com Fri Jan 6 17:47:06 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 06 Jan 2017 11:47:06 -0600 Subject: Accessing dbus (KDE Application) In-Reply-To: References: <95aba172-d5a7-4744-b1cf-cc0c09c26b3b@kdenlive.org> <772e31f7-034b-e313-e19b-5bd5c2c00915@ubuntu.com> <5f16df03-12af-4865-024d-f73196fc9d9b@canonical.com> <30fb12e8-d9f2-ae30-c222-1ac1bf47eacc@ubuntu.com> <962e6d91-7341-9aaa-57ce-627d5865c9bd@canonical.com> <1481826797.22365.7.camel@canonical.com> Message-ID: <1483724826.8977.76.camel@canonical.com> On Fri, 2017-01-06 at 16:10 +0000, Daniel Llewellyn wrote: > On Thu, 15 Dec 2016 at 18:33 Jamie Strandboge wrote: > > > > > FYI, the upcoming snapd 2.20 will support the 'dbus' interface. With this > > you > > can update your snap to include something like: > > > > slots: > >   dbus-corebird: > >     interface: dbus > >     bus: session > >     name: org.baedert.corebird > > > I've added that stanza to my snapcraft.yml and rebuilt using strict > confinement on the new 2.20 snapd. That works perfectly, Glad to hear the interface is working for you! :) > but on uploading > my package to the store (corebird-diddledan.diddledan) I received an > automated testing fail email reporting that: > > not allowed by 'deny-connection/slot-attributes' in base declaration > declaration-snap-v2_slots_deny-connection (dbus-corebird, dbus) > Yes, to claim the well-known dbus name for your snap you need a snap declaration that allows it. I've granted this to your snap just now and it passes automated review. This snap declaration applies to future uploads as well. (Note that while revisions 6 and 7 have passed review, you still need to release them). -- 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 daniel at bowlhat.net Fri Jan 6 17:50:10 2017 From: daniel at bowlhat.net (Daniel Llewellyn) Date: Fri, 06 Jan 2017 17:50:10 +0000 Subject: Accessing dbus (KDE Application) In-Reply-To: <1483724826.8977.76.camel@canonical.com> References: <95aba172-d5a7-4744-b1cf-cc0c09c26b3b@kdenlive.org> <772e31f7-034b-e313-e19b-5bd5c2c00915@ubuntu.com> <5f16df03-12af-4865-024d-f73196fc9d9b@canonical.com> <30fb12e8-d9f2-ae30-c222-1ac1bf47eacc@ubuntu.com> <962e6d91-7341-9aaa-57ce-627d5865c9bd@canonical.com> <1481826797.22365.7.camel@canonical.com> <1483724826.8977.76.camel@canonical.com> Message-ID: On Fri, 6 Jan 2017 at 17:47 Jamie Strandboge wrote: > Yes, to claim the well-known dbus name for your snap you need a snap > declaration > that allows it. I've granted this to your snap just now and it passes > automated > review. This snap declaration applies to future uploads as well. (Note that > while revisions 6 and 7 have passed review, you still need to release > them). > Awesome, thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From claudioandre.br at gmail.com Fri Jan 6 17:54:54 2017 From: claudioandre.br at gmail.com (=?UTF-8?Q?Claudio_Andr=C3=A9?=) Date: Fri, 6 Jan 2017 15:54:54 -0200 Subject: Snaps on Unity7 and app-indicators In-Reply-To: <18caf0c6-a757-74ae-cd2b-64522e749942@canonical.com> References: <18caf0c6-a757-74ae-cd2b-64522e749942@canonical.com> Message-ID: 2016-12-02 13:38 GMT-02:00 Marco Trevisan < marco.trevisan at canonical.com>: > Hello snapcrafters, > > As you might have noticed, snap packages that are including > app-indicators won't generally show the proper icon in unity Hi, below an error I saw while using LP build servers. Ok, I added the missing build packages. But, why "parts" is not aware of its dependencies? Claudio ------ Preparing to build indicator-gtk2 Building indicator-gtk2 You need gnome-common from GNOME SVN Downloading parts list Downloading parts list Downloading parts list Downloading parts list Downloading parts list Downloading parts list Downloading parts list Downloading parts list Downloading parts list Command '['/bin/sh', '/tmp/tmpk6h4cu_n', 'env', 'NOCONFIGURE=1', './autogen.sh']' returned non-zero exit status 1 env NOCONFIGURE=1 ./autogen.sh Traceback (most recent call last): File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 199, in main builder.pull() File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 136, 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) ------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Fri Jan 6 18:10:22 2017 From: dank at kegel.com (Dan Kegel) Date: Fri, 6 Jan 2017 10:10:22 -0800 Subject: classic mode slow, taking up one full core with apparmor logging Message-ID: When building a c++ app on a raspberry pi 3 in classic mode, I noticed two things that hurt performance substantially. 1) the obvious: if you crank config.txt's gpu_mem up above the default, life is bad :-) Don't do that on build machines. 2) the not so obvious: apparmor is keeping systemctl's journal process at 100% on one core logging crud like Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3249]: AVC apparmor="ALLOWED" operation="open" profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5//null-/var/snap/classic/common/classic/usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus" name="/var/snap/classic/common/classic/usr/include/c++/5/cstring" pid=3249 comm="cc1plus" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0 Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3254]: AVC apparmor="ALLOWED" operation="mknod" profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5" name="/var/snap/classic/common/classic/tmp/ccpOmyw6.s" pid=3254 comm="c++" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 Is there an option for reducing apparmor verbosity on ALLOWED operations? (speaking strictly as a foreigner in the land of apparmor and snappy) Thanks! From mike.pontillo at canonical.com Fri Jan 6 18:12:35 2017 From: mike.pontillo at canonical.com (Mike Pontillo) Date: Fri, 6 Jan 2017 10:12:35 -0800 Subject: netplan and post-up/pre-down scripts Message-ID: Hi all, Recently, I was working on a project that led me to become frustrated with the current state of `systemd` and `ifupdown` (e.g. /etc/network/interfaces or /e/n/i) in Xenial. I remembered that `netplan`[1] was under development, so I added the PPA for Xenial and gave it a try. Unfortunately, it didn't solve the issue for me[2]... but I also realized there was a blocking issue in the way of my adoption of it. Let me explain my use case: when an interface goes up or down, I want to be able to do event-driven things with the network configuration, such as add or remove routes, run a DHCP client, etc. My first attempt to make this happen was to add `post-up` and `pre-down` scripts to do this. However, this had a fatal flaw for my application: `ifupdown` doesn't separate the concept of operational status from the concept of administrative status. (That is, in `ifupdown`, an interface is "up" if the admin says it is up. Link up or link down does not seem to matter; it's strictly an /administrative/ status[3].) Long story short: in order to get the behavior I wanted, I wrote a custom script that monitors *operational status* (aka physical link up/down status), and I launch it using /e/n/i's `post-up`, and bring it down using /e/n/i's `pre-down` scripts. Looking at the `netplan` spec[4], I don't see a way to achieve that functionality. I know that many people are using the script-callout functionality in /e/n/i to achieve what they need to achieve, so it seems to me that having this in `netplan` is critical to achieving parity with what we have in Xenial with `ifupdown`. In an ideal world, I think `netplan` would be able to model my use case out-of-the-box.[5] But since we can't expect to model everyone's use case, it seems like custom scripting functionality is a hard requirement, though perhaps one that could have tricky cross-platform implications. Thoughts? Regards, Mike [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039464.html [2]: The behavior was exactly the same, which is actually good for consistency. [3]: Well, it is after an annoying 5 minute timeout, in some cases. [4]: https://git.launchpad.net/netplan/tree/doc/netplan.md [5]: As an aside, this brings up an interesting subtle difference between rendering a networking configuration with (networkd, ifupdown) vs NetworkManager. In NetworkManager, there *IS* a concept of operational status, and I would have been able to get closer to the behavior I wanted, if I was willing to pull in all those dependencies. We should be mindful that rendering the same configuration on NetworkManager, even for simple things like a static IP address and a DHCP interface, could produce drastically different behavior than with networkd or ifupdown. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dank at kegel.com Fri Jan 6 18:14:18 2017 From: dank at kegel.com (Dan Kegel) Date: Fri, 6 Jan 2017 10:14:18 -0800 Subject: classic mode slow, taking up one full core with apparmor logging In-Reply-To: References: Message-ID: Just to illustrate, here's the output of top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 489 root 20 0 13320 3876 1940 R 99.7 0.4 17:36.31 systemd-journal 3779 obdank 20 0 75428 62776 9652 R 93.4 6.7 0:05.93 cc1plus 3734 obdank 20 0 138540 132004 12216 R 79.7 14.0 0:39.54 cc1plus 3707 obdank 20 0 202312 197908 12216 R 64.3 21.0 1:15.61 cc1plus 3785 obdank 20 0 61032 46176 9716 R 59.3 4.9 0:03.80 cc1plus I wantsss all the cores for cc1plussss, I does, I does. On Fri, Jan 6, 2017 at 10:10 AM, Dan Kegel wrote: > When building a c++ app on a raspberry pi 3 in classic mode, > I noticed two things that hurt performance substantially. > > 1) the obvious: if you crank config.txt's gpu_mem up above the > default, life is bad :-) Don't do that on build machines. > > 2) the not so obvious: apparmor is keeping systemctl's journal process > at 100% on one core logging crud like > > Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3249]: AVC apparmor="ALLOWED" > operation="open" > profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5//null-/var/snap/classic/common/classic/usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus" > name="/var/snap/classic/common/classic/usr/include/c++/5/cstring" > pid=3249 comm="cc1plus" requested_mask="r" denied_mask="r" fsuid=1000 > ouid=0 > Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3254]: AVC apparmor="ALLOWED" > operation="mknod" > profile="snap.classic.classic//null-/usr/bin/systemd-run//null-/usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/script//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/usr/bin/sudo//null-/var/snap/classic/common/classic/bin/bash//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/buildshim//null-/var/snap/classic/common/classic/home/obdank/src/ob-repobot/yovo/cmake.d/buildshim-ubu//null-/var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh//null-/var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null-/var/snap/classic/common/classic/usr/bin/dh_auto_build//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/usr/bin/make//null-/var/snap/classic/common/classic/bin/dash//null-/var/snap/classic/common/classic/usr/bin/g++-5" > name="/var/snap/classic/common/classic/tmp/ccpOmyw6.s" pid=3254 > comm="c++" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 > > Is there an option for reducing apparmor verbosity on ALLOWED operations? > (speaking strictly as a foreigner in the land of apparmor and snappy) > > Thanks! From jamie at canonical.com Fri Jan 6 19:33:59 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 06 Jan 2017 13:33:59 -0600 Subject: classic mode slow, taking up one full core with apparmor logging In-Reply-To: References: Message-ID: <1483731239.8977.94.camel@canonical.com> On Fri, 2017-01-06 at 10:10 -0800, Dan Kegel wrote: > When building a c++ app on a raspberry pi 3 in classic mode, > I noticed two things that hurt performance substantially. > > 1) the obvious: if you crank config.txt's gpu_mem up above the > default, life is bad :-)  Don't do that on build machines. > > 2) the not so obvious: apparmor is keeping systemctl's journal process > at 100% on one core logging crud like > > Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3249]: AVC apparmor="ALLOWED" > operation="open" > profile="snap.classic.classic//null-/usr/bin/systemd-run//null- > /usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null- > /var/snap/classic/common/classic/usr/bin/script//null- > /var/snap/classic/common/classic/bin/bash//null- > /var/snap/classic/common/classic/usr/bin/sudo//null- > /var/snap/classic/common/classic/bin/bash//null- > /var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null- > /var/snap/classic/common/classic/home/obdank/src/ob- > repobot/yovo/buildshim//null- > /var/snap/classic/common/classic/home/obdank/src/ob- > repobot/yovo/cmake.d/buildshim-ubu//null- > /var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null- > /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null- > /var/snap/classic/common/classic/usr/bin/dh//null- > /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null- > /var/snap/classic/common/classic/usr/bin/dh_auto_build//null- > /var/snap/classic/common/classic/usr/bin/make//null- > /var/snap/classic/common/classic/us! >  r/bin/mak >  e//null-/var/snap/classic/common/classic/usr/bin/make//null- > /var/snap/classic/common/classic/bin/dash//null- > /var/snap/classic/common/classic/usr/bin/g++-5//null- > /var/snap/classic/common/classic/usr/lib/gcc/arm-linux-gnueabihf/5/cc1plus" > name="/var/snap/classic/common/classic/usr/include/c++/5/cstring" > pid=3249 comm="cc1plus" requested_mask="r" denied_mask="r" fsuid=1000 > ouid=0 > Jan 06 18:03:37 rbb-ubu1604pi3-1 audit[3254]: AVC apparmor="ALLOWED" > operation="mknod" > profile="snap.classic.classic//null-/usr/bin/systemd-run//null- > /usr/sbin/chroot//null-/var/snap/classic/common/classic/bin/dash//null- > /var/snap/classic/common/classic/usr/bin/script//null- > /var/snap/classic/common/classic/bin/bash//null- > /var/snap/classic/common/classic/usr/bin/sudo//null- > /var/snap/classic/common/classic/bin/bash//null- > /var/snap/classic/common/classic/home/obdank/src/ob-repobot/bau//null- > /var/snap/classic/common/classic/home/obdank/src/ob- > repobot/yovo/buildshim//null- > /var/snap/classic/common/classic/home/obdank/src/ob- > repobot/yovo/cmake.d/buildshim-ubu//null- > /var/snap/classic/common/classic/usr/bin/dpkg-buildpackage//null- > /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null- > /var/snap/classic/common/classic/usr/bin/dh//null- > /var/snap/classic/common/classic/home/obdank/src/yovo/debian/rules//null- > /var/snap/classic/common/classic/usr/bin/dh_auto_build//null- > /var/snap/classic/common/classic/usr/bin/make//null- > /var/snap/classic/common/classic/us! >  r/bin/mak >  e//null-/var/snap/classic/common/classic/usr/bin/make//null- > /var/snap/classic/common/classic/bin/dash//null- > /var/snap/classic/common/classic/usr/bin/g++-5" > name="/var/snap/classic/common/classic/tmp/ccpOmyw6.s" pid=3254 > comm="c++" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 > > Is there an option for reducing apparmor verbosity on ALLOWED operations? > (speaking strictly as a foreigner in the land of apparmor and snappy) > What is happening is that the classic snap is currently using a chroot with devmode. devmode causes policy violations to be allowed but logged but because it is using a chroot instead of a pivot_root, all the file accesses don't match the rules from the default template. To silence the logging, the policy needs to be updated. There are several options on how to do this and it needs a little bit of design on which implementation is best. In the meantime, as a quick workaround you can add this to /var/lib/snapd/apparmor/profiles/snap.classic.classic before the final '}':   mount fstype=devpts options=(rw) devpts -> /dev/pts/,   /bin/mountpoint ixr,   @{PROC}/[0-9]*/mountinfo r,   /var/lib/extrausers/{,*} r,   capability fsetid,   capability dac_override,   /etc/sudoers.d/{,*} r,   /usr/bin/systemd-run Uxr,   /bin/systemctl Uxr, then load the profile into the kernel with: $ sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.classic.classic Now you should be able to 'sudo classic' and not see any apparmor logging. Note that you may have to re-add the above rules to the profile (eg, if the snap is removed/installed/updated/etc). IIRC the snappy team is aware of this issue, but so it can be properly tracked, I filed: https://bugs.launchpad.net/snappy/+bug/1654642 -- 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 gareth.france at cliftonts.co.uk Sun Jan 8 09:24:41 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Sun, 8 Jan 2017 09:24:41 +0000 Subject: Unicode characters break snap Message-ID: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Having finally packaged my Roku and Now TV remote (RokuTerm) I am now bug fixing and adding polish. It functions very well but is rather ugly so I have created a new keypad screen using unicode characters. It is all written in python and runs perfectly locally, however when snapped it fails with the following error: UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-24: ordinal not in range(128) So is there something I have to add to the python script, or the snapcraft.yaml to allow the unicode characters? Thanks Gareth From arshidkv12 at gmail.com Sun Jan 8 12:48:24 2017 From: arshidkv12 at gmail.com (Muhammed Arshid KV) Date: Sun, 8 Jan 2017 18:18:24 +0530 Subject: Add to repository Message-ID: How to add bash shell script to Ubuntu repository ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ribalkin at gmail.com Sun Jan 8 17:25:04 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Sun, 8 Jan 2017 17:25:04 +0000 Subject: Snapd free space available check In-Reply-To: References: Message-ID: Hello, Could you tell me if snapd does any free space check before installing a snap? Github link would be ideal if possible. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomi.richards at canonical.com Mon Jan 9 00:20:37 2017 From: thomi.richards at canonical.com (Thomi Richards) Date: Mon, 9 Jan 2017 13:20:37 +1300 Subject: Unicode characters break snap In-Reply-To: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: Hi Gareth, On Sun, Jan 8, 2017 at 10:24 PM, Gareth France < gareth.france at cliftonts.co.uk> wrote: > So is there something I have to add to the python script, or the > snapcraft.yaml to allow the unicode characters? This sounds like you may be running into unicode encoding issues in your python source files. https://www.python.org/dev/peps/pep-0263/ has the full details, but the tl,dr version is that if you have unicode literals in your python source file you need something like "# -*- coding: utf-8 -*-" at the top of your file. The python interpreter inspects your environment to determine the correct encoding to use, but your environment in a confined snap probably doesn't provide the same hints... If that doesn't work, can you build a minimal reproducer for us to look at? Cheers, -- Thomi Richards thomi.richards at canonical.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ericoporto2008 at gmail.com Mon Jan 9 00:27:47 2017 From: ericoporto2008 at gmail.com (=?UTF-8?B?w4lyaWNvIFA=?=) Date: Sun, 8 Jan 2017 22:27:47 -0200 Subject: Unicode characters break snap In-Reply-To: References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: the string is only needed for Python 2, I think Python3 defaults to utf8 encoding. Em 8 de jan de 2017 22:21, "Thomi Richards" escreveu: > Hi Gareth, > > On Sun, Jan 8, 2017 at 10:24 PM, Gareth France < > gareth.france at cliftonts.co.uk> wrote: > >> So is there something I have to add to the python script, or the >> snapcraft.yaml to allow the unicode characters? > > > > This sounds like you may be running into unicode encoding issues in your > python source files. https://www.python.org/dev/peps/pep-0263/ has the > full details, but the tl,dr version is that if you have unicode literals in > your python source file you need something like "# -*- coding: utf-8 -*-" > at the top of your file. The python interpreter inspects your environment > to determine the correct encoding to use, but your environment in a > confined snap probably doesn't provide the same hints... > > > If that doesn't work, can you build a minimal reproducer for us to look at? > > Cheers, > > -- > Thomi Richards > thomi.richards at canonical.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Mon Jan 9 06:02:20 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Mon, 9 Jan 2017 06:02:20 +0000 Subject: Unicode characters break snap In-Reply-To: References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: On 09/01/17 00:20, Thomi Richards wrote: > This sounds like you may be running into unicode encoding issues in > your python source files. https://www.python.org/dev/peps/pep-0263/ > has the full details, but the tl,dr version is that if you have > unicode literals in your python source file you need something like "# > -*- coding: utf-8 -*-" at the top of your file. The python interpreter > inspects your environment to determine the correct encoding to use, > but your environment in a confined snap probably doesn't provide the > same hints... > > > If that doesn't work, can you build a minimal reproducer for us to > look at? Afraid not, still doing the same thing. Just one question. What on earth is a minimal reproducer? -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.nelson at canonical.com Mon Jan 9 06:12:19 2017 From: michael.nelson at canonical.com (Michael Nelson) Date: Mon, 09 Jan 2017 06:12:19 +0000 Subject: Unicode characters break snap In-Reply-To: References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: On Mon, Jan 9, 2017 at 5:03 PM Gareth France wrote: > > > On 09/01/17 00:20, Thomi Richards wrote: > > This sounds like you may be running into unicode encoding issues in your > python source files. > https://www.python.org/dev/peps/pep-0263/ has the full details, but the > tl,dr version is that if you have unicode literals in your python source > file you need something like "# -*- coding: utf-8 -*-" at the top of your > file. The python interpreter inspects your environment to determine the > correct encoding to use, but your environment in a confined snap probably > doesn't provide the same hints... > > > If that doesn't work, can you build a minimal reproducer for us to look at? > > Afraid not, still doing the same thing. Just one question. What on earth > is a minimal reproducer? > Just a paste of an example snapcraft.yaml with which other people can reproduce the issue... it could be your current snapcraft.yaml, or something cut down to be simpler but still reproduces the issue. That'll help someone else debug it locally. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Mon Jan 9 06:14:38 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Mon, 9 Jan 2017 06:14:38 +0000 Subject: Unicode characters break snap In-Reply-To: References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: On 09/01/17 06:12, Michael Nelson wrote: > On Mon, Jan 9, 2017 at 5:03 PM Gareth France > > > wrote: > > > > On 09/01/17 00:20, Thomi Richards wrote: >> This sounds like you may be running into unicode encoding issues >> in your python source files. >> https://www.python.org/dev/peps/pep-0263/ has the full details, >> but the tl,dr version is that if you have unicode literals in >> your python source file you need something like "# -*- coding: >> utf-8 -*-" at the top of your file. The python interpreter >> inspects your environment to determine the correct encoding to >> use, but your environment in a confined snap probably doesn't >> provide the same hints... >> >> >> If that doesn't work, can you build a minimal reproducer for us >> to look at? > Afraid not, still doing the same thing. Just one question. What on > earth is a minimal reproducer? > > > Just a paste of an example snapcraft.yaml with which other people can > reproduce the issue... it could be your current snapcraft.yaml, or > something cut down to be simpler but still reproduces the issue. > That'll help someone else debug it locally. > > > Everything is available here: https://github.com/cliftonts/RokuTerm.git -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.rogovsky at gmail.com Mon Jan 9 08:59:41 2017 From: a.rogovsky at gmail.com (Andrey Rogovsky) Date: Mon, 9 Jan 2017 10:59:41 +0200 Subject: How to add custom libs to snap? Message-ID: Hi, all! I need add custom precompiled libs (no sources) to my snap. I have directory with libs. Need put it into snap. How I can do it? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.pope at canonical.com Mon Jan 9 10:14:57 2017 From: alan.pope at canonical.com (Alan Pope) Date: Mon, 9 Jan 2017 10:14:57 +0000 Subject: How to add custom libs to snap? In-Reply-To: References: Message-ID: Hi Andrey, On 9 January 2017 at 08:59, Andrey Rogovsky wrote: > I need add custom precompiled libs (no sources) to my snap. > I have directory with libs. Need put it into snap. How I can do it? I achieved this with one of my snaps by simply using the copy plugin to put the libs into lib/ and then having a launch script which ensures the LD_LIBRARY_PATH is set appropriately. So, (assuming you're only targetting amd64) copy the libs to lib/x86_64-linux-gnu and in your launcher have something along the lines. export LD_LIBRARY_PATH=$SNAP/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From jenny.murphy at episensor.com Mon Jan 9 10:28:32 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Mon, 9 Jan 2017 10:28:32 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core Message-ID: Hi, My query is related to a few of the recent discussions regarding versions, releases and updates/ I currently have a Snappy Ubuntu system as follows : snap --version gives the following result : snap 2.18.1 snapd 2.18.1 series 16 more /etc/lsb-release yeilds : DISTRIB_ID="Ubuntu Core" DISTRIB_RELEASE=16 DISTRIB_DESCRIPTION="Ubuntu Core 16 And finally snap list yields : core 16.04.1 641 canonical -- I don't see to be getting any automatic updates which I don't mind about as long as I could manually update. So just a few questions : 1. How can I update snap and snapd 2. Is snap the front end to snapd ? Do they get updated together? 3. Can I update snapd and not update ubuntu-core and core. 4. Should ubuntu-core and core be updated together also? From the previous reply on this topic, it seems core is the framework and ubuntu-core is the filesystem or is it vice versa? I know there are a lot of questions here but it is just a little bit unclear to me at the moment. Maybe there are also some other users in the same position. Thanks, Jenny *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at daltondurst.com Sun Jan 8 19:20:07 2017 From: me at daltondurst.com (Dalton) Date: Sun, 08 Jan 2017 13:20:07 -0600 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo Message-ID: <1483903207.2507.1@mail.gandi.net> Hello everyone, Is there any way to get Snapcraft to pull the git source of a kernel at every build without cleaning the entire build directory? Currently, if I make a change to my kernel source (I'm using a source in '.' in my case) then commit it, Snapcraft simply ignores the changes since it has pulled the source previously, printing 'Skipping pull kernel (already ran)'. I have to run 'snapcraft clean' in order to get it to pull the (local) source again. Snapcraft then goes on and redownloads 'os.snap', a 60MB file, again. On a fast connection, this is no problem. I'm on a slightly slower connection that also has a data cap, so this is a waste of both time and bits. It seems like there are two ways to avoid this: A way to cache os.snap locally, or a way to have Snapcraft run 'git pull' to grab source changes into its working directory. Is either possible right now? If it helps, my current snapcraft.yaml can be found here: http://paste.ubuntu.com/23766072/ (Yes, I understand that a 3.4 kernel probably won't run Snaps very well, if at all) Thanks, Dalton -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Mon Jan 9 13:08:10 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 9 Jan 2017 14:08:10 +0100 Subject: Snapd free space available check In-Reply-To: References: Message-ID: I don't think we're doing this yet. Can you please report an issue so that it can be tracked. Best regards ZK On Sun, Jan 8, 2017 at 6:25 PM, Boris Rybalkin wrote: > Hello, > > Could you tell me if snapd does any free space check before installing a > snap? > > Github link would be ideal if possible. > > Thank you. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleixpol at kde.org Sun Jan 8 19:26:44 2017 From: aleixpol at kde.org (Aleix Pol) Date: Sun, 8 Jan 2017 20:26:44 +0100 Subject: Snappy evolution Message-ID: Hi everyone, Last Snappy meeting we discussed several subjects and I would like to know what's the status, hence this e-mail. - Usage of snappy in random Linux systems: Red Hat et al (Fedora, CentOS), random GNU/Linux kernels (e.g. ArchLinux and Android). - Some discussed AppStream semantics introduction for integration in Software Centers. Thanks! Aleix From kyle.nitzsche at canonical.com Mon Jan 9 14:07:41 2017 From: kyle.nitzsche at canonical.com (knitzsche) Date: Mon, 9 Jan 2017 09:07:41 -0500 Subject: How to add custom libs to snap? In-Reply-To: References: Message-ID: On 01/09/2017 05:14 AM, Alan Pope wrote: > Hi Andrey, > > On 9 January 2017 at 08:59, Andrey Rogovsky wrote: >> I need add custom precompiled libs (no sources) to my snap. >> I have directory with libs. Need put it into snap. How I can do it? > > I achieved this with one of my snaps by simply using the copy plugin > to put the libs into lib/ and then having a launch script > which ensures the LD_LIBRARY_PATH is set appropriately. If memory serves, the copy plugin is deprecated in favor of the dump plugin. Here's a small example: environment: plugin: dump source: . organize: run.wrapper: bin/run It means there's a file in root dir (".") named run.wrapper and it should be copied (dumped) to bin/run in the snap, as I understand it. Cheers, Kyle > > So, (assuming you're only targetting amd64) copy the libs to > lib/x86_64-linux-gnu and in your launcher have something along the > lines. > > export LD_LIBRARY_PATH=$SNAP/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH > > Cheers, > From ngompa13 at gmail.com Mon Jan 9 14:24:08 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Mon, 9 Jan 2017 09:24:08 -0500 Subject: Snappy evolution In-Reply-To: References: Message-ID: On Sun, Jan 8, 2017 at 2:26 PM, Aleix Pol wrote: > Hi everyone, > Last Snappy meeting we discussed several subjects and I would like to > know what's the status, hence this e-mail. > - Usage of snappy in random Linux systems: Red Hat et al (Fedora, > CentOS), random GNU/Linux kernels (e.g. ArchLinux and Android). This is not working. SELinux support is missing within snapd, and I'm still playing whack-a-mole with the SELinux policy module[0] I've been working on. Unfortunately, the correct way to handle this is something I'm simply not skilled at doing, since it requires fundamentally comprehensive understanding of snapd and conceptual understanding of SELinux as a MAC and how to use it through libselinux in the manner needed by snapd. While I have the conceptual understanding of SELinux, I do not have the other two pieces. The concepts of SELinux MAC and snapd's security model do mostly line up, from what I can tell, so it's just a matter of someone with understanding of both bridging the gap. CentOS, Fedora, and Android use SELinux, so this is a prerequisite for making Snappy work in a useful, secure manner. Arch Linux has no MAC by default, though the community prefers SELinux and offers it as a supported-ish option (see Arch Hardened), likewise for Gentoo (see Gentoo Hardened). In addition, we're still missing some kind of way to swap default core snaps and have a concept of a "base" snap so that distributions can build snaps from their own code. I wrote code for making core snaps based on Fedora, Mageia, or openSUSE[1], but there's still no way for me to force snapd to use a different core snap. There's also still work to be done from the Snapcraft side to support different distributions, too. See the snapcraft bug[2] for details. [0]: https://gitlab.com/Conan_Kudo/snapcore-selinux [1]: https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap [2]: https://bugs.launchpad.net/snapcraft/+bug/1602258 > - Some discussed AppStream semantics introduction for integration in > Software Centers. > As far as I know, I don't think anything has happened on this front since we discussed at the sprint. -- 真実はいつも一つ！/ Always, there's only one truth! From zygmunt.krynicki at canonical.com Mon Jan 9 15:08:31 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 9 Jan 2017 16:08:31 +0100 Subject: Snappy evolution In-Reply-To: References: Message-ID: > Wiadomość napisana przez Aleix Pol w dniu 08.01.2017, o godz. 20:26: > > Hi everyone, > Last Snappy meeting we discussed several subjects and I would like to > know what's the status, hence this e-mail. > - Usage of snappy in random Linux systems: Red Hat et al (Fedora, > CentOS), random GNU/Linux kernels (e.g. ArchLinux and Android). I put together a wiki page describing this [1] [1] https://github.com/snapcore/snapd/wiki/Distributions > - Some discussed AppStream semantics introduction for integration in > Software Centers. I’m not sure about this. Can you expand on what you are asking about? Best regards ZK From gustavo at niemeyer.net Mon Jan 9 16:05:28 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 9 Jan 2017 18:05:28 +0200 Subject: Snappy evolution In-Reply-To: References: Message-ID: On Mon, Jan 9, 2017 at 5:08 PM, Zygmunt Krynicki < zygmunt.krynicki at canonical.com> wrote: > > > Wiadomość napisana przez Aleix Pol w dniu > 08.01.2017, o godz. 20:26: > > > > Hi everyone, > > Last Snappy meeting we discussed several subjects and I would like to > > know what's the status, hence this e-mail. > > - Usage of snappy in random Linux systems: Red Hat et al (Fedora, > > CentOS), random GNU/Linux kernels (e.g. ArchLinux and Android). > > I put together a wiki page describing this [1] > > [1] https://github.com/snapcore/snapd/wiki/Distributions Nice! > - Some discussed AppStream semantics introduction for integration in > > Software Centers. > > I’m not sure about this. Can you expand on what you are asking about? > That's about supporting an appstream file in the Store as we discussed back in the sprint. I believe not much has happened yet. Still on the queue, though. Same case with the alternative base snaps. We worked on quite a few major features in the last couple of months on the way to 2.20, and ended up pushing some of the previously discussed features forward. We need to revive these ideas, and probably rediscuss them a bit to make sure everybody is still in sync. gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.sawicz at canonical.com Mon Jan 9 19:32:16 2017 From: michal.sawicz at canonical.com (=?UTF-8?Q?Micha=c5=82_Sawicz?=) Date: Mon, 9 Jan 2017 20:32:16 +0100 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: <1483903207.2507.1@mail.gandi.net> References: <1483903207.2507.1@mail.gandi.net> Message-ID: <1129d257-a0f7-a6bb-a56f-0b2117c808bf@canonical.com> W dniu 08.01.2017 o 20:20, Dalton pisze: > > Is there any way to get Snapcraft to pull the git source of a kernel at > every build without cleaning the entire build directory? > > Currently, if I make a change to my kernel source (I'm using a source in > '.' in my case) then commit it, Snapcraft simply ignores the changes > since it has pulled the source previously, printing 'Skipping pull > kernel (already ran)'. I have to run 'snapcraft clean' in order to get > it to pull the (local) source again. Snapcraft then goes on and > redownloads 'os.snap', a 60MB file, again. On a fast connection, this is > no problem. I'm on a slightly slower connection that also has a data > cap, so this is a waste of both time and bits. > > It seems like there are two ways to avoid this: A way to cache os.snap > locally, or a way to have Snapcraft run 'git pull' to grab source > changes into its working directory. Is either possible right now? I *think* (may be wrong) that `snapcraft pull` can help here: http://snapcraft.io/docs/reference/snapcraft-command#pull -- 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 thomi.richards at canonical.com Mon Jan 9 20:07:00 2017 From: thomi.richards at canonical.com (Thomi Richards) Date: Tue, 10 Jan 2017 09:07:00 +1300 Subject: Unicode characters break snap In-Reply-To: References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: Hi, When I build and install a snap from your git repository it prints the contents of my environment to the screen and exits 0. By 'minimal reproducer' I mean a small, self-contained example that demonstrates the problem. Most often the process of making such an example will highlight the problem for you. Some hints can be found here: http://sscce.org/ I'd be more than happy to take a look at a small example the reproduces the problem. I can't reproduce the issue from your current git repository though. Cheers, On Mon, Jan 9, 2017 at 7:14 PM, Gareth France wrote: > > > On 09/01/17 06:12, Michael Nelson wrote: > > On Mon, Jan 9, 2017 at 5:03 PM Gareth France < > gareth.france at cliftonts.co.uk> wrote: > >> >> >> On 09/01/17 00:20, Thomi Richards wrote: >> >> This sounds like you may be running into unicode encoding issues in your >> python source files. https://www.python.org/dev/peps/pep-0263/ has the >> full details, but the tl,dr version is that if you have unicode literals in >> your python source file you need something like "# -*- coding: utf-8 -*-" >> at the top of your file. The python interpreter inspects your environment >> to determine the correct encoding to use, but your environment in a >> confined snap probably doesn't provide the same hints... >> >> >> If that doesn't work, can you build a minimal reproducer for us to look >> at? >> >> Afraid not, still doing the same thing. Just one question. What on earth >> is a minimal reproducer? >> > > Just a paste of an example snapcraft.yaml with which other people can > reproduce the issue... it could be your current snapcraft.yaml, or > something cut down to be simpler but still reproduces the issue. That'll > help someone else debug it locally. > > > > Everything is available here: > https://github.com/cliftonts/RokuTerm.git > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- Thomi Richards thomi.richards at canonical.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.sawicz at canonical.com Mon Jan 9 20:08:47 2017 From: michal.sawicz at canonical.com (=?UTF-8?Q?Micha=c5=82_Sawicz?=) Date: Mon, 9 Jan 2017 21:08:47 +0100 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: <1129d257-a0f7-a6bb-a56f-0b2117c808bf@canonical.com> References: <1483903207.2507.1@mail.gandi.net> <1129d257-a0f7-a6bb-a56f-0b2117c808bf@canonical.com> Message-ID: <4139e5ce-0270-a621-7a3a-3c9c91a80837@canonical.com> W dniu 09.01.2017 o 20:32, Michał Sawicz pisze: > I *think* (may be wrong) that `snapcraft pull` can help here: > > http://snapcraft.io/docs/reference/snapcraft-command#pull I was able to force `snapcraft pull` to pull things again by messing with parts/part-name/state - might wanna try that in case there's no better answers. HTH, -- 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 gareth.france at cliftonts.co.uk Mon Jan 9 20:16:19 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Mon, 9 Jan 2017 20:16:19 +0000 Subject: Unicode characters break snap In-Reply-To: References: <69eec395-c145-0330-272e-7fb6adeeeaa7@cliftonts.co.uk> Message-ID: <64a3e7b7-aac2-0579-c5d2-699bff748750@cliftonts.co.uk> I think you'll find that was a temporary issue caused by me this evening for about 15 minutes whilst resolving the issue. Everything is now working as desired. On 09/01/17 20:07, Thomi Richards wrote: > Hi, > > When I build and install a snap from your git repository it prints the > contents of my environment to the screen and exits 0. > > By 'minimal reproducer' I mean a small, self-contained example that > demonstrates the problem. Most often the process of making such an > example will highlight the problem for you. Some hints can be found > here: http://sscce.org/ > > I'd be more than happy to take a look at a small example the > reproduces the problem. I can't reproduce the issue from your current > git repository though. > > Cheers, > > On Mon, Jan 9, 2017 at 7:14 PM, Gareth France > > > wrote: > > > > On 09/01/17 06:12, Michael Nelson wrote: >> On Mon, Jan 9, 2017 at 5:03 PM Gareth France >> > > wrote: >> >> >> >> On 09/01/17 00:20, Thomi Richards wrote: >>> This sounds like you may be running into unicode encoding >>> issues in your python source files. >>> https://www.python.org/dev/peps/pep-0263/ >>> has the full >>> details, but the tl,dr version is that if you have unicode >>> literals in your python source file you need something like >>> "# -*- coding: utf-8 -*-" at the top of your file. The >>> python interpreter inspects your environment to determine >>> the correct encoding to use, but your environment in a >>> confined snap probably doesn't provide the same hints... >>> >>> >>> If that doesn't work, can you build a minimal reproducer for >>> us to look at? >> Afraid not, still doing the same thing. Just one question. >> What on earth is a minimal reproducer? >> >> >> Just a paste of an example snapcraft.yaml with which other people >> can reproduce the issue... it could be your current >> snapcraft.yaml, or something cut down to be simpler but still >> reproduces the issue. That'll help someone else debug it locally. >> >> >> > Everything is available here: > https://github.com/cliftonts/RokuTerm.git > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > Thomi Richards > thomi.richards at canonical.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.hodapp at canonical.com Mon Jan 9 21:06:13 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Mon, 9 Jan 2017 16:06:13 -0500 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: <1483903207.2507.1@mail.gandi.net> References: <1483903207.2507.1@mail.gandi.net> Message-ID: You can also simply clean to a specific step in the process as well which may help you out. It'll clean out every step from the end back to the step that you specify. E.g. snapcraft clean --step pull http://snapcraft.io/docs/reference/snapcraft-command#clean On Sun, Jan 8, 2017 at 2:20 PM, Dalton wrote: > Hello everyone, > > Is there any way to get Snapcraft to pull the git source of a kernel at > every build without cleaning the entire build directory? > > Currently, if I make a change to my kernel source (I'm using a source in > '.' in my case) then commit it, Snapcraft simply ignores the changes since > it has pulled the source previously, printing 'Skipping pull kernel > (already ran)'. I have to run 'snapcraft clean' in order to get it to pull > the (local) source again. Snapcraft then goes on and redownloads 'os.snap', > a 60MB file, again. On a fast connection, this is no problem. I'm on a > slightly slower connection that also has a data cap, so this is a waste of > both time and bits. > > It seems like there are two ways to avoid this: A way to cache os.snap > locally, or a way to have Snapcraft run 'git pull' to grab source changes > into its working directory. Is either possible right now? > > If it helps, my current snapcraft.yaml can be found here: > http://paste.ubuntu.com/23766072/ > > (Yes, I understand that a 3.4 kernel probably won't run Snaps very well, > if at all) > > Thanks, > Dalton > > -- > 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 kyle.fazzari at canonical.com Mon Jan 9 21:31:25 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Mon, 9 Jan 2017 13:31:25 -0800 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: <4139e5ce-0270-a621-7a3a-3c9c91a80837@canonical.com> References: <1483903207.2507.1@mail.gandi.net> <1129d257-a0f7-a6bb-a56f-0b2117c808bf@canonical.com> <4139e5ce-0270-a621-7a3a-3c9c91a80837@canonical.com> Message-ID: On 01/09/2017 12:08 PM, Michał Sawicz wrote: > W dniu 09.01.2017 o 20:32, Michał Sawicz pisze: >> I *think* (may be wrong) that `snapcraft pull` can help here: >> >> http://snapcraft.io/docs/reference/snapcraft-command#pull > > I was able to force `snapcraft pull` to pull things again by messing > with parts/part-name/state - might wanna try that in case there's no > better answers. Careful with this, snapcraft tends to get upset if you mess with its state behind its back. Lifecycle steps build upon each other: pull -> build -> stage -> prime. Let's say you ran `snapcraft build A`, which will pull part A (let's say it was commit abdc1), and then build it. If commit abcd2 is later made and you want to build it, you need to clean the pull step (which will also clean the build step) with `snapcraft clean A`, and build again: `snapcraft build A`. That will pull any updates that have been made, and build anew. -- 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 daltondurst.com Tue Jan 10 01:35:12 2017 From: me at daltondurst.com (Dalton) Date: Mon, 09 Jan 2017 19:35:12 -0600 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: References: Message-ID: <1484012112.8922.2.camel@daltondurst.com> > Message: 1 > Date: Mon, 9 Jan 2017 20:32:16 +0100 > From: Micha? Sawicz > To: Snapcraft > Subject: Re: Kernel plugin: Avoid redownloading os.snap on a local > Git repo > Message-ID: <1129d257-a0f7-a6bb-a56f-0b2117c808bf at canonical.com> > > I *think* (may be wrong) that `snapcraft pull` can help here: > > http://snapcraft.io/docs/reference/snapcraft-command#pull Boy, I sure hope replying this way worked. Like a loser, I subscribed in Digest mode. Fixed that now. This doesn't really help, Snapcraft simply says that 'pull' for 'kernel' is out of date, and that I should clean then pull again. In any case, I've filed a bug here:https://bugs.launchpad.net/snapcraft /+bug/1655008 From gustavo at niemeyer.net Tue Jan 10 01:35:25 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 10 Jan 2017 03:35:25 +0200 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: References: <1483903207.2507.1@mail.gandi.net> <1129d257-a0f7-a6bb-a56f-0b2117c808bf@canonical.com> <4139e5ce-0270-a621-7a3a-3c9c91a80837@canonical.com> Message-ID: This is one area that is still super confusing, and would be worth investing some time on soon. We discussed this back in May on: - clean behavior is confusing https://bugs.launchpad.net/snapcraft/+bug/1582469 As described there, this is a rock on the most important pipeline of the tool. On Mon, Jan 9, 2017 at 11:31 PM, Kyle Fazzari wrote: > On 01/09/2017 12:08 PM, Michał Sawicz wrote: > > W dniu 09.01.2017 o 20:32, Michał Sawicz pisze: > >> I *think* (may be wrong) that `snapcraft pull` can help here: > >> > >> http://snapcraft.io/docs/reference/snapcraft-command#pull > > > > I was able to force `snapcraft pull` to pull things again by messing > > with parts/part-name/state - might wanna try that in case there's no > > better answers. > > Careful with this, snapcraft tends to get upset if you mess with its > state behind its back. > > Lifecycle steps build upon each other: pull -> build -> stage -> prime. > Let's say you ran `snapcraft build A`, which will pull part A (let's say > it was commit abdc1), and then build it. If commit abcd2 is later made > and you want to build it, you need to clean the pull step (which will > also clean the build step) with `snapcraft clean A`, and build again: > `snapcraft build A`. That will pull any updates that have been made, and > build anew. > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfgoh at yahoo.com Tue Jan 10 03:32:24 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 10 Jan 2017 03:32:24 +0000 (UTC) Subject: Interface management in the context of snap in a classical Debian install In-Reply-To: <1533731758.5175031.1483432794299@mail.yahoo.com> References: <1533731758.5175031.1483432794299.ref@mail.yahoo.com> <1533731758.5175031.1483432794299@mail.yahoo.com> Message-ID: <1164710562.70967.1484019144930@mail.yahoo.com> Bumping this up again since I didnt seem to have received a reply. Was my question sufficiently clear? -- Luther On Tuesday, January 3, 2017 4:39 PM, Luther Goh Lu Feng wrote: I am considering the scenario where snap is installed in a classical Debian install. I intend to package my golang web service in a snap. The web service may have some dependencies that are present in the debian repository, but not available as a snap. Examples could be a database like influxdb, or a reverse proxy like nginx. My question is: how will the snap be interfacing with non snap software in the context of interfaces[1]? Is there an example? I understand that it will be more ideal if the dependencies are also snaps, but this may not be possible in the near future. Please advise implications and other alternative implementations. Thanks. -- Luther [1] http://snapcraft.io/docs/core/interfaces From elfgoh at yahoo.com Tue Jan 10 03:32:24 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 10 Jan 2017 03:32:24 +0000 (UTC) Subject: Interface management in the context of snap in a classical Debian install In-Reply-To: <1533731758.5175031.1483432794299@mail.yahoo.com> References: <1533731758.5175031.1483432794299.ref@mail.yahoo.com> <1533731758.5175031.1483432794299@mail.yahoo.com> Message-ID: <1164710562.70967.1484019144930@mail.yahoo.com> Bumping this up again since I didnt seem to have received a reply. Was my question sufficiently clear? -- Luther On Tuesday, January 3, 2017 4:39 PM, Luther Goh Lu Feng wrote: I am considering the scenario where snap is installed in a classical Debian install. I intend to package my golang web service in a snap. The web service may have some dependencies that are present in the debian repository, but not available as a snap. Examples could be a database like influxdb, or a reverse proxy like nginx. My question is: how will the snap be interfacing with non snap software in the context of interfaces[1]? Is there an example? I understand that it will be more ideal if the dependencies are also snaps, but this may not be possible in the near future. Please advise implications and other alternative implementations. Thanks. -- Luther [1] http://snapcraft.io/docs/core/interfaces From leo.arias at canonical.com Tue Jan 10 04:06:19 2017 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 9 Jan 2017 22:06:19 -0600 Subject: Add to repository In-Reply-To: References: Message-ID: Hello, You can package your script in a snap using snapcraft's dump plugin. And then snapcraft register and snapcraft push to get it into the store. You'll find more info in snapcraft.io, and running snapcraft -h. pura vida. From mike.pontillo at canonical.com Tue Jan 10 09:48:03 2017 From: mike.pontillo at canonical.com (Mike Pontillo) Date: Tue, 10 Jan 2017 01:48:03 -0800 Subject: netplan and post-up/pre-down scripts In-Reply-To: <20170110082316.GA1119@donald> References: <20170110082316.GA1119@donald> Message-ID: Hi Martin, Thanks for the reply. > Let me explain my use case: when an interface goes up or down, I want > to > > be able to do event-driven things with the network configuration, such as > > add or remove routes, run a DHCP client, etc. > > These two and more are already supported by networkd and NM (i. e. both of > netplan's current backends) and also in the netplan YAML itself of course. > OOI, > what is your particular use case? > I had two test cases, which I first tried implementing using 'auto' and 'dhcp' interfaces in ifupdown, then in netplan. Physical setup: two interfaces, intended to be used for routing. One to be used for a WAN interface, the other to be used for a LAN interface. Logical setup: each physical interface has an attached bridge, each containing just that one port. For example: Physical: eth0 ---> Bridge: wan0 Physical: eth1 ---> Bridge: lan0 I configured it this way because I wanted a no-hassle way to attach LXD containers and/or VMs to a physical network.[1] Now, this may have a lot to do with the fact that I'm using the bridge; the behavior I'm describing may be very different for a "pure physical" interface. But with this setup, I see 5-minute timeouts at boot when I: - Declare an 'auto' interface in 'ifupdown' which is disconnected at system boot. - Declare a 'dhcp' interface in 'ifupdown' which is disconnected at system boot. I've seen similar 5-minute timeouts occur in the field with bond interfaces whose physical links are not [all?] available. After the system booted, I then tried more tests, such as checking if routes and addresses were added or removed when I disconnected the physical link. I was also testing a redundant setup with interfaces on the same network, and a route metric in place for shortest-path selection. So I expected the higher-metric route to be used when the lower-metric interface's link went down. However, the behavior I saw was that the routes via the downed interface were marked "linkdown" in the "ip route" output, but route lookups still selected the "linkdown" route rather than switching to the higher-metric route to the same destination. (So the only option is to remove them from the kernel upon link down. Note, I don't want to configure a bond; this is for "someone accidentally, or maybe on purpose, plugged the WAN port into the LAN, or bridged the networks"; you want traffic to keep flowing in that case, and return to normal when it's fixed.) I would have to go back and test more to confirm, but I suspect some of these issues have to do with the bridge. The behavior I want is for the *bridge* to, for example, release its DHCP address, or delete its routes, if the *underlying* physical interface goes down, and bring up the DHCP client and/or static routes if the link comes back up. That way, any running containers correctly see "no route to host" ICMP messages, rather than trying to route packets to an interface whose underlying link is down. I ended up having to write the configuration in 'ifudown' with "auto" and "manual" on all the interfaces, and write a separate script (called from post-up and pre-down callouts) to monitor link status, so that I could take action on the corresponding bridge when the underlying link goes up or down. > > My first attempt to make this happen was to add `post-up` and `pre-down` > > scripts to do this. However, this had a fatal flaw for my application: > > `ifupdown` doesn't separate the concept of operational status from the > > concept of administrative status. (That is, in `ifupdown`, an interface > is > > "up" if the admin says it is up. Link up or link down does not seem to > > matter; it's strictly an /administrative/ status[3].) > > The ifup at .service (more or less) deals with hotplugging, so normally as an > admin you would not explicitly "ifup" any interface (unless you mark them > as > "manual", but then you are on your own anyway). So I fail to see the > problem > here -- for "auto" and "allow-hotplug" interfaces this should just work? > I have not used allow-hotplug, to be honest. The documentation isn't clear on how exactly it works; I'm not sure what exactly triggers the hotplug event. This might solve part of the issue, in that I want to allow booting the system even if the link is down. (Is this the officially-supported way [across all backends] to get rid of the 5-minute timeout I love to hate?) But I also want to be able to take action on link down. So I'll have to look into it more.[2] If you need this, then I suggest to use the NM backend, which gives you > /etc/network/if-up.d/. We will never use NM in confined scenarios like the > initramfs, so that should be reasonably safe. OTOH netplan itself (with > networkd) was meant to work in initrd and other early-boot scenarios where > arbitrary script callouts are not supportable. Again, this is for a router, so NetworkManager doesn't seem like a good option. For the record, I'm fine with the early-boot limitation. I just want the flexibility to both cause and solve my own problems. ;-) But at this point, maybe I'm using so little of 'ifupdown' that I might as well not configure anything, and do everything in custom scripts. But I'd hate for everyone in my situation to have to do that. Regards, Mike [1]: You could also throw in some VLANs, to add to the complexity. I have at least one, but it might not be relevant to this discussion. (I think I had a eth0.100 and was planning to create a bridge on top of that as well, to attach virtual interfaces without giving them access to every VLAN on the physical link.) This probably causes similar issues if set to 'auto'; I wonder if 'allow-hotplug' will work. [2]: So far, I think "allow-hotplug" is a little strange in that seems to blur the distinction between operational status and administrative status. (I guess you could say that the administrative status is "always up" if you have "allow-hotplug" in your /etc/network/interfaces. But what if a flaky NIC is toggling on and off rapidly, and you keep getting hotplug events? I suspect 'ifdown' would not be enough to bring the interface down permanently; you'd need to comment out the "allow-hotplug" in /e/n/i first.) Whereas, with my solution, if an interface set to "auto" and "manual" you can just "ifdown" the interface and it would go away until both: (1) "ifup " occurs, and (2) the interface link is up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Tue Jan 10 13:41:30 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 10 Jan 2017 07:41:30 -0600 Subject: snapd and semaphores In-Reply-To: References: <1483471265.3074.6.camel@canonical.com> Message-ID: <1484055690.3215.86.camel@canonical.com> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote: >  > Here is the bug report: https://launchpad.net/bugs/1653955 Thanks! The fix is in master and will bi in snapd 2.21. -- 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 ajay.pandey at einfochips.com Tue Jan 10 13:35:37 2017 From: ajay.pandey at einfochips.com (Ajay Pandey) Date: Tue, 10 Jan 2017 13:35:37 +0000 Subject: Issue with ubuntu OS snap first time boot. Message-ID: Hi All, We are facing issue with the Ubuntu OS snap first time boot console-conf. We have generated the id_rsa.pub key and put it in the launchpad.net as well as the login.ubuntu.com profiles. Please find below the error that we are getting: Profile setup Enter an email address from your account in the store. Email address: xyz at gmail.com(example) If you do not have an account, visit https://login.ubuntu.com to create one. Creating user failed: error: while creating user: cannot communicate with server: Post http://localhost/v2/create-user: EOF Contacting store... [ Done ] [ Cancel ] 40 % ************************************************************************************************************************************************************* 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 jamie at canonical.com Tue Jan 10 13:42:18 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 10 Jan 2017 07:42:18 -0600 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: <1483715554.26677.6.camel@ubuntu.com> References: <1483540756.17893.4.camel@ubuntu.com> <9099b62a-c697-976f-0cc1-9e75cc420ba6@canonical.com> <1483553517.17893.11.camel@ubuntu.com> <1483623080.18985.33.camel@ubuntu.com> <1483705133.26677.4.camel@ubuntu.com> <1483711784.8977.63.camel@canonical.com> <1483715554.26677.6.camel@ubuntu.com> Message-ID: <1484055738.3215.87.camel@canonical.com> On Fri, 2017-01-06 at 16:12 +0100, Oliver Grawert wrote: > hi, > Am Freitag, den 06.01.2017, 08:09 -0600 schrieb Jamie Strandboge: > > > >   > > > > > > if i install with --devmode from either channel, the daemon starts > > > and > > > the commands work fine though ... so seems we are close ;) > > > > > This seems like a bug in the pulseaudio interface which allows > > 'setgroups' but > > not 'setgroups32'. Can you add setgroups32 to > > /var/lib/snap/seccomp/profiles/snap.pulseaudio... then restart the > > daemon and > > see if that works for you? Can you file a bug if you haven't already? > > > adding setgroups32 led to the next missing syscall ("send") ... adding > support for send as well makes the daemon start fine then ... i filed > http://pad.lv/1654585 and assigned it to you ...  > Thanks! The fix is in master and will be in snapd 2.21. -- 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 martin.pitt at ubuntu.com Tue Jan 10 08:23:16 2017 From: martin.pitt at ubuntu.com (Martin Pitt) Date: Tue, 10 Jan 2017 09:23:16 +0100 Subject: netplan and post-up/pre-down scripts In-Reply-To: References: Message-ID: <20170110082316.GA1119@donald> Hello Mike, Mike Pontillo [2017-01-06 10:12 -0800]: > Recently, I was working on a project that led me to become frustrated > with the current state of `systemd` and `ifupdown` (e.g. > /etc/network/interfaces or /e/n/i) in Xenial. I remembered that > `netplan`[1] was under development, so I added the PPA for Xenial Note that netplan is in xenial-updates, so no PPA needed. > Let me explain my use case: when an interface goes up or down, I want to > be able to do event-driven things with the network configuration, such as > add or remove routes, run a DHCP client, etc. These two and more are already supported by networkd and NM (i. e. both of netplan's current backends) and also in the netplan YAML itself of course. OOI, what is your particular use case? > My first attempt to make this happen was to add `post-up` and `pre-down` > scripts to do this. However, this had a fatal flaw for my application: > `ifupdown` doesn't separate the concept of operational status from the > concept of administrative status. (That is, in `ifupdown`, an interface is > "up" if the admin says it is up. Link up or link down does not seem to > matter; it's strictly an /administrative/ status[3].) The ifup at .service (more or less) deals with hotplugging, so normally as an admin you would not explicitly "ifup" any interface (unless you mark them as "manual", but then you are on your own anyway). So I fail to see the problem here -- for "auto" and "allow-hotplug" interfaces this should just work? > Looking at the `netplan` spec[4], I don't see a way to achieve that > functionality Correct. NetworkManager calls /etc/network/if-up.d/ when an interface is up (same as ifupdown), but networkd doesn't, and it's not planned upstream to do that. It could be done by monitoring networkd's D-Bus signals and reacting to it, but so far there hasn't been a pressing use case for this. Many existing if-up.d/ scripts are workarounds for software which aren't written with the idea of network hotplugging in mind (e. g. not using IP_FREEBIND), and many others aren't necessary or even actively detrimental with NM/networkd as they are essentially ifupdown implementation of bridges or similar, so they must not be called with NM/networkd. > I know that many people are using the script-callout functionality in /e/n/i > to achieve what they need to achieve Actually, /etc/network/if-up.d/ has been the much more popular approach AFAIK. > In an ideal world, I think `netplan` would be able to model my use case > out-of-the-box.[5] But since we can't expect to model everyone's use case, > it seems like custom scripting functionality is a hard requirement, though > perhaps one that could have tricky cross-platform implications. If you need this, then I suggest to use the NM backend, which gives you /etc/network/if-up.d/. We will never use NM in confined scenarios like the initramfs, so that should be reasonably safe. OTOH netplan itself (with networkd) was meant to work in initrd and other early-boot scenarios where arbitrary script callouts are not supportable. If you have something particular that needs to be set/done when an interface goes up, I suggest filing a bug -- maybe that functionality even already exists in networkd/NM and just needs to be wired up to YAML? Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) From olivier.tilloy at canonical.com Tue Jan 10 13:44:04 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Tue, 10 Jan 2017 14:44:04 +0100 Subject: snapd and semaphores In-Reply-To: <1484055690.3215.86.camel@canonical.com> References: <1483471265.3074.6.camel@canonical.com> <1484055690.3215.86.camel@canonical.com> Message-ID: On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge wrote: > On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote: >> >> Here is the bug report: https://launchpad.net/bugs/1653955 > > Thanks! The fix is in master and will bi in snapd 2.21. Excellent, thanks Jamie for your prompt response! Olivier From jamie at canonical.com Tue Jan 10 15:14:09 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 10 Jan 2017 09:14:09 -0600 Subject: Interface management in the context of snap in a classical Debian install In-Reply-To: <1164710562.70967.1484019144930@mail.yahoo.com> References: <1533731758.5175031.1483432794299.ref@mail.yahoo.com> <1533731758.5175031.1483432794299@mail.yahoo.com> <1164710562.70967.1484019144930@mail.yahoo.com> Message-ID: <1484061249.3215.109.camel@canonical.com> On Tue, 2017-01-10 at 03:32 +0000, Luther Goh Lu Feng wrote: > Bumping this up again since I didnt seem to have received a reply. Was my > question sufficiently clear? > Sorry no one responded sooner. At this time, snapd on Debian[0] puts all snaps in devmode so there are far fewer restrictions place on the snap than on systems where confinement is enforced. On Debian, snaps will be able to access all files in the core snap, a few bind mounted directories from the system (like /run) and various IPC mechanisms. As such, your golang web service should be able to access services provided by debs via network IPC (eg, if influxdb opened a port on the loopback interface), DBus, abstract UNIX domain sockets, anonymous sockets, and named sockets if the named socket is in one of the system bind mounted directories (eg, /run/influxdb). On systems with full confinement, snaps run in a sandbox[1][2] that is configured by snappy interfaces[3]. This sandbox controls how the snaps interact with the system and other snaps. On these systems, your golang web service would not be able to access services provided by debs by default. Some interfaces are intended to work on traditional (aka, 'classic') systems so if there is an interface implemented in snapd for a particular service provided as a deb, then connecting that interface for the snap would give the snap access to that system service (eg, network-manager, ofono, etc). There is no interface for influxdb at the moment, so your snap would not be able to access any of its files or non- network IPC mechanisms. If influxdb listened on a network port (eg, on loopback), then your snap would be able to access this port if the 'network' interface was connected. [0]https://github.com/snapcore/snapd/wiki/Distributions#debian [1]http://snapcraft.io/docs/reference/confinement [2]https://github.com/snapcore/snapd/wiki/Security [3]https://github.com/snapcore/snapd/wiki/Interfaces > > -- Luther > > > > On Tuesday, January 3, 2017 4:39 PM, Luther Goh Lu Feng > wrote: > I am considering the scenario where snap is installed in a classical Debian > install. I intend to package my golang web service in a snap. The web service > may have some dependencies that are present in the debian repository, but not > available as a snap. Examples could be a database like influxdb, or a reverse > proxy like nginx. > > My question is: how will the snap be interfacing with non snap software in the > context of interfaces[1]? Is there an example?  > > I understand that it will be more ideal if the dependencies are also snaps, > but this may not be possible in the near future. Please advise implications > and other alternative implementations. Thanks. > > > -- Luther > [1] http://snapcraft.io/docs/core/interfaces > -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From xiaoguo.liu at canonical.com Tue Jan 10 15:28:44 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Tue, 10 Jan 2017 23:28:44 +0800 Subject: Slow snap build on Ubuntu Core device Message-ID: Hi, Currently, I am try to build armhf snap on Raspberry Pi device. I find that the build process is extremely slow, and sometimes, it shows that it will take more than 1 hour to get it down. I cannot set up the VPN on the device for now. May I know whether there is any way to change the source of the download on the board? If I build snap for x86, I can do it on desktop. I can freely choose the source/mirror of the ubuntu or set up the VPN, the speed is fine for me. However, on the ubuntu core device, it is truly slow. Attached please find the captured of the build process in the "classic" app. Thanks & best regards, XiaoGuo -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: (classic)liu-xiao-guo at localhost: ~-apps-basehttpserver_045.png Type: image/png Size: 157702 bytes Desc: not available URL: From alan.pope at canonical.com Tue Jan 10 15:40:24 2017 From: alan.pope at canonical.com (Alan Pope) Date: Tue, 10 Jan 2017 15:40:24 +0000 Subject: Slow snap build on Ubuntu Core device In-Reply-To: References: Message-ID: On 10 January 2017 at 15:28, XiaoGuo Liu wrote: > Currently, I am try to build armhf snap on Raspberry Pi device. I find that > the build process is extremely slow, and sometimes, it shows that it will > take more than 1 hour to get it down. I cannot set up the VPN on the device > for now. May I know whether there is any way to change the source of the > download on the board? > For archive packages being slow (as you have) I use apt-cacher-ng on my laptop. It caches the debs making snapcraft builds much faster. https://www.unix-ag.uni-kl.de/~bloch/acng/ Alternatively, push it to launchpad and build there? https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From elfgoh at yahoo.com Tue Jan 10 15:49:23 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 10 Jan 2017 15:49:23 +0000 (UTC) Subject: Slow snap build on Ubuntu Core device In-Reply-To: References: Message-ID: <1695694266.352232.1484063363568@mail.yahoo.com> Based on the screenshot, your download speed for the packages seems to be very slow. Perhaps you want to use a faster mirror. Maybe you can try netselect-apt as mentioned here[1]. HTH. Thanks. -- Luther [1] https://www.unixmen.com/find-fastest-mirror-debian-derivatives/ On Tuesday, January 10, 2017 11:41 PM, Alan Pope wrote: On 10 January 2017 at 15:28, XiaoGuo Liu wrote: > Currently, I am try to build armhf snap on Raspberry Pi device. I find that > the build process is extremely slow, and sometimes, it shows that it will > take more than 1 hour to get it down. I cannot set up the VPN on the device > for now. May I know whether there is any way to change the source of the > download on the board? > For archive packages being slow (as you have) I use apt-cacher-ng on my laptop. It caches the debs making snapcraft builds much faster. https://www.unix-ag.uni-kl.de/~bloch/acng/ Alternatively, push it to launchpad and build there? https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From ogra at ubuntu.com Tue Jan 10 15:55:35 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 10 Jan 2017 16:55:35 +0100 Subject: Slow snap build on Ubuntu Core device In-Reply-To: References: Message-ID: <1484063735.26677.22.camel@ubuntu.com> hi, Am Dienstag, den 10.01.2017, 15:40 +0000 schrieb Alan Pope: >  > > > For archive packages being slow (as you have) I use apt-cacher-ng on > my laptop. It caches the debs making snapcraft builds much faster. shamelessly promoting my onw snap here: sudo snap install packageproxy ... point your sources.list entries to http://localhost:9999/ubuntu-ports a nd be happy ;) 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 elfgoh at yahoo.com Tue Jan 10 16:02:03 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 10 Jan 2017 16:02:03 +0000 (UTC) Subject: Slow snap build on Ubuntu Core device In-Reply-To: <1695694266.352232.1484063363568@mail.yahoo.com> References: <1695694266.352232.1484063363568@mail.yahoo.com> Message-ID: <1454199292.354630.1484064123511@mail.yahoo.com> Oops sorry! I totally forgot that this isnt classical Ubuntu! Ignore my last message please! On Tuesday, January 10, 2017 11:49 PM, Luther Goh Lu Feng wrote: Based on the screenshot, your download speed for the packages seems to be very slow. Perhaps you want to use a faster mirror. Maybe you can try netselect-apt as mentioned here[1]. HTH. Thanks. -- Luther [1] https://www.unixmen.com/find-fastest-mirror-debian-derivatives/ On Tuesday, January 10, 2017 11:41 PM, Alan Pope wrote: On 10 January 2017 at 15:28, XiaoGuo Liu wrote: > Currently, I am try to build armhf snap on Raspberry Pi device. I find that > the build process is extremely slow, and sometimes, it shows that it will > take more than 1 hour to get it down. I cannot set up the VPN on the device > for now. May I know whether there is any way to change the source of the > download on the board? > For archive packages being slow (as you have) I use apt-cacher-ng on my laptop. It caches the debs making snapcraft builds much faster. https://www.unix-ag.uni-kl.de/~bloch/acng/ Alternatively, push it to launchpad and build there? https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From liming.wang at canonical.com Tue Jan 10 16:27:17 2017 From: liming.wang at canonical.com (Liming Wang) Date: Tue, 10 Jan 2017 16:27:17 +0000 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: <20170110162717.GD1246@mail.walimis.org> On Thu, Jan 05, 2017 at 11:05:56AM -0800, Dan Kegel wrote: >On Thu, Jan 5, 2017 at 10:50 AM, Zygmunt Krynicki > wrote: >>> has anyone tried artik 10 with ubuntu core 16, >>> and what's the story with opengl there? >> >> I don't have access to that hardware so I don't know personally. If the >> kernel and userspace contain the relevant code it should be OK in devmode. >> For confinement it is possible that some of those bits will try to access >> something that is not permitted by the base set of rules. >> >> Do you have any test code you can try? > >First off, let me say that I'm an opengl novice, I know very little about it. > >https://github.com/ubuntu/snappy-playpen/tree/master/hellogl >runs a trivial opengl app, but probably with the default >opengl, which might not be the platform's high-performance opengl. > >https://github.com/penk/oxide-eglfs-snap/tree/rpi2 is a real >app that bundles the raspberry pi's high-performance opengl >userspace driver into the snap; >that's the kind of thing I'm looking for. > >I would be impressed if someone did a single snap that >did high performance opengl on both Pi 3 and Artik 10. >Seems unlikely. Hi Dan, Yes, the ubuntu core 16 release[1] of artik10 has no support of graphics/opengl. And there was also no any experience of running opengl application on ubuntu core 16 of artik10. But that's not to say we can't support it. Actually, in artik10 linux kernel[1], there's an experimental mali driver in drivers/gpu/arm/midgard directory and also there was unofficial userspace opengl support in samsung's forum[3]. To support them, there's some work to do. > >I have a Pi but not an Artik myself, just looking around at >the other hardware Ubuntu Core supports. Did you run the oxide-eglfs-snap example on Pi? If so, do you still need other platform to run opengl on ubuntu core? Best Regards, Liming Wang 1. https://developer.ubuntu.com/core/get-started/artik-5-10 2. https://github.com/SamsungARTIK/linux-artik.git 3. https://developer.artik.io/forums/t/how-i-install-mali-midgard-in-user-space-for-using-x11/594 > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From liming.wang at canonical.com Tue Jan 10 16:27:17 2017 From: liming.wang at canonical.com (Liming Wang) Date: Tue, 10 Jan 2017 16:27:17 +0000 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: Message-ID: <20170110162717.GD1246@mail.walimis.org> On Thu, Jan 05, 2017 at 11:05:56AM -0800, Dan Kegel wrote: >On Thu, Jan 5, 2017 at 10:50 AM, Zygmunt Krynicki > wrote: >>> has anyone tried artik 10 with ubuntu core 16, >>> and what's the story with opengl there? >> >> I don't have access to that hardware so I don't know personally. If the >> kernel and userspace contain the relevant code it should be OK in devmode. >> For confinement it is possible that some of those bits will try to access >> something that is not permitted by the base set of rules. >> >> Do you have any test code you can try? > >First off, let me say that I'm an opengl novice, I know very little about it. > >https://github.com/ubuntu/snappy-playpen/tree/master/hellogl >runs a trivial opengl app, but probably with the default >opengl, which might not be the platform's high-performance opengl. > >https://github.com/penk/oxide-eglfs-snap/tree/rpi2 is a real >app that bundles the raspberry pi's high-performance opengl >userspace driver into the snap; >that's the kind of thing I'm looking for. > >I would be impressed if someone did a single snap that >did high performance opengl on both Pi 3 and Artik 10. >Seems unlikely. Hi Dan, Yes, the ubuntu core 16 release[1] of artik10 has no support of graphics/opengl. And there was also no any experience of running opengl application on ubuntu core 16 of artik10. But that's not to say we can't support it. Actually, in artik10 linux kernel[1], there's an experimental mali driver in drivers/gpu/arm/midgard directory and also there was unofficial userspace opengl support in samsung's forum[3]. To support them, there's some work to do. > >I have a Pi but not an Artik myself, just looking around at >the other hardware Ubuntu Core supports. Did you run the oxide-eglfs-snap example on Pi? If so, do you still need other platform to run opengl on ubuntu core? Best Regards, Liming Wang 1. https://developer.ubuntu.com/core/get-started/artik-5-10 2. https://github.com/SamsungARTIK/linux-artik.git 3. https://developer.artik.io/forums/t/how-i-install-mali-midgard-in-user-space-for-using-x11/594 > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From dank at kegel.com Tue Jan 10 16:36:33 2017 From: dank at kegel.com (Dan Kegel) Date: Tue, 10 Jan 2017 08:36:33 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: <20170110162717.GD1246@mail.walimis.org> References: <20170110162717.GD1246@mail.walimis.org> Message-ID: > Did you run the oxide-eglfs-snap example on Pi? If so, do you still need > other platform to run opengl on ubuntu core? Thank you for the links! The Pi is awesome as a starting point for users, but is underpowered for some of our applications. It's attractive to have a faster/fatter alternative that can run the same snaps (ok, the opengl difference would need some finesse, but it seems doable and writing a demo showing how to do it sounds like a fun project). And having a 2GB pi-compatible arm system would reduce latency for continuous integration try builds... From dank at kegel.com Tue Jan 10 16:36:33 2017 From: dank at kegel.com (Dan Kegel) Date: Tue, 10 Jan 2017 08:36:33 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: <20170110162717.GD1246@mail.walimis.org> References: <20170110162717.GD1246@mail.walimis.org> Message-ID: > Did you run the oxide-eglfs-snap example on Pi? If so, do you still need > other platform to run opengl on ubuntu core? Thank you for the links! The Pi is awesome as a starting point for users, but is underpowered for some of our applications. It's attractive to have a faster/fatter alternative that can run the same snaps (ok, the opengl difference would need some finesse, but it seems doable and writing a demo showing how to do it sounds like a fun project). And having a 2GB pi-compatible arm system would reduce latency for continuous integration try builds... From liming.wang at canonical.com Tue Jan 10 17:00:58 2017 From: liming.wang at canonical.com (Liming Wang) Date: Tue, 10 Jan 2017 17:00:58 +0000 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: <20170110170058.GE1246@mail.walimis.org> On Tue, Jan 10, 2017 at 08:36:33AM -0800, Dan Kegel wrote: >> Did you run the oxide-eglfs-snap example on Pi? If so, do you still need >> other platform to run opengl on ubuntu core? > >Thank you for the links! > >The Pi is awesome as a starting point for users, but is underpowered >for some of our applications. >It's attractive to have a faster/fatter alternative that can run the >same snaps (ok, the opengl difference would need some finesse, but it >seems doable and writing a demo showing how to do it sounds like a >fun project). > >And having a 2GB pi-compatible arm system would reduce latency for >continuous integration try builds... We did support hikey board in snappy 15.04, but also without opengl. But I think hikey is a suitable platform if we continue to support ubuntu core 16 on it. Because there are lots of resources for this hardware. I heard someone is doing the job to support ubuntu core 16 on hikey, but I don't know what's the progress now. Best Regards, Liming Wang > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From liming.wang at canonical.com Tue Jan 10 17:00:58 2017 From: liming.wang at canonical.com (Liming Wang) Date: Tue, 10 Jan 2017 17:00:58 +0000 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: <20170110170058.GE1246@mail.walimis.org> On Tue, Jan 10, 2017 at 08:36:33AM -0800, Dan Kegel wrote: >> Did you run the oxide-eglfs-snap example on Pi? If so, do you still need >> other platform to run opengl on ubuntu core? > >Thank you for the links! > >The Pi is awesome as a starting point for users, but is underpowered >for some of our applications. >It's attractive to have a faster/fatter alternative that can run the >same snaps (ok, the opengl difference would need some finesse, but it >seems doable and writing a demo showing how to do it sounds like a >fun project). > >And having a 2GB pi-compatible arm system would reduce latency for >continuous integration try builds... We did support hikey board in snappy 15.04, but also without opengl. But I think hikey is a suitable platform if we continue to support ubuntu core 16 on it. Because there are lots of resources for this hardware. I heard someone is doing the job to support ubuntu core 16 on hikey, but I don't know what's the progress now. Best Regards, Liming Wang > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From jin.hsieh at canonical.com Tue Jan 10 17:16:34 2017 From: jin.hsieh at canonical.com (Jin Hsieh) Date: Wed, 11 Jan 2017 01:16:34 +0800 Subject: To handle the absolute path in compiling time Message-ID: Hello All, We are trying to snap up a mail server, by referring to the design of a popular solution, there are several services need to be packaged as parts. The major one is the postfix, it uses an install script to deploy the built binary, libraries and the configuration files, the problem here is it assigns an absolute path when installing: https://github.com/jindallo/postfix/blob/master/postfix-install#L446 it's a trouble in snap world since my goal is pushing them into $SNAP properly, however, in the Build phase of my parts it does not know the path $SNAP. I tried to deploy it by stage-packages directly but no luck for such the complicated service, the configuration path is hardcoded on the pre-compiled binary. https://github.com/jindallo/iredmail-snap/blob/master/snapcraft.yaml Besides give the postfix source a hack to do getenv for $SNAP in compiling, do you guys have any idea or any tricks on this to make it works could share with us? Many thanks. BR. Jin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mhall119 at ubuntu.com Tue Jan 10 17:20:50 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Tue, 10 Jan 2017 12:20:50 -0500 Subject: To handle the absolute path in compiling time In-Reply-To: References: Message-ID: You can use /snap//current/ instead of $SNAP. At least from inside the snap's runtime environment that should always point to the current install base. It's not ideal, but it's at least a predictable path you know at build time. Michael Hall mhall119 at ubuntu.com On 01/10/2017 12:16 PM, Jin Hsieh wrote: > Hello All, > > We are trying to snap up a mail server, > by referring to the design of a popular solution, > there are several services need to be packaged as parts. > > The major one is the postfix, > it uses an install script to deploy the built binary, > libraries and the configuration files, > the problem here is it assigns an absolute path when installing: > https://github.com/jindallo/postfix/blob/master/postfix-install#L446 > it's a trouble in snap world since my goal is pushing them into $SNAP > properly, > however, in the Build phase of my parts it does not know the path $SNAP. > > I tried to deploy it by stage-packages directly but no luck for such the > complicated service, > the configuration path is hardcoded on the pre-compiled binary. > https://github.com/jindallo/iredmail-snap/blob/master/snapcraft.yaml > Besides give the postfix source a hack to do getenv for $SNAP in compiling, > do you guys have any idea or any tricks on this to make it works could > share with us? > > Many thanks. > > BR. > Jin > > From kevin.gunn at canonical.com Tue Jan 10 17:35:12 2017 From: kevin.gunn at canonical.com (Kevin Gunn) Date: Tue, 10 Jan 2017 11:35:12 -0600 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: Hey Dan - I'm not certain what your use case is, but seems your open to considering other hw. In which case, I might point out we've done a little bit with our ubuntu graphics stack on top of dragonboard with quite a bit of ease. There's a variety of Qt examples [1], webbrowser [2] and even kodi [3]. If you try these out and have any issues please do let me know. br,kg [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6 [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9 On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel wrote: > > Did you run the oxide-eglfs-snap example on Pi? If so, do you still need > > other platform to run opengl on ubuntu core? > > Thank you for the links! > > The Pi is awesome as a starting point for users, but is underpowered > for some of our applications. > It's attractive to have a faster/fatter alternative that can run the > same snaps (ok, the opengl difference would need some finesse, but it > seems doable and writing a demo showing how to do it sounds like a > fun project). > > And having a 2GB pi-compatible arm system would reduce latency for > continuous integration try builds... > > -- > 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 kevin.gunn at canonical.com Tue Jan 10 17:35:12 2017 From: kevin.gunn at canonical.com (Kevin Gunn) Date: Tue, 10 Jan 2017 11:35:12 -0600 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: Hey Dan - I'm not certain what your use case is, but seems your open to considering other hw. In which case, I might point out we've done a little bit with our ubuntu graphics stack on top of dragonboard with quite a bit of ease. There's a variety of Qt examples [1], webbrowser [2] and even kodi [3]. If you try these out and have any issues please do let me know. br,kg [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6 [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9 On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel wrote: > > Did you run the oxide-eglfs-snap example on Pi? If so, do you still need > > other platform to run opengl on ubuntu core? > > Thank you for the links! > > The Pi is awesome as a starting point for users, but is underpowered > for some of our applications. > It's attractive to have a faster/fatter alternative that can run the > same snaps (ok, the opengl difference would need some finesse, but it > seems doable and writing a demo showing how to do it sounds like a > fun project). > > And having a 2GB pi-compatible arm system would reduce latency for > continuous integration try builds... > > -- > 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 dank at kegel.com Tue Jan 10 18:04:21 2017 From: dank at kegel.com (Dan Kegel) Date: Tue, 10 Jan 2017 10:04:21 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: Hi Kevin, having a preview of the mir stack is attractive. Would that mean snaps that use opengl would not need to carry the boards' opengl library? dragonboard would do for undemanding apps, but it's only 1GB and 30fps HD video. Is there a 2GB RAM + faster GPU board that can do 60fps HD video and use same snaps? On Tue, Jan 10, 2017 at 9:35 AM, Kevin Gunn wrote: > Hey Dan - > I'm not certain what your use case is, but seems your open to considering > other hw. > In which case, I might point out we've done a little bit with our ubuntu > graphics stack on top of dragonboard with quite a bit of ease. There's a > variety of Qt examples [1], webbrowser [2] and even kodi [3]. > If you try these out and have any issues please do let me know. > > br,kg > > [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ > [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6 > [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9 > > > On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel wrote: >> >> > Did you run the oxide-eglfs-snap example on Pi? If so, do you still need >> > other platform to run opengl on ubuntu core? >> >> Thank you for the links! >> >> The Pi is awesome as a starting point for users, but is underpowered >> for some of our applications. >> It's attractive to have a faster/fatter alternative that can run the >> same snaps (ok, the opengl difference would need some finesse, but it >> seems doable and writing a demo showing how to do it sounds like a >> fun project). >> >> And having a 2GB pi-compatible arm system would reduce latency for >> continuous integration try builds... >> >> -- >> 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 dank at kegel.com Tue Jan 10 18:04:21 2017 From: dank at kegel.com (Dan Kegel) Date: Tue, 10 Jan 2017 10:04:21 -0800 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: Hi Kevin, having a preview of the mir stack is attractive. Would that mean snaps that use opengl would not need to carry the boards' opengl library? dragonboard would do for undemanding apps, but it's only 1GB and 30fps HD video. Is there a 2GB RAM + faster GPU board that can do 60fps HD video and use same snaps? On Tue, Jan 10, 2017 at 9:35 AM, Kevin Gunn wrote: > Hey Dan - > I'm not certain what your use case is, but seems your open to considering > other hw. > In which case, I might point out we've done a little bit with our ubuntu > graphics stack on top of dragonboard with quite a bit of ease. There's a > variety of Qt examples [1], webbrowser [2] and even kodi [3]. > If you try these out and have any issues please do let me know. > > br,kg > > [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ > [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6 > [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9 > > > On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel wrote: >> >> > Did you run the oxide-eglfs-snap example on Pi? If so, do you still need >> > other platform to run opengl on ubuntu core? >> >> Thank you for the links! >> >> The Pi is awesome as a starting point for users, but is underpowered >> for some of our applications. >> It's attractive to have a faster/fatter alternative that can run the >> same snaps (ok, the opengl difference would need some finesse, but it >> seems doable and writing a demo showing how to do it sounds like a >> fun project). >> >> And having a 2GB pi-compatible arm system would reduce latency for >> continuous integration try builds... >> >> -- >> 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 kevin.gunn at canonical.com Tue Jan 10 20:46:25 2017 From: kevin.gunn at canonical.com (Kevin Gunn) Date: Tue, 10 Jan 2017 14:46:25 -0600 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: On Tue, Jan 10, 2017 at 12:04 PM, Dan Kegel wrote: > Hi Kevin, > having a preview of the mir stack is attractive. > Would that mean snaps that use opengl would not need to carry the > boards' opengl library? > correct, the snaps rely on the gl drivers provided by the system. > > dragonboard would do for undemanding apps, but it's only 1GB and 30fps HD > video. > Is there a 2GB RAM + faster GPU board that can do 60fps HD video and > use same snaps? > as for embedded type boards, not that we've currently worked on directly. but any board having open kms/drm graphics should easily work - so any intel boards would/should work easily. perhaps someone else from the community could speak up if they've played with something meeting your description. > > On Tue, Jan 10, 2017 at 9:35 AM, Kevin Gunn > wrote: > > Hey Dan - > > I'm not certain what your use case is, but seems your open to considering > > other hw. > > In which case, I might point out we've done a little bit with our ubuntu > > graphics stack on top of dragonboard with quite a bit of ease. There's a > > variety of Qt examples [1], webbrowser [2] and even kodi [3]. > > If you try these out and have any issues please do let me know. > > > > br,kg > > > > [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ > > [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6 > > [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9 > > > > > > On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel wrote: > >> > >> > Did you run the oxide-eglfs-snap example on Pi? If so, do you still > need > >> > other platform to run opengl on ubuntu core? > >> > >> Thank you for the links! > >> > >> The Pi is awesome as a starting point for users, but is underpowered > >> for some of our applications. > >> It's attractive to have a faster/fatter alternative that can run the > >> same snaps (ok, the opengl difference would need some finesse, but it > >> seems doable and writing a demo showing how to do it sounds like a > >> fun project). > >> > >> And having a 2GB pi-compatible arm system would reduce latency for > >> continuous integration try builds... > >> > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.gunn at canonical.com Tue Jan 10 20:46:25 2017 From: kevin.gunn at canonical.com (Kevin Gunn) Date: Tue, 10 Jan 2017 14:46:25 -0600 Subject: opengl on ubuntu core 16 on artik 10? In-Reply-To: References: <20170110162717.GD1246@mail.walimis.org> Message-ID: On Tue, Jan 10, 2017 at 12:04 PM, Dan Kegel wrote: > Hi Kevin, > having a preview of the mir stack is attractive. > Would that mean snaps that use opengl would not need to carry the > boards' opengl library? > correct, the snaps rely on the gl drivers provided by the system. > > dragonboard would do for undemanding apps, but it's only 1GB and 30fps HD > video. > Is there a 2GB RAM + faster GPU board that can do 60fps HD video and > use same snaps? > as for embedded type boards, not that we've currently worked on directly. but any board having open kms/drm graphics should easily work - so any intel boards would/should work easily. perhaps someone else from the community could speak up if they've played with something meeting your description. > > On Tue, Jan 10, 2017 at 9:35 AM, Kevin Gunn > wrote: > > Hey Dan - > > I'm not certain what your use case is, but seems your open to considering > > other hw. > > In which case, I might point out we've done a little bit with our ubuntu > > graphics stack on top of dragonboard with quite a bit of ease. There's a > > variety of Qt examples [1], webbrowser [2] and even kodi [3]. > > If you try these out and have any issues please do let me know. > > > > br,kg > > > > [1] https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ > > [2] https://plus.google.com/+KevinGunnCanonical/posts/KPfVvfTU3f6 > > [3] https://plus.google.com/+KevinGunnCanonical/posts/3SDJjqCz3S9 > > > > > > On Tue, Jan 10, 2017 at 10:36 AM, Dan Kegel wrote: > >> > >> > Did you run the oxide-eglfs-snap example on Pi? If so, do you still > need > >> > other platform to run opengl on ubuntu core? > >> > >> Thank you for the links! > >> > >> The Pi is awesome as a starting point for users, but is underpowered > >> for some of our applications. > >> It's attractive to have a faster/fatter alternative that can run the > >> same snaps (ok, the opengl difference would need some finesse, but it > >> seems doable and writing a demo showing how to do it sounds like a > >> fun project). > >> > >> And having a 2GB pi-compatible arm system would reduce latency for > >> continuous integration try builds... > >> > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.ehrhardt at canonical.com Wed Jan 11 06:24:08 2017 From: christian.ehrhardt at canonical.com (Christian Ehrhardt) Date: Wed, 11 Jan 2017 08:24:08 +0200 Subject: snapd 2.20 release available in {xenial,yakkety}-updates In-Reply-To: <20170106084847.GI15361@bod> References: <20170105221300.GA16549@bod> <20170106084847.GI15361@bod> Message-ID: On Fri, Jan 6, 2017 at 10:48 AM, Michael Vogt wrote: > > Can you say a few words about classic confinement? I didn't see doc... > > Thanks for this reminder, I should have included the link that David > provided to http://snapcraft.io/docs/reference/confinement > > In a nutshell classic make it very easy to provide snaps for > traditional (classic) distributions like Ubuntu 16.04. It is currently > not quite as polished as we would like it to be (we are actively > working on fixing that!) but I think its a really nice feature. Even being subscribed I missed the importance of this when it came around a few days ago. Since now there is also this insights post about it - it might be worth to "ping" the thread once more. See: https://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/ -- Christian Ehrhardt Software Engineer, Ubuntu Server Canonical Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Wed Jan 11 07:07:29 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 11 Jan 2017 09:07:29 +0200 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: References: Message-ID: Hi Ajay, That means the communication with the local snapd daemon failed abruptly, which is unusual. Can you tell us a bit more about the environment this is running on, and which image it is? Do you have access to the underlying filesystem somehow (is it an SD card? VM?), in which case can you send us the /var/log content? Thanks, and sorry you're having trouble there. On Tue, Jan 10, 2017 at 3:35 PM, Ajay Pandey wrote: > Hi All, > > > > We are facing issue with the Ubuntu OS snap first time boot console-conf. > > > > We have generated the id_rsa.pub key and put it in the launchpad.net as > well as the login.ubuntu.com profiles. > > > > Please find below the error that we are getting: > > > > > > > > > > > > > > > > > > > > > > > > *Profile setup > Enter an email address from your account in the store. > Email address: xyz at gmail.com > (example) If you do not have an > account, visit https://login.ubuntu.com > to create one. > Creating user failed: > error: while creating user: cannot communicate with server: > Post http://localhost/v2/create-user > : EOF > > Contacting > store... [ > Done ] [ Cancel ] > 40 %* > ************************************************************ > ************************************************************ > ************************************* 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 > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Wed Jan 11 07:16:49 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Wed, 11 Jan 2017 07:16:49 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: Message-ID: <20170111071649.omr65dkuxylolgpk@golstein> Hi Jenny, On 09/01/17 at 10:28am, Jenny Murphy wrote: > Hi, > My query is related to a few of the recent discussions regarding versions, > releases and updates/ > > I currently have a Snappy Ubuntu system as follows : > > snap --version gives the following result : > snap 2.18.1 > snapd 2.18.1 > series 16 > > more /etc/lsb-release yeilds : > DISTRIB_ID="Ubuntu Core" > DISTRIB_RELEASE=16 > DISTRIB_DESCRIPTION="Ubuntu Core 16 > > And finally snap list yields : > core 16.04.1 641 canonical -- > > I don't see to be getting any automatic updates which I don't mind about > as long as I could manually update. > > So just a few questions : > > 1. How can I update snap and snapd What happens when you type: $ snap info core Also, what happens when you type: $ snap refresh > 2. Is snap the front end to snapd ? Do they get updated together? Yes. > 3. Can I update snapd and not update ubuntu-core and core. On an Ubuntu Core system snapd is integral to the device, on a classic system snapd is an add-on package so in the former case the system and snapd are updated together. > 4. Should ubuntu-core and core be updated together also? From the previous > reply on this topic, it seems core is the framework and ubuntu-core is the > filesystem or is it vice versa? ubuntu-core is the old name for core. We renamed this to better reflect that other cores could be available that are not Ubuntu based. Do you have both of these installed on your system? In fact, can you give us a full output of: $ snap list > I know there are a lot of questions here but it is just a little bit > unclear to me at the moment. Maybe there are also some other users in the > same position. > > > Thanks, > Jenny > > > > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 w | http://www.episensor.com > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From ribalkin at gmail.com Wed Jan 11 09:06:05 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Wed, 11 Jan 2017 09:06:05 +0000 Subject: Snapd free space available check In-Reply-To: References: Message-ID: Done https://github.com/snapcore/snapd/issues/2603 On 9 Jan 2017 13:57, "Zygmunt Krynicki" wrote: > I don't think we're doing this yet. > > > Can you please report an issue so that it can be tracked. > > Best regards > ZK > > On Sun, Jan 8, 2017 at 6:25 PM, Boris Rybalkin wrote: > >> Hello, >> >> Could you tell me if snapd does any free space check before installing a >> snap? >> >> Github link would be ideal if possible. >> >> Thank you. >> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Wed Jan 11 09:30:07 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 11 Jan 2017 11:30:07 +0200 Subject: Slow snap build on Ubuntu Core device In-Reply-To: <1484063735.26677.22.camel@ubuntu.com> References: <1484063735.26677.22.camel@ubuntu.com> Message-ID: Nice :) On Tue, Jan 10, 2017 at 5:55 PM, Oliver Grawert wrote: > hi, > Am Dienstag, den 10.01.2017, 15:40 +0000 schrieb Alan Pope: > > > > > > > For archive packages being slow (as you have) I use apt-cacher-ng on > > my laptop. It caches the debs making snapcraft builds much faster. > > shamelessly promoting my onw snap here: > > sudo snap install packageproxy ... > > point your sources.list entries to http://localhost:9999/ubuntu-ports a > nd be happy ;) > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.rogovsky at gmail.com Wed Jan 11 09:34:24 2017 From: a.rogovsky at gmail.com (Andrey Rogovsky) Date: Wed, 11 Jan 2017 11:34:24 +0200 Subject: Bad system call - 45 for my binary app Message-ID: Hi, all! I crafted snap for i386 X11 app (no sources) which work success on amd64 arch in development mode. But when I install it in strict mode - got this error: = Seccomp = Time: Jan 11 11:26:38 Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=17988 comm="BlueQuest" exe="/snap/bluequest/x1/usr/bin/BlueQuest" sig=31 arch=40000003 45(brk) compat=1 ip=0xf7749547 code=0x0 Syscall: brk How I can resolve this problem? This is my snapcraft file: name: bluequest version: 1.0 summary: Game description: Play Blue Quest Game. icon: BlueQuest/assets/icon.png grade: stable confinement: strict apps: bluequest: command: usr/bin/bluequest plugs: [network, network-bindx11, home, unity7, pulseaudio] parts: bluequest: plugin: dump source: BlueQuest organize: bluequest: usr/bin/bluequest BlueQuest: usr/bin/BlueQuest usrlib32: plugin: dump source: /usr/lib/i386-linux-gnu syslib32: plugin: dump source: /lib/i386-linux-gnu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenny.murphy at episensor.com Wed Jan 11 09:39:31 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Wed, 11 Jan 2017 09:39:31 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: <20170111071649.omr65dkuxylolgpk@golstein> References: <20170111071649.omr65dkuxylolgpk@golstein> Message-ID: Hi Jamie, Here is some more information as requested : admin at localhost:~$ snap info core name: core summary: "snapd runtime environment" publisher: canonical description: | The core runtime environment for snapd type: core tracking: stable installed: 16.04.1 (714) 79MB - refreshed: 2016-12-16 04:28:38 +0000 UTC channels: stable: 16.04.1 (714) 0B - candidate: 16.04.1 (714) 0B - beta: 16.04.1 (714) 0B - edge: 16.04.1 (870) 0B - admin at localhost:~$ snap refresh error: cannot refresh []: cannot refresh snap-declaration for "stlouis-kernel": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJxDUHag?max-format=1: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) admin at localhost:~$ snap list Name Version Rev Developer Notes bluez 5.37-2 15 canonical - core 16.04.1 714 canonical - gateway 2.0 x3 devmode modem-manager 1.4.0-1 14 canonical - network-manager 1.2.2-10 73 canonical - snappy-debug 0.26 25 canonical - snapweb 0.21.2 24 canonical - stlouis 16.04-1.13 11 canonical - stlouis-kernel 4.4.0-57-1 7 canonical - tpm2 1.0-2.1 12 canonical - uefi-fw-tools 1.2-0.7.2+git 2 canonical - snapcraft at lists.snapcraft.io On 11 January 2017 at 07:16, Jamie Bennett wrote: > Hi Jenny, > > On 09/01/17 at 10:28am, Jenny Murphy wrote: > > Hi, > > My query is related to a few of the recent discussions regarding > versions, > > releases and updates/ > > > > I currently have a Snappy Ubuntu system as follows : > > > > snap --version gives the following result : > > snap 2.18.1 > > snapd 2.18.1 > > series 16 > > > > more /etc/lsb-release yeilds : > > DISTRIB_ID="Ubuntu Core" > > DISTRIB_RELEASE=16 > > DISTRIB_DESCRIPTION="Ubuntu Core 16 > > > > And finally snap list yields : > > core 16.04.1 641 canonical -- > > > > I don't see to be getting any automatic updates which I don't mind about > > as long as I could manually update. > > > > So just a few questions : > > > > 1. How can I update snap and snapd > > What happens when you type: > > $ snap info core > > Also, what happens when you type: > > $ snap refresh > > > 2. Is snap the front end to snapd ? Do they get updated together? > > Yes. > > > 3. Can I update snapd and not update ubuntu-core and core. > > On an Ubuntu Core system snapd is integral to the device, on a classic > system > snapd is an add-on package so in the former case the system and snapd are > updated together. > > > 4. Should ubuntu-core and core be updated together also? From the > previous > > reply on this topic, it seems core is the framework and ubuntu-core is > the > > filesystem or is it vice versa? > > ubuntu-core is the old name for core. We renamed this to better reflect > that > other cores could be available that are not Ubuntu based. Do you have both > of > these installed on your system? In fact, can you give us a full output of: > > $ snap list > > > I know there are a lot of questions here but it is just a little bit > >sn unclear to me at the moment. Maybe there are also some other users in > the > > same position. > > > > > > Thanks, > > Jenny > > > > > > > > *Jenny Murphy* > > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > > jenny.murphy at episensor.com t | +353 (0) 61 > > 512 511 w | http://www.episensor.com > > > -- > > 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 > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Jan 11 10:18:56 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 11 Jan 2017 11:18:56 +0100 Subject: Issue with ubuntu OS snap first time boot. In-Reply-To: References: Message-ID: <1484129936.26677.30.camel@ubuntu.com> hi, Am Dienstag, den 10.01.2017, 13:35 +0000 schrieb Ajay Pandey: > Hi All, >   > We are facing issue with the Ubuntu OS snap first time boot console- > conf. >   ...                    >         error: while creating user: cannot communicate with server: > Post     >                       http://localhost/v2/create-user: > EOF                   is this on one of the official images or is it your own build ?  looks like snapd did not start properly. 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 manik at canonical.com Wed Jan 11 10:21:37 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 11 Jan 2017 12:21:37 +0200 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: <20170111071649.omr65dkuxylolgpk@golstein> Message-ID: Hi Jenny, Welcome to Ubuntu Core. I see that you are experiencing a timeout while retrieving assertions. We have added additional redundancy to the client in a later revision (2.20) of snapd. While we await for 2.20 to move into the stable channel, can I request that you manually upgrade to the edge channel using- snap refresh core --edge snap --version snap list Once the refresh succedes, than please try the snap refresh command to make sure that all snaps are updated to the latest. If you still experience similar issues, please let us know. For reference, here's a screenshot of the cmd usage- [image: Inline image 1] Regards, Manik On Wed, Jan 11, 2017 at 11:39 AM, Jenny Murphy wrote: > Hi Jamie, > Here is some more information as requested : > > admin at localhost:~$ snap info core > name: core > summary: "snapd runtime environment" > publisher: canonical > description: | > The core runtime environment for snapd > type: core > tracking: stable > installed: 16.04.1 (714) 79MB - > refreshed: 2016-12-16 04:28:38 +0000 UTC > channels: > stable: 16.04.1 (714) 0B - > candidate: 16.04.1 (714) 0B - > beta: 16.04.1 (714) 0B - > edge: 16.04.1 (870) 0B - > > admin at localhost:~$ snap refresh > error: cannot refresh []: cannot refresh snap-declaration for > "stlouis-kernel": Get https://assertions.ubuntu.com/v1/assertions/snap- > declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJxDUHag?max-format=1: net/http: > request canceled while waiting for connection (Client.Timeout exceeded > while awaiting headers) > > admin at localhost:~$ snap list > Name Version Rev Developer Notes > bluez 5.37-2 15 canonical - > core 16.04.1 714 canonical - > gateway 2.0 x3 devmode > modem-manager 1.4.0-1 14 canonical - > network-manager 1.2.2-10 73 canonical - > snappy-debug 0.26 25 canonical - > snapweb 0.21.2 24 canonical - > stlouis 16.04-1.13 11 canonical - > stlouis-kernel 4.4.0-57-1 7 canonical - > tpm2 1.0-2.1 12 canonical - > uefi-fw-tools 1.2-0.7.2+git 2 canonical - > > > snapcraft at lists.snapcraft.io > On 11 January 2017 at 07:16, Jamie Bennett > wrote: > >> Hi Jenny, >> >> On 09/01/17 at 10:28am, Jenny Murphy wrote: >> > Hi, >> > My query is related to a few of the recent discussions regarding >> versions, >> > releases and updates/ >> > >> > I currently have a Snappy Ubuntu system as follows : >> > >> > snap --version gives the following result : >> > snap 2.18.1 >> > snapd 2.18.1 >> > series 16 >> > >> > more /etc/lsb-release yeilds : >> > DISTRIB_ID="Ubuntu Core" >> > DISTRIB_RELEASE=16 >> > DISTRIB_DESCRIPTION="Ubuntu Core 16 >> > >> > And finally snap list yields : >> > core 16.04.1 641 canonical -- >> > >> > I don't see to be getting any automatic updates which I don't mind >> about >> > as long as I could manually update. >> > >> > So just a few questions : >> > >> > 1. How can I update snap and snapd >> >> What happens when you type: >> >> $ snap info core >> >> Also, what happens when you type: >> >> $ snap refresh >> >> > 2. Is snap the front end to snapd ? Do they get updated together? >> >> Yes. >> >> > 3. Can I update snapd and not update ubuntu-core and core. >> >> On an Ubuntu Core system snapd is integral to the device, on a classic >> system >> snapd is an add-on package so in the former case the system and snapd are >> updated together. >> >> > 4. Should ubuntu-core and core be updated together also? From the >> previous >> > reply on this topic, it seems core is the framework and ubuntu-core is >> the >> > filesystem or is it vice versa? >> >> ubuntu-core is the old name for core. We renamed this to better reflect >> that >> other cores could be available that are not Ubuntu based. Do you have >> both of >> these installed on your system? In fact, can you give us a full output of: >> >> $ snap list >> >> > I know there are a lot of questions here but it is just a little bit >> >sn unclear to me at the moment. Maybe there are also some other users in >> the >> > same position. >> > >> > >> > Thanks, >> > Jenny >> > >> > >> > >> > *Jenny Murphy* >> > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >> > jenny.murphy at episensor.com t | +353 (0) >> 61 >> > 512 511 w | http://www.episensor.com >> >> > -- >> > 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/mailm >> an/listinfo/snapcraft >> > > > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 <+353%2061%20512%20511> w | http://www.episensor.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 199646 bytes Desc: not available URL: From jenny.murphy at episensor.com Wed Jan 11 11:26:14 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Wed, 11 Jan 2017 11:26:14 +0000 Subject: Use of build-properties in the schema is deprecated. Message-ID: I recently upgraded to snapcraft 2.24 (from 2.22) for building my .snaps. Now I am getting the following warning : Use of build-properties in the schema is deprecated. Plugins should now implement get_build_properties This is my yaml file : name: gateway version: '2.0' # just for humans, typically '1.2+git' or '1.3.2' summary: EpiSensor IIoT Gateway Application # 79 char long summary description: This is a Java application with web interface and a RESTful API. grade: devel # must be 'stable' to release into candidate/stable channels confinement: devmode # use 'strict' once you have the right plugs and slots icon: epi-icon-256x256px.png apps: main: command: bin/wrapper daemon: simple plugs: [zap-plug] plugs: zap-plug: interface: serial-port parts: move-lib: plugin: dump source: ./lib/ organize: "*": lib/ move-ext-lib: plugin: dump source: ./ext-lib/ organize: "*": ext-lib/ move-webapp: plugin: dump source: ./webapp/ organize: "*": webapp/ move-config: plugin: dump source: ./config/ organize: "*": config/ move-scripts: plugin: dump source: ./scripts/ organize: "*": scripts/ main: plugin: ant source: . wrapper: plugin: make source: . move-rxtx: after: [move-ext-lib] plugin: dump source: ./rxtx organize: RXTXcomm.jar: ext-lib/RXTXcomm.jar librxtxSerial.so: usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/librxtxSerial.so Any ideas as to why this has changed? -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenny.murphy at episensor.com Wed Jan 11 11:38:41 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Wed, 11 Jan 2017 11:38:41 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: <20170111071649.omr65dkuxylolgpk@golstein> Message-ID: Hi, This is the error I get after step 1: admin at localhost:~$ snap refresh core --edge error: cannot refresh "core": cannot refresh "core" to revision 870: no validation by "stlouis" On 11 January 2017 at 10:21, Manik Taneja wrote: > Hi Jenny, > > Welcome to Ubuntu Core. I see that you are experiencing a timeout while > retrieving assertions. We have added additional redundancy to the client in > a later revision (2.20) of snapd. While we await for 2.20 to move into the > stable channel, can I request that you manually upgrade to the edge channel > using- > > snap refresh core --edge > snap --version > snap list > > Once the refresh succedes, than please try the snap refresh command to > make sure that all snaps are updated to the latest. If you still experience > similar issues, please let us know. For reference, here's a screenshot of > the cmd usage- > > [image: Inline image 1] > > Regards, > Manik > > On Wed, Jan 11, 2017 at 11:39 AM, Jenny Murphy > wrote: > >> Hi Jamie, >> Here is some more information as requested : >> >> admin at localhost:~$ snap info core >> name: core >> summary: "snapd runtime environment" >> publisher: canonical >> description: | >> The core runtime environment for snapd >> type: core >> tracking: stable >> installed: 16.04.1 (714) 79MB - >> refreshed: 2016-12-16 04:28:38 +0000 UTC >> channels: >> stable: 16.04.1 (714) 0B - >> candidate: 16.04.1 (714) 0B - >> beta: 16.04.1 (714) 0B - >> edge: 16.04.1 (870) 0B - >> >> admin at localhost:~$ snap refresh >> error: cannot refresh []: cannot refresh snap-declaration for >> "stlouis-kernel": Get https://assertions.ubuntu.com/ >> v1/assertions/snap-declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJ >> xDUHag?max-format=1: net/http: request canceled while waiting for >> connection (Client.Timeout exceeded while awaiting headers) >> >> admin at localhost:~$ snap list >> Name Version Rev Developer Notes >> bluez 5.37-2 15 canonical - >> core 16.04.1 714 canonical - >> gateway 2.0 x3 devmode >> modem-manager 1.4.0-1 14 canonical - >> network-manager 1.2.2-10 73 canonical - >> snappy-debug 0.26 25 canonical - >> snapweb 0.21.2 24 canonical - >> stlouis 16.04-1.13 11 canonical - >> stlouis-kernel 4.4.0-57-1 7 canonical - >> tpm2 1.0-2.1 12 canonical - >> uefi-fw-tools 1.2-0.7.2+git 2 canonical - >> >> >> snapcraft at lists.snapcraft.io >> On 11 January 2017 at 07:16, Jamie Bennett >> wrote: >> >>> Hi Jenny, >>> >>> On 09/01/17 at 10:28am, Jenny Murphy wrote: >>> > Hi, >>> > My query is related to a few of the recent discussions regarding >>> versions, >>> > releases and updates/ >>> > >>> > I currently have a Snappy Ubuntu system as follows : >>> > >>> > snap --version gives the following result : >>> > snap 2.18.1 >>> > snapd 2.18.1 >>> > series 16 >>> > >>> > more /etc/lsb-release yeilds : >>> > DISTRIB_ID="Ubuntu Core" >>> > DISTRIB_RELEASE=16 >>> > DISTRIB_DESCRIPTION="Ubuntu Core 16 >>> > >>> > And finally snap list yields : >>> > core 16.04.1 641 canonical -- >>> > >>> > I don't see to be getting any automatic updates which I don't mind >>> about >>> > as long as I could manually update. >>> > >>> > So just a few questions : >>> > >>> > 1. How can I update snap and snapd >>> >>> What happens when you type: >>> >>> $ snap info core >>> >>> Also, what happens when you type: >>> >>> $ snap refresh >>> >>> > 2. Is snap the front end to snapd ? Do they get updated together? >>> >>> Yes. >>> >>> > 3. Can I update snapd and not update ubuntu-core and core. >>> >>> On an Ubuntu Core system snapd is integral to the device, on a classic >>> system >>> snapd is an add-on package so in the former case the system and snapd are >>> updated together. >>> >>> > 4. Should ubuntu-core and core be updated together also? From the >>> previous >>> > reply on this topic, it seems core is the framework and ubuntu-core is >>> the >>> > filesystem or is it vice versa? >>> >>> ubuntu-core is the old name for core. We renamed this to better reflect >>> that >>> other cores could be available that are not Ubuntu based. Do you have >>> both of >>> these installed on your system? In fact, can you give us a full output >>> of: >>> >>> $ snap list >>> >>> > I know there are a lot of questions here but it is just a little bit >>> >sn unclear to me at the moment. Maybe there are also some other users >>> in the >>> > same position. >>> > >>> > >>> > Thanks, >>> > Jenny >>> > >>> > >>> > >>> > *Jenny Murphy* >>> > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>> > jenny.murphy at episensor.com t | +353 (0) >>> 61 >>> > 512 511 w | http://www.episensor.com >>> >>> > -- >>> > 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/mailm >>> an/listinfo/snapcraft >>> >> >> >> >> -- >> *Jenny Murphy* >> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >> jenny.murphy at episensor.com t | +353 (0) 61 >> 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 199646 bytes Desc: not available URL: From jamie.bennett at canonical.com Wed Jan 11 11:54:18 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Wed, 11 Jan 2017 13:54:18 +0200 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: <20170111071649.omr65dkuxylolgpk@golstein> Message-ID: <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> Hi Jenny, The lack of update is due to the platform you are using: St Louis. It looks like the team responsible for St Louis updates has not fully validated the new Ubuntu Core software which is why you haven't seen an update yet. I suspect that an update is forthcoming soon. Regards, Jamie. > On 11 Jan 2017, at 13:38, Jenny Murphy wrote: > > Hi, > This is the error I get after step 1: > > > admin at localhost:~$ snap refresh core --edge > error: cannot refresh "core": cannot refresh "core" to revision 870: no validation by "stlouis" > >> On 11 January 2017 at 10:21, Manik Taneja wrote: >> Hi Jenny, >> >> Welcome to Ubuntu Core. I see that you are experiencing a timeout while retrieving assertions. We have added additional redundancy to the client in a later revision (2.20) of snapd. While we await for 2.20 to move into the stable channel, can I request that you manually upgrade to the edge channel using- >> >> snap refresh core --edge >> snap --version >> snap list >> >> Once the refresh succedes, than please try the snap refresh command to make sure that all snaps are updated to the latest. If you still experience similar issues, please let us know. For reference, here's a screenshot of the cmd usage- >> >> >> >> Regards, >> Manik >> >>> On Wed, Jan 11, 2017 at 11:39 AM, Jenny Murphy wrote: >>> Hi Jamie, >>> Here is some more information as requested : >>> >>> admin at localhost:~$ snap info core >>> name: core >>> summary: "snapd runtime environment" >>> publisher: canonical >>> description: | >>> The core runtime environment for snapd >>> type: core >>> tracking: stable >>> installed: 16.04.1 (714) 79MB - >>> refreshed: 2016-12-16 04:28:38 +0000 UTC >>> channels: >>> stable: 16.04.1 (714) 0B - >>> candidate: 16.04.1 (714) 0B - >>> beta: 16.04.1 (714) 0B - >>> edge: 16.04.1 (870) 0B - >>> >>> admin at localhost:~$ snap refresh >>> error: cannot refresh []: cannot refresh snap-declaration for "stlouis-kernel": Get https://assertions.ubuntu.com/v1/assertions/snap-declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJxDUHag?max-format=1: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) >>> >>> admin at localhost:~$ snap list >>> Name Version Rev Developer Notes >>> bluez 5.37-2 15 canonical - >>> core 16.04.1 714 canonical - >>> gateway 2.0 x3 devmode >>> modem-manager 1.4.0-1 14 canonical - >>> network-manager 1.2.2-10 73 canonical - >>> snappy-debug 0.26 25 canonical - >>> snapweb 0.21.2 24 canonical - >>> stlouis 16.04-1.13 11 canonical - >>> stlouis-kernel 4.4.0-57-1 7 canonical - >>> tpm2 1.0-2.1 12 canonical - >>> uefi-fw-tools 1.2-0.7.2+git 2 canonical - >>> >>> >>> snapcraft at lists.snapcraft.io >>>> On 11 January 2017 at 07:16, Jamie Bennett wrote: >>>> Hi Jenny, >>>> >>>> On 09/01/17 at 10:28am, Jenny Murphy wrote: >>>> > Hi, >>>> > My query is related to a few of the recent discussions regarding versions, >>>> > releases and updates/ >>>> > >>>> > I currently have a Snappy Ubuntu system as follows : >>>> > >>>> > snap --version gives the following result : >>>> > snap 2.18.1 >>>> > snapd 2.18.1 >>>> > series 16 >>>> > >>>> > more /etc/lsb-release yeilds : >>>> > DISTRIB_ID="Ubuntu Core" >>>> > DISTRIB_RELEASE=16 >>>> > DISTRIB_DESCRIPTION="Ubuntu Core 16 >>>> > >>>> > And finally snap list yields : >>>> > core 16.04.1 641 canonical -- >>>> > >>>> > I don't see to be getting any automatic updates which I don't mind about >>>> > as long as I could manually update. >>>> > >>>> > So just a few questions : >>>> > >>>> > 1. How can I update snap and snapd >>>> >>>> What happens when you type: >>>> >>>> $ snap info core >>>> >>>> Also, what happens when you type: >>>> >>>> $ snap refresh >>>> >>>> > 2. Is snap the front end to snapd ? Do they get updated together? >>>> >>>> Yes. >>>> >>>> > 3. Can I update snapd and not update ubuntu-core and core. >>>> >>>> On an Ubuntu Core system snapd is integral to the device, on a classic system >>>> snapd is an add-on package so in the former case the system and snapd are >>>> updated together. >>>> >>>> > 4. Should ubuntu-core and core be updated together also? From the previous >>>> > reply on this topic, it seems core is the framework and ubuntu-core is the >>>> > filesystem or is it vice versa? >>>> >>>> ubuntu-core is the old name for core. We renamed this to better reflect that >>>> other cores could be available that are not Ubuntu based. Do you have both of >>>> these installed on your system? In fact, can you give us a full output of: >>>> >>>> $ snap list >>>> >>>> > I know there are a lot of questions here but it is just a little bit >>>> >sn unclear to me at the moment. Maybe there are also some other users in the >>>> > same position. >>>> > >>>> > >>>> > Thanks, >>>> > Jenny >>>> > >>>> > >>>> > >>>> > *Jenny Murphy* >>>> > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>>> > jenny.murphy at episensor.com t | +353 (0) 61 >>>> > 512 511 w | http://www.episensor.com >>>> >>>> > -- >>>> > 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 >>> >>> >>> >>> -- >>> 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 >> > > > > -- > Jenny Murphy > EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland > jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From jenny.murphy at episensor.com Wed Jan 11 12:05:59 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Wed, 11 Jan 2017 12:05:59 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> References: <20170111071649.omr65dkuxylolgpk@golstein> <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> Message-ID: Oh ok, so when they do, the updates will start happening automatically? Thanks. On 11 January 2017 at 11:54, Jamie Bennett wrote: > Hi Jenny, > > The lack of update is due to the platform you are using: St Louis. It > looks like the team responsible for St Louis updates has not fully > validated the new Ubuntu Core software which is why you haven't seen an > update yet. I suspect that an update is forthcoming soon. > > Regards, > Jamie. > > On 11 Jan 2017, at 13:38, Jenny Murphy wrote: > > Hi, > This is the error I get after step 1: > > > admin at localhost:~$ snap refresh core --edge > error: cannot refresh "core": cannot refresh "core" to revision 870: no > validation by "stlouis" > > On 11 January 2017 at 10:21, Manik Taneja wrote: > >> Hi Jenny, >> >> Welcome to Ubuntu Core. I see that you are experiencing a timeout while >> retrieving assertions. We have added additional redundancy to the client in >> a later revision (2.20) of snapd. While we await for 2.20 to move into the >> stable channel, can I request that you manually upgrade to the edge channel >> using- >> >> snap refresh core --edge >> snap --version >> snap list >> >> Once the refresh succedes, than please try the snap refresh command to >> make sure that all snaps are updated to the latest. If you still experience >> similar issues, please let us know. For reference, here's a screenshot of >> the cmd usage- >> >> >> >> Regards, >> Manik >> >> On Wed, Jan 11, 2017 at 11:39 AM, Jenny Murphy < >> jenny.murphy at episensor.com> wrote: >> >>> Hi Jamie, >>> Here is some more information as requested : >>> >>> admin at localhost:~$ snap info core >>> name: core >>> summary: "snapd runtime environment" >>> publisher: canonical >>> description: | >>> The core runtime environment for snapd >>> type: core >>> tracking: stable >>> installed: 16.04.1 (714) 79MB - >>> refreshed: 2016-12-16 04:28:38 +0000 UTC >>> channels: >>> stable: 16.04.1 (714) 0B - >>> candidate: 16.04.1 (714) 0B - >>> beta: 16.04.1 (714) 0B - >>> edge: 16.04.1 (870) 0B - >>> >>> admin at localhost:~$ snap refresh >>> error: cannot refresh []: cannot refresh snap-declaration for >>> "stlouis-kernel": Get https://assertions.ubuntu.com/ >>> v1/assertions/snap-declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJ >>> xDUHag?max-format=1: net/http: request canceled while waiting for >>> connection (Client.Timeout exceeded while awaiting headers) >>> >>> admin at localhost:~$ snap list >>> Name Version Rev Developer Notes >>> bluez 5.37-2 15 canonical - >>> core 16.04.1 714 canonical - >>> gateway 2.0 x3 devmode >>> modem-manager 1.4.0-1 14 canonical - >>> network-manager 1.2.2-10 73 canonical - >>> snappy-debug 0.26 25 canonical - >>> snapweb 0.21.2 24 canonical - >>> stlouis 16.04-1.13 11 canonical - >>> stlouis-kernel 4.4.0-57-1 7 canonical - >>> tpm2 1.0-2.1 12 canonical - >>> uefi-fw-tools 1.2-0.7.2+git 2 canonical - >>> >>> >>> snapcraft at lists.snapcraft.io >>> On 11 January 2017 at 07:16, Jamie Bennett >>> wrote: >>> >>>> Hi Jenny, >>>> >>>> On 09/01/17 at 10:28am, Jenny Murphy wrote: >>>> > Hi, >>>> > My query is related to a few of the recent discussions regarding >>>> versions, >>>> > releases and updates/ >>>> > >>>> > I currently have a Snappy Ubuntu system as follows : >>>> > >>>> > snap --version gives the following result : >>>> > snap 2.18.1 >>>> > snapd 2.18.1 >>>> > series 16 >>>> > >>>> > more /etc/lsb-release yeilds : >>>> > DISTRIB_ID="Ubuntu Core" >>>> > DISTRIB_RELEASE=16 >>>> > DISTRIB_DESCRIPTION="Ubuntu Core 16 >>>> > >>>> > And finally snap list yields : >>>> > core 16.04.1 641 canonical -- >>>> > >>>> > I don't see to be getting any automatic updates which I don't mind >>>> about >>>> > as long as I could manually update. >>>> > >>>> > So just a few questions : >>>> > >>>> > 1. How can I update snap and snapd >>>> >>>> What happens when you type: >>>> >>>> $ snap info core >>>> >>>> Also, what happens when you type: >>>> >>>> $ snap refresh >>>> >>>> > 2. Is snap the front end to snapd ? Do they get updated together? >>>> >>>> Yes. >>>> >>>> > 3. Can I update snapd and not update ubuntu-core and core. >>>> >>>> On an Ubuntu Core system snapd is integral to the device, on a classic >>>> system >>>> snapd is an add-on package so in the former case the system and snapd >>>> are >>>> updated together. >>>> >>>> > 4. Should ubuntu-core and core be updated together also? From the >>>> previous >>>> > reply on this topic, it seems core is the framework and ubuntu-core >>>> is the >>>> > filesystem or is it vice versa? >>>> >>>> ubuntu-core is the old name for core. We renamed this to better reflect >>>> that >>>> other cores could be available that are not Ubuntu based. Do you have >>>> both of >>>> these installed on your system? In fact, can you give us a full output >>>> of: >>>> >>>> $ snap list >>>> >>>> > I know there are a lot of questions here but it is just a little bit >>>> >sn unclear to me at the moment. Maybe there are also some other users >>>> in the >>>> > same position. >>>> > >>>> > >>>> > Thanks, >>>> > Jenny >>>> > >>>> > >>>> > >>>> > *Jenny Murphy* >>>> > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>>> > jenny.murphy at episensor.com t | +353 >>>> (0) 61 >>>> > 512 511 w | http://www.episensor.com >>>> >>>> > -- >>>> > 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/mailm >>>> an/listinfo/snapcraft >>>> >>> >>> >>> >>> -- >>> *Jenny Murphy* >>> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>> jenny.murphy at episensor.com t | +353 (0) >>> 61 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 <+353%2061%20512%20511> 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 > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.wayne at canonical.com Wed Jan 11 14:22:29 2017 From: chris.wayne at canonical.com (Chris Wayne) Date: Wed, 11 Jan 2017 09:22:29 -0500 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: <20170111071649.omr65dkuxylolgpk@golstein> <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> Message-ID: Hi Jenny, >From the looks of it, your system has actually been updated automatically, as your first email indicates you had core version 641, and now have core 714. The reason you could not update to core on the edge channel to version 870 is because that version has not been validated yet. Does snap --version still show 2.18? With core rev 714 (which your snap list indicates you have installed) you should now be seeing 2.20. Thanks Chris On Wed, Jan 11, 2017 at 7:05 AM, Jenny Murphy wrote: > Oh ok, so when they do, the updates will start happening automatically? > Thanks. > > On 11 January 2017 at 11:54, Jamie Bennett > wrote: > >> Hi Jenny, >> >> The lack of update is due to the platform you are using: St Louis. It >> looks like the team responsible for St Louis updates has not fully >> validated the new Ubuntu Core software which is why you haven't seen an >> update yet. I suspect that an update is forthcoming soon. >> >> Regards, >> Jamie. >> >> On 11 Jan 2017, at 13:38, Jenny Murphy >> wrote: >> >> Hi, >> This is the error I get after step 1: >> >> >> admin at localhost:~$ snap refresh core --edge >> error: cannot refresh "core": cannot refresh "core" to revision 870: no >> validation by "stlouis" >> >> On 11 January 2017 at 10:21, Manik Taneja wrote: >> >>> Hi Jenny, >>> >>> Welcome to Ubuntu Core. I see that you are experiencing a timeout while >>> retrieving assertions. We have added additional redundancy to the client in >>> a later revision (2.20) of snapd. While we await for 2.20 to move into the >>> stable channel, can I request that you manually upgrade to the edge channel >>> using- >>> >>> snap refresh core --edge >>> snap --version >>> snap list >>> >>> Once the refresh succedes, than please try the snap refresh command to >>> make sure that all snaps are updated to the latest. If you still experience >>> similar issues, please let us know. For reference, here's a screenshot of >>> the cmd usage- >>> >>> >>> >>> Regards, >>> Manik >>> >>> On Wed, Jan 11, 2017 at 11:39 AM, Jenny Murphy < >>> jenny.murphy at episensor.com> wrote: >>> >>>> Hi Jamie, >>>> Here is some more information as requested : >>>> >>>> admin at localhost:~$ snap info core >>>> name: core >>>> summary: "snapd runtime environment" >>>> publisher: canonical >>>> description: | >>>> The core runtime environment for snapd >>>> type: core >>>> tracking: stable >>>> installed: 16.04.1 (714) 79MB - >>>> refreshed: 2016-12-16 04:28:38 +0000 UTC >>>> channels: >>>> stable: 16.04.1 (714) 0B - >>>> candidate: 16.04.1 (714) 0B - >>>> beta: 16.04.1 (714) 0B - >>>> edge: 16.04.1 (870) 0B - >>>> >>>> admin at localhost:~$ snap refresh >>>> error: cannot refresh []: cannot refresh snap-declaration for >>>> "stlouis-kernel": Get https://assertions.ubuntu.com/ >>>> v1/assertions/snap-declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJ >>>> xDUHag?max-format=1: net/http: request canceled while waiting for >>>> connection (Client.Timeout exceeded while awaiting headers) >>>> >>>> admin at localhost:~$ snap list >>>> Name Version Rev Developer Notes >>>> bluez 5.37-2 15 canonical - >>>> core 16.04.1 714 canonical - >>>> gateway 2.0 x3 devmode >>>> modem-manager 1.4.0-1 14 canonical - >>>> network-manager 1.2.2-10 73 canonical - >>>> snappy-debug 0.26 25 canonical - >>>> snapweb 0.21.2 24 canonical - >>>> stlouis 16.04-1.13 11 canonical - >>>> stlouis-kernel 4.4.0-57-1 7 canonical - >>>> tpm2 1.0-2.1 12 canonical - >>>> uefi-fw-tools 1.2-0.7.2+git 2 canonical - >>>> >>>> >>>> snapcraft at lists.snapcraft.io >>>> On 11 January 2017 at 07:16, Jamie Bennett >>> > wrote: >>>> >>>>> Hi Jenny, >>>>> >>>>> On 09/01/17 at 10:28am, Jenny Murphy wrote: >>>>> > Hi, >>>>> > My query is related to a few of the recent discussions regarding >>>>> versions, >>>>> > releases and updates/ >>>>> > >>>>> > I currently have a Snappy Ubuntu system as follows : >>>>> > >>>>> > snap --version gives the following result : >>>>> > snap 2.18.1 >>>>> > snapd 2.18.1 >>>>> > series 16 >>>>> > >>>>> > more /etc/lsb-release yeilds : >>>>> > DISTRIB_ID="Ubuntu Core" >>>>> > DISTRIB_RELEASE=16 >>>>> > DISTRIB_DESCRIPTION="Ubuntu Core 16 >>>>> > >>>>> > And finally snap list yields : >>>>> > core 16.04.1 641 canonical -- >>>>> > >>>>> > I don't see to be getting any automatic updates which I don't mind >>>>> about >>>>> > as long as I could manually update. >>>>> > >>>>> > So just a few questions : >>>>> > >>>>> > 1. How can I update snap and snapd >>>>> >>>>> What happens when you type: >>>>> >>>>> $ snap info core >>>>> >>>>> Also, what happens when you type: >>>>> >>>>> $ snap refresh >>>>> >>>>> > 2. Is snap the front end to snapd ? Do they get updated together? >>>>> >>>>> Yes. >>>>> >>>>> > 3. Can I update snapd and not update ubuntu-core and core. >>>>> >>>>> On an Ubuntu Core system snapd is integral to the device, on a classic >>>>> system >>>>> snapd is an add-on package so in the former case the system and snapd >>>>> are >>>>> updated together. >>>>> >>>>> > 4. Should ubuntu-core and core be updated together also? From the >>>>> previous >>>>> > reply on this topic, it seems core is the framework and ubuntu-core >>>>> is the >>>>> > filesystem or is it vice versa? >>>>> >>>>> ubuntu-core is the old name for core. We renamed this to better >>>>> reflect that >>>>> other cores could be available that are not Ubuntu based. Do you have >>>>> both of >>>>> these installed on your system? In fact, can you give us a full output >>>>> of: >>>>> >>>>> $ snap list >>>>> >>>>> > I know there are a lot of questions here but it is just a little bit >>>>> >sn unclear to me at the moment. Maybe there are also some other users >>>>> in the >>>>> > same position. >>>>> > >>>>> > >>>>> > Thanks, >>>>> > Jenny >>>>> > >>>>> > >>>>> > >>>>> > *Jenny Murphy* >>>>> > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>>>> > jenny.murphy at episensor.com t | +353 >>>>> (0) 61 >>>>> > 512 511 w | http://www.episensor.com >>>>> >>>>> > -- >>>>> > 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/mailm >>>>> an/listinfo/snapcraft >>>>> >>>> >>>> >>>> >>>> -- >>>> *Jenny Murphy* >>>> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>>> jenny.murphy at episensor.com t | +353 (0) >>>> 61 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> >> -- >> *Jenny Murphy* >> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >> jenny.murphy at episensor.com t | +353 (0) 61 >> 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > *Jenny Murphy* > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* > jenny.murphy at episensor.com t | +353 (0) 61 > 512 511 <+353%2061%20512%20511> w | http://www.episensor.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.hodapp at canonical.com Wed Jan 11 15:24:55 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Wed, 11 Jan 2017 10:24:55 -0500 Subject: Slow snap build on Ubuntu Core device In-Reply-To: <1484063735.26677.22.camel@ubuntu.com> References: <1484063735.26677.22.camel@ubuntu.com> Message-ID: That works well ogra, started using this on my laptop. On Tue, Jan 10, 2017 at 10:55 AM, Oliver Grawert wrote: > hi, > Am Dienstag, den 10.01.2017, 15:40 +0000 schrieb Alan Pope: > > > > > > > For archive packages being slow (as you have) I use apt-cacher-ng on > > my laptop. It caches the debs making snapcraft builds much faster. > > shamelessly promoting my onw snap here: > > sudo snap install packageproxy ... > > point your sources.list entries to http://localhost:9999/ubuntu-ports a > nd be happy ;) > > 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 kyle.fazzari at canonical.com Wed Jan 11 16:43:34 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 11 Jan 2017 08:43:34 -0800 Subject: Kernel plugin: Avoid redownloading os.snap on a local Git repo In-Reply-To: References: <1483903207.2507.1@mail.gandi.net> <1129d257-a0f7-a6bb-a56f-0b2117c808bf@canonical.com> <4139e5ce-0270-a621-7a3a-3c9c91a80837@canonical.com> Message-ID: <7bfa7ac7-6e88-8071-d241-6325b4a001e4@canonical.com> This doesn't really involve cleaning, in fact it's not ideal that anything needs to be cleaned at all in this case-- snapcraft needs to pick up local changes automatically. That work in ongoing. On 01/09/2017 05:35 PM, Gustavo Niemeyer wrote: > > This is one area that is still super confusing, and would be worth > investing some time on soon. > > We discussed this back in May on: > > - clean behavior is confusing > https://bugs.launchpad.net/snapcraft/+bug/1582469 > > As described there, this is a rock on the most important pipeline of the > tool. > > > On Mon, Jan 9, 2017 at 11:31 PM, Kyle Fazzari > > wrote: > > On 01/09/2017 12:08 PM, Michał Sawicz wrote: > > W dniu 09.01.2017 o 20:32, Michał Sawicz pisze: > >> I *think* (may be wrong) that `snapcraft pull` can help here: > >> > >> http://snapcraft.io/docs/reference/snapcraft-command#pull > > > > > I was able to force `snapcraft pull` to pull things again by messing > > with parts/part-name/state - might wanna try that in case there's no > > better answers. > > Careful with this, snapcraft tends to get upset if you mess with its > state behind its back. > > Lifecycle steps build upon each other: pull -> build -> stage -> prime. > Let's say you ran `snapcraft build A`, which will pull part A (let's say > it was commit abdc1), and then build it. If commit abcd2 is later made > and you want to build it, you need to clean the pull step (which will > also clean the build step) with `snapcraft clean A`, and build again: > `snapcraft build A`. That will pull any updates that have been made, and > build anew. > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > > gustavo @ http://niemeyer.net > > -- 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 mrsingh at ssni.com Wed Jan 11 17:59:10 2017 From: mrsingh at ssni.com (Mritunjai Singh) Date: Wed, 11 Jan 2017 17:59:10 +0000 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) Message-ID: Hi All, Kindly refer to: https://github.com/snapcore/snapd/issues/2557 We are trying to get a head start on Core Snappy working with our RF Mesh network card. It connects over serial and needs to be available at boot. We first tried this using snap approach but due to missing hotplugging serial-interface in current(latest) version of snapcraft, serial i/o requests are being denied even if the snap has the permission to use serial port. We have been suggested the gadget snap approach in order to expose /dev/ttyS0 to the serial port interface for tunnccd snap to access it. It would be very helpful if someone can point me to the working example of a gadget snap with access to serial interface or any end to end gadget snap example and its build steps. Regards, Mritunjai -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Jan 11 18:37:20 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 11 Jan 2017 19:37:20 +0100 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) In-Reply-To: References: Message-ID: <1484159840.26677.55.camel@ubuntu.com> hi, Am Mittwoch, den 11.01.2017, 17:59 +0000 schrieb Mritunjai Singh: > Hi All, >   > Kindly refer to: https://github.com/snapcore/snapd/issues/2557 >   > We are trying to get a head start on Core Snappy working with our RF > Mesh network card. It connects over serial and needs to be available > at boot. We first tried this using snap approach but due to missing > hotplugging serial-interface in current(latest) version of snapcraft, > serial i/o requests are being denied even if the snap has the > permission to use serial port. >   > We have been suggested the gadget snap approach in order to expose > /dev/ttyS0 to the serial port interface for tunnccd snap to access > it. It would be very helpful if someone can point me to the working > example of a gadget snap with access to serial interface or any end > to end gadget snap example and its build steps. note that all our gadgets offer a console on serial by default, if you drive some external device via serial you might want to drop this console tty option.  all our official gadgets are under https://github.com/snapcore/ .. namely the pi2-gadget, pi3-gadget, pc-gadget and dragonboard-gadget sub-trees if you want to take a look ... 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 max.brustkern at canonical.com Wed Jan 11 18:44:34 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Wed, 11 Jan 2017 13:44:34 -0500 Subject: Configuring snapd on ubuntu core for a web proxy Message-ID: I'm trying to run ubuntu core 16 in a kvm instance in an internal lab that requires a web proxy. This bug: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 seems to cover how to do this on classic ubuntu, but the files that hold the environment variables used by snapd on an ubuntu core system are all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way for snapd on that system? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.butler at canonical.com Wed Jan 11 19:31:57 2017 From: charles.butler at canonical.com (Charles Butler) Date: Wed, 11 Jan 2017 13:31:57 -0600 Subject: SystemD Unit file customization for a snap Message-ID: Greetings, I'm working on an update to the etcd snap so we can make the Kubernetes etcd2 -> etcd3 migration simple, transactional, and hopefully more bullet proof in iterations to come. I've got a question regarding the SystemD Daemon unitfile. You can declare to snapcraft, that a bin should be treated as a daemon with very straightforward syntax apps: etcd: command: bin/etcd plugs: - network daemon: simple restart-condition: on-abnormal This was -almost magical-. I have need of customizing this output unit file based on conditions coming from Juju, such as TLS certificate paths will need to be passed as ENV, as well as peer connection strings. I can template this in Juju and overwrite the systemd unit file, but I feel like this will be a continual issue as the snap upgrades, I can only presume the systemd unit file is upgraded along the way. Please correct me if my assumption is incorrect here. Is there a way I can declare ENV or template the systemd file with the snap? Thanks and all the best, Charles Butler - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com Conjure up Kubernetes: `conjure-up kubernetes-core` on any ubuntu install with Conjure and Juju. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Wed Jan 11 22:12:14 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 11 Jan 2017 16:12:14 -0600 Subject: Bad system call - 45 for my binary app In-Reply-To: References: Message-ID: <1484172734.3354.7.camel@canonical.com> On Wed, 2017-01-11 at 11:34 +0200, Andrey Rogovsky wrote: > Hi, all! > > I crafted snap for i386 X11 app (no sources) which work success on amd64 > arch in development mode. > But when I install it in strict mode - got this error: > > = Seccomp = > Time: Jan 11 11:26:38 > Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=17988 > comm="BlueQuest" exe="/snap/bluequest/x1/usr/bin/BlueQuest" sig=31 > arch=40000003 45(brk) compat=1 ip=0xf7749547 code=0x0 > Syscall: brk > > How I can resolve this problem? > This sounds like bug #1592022 which should be fixed in snapd and snap-confine 2.20. What versions of there packages do you have installed? [1]https://bugs.launchpad.net/snap-confine/+bug/1592022 -- 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 stuart.bishop at canonical.com Thu Jan 12 04:33:01 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Thu, 12 Jan 2017 11:33:01 +0700 Subject: SystemD Unit file customization for a snap In-Reply-To: References: Message-ID: On 12 January 2017 at 02:31, Charles Butler wrote: > Greetings, > > I'm working on an update to the etcd snap so we can make the Kubernetes > etcd2 -> etcd3 migration simple, transactional, and hopefully more bullet > proof in iterations to come. I've got a question regarding the SystemD > Daemon unitfile. > > You can declare to snapcraft, that a bin should be treated as a daemon > with very straightforward syntax > > apps: > etcd: > command: bin/etcd > plugs: > - network > daemon: simple > restart-condition: on-abnormal > > This was -almost magical-. I have need of customizing this output unit > file based on conditions coming from Juju, such as TLS certificate paths > will need to be passed as ENV, as well as peer connection strings. > > I can template this in Juju and overwrite the systemd unit file, but I > feel like this will be a continual issue as the snap upgrades, I can only > presume the systemd unit file is upgraded along the way. Please correct me > if my assumption is incorrect here. Is there a way I can declare ENV or > template the systemd file with the snap? > You don't have much control over the generated systemd service file. Its an open issue. So while you could have your snap accept configuration options, the snap can't rewrite its own systemd service file (or it could escape its containment). What you would need to do is write a wrapper for bin/etcd that sets the environment variables (pulled from snap configuration, or from a .ini file or similar stored in $SNAP_DATA or $SNAP_COMMON) before os.exec'ing the real bin/etcd Since you are driving this from a charm though, you don't need it. systemd supports '.d' style directories, allowing you to extend a .service file owned by some other process. This is how the snap layer adds support for downloading snaps via proxies, so see https://git.launchpad.net/layer-snap/tree/reactive/snap.py#n62 for an example. -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.bishop at canonical.com Thu Jan 12 04:36:13 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Thu, 12 Jan 2017 11:36:13 +0700 Subject: SystemD Unit file customization for a snap In-Reply-To: References: Message-ID: On 12 January 2017 at 11:33, Stuart Bishop wrote: > > On 12 January 2017 at 02:31, Charles Butler > wrote: > You don't have much control over the generated systemd service file. Its > an open issue. So while you could have your snap accept configuration > options, the snap can't rewrite its own systemd service file (or it could > escape its containment). What you would need to do is write a wrapper for > bin/etcd that sets the environment variables (pulled from snap > configuration, or from a .ini file or similar stored in $SNAP_DATA or > $SNAP_COMMON) before os.exec'ing the real bin/etcd > (and if you choose this approach, you of course need your charm to restart the service when you change the config. snapd can't do that for you, yet. Well, maybe the config handler is able to restart the service but I suspect confinement would block that attempt) Since you are driving this from a charm though, you don't need it. systemd > supports '.d' style directories, allowing you to extend a .service file > owned by some other process. This is how the snap layer adds support for > downloading snaps via proxies, so see https://git.launchpad.net/ > layer-snap/tree/reactive/snap.py#n62 for an example. > > -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.bishop at canonical.com Thu Jan 12 04:49:39 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Thu, 12 Jan 2017 11:49:39 +0700 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: On 12 January 2017 at 01:44, Max Brustkern wrote: > I'm trying to run ubuntu core 16 in a kvm instance in an internal lab that > requires a web proxy. This bug: > https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 > seems to cover how to do this on classic ubuntu, but the files that hold > the environment variables used by snapd on an ubuntu core system are all on > read-only filesystems. How do I set HTTPS_PROXY in a persistent way for > snapd on that system? > https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about adding support for proxies to snapd (rather than have it use the system environment variables, which is one implementation option but not always what you want since that affects everything on the system). But that doesn't help with your read-only filesystem sorry :-( (Hmm... disgusting hack idea.... since you can't create /etc/systemd/system/ snapd.service.d/ on your read-only filesystem, try mounting that directory from somewhere. Extra points for using systemd to mount the systemd service file overrides and setting up dependencies so it does everything in the right order :-) ) -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.rogovsky at gmail.com Thu Jan 12 05:10:06 2017 From: a.rogovsky at gmail.com (Andrey Rogovsky) Date: Thu, 12 Jan 2017 07:10:06 +0200 Subject: Bad system call - 45 for my binary app In-Reply-To: <1484172734.3354.7.camel@canonical.com> References: <1484172734.3354.7.camel@canonical.com> Message-ID: Hi, Jamie Strandboge! Thank you for reply! Update snap is resolve my problem! Thanks! 2017-01-12 0:12 GMT+02:00 Jamie Strandboge : > On Wed, 2017-01-11 at 11:34 +0200, Andrey Rogovsky wrote: > > Hi, all! > > > > I crafted snap for i386 X11 app (no sources) which work success on amd64 > > arch in development mode. > > But when I install it in strict mode - got this error: > > > > = Seccomp = > > Time: Jan 11 11:26:38 > > Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=17988 > > comm="BlueQuest" exe="/snap/bluequest/x1/usr/bin/BlueQuest" sig=31 > > arch=40000003 45(brk) compat=1 ip=0xf7749547 code=0x0 > > Syscall: brk > > > > How I can resolve this problem? > > > > This sounds like bug #1592022 which should be fixed in snapd and > snap-confine > 2.20. What versions of there packages do you have installed? > > [1]https://bugs.launchpad.net/snap-confine/+bug/1592022 > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Thu Jan 12 08:57:50 2017 From: simon.fels at canonical.com (Simon Fels) Date: Thu, 12 Jan 2017 09:57:50 +0100 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) In-Reply-To: <1484159840.26677.55.camel@ubuntu.com> References: <1484159840.26677.55.camel@ubuntu.com> Message-ID: You can add a serial port slot to a gadget snap.yaml like this: ttyS4: interface: serial-port path: /dev/ttyS4 This only applies to static serial port nodes. If you have one provided by an USB device you have to user a slightly different slot definition which refers the USB product/vendor id of your USB device: my-usb-serial: interface: serial-port usb-product: 0x1111 usb-vendor: 0x2222 path: /dev/my-usb-serial-port With the path attribute you can select a static path for the serial port node which your snap then gets access to once you connected the plug and the slot. The path needs to start with /dev/ and afterwards you're free to select a free node name. Internally the interface implementation will link the right /dev/ttyUSB* node to the specified path. Please note that you can define such a slot only on a gadget snap! So if you don't have your own gadget snap today, you need to create one for your device in order to get access to the serial port. I hope that helps. regards, Simon On Wed, Jan 11, 2017 at 7:37 PM, Oliver Grawert wrote: > hi, > Am Mittwoch, den 11.01.2017, 17:59 +0000 schrieb Mritunjai Singh: > > Hi All, > > > > Kindly refer to: https://github.com/snapcore/snapd/issues/2557 > > > > We are trying to get a head start on Core Snappy working with our RF > > Mesh network card. It connects over serial and needs to be available > > at boot. We first tried this using snap approach but due to missing > > hotplugging serial-interface in current(latest) version of snapcraft, > > serial i/o requests are being denied even if the snap has the > > permission to use serial port. > > > > We have been suggested the gadget snap approach in order to expose > > /dev/ttyS0 to the serial port interface for tunnccd snap to access > > it. It would be very helpful if someone can point me to the working > > example of a gadget snap with access to serial interface or any end > > to end gadget snap example and its build steps. > > note that all our gadgets offer a console on serial by default, if you > drive some external device via serial you might want to drop this > console tty option. > > all our official gadgets are under https://github.com/snapcore/ .. > namely the pi2-gadget, pi3-gadget, pc-gadget and dragonboard-gadget > sub-trees if you want to take a look ... > > 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 jenny.murphy at episensor.com Thu Jan 12 09:24:56 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 12 Jan 2017 09:24:56 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: <20170111071649.omr65dkuxylolgpk@golstein> <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> Message-ID: Hi Chris, Yes it seems to have! So I guess I am being automatically updated after all! Maybe this is a rather basic question but how does one keep track of whether or not an automatic update has occurred. (I had seen messages previously in syslog about attempted updates). Thanks for you assistance. Jenny On 11 January 2017 at 14:22, Chris Wayne wrote: > Hi Jenny, > > From the looks of it, your system has actually been updated automatically, > as your first email indicates you had core version 641, and now have core > 714. The reason you could not update to core on the edge channel to > version 870 is because that version has not been validated yet. > > Does snap --version still show 2.18? With core rev 714 (which your snap > list indicates you have installed) you should now be seeing 2.20. > > Thanks > Chris > > On Wed, Jan 11, 2017 at 7:05 AM, Jenny Murphy > wrote: > >> Oh ok, so when they do, the updates will start happening automatically? >> Thanks. >> >> On 11 January 2017 at 11:54, Jamie Bennett >> wrote: >> >>> Hi Jenny, >>> >>> The lack of update is due to the platform you are using: St Louis. It >>> looks like the team responsible for St Louis updates has not fully >>> validated the new Ubuntu Core software which is why you haven't seen an >>> update yet. I suspect that an update is forthcoming soon. >>> >>> Regards, >>> Jamie. >>> >>> On 11 Jan 2017, at 13:38, Jenny Murphy >>> wrote: >>> >>> Hi, >>> This is the error I get after step 1: >>> >>> >>> admin at localhost:~$ snap refresh core --edge >>> error: cannot refresh "core": cannot refresh "core" to revision 870: no >>> validation by "stlouis" >>> >>> On 11 January 2017 at 10:21, Manik Taneja wrote: >>> >>>> Hi Jenny, >>>> >>>> Welcome to Ubuntu Core. I see that you are experiencing a timeout while >>>> retrieving assertions. We have added additional redundancy to the client in >>>> a later revision (2.20) of snapd. While we await for 2.20 to move into the >>>> stable channel, can I request that you manually upgrade to the edge channel >>>> using- >>>> >>>> snap refresh core --edge >>>> snap --version >>>> snap list >>>> >>>> Once the refresh succedes, than please try the snap refresh command to >>>> make sure that all snaps are updated to the latest. If you still experience >>>> similar issues, please let us know. For reference, here's a screenshot of >>>> the cmd usage- >>>> >>>> >>>> >>>> Regards, >>>> Manik >>>> >>>> On Wed, Jan 11, 2017 at 11:39 AM, Jenny Murphy < >>>> jenny.murphy at episensor.com> wrote: >>>> >>>>> Hi Jamie, >>>>> Here is some more information as requested : >>>>> >>>>> admin at localhost:~$ snap info core >>>>> name: core >>>>> summary: "snapd runtime environment" >>>>> publisher: canonical >>>>> description: | >>>>> The core runtime environment for snapd >>>>> type: core >>>>> tracking: stable >>>>> installed: 16.04.1 (714) 79MB - >>>>> refreshed: 2016-12-16 04:28:38 +0000 UTC >>>>> channels: >>>>> stable: 16.04.1 (714) 0B - >>>>> candidate: 16.04.1 (714) 0B - >>>>> beta: 16.04.1 (714) 0B - >>>>> edge: 16.04.1 (870) 0B - >>>>> >>>>> admin at localhost:~$ snap refresh >>>>> error: cannot refresh []: cannot refresh snap-declaration for >>>>> "stlouis-kernel": Get https://assertions.ubuntu.com/ >>>>> v1/assertions/snap-declaration/16/0EawO5JYYJmNw9CmweMnyrwGgJ >>>>> xDUHag?max-format=1: net/http: request canceled while waiting for >>>>> connection (Client.Timeout exceeded while awaiting headers) >>>>> >>>>> admin at localhost:~$ snap list >>>>> Name Version Rev Developer Notes >>>>> bluez 5.37-2 15 canonical - >>>>> core 16.04.1 714 canonical - >>>>> gateway 2.0 x3 devmode >>>>> modem-manager 1.4.0-1 14 canonical - >>>>> network-manager 1.2.2-10 73 canonical - >>>>> snappy-debug 0.26 25 canonical - >>>>> snapweb 0.21.2 24 canonical - >>>>> stlouis 16.04-1.13 11 canonical - >>>>> stlouis-kernel 4.4.0-57-1 7 canonical - >>>>> tpm2 1.0-2.1 12 canonical - >>>>> uefi-fw-tools 1.2-0.7.2+git 2 canonical - >>>>> >>>>> >>>>> snapcraft at lists.snapcraft.io >>>>> On 11 January 2017 at 07:16, Jamie Bennett < >>>>> jamie.bennett at canonical.com> wrote: >>>>> >>>>>> Hi Jenny, >>>>>> >>>>>> On 09/01/17 at 10:28am, Jenny Murphy wrote: >>>>>> > Hi, >>>>>> > My query is related to a few of the recent discussions regarding >>>>>> versions, >>>>>> > releases and updates/ >>>>>> > >>>>>> > I currently have a Snappy Ubuntu system as follows : >>>>>> > >>>>>> > snap --version gives the following result : >>>>>> > snap 2.18.1 >>>>>> > snapd 2.18.1 >>>>>> > series 16 >>>>>> > >>>>>> > more /etc/lsb-release yeilds : >>>>>> > DISTRIB_ID="Ubuntu Core" >>>>>> > DISTRIB_RELEASE=16 >>>>>> > DISTRIB_DESCRIPTION="Ubuntu Core 16 >>>>>> > >>>>>> > And finally snap list yields : >>>>>> > core 16.04.1 641 canonical -- >>>>>> > >>>>>> > I don't see to be getting any automatic updates which I don't mind >>>>>> about >>>>>> > as long as I could manually update. >>>>>> > >>>>>> > So just a few questions : >>>>>> > >>>>>> > 1. How can I update snap and snapd >>>>>> >>>>>> What happens when you type: >>>>>> >>>>>> $ snap info core >>>>>> >>>>>> Also, what happens when you type: >>>>>> >>>>>> $ snap refresh >>>>>> >>>>>> > 2. Is snap the front end to snapd ? Do they get updated together? >>>>>> >>>>>> Yes. >>>>>> >>>>>> > 3. Can I update snapd and not update ubuntu-core and core. >>>>>> >>>>>> On an Ubuntu Core system snapd is integral to the device, on a >>>>>> classic system >>>>>> snapd is an add-on package so in the former case the system and snapd >>>>>> are >>>>>> updated together. >>>>>> >>>>>> > 4. Should ubuntu-core and core be updated together also? From the >>>>>> previous >>>>>> > reply on this topic, it seems core is the framework and ubuntu-core >>>>>> is the >>>>>> > filesystem or is it vice versa? >>>>>> >>>>>> ubuntu-core is the old name for core. We renamed this to better >>>>>> reflect that >>>>>> other cores could be available that are not Ubuntu based. Do you have >>>>>> both of >>>>>> these installed on your system? In fact, can you give us a full >>>>>> output of: >>>>>> >>>>>> $ snap list >>>>>> >>>>>> > I know there are a lot of questions here but it is just a little bit >>>>>> >sn unclear to me at the moment. Maybe there are also some other >>>>>> users in the >>>>>> > same position. >>>>>> > >>>>>> > >>>>>> > Thanks, >>>>>> > Jenny >>>>>> > >>>>>> > >>>>>> > >>>>>> > *Jenny Murphy* >>>>>> > *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>>>>> > jenny.murphy at episensor.com t | +353 >>>>>> (0) 61 >>>>>> > 512 511 w | http://www.episensor.com >>>>>> >>>>>> > -- >>>>>> > 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/mailm >>>>>> an/listinfo/snapcraft >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *Jenny Murphy* >>>>> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>>>> jenny.murphy at episensor.com t | +353 (0) >>>>> 61 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >>>>> >>>>> -- >>>>> Snapcraft mailing list >>>>> Snapcraft at lists.snapcraft.io >>>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> -- >>>> Snapcraft mailing list >>>> Snapcraft at lists.snapcraft.io >>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> >>> -- >>> *Jenny Murphy* >>> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >>> jenny.murphy at episensor.com t | +353 (0) >>> 61 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/snapcraft >>> >>> >> >> >> -- >> *Jenny Murphy* >> *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* >> jenny.murphy at episensor.com t | +353 (0) 61 >> 512 511 <+353%2061%20512%20511> w | http://www.episensor.com >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Thu Jan 12 09:31:11 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 12 Jan 2017 10:31:11 +0100 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: References: <20170111071649.omr65dkuxylolgpk@golstein> <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> Message-ID: <1484213471.26677.59.camel@ubuntu.com> hi, Am Donnerstag, den 12.01.2017, 09:24 +0000 schrieb Jenny Murphy: > Hi Chris, >  Yes it seems to have! So I guess I am being automatically updated > after all! Maybe this is a rather basic question but how does one > keep track of whether or not an automatic update has occurred. "snap changes" is your friend :) here is an excerpt of mine: 5    Done    2017-01-11T23:40:13Z  2017-01-11T23:40:13Z  Refresh all snaps: no updates 6    Done    2017-01-12T05:30:13Z  2017-01-12T05:31:14Z  Refresh snap "core" 7    Done    2017-01-12T05:36:14Z  2017-01-12T05:36:16Z  Update kernel and core snap revisions 9    Done    2017-01-12T06:30:48Z  2017-01-12T06:30:48Z  Refresh all snaps: no updates you can see more details by using the change ID from the first column with "snap change $ID" ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From jenny.murphy at episensor.com Thu Jan 12 09:35:41 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Thu, 12 Jan 2017 09:35:41 +0000 Subject: Manual update of snap/snapd and core/ubuntu-core In-Reply-To: <1484213471.26677.59.camel@ubuntu.com> References: <20170111071649.omr65dkuxylolgpk@golstein> <69CB20B6-26E8-432C-A1D0-031924070DCB@canonical.com> <1484213471.26677.59.camel@ubuntu.com> Message-ID: Hi Oli, Great, that is fantastic. Jenny On 12 January 2017 at 09:31, Oliver Grawert wrote: > hi, > Am Donnerstag, den 12.01.2017, 09:24 +0000 schrieb Jenny Murphy: > > Hi Chris, > > Yes it seems to have! So I guess I am being automatically updated > > after all! Maybe this is a rather basic question but how does one > > keep track of whether or not an automatic update has occurred. > > "snap changes" is your friend :) > here is an excerpt of mine: > > 5 Done 2017-01-11T23:40:13Z 2017-01-11T23:40:13Z Refresh all > snaps: no updates > 6 Done 2017-01-12T05:30:13Z 2017-01-12T05:31:14Z Refresh snap > "core" > 7 Done 2017-01-12T05:36:14Z 2017-01-12T05:36:16Z Update kernel > and core snap revisions > 9 Done 2017-01-12T06:30:48Z 2017-01-12T06:30:48Z Refresh all > snaps: no updates > > you can see more details by using the change ID from the first column > with "snap change $ID" > > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Thu Jan 12 12:36:12 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Thu, 12 Jan 2017 12:36:12 +0000 Subject: Packaging with pygtk Message-ID: <151c63230ef4f55229b58c5d9f37f5d1@cliftonts.co.uk> I have a graphical python project built with pygtk I wish to package, I'm using travis CI to automatically package and release when I commit to github. I have been informed that pygtk needs to be specifically installed and bundled within snapcraft.yaml / travis.yaml but I don't seem to be able to get it to work. Does anyone have any insight into how this is done? Thanks From simon.fels at canonical.com Thu Jan 12 13:09:24 2017 From: simon.fels at canonical.com (Simon Fels) Date: Thu, 12 Jan 2017 14:09:24 +0100 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: As both platform and commercial QA have approved the new snaps I would like to go ahead with both snaps earlier than waiting for next Wednesday and publishing them to stable. Any objections from anyone? regards, Simon On Wed, Jan 4, 2017 at 2:51 PM, Simon Fels wrote: > Hey everyone, > > A new release of the wifi-ap and pulseaudio snaps were pushed into the > candidate channel. This release includes several improvements for both > snaps. > > wifi-ap: > > * Switched to a unix domain socket instead of a local TCP endpoint to > provide secure access to the management service REST API endpoint via a > content interface based slot. > > * The management service now controls the access point process directly > instead of both being two independent systemd service units. This makes > coordination and application of configuration changes a lot easier. > > * New wifi-ap.status command is now available which shows the current > status of the AP. > > * Improve configuration wizard which now has an auto mode as well which is > executed directly after the installation of the snap to provide an > out-of-the-box experience and directly spawn up an access point users can > connect to. Wizard can be manually invoked too and guides the user through > the configuration of the access point. > > * Added extensive testing of the whole snap via spread > > pulseaudio: > > This is the first release of the snap. We currently only support running > pulseaudio in system mode and with that only support Ubuntu Core devices. > Installing on classic desktop devices is possible but not yet supported. > > Please note that we require a kernel with ALSA support enabled which is > not yet the case for all reference devices like the Raspberry Pi 2 or 3. > > --- > > An overview of which revisions / versions of the particular snaps are > available in which channel is available at https://docs.google.com/spr > eadsheets/d/1q2dmjPQ0Bam3p3frmmrX2WI3d1r8iusE0JTc0wm2jKM/edit#gid=0 > > The snaps have passed our engineering QA and will now be tested by the > platform and commercial QA teams before the new versions are pushed to the > stable channel. > > Bileto requests are: > - wifi-ap: https://bileto.ubuntu.com/#/ticket/2333 > - pulseaudio: https://bileto.ubuntu.com/#/ticket/2327 > > If you have any questions feel free to ping me. > > regards, > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From espy at canonical.com Thu Jan 12 13:49:49 2017 From: espy at canonical.com (espy) Date: Thu, 12 Jan 2017 08:49:49 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: <20e039e8-da1e-dd8d-6854-fa3998a577d8@canonical.com> On 01/12/2017 08:09 AM, Simon Fels wrote: > As both platform and commercial QA have approved the new snaps I would > like to go ahead with both snaps earlier than waiting for next Wednesday > and publishing them to stable. > > Any objections from anyone? +1 to releasing now. Thanks! /t From matt.aguirre at gmail.com Thu Jan 12 14:34:20 2017 From: matt.aguirre at gmail.com (Matthew Aguirre) Date: Thu, 12 Jan 2017 09:34:20 -0500 Subject: Packaging with pygtk In-Reply-To: <151c63230ef4f55229b58c5d9f37f5d1@cliftonts.co.uk> References: <151c63230ef4f55229b58c5d9f37f5d1@cliftonts.co.uk> Message-ID: <1484231660.3560.14@smtp.gmail.com> You can use launchpad to build and publish to the store if travis won't do it. That's how I went anyway. -- Matt On Thu, Jan 12, 2017 at 7:36 AM, gareth.france at cliftonts.co.uk wrote: > I have a graphical python project built with pygtk I wish to package, > I'm using travis CI to automatically package and release when I > commit to github. > > I have been informed that pygtk needs to be specifically installed > and bundled within snapcraft.yaml / travis.yaml but I don't seem to > be able to get it to work. Does anyone have any insight into how this > is done? > > Thanks > > -- > 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 jim.hodapp at canonical.com Thu Jan 12 14:48:40 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Thu, 12 Jan 2017 09:48:40 -0500 Subject: [System Enablement] New releases: wifi-ap=10 pulseaudio=8.0-3 In-Reply-To: References: Message-ID: +1 to moving ahead. On Thu, Jan 12, 2017 at 8:09 AM, Simon Fels wrote: > As both platform and commercial QA have approved the new snaps I would > like to go ahead with both snaps earlier than waiting for next Wednesday > and publishing them to stable. > > Any objections from anyone? > > regards, > Simon > > On Wed, Jan 4, 2017 at 2:51 PM, Simon Fels > wrote: > >> Hey everyone, >> >> A new release of the wifi-ap and pulseaudio snaps were pushed into the >> candidate channel. This release includes several improvements for both >> snaps. >> >> wifi-ap: >> >> * Switched to a unix domain socket instead of a local TCP endpoint to >> provide secure access to the management service REST API endpoint via a >> content interface based slot. >> >> * The management service now controls the access point process directly >> instead of both being two independent systemd service units. This makes >> coordination and application of configuration changes a lot easier. >> >> * New wifi-ap.status command is now available which shows the current >> status of the AP. >> >> * Improve configuration wizard which now has an auto mode as well which >> is executed directly after the installation of the snap to provide an >> out-of-the-box experience and directly spawn up an access point users can >> connect to. Wizard can be manually invoked too and guides the user through >> the configuration of the access point. >> >> * Added extensive testing of the whole snap via spread >> >> pulseaudio: >> >> This is the first release of the snap. We currently only support running >> pulseaudio in system mode and with that only support Ubuntu Core devices. >> Installing on classic desktop devices is possible but not yet supported. >> >> Please note that we require a kernel with ALSA support enabled which is >> not yet the case for all reference devices like the Raspberry Pi 2 or 3. >> >> --- >> >> An overview of which revisions / versions of the particular snaps are >> available in which channel is available at https://docs.google.com/spr >> eadsheets/d/1q2dmjPQ0Bam3p3frmmrX2WI3d1r8iusE0JTc0wm2jKM/edit#gid=0 >> >> The snaps have passed our engineering QA and will now be tested by the >> platform and commercial QA teams before the new versions are pushed to the >> stable channel. >> >> Bileto requests are: >> - wifi-ap: https://bileto.ubuntu.com/#/ticket/2333 >> - pulseaudio: https://bileto.ubuntu.com/#/ticket/2327 >> >> If you have any questions feel free to ping me. >> >> regards, >> Simon >> > > > -- > 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 max.brustkern at canonical.com Thu Jan 12 16:00:21 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Thu, 12 Jan 2017 11:00:21 -0500 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: So is that the bug to follow if I want to track when proxy usage will work in snapd on ubuntu core? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.aguirre at gmail.com Thu Jan 12 16:00:27 2017 From: matt.aguirre at gmail.com (Matthew Aguirre) Date: Thu, 12 Jan 2017 11:00:27 -0500 Subject: Packaging with pygtk In-Reply-To: <151c63230ef4f55229b58c5d9f37f5d1@cliftonts.co.uk> References: <151c63230ef4f55229b58c5d9f37f5d1@cliftonts.co.uk> Message-ID: <1484236827.3560.15@smtp.gmail.com> You can use launchpad to build and publish to the store if travis won't do it. That's how I went anyway. -- Matt On Thu, Jan 12, 2017 at 7:36 AM, gareth.france at cliftonts.co.uk wrote: > I have a graphical python project built with pygtk I wish to package, > I'm using travis CI to automatically package and release when I > commit to github. > > I have been informed that pygtk needs to be specifically installed > and bundled within snapcraft.yaml / travis.yaml but I don't seem to > be able to get it to work. Does anyone have any insight into how this > is done? > > Thanks > > -- > 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 Thu Jan 12 16:55:10 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 12 Jan 2017 17:55:10 +0100 Subject: OpenGLES on Raspberry Pi3 Message-ID: <1484240110.26677.82.camel@ubuntu.com> hi, i'm extremely happy to announce that with the most recent daily image [1] the raspberry Pi3 (Pi2 to follow the next days) image now defaults to use the VC4 driver for all display output and thus comes with full GLES support enabled by default. a bunch of people worked hard the recent days to make this happen, special thanks go to Paolo Pisati, Thomas Voß and the tireless Alberto Aguirre who helped to make this happen.  in lsmod you should see vc4 and the related drm drivers loaded and when starting a GLES app your syslog should show the following lines: GLRenderer: EGL vendor: Mesa Project GLRenderer: EGL version: 1.4 (DRI2) GLRenderer: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 GLRenderer: GL vendor: Broadcom GLRenderer: GL renderer: Gallium 0.4 on VC4 GLRenderer: GL version: OpenGL ES 2.0 Mesa 11.2.0 GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16 GLRenderer: GL max texture size = 2048 GLRenderer: GL framebuffer bits: RGBA=8880, depth=0, stencil=0 along with this you will now find a /dev/dri/card0 device on the system. if there are any issues, please file bugs... happy hacking ;) ciao oli [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ -------------- 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 Thu Jan 12 18:05:50 2017 From: mrsingh at ssni.com (Mritunjai Singh) Date: Thu, 12 Jan 2017 18:05:50 +0000 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) In-Reply-To: References: <1484159840.26677.55.camel@ubuntu.com> Message-ID: <80272fb51d344b5dba8b61c600fc2226@sfo-ex13-04.silverspringnet.com> @Simon Fels, thanks for the pointer. It would be great if you can further guide me writing the gadget snap. I have a Ubuntu x86_64 machine(VM) to which I will be connecting our RF Mesh network card through USB. The network card connects over serial and exposes a /dev/ttys0 port to work with. So do I need to write gadget snap for my network card or for my Ubuntu machine on which I have already installed snapcraft. Please guide and do let me know should you require any further information. Regards, Mritunjai From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Simon Fels Sent: Thursday, January 12, 2017 12:58 AM To: Snapcraft Subject: Re: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) You can add a serial port slot to a gadget snap.yaml like this: ttyS4: interface: serial-port path: /dev/ttyS4 This only applies to static serial port nodes. If you have one provided by an USB device you have to user a slightly different slot definition which refers the USB product/vendor id of your USB device: my-usb-serial: interface: serial-port usb-product: 0x1111 usb-vendor: 0x2222 path: /dev/my-usb-serial-port With the path attribute you can select a static path for the serial port node which your snap then gets access to once you connected the plug and the slot. The path needs to start with /dev/ and afterwards you're free to select a free node name. Internally the interface implementation will link the right /dev/ttyUSB* node to the specified path. Please note that you can define such a slot only on a gadget snap! So if you don't have your own gadget snap today, you need to create one for your device in order to get access to the serial port. I hope that helps. regards, Simon On Wed, Jan 11, 2017 at 7:37 PM, Oliver Grawert > wrote: hi, Am Mittwoch, den 11.01.2017, 17:59 +0000 schrieb Mritunjai Singh: > Hi All, > > Kindly refer to: https://github.com/snapcore/snapd/issues/2557 > > We are trying to get a head start on Core Snappy working with our RF > Mesh network card. It connects over serial and needs to be available > at boot. We first tried this using snap approach but due to missing > hotplugging serial-interface in current(latest) version of snapcraft, > serial i/o requests are being denied even if the snap has the > permission to use serial port. > > We have been suggested the gadget snap approach in order to expose > /dev/ttyS0 to the serial port interface for tunnccd snap to access > it. It would be very helpful if someone can point me to the working > example of a gadget snap with access to serial interface or any end > to end gadget snap example and its build steps. note that all our gadgets offer a console on serial by default, if you drive some external device via serial you might want to drop this console tty option. all our official gadgets are under https://github.com/snapcore/ .. namely the pi2-gadget, pi3-gadget, pc-gadget and dragonboard-gadget sub-trees if you want to take a look ... 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 max.brustkern at canonical.com Thu Jan 12 19:14:47 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Thu, 12 Jan 2017 14:14:47 -0500 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: So I created a system directory with the contents of /lib/systemd/system. I edited that file to contain the environment variables: nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service [Unit] Description=Snappy daemon Requires=snapd.socket [Service] ExecStart=/usr/lib/snapd/snapd EnvironmentFile=/etc/environment Restart=always http_proxy=http://squid.internal:3128 https_proxy=https://squid.internal:3128 [Install] WantedBy=multi-user.target I then did: nuclearbob at localhost:~$ sudo systemctl daemon-reload nuclearbob at localhost:~$ sudo service snapd restart I still don't seem to see snapd picking up on the proxy. I tried: sudo systemctl edit snapd I pasted in the file contents to there, but after that I get: nuclearbob at localhost:~$ sudo service snapd restart Failed to restart snapd.service: Unit snapd.service is not loaded properly: Invalid argument. See system logs and 'systemctl status snapd.service' for details. nuclearbob at localhost:~$ systemctl status snapd.service ● snapd.service - Snappy daemon Loaded: error (Reason: Invalid argument) Drop-In: /etc/systemd/system/snapd.service.d └─override.conf Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min 26s ago Main PID: 1339 (snapd) CGroup: /system.slice/snapd.service └─1339 /usr/lib/snapd/snapd Any additional tips to get snapd running on ubuntu core in the lab? On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop wrote: > > > On 12 January 2017 at 01:44, Max Brustkern > wrote: > >> I'm trying to run ubuntu core 16 in a kvm instance in an internal lab >> that requires a web proxy. This bug: >> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >> seems to cover how to do this on classic ubuntu, but the files that hold >> the environment variables used by snapd on an ubuntu core system are all on >> read-only filesystems. How do I set HTTPS_PROXY in a persistent way for >> snapd on that system? >> > > https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about > adding support for proxies to snapd (rather than have it use the system > environment variables, which is one implementation option but not always > what you want since that affects everything on the system). But that > doesn't help with your read-only filesystem sorry :-( > > (Hmm... disgusting hack idea.... since you can't create > /etc/systemd/system/snapd.service.d/ on your read-only filesystem, try > mounting that directory from somewhere. Extra points for using systemd to > mount the systemd service file overrides and setting up dependencies so it > does everything in the right order :-) ) > > > -- > Stuart Bishop > > -- > 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 michael.hudson at canonical.com Thu Jan 12 19:28:48 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Fri, 13 Jan 2017 08:28:48 +1300 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: On 13 January 2017 at 08:14, Max Brustkern wrote: > So I created a system directory with the contents of /lib/systemd/system. > I edited that file to contain the environment variables: > nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service > [Unit] > Description=Snappy daemon > Requires=snapd.socket > > [Service] > ExecStart=/usr/lib/snapd/snapd > EnvironmentFile=/etc/environment > Restart=always > http_proxy=http://squid.internal:3128 > https_proxy=https://squid.internal:3128 > That's not the right syntax, it should be Environment=http_proxy=http://squid.internal:3128 https_proxy=https://squid. internal:3128 See man systemd.exec for more details on this. Cheers, mwh > [Install] > WantedBy=multi-user.target > > I then did: > nuclearbob at localhost:~$ sudo systemctl daemon-reload > nuclearbob at localhost:~$ sudo service snapd restart > > I still don't seem to see snapd picking up on the proxy. I tried: > sudo systemctl edit snapd > I pasted in the file contents to there, but after that I get: > nuclearbob at localhost:~$ sudo service snapd restart > Failed to restart snapd.service: Unit snapd.service is not loaded > properly: Invalid argument. > See system logs and 'systemctl status snapd.service' for details. > nuclearbob at localhost:~$ systemctl status snapd.service > ● snapd.service - Snappy daemon > Loaded: error (Reason: Invalid argument) > Drop-In: /etc/systemd/system/snapd.service.d > └─override.conf > Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min 26s ago > Main PID: 1339 (snapd) > CGroup: /system.slice/snapd.service > └─1339 /usr/lib/snapd/snapd > > Any additional tips to get snapd running on ubuntu core in the lab? > > On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < > stuart.bishop at canonical.com> wrote: > >> >> >> On 12 January 2017 at 01:44, Max Brustkern >> wrote: >> >>> I'm trying to run ubuntu core 16 in a kvm instance in an internal lab >>> that requires a web proxy. This bug: >>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>> seems to cover how to do this on classic ubuntu, but the files that hold >>> the environment variables used by snapd on an ubuntu core system are all on >>> read-only filesystems. How do I set HTTPS_PROXY in a persistent way for >>> snapd on that system? >>> >> >> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >> adding support for proxies to snapd (rather than have it use the system >> environment variables, which is one implementation option but not always >> what you want since that affects everything on the system). But that >> doesn't help with your read-only filesystem sorry :-( >> >> (Hmm... disgusting hack idea.... since you can't create >> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, try >> mounting that directory from somewhere. Extra points for using systemd to >> mount the systemd service file overrides and setting up dependencies so it >> does everything in the right order :-) ) >> >> >> -- >> Stuart Bishop >> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simos.lists at googlemail.com Fri Jan 13 00:32:36 2017 From: simos.lists at googlemail.com (Simos Xenitellis) Date: Fri, 13 Jan 2017 02:32:36 +0200 Subject: Use of build-properties in the schema is deprecated. In-Reply-To: References: Message-ID: On Wed, Jan 11, 2017 at 1:26 PM, Jenny Murphy wrote: > I recently upgraded to snapcraft 2.24 (from 2.22) for building my .snaps. > Now I am getting the following warning : > > Use of build-properties in the schema is deprecated. > Plugins should now implement get_build_properties > > This was a recent change, https://github.com/snapcore/snapcraft/blame/master/snapcraft/_baseplugin.py#L65 and it affects even tutorials, such as http://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/ I suppose there is an easy solution to adjust the .yaml file in order to produce a nice/clean build, and I am interested in learning about that as well. Simos From kyle.fazzari at canonical.com Fri Jan 13 03:33:05 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Thu, 12 Jan 2017 19:33:05 -0800 Subject: Use of build-properties in the schema is deprecated. In-Reply-To: References: Message-ID: On 01/12/2017 04:32 PM, Simos Xenitellis wrote: > On Wed, Jan 11, 2017 at 1:26 PM, Jenny Murphy > wrote: >> I recently upgraded to snapcraft 2.24 (from 2.22) for building my .snaps. >> Now I am getting the following warning : >> >> Use of build-properties in the schema is deprecated. >> Plugins should now implement get_build_properties >> >> > > This was a recent change, > https://github.com/snapcore/snapcraft/blame/master/snapcraft/_baseplugin.py#L65 > and it affects even tutorials, such as > http://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic-confinement/ > > I suppose there is an easy solution to adjust the .yaml file in order > to produce a nice/clean build, > and I am interested in learning about that as well. Yeah, this is internal to the plugins. If you're not using any custom local plugins you can disregard these deprecation notices. We ended up cutting a release right after the feature was introduced but before all of snapcraft's built-in plugins moved to using it. Don't worry-- this has been completed in master, and these deprecation notices will disappear in the next release. -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. kyle at canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gustavo.niemeyer at canonical.com Fri Jan 13 07:36:01 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 13 Jan 2017 09:36:01 +0200 Subject: Bug tracking Message-ID: Quick update on our bug tracking practices: https://launchpad.net/snapd was opened up, and we invite all bugs which affect snapd to be explicitly assigned to this project. This will make slightly easier to track and update issues which require explicit action on snapd vs. those which target snapcraft or other pieces of the puzzle. Thanks for your help, gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From seb128 at ubuntu.com Fri Jan 13 08:28:26 2017 From: seb128 at ubuntu.com (Sebastien Bacher) Date: Fri, 13 Jan 2017 09:28:26 +0100 Subject: Use of build-properties in the schema is deprecated. In-Reply-To: References: Message-ID: <9e1257bd-fcd0-d26b-fd07-38db0e0d5dd2@ubuntu.com> Hey Kyle, Le 13/01/2017 à 04:33, Kyle Fazzari a écrit : > We ended up > cutting a release right after the feature was introduced but before all > of snapcraft's built-in plugins moved to using it. Was the release rolled out knowing that the warnings were there or was that an overlook? It sounds like something worth adding to the new-version-checklist to make sure we don't confuse users this way again with futur updates... Cheers, Sebastien Bacher From jenny.murphy at episensor.com Fri Jan 13 11:18:34 2017 From: jenny.murphy at episensor.com (Jenny Murphy) Date: Fri, 13 Jan 2017 11:18:34 +0000 Subject: Use of build-properties in the schema is deprecated. In-Reply-To: References: Message-ID: Hi, Ok thanks for that. Jenny On 13 January 2017 at 03:33, Kyle Fazzari wrote: > > > On 01/12/2017 04:32 PM, Simos Xenitellis wrote: > > On Wed, Jan 11, 2017 at 1:26 PM, Jenny Murphy > > wrote: > >> I recently upgraded to snapcraft 2.24 (from 2.22) for building my > .snaps. > >> Now I am getting the following warning : > >> > >> Use of build-properties in the schema is deprecated. > >> Plugins should now implement get_build_properties > >> > >> > > > > This was a recent change, > > https://github.com/snapcore/snapcraft/blame/master/ > snapcraft/_baseplugin.py#L65 > > and it affects even tutorials, such as > > http://insights.ubuntu.com/2017/01/09/how-to-snap-introducing-classic- > confinement/ > > > > I suppose there is an easy solution to adjust the .yaml file in order > > to produce a nice/clean build, > > and I am interested in learning about that as well. > > Yeah, this is internal to the plugins. If you're not using any custom > local plugins you can disregard these deprecation notices. We ended up > cutting a release right after the feature was introduced but before all > of snapcraft's built-in plugins moved to using it. Don't worry-- this > has been completed in master, and these deprecation notices will > disappear in the next release. > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- *Jenny Murphy* *EpiSensor, Georges Quay House, Georges Quay, Limerick, Ireland* jenny.murphy at episensor.com t | +353 (0) 61 512 511 w | http://www.episensor.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Jan 13 16:32:26 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 13 Jan 2017 17:32:26 +0100 Subject: Kodi on Mir on Pi3 ubuntu-core image .... Message-ID: <1484325146.26677.86.camel@ubuntu.com> hi, just to whet your appetite ... https://plus.google.com/+OliverGrawert/posts/6S6U4MKG32y?sfc=true ;) 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 kyle.fazzari at canonical.com Fri Jan 13 17:04:15 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Fri, 13 Jan 2017 09:04:15 -0800 Subject: Use of build-properties in the schema is deprecated. In-Reply-To: <9e1257bd-fcd0-d26b-fd07-38db0e0d5dd2@ubuntu.com> References: <9e1257bd-fcd0-d26b-fd07-38db0e0d5dd2@ubuntu.com> Message-ID: <370a850b-1b98-66a5-2e9b-ec258ccb6143@canonical.com> On 01/13/2017 12:28 AM, Sebastien Bacher wrote: > Hey Kyle, > > Le 13/01/2017 à 04:33, Kyle Fazzari a écrit : >> We ended up >> cutting a release right after the feature was introduced but before all >> of snapcraft's built-in plugins moved to using it. > > Was the release rolled out knowing that the warnings were there or was > that an overlook? Yes, this was an oversight, and we do apologize! -- 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 leo.arias at canonical.com Fri Jan 13 17:38:43 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 13 Jan 2017 11:38:43 -0600 Subject: call for testing: snapcraft Message-ID: Hello! We are now ready to make the first snapcraft release of 2017, and the 2.25 package is now in the proposed pocket of xenial and yakkety. We would like to give it a little more testing before we move it forward and deliver it to all our users Anybody can help. As I mentioned before, you can get a clean and safe environment following the summaries of the past testing days: https://wiki.ubuntu.com/Testing/UbuntuTestingDay Here you can find some instructions to enable proposed: http://elopio.net/blog/test-sru/ There is a guide for testing in the 2.25 SRU bug: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1656291/comments/3 You will notice that the tests mentioned in there are vague and open-ended. That's on purpose because we have already tested and automated checks for the specific bug fixes and new features. What we want to encourage here is exploration and experimentation; use that text as a guide to try to break snapcraft. The release cycle of snapcraft is faster than normal packages, so we start testing on Thursday or Friday to make the release on Monday. But if you want to help and don't have time this weekend, we always appreciate if you try snapcraft in xenial, yakkety and zesty, anytime. Please send me an email if you have questions, if you see something weird or if you think that you have found a bug. And please don't change the tag in the SRU bug, I will do that on Sunday if everything goes well. pura vida -- ¡paz y baile! http://www.ubuntu.com From jamie at canonical.com Fri Jan 13 18:26:40 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 13 Jan 2017 12:26:40 -0600 Subject: Kodi on Mir on Pi3 ubuntu-core image .... In-Reply-To: <1484325146.26677.86.camel@ubuntu.com> References: <1484325146.26677.86.camel@ubuntu.com> Message-ID: <1484332000.3177.9.camel@canonical.com> On Fri, 2017-01-13 at 17:32 +0100, Oliver Grawert wrote: > hi, > > just to whet your appetite ... > > https://plus.google.com/+OliverGrawert/posts/6S6U4MKG32y?sfc=true Are there bugs for why kodi and mir-kiosk need devmode? -- 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 ogra at ubuntu.com Fri Jan 13 19:05:52 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 13 Jan 2017 20:05:52 +0100 Subject: Kodi on Mir on Pi3 ubuntu-core image .... In-Reply-To: <1484332000.3177.9.camel@canonical.com> References: <1484325146.26677.86.camel@ubuntu.com> <1484332000.3177.9.camel@canonical.com> Message-ID: <1484334352.17893.25.camel@ubuntu.com> hi, On Fr, 2017-01-13 at 12:26 -0600, Jamie Strandboge wrote: > On Fri, 2017-01-13 at 17:32 +0100, Oliver Grawert wrote: > > > > hi, > > > > just to whet your appetite ... > > > > https://plus.google.com/+OliverGrawert/posts/6S6U4MKG32y?sfc=true > > Are there bugs for why kodi and mir-kiosk need devmode? > i'm not sure it is needed ... to be honest i didnt expect this to work at all, it suddenly came up on screen and just worked after some tinkering so i wrote down what was in my shell history :) i'll try to get a proper setup and even a kodi image working the next weeks (waiting for a recent mir to actually work on the pi, brandon landed the kodi-mir bits upstream so i'll try to use this one instead of my hacked together snap etc etc) if i actually hit interface issues i'll file bugs ;) 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 jamie at canonical.com Fri Jan 13 19:17:42 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 13 Jan 2017 13:17:42 -0600 Subject: Kodi on Mir on Pi3 ubuntu-core image .... In-Reply-To: <1484334352.17893.25.camel@ubuntu.com> References: <1484325146.26677.86.camel@ubuntu.com> <1484332000.3177.9.camel@canonical.com> <1484334352.17893.25.camel@ubuntu.com> Message-ID: <1484335062.3177.15.camel@canonical.com> On Fri, 2017-01-13 at 20:05 +0100, Oliver Grawert wrote: > hi, > On Fr, 2017-01-13 at 12:26 -0600, Jamie Strandboge wrote: > > > > On Fri, 2017-01-13 at 17:32 +0100, Oliver Grawert wrote: > > > > > > > > > hi, > > > > > > just to whet your appetite ... > > > > > > https://plus.google.com/+OliverGrawert/posts/6S6U4MKG32y?sfc=true > > Are there bugs for why kodi and mir-kiosk need devmode? > > > i'm not sure it is needed ... to be honest i didnt expect this to work > at all, it suddenly came up on screen and just worked after some > tinkering so i wrote down what was in my shell history :) > > i'll try to get a proper setup and even a kodi image working the next > weeks (waiting for a recent mir to actually work on the pi, brandon > landed the kodi-mir bits upstream so i'll try to use this one instead > of my hacked together snap etc etc) > > if i actually hit interface issues i'll file bugs ;) > Great, thanks! Btw, nice work to everyone involved :) -- 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 Jan 13 20:33:47 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Fri, 13 Jan 2017 15:33:47 -0500 Subject: Command to check for updates? Message-ID: I'm attempting to run automated upgrade tests from the stable release to candidate versions. If I run snap refresh x and there is no new version of x, the snap command exits with status 1. Is there a command I can use to check if an update is available and only install in that case? Right now I don't know how to distinguish an update failure from a case where the system is already up to date. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Fri Jan 13 20:46:37 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 13 Jan 2017 21:46:37 +0100 Subject: Classic confinement and core_dynamic_linker Message-ID: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Hello all, Hearing about classic confinement was rather exciting given that it seems tailor-made for the use-cases of my current WiP snaps for the ldc2 D compiler and the dub D build system: https://github.com/WebDrake/ldc2.snap/pull/1 https://github.com/WebDrake/dub.snap/pull/1 However, I'm running into difficulties every time I try to do a `snapcraft cleanbuild`: part-way through the build process I invariably get an error: classic confinement requires the core_dynamic_linker to be set I've discovered and tried the proposed workaround here: https://bugs.launchpad.net/snapcraft/+bug/1650946/comments/11 ... but it seems to make no difference. Can anyone advise what else needs to be done to build a package with `classic` confinement? My system is Ubuntu 16.04 with snapcraft 2.24 and snapd 2.20.1 (both installed from the normal Ubuntu apt repos). Thanks & best wishes, -- Joe From kyle.fazzari at canonical.com Fri Jan 13 22:18:29 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Fri, 13 Jan 2017 14:18:29 -0800 Subject: Classic confinement and core_dynamic_linker In-Reply-To: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: On 01/13/2017 12:46 PM, Joseph Rushton Wakeling wrote: > Hello all, > > Hearing about classic confinement was rather exciting given that it > seems tailor-made for the use-cases of my current WiP snaps for the ldc2 > D compiler and the dub D build system: > https://github.com/WebDrake/ldc2.snap/pull/1 > https://github.com/WebDrake/dub.snap/pull/1 > > However, I'm running into difficulties every time I try to do a > `snapcraft cleanbuild`: part-way through the build process I invariably > get an error: > > classic confinement requires the core_dynamic_linker to be set > > I've discovered and tried the proposed workaround here: > https://bugs.launchpad.net/snapcraft/+bug/1650946/comments/11 > > ... but it seems to make no difference. Can anyone advise what else > needs to be done to build a package with `classic` confinement? > > My system is Ubuntu 16.04 with snapcraft 2.24 and snapd 2.20.1 (both > installed from the normal Ubuntu apt repos). Since you're using cleanbuild, you would actually need the core snap installed in the lxc container being used, which I don't think is currently possible in lxc (though maybe it is nowadays, I know work was being done in that area). Have you tried _not_ doing this in cleanbuild, on a system with the core snap installed? -- 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 joseph.wakeling at webdrake.net Fri Jan 13 23:20:45 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 14 Jan 2017 00:20:45 +0100 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: <7f03576b-d0a1-1cf7-50ab-54a650677d55@webdrake.net> On 13/01/17 23:18, Kyle Fazzari wrote: > Since you're using cleanbuild, you would actually need the core snap > installed in the lxc container being used, which I don't think is > currently possible in lxc (though maybe it is nowadays, I know work was > being done in that area). > > Have you tried _not_ doing this in cleanbuild, on a system with the core > snap installed? Ah, thanks. I did consider that but thought it would be a bit odd for a new feature to come without a cleanbuild of it being possible. Anyway, doing a regular `snapcraft build` means the `core_dynamic_linker` error vanishes, but this time I get linker errors when building LDC: error while loading shared libraries: libconfig.so.9: cannot open shared object file: No such file or directory `libconfig++-dev` and `libconfig-dev` are both installed along with their dependencies (libconfig++-dev is specified as a build dependency), and I _don't_ get this linker error when confinement is set to `strict`. From sergio.schvezov at canonical.com Sat Jan 14 02:26:06 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Sat, 14 Jan 2017 04:26:06 +0200 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: El 13 ene. 2017 10:47 PM, "Joseph Rushton Wakeling" < joseph.wakeling at webdrake.net> escribió: Hello all, Hearing about classic confinement was rather exciting given that it seems tailor-made for the use-cases of my current WiP snaps for the ldc2 D compiler and the dub D build system: https://github.com/WebDrake/ldc2.snap/pull/1 https://github.com/WebDrake/dub.snap/pull/1 However, I'm running into difficulties every time I try to do a `snapcraft cleanbuild`: part-way through the build process I invariably get an error: classic confinement requires the core_dynamic_linker to be set I've discovered and tried the proposed workaround here: https://bugs.launchpad.net/snapcraft/+bug/1650946/comments/11 ... but it seems to make no difference. Can anyone advise what else needs to be done to build a package with `classic` confinement? A generic solution for build systems and CI is being worked on. Thanks for taking notice. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ribalkin at gmail.com Sat Jan 14 15:55:43 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Sat, 14 Jan 2017 15:55:43 +0000 Subject: systemd reload (ExevReload) support In-Reply-To: References: Message-ID: Hi, Could you tell me if there is systemd ExecReload support in snap.yaml? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.tilloy at canonical.com Sat Jan 14 18:15:24 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Sat, 14 Jan 2017 19:15:24 +0100 Subject: stable 0ad snap Message-ID: Hi all, I’m happy to announce there's a stable snap in the store for 0ad, the real-time strategy game of ancient warfare (Alpha 21 Ulysses): https://uappexplorer.com/app/play0ad.osomon. The snap is available for i386 and amd64, and requires manual connection of the process-control interface after installation: snap install play0ad snap connect play0ad:process-control ubuntu-core:process-control Single-player and multi-player games work, the map editor doesn't (it should once the fix for https://launchpad.net/bugs/1653955 is released). Feedback welcome. Enjoy! Olivier From thibaut.rouffineau at canonical.com Sat Jan 14 19:43:10 2017 From: thibaut.rouffineau at canonical.com (Thibaut Rouffineau) Date: Sat, 14 Jan 2017 19:43:10 +0000 Subject: Spotify-Web-Player-for-Linux as a snap Message-ID: Hi Matthew Once again, great job on the snap! Meet the snapcraft list! (feel free to join too : here ) Copying in your messages below to see if someone can help! Cheers T ---------- Forwarded message ---------- From: Matthew James Date: Sat, Jan 14, 2017 at 5:31 PM Subject: Re: Spotify-Web-Player-for-Linux as a snap To: Thibaut Rouffineau Just to update that the snap is now under 'manual review' after it failed automatic testing due to platform lint tags, perhaps because I built with electron-builder. On 14 Jan 2017 5:05 p.m., "Matthew James" wrote: Hi Thibaut, I have been able to make 32 and 64bit snaps in the next version of Spotify Web Player for Linux, version 1.0.30. I made a snap package on the Ubuntu Store and uploaded the 64bit snap but I cannot upload the 32bit snap unless I upload a new update. How would I be able to offer both? At the moment I can also host it on GitHub with the AppImages too. Regards, Matthew -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Sun Jan 15 02:55:59 2017 From: leo.arias at canonical.com (Leo Arias) Date: Sat, 14 Jan 2017 20:55:59 -0600 Subject: classic snap fails to find libraries Message-ID: Hello, I'm testing the classic mode and aliases making a snap for mosh. When I try to run it, I get this error: $ mosh 192.168.122.29 mosh-client: error while loading shared libraries: libprotobuf.so.9: cannot open shared object file: No such file or directory Died at /snap/mosh/x1/bin/mosh line 311. When I build the snap without classic mode, that library is in prime/usr/lib/x86_64-linux-gnu/. With devmode, it is not included in the snap. Here is my yaml: https://github.com/elopio/mosh/blob/snapcraft/snapcraft.yaml Am I doing something wrong in there? -- ¡paz y baile! http://www.ubuntu.com From luke.williams at canonical.com Sun Jan 15 06:58:28 2017 From: luke.williams at canonical.com (Luke Williams) Date: Sat, 14 Jan 2017 22:58:28 -0800 Subject: Apparmor error when using classic mode Message-ID: Hello, I have the following error when I try to install my snap in classic mode: root at ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap --classic --force-dangerous error: cannot perform the following tasks: - Setup snap "flexswitch" (unset) security profiles (cannot setup apparmor for snap "flexswitch": cannot load apparmor profile "snap.flex switch.flexswitch": cannot load apparmor profile: exit status 1 apparmor_parser output: profile has merged rule with conflicting x modifiers ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to load ) - Setup snap "flexswitch" (unset) security profiles (cannot load apparmor profile "snap.flexswitch.flexswitch": cannot load apparmor prof ile: exit status 1 apparmor_parser output: profile has merged rule with conflicting x modifiers ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to load ) I cannot find any information on why it is failing to install. Any thing I should look at to see what is keeping this from working or any more information you need to assist in troubleshooting? I am trying to install this snap on 16.04 Server. -- Thanks, Luke Williams - Technical Partner Manager, Network Switches and Ubuntu-Core luke.williams at canonical.com www.canonical.com || www.ubuntu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Sun Jan 15 08:11:59 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Sun, 15 Jan 2017 08:11:59 +0000 Subject: Issues working with pygtk Message-ID: I have been struggling to get my latest creation to package, whatever I try it fails trying to include pygtk. My builds are automated on git through travis and this seemed to be where the problem lay. Today though I thought I'd try a local build and it still fails. The problem seems to be with the way it is obtaining pygtk as one of the python packages. It spits out this error at the end of the build: ******************************************************************** * Building PyGTK using distutils is only supported on windows. * * To build PyGTK in a supported way, read the INSTALL file. * ******************************************************************** I presume that I need to add some entries to the yaml to instruct it to download and build pygtk rather than just including it as a python module. Being new to this I'm not sure where to start though. Any help greatly appreciated. From stuart.bishop at canonical.com Mon Jan 16 04:54:15 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Mon, 16 Jan 2017 11:54:15 +0700 Subject: Command to check for updates? In-Reply-To: References: Message-ID: On 14 January 2017 at 03:33, Max Brustkern wrote: > I'm attempting to run automated upgrade tests from the stable release to > candidate versions. If I run > snap refresh x > and there is no new version of x, the snap command exits with status 1. Is > there a command I can use to check if an update is available and only > install in that case? Right now I don't know how to distinguish an update > failure from a case where the system is already up to date. > According to https://bugs.launchpad.net/layer-snap/+bug/1588322 , this was supposed to have been fixed with 2.18. -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From spencertparkin at gmail.com Mon Jan 16 07:07:51 2017 From: spencertparkin at gmail.com (Spencer) Date: Mon, 16 Jan 2017 00:07:51 -0700 Subject: Snapping with scons Message-ID: <17380F19-73F1-48F2-9B9D-70FA4E2B6E2D@gmail.com> Hi. I have a project with 2 dependencies so I need 3 parts in my yaml file. The dependencies install correctly during snapping, but when my program starts to compile, it can't locate the header files for the library dependencies. There is no mystery here as to why that is the case. My question, however, is: what do I put in my scons file so that I can locate the header files during snapping? I've been looking at the snapcraft python code, but I can't seem to find out what, if any, additional environment variables there may be setup for me to use in my scons file so that I can locate headers and libraries. Is there a different way to go about it? Thanks. From michael.vogt at canonical.com Mon Jan 16 07:36:00 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Mon, 16 Jan 2017 08:36:00 +0100 Subject: New snapd 2.21 release Message-ID: <20170116073600.GG23539@bod> Hi, The snappy team is proud to announce the release of snapd 2.21. After a refreshing holiday season we are back in action and have built some interesting new features! The focus was improving classic confinement and aliases support. Here are just some of the highlights: - improve alias handling (auto-alias improvements, new `snap aliases` command to list them and their status) - fix install of classic confined snaps from the store - improve output of "snap find" when nothing is found - switch to a pure go based gettext - fixes in the "snap info" output (fix remote sizes, fix tracked channel output) - allow using new snapd from the core snap - new interfaces: - physical-memory-*, io-ports-control - interface improvements: - upower-observer - allow getsockopt by default everyhwere This release is uploaded to the Ubuntu 14.04/16.04/16.10 "proposed" pocket. It will also be available in 17.04 and in the "candidate" channel for the "core" and "ubuntu-core" snaps. Other distros will follow shortly. The stable channel continues to have the 2.20 version. If you would like to test out this new snapd version on your Ubuntu Core device you can use the command: $ snap refresh --candidate core On the classic distribution you can help testing by enabling -proposed and then installing snapd [1]. Hope you enjoy the new release, if there are any questions, please let us know! Cheers, Michael (on behalf of the snappy team) [1] https://wiki.ubuntu.com/Testing/EnableProposed From manik at canonical.com Mon Jan 16 07:45:02 2017 From: manik at canonical.com (Manik Taneja) Date: Sun, 15 Jan 2017 23:45:02 -0800 Subject: create-user primitive Message-ID: hi there, i was trying to verify the functionality of the snapd create-user primitive and see this error- [image: Inline image 1] is this expected behavior? why can't i have more than 1 user managing the device? separately, i noticed that this primitive has been deprecated from the help menu- [image: Inline image 2] can someone please help me understand why this is the case? finally, at the first boot, device ownership must be established via Ubuntu SSO. given that, and the fact that create-user does not allow extra user creation, how and when can someone use it? /manik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 68424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 224613 bytes Desc: not available URL: From mark at ubuntu.com Mon Jan 16 09:02:49 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 11:02:49 +0200 Subject: Apparmor error when using classic mode In-Reply-To: References: Message-ID: <87ad3bf5-0c9b-67bd-24c2-f2db3bc9d7cf@ubuntu.com> On 15/01/17 08:58, Luke Williams wrote: > Hello, > > I have the following error when I try to install my snap in classic mode: > > root at ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap > --classic --force-dangerous > > error: cannot perform the following tasks: > > - Setup snap "flexswitch" (unset) security profiles (cannot setup > apparmor for snap "flexswitch": cannot load apparmor profile "snap.flex > switch.flexswitch": cannot load apparmor profile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed > to load > ) > > - Setup snap "flexswitch" (unset) security profiles (cannot load > apparmor profile "snap.flexswitch.flexswitch": cannot load apparmor prof > ile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed > to load > ) > > > I cannot find any information on why it is failing to install. Any > thing I should look at to see what is keeping this from working or any > more information you need to assist in troubleshooting? > > I am trying to install this snap on 16.04 Server. I have a feeling this is when one tries to combine "confinement: classic" with plugs on commands. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Mon Jan 16 09:02:49 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 11:02:49 +0200 Subject: Apparmor error when using classic mode In-Reply-To: References: Message-ID: <87ad3bf5-0c9b-67bd-24c2-f2db3bc9d7cf@ubuntu.com> On 15/01/17 08:58, Luke Williams wrote: > Hello, > > I have the following error when I try to install my snap in classic mode: > > root at ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap > --classic --force-dangerous > > error: cannot perform the following tasks: > > - Setup snap "flexswitch" (unset) security profiles (cannot setup > apparmor for snap "flexswitch": cannot load apparmor profile "snap.flex > switch.flexswitch": cannot load apparmor profile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed > to load > ) > > - Setup snap "flexswitch" (unset) security profiles (cannot load > apparmor profile "snap.flexswitch.flexswitch": cannot load apparmor prof > ile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed > to load > ) > > > I cannot find any information on why it is failing to install. Any > thing I should look at to see what is keeping this from working or any > more information you need to assist in troubleshooting? > > I am trying to install this snap on 16.04 Server. I have a feeling this is when one tries to combine "confinement: classic" with plugs on commands. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Mon Jan 16 09:05:38 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 16 Jan 2017 10:05:38 +0100 Subject: Apparmor error when using classic mode In-Reply-To: <87ad3bf5-0c9b-67bd-24c2-f2db3bc9d7cf@ubuntu.com> References: <87ad3bf5-0c9b-67bd-24c2-f2db3bc9d7cf@ubuntu.com> Message-ID: Hey This bug is fixed in the recently released snapd 2.21. Mark's suggestion is correct. You should not (until 2.21) combine interfaces and classic confinement. Since you may be interested what happens when you do. In 2.21 you can install a snap that is using classic confinement with --jailmode which will enable all those plugs/slots and treat it as any other snap. I hope this helps you out Best regards ZK On Mon, Jan 16, 2017 at 10:02 AM, Mark Shuttleworth wrote: > On 15/01/17 08:58, Luke Williams wrote: > > Hello, > > I have the following error when I try to install my snap in classic mode: > > root at ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap --classic > --force-dangerous > error: cannot perform the following tasks: > > - Setup snap "flexswitch" (unset) security profiles (cannot setup apparmor > for snap "flexswitch": cannot load apparmor profile "snap.flex > switch.flexswitch": cannot load apparmor profile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to > load > ) > > - Setup snap "flexswitch" (unset) security profiles (cannot load apparmor > profile "snap.flexswitch.flexswitch": cannot load apparmor prof > ile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to > load > ) > > > I cannot find any information on why it is failing to install. Any thing I > should look at to see what is keeping this from working or any more > information you need to assist in troubleshooting? > > I am trying to install this snap on 16.04 Server. > > > I have a feeling this is when one tries to combine "confinement: classic" > with plugs on commands. > > Mark > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Mon Jan 16 09:05:38 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 16 Jan 2017 10:05:38 +0100 Subject: Apparmor error when using classic mode In-Reply-To: <87ad3bf5-0c9b-67bd-24c2-f2db3bc9d7cf@ubuntu.com> References: <87ad3bf5-0c9b-67bd-24c2-f2db3bc9d7cf@ubuntu.com> Message-ID: Hey This bug is fixed in the recently released snapd 2.21. Mark's suggestion is correct. You should not (until 2.21) combine interfaces and classic confinement. Since you may be interested what happens when you do. In 2.21 you can install a snap that is using classic confinement with --jailmode which will enable all those plugs/slots and treat it as any other snap. I hope this helps you out Best regards ZK On Mon, Jan 16, 2017 at 10:02 AM, Mark Shuttleworth wrote: > On 15/01/17 08:58, Luke Williams wrote: > > Hello, > > I have the following error when I try to install my snap in classic mode: > > root at ubuntu:~# snap install flexswitch_1.0.0.178.0_amd64.snap --classic > --force-dangerous > error: cannot perform the following tasks: > > - Setup snap "flexswitch" (unset) security profiles (cannot setup apparmor > for snap "flexswitch": cannot load apparmor profile "snap.flex > switch.flexswitch": cannot load apparmor profile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to > load > ) > > - Setup snap "flexswitch" (unset) security profiles (cannot load apparmor > profile "snap.flexswitch.flexswitch": cannot load apparmor prof > ile: exit status 1 > > apparmor_parser output: > > profile has merged rule with conflicting x modifiers > > ERROR processing regexs for profile snap.flexswitch.flexswitch, failed to > load > ) > > > I cannot find any information on why it is failing to install. Any thing I > should look at to see what is keeping this from working or any more > information you need to assist in troubleshooting? > > I am trying to install this snap on 16.04 Server. > > > I have a feeling this is when one tries to combine "confinement: classic" > with plugs on commands. > > Mark > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.dandrea at canonical.com Mon Jan 16 09:12:30 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Mon, 16 Jan 2017 09:12:30 +0000 Subject: Spotify-Web-Player-for-Linux as a snap In-Reply-To: References: Message-ID: Hi Matthew, You've set your snap to use the 'platform' interface, but no such interface exists. If you remove that line and 'unity8', then re-upload, it should pass review. Do you recall what you read that referenced a 'platform' interface? If there's some outdated documentation out there, I'd like to get it fixed. Let us know if you need any more help, and thanks for snapping Spotify! On Sat, 14 Jan 2017 at 21:44 Thibaut Rouffineau < thibaut.rouffineau at canonical.com> wrote: > Hi Matthew > > Once again, great job on the snap! > > Meet the snapcraft list! (feel free to join too : here > > ) > > Copying in your messages below to see if someone can help! > > Cheers > > T > > ---------- Forwarded message ---------- > From: *Matthew James* > Date: Sat, Jan 14, 2017 at 5:31 PM > Subject: Re: Spotify-Web-Player-for-Linux as a snap > To: Thibaut Rouffineau > > > Just to update that the snap is now under 'manual review' after it failed > automatic testing due to platform lint tags, perhaps because I built with > electron-builder. > > On 14 Jan 2017 5:05 p.m., "Matthew James" wrote: > > Hi Thibaut, > > I have been able to make 32 and 64bit snaps in the next version of Spotify > Web Player for Linux, version 1.0.30. I made a snap package on the Ubuntu > Store and uploaded the 64bit snap but I cannot upload the 32bit snap unless > I upload a new update. How would I be able to offer both? At the moment I > can also host it on GitHub with the AppImages too. > > > Regards, > > Matthew > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Mon Jan 16 10:02:43 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Mon, 16 Jan 2017 11:02:43 +0100 Subject: Switching to a non-native package Message-ID: I'd like to work on enabling Debian in the CI loop and I was thinking that it would be somewhat easier we switched to non-native packaging in the upstream tree and similarly switched to quilt in the Debian tree (we could have separate packaging trees for sid / stretch if that would help). Since my view may be simplistic I would like to ask the current most active Debian maintainers of snapd for opinion. Right now almost all of the CI in the tree is performed on the packaging that is in the tree as well. The notable exception is 14.04 which has a separate packaging branch. This is unrealistic as the Debian packaging tree is widely different and even if we built a package from the in-tree debian directory and tested it on a real Debian machine the result would not be representative of what a subsequent upstream release would look like in Debian. I'd like to propose that we remove the debian directory from the upstream repository (no special casing) and work on ensuring that Ubuntu and subsequently Debian are tested equally well whenever we make a pull request. Best regards ZK From ngompa13 at gmail.com Mon Jan 16 11:24:54 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Mon, 16 Jan 2017 06:24:54 -0500 Subject: Switching to a non-native package In-Reply-To: References: Message-ID: On Mon, Jan 16, 2017 at 5:02 AM, Zygmunt Krynicki wrote: > I'd like to work on enabling Debian in the CI loop and I was thinking > that it would be somewhat easier we switched to non-native packaging > in the upstream tree and similarly switched to quilt in the Debian > tree (we could have separate packaging trees for sid / stretch if that > would help). Since my view may be simplistic I would like to ask the > current most active Debian maintainers of snapd for opinion. > > Right now almost all of the CI in the tree is performed on the > packaging that is in the tree as well. The notable exception is 14.04 > which has a separate packaging branch. This is unrealistic as the > Debian packaging tree is widely different and even if we built a > package from the in-tree debian directory and tested it on a real > Debian machine the result would not be representative of what a > subsequent upstream release would look like in Debian. > > I'd like to propose that we remove the debian directory from the > upstream repository (no special casing) and work on ensuring that > Ubuntu and subsequently Debian are tested equally well whenever we > make a pull request. > Splitting it out and using a similar repository structure to what you had previously for snap-confine would probably be a good move. That will also make things simpler for integrating in other distributions later (openSUSE, etc.). -- 真実はいつも一つ！/ Always, there's only one truth! From ngompa13 at gmail.com Mon Jan 16 11:26:04 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Mon, 16 Jan 2017 06:26:04 -0500 Subject: Switching to a non-native package In-Reply-To: References: Message-ID: On Mon, Jan 16, 2017 at 6:24 AM, Neal Gompa wrote: > On Mon, Jan 16, 2017 at 5:02 AM, Zygmunt Krynicki > wrote: >> I'd like to work on enabling Debian in the CI loop and I was thinking >> that it would be somewhat easier we switched to non-native packaging >> in the upstream tree and similarly switched to quilt in the Debian >> tree (we could have separate packaging trees for sid / stretch if that >> would help). Since my view may be simplistic I would like to ask the >> current most active Debian maintainers of snapd for opinion. >> >> Right now almost all of the CI in the tree is performed on the >> packaging that is in the tree as well. The notable exception is 14.04 >> which has a separate packaging branch. This is unrealistic as the >> Debian packaging tree is widely different and even if we built a >> package from the in-tree debian directory and tested it on a real >> Debian machine the result would not be representative of what a >> subsequent upstream release would look like in Debian. >> >> I'd like to propose that we remove the debian directory from the >> upstream repository (no special casing) and work on ensuring that >> Ubuntu and subsequently Debian are tested equally well whenever we >> make a pull request. >> > > Splitting it out and using a similar repository structure to what you > had previously for snap-confine would probably be a good move. That > will also make things simpler for integrating in other distributions > later (openSUSE, etc.). > Errm, Fedora, openSUSE, and other distributions that already use this split naturally. -- 真実はいつも一つ！/ Always, there's only one truth! From gustavo.niemeyer at canonical.com Mon Jan 16 11:44:38 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 16 Jan 2017 13:44:38 +0200 Subject: Switching to a non-native package In-Reply-To: References: Message-ID: That sounds fine, but also like a detour from the actual goal. One way or another, the in-tree packaging that is there for Ubuntu won't be at stake when making it work on Debian. Also note that the in-tree debian/ directory doesn't work even for Ubuntu, strictly speaking. We already have the 14.04 bits in a separate branch. I'd focus on making it properly test more distributions first (not just Debian either) and later worry about whether we should get rid of debian/ or not. On Mon, Jan 16, 2017 at 12:02 PM, Zygmunt Krynicki < zygmunt.krynicki at canonical.com> wrote: > I'd like to work on enabling Debian in the CI loop and I was thinking > that it would be somewhat easier we switched to non-native packaging > in the upstream tree and similarly switched to quilt in the Debian > tree (we could have separate packaging trees for sid / stretch if that > would help). Since my view may be simplistic I would like to ask the > current most active Debian maintainers of snapd for opinion. > > Right now almost all of the CI in the tree is performed on the > packaging that is in the tree as well. The notable exception is 14.04 > which has a separate packaging branch. This is unrealistic as the > Debian packaging tree is widely different and even if we built a > package from the in-tree debian directory and tested it on a real > Debian machine the result would not be representative of what a > subsequent upstream release would look like in Debian. > > I'd like to propose that we remove the debian directory from the > upstream repository (no special casing) and work on ensuring that > Ubuntu and subsequently Debian are tested equally well whenever we > make a pull request. > > Best regards > ZK > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Mon Jan 16 15:16:36 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 10:16:36 -0500 Subject: [NEWS] Kdenlive devel snap In-Reply-To: References: Message-ID: <3aedfec7-24b5-a4fa-1c7f-50b2fa7c014f@ubuntu.com> On 05/01/17 15:41, Tiago Herrmann wrote: > Sorry to revive this old thread, but this very same website just > posted a tutorial [1] on how to manage snaps. > The maintainer of this website is a friend of mine and he told me his > goal was to write the most complete snap utilization tutorial > available in Portuguese. > He has been doing a great job on spreading news about ubuntu and snap > here in Brazil. > > [1] http://www.diolinux.com.br/2017/01/ubuntu-snap-utilization-manual.html > or google translation: > https://translate.google.com/translate?hl=pt-BR&sl=pt&tl=en&u=http%3A%2F%2Fwww.diolinux.com.br%2F2017%2F01%2Fubuntu-snap-utilization-manual.html > Very happy to see how many people are enjoying snaps now! Those of you who have been thinking about making a snap, I would suggest you start with a classic snap which should work on 14.04 and 16.04 very easily. Then you can try to get it fully confined, starting with devmode. Mark From mark at ubuntu.com Mon Jan 16 15:35:49 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 10:35:49 -0500 Subject: netplan and post-up/pre-down scripts In-Reply-To: References: Message-ID: On 06/01/17 13:12, Mike Pontillo wrote: > Long story short: in order to get the behavior I wanted, I wrote a > custom script that monitors *operational status* (aka physical link > up/down status), and I launch it using /e/n/i's `post-up`, and bring > it down using /e/n/i's `pre-down` scripts. > > Looking at the `netplan` spec[4], I don't see a way to achieve that > functionality. I know that many people are using the script-callout > functionality in /e/n/i to achieve what they need to achieve, so it > seems to me that having this in `netplan` is critical to achieving > parity with what we have in Xenial with `ifupdown`. > > In an ideal world, I think `netplan` would be able to model my use > case out-of-the-box.[5] But since we can't expect to model everyone's > use case, it seems like custom scripting functionality is a hard > requirement, though perhaps one that could have tricky cross-platform > implications. Would 'got-link' and 'lost-link' be good names for this? Mark From mark at ubuntu.com Mon Jan 16 15:35:49 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 10:35:49 -0500 Subject: netplan and post-up/pre-down scripts In-Reply-To: References: Message-ID: On 06/01/17 13:12, Mike Pontillo wrote: > Long story short: in order to get the behavior I wanted, I wrote a > custom script that monitors *operational status* (aka physical link > up/down status), and I launch it using /e/n/i's `post-up`, and bring > it down using /e/n/i's `pre-down` scripts. > > Looking at the `netplan` spec[4], I don't see a way to achieve that > functionality. I know that many people are using the script-callout > functionality in /e/n/i to achieve what they need to achieve, so it > seems to me that having this in `netplan` is critical to achieving > parity with what we have in Xenial with `ifupdown`. > > In an ideal world, I think `netplan` would be able to model my use > case out-of-the-box.[5] But since we can't expect to model everyone's > use case, it seems like custom scripting functionality is a hard > requirement, though perhaps one that could have tricky cross-platform > implications. Would 'got-link' and 'lost-link' be good names for this? Mark From mark at ubuntu.com Mon Jan 16 17:07:25 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 12:07:25 -0500 Subject: snapd and semaphores In-Reply-To: References: <1483471265.3074.6.camel@canonical.com> <1484055690.3215.86.camel@canonical.com> Message-ID: <41663ec7-5065-506a-0bca-0dc1f9810bb2@ubuntu.com> On 10/01/17 08:44, Olivier Tilloy wrote: > On Tue, Jan 10, 2017 at 2:41 PM, Jamie Strandboge wrote: >> On Wed, 2017-01-04 at 13:39 +0100, Olivier Tilloy wrote: >>> Here is the bug report: https://launchpad.net/bugs/1653955 >> Thanks! The fix is in master and will bi in snapd 2.21. > Excellent, thanks Jamie for your prompt response! Catching up on email, I have to say a TON of good stuff landed in 2.21. Wow. Thank you everybody! Mark From jcoates at extremenetworks.com Mon Jan 16 21:39:33 2017 From: jcoates at extremenetworks.com (Joe Coates) Date: Mon, 16 Jan 2017 21:39:33 +0000 Subject: DHCP and /etc/resolv.conf Message-ID: I'm snapping an app which includes a DHCP client replacement. Ultimately it wants to update/replace /etc/resolv.conf. My snap is connected to all the "network" interfaces available in my ubuntu-core, but none seem to allow write access to this file. Shouldn't an interface like "network-control" allow write access to /etc/resolv.conf ? Thanks, Joe Coates ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Mon Jan 16 21:58:45 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 16 Jan 2017 16:58:45 -0500 Subject: DHCP and /etc/resolv.conf In-Reply-To: References: Message-ID: On 16/01/17 16:39, Joe Coates wrote: > > I'm snapping an app which includes a DHCP client replacement. > Ultimately it wants to update/replace /etc/resolv.conf. My snap is > connected to all the "network" interfaces available in my ubuntu-core, > but none seem to allow write access to this file. Shouldn't an > interface like "network-control" allow write access to /etc/resolv.conf ? > I think /etc/resolv.conf is generated from a number of sources, but yes, it should be possible to influence it. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Mon Jan 16 22:26:26 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Mon, 16 Jan 2017 22:26:26 +0000 Subject: Yet more issues snapping Message-ID: Having given up all hope of ever being able to do a simple thing like include pygtk in a snap I have rebuilt my package using wx. I can't face the same issue twice, surely right? Well I've built it without explicitly mentioning wx, and specifically asking travis to include it. The end result is always a failure. Could someone please take a look at this and tell me what on earth is going on? https://paste.ubuntu.com/23812998/ From jcoates at extremenetworks.com Mon Jan 16 23:01:13 2017 From: jcoates at extremenetworks.com (Joe Coates) Date: Mon, 16 Jan 2017 23:01:13 +0000 Subject: DHCP and /etc/resolv.conf In-Reply-To: References: , Message-ID: Is there a current slot interface which allows write access to /etc/resolv.conf? Thanks, Joe Coates ________________________________________ From: snapcraft-bounces at lists.snapcraft.io on behalf of Mark Shuttleworth Sent: Monday, January 16, 2017 4:58:45 PM To: Snapcraft Subject: Re: DHCP and /etc/resolv.conf On 16/01/17 16:39, Joe Coates wrote: I'm snapping an app which includes a DHCP client replacement. Ultimately it wants to update/replace /etc/resolv.conf. My snap is connected to all the "network" interfaces available in my ubuntu-core, but none seem to allow write access to this file. Shouldn't an interface like "network-control" allow write access to /etc/resolv.conf ? I think /etc/resolv.conf is generated from a number of sources, but yes, it should be possible to influence it. Mark ________________________________ 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 loic.minier at ubuntu.com Mon Jan 16 23:58:24 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Tue, 17 Jan 2017 00:58:24 +0100 Subject: Yet more issues snapping In-Reply-To: References: Message-ID: Hi, Running snapcraft on https://github.com/cliftonts/rokugtk.git works for me on top of a clean 16.04 LXD container. However your Travis log suggests that the builds takes place on top of Ubuntu 14.04. I suggest you try running your Travis build inside a 16.04 environment; it seems this is achieved by running the 16.04 Docker container. Cheers, - Loïc Minier On Mon, Jan 16, 2017 at 11:26 PM, Gareth France < gareth.france at cliftonts.co.uk> wrote: > Having given up all hope of ever being able to do a simple thing like > include pygtk in a snap I have rebuilt my package using wx. I can't face > the same issue twice, surely right? > > > Well I've built it without explicitly mentioning wx, and specifically > asking travis to include it. The end result is always a failure. Could > someone please take a look at this and tell me what on earth is going on? > > > https://paste.ubuntu.com/23812998/ > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.aguirre at gmail.com Tue Jan 17 00:04:10 2017 From: matt.aguirre at gmail.com (Matthew Aguirre) Date: Mon, 16 Jan 2017 19:04:10 -0500 Subject: Yet more issues snapping In-Reply-To: References: Message-ID: Can you not just list the library dependencies and dev packages in the snapcraft file instead of building everything from source? python-gtk2 parts: your_app: plugin: python source: . build-packages: - python-gtk2-dev stage-packages: - python-gtk2 ... Or I assume there may be a similar package for wxPython. -- Matt On Jan 16, 2017 5:27 PM, "Gareth France" wrote: Having given up all hope of ever being able to do a simple thing like include pygtk in a snap I have rebuilt my package using wx. I can't face the same issue twice, surely right? Well I've built it without explicitly mentioning wx, and specifically asking travis to include it. The end result is always a failure. Could someone please take a look at this and tell me what on earth is going on? https://paste.ubuntu.com/23812998/ -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm an/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Tue Jan 17 00:06:31 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Tue, 17 Jan 2017 00:06:31 +0000 Subject: Yet more issues snapping In-Reply-To: References: Message-ID: <36d62167-ac61-5c6f-eae4-8c15ac51c1d3@cliftonts.co.uk> On 17/01/17 00:04, Matthew Aguirre wrote: > Can you not just list the library dependencies and dev packages in the > snapcraft file instead of building everything from source? > python-gtk2 > > parts: > your_app: > plugin: python > source: . > build-packages: > - python-gtk2-dev > stage-packages: > - python-gtk2 > ... > Or I assume there may be a similar package for wxPython. > -- > Matt I have no idea. I've been asking for help but it's been thin on the ground. I've only ever built one snap without issues, this is early days for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gareth.france at cliftonts.co.uk Tue Jan 17 00:07:50 2017 From: gareth.france at cliftonts.co.uk (Gareth France) Date: Tue, 17 Jan 2017 00:07:50 +0000 Subject: Yet more issues snapping In-Reply-To: References: Message-ID: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> On 16/01/17 23:58, Loïc Minier wrote: > I suggest you try running your Travis build inside a 16.04 > environment; it seems this is achieved by running the 16.04 Docker > container. Thank you, but how do I do that? From matt.aguirre at gmail.com Tue Jan 17 00:21:24 2017 From: matt.aguirre at gmail.com (Matthew Aguirre) Date: Mon, 16 Jan 2017 19:21:24 -0500 Subject: Yet more issues snapping In-Reply-To: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> References: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> Message-ID: <1484612484.1922.12@smtp.gmail.com> I just issued a pull request on your app. Here's the gist: you needed to include x11 slot I admit I am not familar w/ the python plugin, so I didn't use the requests package from python-packages as it failed on me the first time. Instead added it from the repos under stage-packages. -- Matt On Mon, Jan 16, 2017 at 7:07 PM, Gareth France wrote: > > > On 16/01/17 23:58, Loïc Minier wrote: >> I suggest you try running your Travis build inside a 16.04 >> environment; it seems this is achieved by running the 16.04 Docker >> container. > Thank you, but how do I do that? > > -- > 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 mike.pontillo at canonical.com Tue Jan 17 06:02:24 2017 From: mike.pontillo at canonical.com (Mike Pontillo) Date: Mon, 16 Jan 2017 22:02:24 -0800 Subject: netplan and post-up/pre-down scripts In-Reply-To: References: Message-ID: On Mon, Jan 16, 2017 at 7:35 AM, Mark Shuttleworth wrote: > Would 'got-link' and 'lost-link' be good names for this? > I'm not certain a new event name is needed for this functionality; it seems to me that the current definition of 'up' isn't quite correct.[1] (But all this might be a moot point depending on what is supported in networkd, and how it behaves.) I understand there have been several attempts to address this in the past, such as the 'allow-hotplug' option, ifplugd, ifupdown-extra, NetworkManager, and now networkd. IMHO, no solution is complete unless it properly separates adminStatus from operStatus, and holds off on confirming "link up" until both are "up". For backward compatibility, a boolean flag (similar to "allow-hotplug") should indicate whether or not the system is allowed to continue booting if the interface is down.[2] Another subtle detail is that if an interface is administratively down, there should be an option to cause the NIC to take its physical link down. That way, whatever is on the other side of the link doesn't assume its peer is active. (This is standard behavior on a router or a switch, but may be atypical for a server... so I think the default behavior should continue be "leave the physical link up".) Regards, Mike [1]: I would refer to the IF-MIB definitions for administrative and operational status, which haven't changed in a long time. They can be found in RFC 2863 sections 3.1.12 and 3.1.13[1]. There is also discussion (amendments to a previous RFC) about when to send the "linkUp" trap. (To summarize, only when a link is both operationally and administratively up.) See the relevant states here: https://tools.ietf.org/search/rfc2863#section-3.1.12 Contrast this to the default behavior of an auto/static interface: an interface is considered UP if its operStatus AND adminStatus were "up" within 5 minutes of boot. After that, you can throw all your assumptions out the window; the interface will stay DOWN even if its operational status changes from "down" to "up", and the system will hobble along in a half-configured state, even if the link status changes. [2]: I think that should default to to allow boot, to prevent the UX nightmares that occur during boot when the boot process waits for interfaces it thinks should be up. If a particular service is finicky enough to not handle a missing interface gracefully, the admin can manually configure the flag to /not/ allow boot. The current behavior is also strange because if an interface becomes operationally "down" after the five minute timeout, the system takes no action, pretending nothing happened. (Why did we just wait 5 minutes for an interface to be up, if we weren't going to care if it later went down?) If a service /seriously/ depends on an interface being up, and cannot handle changes in interface status, the admin should configure that service to start upon receiving a link up event, and stop it upon receiving a link down event for that interface. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spencertparkin at gmail.com Tue Jan 17 07:35:13 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Tue, 17 Jan 2017 00:35:13 -0700 Subject: Snapping with scons In-Reply-To: <17380F19-73F1-48F2-9B9D-70FA4E2B6E2D@gmail.com> References: <17380F19-73F1-48F2-9B9D-70FA4E2B6E2D@gmail.com> Message-ID: Okay, maybe no one knew what I was taking about. In any case, for the record, I've resolved the issue by using relative paths in my SConstruct file that would only work during snapping. This doesn't cause an issue with normal development, because I also include relative paths (include paths and lib paths) that would only work in that context. Extraneous paths in either context is fine. What I figured is that, like the "DESTDIR" variable provided by the scons plugin, there would be similar environment variables setup that SConstruct and other make-type files could use to be able to locate dependency parts that have already been built during the snapping process. But maybe my solution is above reasonable? It doesn't seem all that clean to me. By the way, the documentation at... http://snapcraft.io/docs/reference/plugins/scons ...is pretty bad. If someone pointed me in the right direction, I could at least add what I know from looking at the plugin's Python code. Sincerely yours, The worst snapcrafter on the list. On Mon, Jan 16, 2017 at 12:07 AM, Spencer wrote: > Hi. I have a project with 2 dependencies so I need 3 parts in my yaml > file. The dependencies install correctly during snapping, but when my > program starts to compile, it can't locate the header files for the library > dependencies. There is no mystery here as to why that is the case. My > question, however, is: what do I put in my scons file so that I can locate > the header files during snapping? I've been looking at the snapcraft > python code, but I can't seem to find out what, if any, additional > environment variables there may be setup for me to use in my scons file so > that I can locate headers and libraries. Is there a different way to go > about it? > > Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Tue Jan 17 11:35:11 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 17 Jan 2017 11:35:11 +0000 Subject: Snapping with scons In-Reply-To: References: <17380F19-73F1-48F2-9B9D-70FA4E2B6E2D@gmail.com> Message-ID: On Tue, 17 Jan 2017 00:35:13 -0700, Spencer Parkin wrote: > Okay, maybe no one knew what I was taking about. In any case, for the > record, I've resolved the issue by using relative paths in my SConstruct > file that would only work during snapping. This doesn't cause an issue > with normal development, because I also include relative paths (include > paths and lib paths) that would only work in that context. Extraneous > paths in either context is fine. > > What I figured is that, like the "DESTDIR" variable provided by the scons > plugin, there would be similar environment variables setup that SConstruct > and other make-type files could use to be able to locate dependency parts > that have already been built during the snapping process. But maybe my > solution is above reasonable? It doesn't seem all that clean to me. There are, I'll make those more discoverable. > By the way, the documentation at... > > http://snapcraft.io/docs/reference/plugins/scons Recommendations in the form of a bug on what you are missing would be a nice way to get the documentation improved. https://bugs.launchpad.net/snapcraft/+filebug > ...is pretty bad. If someone pointed me in the right direction, I could at > least add what I know from looking at the plugin's Python code. Hop on to https://rocket.ubuntu.com/channel/snapcraft and we can go over your issues in more details. -- Sent using Dekko from my Ubuntu device From zygmunt.krynicki at canonical.com Tue Jan 17 13:18:40 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Tue, 17 Jan 2017 14:18:40 +0100 Subject: DHCP and /etc/resolv.conf In-Reply-To: References: Message-ID: Quick grep tells me that no interface currently relates to "resolv.conf" file On Tue, Jan 17, 2017 at 12:01 AM, Joe Coates wrote: > Is there a current slot interface which allows write access to /etc/resolv.conf? > > Thanks, > Joe Coates > > ________________________________________ > From: snapcraft-bounces at lists.snapcraft.io on behalf of Mark Shuttleworth > Sent: Monday, January 16, 2017 4:58:45 PM > To: Snapcraft > Subject: Re: DHCP and /etc/resolv.conf > > On 16/01/17 16:39, Joe Coates wrote: > > I'm snapping an app which includes a DHCP client replacement. Ultimately it wants to update/replace /etc/resolv.conf. My snap is connected to all the "network" interfaces available in my ubuntu-core, but none seem to allow write access to this file. Shouldn't an interface like "network-control" allow write access to /etc/resolv.conf ? > > I think /etc/resolv.conf is generated from a number of sources, but yes, it should be possible to influence it. > > Mark > > ________________________________ > > 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. > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From zygmunt.krynicki at canonical.com Tue Jan 17 13:19:16 2017 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Tue, 17 Jan 2017 14:19:16 +0100 Subject: systemd reload (ExevReload) support In-Reply-To: References: Message-ID: Quick grep tells me that this is not currently supported. On Sat, Jan 14, 2017 at 4:55 PM, Boris Rybalkin wrote: > Hi, > > Could you tell me if there is systemd ExecReload support in snap.yaml? > > Thank you. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From ribalkin at gmail.com Tue Jan 17 13:51:40 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Tue, 17 Jan 2017 13:51:40 +0000 Subject: systemd reload (ExevReload) support In-Reply-To: References: Message-ID: Yes, I had to add support on our branch before we get official Implementation: https://github.com/syncloud/snapd/blob/master/wrappers/services.go#L185 I have also created a bug: https://bugs.launchpad.net/snapd/+bug/1657116 On 17 Jan 2017 13:19, "Zygmunt Krynicki" wrote: > Quick grep tells me that this is not currently supported. > > On Sat, Jan 14, 2017 at 4:55 PM, Boris Rybalkin > wrote: > > Hi, > > > > Could you tell me if there is systemd ExecReload support in snap.yaml? > > > > Thank you. > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.brustkern at canonical.com Tue Jan 17 14:37:09 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Tue, 17 Jan 2017 09:37:09 -0500 Subject: Command to check for updates? In-Reply-To: References: Message-ID: Excellent, thanks! On Sun, Jan 15, 2017 at 11:54 PM, Stuart Bishop wrote: > > > On 14 January 2017 at 03:33, Max Brustkern > wrote: > >> I'm attempting to run automated upgrade tests from the stable release to >> candidate versions. If I run >> snap refresh x >> and there is no new version of x, the snap command exits with status 1. >> Is there a command I can use to check if an update is available and only >> install in that case? Right now I don't know how to distinguish an update >> failure from a case where the system is already up to date. >> > > According to https://bugs.launchpad.net/layer-snap/+bug/1588322 , this > was supposed to have been fixed with 2.18. > > > -- > Stuart Bishop > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.fels at canonical.com Tue Jan 17 16:05:21 2017 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 17 Jan 2017 17:05:21 +0100 Subject: DHCP and /etc/resolv.conf In-Reply-To: References: Message-ID: <774b418a-e1f5-7576-bd15-1b885084818d@canonical.com> On 17.01.2017 14:18, Zygmunt Krynicki wrote: > Quick grep tells me that no interface currently relates to "resolv.conf" file Actually you shouldn't allow access to /etc/resolv.conf but to /run/resolvconf/ which the network-manager interface allows as the only one so far. regards, Simon > On Tue, Jan 17, 2017 at 12:01 AM, Joe Coates > wrote: >> Is there a current slot interface which allows write access to /etc/resolv.conf? >> >> Thanks, >> Joe Coates >> >> ________________________________________ >> From: snapcraft-bounces at lists.snapcraft.io on behalf of Mark Shuttleworth >> Sent: Monday, January 16, 2017 4:58:45 PM >> To: Snapcraft >> Subject: Re: DHCP and /etc/resolv.conf >> >> On 16/01/17 16:39, Joe Coates wrote: >> >> I'm snapping an app which includes a DHCP client replacement. Ultimately it wants to update/replace /etc/resolv.conf. My snap is connected to all the "network" interfaces available in my ubuntu-core, but none seem to allow write access to this file. Shouldn't an interface like "network-control" allow write access to /etc/resolv.conf ? >> >> I think /etc/resolv.conf is generated from a number of sources, but yes, it should be possible to influence it. >> >> Mark >> >> ________________________________ >> >> 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. >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From gustavo at niemeyer.net Tue Jan 17 16:06:24 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 17 Jan 2017 14:06:24 -0200 Subject: Command to check for updates? In-Reply-To: References: Message-ID: Does it work for you after an update? On Tue, Jan 17, 2017 at 12:37 PM, Max Brustkern wrote: > Excellent, thanks! > > On Sun, Jan 15, 2017 at 11:54 PM, Stuart Bishop < > stuart.bishop at canonical.com> wrote: > >> >> >> On 14 January 2017 at 03:33, Max Brustkern >> wrote: >> >>> I'm attempting to run automated upgrade tests from the stable release to >>> candidate versions. If I run >>> snap refresh x >>> and there is no new version of x, the snap command exits with status 1. >>> Is there a command I can use to check if an update is available and only >>> install in that case? Right now I don't know how to distinguish an update >>> failure from a case where the system is already up to date. >>> >> >> According to https://bugs.launchpad.net/layer-snap/+bug/1588322 , this >> was supposed to have been fixed with 2.18. >> >> >> -- >> Stuart Bishop >> >> -- >> 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 > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcoates at extremenetworks.com Tue Jan 17 16:46:40 2017 From: jcoates at extremenetworks.com (Joe Coates) Date: Tue, 17 Jan 2017 16:46:40 +0000 Subject: DHCP and /etc/resolv.conf In-Reply-To: <774b418a-e1f5-7576-bd15-1b885084818d@canonical.com> References: <774b418a-e1f5-7576-bd15-1b885084818d@canonical.com> Message-ID: The 'network-manager' slot interface does not show up in my Ubuntu-core interface list. I'm running 2.21 on a Virtualbox VM. Joe -----Original Message----- From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Simon Fels Sent: Tuesday, January 17, 2017 11:05 AM To: snapcraft at lists.snapcraft.io Subject: Re: DHCP and /etc/resolv.conf On 17.01.2017 14:18, Zygmunt Krynicki wrote: > Quick grep tells me that no interface currently relates to > "resolv.conf" file Actually you shouldn't allow access to /etc/resolv.conf but to /run/resolvconf/ which the network-manager interface allows as the only one so far. regards, Simon > On Tue, Jan 17, 2017 at 12:01 AM, Joe Coates > wrote: >> Is there a current slot interface which allows write access to /etc/resolv.conf? >> >> Thanks, >> Joe Coates >> >> ________________________________________ >> From: snapcraft-bounces at lists.snapcraft.io >> on behalf of Mark Shuttleworth >> >> Sent: Monday, January 16, 2017 4:58:45 PM >> To: Snapcraft >> Subject: Re: DHCP and /etc/resolv.conf >> >> On 16/01/17 16:39, Joe Coates wrote: >> >> I'm snapping an app which includes a DHCP client replacement. Ultimately it wants to update/replace /etc/resolv.conf. My snap is connected to all the "network" interfaces available in my ubuntu-core, but none seem to allow write access to this file. Shouldn't an interface like "network-control" allow write access to /etc/resolv.conf ? >> >> I think /etc/resolv.conf is generated from a number of sources, but yes, it should be possible to influence it. >> >> Mark >> >> ________________________________ >> >> 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. >> >> >> -- >> 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 ________________________________ 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 simon.fels at canonical.com Tue Jan 17 17:23:56 2017 From: simon.fels at canonical.com (Simon Fels) Date: Tue, 17 Jan 2017 18:23:56 +0100 Subject: DHCP and /etc/resolv.conf In-Reply-To: References: <774b418a-e1f5-7576-bd15-1b885084818d@canonical.com> Message-ID: On 17.01.2017 17:46, Joe Coates wrote: > The 'network-manager' slot interface does not show up in my Ubuntu-core interface list. I'm running 2.21 on a Virtualbox VM. It's not a slot you can put on your snap or one which is provided by the core snap. It's a slot which only the network-manager snap can own and no other one and its not a one which allows arbitrary snaps to access the resolvconf configuration. For that we still need a different interface or add support for resolvconf access to the network-control interface. If you look at the code for the network-manager interface the responsible part for resolveconf is at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_manager.go#L86 I guess it would be ok to get those bits added to the network-control interface at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go If you want you can easily submit a PR to get those bits added there. A short introduction into snapd hacking is available at https://github.com/snapcore/snapd/blob/master/HACKING.md regards, Simon > -----Original Message----- > From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Simon Fels > Sent: Tuesday, January 17, 2017 11:05 AM > To: snapcraft at lists.snapcraft.io > Subject: Re: DHCP and /etc/resolv.conf > > On 17.01.2017 14:18, Zygmunt Krynicki wrote: >> Quick grep tells me that no interface currently relates to >> "resolv.conf" file > > Actually you shouldn't allow access to /etc/resolv.conf but to /run/resolvconf/ which the network-manager interface allows as the only one so far. > > regards, > Simon > >> On Tue, Jan 17, 2017 at 12:01 AM, Joe Coates >> wrote: >>> Is there a current slot interface which allows write access to /etc/resolv.conf? >>> >>> Thanks, >>> Joe Coates >>> >>> ________________________________________ >>> From: snapcraft-bounces at lists.snapcraft.io >>> on behalf of Mark Shuttleworth >>> >>> Sent: Monday, January 16, 2017 4:58:45 PM >>> To: Snapcraft >>> Subject: Re: DHCP and /etc/resolv.conf >>> >>> On 16/01/17 16:39, Joe Coates wrote: >>> >>> I'm snapping an app which includes a DHCP client replacement. Ultimately it wants to update/replace /etc/resolv.conf. My snap is connected to all the "network" interfaces available in my ubuntu-core, but none seem to allow write access to this file. Shouldn't an interface like "network-control" allow write access to /etc/resolv.conf ? >>> >>> I think /etc/resolv.conf is generated from a number of sources, but yes, it should be possible to influence it. >>> >>> Mark >>> >>> ________________________________ >>> >>> 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. >>> >>> >>> -- >>> 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 > > > ________________________________ > > 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 max.brustkern at canonical.com Tue Jan 17 20:00:13 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Tue, 17 Jan 2017 15:00:13 -0500 Subject: Command to check for updates? In-Reply-To: References: Message-ID: Yes, thank you for the information. On Tue, Jan 17, 2017 at 11:06 AM, Gustavo Niemeyer wrote: > Does it work for you after an update? > > On Tue, Jan 17, 2017 at 12:37 PM, Max Brustkern < > max.brustkern at canonical.com> wrote: > >> Excellent, thanks! >> >> On Sun, Jan 15, 2017 at 11:54 PM, Stuart Bishop < >> stuart.bishop at canonical.com> wrote: >> >>> >>> >>> On 14 January 2017 at 03:33, Max Brustkern >>> wrote: >>> >>>> I'm attempting to run automated upgrade tests from the stable release >>>> to candidate versions. If I run >>>> snap refresh x >>>> and there is no new version of x, the snap command exits with status 1. >>>> Is there a command I can use to check if an update is available and only >>>> install in that case? Right now I don't know how to distinguish an update >>>> failure from a case where the system is already up to date. >>>> >>> >>> According to https://bugs.launchpad.net/layer-snap/+bug/1588322 , this >>> was supposed to have been fixed with 2.18. >>> >>> >>> -- >>> Stuart Bishop >>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> > > > -- > > gustavo @ http://niemeyer.net > > -- > 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 joseph.wakeling at webdrake.net Tue Jan 17 21:11:57 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 17 Jan 2017 22:11:57 +0100 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: On 14/01/17 03:26, Sergio Schvezov wrote: > A generic solution for build systems and CI is being worked on. > > Thanks for taking notice. Ah, OK, thanks. Please do ping me if there is work-in-progress I can help to test. I'd be happy to help out if I can. Can you shed light on the reason for the linker errors I get when trying to build a `classic` snap using regular `snapcraft build`? See: https://lists.ubuntu.com/archives/snapcraft/2017-January/002483.html ... for details. Do I assume right here that the problem is along the lines that the libraries concerned are not part of the core snap, and therefore the core_dynamic_linker cannot access them, even though they are installed on my machine via apt? Thanks & best wishes, -- Joe From sergio.schvezov at canonical.com Tue Jan 17 21:22:51 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 17 Jan 2017 21:22:51 +0000 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> On Tue, 17 Jan 2017 22:11:57 +0100, Joseph Rushton Wakeling wrote: > On 14/01/17 03:26, Sergio Schvezov wrote: >> A generic solution for build systems and CI is being worked on. >> >> Thanks for taking notice. > > Ah, OK, thanks. Please do ping me if there is work-in-progress > I can help to > test. I'd be happy to help out if I can. > > Can you shed light on the reason for the linker errors I get when trying to > build a `classic` snap using regular `snapcraft build`? See: > https://lists.ubuntu.com/archives/snapcraft/2017-January/002483.html > > ... for details. Do I assume right here that the problem is > along the lines > that the libraries concerned are not part of the core snap, and > therefore the > core_dynamic_linker cannot access them, even though they are > installed on my > machine via apt? For classic confined snaps to link, they either need to be part of core or staged into your snap. On system libraries are ignored completely to ensure you have a working snap in the end. The `core_dynamic_linker` error message has been improved in 2.25 which is making its way into the -updates' pockets for the current supported series in Ubuntu. -- Sent using Dekko from my Ubuntu device From michael.hudson at canonical.com Tue Jan 17 21:30:51 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Wed, 18 Jan 2017 10:30:51 +1300 Subject: create-user primitive In-Reply-To: References: Message-ID: On 16 January 2017 at 20:45, Manik Taneja wrote: > hi there, > > i was trying to verify the functionality of the snapd create-user > primitive and see this error- > > [image: Inline image 1] > > is this expected behavior? > Yes. You can use --force-managed to create another user regardless. > why can't i have more than 1 user managing the device? separately, i > noticed that this primitive has been deprecated from the help menu- > > [image: Inline image 2] > > can someone please help me understand why this is the case? finally, at > the first boot, device ownership must be established via Ubuntu SSO. given > that, and the fact that create-user does not allow extra user creation, how > and when can someone use it? > Well snap create-user is mostly there exactly so that console-conf can invoke it. That's also why it's hidden from snap help! Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 68424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 224613 bytes Desc: not available URL: From joseph.wakeling at webdrake.net Tue Jan 17 22:17:27 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 17 Jan 2017 23:17:27 +0100 Subject: Classic confinement and core_dynamic_linker In-Reply-To: <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> Message-ID: <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> On 17/01/17 22:22, Sergio Schvezov wrote: > For classic confined snaps to link, they either need to be part of core or staged into your snap. On system libraries are ignored completely to ensure you have a working snap in the end. Is that a work in progress constraint, or is it the intended long term behaviour? (I'll try it out shortly in any case.) I ask because currently, if a package is explicitly stated as a build dependency, then with `strict` confinement it's automatically included in the final snap where necessary. What makes `classic` confinement unable to automatically handle the inclusion of build dependencies in the same way? From manik at canonical.com Tue Jan 17 23:13:12 2017 From: manik at canonical.com (Manik Taneja) Date: Tue, 17 Jan 2017 15:13:12 -0800 Subject: create-user primitive In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 1:30 PM, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > > On 16 January 2017 at 20:45, Manik Taneja wrote: > >> hi there, >> >> i was trying to verify the functionality of the snapd create-user >> primitive and see this error- >> >> [image: Inline image 1] >> >> is this expected behavior? >> > > Yes. You can use --force-managed to create another user regardless. > > >> why can't i have more than 1 user managing the device? separately, i >> noticed that this primitive has been deprecated from the help menu- >> >> [image: Inline image 2] >> >> can someone please help me understand why this is the case? finally, at >> the first boot, device ownership must be established via Ubuntu SSO. given >> that, and the fact that create-user does not allow extra user creation, how >> and when can someone use it? >> > > Well snap create-user is mostly there exactly so that console-conf can > invoke it. That's also why it's hidden from snap help! > thanks for the insights michael. in addition, is there a way to- - remove the user created via create-user? - add local users? /manik -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 224613 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 68424 bytes Desc: not available URL: From luis.pinto.martins at gmail.com Tue Jan 17 23:31:10 2017 From: luis.pinto.martins at gmail.com (=?UTF-8?Q?Lu=C3=ADs_Martins?=) Date: Tue, 17 Jan 2017 23:31:10 +0000 Subject: ubuntu core + snap + gpios Message-ID: Hi, I was trying to build a simple snap to test the ubuntu core raspberry pi 3 gpios [1] but for some reason the app does not seem allowed to write into /sys/class/gpio/ within my snap. I declared the "plugs: [gpio]" in the snapcraft.yaml and the app is a simple qt5/c++ program using std::ifstream/std::ofstream to read/write to the files. However, using the latest stable ubuntu core image, the "snap interfaces" command does not list the "gpio" as an available interface, is this normal ? Am I missing any step here ? [1] https://github.com/luispintomartins/gpio-tester Thanks, Luís -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hudson at canonical.com Wed Jan 18 00:01:52 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Wed, 18 Jan 2017 13:01:52 +1300 Subject: create-user primitive In-Reply-To: References: Message-ID: On 18 January 2017 at 12:13, Manik Taneja wrote: > > > On Tue, Jan 17, 2017 at 1:30 PM, Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: >> >> >> Well snap create-user is mostly there exactly so that console-conf can >> invoke it. That's also why it's hidden from snap help! >> > thanks for the insights michael. in addition, is there a way to- > > - remove the user created via create-user? > > I don't know. > > - add local users? > > Yes, you can you adduser with the --extrausers flag. Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Wed Jan 18 00:57:52 2017 From: manik at canonical.com (Manik Taneja) Date: Tue, 17 Jan 2017 16:57:52 -0800 Subject: create-user primitive In-Reply-To: References: Message-ID: On Tue, Jan 17, 2017 at 4:01 PM, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > On 18 January 2017 at 12:13, Manik Taneja wrote: > >> >> >> On Tue, Jan 17, 2017 at 1:30 PM, Michael Hudson-Doyle < >> michael.hudson at canonical.com> wrote: >>> >>> >>> Well snap create-user is mostly there exactly so that console-conf can >>> invoke it. That's also why it's hidden from snap help! >>> >> thanks for the insights michael. in addition, is there a way to- >> >> - remove the user created via create-user? >> >> I don't know. > >> >> - add local users? >> >> Yes, you can you adduser with the --extrausers flag. > thanks michael! -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Wed Jan 18 01:21:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 01:21:00 +0000 Subject: Classic confinement and core_dynamic_linker In-Reply-To: <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: On Tue, 17 Jan 2017 23:17:27 +0100, Joseph Rushton Wakeling wrote: > On 17/01/17 22:22, Sergio Schvezov wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Is that a work in progress constraint, or is it the intended long term > behaviour? (I'll try it out shortly in any case.) > > I ask because currently, if a package is explicitly stated as a build > dependency, then with `strict` confinement it's automatically > included in the > final snap where necessary. What makes `classic` confinement unable to > automatically handle the inclusion of build dependencies in the same way? The logic is still run, but the resulting binary in classic uses rpath and no dynamic loading so there is no resolution to a on-system library we can pick up. I guess we can do some magic, but it feels it might be either fragile or make the build process a lot slower. We will need to look into it, but not short term. -- Sent using Dekko from my Ubuntu device From spencertparkin at gmail.com Wed Jan 18 06:39:38 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Tue, 17 Jan 2017 23:39:38 -0700 Subject: [announce] twistypuzzle snap Message-ID: Hi, I've just uploaded to beta channel my new snap: twistypuzzle. Unlike "rubecube," one of my other snaps, this one can simulate a variety of twisty puzzles. My main motivation is the technical challenge such a program represents. There are still some bugs that must be resolved before releasing to the stable channel, but in the mean time, I'd be curious to know what anyone thinks about it. I think it's a cool idea, but hey, maybe it's not. Out of curiosity, is there a way to monetize a snap? I see a "buy" option in the snap command, and I see a "price" field on the Ubuntu Apps web-page for my snap, but I can't seem to find any information about how to configure these for a snap. I don't think my snaps are worth anything, and I want people to actually use them (so I want them to be free), but it would be interesting to know how or if this can be done. Thanks, --Sp -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.dandrea at canonical.com Wed Jan 18 07:49:12 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Wed, 18 Jan 2017 07:49:12 +0000 Subject: [announce] twistypuzzle snap In-Reply-To: References: Message-ID: On Wed, 18 Jan 2017 at 08:40 Spencer Parkin wrote: > Out of curiosity, is there a way to monetize a snap? I see a "buy" option > in the snap command, and I see a "price" field on the Ubuntu Apps web-page > for my snap, but I can't seem to find any information about how to > configure these for a snap. I don't think my snaps are worth anything, and > I want people to actually use them (so I want them to be free), but it > would be interesting to know how or if this can be done. > Yes, you absolutely will be able to monetise a snap, and we're working hard to make this a breeze for both the buyer and the seller. Complete instructions will be announced to this mailing list when we're ready to launch. Stay tuned :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From evan.dandrea at canonical.com Wed Jan 18 08:10:42 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Wed, 18 Jan 2017 08:10:42 +0000 Subject: create-user primitive In-Reply-To: References: Message-ID: On Tue, 17 Jan 2017 at 23:31 Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > Well snap create-user is mostly there exactly so that console-conf can > invoke it. That's also why it's hidden from snap help! > If it's mostly not intended to be used by humans, would it be reasonable to have it print a warning? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 68424 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 224613 bytes Desc: not available URL: From evan.dandrea at canonical.com Wed Jan 18 08:41:18 2017 From: evan.dandrea at canonical.com (Evan Dandrea) Date: Wed, 18 Jan 2017 08:41:18 +0000 Subject: Yet more issues snapping In-Reply-To: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> References: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> Message-ID: On Tue, 17 Jan 2017 at 02:08 Gareth France wrote: > > On 16/01/17 23:58, Loïc Minier wrote: > > I suggest you try running your Travis build inside a 16.04 > > environment; it seems this is achieved by running the 16.04 Docker > > container. > Thank you, but how do I do that? > This will guide you through it: http://snapcraft.io/docs/build-snaps/ci-integration If you run into any problems, please do let me know. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Wed Jan 18 08:52:24 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Wed, 18 Jan 2017 08:52:24 +0000 Subject: [announce] twistypuzzle snap In-Reply-To: References: Message-ID: Great work Spencer. I presume your project is hosted on GitHub at: * https://github.com/spencerparkin/TwistyPuzzle I don't see a snapcraft.yaml file there so I would be interested in what it looks like and how you found the whole process. After playing with it briefly I have filed the following bug. * https://github.com/spencerparkin/TwistyPuzzle/issues/1 Regards, Jamie. On Wed, Jan 18, 2017 at 6:39 AM, Spencer Parkin wrote: > Hi, > > I've just uploaded to beta channel my new snap: twistypuzzle. Unlike > "rubecube," one of my other snaps, this one can simulate a variety of twisty > puzzles. My main motivation is the technical challenge such a program > represents. > > There are still some bugs that must be resolved before releasing to the > stable channel, but in the mean time, I'd be curious to know what anyone > thinks about it. I think it's a cool idea, but hey, maybe it's not. > > Out of curiosity, is there a way to monetize a snap? I see a "buy" option > in the snap command, and I see a "price" field on the Ubuntu Apps web-page > for my snap, but I can't seem to find any information about how to configure > these for a snap. I don't think my snaps are worth anything, and I want > people to actually use them (so I want them to be free), but it would be > interesting to know how or if this can be done. > > Thanks, > --Sp > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From gareth.france at cliftonts.co.uk Wed Jan 18 08:53:27 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Wed, 18 Jan 2017 08:53:27 +0000 Subject: Yet more issues snapping In-Reply-To: References: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> Message-ID: <46eecfb7d8f858c82faed620d7994bcc@cliftonts.co.uk> On 2017-01-18 08:41, Evan Dandrea wrote: > On Tue, 17 Jan 2017 at 02:08 Gareth France > wrote: > > On 16/01/17 23:58, Loïc Minier wrote: > I suggest you try running your Travis build inside a 16.04 > environment; it seems this is achieved by running the 16.04 Docker > container. > Thank you, but how do I do that? > > This will guide you through it: > http://snapcraft.io/docs/build-snaps/ci-integration [1] > > If you run into any problems, please do let me know.  > > > Links: > ------ > [1] http://snapcraft.io/docs/build-snaps/ci-integration It is ok now thank you. I have had some excellent help and can use what I now have to aid me going forward. It is those first few steps that seem impossible. From mark at ubuntu.com Wed Jan 18 09:16:45 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 18 Jan 2017 04:16:45 -0500 Subject: Please test my asciinema snap Message-ID: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Hi folks (For those of you who Gmail does not filter this email on as-yet-unexplained-grounds :)) Please could you test my asciinema snap? Asciinema is a console video recording utility that's great for CLI-diven demos. If you want to make a quick web video of a CLI / console journey, asciinema is the ticket. An older version (0.9.8) is in 16.04. The new 1.3.0 version is now a snap, and it should work on 16.04. I am also interested in feedback on 14.04 for those of you on Trusty steeds who are blazing the snaps-on-trusty trail. It's a 'classic-only' snap, so you need: sudo snap install --classic asciinema Then 'asciinema rec' starts a recording session, and you're off to the races. Thanks! Mark From mark at ubuntu.com Wed Jan 18 09:19:43 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 18 Jan 2017 04:19:43 -0500 Subject: Please test my asciinema snap In-Reply-To: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> ... you may also need to enable xenial-proposed main in /etc/apt/sources.list to make sure you have the very latest snapd. Mark On 18/01/17 04:16, Mark Shuttleworth wrote: > It's a 'classic-only' snap, so you need: > > sudo snap install --classic asciinema > > Then 'asciinema rec' starts a recording session, and you're off to the > races. > From ogra at ubuntu.com Wed Jan 18 09:33:51 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 18 Jan 2017 10:33:51 +0100 Subject: ubuntu core + snap + gpios In-Reply-To: References: Message-ID: <1484732031.4288.1.camel@ubuntu.com> hi, Am Dienstag, den 17.01.2017, 23:31 +0000 schrieb Luís Martins: > Hi, I was trying to build a simple snap to test the ubuntu core > raspberry pi 3 gpios [1] but for some reason the app does not seem > allowed to write into /sys/class/gpio/ within my snap. > > I declared the "plugs: [gpio]" in the snapcraft.yaml and the app is a > simple qt5/c++ program using std::ifstream/std::ofstream to > read/write to the files. > > However, using the latest stable ubuntu core image, the "snap > interfaces" command does not list the "gpio" as an available > interface, is this normal ? > no, this is a bug, i have something nearly ready and can land it later today in the edge channel, i'll notify the list once it is there and also trigger a rebuild of the daily images (so you dont need to roll your own image) ciao oli -------------- 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 jamie.bennett at canonical.com Wed Jan 18 10:40:47 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Wed, 18 Jan 2017 10:40:47 +0000 Subject: Please test my asciinema snap In-Reply-To: <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> Message-ID: <20170118104047.icqjltuwqd6s4vub@golstein> On 18/01/17 at 04:19am, Mark Shuttleworth wrote: > > ... you may also need to enable xenial-proposed main in > /etc/apt/sources.list to make sure you have the very latest snapd. Yes, classic needs snapd 2.21 from proposed otherwise you will not be able to find or install the snap. After that, it works a treat [1], thanks. > Mark Regards, Jamie. [1] https://asciinema.org/a/bdlo4mxqzvko1sfretclbzl79 > On 18/01/17 04:16, Mark Shuttleworth wrote: > > It's a 'classic-only' snap, so you need: > > > > sudo snap install --classic asciinema > > > > Then 'asciinema rec' starts a recording session, and you're off to the > > races. > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From mrsingh at ssni.com Tue Jan 17 21:06:46 2017 From: mrsingh at ssni.com (Mritunjai Singh) Date: Tue, 17 Jan 2017 21:06:46 +0000 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) References: <1484159840.26677.55.camel@ubuntu.com> Message-ID: <42ffc25d06fe4aa4a3b554df27f2e580@sfo-ex13-04.silverspringnet.com> Can anyone please guide me how to start writing gadget snap which gives me access to serial port interface on my Raspberry Pi board and x86_64 ubuntu machine. Regards, Mritunjai From: Mritunjai Singh Sent: Thursday, January 12, 2017 10:06 AM To: 'Snapcraft' Subject: RE: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) @Simon Fels, thanks for the pointer. It would be great if you can further guide me writing the gadget snap. I have a Ubuntu x86_64 machine(VM) to which I will be connecting our RF Mesh network card through USB. The network card connects over serial and exposes a /dev/ttys0 port to work with. So do I need to write gadget snap for my network card or for my Ubuntu machine on which I have already installed snapcraft. Please guide and do let me know should you require any further information. Regards, Mritunjai From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Simon Fels Sent: Thursday, January 12, 2017 12:58 AM To: Snapcraft > Subject: Re: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) You can add a serial port slot to a gadget snap.yaml like this: ttyS4: interface: serial-port path: /dev/ttyS4 This only applies to static serial port nodes. If you have one provided by an USB device you have to user a slightly different slot definition which refers the USB product/vendor id of your USB device: my-usb-serial: interface: serial-port usb-product: 0x1111 usb-vendor: 0x2222 path: /dev/my-usb-serial-port With the path attribute you can select a static path for the serial port node which your snap then gets access to once you connected the plug and the slot. The path needs to start with /dev/ and afterwards you're free to select a free node name. Internally the interface implementation will link the right /dev/ttyUSB* node to the specified path. Please note that you can define such a slot only on a gadget snap! So if you don't have your own gadget snap today, you need to create one for your device in order to get access to the serial port. I hope that helps. regards, Simon On Wed, Jan 11, 2017 at 7:37 PM, Oliver Grawert > wrote: hi, Am Mittwoch, den 11.01.2017, 17:59 +0000 schrieb Mritunjai Singh: > Hi All, > > Kindly refer to: https://github.com/snapcore/snapd/issues/2557 > > We are trying to get a head start on Core Snappy working with our RF > Mesh network card. It connects over serial and needs to be available > at boot. We first tried this using snap approach but due to missing > hotplugging serial-interface in current(latest) version of snapcraft, > serial i/o requests are being denied even if the snap has the > permission to use serial port. > > We have been suggested the gadget snap approach in order to expose > /dev/ttyS0 to the serial port interface for tunnccd snap to access > it. It would be very helpful if someone can point me to the working > example of a gadget snap with access to serial interface or any end > to end gadget snap example and its build steps. note that all our gadgets offer a console on serial by default, if you drive some external device via serial you might want to drop this console tty option. all our official gadgets are under https://github.com/snapcore/ .. namely the pi2-gadget, pi3-gadget, pc-gadget and dragonboard-gadget sub-trees if you want to take a look ... 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 gustavo at niemeyer.net Wed Jan 18 10:58:00 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 18 Jan 2017 08:58:00 -0200 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: Hi Sergio, The question asked was actually how to get snapcraft to include dependencies *inside the snap* so that it works as it does with strict snaps, bundling the dependencies. Your response was about system libraries rather than bundled in-snap libraries, I believe. This should definitely work fine, right? On Tue, Jan 17, 2017 at 11:21 PM, Sergio Schvezov < sergio.schvezov at canonical.com> wrote: > On Tue, 17 Jan 2017 23:17:27 +0100, Joseph Rushton Wakeling wrote: > > On 17/01/17 22:22, Sergio Schvezov wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > Is that a work in progress constraint, or is it the intended long term > > behaviour? (I'll try it out shortly in any case.) > > > > I ask because currently, if a package is explicitly stated as a build > > dependency, then with `strict` confinement it's automatically > > included in the > > final snap where necessary. What makes `classic` confinement unable to > > automatically handle the inclusion of build dependencies in the same way? > > The logic is still run, but the resulting binary in classic uses rpath and > no dynamic loading so there is no resolution to a on-system library we can > pick up. I guess we can do some magic, but it feels it might be either > fragile or make the build process a lot slower. We will need to look into > it, but not short term. > > -- > Sent using Dekko from my Ubuntu device > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Wed Jan 18 11:05:56 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 11:05:56 +0000 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: On Wed, 18 Jan 2017 08:58:00 -0200, Gustavo Niemeyer wrote: > Hi Sergio, > > The question asked was actually how to get snapcraft to include > dependencies *inside the snap* so that it works as it does with strict > snaps, bundling the dependencies. > > Your response was about system libraries rather than bundled > in-snap libraries, I believe. > > This should definitely work fine, right? Yes, there is a gotcha though wrt the question asked. Using `build-packages`, which install on the host -the usual `-dev` ones- means that the libraries they bring in need to be added as `stage-packages`. We added an optimization here where we crawl all elf files in `prime` and `ldd` them to see if anything would resolve outside the snap and bring those libraries in. This is not as easy with classic confinement as all those elf files are runpathed. I have slept on it though and think there is a way to do it, but it won't be as straightforward. -- Sent using Dekko from my Ubuntu device From sergio.schvezov at canonical.com Wed Jan 18 11:12:36 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 11:12:36 +0000 Subject: Please test my asciinema snap In-Reply-To: <20170118104047.icqjltuwqd6s4vub@golstein> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> <20170118104047.icqjltuwqd6s4vub@golstein> Message-ID: On Wed, 18 Jan 2017 10:40:47 +0000, Jamie Bennett wrote: > On 18/01/17 at 04:19am, Mark Shuttleworth wrote: >> >> ... you may also need to enable xenial-proposed main in >> /etc/apt/sources.list to make sure you have the very latest snapd. > > Yes, classic needs snapd 2.21 from proposed otherwise you will > not be able to > find or install the snap. > > After that, it works a treat [1], thanks. Working fine for me as well! -- Sent using Dekko from my Ubuntu device From mark at ubuntu.com Wed Jan 18 11:34:26 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 18 Jan 2017 06:34:26 -0500 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> <20170118104047.icqjltuwqd6s4vub@golstein> Message-ID: On 18/01/17 06:12, Sergio Schvezov wrote: > On Wed, 18 Jan 2017 10:40:47 +0000, Jamie Bennett wrote: >> On 18/01/17 at 04:19am, Mark Shuttleworth wrote: >>> ... you may also need to enable xenial-proposed main in >>> /etc/apt/sources.list to make sure you have the very latest snapd. >> Yes, classic needs snapd 2.21 from proposed otherwise you will >> not be able to >> find or install the snap. >> >> After that, it works a treat [1], thanks. > Working fine for me as well! Thank you. Loving this :) Mark From davmor2 at davmor2.co.uk Wed Jan 18 11:41:49 2017 From: davmor2 at davmor2.co.uk (Dave Morley) Date: Wed, 18 Jan 2017 11:41:49 +0000 Subject: Please test my asciinema snap In-Reply-To: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: <20170118114149.64bfe73e@Stryder> On Wed, 18 Jan 2017 04:16:45 -0500 Mark Shuttleworth wrote: > Hi folks > > (For those of you who Gmail does not filter this email on > as-yet-unexplained-grounds :)) > > Please could you test my asciinema snap? Asciinema is a console video > recording utility that's great for CLI-diven demos. If you want to > make a quick web video of a CLI / console journey, asciinema is the > ticket. > > An older version (0.9.8) is in 16.04. The new 1.3.0 version is now a > snap, and it should work on 16.04. I am also interested in feedback on > 14.04 for those of you on Trusty steeds who are blazing the > snaps-on-trusty trail. > > It's a 'classic-only' snap, so you need: > > sudo snap install --classic asciinema > > Then 'asciinema rec' starts a recording session, and you're off to the > races. > > Thanks! > > Mark > > > > Not so happy on 14.04 paste.ubuntu.com/23821653/ I get a segfault :( -- You Make It, I'll Break It! I Love My Job :) http://www.canonical.com http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From sergio.schvezov at canonical.com Wed Jan 18 12:12:34 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 12:12:34 +0000 Subject: Classic confinement and core_dynamic_linker In-Reply-To: <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: <3r2iq0.ojz5x2.1hge17a-qmf@smtp.googlemail.com> On Tue, 17 Jan 2017 23:17:27 +0100, Joseph Rushton Wakeling wrote: > On 17/01/17 22:22, Sergio Schvezov wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > Is that a work in progress constraint, or is it the intended long term > behaviour? (I'll try it out shortly in any case.) > > I ask because currently, if a package is explicitly stated as a build > dependency, then with `strict` confinement it's automatically > included in the > final snap where necessary. What makes `classic` confinement unable to > automatically handle the inclusion of build dependencies in the same way? After a quick but thorough conversation with Gustavo we agreed that this is the wrong path to take as it might not be deterministic or people might get surprised about things included that shouldn't have been. There needs to be a clear line between `build-packages` and `stage-packages`. With that in mind snapcraft (even for `strict` snaps) will still crawl all the libraries and error on missing ones with a list of those that are missing. This should be something one can disable and set to ignore as some of the missing libraries might be provided by a content interface slot from another snap. -- Sent using Dekko from my Ubuntu device From sergio.schvezov at canonical.com Wed Jan 18 12:18:33 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 12:18:33 +0000 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: <4yahqs.ojz671.1hge17a-qmf@smtp.googlemail.com> On Wed, 18 Jan 2017 08:58:00 -0200, Gustavo Niemeyer wrote: > Hi Sergio, > > The question asked was actually how to get snapcraft to include > dependencies *inside the snap* so that it works as it does with strict > snaps, bundling the dependencies. The recomended way to add a library to your snap is to either build/stage it through a part or to add a stage-packages entry with the package that would include the needed library. -- Sent using Dekko from my Ubuntu device From simon.fels at canonical.com Wed Jan 18 12:26:19 2017 From: simon.fels at canonical.com (Simon Fels) Date: Wed, 18 Jan 2017 13:26:19 +0100 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) In-Reply-To: <42ffc25d06fe4aa4a3b554df27f2e580@sfo-ex13-04.silverspringnet.com> References: <1484159840.26677.55.camel@ubuntu.com> <42ffc25d06fe4aa4a3b554df27f2e580@sfo-ex13-04.silverspringnet.com> Message-ID: The gadget snap itself is pretty well explained on https://docs.ubuntu.com/core/en/guides/build-device/gadget which also links to the official supported gadget snaps you can use for your experiements. The slot definition can then be added to one of these as explained above. Another option is that you download one of these gadget snaps from the store via the snap download command, modify it and then repack it and generate a new image via ubuntu-image out of it: $ snap download pi3 $ unsquashfs pi3_*.snap # Do any modifications to squashfs-root/meta/snap.yaml $ snapcraft snap squashfs-root # Now you have a new .snap file snapcraft generated for you $ ubuntu-image ... --extra-snaps my-gadget.snap ... my-model.assert Hope that helps. regards, Simon On Tue, Jan 17, 2017 at 10:06 PM, Mritunjai Singh wrote: > Can anyone please guide me how to start writing gadget snap which gives me > access to serial port interface on my Raspberry Pi board and x86_64 ubuntu > machine. > > > > Regards, > > Mritunjai > > > > *From:* Mritunjai Singh > *Sent:* Thursday, January 12, 2017 10:06 AM > *To:* 'Snapcraft' > *Subject:* RE: Serial Port Plug/Interface issue with Ubuntu-core 16.04 > (#2557) > > > > *@Simon Fels*, thanks for the pointer. It would be great if you can > further guide me writing the gadget snap. I have a Ubuntu x86_64 > machine(VM) to which I will be connecting our RF Mesh network card through > USB. The network card connects over serial and exposes a /dev/ttys0 port to > work with. So do I need to write gadget snap for my network card or for my > Ubuntu machine on which I have already installed snapcraft. > > > > Please guide and do let me know should you require any further information. > > > > Regards, > > Mritunjai > > > > *From:* snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces@ > lists.snapcraft.io ] *On Behalf Of *Simon > Fels > *Sent:* Thursday, January 12, 2017 12:58 AM > *To:* Snapcraft > *Subject:* Re: Serial Port Plug/Interface issue with Ubuntu-core 16.04 > (#2557) > > > > You can add a serial port slot to a gadget snap.yaml like this: > > > > ttyS4: > > interface: serial-port > > path: /dev/ttyS4 > > > > This only applies to static serial port nodes. If you have one provided by > an USB device you have to user a slightly different slot definition which > refers the USB product/vendor id of your USB device: > > > > my-usb-serial: > > interface: serial-port > > usb-product: 0x1111 > > usb-vendor: 0x2222 > > path: /dev/my-usb-serial-port > > > > With the path attribute you can select a static path for the serial port > node which your snap then gets access to once you connected the plug and > the slot. The path needs to start with /dev/ and afterwards you're free to > select a free node name. Internally the interface implementation will link > the right /dev/ttyUSB* node to the specified path. > > > > Please note that you can define such a slot only on a gadget snap! So if > you don't have your own gadget snap today, you need to create one for your > device in order to get access to the serial port. > > > > I hope that helps. > > > > regards, > > Simon > > > > > > On Wed, Jan 11, 2017 at 7:37 PM, Oliver Grawert wrote: > > hi, > Am Mittwoch, den 11.01.2017, 17:59 +0000 schrieb Mritunjai Singh: > > Hi All, > > > > Kindly refer to: https://github.com/snapcore/snapd/issues/2557 > > > > We are trying to get a head start on Core Snappy working with our RF > > Mesh network card. It connects over serial and needs to be available > > at boot. We first tried this using snap approach but due to missing > > hotplugging serial-interface in current(latest) version of snapcraft, > > serial i/o requests are being denied even if the snap has the > > permission to use serial port. > > > > We have been suggested the gadget snap approach in order to expose > > /dev/ttyS0 to the serial port interface for tunnccd snap to access > > it. It would be very helpful if someone can point me to the working > > example of a gadget snap with access to serial interface or any end > > to end gadget snap example and its build steps. > > note that all our gadgets offer a console on serial by default, if you > drive some external device via serial you might want to drop this > console tty option. > > all our official gadgets are under https://github.com/snapcore/ .. > namely the pi2-gadget, pi3-gadget, pc-gadget and dragonboard-gadget > sub-trees if you want to take a look ... > > 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/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Wed Jan 18 12:32:28 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 18 Jan 2017 13:32:28 +0100 Subject: Serial Port Plug/Interface issue with Ubuntu-core 16.04 (#2557) In-Reply-To: References: <1484159840.26677.55.camel@ubuntu.com> <42ffc25d06fe4aa4a3b554df27f2e580@sfo-ex13-04.silverspringnet.com> Message-ID: <1484742748.4288.14.camel@ubuntu.com> hi, Am Mittwoch, den 18.01.2017, 13:26 +0100 schrieb Simon Fels: > > $ snap download pi3 > $ unsquashfs pi3_*.snap > # Do any modifications to squashfs-root/meta/snap.yaml > $ snapcraft snap squashfs-root > # Now you have a new .snap file snapcraft generated for you > $ ubuntu-image ... --extra-snaps my-gadget.snap ... my-model.assert > better do: $ git clone https://github.com/snapcore/pi3-gadget $ cd pi3-gadget # make your changes in snapcraft.yaml to add the slots you need then just run: $ snapcraft # .. and use ubuntu-image as described above ... ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From gustavo at niemeyer.net Wed Jan 18 12:33:54 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 18 Jan 2017 10:33:54 -0200 Subject: create-user primitive In-Reply-To: References: Message-ID: Don't see a reason to go beyond not listing it. The command works fine, including proper help and reasonable error messages. The reason it prevents creating users when one already exists is so we don't see scripts opening back doors by mistake. As Michael points out, this may be overriden with --force-managed. On Wed, Jan 18, 2017 at 6:10 AM, Evan Dandrea wrote: > On Tue, 17 Jan 2017 at 23:31 Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: > >> Well snap create-user is mostly there exactly so that console-conf can >> invoke it. That's also why it's hidden from snap help! >> > > If it's mostly not intended to be used by humans, would it be reasonable > to have it print a warning? > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Wed Jan 18 12:54:31 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 12:54:31 +0000 Subject: Please test my asciinema snap In-Reply-To: <20170118114149.64bfe73e@Stryder> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <20170118114149.64bfe73e@Stryder> Message-ID: On Wed, 18 Jan 2017 11:41:49 +0000, Dave Morley wrote: > On Wed, 18 Jan 2017 04:16:45 -0500 > Mark Shuttleworth wrote: > >> Hi folks >> >> (For those of you who Gmail does not filter this email on >> as-yet-unexplained-grounds :)) >> >> Please could you test my asciinema snap? Asciinema is a console video >> recording utility that's great for CLI-diven demos. If you want to >> make a quick web video of a CLI / console journey, asciinema is the >> ticket. >> >> An older version (0.9.8) is in 16.04. The new 1.3.0 version is now a >> snap, and it should work on 16.04. I am also interested in feedback on >> 14.04 for those of you on Trusty steeds who are blazing the >> snaps-on-trusty trail. >> >> It's a 'classic-only' snap, so you need: >> >> sudo snap install --classic asciinema >> >> Then 'asciinema rec' starts a recording session, and you're off to the >> races. >> > Not so happy on 14.04 paste.ubuntu.com/23821653/ I get a segfault :( Looking at the snap itself, I see it is python3 and using the in-core python3 which leads to $ readelf -a /snap/core/current/usr/bin/python3 |grep INTERP -A2 INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238 0x000000000000001c 0x000000000000001c R 1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] `stage-packages` that provide runnables will also have this problem; the solution is to use a python3 part (Zygmunt is working on some python parts, he started with python0 though). /brainstorming-mode on It would be interesting to bring back the snapcraft concept of `provides` which has plugin specific meaning, here's an example (made up sources): parts: python3: source: https://python.org/python3.tar.gz plugin: autotools provides: [python3] environment: PYTHONUSERBASE: ... PYTHONHOME: ... asciinema: source: https://sourceforge.org/asciinema.tar.gz plugin: python after: [python3] How will this work, in the general scenario, the `python` plugin will just use its built in logic to obtain python3 (which is through use of `stage-packages`) but given that the part comes `after` the `python3` part and that `python3` part provides `python3` the plugin will no fetch python3 and use the defined `environment` to work it out. Then again, this might be all to complex and a custom plugin that overrides the `python` plugin's `pull` step might be an easier concept. But here is another option: parts: python3: source: https://python.org/python3.tar.gz plugin: autotools asciinema: source: https://sourceforge.org/asciinema.tar.gz plugin: python environment: PYTHONUSERBASE: $SNAPCRAFT_STAGE after: [python3] stage: - -$python3-runtime # defined in filesets filesets: python-runtime: [ .... ] Other ideas anyone? -- Sent using Dekko from my Ubuntu device From michael.sheldon at canonical.com Wed Jan 18 13:47:41 2017 From: michael.sheldon at canonical.com (Mike Sheldon) Date: Wed, 18 Jan 2017 13:47:41 +0000 Subject: Naming for the Ubuntu Download Manager interface Message-ID: <1484747261.7772.34.camel@canonical.com> Hi all,  Currently the interface for UDM (Ubuntu Download Manager) has been named unity8-download-manager. It's my understanding that whilst we might initially be bundling UDM within the unity8 snap to make the first stages of development easier (e.g. so it can talk directly to unity8's transfer indicator), the long term plan would be for it to be available separately.  Having UDM permanently tied to unity8 would seem to add a strong disincentive for app developers to make use of it at all, as their apps would then no-longer be portable across different desktop environments.  As such, I'm wondering if the naming of this interface is perhaps misleading? Thanks,  Mike From gustavo at niemeyer.net Wed Jan 18 14:34:34 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 18 Jan 2017 12:34:34 -0200 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: <1484747261.7772.34.camel@canonical.com> References: <1484747261.7772.34.camel@canonical.com> Message-ID: The real issue with download-manager is that it's too general. We all have several download managers in our systems, so this gives no hint of what it's really talking about. We can call it ubuntu-download-manager if that's how the software was named. Note that part of the rationale of having unity8-contacts and unity8-calendar named like that was that these interfaces are likely to change in meaningful and incompatible ways in the near future. If the download manager is going to be bundled with unity8, it may be wise to do the same. We can always introduce a more general interface later.. not so nice to get out of a general interface that doesn't work. On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon < michael.sheldon at canonical.com> wrote: > Hi all, > > Currently the interface for UDM (Ubuntu Download Manager) has been > named unity8-download-manager. It's my understanding that whilst we > might initially be bundling UDM within the unity8 snap to make the > first stages of development easier (e.g. so it can talk directly to > unity8's transfer indicator), the long term plan would be for it to be > available separately. > > Having UDM permanently tied to unity8 would seem to add a strong > disincentive for app developers to make use of it at all, as their apps > would then no-longer be portable across different desktop environments. > > As such, I'm wondering if the naming of this interface is perhaps > misleading? > > Thanks, > Mike > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From davmor2 at davmor2.co.uk Wed Jan 18 14:38:01 2017 From: davmor2 at davmor2.co.uk (Dave Morley) Date: Wed, 18 Jan 2017 14:38:01 +0000 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> <20170118104047.icqjltuwqd6s4vub@golstein> Message-ID: <20170118143801.2a725332@Stryder> On Wed, 18 Jan 2017 06:34:26 -0500 Mark Shuttleworth wrote: > On 18/01/17 06:12, Sergio Schvezov wrote: > > On Wed, 18 Jan 2017 10:40:47 +0000, Jamie Bennett wrote: > >> On 18/01/17 at 04:19am, Mark Shuttleworth wrote: > >>> ... you may also need to enable xenial-proposed main in > >>> /etc/apt/sources.list to make sure you have the very latest > >>> snapd. > >> Yes, classic needs snapd 2.21 from proposed otherwise you will > >> not be able to > >> find or install the snap. > >> > >> After that, it works a treat [1], thanks. > > Working fine for me as well! > > > Thank you. Loving this :) > > Mark > > https://asciinema.org/a/c7ohu56eupwnq6noyua2k0eum -- You Make It, I'll Break It! I Love My Job :) http://www.canonical.com http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From daniel.watkins at canonical.com Wed Jan 18 14:43:30 2017 From: daniel.watkins at canonical.com (Dan Watkins) Date: Wed, 18 Jan 2017 14:43:30 +0000 Subject: Please test my asciinema snap In-Reply-To: <20170118143801.2a725332@Stryder> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> <20170118104047.icqjltuwqd6s4vub@golstein> <20170118143801.2a725332@Stryder> Message-ID: <31a85b05-4352-80e1-7379-d0e40890efdb@canonical.com> On 18/01/17 14:38, Dave Morley wrote: > https://asciinema.org/a/c7ohu56eupwnq6noyua2k0eum https://asciinema.org/a/3ymbowr1pk6usww8v1iyveai9 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From davmor2 at davmor2.co.uk Wed Jan 18 15:00:06 2017 From: davmor2 at davmor2.co.uk (Dave Morley) Date: Wed, 18 Jan 2017 15:00:06 +0000 Subject: Please test my asciinema snap In-Reply-To: <31a85b05-4352-80e1-7379-d0e40890efdb@canonical.com> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <97b59750-c089-65b9-c606-e892def1fcfe@ubuntu.com> <20170118104047.icqjltuwqd6s4vub@golstein> <20170118143801.2a725332@Stryder> <31a85b05-4352-80e1-7379-d0e40890efdb@canonical.com> Message-ID: <20170118150006.798fdc65@Stryder> On Wed, 18 Jan 2017 14:43:30 +0000 Dan Watkins wrote: > On 18/01/17 14:38, Dave Morley wrote: > > https://asciinema.org/a/c7ohu56eupwnq6noyua2k0eum > > https://asciinema.org/a/3ymbowr1pk6usww8v1iyveai9 > https://asciinema.org/a/0o2pajjotf3k9fnv80btm26qx -- You Make It, I'll Break It! I Love My Job :) http://www.canonical.com http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From michael.sheldon at canonical.com Wed Jan 18 15:01:34 2017 From: michael.sheldon at canonical.com (Mike Sheldon) Date: Wed, 18 Jan 2017 15:01:34 +0000 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: References: <1484747261.7772.34.camel@canonical.com> Message-ID: <1484751694.7772.37.camel@canonical.com> ubuntu-download-manager makes sense as a name to me, especially as it's one of the APIs in the Ubuntu SDK. On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > The real issue with download-manager is that it's too general. We all > have several download managers in our systems, so this gives no hint > of what it's really talking about. > > We can call it ubuntu-download-manager if that's how the software was > named. Note that part of the rationale of having unity8-contacts and > unity8-calendar named like that was that these interfaces are likely > to change in meaningful and incompatible ways in the near future. If > the download manager is going to be bundled with unity8, it may be > wise to do the same. We can always introduce a more general interface > later.. not so nice to get out of a general interface that doesn't > work. > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon ical.com> wrote: > > Hi all, > > > >  Currently the interface for UDM (Ubuntu Download Manager) has been > > named unity8-download-manager. It's my understanding that whilst we > > might initially be bundling UDM within the unity8 snap to make the > > first stages of development easier (e.g. so it can talk directly to > > unity8's transfer indicator), the long term plan would be for it to > > be > > available separately. > > > >  Having UDM permanently tied to unity8 would seem to add a strong > > disincentive for app developers to make use of it at all, as their > > apps > > would then no-longer be portable across different desktop > > environments. > > > >  As such, I'm wondering if the naming of this interface is perhaps > > misleading? > > > > Thanks, > >  Mike > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > --  > > gustavo @ http://niemeyer.net > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft From davmor2 at davmor2.co.uk Wed Jan 18 15:12:15 2017 From: davmor2 at davmor2.co.uk (Dave Morley) Date: Wed, 18 Jan 2017 15:12:15 +0000 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: <1484751694.7772.37.camel@canonical.com> References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> Message-ID: <20170118151215.1047953f@Stryder> On Wed, 18 Jan 2017 15:01:34 +0000 Mike Sheldon wrote: > ubuntu-download-manager makes sense as a name to me, especially as > it's one of the APIs in the Ubuntu SDK. > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > The real issue with download-manager is that it's too general. We > > all have several download managers in our systems, so this gives no > > hint of what it's really talking about. > > > > We can call it ubuntu-download-manager if that's how the software > > was named. Note that part of the rationale of having > > unity8-contacts and unity8-calendar named like that was that these > > interfaces are likely to change in meaningful and incompatible ways > > in the near future. If the download manager is going to be bundled > > with unity8, it may be wise to do the same. We can always introduce > > a more general interface later.. not so nice to get out of a > > general interface that doesn't work. > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > > wrote: > > > Hi all, > > > > > >  Currently the interface for UDM (Ubuntu Download Manager) has > > > been named unity8-download-manager. It's my understanding that > > > whilst we might initially be bundling UDM within the unity8 snap > > > to make the first stages of development easier (e.g. so it can > > > talk directly to unity8's transfer indicator), the long term plan > > > would be for it to be > > > available separately. > > > > > >  Having UDM permanently tied to unity8 would seem to add a strong > > > disincentive for app developers to make use of it at all, as their > > > apps > > > would then no-longer be portable across different desktop > > > environments. > > > > > >  As such, I'm wondering if the naming of this interface is perhaps > > > misleading? > > > > > > Thanks, > > >  Mike > > > > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: > > > https://lists.ubuntu.com/mailman /listinfo/snapcraft > > > > > > > > > --  > > > > gustavo @ http://niemeyer.net > > --  > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/l istinfo/snapcraft > Go down the ufw Route and just call it uncomplicated download manager then it isn't restricted to Ubuntu as a distro or a desktop variant -- You Make It, I'll Break It! I Love My Job :) http://www.canonical.com http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From gustavo at niemeyer.net Wed Jan 18 15:22:07 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 18 Jan 2017 13:22:07 -0200 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> Message-ID: The second part of the point was cut out. Can you please at least let us know how you feel about it, so we can be in sync about the right decision. On Jan 18, 2017 1:02 PM, "Mike Sheldon" wrote: ubuntu-download-manager makes sense as a name to me, especially as it's one of the APIs in the Ubuntu SDK. On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > The real issue with download-manager is that it's too general. We all > have several download managers in our systems, so this gives no hint > of what it's really talking about. > > We can call it ubuntu-download-manager if that's how the software was > named. Note that part of the rationale of having unity8-contacts and > unity8-calendar named like that was that these interfaces are likely > to change in meaningful and incompatible ways in the near future. If > the download manager is going to be bundled with unity8, it may be > wise to do the same. We can always introduce a more general interface > later.. not so nice to get out of a general interface that doesn't > work. > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon ical.com> wrote: > > Hi all, > > > > Currently the interface for UDM (Ubuntu Download Manager) has been > > named unity8-download-manager. It's my understanding that whilst we > > might initially be bundling UDM within the unity8 snap to make the > > first stages of development easier (e.g. so it can talk directly to > > unity8's transfer indicator), the long term plan would be for it to > > be > > available separately. > > > > Having UDM permanently tied to unity8 would seem to add a strong > > disincentive for app developers to make use of it at all, as their > > apps > > would then no-longer be portable across different desktop > > environments. > > > > As such, I'm wondering if the naming of this interface is perhaps > > misleading? > > > > Thanks, > > Mike > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > -- > > gustavo @ http://niemeyer.net > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft -- 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 Wed Jan 18 15:47:27 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 18 Jan 2017 10:47:27 -0500 Subject: Please test my asciinema snap In-Reply-To: <20170118114149.64bfe73e@Stryder> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <20170118114149.64bfe73e@Stryder> Message-ID: <8210d84e-0947-2cb2-8564-39babbcb27d6@ubuntu.com> On 18/01/17 06:41, Dave Morley wrote: > Not so happy on 14.04 paste.ubuntu.com/23821653/ I get a segfault :( Can you report a bug and include 'snap --version' please? Thank you! Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: From ogra at ubuntu.com Wed Jan 18 15:59:37 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Wed, 18 Jan 2017 16:59:37 +0100 Subject: Pi2 and 3 image improvements (GLES, GPIO) Message-ID: <1484755177.4288.19.camel@ubuntu.com> hi, at [1] you can now find a daily image build for the Pi2 and Pi3 that both have full GLES support and all 26 GPIOs exposed through interfaces, some test feedback would be nice :) the GPIO numbering and pin mapping follows the community map at [2] and looks like [3] in the "snap interfaces" output now. ciao oli [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ [2] http://pinout.xyz/# [3] http://paste.ubuntu.com/23822613/ -------------- 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 davmor2 at davmor2.co.uk Wed Jan 18 16:11:46 2017 From: davmor2 at davmor2.co.uk (Dave Morley) Date: Wed, 18 Jan 2017 16:11:46 +0000 Subject: Please test my asciinema snap In-Reply-To: <8210d84e-0947-2cb2-8564-39babbcb27d6@ubuntu.com> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <20170118114149.64bfe73e@Stryder> <8210d84e-0947-2cb2-8564-39babbcb27d6@ubuntu.com> Message-ID: <20170118161146.0863631e@Stryder> On Wed, 18 Jan 2017 10:47:27 -0500 Mark Shuttleworth wrote: > On 18/01/17 06:41, Dave Morley wrote: > > Not so happy on 14.04 paste.ubuntu.com/23821653/ I get a > > segfault :( > > Can you report a bug and include 'snap --version' please? > > Thank you! > Mark > Done https://bugs.launchpad.net/ubuntu/+source/asciinema/+bug/1657504 -- You Make It, I'll Break It! I Love My Job :) http://www.canonical.com http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From michael.sheldon at canonical.com Wed Jan 18 16:15:34 2017 From: michael.sheldon at canonical.com (Mike Sheldon) Date: Wed, 18 Jan 2017 16:15:34 +0000 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> Message-ID: <1484756134.7772.42.camel@canonical.com> Sorry, that was my entire point, I guess I should have expanded on it a bit. I agree with ubuntu-download-manager as a name, since that's the name developers will be interacting with if they're using our SDK. For example under QML they're importing Ubuntu.DownloadManager and the C++ namespace is Ubuntu::DownloadManager. So the interface being named ubuntu-download-manager seems perfectly natural to me (in fact this was the initial name I proposed for it, before it was suggested that download-manager might be a better name). On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > The second part of the point was cut out. Can you please at least let > us know how you feel about it, so we can be in sync about the right > decision. > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" m> wrote: > ubuntu-download-manager makes sense as a name to me, especially as > it's > one of the APIs in the Ubuntu SDK. > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > The real issue with download-manager is that it's too general. We > all > > have several download managers in our systems, so this gives no > hint > > of what it's really talking about. > > > > We can call it ubuntu-download-manager if that's how the software > was > > named. Note that part of the rationale of having unity8-contacts > and > > unity8-calendar named like that was that these interfaces are > likely > > to change in meaningful and incompatible ways in the near future. > If > > the download manager is going to be bundled with unity8, it may be > > wise to do the same. We can always introduce a more general > interface > > later.. not so nice to get out of a general interface that doesn't > > work. > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon on > > ical.com> wrote: > > > Hi all, > > > > > >  Currently the interface for UDM (Ubuntu Download Manager) has > been > > > named unity8-download-manager. It's my understanding that whilst > we > > > might initially be bundling UDM within the unity8 snap to make > the > > > first stages of development easier (e.g. so it can talk directly > to > > > unity8's transfer indicator), the long term plan would be for it > to > > > be > > > available separately. > > > > > >  Having UDM permanently tied to unity8 would seem to add a strong > > > disincentive for app developers to make use of it at all, as > their > > > apps > > > would then no-longer be portable across different desktop > > > environments. > > > > > >  As such, I'm wondering if the naming of this interface is > perhaps > > > misleading? > > > > > > Thanks, > > >  Mike > > > > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an > > > /listinfo/snapcraft > > > > > > > > > --  > > > > gustavo @ http://niemeyer.net > > --  > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > /l > > istinfo/snapcraft > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft > > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft From gustavo at niemeyer.net Wed Jan 18 16:24:42 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Wed, 18 Jan 2017 14:24:42 -0200 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: <1484756134.7772.42.camel@canonical.com> References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> <1484756134.7772.42.camel@canonical.com> Message-ID: Sorry for not being clear. In addition to the suggestion about ubuntu-download-manager, I also wrote this: "Note that part of the rationale of having unity8-contacts and unity8-calendar named like that was that these interfaces are likely to change in meaningful and incompatible ways in the near future. If the download manager is going to be bundled with unity8, it may be wise to do the same. We can always introduce a more general interface later.. not so nice to get out of a general interface that doesn't work." What's your take on it? On Wed, Jan 18, 2017 at 2:15 PM, Mike Sheldon wrote: > Sorry, that was my entire point, I guess I should have expanded on it a > bit. I agree with ubuntu-download-manager as a name, since that's the > name developers will be interacting with if they're using our SDK. For > example under QML they're importing Ubuntu.DownloadManager and the C++ > namespace is Ubuntu::DownloadManager. So the interface being named > ubuntu-download-manager seems perfectly natural to me (in fact this was > the initial name I proposed for it, before it was suggested that > download-manager might be a better name). > > On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > > The second part of the point was cut out. Can you please at least let > > us know how you feel about it, so we can be in sync about the right > > decision. > > > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" > m> wrote: > > ubuntu-download-manager makes sense as a name to me, especially as > > it's > > one of the APIs in the Ubuntu SDK. > > > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > > > The real issue with download-manager is that it's too general. We > > all > > > have several download managers in our systems, so this gives no > > hint > > > of what it's really talking about. > > > > > > We can call it ubuntu-download-manager if that's how the software > > was > > > named. Note that part of the rationale of having unity8-contacts > > and > > > unity8-calendar named like that was that these interfaces are > > likely > > > to change in meaningful and incompatible ways in the near future. > > If > > > the download manager is going to be bundled with unity8, it may be > > > wise to do the same. We can always introduce a more general > > interface > > > later.. not so nice to get out of a general interface that doesn't > > > work. > > > > > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > on > > > ical.com> wrote: > > > > Hi all, > > > > > > > > Currently the interface for UDM (Ubuntu Download Manager) has > > been > > > > named unity8-download-manager. It's my understanding that whilst > > we > > > > might initially be bundling UDM within the unity8 snap to make > > the > > > > first stages of development easier (e.g. so it can talk directly > > to > > > > unity8's transfer indicator), the long term plan would be for it > > to > > > > be > > > > available separately. > > > > > > > > Having UDM permanently tied to unity8 would seem to add a strong > > > > disincentive for app developers to make use of it at all, as > > their > > > > apps > > > > would then no-longer be portable across different desktop > > > > environments. > > > > > > > > As such, I'm wondering if the naming of this interface is > > perhaps > > > > misleading? > > > > > > > > Thanks, > > > > Mike > > > > > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > an > > > > /listinfo/snapcraft > > > > > > > > > > > > > -- > > > > > > gustavo @ http://niemeyer.net > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /l > > > istinfo/snapcraft > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > > istinfo/snapcraft > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > > istinfo/snapcraft > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.sheldon at canonical.com Wed Jan 18 16:34:38 2017 From: michael.sheldon at canonical.com (Mike Sheldon) Date: Wed, 18 Jan 2017 16:34:38 +0000 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> <1484756134.7772.42.camel@canonical.com> Message-ID: <1484757278.7772.47.camel@canonical.com> Ah, my mistake. I'd suspect UDM is less likely to change since it's already a public facing API being used in third party apps. But it sounds like we don't lose anything if we start it off as unity8- download-manager whilst bundled with unity8 if we can then add an additional interface once its distributed in its own snap (although I guess that snap would have to advertise itself as providing both interfaces to keep compatibility with existing snaps).  I'm not sure if we gain much in this particular case though since we'd need to be maintaining a stable API to work with existing apps regardless? On Wed, 2017-01-18 at 14:24 -0200, Gustavo Niemeyer wrote: > Sorry for not being clear. In addition to the suggestion about > ubuntu-download-manager, I also wrote this: > > "Note that part of the rationale of having unity8-contacts and > unity8-calendar named like that was that these interfaces are likely > to change in meaningful and incompatible ways in the near future. If > the download manager is going to be bundled with unity8, it may be > wise to do the same. We can always introduce a more general interface > later.. not so nice to get out of a general interface that doesn't > work." > > What's your take on it? > > > > On Wed, Jan 18, 2017 at 2:15 PM, Mike Sheldon cal.com> wrote: > > Sorry, that was my entire point, I guess I should have expanded on > > it a > > bit. I agree with ubuntu-download-manager as a name, since that's > > the > > name developers will be interacting with if they're using our SDK. > > For > > example under QML they're importing Ubuntu.DownloadManager and the > > C++ > > namespace is Ubuntu::DownloadManager. So the interface being named > > ubuntu-download-manager seems perfectly natural to me (in fact this > > was > > the initial name I proposed for it, before it was suggested that > > download-manager might be a better name). > > > > On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > > > The second part of the point was cut out. Can you please at least > > let > > > us know how you feel about it, so we can be in sync about the > > right > > > decision. > > > > > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" > l.co > > > m> wrote: > > > ubuntu-download-manager makes sense as a name to me, especially > > as > > > it's > > > one of the APIs in the Ubuntu SDK. > > > > > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > > > > > The real issue with download-manager is that it's too general. > > We > > > all > > > > have several download managers in our systems, so this gives no > > > hint > > > > of what it's really talking about. > > > > > > > > We can call it ubuntu-download-manager if that's how the > > software > > > was > > > > named. Note that part of the rationale of having unity8- > > contacts > > > and > > > > unity8-calendar named like that was that these interfaces are > > > likely > > > > to change in meaningful and incompatible ways in the near > > future. > > > If > > > > the download manager is going to be bundled with unity8, it may > > be > > > > wise to do the same. We can always introduce a more general > > > interface > > > > later.. not so nice to get out of a general interface that > > doesn't > > > > work. > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > @can > > > on > > > > ical.com> wrote: > > > > > Hi all, > > > > > > > > > >  Currently the interface for UDM (Ubuntu Download Manager) > > has > > > been > > > > > named unity8-download-manager. It's my understanding that > > whilst > > > we > > > > > might initially be bundling UDM within the unity8 snap to > > make > > > the > > > > > first stages of development easier (e.g. so it can talk > > directly > > > to > > > > > unity8's transfer indicator), the long term plan would be for > > it > > > to > > > > > be > > > > > available separately. > > > > > > > > > >  Having UDM permanently tied to unity8 would seem to add a > > strong > > > > > disincentive for app developers to make use of it at all, as > > > their > > > > > apps > > > > > would then no-longer be portable across different desktop > > > > > environments. > > > > > > > > > >  As such, I'm wondering if the naming of this interface is > > > perhaps > > > > > misleading? > > > > > > > > > > Thanks, > > > > >  Mike > > > > > > > > > > -- > > > > > Snapcraft mailing list > > > > > Snapcraft at lists.snapcraft.io > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > ailm > > > an > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > --  > > > > > > > > gustavo @ http://niemeyer.net > > > > --  > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mai > > lman > > > /l > > > > istinfo/snapcraft > > > > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > an/l > > > istinfo/snapcraft > > > > > > --  > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > an/l > > > istinfo/snapcraft > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > --  > > gustavo @ http://niemeyer.net > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft From spencertparkin at gmail.com Wed Jan 18 17:28:38 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Wed, 18 Jan 2017 10:28:38 -0700 Subject: [announce] twistypuzzle snap In-Reply-To: References: Message-ID: Thank you for the bug report and the feedback! I think I know how to fix that bug. The .yaml file is here... https://github.com/spencerparkin/TwistyPuzzle/blob/stable-release/Snap/snapcraft.yaml Compared to Microsoft's "snapping process," Ubuntu snaps are infinitely better. I have actually never successfully gotten through Microsoft's process. On Wed, Jan 18, 2017 at 1:52 AM, Jamie Bennett wrote: > Great work Spencer. I presume your project is hosted on GitHub at: > > * https://github.com/spencerparkin/TwistyPuzzle > > I don't see a snapcraft.yaml file there so I would be interested in > what it looks like and how you found the whole process. > > After playing with it briefly I have filed the following bug. > * https://github.com/spencerparkin/TwistyPuzzle/issues/1 > > Regards, > Jamie. > > On Wed, Jan 18, 2017 at 6:39 AM, Spencer Parkin > wrote: > > Hi, > > > > I've just uploaded to beta channel my new snap: twistypuzzle. Unlike > > "rubecube," one of my other snaps, this one can simulate a variety of > twisty > > puzzles. My main motivation is the technical challenge such a program > > represents. > > > > There are still some bugs that must be resolved before releasing to the > > stable channel, but in the mean time, I'd be curious to know what anyone > > thinks about it. I think it's a cool idea, but hey, maybe it's not. > > > > Out of curiosity, is there a way to monetize a snap? I see a "buy" > option > > in the snap command, and I see a "price" field on the Ubuntu Apps > web-page > > for my snap, but I can't seem to find any information about how to > configure > > these for a snap. I don't think my snaps are worth anything, and I want > > people to actually use them (so I want them to be free), but it would be > > interesting to know how or if this can be done. > > > > Thanks, > > --Sp > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From manik at canonical.com Wed Jan 18 17:29:16 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 18 Jan 2017 09:29:16 -0800 Subject: Hi In-Reply-To: References: Message-ID: Sunny, Can you please mail your request in to . /Manik On Tue, Jan 17, 2017 at 10:54 PM, Sunny Bhayani < sunny.bhayani at einfochips.com> wrote: > Hi Manik, > > > Thank you for your time. > > > Actually, we have some technical query, related to the ubuntu-image binary > which builds the ubuntu-os. > > > So is this the right forum ? > > If not, then I request you to please connect me to the right person. > > > I have already posted my query on the Rocketchat #snapcraft and #snappy > channels for the same, but the query is open. > > > Keeping in loop my manager Mr. Ajay Pandey. > > > Thanks & Regards, > *Sunny Bhayani* > Solution Consultant | Solutions > Tel: - | Cell: 919909705699 > Product Engineering Services > Software | System | Silicon | Mechanical > > www.einfochips.com | sunny.bhayani at einfochips.com > > > > > > > > 20 Years of Engineering Innovation & Excellence > Recognized as 'Leader' in Zinnov's Global Service Providers Rating-2015 > > ------------------------------ > *From:* Manik Taneja > *Sent:* Wednesday, January 18, 2017 7:12:50 AM > *To:* Sunny Bhayani > *Cc:* Prakash Advani > *Subject:* Hi > > Hi Sunny, > > Hope this email finds you well. Thanks for reaching out on linkedin. I was > wondering as to where are you based and if you were connected to Prakash, > our Dir of Sales India. In any case, please let us know how we can help. > > Regards, > Manik > ************************************************************ > ************************************************************ > ************************************* 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 manik at canonical.com Wed Jan 18 17:37:23 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 18 Jan 2017 09:37:23 -0800 Subject: create-user primitive In-Reply-To: References: Message-ID: On Wed, Jan 18, 2017 at 4:33 AM, Gustavo Niemeyer wrote: > Don't see a reason to go beyond not listing it. The command works fine, > including proper help and reasonable error messages. > > The reason it prevents creating users when one already exists is so we > don't see scripts opening back doors by mistake. As Michael points out, > this may be overriden with --force-managed. > > i would suggest that we document this somewhere. the only way i knew about its existence was the fact that i had seen the primitive in an earlier version of snapd. for others who are not familiar, this might not even show up on their radar. /manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke.williams at canonical.com Wed Jan 18 18:42:27 2017 From: luke.williams at canonical.com (Luke Williams) Date: Wed, 18 Jan 2017 10:42:27 -0800 Subject: Error using custom image Message-ID: Hello, We are trying to build a custom image with a custom kernel. The kernel build and making the image goes without a hitch, however, when we try to run it in Virtual Box, we get the following error: And it fails to load. We have tried an image built with the custom kernel, one built with a yaketty kernel, and one that we just build with all stock pieces. None of them can get past this part. If we use the image that we download from cdimages, that one works. When we look at the images side by side, we can’t see any differences. Is there anything you recommend we check to see why it cannot see the writable partition? Thanks, Luke Williams - Technical Partner Manager, Open Networking/Ubuntu-Core email: luke.williams at canonical.com http://www.canonical.com/ | http://www.ubuntu.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: unknown.png Type: image/png Size: 153743 bytes Desc: not available URL: From sergio.schvezov at canonical.com Wed Jan 18 18:56:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 18 Jan 2017 18:56:00 +0000 Subject: Error using custom image In-Reply-To: References: Message-ID: On Wed, 18 Jan 2017 18:42:27 +0000, Luke Williams wrote: > Hello, > > We are trying to build a custom image with a custom kernel. The > kernel build and making the image goes without a hitch, however, > when we try to run it in Virtual Box, we get the following > error: > > > > And it fails to load. > We have tried an image built with the custom kernel, one built > with a yaketty kernel, and one that we just build with all stock > pieces. None of them can get past this part. > > If we use the image that we download from cdimages, that one > works. When we look at the images side by side, we can’t see any > differences. > Is there anything you recommend we check to see why it cannot > see the writable partition? Without havig touched this in a while have you ensured you have vfat and squashfs either built-in or in initramfs? -- Sent using Dekko from my Ubuntu device From joseph.wakeling at webdrake.net Thu Jan 19 00:37:35 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 19 Jan 2017 01:37:35 +0100 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: On 18/01/17 02:21, Sergio Schvezov wrote: > The logic is still run, but the resulting binary in classic uses rpath and no dynamic loading so there is no resolution to a on-system library we can pick up. I guess we can do some magic, but it feels it might be either fragile or make the build process a lot slower. We will need to look into it, but not short term. OK -- thanks for the explanation. Completely understand the preference to require explicit staging of packages over potentially fragile automation. Anyway, I had a go at tweaking my snap package as defined here: https://github.com/WebDrake/ldc2.snap/pull/1/files https://github.com/WebDrake/ldc2.snap/blob/a437ec17d50bdd767febebf5b617d7d3a716716b/snapcraft.yaml ... to use `classic` confinement and staging packages necessary for linking. I've posted the resulting `snapcraft.yaml` below. The major diff apart from the `confinement` setting is the addition of these lines to the `ldc` part of the file: stage-packages: - libconfig++-dev - libphobos2-ldc-dev When I run `snapcraft build`, however, everything builds and links fine, but _nothing_ gets staged (the `stage/` and `prime/` directories both remain empty). I've tried the same thing while removing the `gcc`, `gcc-wrapper`, `libc6` and `libc6-dev` parts, with the same result. Any thoughts on what could be the problem here? --- snapcraft.yaml -------------------------------------------------- name: ldc2 version: "1.1.0-beta6" summary: D compiler with LLVM backend description: | LDC is a portable compiler for the D programming Language, with modern optimization and code generation capabilities. It uses the official DMD compiler frontend to support the latest version of D2, and uses the LLVM Core libraries for code generation. confinement: classic grade: devel apps: ldc2: command: ldc2 plugs: [home] ldmd2: command: ldmd2 plugs: [home] ldc-profdata: command: ldc-profdata plugs: [home] parts: ldc: source: git://github.com/ldc-developers/ldc.git source-tag: v1.1.0-beta6 plugin: cmake stage: - -etc/ldc2.conf build-packages: - build-essential - ldc - llvm-dev - libconfig++-dev - libedit-dev - zlib1g-dev stage-packages: - libconfig++-dev - libphobos2-ldc-dev ldc-config: plugin: dump source: ldc-config organize: ldc2.conf: etc/ldc2.conf gcc: plugin: nil stage-packages: [gcc] organize: usr/bin/gcc: usr/bin/gcc.real gcc-wrapper: plugin: dump source: gcc-wrapper organize: gcc.wrapper: usr/bin/gcc libc6: plugin: nil stage-packages: [libc6] libc6-dev: plugin: nil stage-packages: [libc6-dev] From joseph.wakeling at webdrake.net Thu Jan 19 00:55:36 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 19 Jan 2017 01:55:36 +0100 Subject: Classic confinement and core_dynamic_linker In-Reply-To: <3r2iq0.ojz5x2.1hge17a-qmf@smtp.googlemail.com> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> <3r2iq0.ojz5x2.1hge17a-qmf@smtp.googlemail.com> Message-ID: <655b1f49-9888-bc75-1176-5a2696a9fa0c@webdrake.net> On 18/01/17 13:12, Sergio Schvezov wrote: > After a quick but thorough conversation with Gustavo we agreed that this is the wrong path to take as it might not be deterministic or people might get surprised about things included that shouldn't have been. > > There needs to be a clear line between `build-packages` and `stage-packages`. With that in mind snapcraft (even for `strict` snaps) will still crawl all the libraries and error on missing ones with a list of those that are missing. This should be something one can disable and set to ignore as some of the missing libraries might be provided by a content interface slot from another snap. Well, I'm glad that my question may have led to a more rigorous and consistent definition of desired snapcraft behaviour, even if it means a slightly longer snapcraft.yaml ... :-) From manik at canonical.com Thu Jan 19 01:00:50 2017 From: manik at canonical.com (Manik Taneja) Date: Wed, 18 Jan 2017 17:00:50 -0800 Subject: Locally extending trusted certificates In-Reply-To: References: Message-ID: hi there, just wanted to follow-up on this query and see if we have a solution to this problem? /manik On Fri, Jan 6, 2017 at 9:17 AM, Loïc Minier wrote: > Hi, > > This question came up in the context of Docker registries with self-signed > certificates: > http://askubuntu.com/questions/868268/add-self-signed-certif > icate-in-ubuntu-core-16-04 > this could be addressed in ways specific to the Docker snap, but I believe > this touches a larger question: support for extending the list of > system-trusted certificates. > > Our Ubuntu Core images ship with a set of trusted certificates. These are > inherited from the .deb world where there is a mechanism to locally extend > the list of trusted certificates (update-ca-certificates). This mechanism > doesn't work with core images due to read-only directories (and perhaps > other issues as well). > > Here are some possible options to address this: > 1) fix the update-ca-certificates system to also work on core images; this > might just be a matter of making some directories bind-mounts to the > writable space > > 2) implement some kind of snapd keystore feature/configs/APIs (much like > system keystores on mobile OSes); this is likely significant work, but > opens interesting perspectives in providing new management APIs and a more > secure implementation. For instance, one could design this to store secrets > in hw-specific secure stores, or offer mechanisms to roll out new > certificates/keys via assertions, or to disable some specific CAs > > 3) keep the list of system certificates as static and not locally > configurable; this will likely result in some snaps developing alternate > keystores > > I'm sure there are other options and I'd to hear how people think this > should best be addressed in the snap/snapd world. > > Cheers, > - Loïc Minier > > -- > 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 tonny.tzeng at gmail.com Thu Jan 19 09:41:43 2017 From: tonny.tzeng at gmail.com (Tonny Tzeng) Date: Thu, 19 Jan 2017 17:41:43 +0800 Subject: Which snap interface allows accessing /dev/rfkill? Message-ID: Hi, I'd like to unblock the Bluetooth interface on Ubuntu Core, so I use 'stage-packages' keyword to install 'rfkill' package to my snap. If I install the snap in devmode, the rfkill command works as expected. But if the snap is installed in confined mode, I always get 'Permission denied', and the /var/log/syslog shows below message: Jan 19 09:17:42 localhost kernel: [177262.419927] audit: type=1400 audit(1484817462.015:2031): apparmor="DENIED" operation="open" profile="snap.iotivity-smarthome-demo.rfkill" name="/dev/rfkill" pid=14430 comm="rfkill" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0 Would anyone help me which interface should I declare with the plugs keyword? I've tried hardware-observe and bluetooth-control interfaces but no success. Any pointers would be appreciated, thanks in advance. Best Regards, Tonny -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Thu Jan 19 09:49:57 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Thu, 19 Jan 2017 09:49:57 +0000 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: Hi Tonny, A quick grep of the snapd source code shows that /dev/rfkill is part of the network-control and network-manager interfaces. Regards, Jamie. > On 19 Jan 2017, at 09:41, Tonny Tzeng wrote: > > Hi, > > I'd like to unblock the Bluetooth interface on Ubuntu Core, so I use 'stage-packages' keyword to install 'rfkill' package to my snap. If I install the snap in devmode, the rfkill command works as expected. But if the snap is installed in confined mode, I always get 'Permission denied', and the /var/log/syslog shows below message: > > Jan 19 09:17:42 localhost kernel: [177262.419927] audit: type=1400 audit(1484817462.015:2031): apparmor="DENIED" operation="open" profile="snap.iotivity-smarthome-demo.rfkill" name="/dev/rfkill" pid=14430 comm="rfkill" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0 > > Would anyone help me which interface should I declare with the plugs keyword? I've tried hardware-observe and bluetooth-control interfaces but no success. Any pointers would be appreciated, thanks in advance. > > Best Regards, > Tonny > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From simon.fels at canonical.com Thu Jan 19 09:50:39 2017 From: simon.fels at canonical.com (Simon Fels) Date: Thu, 19 Jan 2017 10:50:39 +0100 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: <29fd8106-adce-d980-7883-3fb0d68149be@canonical.com> On 19.01.2017 10:41, Tonny Tzeng wrote: > Hi, > > I'd like to unblock the Bluetooth interface on Ubuntu Core, so I use > 'stage-packages' keyword to install 'rfkill' package to my snap. If I > install the snap in devmode, the rfkill command works as expected. But > if the snap is installed in confined mode, I always get 'Permission > denied', and the /var/log/syslog shows below message: > > Jan 19 09:17:42 localhost kernel: [177262.419927] audit: type=1400 > audit(1484817462.015:2031): apparmor="DENIED" operation="open" > profile="snap.iotivity-smarthome-demo.rfkill" name="/dev/rfkill" > pid=14430 comm="rfkill" requested_mask="r" denied_mask="r" fsuid=1001 ouid=0 > > Would anyone help me which interface should I declare with the plugs > keyword? I've tried hardware-observe and bluetooth-control interfaces > but no success. Any pointers would be appreciated, thanks in advance. The 'network-control' interface should do the job for you. See https://github.com/snapcore/snapd/blob/master/interfaces/builtin/network_control.go#L94 regards, Simon From sergio.schvezov at canonical.com Thu Jan 19 11:51:42 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 19 Jan 2017 11:51:42 +0000 Subject: Snapcraft 2.25 has been released Message-ID: Hello snapcrafters! We are pleased to announce the release of version `2.25` of snapcraft has been released: https://launchpad.net/snapcraft/+milestone/2.25 This release is now available on xenial-updates, yakkety-updates and zesty. What follows are the full release notes (the prettier version can be read at https://github.com/snapcore/snapcraft/releases/tag/2.25) # New in this release ## Support for hooks Hooks support has arrived. There are currently two ways to use them, either with a by-convention path or by using a `part` and installing into an expected path in the part's install directory. Find out more about this feature at https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md ## Desktop file support Aside from the by-convention functionality already in place, you can now declare a desktop file from your app within an `apps` entry using a path relative to the `prime` directory pointing to a desktop file, snapcraft will take care of the rest. So if your project already has a desktop file, say in `./prime/usr/share/applications/my-app.desktop` all you need to do is something like this: ```yaml apps: my-app: command: my-app desktop: usr/share/applications/my-app.desktop ``` That said, it is worth mentioning that the by-convention mechanism is still supported. ## rust plugin The `rust` plugin has seen an improvement and a couple of bug fixes. The added feature allow for one to set `rust-features` which is a list of strings used to build optional dependencies (run `snapcraft help rust` for a bit more details). The bug fixes relate to: - Allowing to build with `Cargo.toml` not in the base source directory. - Repecting the other `rust` plugin properties: `rust-channel` and `rust-revision`. ## nodejs plugin The plugin now correctly downloads dependencies in `package.json` to the correct location. ## godeps plugin This plugin is now no longer affected by `GOBIN` being set in the environment. ## deb sources `deb` sources are now being handled with `python-debian` which does incorrecly handle symlinks. ## More modes for daemon's in apps You can now set the `daemon` property in an `apps` entry to `notify` (and it will follow systemd's expected behavior for this service type). ## Deprecations Some new deprecations have been introduced, for `parts` the `prime` keyword is now favored over the `snap` one. When using the `snap` keyword a link to http://snapcraft.io/docs/deprecation-notices/dn1 will be presented with more information and the migration path. Plugins that are part of snapcraft that were displaying `DEPRECATED` notices have all been updated to use the newer plugin API. ## Classic confinement Some improvements were made to classic confinement with a more comprehensive error when the prerequisites to build a classic confined snap are not met. ## parts Improvements were made to the core parts management of snapcraft: - `stage` entries now don't need to be replicated in `prime`. - cleaning all parts works correctly even if `snapcraft.yaml` is broken. ## Others For the full list of things available on 2.25 feel free to check https://launchpad.net/snapcraft/+milestone/2.25 # 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: - Chris Holcombe - Jonathon Love - Kit Randel - Marco Trevisan - Matthew Aguirre - Olivier Tilloy # Final Notes To get the source for this release check it out at https://github.com/snapcore/snapcraft/releases/tag/2.25 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 sergiusens at gmail.com Thu Jan 19 02:47:43 2017 From: sergiusens at gmail.com (Sergio Schvezov) Date: Thu, 19 Jan 2017 02:47:43 +0000 Subject: Snapcraft 2.25 has been released. Message-ID: Hello snapcrafters! We are pleased to announce the release of version `2.25` of snapcraft has been released: https://launchpad.net/snapcraft/+milestone/2.25 This release is now available on xenial-updates, yakkety-updates and zesty. What follows are the full release notes (the prettier version can be read at https://github.com/snapcore/snapcraft/releases/tag/2.25) # New in this release ## Support for hooks Hooks support has arrived. There are currently two ways to use them, either with a by-convention path or by using a `part` and installing into an expected path in the part's install directory. Find out more about this feature at https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md ## Desktop file support Aside from the by-convention functionality already in place, you can now declare a desktop file from your app within an `apps` entry using a path relative to the `prime` directory pointing to a desktop file, snapcraft will take care of the rest. So if your project already has a desktop file, say in `./prime/usr/share/applications/my-app.desktop` all you need to do is something like this: ```yaml apps: my-app: command: my-app desktop: usr/share/applications/my-app.desktop ``` That said, it is worth mentioning that the by-convention mechanism is still supported. ## rust plugin The `rust` plugin has seen an improvement and a couple of bug fixes. The added feature allow for one to set `rust-features` which is a list of strings used to build optional dependencies (run `snapcraft help rust` for a bit more details). The bug fixes relate to: - Allowing to build with `Cargo.toml` not in the base source directory. - Repecting the other `rust` plugin properties: `rust-channel` and `rust-revision`. ## nodejs plugin The plugin now correctly downloads dependencies in `package.json` to the correct location. ## godeps plugin This plugin is now no longer affected by `GOBIN` being set in the environment. ## deb sources `deb` sources are now being handled with `python-debian` which does incorrecly handle symlinks. ## More modes for daemon's in apps You can now set the `daemon` property in an `apps` entry to `notify` (and it will follow systemd's expected behavior for this service type). ## Deprecations Some new deprecations have been introduced, for `parts` the `prime` keyword is now favored over the `snap` one. When using the `snap` keyword a link to http://snapcraft.io/docs/deprecation-notices/dn1 will be presented with more information and the migration path. Plugins that are part of snapcraft that were displaying `DEPRECATED` notices have all been updated to use the newer plugin API. ## Classic confinement Some improvements were made to classic confinement with a more comprehensive error when the prerequisites to build a classic confined snap are not met. ## parts Improvements were made to the core parts management of snapcraft: - `stage` entries now don't need to be replicated in `prime`. - cleaning all parts works correctly even if `snapcraft.yaml` is broken. ## Others For the full list of things available on 2.25 feel free to check https://launchpad.net/snapcraft/+milestone/2.25 # 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: - Chris Holcombe - Jonathon Love - Kit Randel - Marco Trevisan - Matthew Aguirre - Olivier Tilloy # Final Notes To get the source for this release check it out at https://github.com/snapcore/snapcraft/releases/tag/2.25 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 tonny.tzeng at gmail.com Thu Jan 19 14:13:52 2017 From: tonny.tzeng at gmail.com (Tonny Tzeng) Date: Thu, 19 Jan 2017 22:13:52 +0800 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: <29fd8106-adce-d980-7883-3fb0d68149be@canonical.com> References: <29fd8106-adce-d980-7883-3fb0d68149be@canonical.com> Message-ID: Thanks for your quick responses, Simon & Jamie, it works by connect the snap to 'network-control' interface. Many thanks! Best Regards, Tonny On Thu, Jan 19, 2017 at 5:50 PM, Simon Fels wrote: > On 19.01.2017 10:41, Tonny Tzeng wrote: > > Hi, > > > > I'd like to unblock the Bluetooth interface on Ubuntu Core, so I use > > 'stage-packages' keyword to install 'rfkill' package to my snap. If I > > install the snap in devmode, the rfkill command works as expected. But > > if the snap is installed in confined mode, I always get 'Permission > > denied', and the /var/log/syslog shows below message: > > > > Jan 19 09:17:42 localhost kernel: [177262.419927] audit: type=1400 > > audit(1484817462.015:2031): apparmor="DENIED" operation="open" > > profile="snap.iotivity-smarthome-demo.rfkill" name="/dev/rfkill" > > pid=14430 comm="rfkill" requested_mask="r" denied_mask="r" fsuid=1001 > ouid=0 > > > > Would anyone help me which interface should I declare with the plugs > > keyword? I've tried hardware-observe and bluetooth-control interfaces > > but no success. Any pointers would be appreciated, thanks in advance. > > The 'network-control' interface should do the job for you. See > https://github.com/snapcore/snapd/blob/master/interfaces/ > builtin/network_control.go#L94 > > regards, > Simon > > > -- > 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 tonny.tzeng at gmail.com Thu Jan 19 14:56:48 2017 From: tonny.tzeng at gmail.com (Tonny Tzeng) Date: Thu, 19 Jan 2017 22:56:48 +0800 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: <29fd8106-adce-d980-7883-3fb0d68149be@canonical.com> Message-ID: BTW, while trying different interfaces for getting permission for /dev/rfkill, I accidentally set 'kernel-module-control' plug in my snap, which triggers pending review of the snap, and blocking following pushes. How could I withdraw or drop the pending snap and it's successors in the Store? Best Regards, Tonny On Thu, Jan 19, 2017 at 10:13 PM, Tonny Tzeng wrote: > Thanks for your quick responses, Simon & Jamie, it works by connect the > snap to 'network-control' interface. Many thanks! > > Best Regards, > Tonny > > On Thu, Jan 19, 2017 at 5:50 PM, Simon Fels > wrote: > >> On 19.01.2017 10:41, Tonny Tzeng wrote: >> > Hi, >> > >> > I'd like to unblock the Bluetooth interface on Ubuntu Core, so I use >> > 'stage-packages' keyword to install 'rfkill' package to my snap. If I >> > install the snap in devmode, the rfkill command works as expected. But >> > if the snap is installed in confined mode, I always get 'Permission >> > denied', and the /var/log/syslog shows below message: >> > >> > Jan 19 09:17:42 localhost kernel: [177262.419927] audit: type=1400 >> > audit(1484817462.015:2031): apparmor="DENIED" operation="open" >> > profile="snap.iotivity-smarthome-demo.rfkill" name="/dev/rfkill" >> > pid=14430 comm="rfkill" requested_mask="r" denied_mask="r" fsuid=1001 >> ouid=0 >> > >> > Would anyone help me which interface should I declare with the plugs >> > keyword? I've tried hardware-observe and bluetooth-control interfaces >> > but no success. Any pointers would be appreciated, thanks in advance. >> >> The 'network-control' interface should do the job for you. See >> https://github.com/snapcore/snapd/blob/master/interfaces/bui >> ltin/network_control.go#L94 >> >> regards, >> Simon >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.ries at canonical.com Thu Jan 19 14:58:53 2017 From: oliver.ries at canonical.com (Oliver Ries) Date: Thu, 19 Jan 2017 07:58:53 -0700 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: On Thu, Jan 19, 2017 at 2:49 AM, Jamie Bennett wrote: > Hi Tonny, > > A quick grep of the snapd source code shows that /dev/rfkill is part of > the network-control and network-manager interfaces. > this method (grep the code) has been a repeated answer in the last few days, do we have any way of publishing this as part of our documentation? Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabiocolella1990 at gmail.com Thu Jan 19 15:20:57 2017 From: fabiocolella1990 at gmail.com (Fabio Colella) Date: Thu, 19 Jan 2017 16:20:57 +0100 Subject: Snapping webapps Message-ID: Hello, I'm trying to snap a simple webapp for HexGL. Here's the code: https://github.com/fcole90/fcole-hexgl-webapp Unfortunately it's failing to start due to the following error: Qt: Session management error: None of the authentication protocols specified are supported QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries. "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16.04.20160413/src/app/webcontainer/webapp-container.qml:-1 File not found\n" You can try it with: snap install --beta fcole90-hexgl-webapp And run it with: fcole90-hexgl-webapp.hexgl-webapp Let me know if it happens for you too. -- Yours sincerely, Fabio Colella -------------- next part -------------- An HTML attachment was scrubbed... URL: From nitin.mahendru88 at gmail.com Thu Jan 19 15:48:17 2017 From: nitin.mahendru88 at gmail.com (nitin mahendru) Date: Thu, 19 Jan 2017 15:48:17 +0000 Subject: Signing snaps with your own keys on your own local store. Message-ID: Hi Everyone, I am new to the world of snaps and am pretty excited to learn more about it. I am trying to run ubuntu core on a Raspberry pi and I want to securely update snaps which run on it. What I want to do is: 1. Build my own snap 2. upload it to my own instance of a snap store where while uploading it can be signed using a keypair that I provide. 3. Run snap install on my raspberry Pi to install the snap I uploaded into my store. This should involve signature verification with my own public key. I can't seem to find the source code for a snap store. I found this https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex Then I also found this implementation https://github.com/noise/snapstore but that doesn't seem to serve my purpose. Do you guys know of a propper implementation for the snapstore ? I am trying to get past point 2 above. Thanks in advance. cheers! Nitin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Thu Jan 19 15:54:06 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 19 Jan 2017 15:54:06 +0000 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: On Thu, 19 Jan 2017 07:58:53 -0700, Oliver Ries wrote: > On Thu, Jan 19, 2017 at 2:49 AM, Jamie Bennett > wrote: > >> Hi Tonny, >> >> A quick grep of the snapd source code shows that /dev/rfkill is part of >> the network-control and network-manager interfaces. >> > > this method (grep the code) has been a repeated answer in the last few > days, do we have any way of publishing this as part of our documentation? It was one of the feedback items from James last week: - all interfaces described. - extended information on what the interface provides (apparmor rules and seccomp) for easier debugging or figuring out what you need. These don't need to be in your face. -- Sent using Dekko from my Ubuntu device From joe.talbott at canonical.com Thu Jan 19 15:56:44 2017 From: joe.talbott at canonical.com (Joe Talbott) Date: Thu, 19 Jan 2017 10:56:44 -0500 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: On Wed, Jan 18, 2017 at 7:37 PM, Joseph Rushton Wakeling wrote: > On 18/01/17 02:21, Sergio Schvezov wrote: >> >> The logic is still run, but the resulting binary in classic uses rpath and >> no dynamic loading so there is no resolution to a on-system library we can >> pick up. I guess we can do some magic, but it feels it might be either >> fragile or make the build process a lot slower. We will need to look into >> it, but not short term. > > > OK -- thanks for the explanation. Completely understand the preference to > require explicit staging of packages over potentially fragile automation. > > Anyway, I had a go at tweaking my snap package as defined here: > https://github.com/WebDrake/ldc2.snap/pull/1/files > https://github.com/WebDrake/ldc2.snap/blob/a437ec17d50bdd767febebf5b617d7d3a716716b/snapcraft.yaml > > ... to use `classic` confinement and staging packages necessary for linking. > I've posted the resulting `snapcraft.yaml` below. The major diff apart from > the `confinement` setting is the addition of these lines to the `ldc` part > of the file: > > stage-packages: > - libconfig++-dev > - libphobos2-ldc-dev > > When I run `snapcraft build`, however, everything builds and links fine, but > _nothing_ gets staged (the `stage/` and `prime/` directories both remain > empty). I've tried the same thing while removing the `gcc`, `gcc-wrapper`, > `libc6` and `libc6-dev` parts, with the same result. > > Any thoughts on what could be the problem here? > 'snapcraft build' only builds the part. You'd need to run 'snapcraft stage' to get files into the stage directory and 'snapcraft prime' to get files into the prime directory. 'snapcraft prime' will do a 'snapcraft stage' as part of its lifecycle. Joe From mark at ubuntu.com Thu Jan 19 16:10:12 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 19 Jan 2017 08:10:12 -0800 Subject: Signing snaps with your own keys on your own local store. In-Reply-To: References: Message-ID: I would suggest you start with classic (deb-based) Ubuntu and make 'classic' snaps. When those are working well you can start devmode development to add the confinement, which gives you fully confined ('strict') snaps. At that point, you can use Ubuntu Core. On the store, there are various folks taking different approaches, you might want to just use the public one for now (you can have private snaps in there). We'll make it easier to install your own store soon. Mark On 19/01/17 07:48, nitin mahendru wrote: > Hi Everyone, > > I am new to the world of snaps and am pretty excited to learn more > about it. > > I am trying to run ubuntu core on a Raspberry pi and I want to > securely update snaps which run on it. > > What I want to do is: > > 1. Build my own snap > 2. upload it to my own instance of a snap store where while uploading > it can be signed using a keypair that I provide. > 3. Run snap install on my raspberry Pi to install the snap I uploaded > into my store. This should involve signature verification with my own > public key. > > I can't seem to find the source code for a snap store. I found this > https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex > > Then I also found this implementation > https://github.com/noise/snapstore but that doesn't seem to serve my > purpose. > > Do you guys know of a propper implementation for the snapstore ? I am > trying to get past point 2 above. > > Thanks in advance. > > cheers! > Nitin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke.williams at canonical.com Thu Jan 19 17:08:33 2017 From: luke.williams at canonical.com (Luke Williams) Date: Thu, 19 Jan 2017 09:08:33 -0800 Subject: Error using custom image In-Reply-To: References: Message-ID: That fixed it for the most part. Now we are getting dropped to a maintenance shell saying that our /lib/modules/ directory is empty. I feel this might have something to do with how we are building the kernel itself. Thanks, Luke Williams - Technical Partner Manager, Open Networking/Ubuntu-Core email: luke.williams at canonical.com http://www.canonical.com/ | http://www.ubuntu.com > On Jan 18, 2017, at 10:56 AM, Sergio Schvezov wrote: > > On Wed, 18 Jan 2017 18:42:27 +0000, Luke Williams wrote: >> Hello, >> >> We are trying to build a custom image with a custom kernel. The >> kernel build and making the image goes without a hitch, however, >> when we try to run it in Virtual Box, we get the following >> error: >> >> >> >> And it fails to load. >> We have tried an image built with the custom kernel, one built >> with a yaketty kernel, and one that we just build with all stock >> pieces. None of them can get past this part. >> >> If we use the image that we download from cdimages, that one >> works. When we look at the images side by side, we can’t see any >> differences. >> Is there anything you recommend we check to see why it cannot >> see the writable partition? > > Without havig touched this in a while have you ensured you have vfat and squashfs either built-in or in initramfs? > > -- > Sent using Dekko from my Ubuntu device > > -- > 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 nitin.mahendru88 at gmail.com Thu Jan 19 17:09:44 2017 From: nitin.mahendru88 at gmail.com (nitin mahendru) Date: Thu, 19 Jan 2017 17:09:44 +0000 Subject: Signing snaps with your own keys on your own local store. In-Reply-To: References: Message-ID: Mark, Thank you for such a quick reply. I'll wait for the release of the store code from you guys. Meanwhile I will try to see if I can modify the public one for my needs. Thanks Nitin On Thu, Jan 19, 2017 at 8:11 AM Mark Shuttleworth wrote: > > I would suggest you start with classic (deb-based) Ubuntu and make > 'classic' snaps. When those are working well you can start devmode > development to add the confinement, which gives you fully confined > ('strict') snaps. At that point, you can use Ubuntu Core. > > On the store, there are various folks taking different approaches, you > might want to just use the public one for now (you can have private snaps > in there). We'll make it easier to install your own store soon. > > Mark > > > On 19/01/17 07:48, nitin mahendru wrote: > > Hi Everyone, > > I am new to the world of snaps and am pretty excited to learn more about > it. > > I am trying to run ubuntu core on a Raspberry pi and I want to securely > update snaps which run on it. > > What I want to do is: > > 1. Build my own snap > 2. upload it to my own instance of a snap store where while uploading it > can be signed using a keypair that I provide. > 3. Run snap install on my raspberry Pi to install the snap I uploaded into > my store. This should involve signature verification with my own public key. > > I can't seem to find the source code for a snap store. I found this > https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex > > Then I also found this implementation https://github.com/noise/snapstore > but that doesn't seem to serve my purpose. > > Do you guys know of a propper implementation for the snapstore ? I am > trying to get past point 2 above. > > Thanks in advance. > > cheers! > Nitin > > > > -- > 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 Thu Jan 19 17:18:19 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 19 Jan 2017 18:18:19 +0100 Subject: Error using custom image In-Reply-To: References: Message-ID: <1484846299.4288.22.camel@ubuntu.com> hi, Am Donnerstag, den 19.01.2017, 09:08 -0800 schrieb Luke Williams: > That fixed it for the most part. Now we are getting dropped to a > maintenance shell saying that our /lib/modules/ directory is empty. I > feel this might have something to do with how we are building the > kernel itself.  so how do you build the kernel yourself ?  note that you should use snapcraft and the kernel plugin to properly create a snap of it, which will put the modules in the right places. this snap you then hand to ubuntu-image with the --extra-snaps option when creating the signed image ... https://docs.ubuntu.com/core/en/guides/build-device/image-building describes this process in detail ... 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 tyhicks at canonical.com Thu Jan 19 17:43:36 2017 From: tyhicks at canonical.com (Tyler Hicks) Date: Thu, 19 Jan 2017 11:43:36 -0600 Subject: Locally extending trusted certificates In-Reply-To: References: Message-ID: <573814d1-efe6-1732-ce6c-324298276279@canonical.com> On 01/18/2017 07:00 PM, Manik Taneja wrote: > hi there, > > just wanted to follow-up on this query and see if we have a solution to > this problem? There have been some offline discussions about possible solutions but they're still in the early stages and nobody is actively work on this right now. Loïc's request of allowing the admin to extend the set of system-wide trusted certs is the most useful/common use case of extending the system certs. I think the first step would be to fully design option #1 or think through the basic requirements for snapd to manage adding/deleting certs specified by the admin (a simpler version of #2). Tyler > /manik > > On Fri, Jan 6, 2017 at 9:17 AM, Loïc Minier > wrote: > > Hi, > > This question came up in the context of Docker registries with > self-signed certificates: > http://askubuntu.com/questions/868268/add-self-signed-certificate-in-ubuntu-core-16-04 > > this could be addressed in ways specific to the Docker snap, but I > believe this touches a larger question: support for extending the > list of system-trusted certificates. > > Our Ubuntu Core images ship with a set of trusted certificates. > These are inherited from the .deb world where there is a mechanism > to locally extend the list of trusted certificates > (update-ca-certificates). This mechanism doesn't work with core > images due to read-only directories (and perhaps other issues as well). > > Here are some possible options to address this: > 1) fix the update-ca-certificates system to also work on core > images; this might just be a matter of making some directories > bind-mounts to the writable space > > 2) implement some kind of snapd keystore feature/configs/APIs (much > like system keystores on mobile OSes); this is likely significant > work, but opens interesting perspectives in providing new management > APIs and a more secure implementation. For instance, one could > design this to store secrets in hw-specific secure stores, or offer > mechanisms to roll out new certificates/keys via assertions, or to > disable some specific CAs > > 3) keep the list of system certificates as static and not locally > configurable; this will likely result in some snaps developing > alternate keystores > > I'm sure there are other options and I'd to hear how people think > this should best be addressed in the snap/snapd world. > > Cheers, > - Loïc Minier > > -- > 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: 801 bytes Desc: OpenPGP digital signature URL: From fcole90 at gmail.com Thu Jan 19 18:14:01 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Thu, 19 Jan 2017 19:14:01 +0100 Subject: Fwd: Snapping webapps In-Reply-To: References: Message-ID: Hello, I'm trying to snap a simple webapp for HexGL. Here's the code: https://github.com/fcole90/fcole-hexgl-webapp Unfortunately it's failing to start due to the following error: Qt: Session management error: None of the authentication protocols specified are supported QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries. "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16. 04.20160413/src/app/webcontainer/webapp-container.qml:-1 File not found\n" You can try it with: snap install --beta fcole90-hexgl-webapp And run it with: fcole90-hexgl-webapp.hexgl-webapp Let me know if it happens for you too. -- Yours sincerely, Fabio Colella -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Thu Jan 19 19:54:57 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 19 Jan 2017 20:54:57 +0100 Subject: Classic confinement and core_dynamic_linker In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <79rs86.ojy0q7.1hge17a-qmf@smtp.googlemail.com> <0f3f8bb6-991e-bb89-65ab-11c728189419@webdrake.net> Message-ID: <0a5e38ee-26f3-1e93-c6ac-e89354ed86e4@webdrake.net> On 19/01/17 16:56, Joe Talbott wrote: > 'snapcraft build' only builds the part. You'd need to run 'snapcraft > stage' to get files into the stage directory and 'snapcraft prime' to > get files into the prime directory. 'snapcraft prime' will do a > 'snapcraft stage' as part of its lifecycle. :-\ I've been using `cleanbuild` so regularly for so long that I obviously forgot how the unclean commands worked ... :-P From pat.mcgowan at canonical.com Thu Jan 19 20:52:11 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Thu, 19 Jan 2017 15:52:11 -0500 Subject: Snapping webapps In-Reply-To: References: Message-ID: On Thu, Jan 19, 2017 at 10:20 AM, Fabio Colella wrote: > Hello, > I'm trying to snap a simple webapp for HexGL. > > Here's the code: https://github.com/fcole90/fcole-hexgl-webapp > > Unfortunately it's failing to start due to the following error: > > Qt: Session management error: None of the authentication protocols > specified are supported > QGtkStyle could not resolve GTK. Make sure you have installed the proper > libraries. > "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16. > 04.20160413/src/app/webcontainer/webapp-container.qml:-1 File not found\n" > > > You can try it with: snap install --beta fcole90-hexgl-webapp > > And run it with: fcole90-hexgl-webapp.hexgl-webapp > > Let me know if it happens for you too. > Installing from the store I had the same result, but building it locally it ran fine. I built on xenial with the overlay PPA needed by the platform snap: https://launchpad.net/~ci-train-ppa-service/+archive/ ubuntu/stable-phone-overlay Once I started the game I got a number of GL errors but it seemed to run fine. Chromium reports the same errors. Cheers Pat > > -- > Yours sincerely, > Fabio Colella > > > -- > 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 fcole90 at gmail.com Thu Jan 19 21:08:24 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Thu, 19 Jan 2017 22:08:24 +0100 Subject: Snapping webapps In-Reply-To: References: Message-ID: Nice, thank you. Unfortunately when I build it locally and I try to run it, it endlessly asks me to be connected to the ubuntu-app-platform even if I already connected it.. On 19 January 2017 at 21:52, Pat McGowan wrote: > > > On Thu, Jan 19, 2017 at 10:20 AM, Fabio Colella < > fabiocolella1990 at gmail.com> wrote: > >> Hello, >> I'm trying to snap a simple webapp for HexGL. >> >> Here's the code: https://github.com/fcole90/fcole-hexgl-webapp >> >> Unfortunately it's failing to start due to the following error: >> >> Qt: Session management error: None of the authentication protocols >> specified are supported >> QGtkStyle could not resolve GTK. Make sure you have installed the proper >> libraries. >> "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16. >> 04.20160413/src/app/webcontainer/webapp-container.qml:-1 File not >> found\n" >> >> >> You can try it with: snap install --beta fcole90-hexgl-webapp >> >> And run it with: fcole90-hexgl-webapp.hexgl-webapp >> >> Let me know if it happens for you too. >> > > Installing from the store I had the same result, but building it locally > it ran fine. I built on xenial with the overlay PPA needed by the platform > snap: > https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/ > stable-phone-overlay > > > Once > I started the game I got a number of GL errors but it seemed to run fine. > Chromium reports the same errors. > > Cheers > Pat > > >> >> -- >> Yours sincerely, >> Fabio Colella >> >> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pat.mcgowan at canonical.com Thu Jan 19 21:31:55 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Thu, 19 Jan 2017 16:31:55 -0500 Subject: Snapping webapps In-Reply-To: References: Message-ID: There was an issue where you need to uninstall the snap, reinstall it, connect it (before running it) then run and all is well. I believe it was fixed in a recent snapd. On Thu, Jan 19, 2017 at 4:08 PM, Fabio Colella wrote: > Nice, thank you. > > Unfortunately when I build it locally and I try to run it, it endlessly > asks me to be connected to the ubuntu-app-platform even if I already > connected it.. > > On 19 January 2017 at 21:52, Pat McGowan > wrote: > >> >> >> On Thu, Jan 19, 2017 at 10:20 AM, Fabio Colella < >> fabiocolella1990 at gmail.com> wrote: >> >>> Hello, >>> I'm trying to snap a simple webapp for HexGL. >>> >>> Here's the code: https://github.com/fcole90/fcole-hexgl-webapp >>> >>> Unfortunately it's failing to start due to the following error: >>> >>> Qt: Session management error: None of the authentication protocols >>> specified are supported >>> QGtkStyle could not resolve GTK. Make sure you have installed the proper >>> libraries. >>> "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16. >>> 04.20160413/src/app/webcontainer/webapp-container.qml:-1 File not >>> found\n" >>> >>> >>> You can try it with: snap install --beta fcole90-hexgl-webapp >>> >>> And run it with: fcole90-hexgl-webapp.hexgl-webapp >>> >>> Let me know if it happens for you too. >>> >> >> Installing from the store I had the same result, but building it locally >> it ran fine. I built on xenial with the overlay PPA needed by the platform >> snap: >> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/ >> stable-phone-overlay >> >> >> Once >> I started the game I got a number of GL errors but it seemed to run fine. >> Chromium reports the same errors. >> >> Cheers >> Pat >> >> >>> >>> -- >>> Yours sincerely, >>> Fabio Colella >>> >>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Thu Jan 19 21:42:39 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Thu, 19 Jan 2017 15:42:39 -0600 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: <29fd8106-adce-d980-7883-3fb0d68149be@canonical.com> Message-ID: <1484862159.4839.21.camel@canonical.com> On Thu, 2017-01-19 at 22:56 +0800, Tonny Tzeng wrote: > BTW, while trying different interfaces for getting permission for > /dev/rfkill, I accidentally set 'kernel-module-control' plug in my snap, > which triggers pending review of the snap, and blocking following pushes. > How could I withdraw or drop the pending snap and it's successors in the > Store? > What is the name of your snap? I'll reject it and then you can upload a new one. Feel free to respond off-list if you prefer. -- 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 oliver.ries at canonical.com Thu Jan 19 21:48:34 2017 From: oliver.ries at canonical.com (Oliver Ries) Date: Thu, 19 Jan 2017 14:48:34 -0700 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: On Thu, Jan 19, 2017 at 8:54 AM, Sergio Schvezov < sergio.schvezov at canonical.com> wrote: > On Thu, 19 Jan 2017 07:58:53 -0700, Oliver Ries wrote: > > On Thu, Jan 19, 2017 at 2:49 AM, Jamie Bennett < > jamie.bennett at canonical.com> > > wrote: > > > >> Hi Tonny, > >> > >> A quick grep of the snapd source code shows that /dev/rfkill is part of > >> the network-control and network-manager interfaces. > >> > > > > this method (grep the code) has been a repeated answer in the last few > > days, do we have any way of publishing this as part of our documentation? > > It was one of the feedback items from James last week: > > - all interfaces described. > - extended information on what the interface provides (apparmor rules and > seccomp) for easier debugging or figuring out what you need. These don't > need to be in your face what does this mean specifically? Olli -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hudson at canonical.com Fri Jan 20 00:03:27 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Fri, 20 Jan 2017 13:03:27 +1300 Subject: Please test my asciinema snap In-Reply-To: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: This confused me for a while: https://asciinema.org/a/2ua1d08k6v8jiyy1m2uyvn8rx (spoiler: python3 inside ' asciinema rec' is python3 from the core snap). Cheers, mwh On 18 January 2017 at 22:16, Mark Shuttleworth wrote: > Hi folks > > (For those of you who Gmail does not filter this email on > as-yet-unexplained-grounds :)) > > Please could you test my asciinema snap? Asciinema is a console video > recording utility that's great for CLI-diven demos. If you want to make > a quick web video of a CLI / console journey, asciinema is the ticket. > > An older version (0.9.8) is in 16.04. The new 1.3.0 version is now a > snap, and it should work on 16.04. I am also interested in feedback on > 14.04 for those of you on Trusty steeds who are blazing the > snaps-on-trusty trail. > > It's a 'classic-only' snap, so you need: > > sudo snap install --classic asciinema > > Then 'asciinema rec' starts a recording session, and you're off to the > races. > > Thanks! > > Mark > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Fri Jan 20 00:18:50 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 20 Jan 2017 01:18:50 +0100 Subject: Classic confinement success for LDC D compiler In-Reply-To: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: On 13/01/17 21:46, Joseph Rushton Wakeling wrote: > Hearing about classic confinement was rather exciting given that it seems > tailor-made for the use-cases of my current WiP snaps for the ldc2 D compiler > and the dub D build system: > https://github.com/WebDrake/ldc2.snap/pull/1 > https://github.com/WebDrake/dub.snap/pull/1 Just to follow up on this: after everyone's help in this thread, I was able to adjust the design of my package for the D compiler `ldc2`: https://github.com/WebDrake/ldc2.snap/pull/2 As far as I can tell, this fixes all the major issues with the original snap package. The `dub` package manager snap will follow some time soon now I've got the hang of things ;-) Thanks very much to everyone who offered advice and support. Best wishes, -- Joe From michael.hudson at canonical.com Fri Jan 20 00:20:16 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Fri, 20 Jan 2017 13:20:16 +1300 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: PYTHONHOME also leaks into the recording environment. On 20 January 2017 at 13:03, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > This confused me for a while: https://asciinema.org/ > a/2ua1d08k6v8jiyy1m2uyvn8rx (spoiler: python3 inside 'asciinema rec' is > python3 from the core snap). > > Cheers, > mwh > > On 18 January 2017 at 22:16, Mark Shuttleworth wrote: > >> Hi folks >> >> (For those of you who Gmail does not filter this email on >> as-yet-unexplained-grounds :)) >> >> Please could you test my asciinema snap? Asciinema is a console video >> recording utility that's great for CLI-diven demos. If you want to make >> a quick web video of a CLI / console journey, asciinema is the ticket. >> >> An older version (0.9.8) is in 16.04. The new 1.3.0 version is now a >> snap, and it should work on 16.04. I am also interested in feedback on >> 14.04 for those of you on Trusty steeds who are blazing the >> snaps-on-trusty trail. >> >> It's a 'classic-only' snap, so you need: >> >> sudo snap install --classic asciinema >> >> Then 'asciinema rec' starts a recording session, and you're off to the >> races. >> >> Thanks! >> >> Mark >> >> >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Fri Jan 20 00:45:31 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Fri, 20 Jan 2017 08:45:31 +0800 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: I think it would be good to let "snappy-debug" snap output what are the needed plugs. Sometimes, the utility does not give us hints. Is there any way to improve the app? It is even easier than looking for some info on the website. https://github.com/snapcore/snapd/wiki/Security Thanks & best regards, xiaoguo On Fri, Jan 20, 2017 at 5:48 AM, Oliver Ries wrote: > On Thu, Jan 19, 2017 at 8:54 AM, Sergio Schvezov < > sergio.schvezov at canonical.com> wrote: > >> On Thu, 19 Jan 2017 07:58:53 -0700, Oliver Ries wrote: >> > On Thu, Jan 19, 2017 at 2:49 AM, Jamie Bennett < >> jamie.bennett at canonical.com> >> > wrote: >> > >> >> Hi Tonny, >> >> >> >> A quick grep of the snapd source code shows that /dev/rfkill is part of >> >> the network-control and network-manager interfaces. >> >> >> > >> > this method (grep the code) has been a repeated answer in the last few >> > days, do we have any way of publishing this as part of our >> documentation? >> >> It was one of the feedback items from James last week: >> >> - all interfaces described. >> - extended information on what the interface provides (apparmor rules and >> seccomp) for easier debugging or figuring out what you need. These don't >> need to be in your face > > > what does this mean specifically? > Olli > > -- > 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 luke.williams at canonical.com Fri Jan 20 01:52:29 2017 From: luke.williams at canonical.com (Luke Williams) Date: Thu, 19 Jan 2017 17:52:29 -0800 Subject: Error using custom image In-Reply-To: <1484846299.4288.22.camel@ubuntu.com> References: <1484846299.4288.22.camel@ubuntu.com> Message-ID: <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> In the assertion file for the image, if it is amd64, is the model and gadget still pc or is it core now? Thanks, Luke Williams - Technical Partner Manager, Open Networking/Ubuntu-Core email: luke.williams at canonical.com http://www.canonical.com/ | http://www.ubuntu.com > On Jan 19, 2017, at 9:18 AM, Oliver Grawert wrote: > > hi, > Am Donnerstag, den 19.01.2017, 09:08 -0800 schrieb Luke Williams: >> That fixed it for the most part. Now we are getting dropped to a >> maintenance shell saying that our /lib/modules/ directory is empty. I >> feel this might have something to do with how we are building the >> kernel itself. > > so how do you build the kernel yourself ? > > note that you should use snapcraft and the kernel plugin to properly > create a snap of it, which will put the modules in the right places. > > this snap you then hand to ubuntu-image with the --extra-snaps option > when creating the signed image ... > > https://docs.ubuntu.com/core/en/guides/build-device/image-building > > describes this process in detail ... > > 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 mohammads_32 at yahoo.com Fri Jan 20 04:29:20 2017 From: mohammads_32 at yahoo.com (Mohammad Moradi) Date: Fri, 20 Jan 2017 04:29:20 +0000 (UTC) Subject: Ubuntu core on BBB In-Reply-To: <1481899592.4743.100.camel@ubuntu.com> References: <670779908.3917.1481847312693.ref@mail.yahoo.com> <670779908.3917.1481847312693@mail.yahoo.com> <1270692636.167626.1481876384156@mail.yahoo.com> <41B76818-DDF2-41C9-B1E4-51B536BF683E@canonical.com> <1481899592.4743.100.camel@ubuntu.com> Message-ID: <1306060865.195487.1484886560295@mail.yahoo.com> HiIt's good to hear that Ubuntu core supports BBB again. it's unfair to deprive such a great SBC.Thank you Ubuntu developers Mohammads Sent from Yahoo Mail on Android On Fri, Dec 16, 2016 at 18:17, Oliver Grawert wrote: hi, Am Freitag, den 16.12.2016, 13:17 +0000 schrieb Jamie Bennett: > > I have contacts in element14 that I can reach out to but would like > > to understand the context and status of the gadget snap published > > by mvo. > I think you should talk to element14 about having Ubuntu Core as an > official option or directly with Beagleboard themselves. Beagleboard > have a forum where you could start the conversation or contact > information on - https://beagleboard.org/about. ... and i'm happy to give them a hand if needed ...  ;) > > > I am also curious why ogra published his own gadget snap instead of > > using the "official looking" beagleblack snap (see screenshot). > > Thanks the "beagleblack" was a 15.04 gadget, the "bbb" gadget is for series 16, i wanted to make the difference clear in the naming (not only to point out the difference in releases but also the changed state of official support) it would be awesome to have an element14 image even with the robert nelson kernel, today i'm just re-using the linux-generic one from the archive in beaglebone setup, i know robert has some non-upstreamed patches that some users would like ... 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 andrew.wilkins at canonical.com Fri Jan 20 06:09:15 2017 From: andrew.wilkins at canonical.com (Andrew Wilkins) Date: Fri, 20 Jan 2017 06:09:15 +0000 Subject: ANN: snap for TLA+Toolbox Message-ID: Hi folks, I've recently been re-living my misspent university days learning about modelling complex systems and model-checking. In particular, I've been reading about TLA+ (Temporal Logic of Actions) [0], a language conceived by Leslie Lamport, and playing with the TLA+Toolbox. The TLA+Toolbox is an Eclipse-based IDE for defining specifications and checking models against them. I have snapped the TLA+Toolbox application; the snap is called "tlaplus". If you're interested in this area at all, I can recommend the TLA+ Hyperbook [1] (or what I've read of it so far, anyway). Please let me know of any problems you encounter using the snap. I know for one thing that the hyperlinks from the IDE do not work. Cheers, Andrew [0] https://research.microsoft.com/en-us/um/people/lamport/tla/tla.html [1] https://research.microsoft.com/en-us/um/people/lamport/tla/hyperbook.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiaoguo.liu at canonical.com Fri Jan 20 06:15:16 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Fri, 20 Jan 2017 14:15:16 +0800 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: Hi, For the desktop, can each of the app have its own icon? If yes, how can we define the icons for each of them? Thanks & best regards, XiaoGuo On Thu, Jan 19, 2017 at 10:47 AM, Sergio Schvezov wrote: > Hello snapcrafters! > > We are pleased to announce the release of version `2.25` of snapcraft has > been released: > https://launchpad.net/snapcraft/+milestone/2.25 > > This release is now available on xenial-updates, yakkety-updates and zesty. > What follows are the full release notes (the prettier version can be read > at https://github.com/snapcore/snapcraft/releases/tag/2.25) > > # New in this release > > ## Support for hooks > Hooks support has arrived. There are currently two ways to use them, > either with a by-convention path or by using a `part` and installing into > an expected path in the part's install directory. > > Find out more about this feature at https://github.com/snapcore/ > snapcraft/blob/master/docs/hooks.md > > ## Desktop file support > Aside from the by-convention functionality already in place, you can now > declare a desktop file from your app within an `apps` entry using a path > relative to the `prime` directory pointing to a desktop file, snapcraft > will take care of the rest. So if your project already has a desktop file, > say in `./prime/usr/share/applications/my-app.desktop` all you need to do > is something like this: > > ```yaml > apps: > my-app: > command: my-app > desktop: usr/share/applications/my-app.desktop > ``` > > That said, it is worth mentioning that the by-convention mechanism is > still supported. > > ## rust plugin > The `rust` plugin has seen an improvement and a couple of bug fixes. > > The added feature allow for one to set `rust-features` which is a list of > strings used to build optional dependencies (run `snapcraft help rust` for > a bit more details). > > The bug fixes relate to: > > - Allowing to build with `Cargo.toml` not in the base source directory. > - Repecting the other `rust` plugin properties: `rust-channel` and > `rust-revision`. > > ## nodejs plugin > The plugin now correctly downloads dependencies in `package.json` to the > correct location. > > ## godeps plugin > This plugin is now no longer affected by `GOBIN` being set in the > environment. > > ## deb sources > `deb` sources are now being handled with `python-debian` which does > incorrecly handle symlinks. > > ## More modes for daemon's in apps > You can now set the `daemon` property in an `apps` entry to `notify` (and > it will follow systemd's expected behavior for this service type). > > ## Deprecations > Some new deprecations have been introduced, for `parts` the `prime` > keyword is now favored over the `snap` one. When using the `snap` keyword a > link to http://snapcraft.io/docs/deprecation-notices/dn1 will be > presented with more information and the migration path. > > Plugins that are part of snapcraft that were displaying `DEPRECATED` > notices have all been updated to use the newer plugin API. > > ## Classic confinement > Some improvements were made to classic confinement with a more > comprehensive error when the prerequisites to build a classic confined snap > are not met. > > ## parts > Improvements were made to the core parts management of snapcraft: > > - `stage` entries now don't need to be replicated in `prime`. > - cleaning all parts works correctly even if `snapcraft.yaml` is broken. > > ## Others > For the full list of things available on 2.25 feel free to check > https://launchpad.net/snapcraft/+milestone/2.25 > > # 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: > > - Chris Holcombe > - Jonathon Love > - Kit Randel > - Marco Trevisan > - Matthew Aguirre > - Olivier Tilloy > > # Final Notes > To get the source for this release check it out at > https://github.com/snapcore/snapcraft/releases/tag/2.25 > > 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 > > -- > 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 alberto.mardegan at canonical.com Fri Jan 20 08:14:29 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Fri, 20 Jan 2017 11:14:29 +0300 Subject: Snapping webapps In-Reply-To: References: Message-ID: <74c53c86-308e-2935-1725-e34b8a0d8e47@canonical.com> On 19/01/2017 18:20, Fabio Colella wrote: > Hello, > I'm trying to snap a simple webapp for HexGL. > > Here's the code: https://github.com/fcole90/fcole-hexgl-webapp > > Unfortunately it's failing to start due to the following error: > > Qt: Session management error: None of the authentication protocols > specified are supported > QGtkStyle could not resolve GTK. Make sure you have installed the proper > libraries. > "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16.04.20160413/src/app/webcontainer/webapp-container.qml:-1 > File not found\n" Hi Fabio! As Pat already wrote, you should build it using xenial + stable-phone-overlay PPA. The reason for this is that the webapp-container in xenial is too old and doesn't support being run inside a snap. Also, in general, when using the ubuntu-app-platform snap (the webapp-helper part is using it) one should build the snap in xenial+overlay in order to make sure that he's using the same library versions as those provided by the ubuntu-app-platform snap. Ciao, Alberto From ogra at ubuntu.com Fri Jan 20 09:06:47 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 20 Jan 2017 10:06:47 +0100 Subject: Error using custom image In-Reply-To: <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> References: <1484846299.4288.22.camel@ubuntu.com> <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> Message-ID: <1484903207.4288.25.camel@ubuntu.com> hi, Am Donnerstag, den 19.01.2017, 17:52 -0800 schrieb Luke Williams: > In the assertion file for the image, if it is amd64, is the model and > gadget still pc or is it core now? > core is hardcoded in ubuntu-image to provide the rootfs, you usually do not need to specify it anywhere.  if you dont plan to modify the gadget, keep pc and let it also download from the store. the name of the assertion does not matter as long as you use the right filename in the ubuntu-image call. 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 olivier.tilloy at canonical.com Fri Jan 20 09:18:17 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Fri, 20 Jan 2017 10:18:17 +0100 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: On Fri, Jan 20, 2017 at 7:15 AM, XiaoGuo Liu wrote: > Hi, > > For the desktop, can each of the app have its own icon? If yes, how can we > define the icons for each of them? With the new 'desktop' keyword, you should be able to add a separate desktop file for each app, and if their 'Icon' key is an absolute path that points to an image file available in the prime directory, snapcraft will do the right thing and prepend ${SNAP} to it. I haven't actually tested with multiple apps in the same snap, feedback welcome! HTH, Olivier > On Thu, Jan 19, 2017 at 10:47 AM, Sergio Schvezov > wrote: >> >> Hello snapcrafters! >> >> We are pleased to announce the release of version `2.25` of snapcraft has >> been released: >> https://launchpad.net/snapcraft/+milestone/2.25 >> >> This release is now available on xenial-updates, yakkety-updates and >> zesty. >> What follows are the full release notes (the prettier version can be read >> at https://github.com/snapcore/snapcraft/releases/tag/2.25) >> >> # New in this release >> >> ## Support for hooks >> Hooks support has arrived. There are currently two ways to use them, >> either with a by-convention path or by using a `part` and installing into an >> expected path in the part's install directory. >> >> Find out more about this feature at >> https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md >> >> ## Desktop file support >> Aside from the by-convention functionality already in place, you can now >> declare a desktop file from your app within an `apps` entry using a path >> relative to the `prime` directory pointing to a desktop file, snapcraft will >> take care of the rest. So if your project already has a desktop file, say in >> `./prime/usr/share/applications/my-app.desktop` all you need to do is >> something like this: >> >> ```yaml >> apps: >> my-app: >> command: my-app >> desktop: usr/share/applications/my-app.desktop >> ``` >> >> That said, it is worth mentioning that the by-convention mechanism is >> still supported. >> >> ## rust plugin >> The `rust` plugin has seen an improvement and a couple of bug fixes. >> >> The added feature allow for one to set `rust-features` which is a list of >> strings used to build optional dependencies (run `snapcraft help rust` for a >> bit more details). >> >> The bug fixes relate to: >> >> - Allowing to build with `Cargo.toml` not in the base source directory. >> - Repecting the other `rust` plugin properties: `rust-channel` and >> `rust-revision`. >> >> ## nodejs plugin >> The plugin now correctly downloads dependencies in `package.json` to the >> correct location. >> >> ## godeps plugin >> This plugin is now no longer affected by `GOBIN` being set in the >> environment. >> >> ## deb sources >> `deb` sources are now being handled with `python-debian` which does >> incorrecly handle symlinks. >> >> ## More modes for daemon's in apps >> You can now set the `daemon` property in an `apps` entry to `notify` (and >> it will follow systemd's expected behavior for this service type). >> >> ## Deprecations >> Some new deprecations have been introduced, for `parts` the `prime` >> keyword is now favored over the `snap` one. When using the `snap` keyword a >> link to http://snapcraft.io/docs/deprecation-notices/dn1 will be presented >> with more information and the migration path. >> >> Plugins that are part of snapcraft that were displaying `DEPRECATED` >> notices have all been updated to use the newer plugin API. >> >> ## Classic confinement >> Some improvements were made to classic confinement with a more >> comprehensive error when the prerequisites to build a classic confined snap >> are not met. >> >> ## parts >> Improvements were made to the core parts management of snapcraft: >> >> - `stage` entries now don't need to be replicated in `prime`. >> - cleaning all parts works correctly even if `snapcraft.yaml` is broken. >> >> ## Others >> For the full list of things available on 2.25 feel free to check >> https://launchpad.net/snapcraft/+milestone/2.25 >> >> # 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: >> >> - Chris Holcombe >> - Jonathon Love >> - Kit Randel >> - Marco Trevisan >> - Matthew Aguirre >> - Olivier Tilloy >> >> # Final Notes >> To get the source for this release check it out at >> https://github.com/snapcore/snapcraft/releases/tag/2.25 >> >> 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 >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From snapcraft-announce-bounces at lists.snapcraft.io Fri Jan 20 08:13:06 2017 From: snapcraft-announce-bounces at lists.snapcraft.io (snapcraft-announce-bounces at lists.snapcraft.io) Date: Fri, 20 Jan 2017 08:13:06 +0000 Subject: Forward of moderated message Message-ID: An embedded message was scrubbed... From: XiaoGuo Liu Subject: Re: Snapcraft 2.25 has been released. Date: Fri, 20 Jan 2017 14:15:16 +0800 Size: 13875 URL: From fcole90 at gmail.com Fri Jan 20 12:03:22 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Fri, 20 Jan 2017 12:03:22 +0000 Subject: Snapping webapps In-Reply-To: <74c53c86-308e-2935-1725-e34b8a0d8e47@canonical.com> References: <74c53c86-308e-2935-1725-e34b8a0d8e47@canonical.com> Message-ID: Thank you. I built it using the Launchpad service, can I add the overlay ppa there? I will check to have the overlay ppa enabled on my local machine and to have the latest snapd installed. Cheers, Fabio On Fri, 20 Jan 2017, 09:15 Alberto Mardegan, wrote: > On 19/01/2017 18:20, Fabio Colella wrote: > > Hello, > > I'm trying to snap a simple webapp for HexGL. > > > > Here's the code: https://github.com/fcole90/fcole-hexgl-webapp > > > > Unfortunately it's failing to start due to the following error: > > > > Qt: Session management error: None of the authentication protocols > > specified are supported > > QGtkStyle could not resolve GTK. Make sure you have installed the proper > > libraries. > > > "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16.04.20160413/src/app/webcontainer/webapp-container.qml:-1 > > File not found\n" > > Hi Fabio! > As Pat already wrote, you should build it using xenial + > stable-phone-overlay PPA. The reason for this is that the > webapp-container in xenial is too old and doesn't support being run > inside a snap. > > Also, in general, when using the ubuntu-app-platform snap (the > webapp-helper part is using it) one should build the snap in > xenial+overlay in order to make sure that he's using the same library > versions as those provided by the ubuntu-app-platform snap. > > Ciao, > Alberto > > -- > 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 Jan 20 12:58:15 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 Jan 2017 04:58:15 -0800 Subject: Classic confinement success for LDC D compiler In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> Message-ID: <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> On 19/01/17 16:18, Joseph Rushton Wakeling wrote: > On 13/01/17 21:46, Joseph Rushton Wakeling wrote: >> Hearing about classic confinement was rather exciting given that it >> seems >> tailor-made for the use-cases of my current WiP snaps for the ldc2 D >> compiler >> and the dub D build system: >> https://github.com/WebDrake/ldc2.snap/pull/1 >> https://github.com/WebDrake/dub.snap/pull/1 > > Just to follow up on this: after everyone's help in this thread, I was > able to adjust the design of my package for the D compiler `ldc2`: > https://github.com/WebDrake/ldc2.snap/pull/2 > > As far as I can tell, this fixes all the major issues with the > original snap package. > > The `dub` package manager snap will follow some time soon now I've got > the hang of things ;-) > > Thanks very much to everyone who offered advice and support. Congrats! What's the best way to get the D community aware of this? Sounds like it would be a nice way for them to keep up to date. Mark From mark at ubuntu.com Fri Jan 20 12:59:16 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 Jan 2017 04:59:16 -0800 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: Any recommendations for dealing with those? On 19/01/17 16:20, Michael Hudson-Doyle wrote: > PYTHONHOME also leaks into the recording environment. > > On 20 January 2017 at 13:03, Michael Hudson-Doyle > > > wrote: > > This confused me for a > while: https://asciinema.org/a/2ua1d08k6v8jiyy1m2uyvn8rx > (spoiler: > python3 inside 'asciinema rec' is python3 from the core snap). > > Cheers, > mwh > > On 18 January 2017 at 22:16, Mark Shuttleworth > wrote: > > Hi folks > > (For those of you who Gmail does not filter this email on > as-yet-unexplained-grounds :)) > > Please could you test my asciinema snap? Asciinema is a > console video > recording utility that's great for CLI-diven demos. If you > want to make > a quick web video of a CLI / console journey, asciinema is the > ticket. > > An older version (0.9.8) is in 16.04. The new 1.3.0 version is > now a > snap, and it should work on 16.04. I am also interested in > feedback on > 14.04 for those of you on Trusty steeds who are blazing the > snaps-on-trusty trail. > > It's a 'classic-only' snap, so you need: > > sudo snap install --classic asciinema > > Then 'asciinema rec' starts a recording session, and you're > off to the > races. > > Thanks! > > Mark > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Fri Jan 20 13:59:34 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 20 Jan 2017 14:59:34 +0100 Subject: Ubuntu Core: how the file-system works Message-ID: Hi all, I am planning to build a raspberry-based gadget and I would rather use Ubuntu Core on it. So I am right now using it on a KVM in order to see how it works. First of all I need to understand how the file-system works. Because I need to edit some system files. My first question to the list is: why don't I see two partitions on the disk? I recall having read that Ubuntu Core was able to rollback to the previous version of "core" snap thanks to a second partition. Do I miss something? --Luca From jamie at canonical.com Fri Jan 20 14:03:04 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 20 Jan 2017 08:03:04 -0600 Subject: Which snap interface allows accessing /dev/rfkill? In-Reply-To: References: Message-ID: <1484920984.3222.16.camel@canonical.com> On Fri, 2017-01-20 at 08:45 +0800, XiaoGuo Liu wrote: > I think it would be good to let "snappy-debug" snap output what are the > needed plugs. Sometimes, the utility does  not give us hints. Is there any > way to improve the app? It is even easier than looking for some info on the > website. > > https://github.com/snapcore/snapd/wiki/Security > This page provides an overview about how the sandbox is setup and how one can work with it. The page with all the interfaces is linked in the table of contents at the right as 'Interfaces': https://github.com/snapcore/snapd/wiki/Interfaces This page has a description of all the interfaces, their attributes and how to use them. It does not have specific rules listed. The snappy-debug command is periodically updated for new interfaces (it is missing the new interfaces in 2.21 and I have a todo to fix that soon) and as mentioned, can be used to recommend interfaces. In general this command should work well for anything except dbus. Obviously, the lack of dbus is a glaring omission however at least it is usually easy to map a dbus denial to an interface name (eg, org.freedesktop.NetworkManager to network-manager). Please feel free to file bugs if it isn't doing what you expect. Updating snappy-debug for dbus, improving its cli and generally sprucing up the snap is planned but behind other prioritized work right now. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mark at ubuntu.com Fri Jan 20 14:06:40 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 Jan 2017 06:06:40 -0800 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: Message-ID: On 20/01/17 05:59, Luca Dionisi wrote: > First of all I need to understand how the file-system works. Because I > need to edit some system files. Ubuntu Core is designed to offer a super-reliable and predictable upgrade experience, so core system files are often fixed ("immutable"). It will be interesting to know what you need at the base level so we can expose it as a standard config element. > My first question to the list is: why don't I see two partitions on > the disk? I recall having read that Ubuntu Core was able to rollback to > the previous version of "core" snap thanks to a second partition. > Do I miss something? In 15.04 we had an A/B partition system. Now we have evolved to something much better, which is mountable compressed filesystems. The A/B filesystems are now single files on the base filesystem. That's better because it lets us use space much more efficiently, or decide later we want three or four versions instead of just A/B versions, etc. Mark From pat.mcgowan at canonical.com Fri Jan 20 14:10:31 2017 From: pat.mcgowan at canonical.com (Pat McGowan) Date: Fri, 20 Jan 2017 09:10:31 -0500 Subject: Snapping webapps In-Reply-To: References: <74c53c86-308e-2935-1725-e34b8a0d8e47@canonical.com> Message-ID: On Fri, Jan 20, 2017 at 7:03 AM, Fabio Colella wrote: > Thank you. I built it using the Launchpad service, can I add the overlay > ppa there? > Yes, when you Request Builds you can specify a PPA, or do so in the configuration for automatic builds. BTW I find Kyle's post quite useful as a referrence https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way Pat > I will check to have the overlay ppa enabled on my local machine and to > have the latest snapd installed. > > Cheers, > Fabio > > On Fri, 20 Jan 2017, 09:15 Alberto Mardegan, com> wrote: > >> On 19/01/2017 18:20, Fabio Colella wrote: >> > Hello, >> > I'm trying to snap a simple webapp for HexGL. >> > >> > Here's the code: https://github.com/fcole90/fcole-hexgl-webapp >> > >> > Unfortunately it's failing to start due to the following error: >> > >> > Qt: Session management error: None of the authentication protocols >> > specified are supported >> > QGtkStyle could not resolve GTK. Make sure you have installed the proper >> > libraries. >> > "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16. >> 04.20160413/src/app/webcontainer/webapp-container.qml:-1 >> > File not found\n" >> >> Hi Fabio! >> As Pat already wrote, you should build it using xenial + >> stable-phone-overlay PPA. The reason for this is that the >> webapp-container in xenial is too old and doesn't support being run >> inside a snap. >> >> Also, in general, when using the ubuntu-app-platform snap (the >> webapp-helper part is using it) one should build the snap in >> xenial+overlay in order to make sure that he's using the same library >> versions as those provided by the ubuntu-app-platform snap. >> >> Ciao, >> Alberto >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/ >> mailman/listinfo/snapcraft >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Fri Jan 20 14:14:14 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 20 Jan 2017 15:14:14 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: Message-ID: <1484921654.4288.33.camel@ubuntu.com> hi, Am Freitag, den 20.01.2017, 14:59 +0100 schrieb Luca Dionisi: > Hi all, > > I am planning to build a raspberry-based gadget and I would rather > use > Ubuntu Core on it. So I am right now using it on a KVM in order to > see > how it works. > > First of all I need to understand how the file-system works. Because > I > need to edit some system files. > > My first question to the list is: why don't I see two partitions on > the disk? I recall having read that Ubuntu Core was able to rollback > to > the previous version of "core" snap thanks to a second partition. > Do I miss something? > two readonly partitions were the 15.04 way when we still used image based upgrades (a technology that was developed for the phone images) with 16.04 snappy images switched to have everything as a snap this includes kernel, bootloader (gadget) and the rootfs (core). during boot the initrd mounts the readonly core snap (which is a squashfs) and bind-mounts a few required files into writable directories so they become writable (typically this are a bunch of selected cache and config files for system services).  rollback of kernel or core is done by switching back and forth between the different revisions of the snaps now, not by hopping between partitions any more, this way snappy can now use a single partition (the snaps just sit on the writeable partition) which reduces the complexity a lot. it also has the advantage that the core and kernel snaps are signed readonly squashfses and can not just be modified which adds a great amount of extra security. 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 luca.dionisi at gmail.com Fri Jan 20 14:33:33 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 20 Jan 2017 15:33:33 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: <1484921654.4288.33.camel@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> Message-ID: On Fri, Jan 20, 2017 at 3:06 PM, Mark Shuttleworth wrote: > On 20/01/17 05:59, Luca Dionisi wrote: >> First of all I need to understand how the file-system works. Because I >> need to edit some system files. > > Ubuntu Core is designed to offer a super-reliable and predictable > upgrade experience, so core system files are often fixed ("immutable"). > It will be interesting to know what you need at the base level so we can > expose it as a standard config element. Since my "thingy" is going to sport an experimental routing protocol, I need to change some files on the fly. For instance /etc/iproute/rt_tables. Which I already see that is not writeable in my Ubuntu Core install. Also I am going to use some commands that I haven't yet tested on Ubuntu Core. Mostly "ip" and "iptables", also in non-default network namespaces. And I don't know if they need internally write-access to some file. Do you see anything about it that would be infeasible in a Ubuntu Core as it currently stands? If not, what is my next step? Will I need to build a custom Ubuntu Core image? While testing, would I be able to remount the current image file system in read-write? --Luca From mark at ubuntu.com Fri Jan 20 14:36:40 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 Jan 2017 06:36:40 -0800 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> Message-ID: <53f08293-d6e2-fb1d-4c8c-19185f86f3a3@ubuntu.com> On 20/01/17 06:33, Luca Dionisi wrote: > Since my "thingy" is going to sport an experimental routing protocol, > I need > to change some files on the fly. For instance /etc/iproute/rt_tables. Which > I already see that is not writeable in my Ubuntu Core install. > > Also I am going to use some commands that I haven't yet tested on Ubuntu > Core. Mostly "ip" and "iptables", also in non-default network namespaces. > And I don't know if they need internally write-access to some file. > > Do you see anything about it that would be infeasible in a Ubuntu Core as > it currently stands? That all sounds like stuff we would want to be doable. There are a number of folks using Ubuntu Core for networking kit, so we are adding capabilities for that domain all the time. We just recently added network namespace control. Generally, you want to think about how best to express config in a way that easily survives upgrades. Editing something like rt_tables should be fine. But where you have something that multiple pieces want to edit, or a set of things which need to line up, we need to design a config item which drives those things consistently so the device can *never* end up in a broken state, by design. Make sense? Mark From gmgross at shoreham.net Fri Jan 20 14:43:37 2017 From: gmgross at shoreham.net (George Gross) Date: Fri, 20 Jan 2017 09:43:37 -0500 Subject: file system signatures and trust model, was Re: Ubuntu Core: how the file-system works In-Reply-To: <1484921654.4288.33.camel@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> Message-ID: <1484923417.9026.158.camel@civic> Hi, at the risk of wading into the weeds, you mentioned below that: "...it also has the advantage that the core and kernel snaps are signed readonly squashfses and can not just be modified which adds a great amount of extra security." Is there a Wiki or document explaining the signature private key's life cycle management? For example, what process happens when the key expires or is compromised? Who is the entity that actually *signs* the file system? If you built a custom kernel and/or device drivers, how would your binaries interact with this file system signature's verification? Can you substitute your own software factory/store's signature? If you operate your own private CA and sign some file objects within the snap, does that CA need to be cross-certified with the trust anchor CA that is vouching for the identity applying the core/kernel file system signature? tia, George On Fri, 2017-01-20 at 15:14 +0100, Oliver Grawert wrote: From ogra at ubuntu.com Fri Jan 20 14:54:05 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 20 Jan 2017 15:54:05 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> Message-ID: <1484924045.4288.46.camel@ubuntu.com> hi, Am Freitag, den 20.01.2017, 15:33 +0100 schrieb Luca Dionisi: >  > Since my "thingy" is going to sport an experimental routing protocol, > I need > to change some files on the fly. For instance /etc/iproute/rt_tables. > Which > I already see that is not writeable in my Ubuntu Core install. > > Also I am going to use some commands that I haven't yet tested on > Ubuntu > Core. Mostly "ip" and "iptables", also in non-default network > namespaces. > And I don't know if they need internally write-access to some file. > > Do you see anything about it that would be infeasible in a Ubuntu > Core as > it currently stands? > > If not, what is my next step? Will I need to build a custom Ubuntu > Core > image? While testing, would I be able to remount the current image > file > system in read-write? > you would not be able to mount the current rootfs in read-write, since it is a squashfs file.  for the above features you require ubuntu-core typically offers interfaces that a snap can use to control specific parts of the system [1]. i assume your goal is to have some app that can manage firewall, routing and other networking aspects.  my first step here would be to use the default ubuntu-core image and start working on a snap you can install on top of it that uses the existing interfaces. also take a look at the source of existing snaps for inspiration i.e. there is a "ufw" snap that does firewalling that should show how you can be able to manipulate iptables with thefirewall-control interface.  every time you hit a roadblock you file a bug and ask for extension of the interface or for a new interface to be added (and indeed we also accept patches if you already have an idea for a solution ;) ). eventually you will end up with the system you desire. snappy is a new approach so things you are used to from existing deb based systems might work in different ways (like: you wont make /etc/iproute/rt_tables writable but instead use the network- control interface to manipulate the routing table). ciao oli [1] http://snapcraft.io/docs/reference/interfaces -------------- 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 Jan 20 15:01:43 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 20 Jan 2017 16:01:43 +0100 Subject: file system signatures and trust model, was Re: Ubuntu Core: how the file-system works In-Reply-To: <1484923417.9026.158.camel@civic> References: <1484921654.4288.33.camel@ubuntu.com> <1484923417.9026.158.camel@civic> Message-ID: <1484924503.4288.53.camel@ubuntu.com> hi, Am Freitag, den 20.01.2017, 09:43 -0500 schrieb George Gross: > Hi, > > at the risk of wading into the weeds, you mentioned below that: > > "...it also has the advantage that the core and kernel snaps are > signed > readonly squashfses and can not just be modified which adds a great > amount of extra security." > > Is there a Wiki or document explaining the signature private key's > life > cycle management? For example, what process happens when the key > expires > or is compromised? Who is the entity that actually *signs* the file > system? this is probably something the security and store teams can answer better than me. > > If you built a custom kernel and/or device drivers, how would your > binaries interact with this file system signature's verification? Can > you substitute your own software factory/store's signature? you would create a complete own image based on your own developer signature using a signed model assertion. https://docs.ubuntu.com/core/en/guides/build-device/image-building has details on this. > > If you operate your own private CA and sign some file objects within > the > snap, does that CA need to be cross-certified with the trust anchor > CA > that is vouching for the identity applying the core/kernel file > system > signature? again something the store people are better suited to answer, i dont exactly know how the CA store side is set up here :) 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 luca.dionisi at gmail.com Fri Jan 20 16:03:23 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 20 Jan 2017 17:03:23 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: <1484924045.4288.46.camel@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> Message-ID: On Fri, Jan 20, 2017 at 3:36 PM, Mark Shuttleworth wrote: > On 20/01/17 06:33, Luca Dionisi wrote: >> Since my "thingy" is going to sport an experimental routing protocol, >> I need >> to change some files on the fly. For instance /etc/iproute/rt_tables. Which >> I already see that is not writeable in my Ubuntu Core install. >> >> Also I am going to use some commands that I haven't yet tested on Ubuntu >> Core. Mostly "ip" and "iptables", also in non-default network namespaces. >> And I don't know if they need internally write-access to some file. >> >> Do you see anything about it that would be infeasible in a Ubuntu Core as >> it currently stands? > > That all sounds like stuff we would want to be doable. There are a > number of folks using Ubuntu Core for networking kit, so we are adding > capabilities for that domain all the time. We just recently added > network namespace control. > > Generally, you want to think about how best to express config in a way > that easily survives upgrades. Editing something like rt_tables should > be fine. But where you have something that multiple pieces want to edit, > or a set of things which need to line up, we need to design a config > item which drives those things consistently so the device can *never* > end up in a broken state, by design. Make sense? It certainly makes sense. I think that, when in production, my snap will have confinement enabled so that the user will have to hook the right capabilities from the core snap. For now, I'd like to produce a unconfined snap for my tests. If I understand it correctly, an unconfined app will be able in the system to do whatever my standard user would be able to. For instance, if I log into my ubucore16 (the name of my KVM instance) and issue: sudo sysctl net.ipv4.ip_forward=1 -or- sudo ip address add 10.0.0.10 dev eth0 it reports success. Thus, if I run an unconfined app which tries to do the same it will succeed. Whilst a strictly confined app would not, if it is not hooked to a certain capability. So far, so good? As for particular config files, with the exception of rt_tables, my app currently doesn't need to save or edit files that other apps would read or modify. It doesn't need to save configurations that would have to survive upgrades, either. On Fri, Jan 20, 2017 at 3:54 PM, Oliver Grawert wrote: > my first step here would be to use the default ubuntu-core image and > start working on a snap you can install on top of it that uses the > existing interfaces. also take a look at the source of existing snaps > for inspiration i.e. there is a "ufw" snap that does firewalling that > should show how you can be able to manipulate iptables with > thefirewall-control interface. In my app I do network-control-related tasks by simply spawning standard linux commands. With g_spawn_async_with_pipes. I don't use other "interfaces" and I would prefer not to use any particular interface that ties my program to one platform. Or do I misunderstand what you mean by "the firewall-control interface?" > every time you hit a roadblock you file a bug and ask for extension of > the interface or for a new interface to be added (and indeed we also > accept patches if you already have an idea for a solution ;) ). > eventually you will end up with the system you desire. Glad to see positive approach. From olivier.tilloy at canonical.com Fri Jan 20 16:09:50 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Fri, 20 Jan 2017 17:09:50 +0100 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: On Thu, Jan 19, 2017 at 3:47 AM, Sergio Schvezov wrote: > Hello snapcrafters! > > We are pleased to announce the release of version `2.25` of snapcraft has been released: > https://launchpad.net/snapcraft/+milestone/2.25 > > This release is now available on xenial-updates, yakkety-updates and zesty. > What follows are the full release notes (the prettier version can be read at https://github.com/snapcore/snapcraft/releases/tag/2.25) > > # New in this release > > ## Support for hooks > Hooks support has arrived. There are currently two ways to use them, either with a by-convention path or by using a `part` and installing into an expected path in the part's install directory. > > Find out more about this feature at https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md > > ## Desktop file support > Aside from the by-convention functionality already in place, you can now declare a desktop file from your app within an `apps` entry using a path relative to the `prime` directory pointing to a desktop file, snapcraft will take care of the rest. I would not recommend starting to use that new feature because of https://launchpad.net/bugs/1658123. This will hopefully be usable in time for 2.26. > So if your project already has a desktop file, say in `./prime/usr/share/applications/my-app.desktop` all you need to do is something like this: > > ```yaml > apps: > my-app: > command: my-app > desktop: usr/share/applications/my-app.desktop > ``` > > That said, it is worth mentioning that the by-convention mechanism is still supported. > > ## rust plugin > The `rust` plugin has seen an improvement and a couple of bug fixes. > > The added feature allow for one to set `rust-features` which is a list of strings used to build optional dependencies (run `snapcraft help rust` for a bit more details). > > The bug fixes relate to: > > - Allowing to build with `Cargo.toml` not in the base source directory. > - Repecting the other `rust` plugin properties: `rust-channel` and `rust-revision`. > > ## nodejs plugin > The plugin now correctly downloads dependencies in `package.json` to the correct location. > > ## godeps plugin > This plugin is now no longer affected by `GOBIN` being set in the environment. > > ## deb sources > `deb` sources are now being handled with `python-debian` which does incorrecly handle symlinks. > > ## More modes for daemon's in apps > You can now set the `daemon` property in an `apps` entry to `notify` (and it will follow systemd's expected behavior for this service type). > > ## Deprecations > Some new deprecations have been introduced, for `parts` the `prime` keyword is now favored over the `snap` one. When using the `snap` keyword a link to http://snapcraft.io/docs/deprecation-notices/dn1 will be presented with more information and the migration path. > > Plugins that are part of snapcraft that were displaying `DEPRECATED` notices have all been updated to use the newer plugin API. > > ## Classic confinement > Some improvements were made to classic confinement with a more comprehensive error when the prerequisites to build a classic confined snap are not met. > > ## parts > Improvements were made to the core parts management of snapcraft: > > - `stage` entries now don't need to be replicated in `prime`. > - cleaning all parts works correctly even if `snapcraft.yaml` is broken. > > ## Others > For the full list of things available on 2.25 feel free to check https://launchpad.net/snapcraft/+milestone/2.25 > > # 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: > > - Chris Holcombe > - Jonathon Love > - Kit Randel > - Marco Trevisan > - Matthew Aguirre > - Olivier Tilloy > > # Final Notes > To get the source for this release check it out at > https://github.com/snapcore/snapcraft/releases/tag/2.25 > > 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 > > -- > 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 Fri Jan 20 16:18:23 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 20 Jan 2017 17:18:23 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> Message-ID: <1484929103.4288.59.camel@ubuntu.com> hi, Am Freitag, den 20.01.2017, 17:03 +0100 schrieb Luca Dionisi: >  > > my first step here would be to use the default ubuntu-core image > > and > > start working on a snap you can install on top of it that uses the > > existing interfaces. also take a look at the source of existing > > snaps > > for inspiration i.e. there is a "ufw" snap that does firewalling > > that > > should show how you can be able to manipulate iptables with > > thefirewall-control interface. > In my app I do network-control-related tasks by simply spawning > standard > linux commands. With g_spawn_async_with_pipes. > > I don't use other "interfaces" and I would prefer not to use any > particular interface that ties my program to one platform. Or do I > misunderstand what you mean by "the firewall-control interface?" the firewall interface gives you access to the kernel firewall features, your snap would ship the necessary user space tools for this and run them in the snap. the interface will be the same on all snap based systems (pretty much like ufw builds in iptables, ipset in the snap [1]) ciao oli [1] http://bazaar.launchpad.net/~jdstrand/ufw/trunk/view/head:/snapcraf t.yaml -------------- 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 mark at ubuntu.com Fri Jan 20 16:33:34 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 Jan 2017 08:33:34 -0800 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> Message-ID: <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> On 20/01/17 08:03, Luca Dionisi wrote: > If I understand it correctly, an unconfined app will be able in the > system > to do whatever my standard user would be able to. For instance, if I > log into my ubucore16 (the name of my KVM instance) and issue: > sudo sysctl net.ipv4.ip_forward=1 > -or- > sudo ip address add 10.0.0.10 dev eth0 > it reports success. Thus, if I run an unconfined app which tries to do the > same it will succeed. Whilst a strictly confined app would not, if it is > not hooked to a certain capability. > So far, so good? Ubuntu Core is confined-snaps-only. Ubuntu Classic allows less confined snaps. The commands you're wanting to run should be fine, though, with the right interfaces in place for your confined snap on Ubuntu Core. I think you meant that when you said 'hooked for a certain capability'. The devmode confinement should also be a useful workaround in your development process. Mark From gmgross at shoreham.net Fri Jan 20 17:10:30 2017 From: gmgross at shoreham.net (George Gross) Date: Fri, 20 Jan 2017 12:10:30 -0500 Subject: file system signatures and trust model, was Re: Ubuntu Core: how the file-system works In-Reply-To: <1484924503.4288.53.camel@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484923417.9026.158.camel@civic> <1484924503.4288.53.camel@ubuntu.com> Message-ID: <1484932230.9026.189.camel@civic> thank you for the "how to" pointer to make custom Ubuntu Core images, I'll stay tuned for replies on the other Qs... george On Fri, 2017-01-20 at 16:01 +0100, Oliver Grawert wrote: > hi, > Am Freitag, den 20.01.2017, 09:43 -0500 schrieb George Gross: > > Hi, > > > > at the risk of wading into the weeds, you mentioned below that: > > > > "...it also has the advantage that the core and kernel snaps are > > signed > > readonly squashfses and can not just be modified which adds a great > > amount of extra security." > > > > Is there a Wiki or document explaining the signature private key's > > life > > cycle management? For example, what process happens when the key > > expires > > or is compromised? Who is the entity that actually *signs* the file > > system? > > this is probably something the security and store teams can answer > better than me. > > > > > If you built a custom kernel and/or device drivers, how would your > > binaries interact with this file system signature's verification? Can > > you substitute your own software factory/store's signature? > > you would create a complete own image based on your own developer > signature using a signed model assertion. > > https://docs.ubuntu.com/core/en/guides/build-device/image-building > > has details on this. > > > > > If you operate your own private CA and sign some file objects within > > the > > snap, does that CA need to be cross-certified with the trust anchor > > CA > > that is vouching for the identity applying the core/kernel file > > system > > signature? > > again something the store people are better suited to answer, i dont > exactly know how the CA store side is set up here :) > > ciao > oli From luca.dionisi at gmail.com Fri Jan 20 17:15:17 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 20 Jan 2017 18:15:17 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> Message-ID: On Fri, Jan 20, 2017 at 5:33 PM, Mark Shuttleworth wrote: > On 20/01/17 08:03, Luca Dionisi wrote: >> If I understand it correctly, an unconfined app will be able in the >> system >> to do whatever my standard user would be able to. For instance, if I >> log into my ubucore16 (the name of my KVM instance) and issue: >> sudo sysctl net.ipv4.ip_forward=1 >> -or- >> sudo ip address add 10.0.0.10 dev eth0 >> it reports success. Thus, if I run an unconfined app which tries to do the >> same it will succeed. Whilst a strictly confined app would not, if it is >> not hooked to a certain capability. >> So far, so good? > > Ubuntu Core is confined-snaps-only. Ubuntu Classic allows less confined > snaps. > > The commands you're wanting to run should be fine, though, with the > right interfaces in place for your confined snap on Ubuntu Core. I think > you meant that when you said 'hooked for a certain capability'. The > devmode confinement should also be a useful workaround in your > development process. Ok. On Fri, Jan 20, 2017 at 5:18 PM, Oliver Grawert wrote: > the firewall interface gives you access to the kernel firewall > features, your snap would ship the necessary user space tools for this > and run them in the snap. the interface will be the same on all snap > based systems (pretty much like ufw builds in iptables, ipset in the > snap [1]) I think I got it. So I will continue to use g_spawn_async_with_pipes in my code. But I will prepare the snap file so that when installed on Ubuntu Core (or snap based system) it will work even in confined mode. Also, it will have the exact version of the userspace tools that I will choose to ship. ==== So, going back to my first issue. I would like to be able to create routing table names on Ubuntu Core. To my knowledge this should be done by writing to the rt_tables file, and it is currently impossible. Should I consider filing a bug? --Luca From ogra at ubuntu.com Fri Jan 20 17:43:05 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Fri, 20 Jan 2017 18:43:05 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> Message-ID: <1484934185.4288.65.camel@ubuntu.com> hi, Am Freitag, den 20.01.2017, 18:15 +0100 schrieb Luca Dionisi: >  > I think I got it. So I will continue to use g_spawn_async_with_pipes > in my code. But I will prepare the snap file so that when installed > on > Ubuntu Core (or snap based system) it will work even in confined > mode. > Also, it will have the exact version of the userspace tools that I > will > choose to ship. exactly, use g_spawn_async_with_pipes but allow it to accept env vars for the path of the executable it calls, that way you can create a snapcraft.yaml that pulls in iptables and your command will just do the right thing if $SNAP is set (i.e. iptables in your snap might live in $SNAP/usr/sbin/ while on a deb system it is just /usr/sbin, this also gives you full control over the iptables version in snappy)   > > ==== > > So, going back to my first issue. I would like to be able to create > routing table names on Ubuntu Core. To my knowledge this should be > done by writing to the rt_tables file, and it is currently > impossible. > Should I consider filing a bug? > yes, please start by filing it under the snappy umbrella [1] project and we'll add the necessary bug tasks for all bits and pieces involved then. ciao oli [1] https://bugs.launchpad.net/snappy/+filebug -------------- 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 luke.williams at canonical.com Fri Jan 20 18:24:35 2017 From: luke.williams at canonical.com (Luke Williams) Date: Fri, 20 Jan 2017 10:24:35 -0800 Subject: Error using custom image In-Reply-To: <1484903207.4288.25.camel@ubuntu.com> References: <1484846299.4288.22.camel@ubuntu.com> <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> <1484903207.4288.25.camel@ubuntu.com> Message-ID: Hi, So I now get a listing when I use 'snap list' of the installed snaps compared to in the past where it would ask to install a snap. However, my /lib/modules/ directory and /lib/firmware directory are empty, however, when I look in /snap/kernel/x1 the kernel.img, initrd.img, the .dep and .dep.bin and the modules and firmware directories are all there. I look in the syslog and dmesg and I don't see any errors other than systemd cannot find my dependency file in /lib/modules/4.8.0-RC5/modules.dep.bin. Any ideas on this error? On 01/20/2017 01:06 AM, Oliver Grawert wrote: > hi, > Am Donnerstag, den 19.01.2017, 17:52 -0800 schrieb Luke Williams: >> In the assertion file for the image, if it is amd64, is the model and >> gadget still pc or is it core now? >> > core is hardcoded in ubuntu-image to provide the rootfs, you usually do > not need to specify it anywhere. > > if you dont plan to modify the gadget, keep pc and let it also download > from the store. > the name of the assertion does not matter as long as you use the right > filename in the ubuntu-image call. > > ciao > oli > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.hodapp at canonical.com Fri Jan 20 18:32:05 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Fri, 20 Jan 2017 13:32:05 -0500 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: <1484755177.4288.19.camel@ubuntu.com> References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: Fantastic work! On Wed, Jan 18, 2017 at 10:59 AM, Oliver Grawert wrote: > hi, > > at [1] you can now find a daily image build for the Pi2 and Pi3 that > both have full GLES support and all 26 GPIOs exposed through > interfaces, some test feedback would be nice :) > > the GPIO numbering and pin mapping follows the community map at [2] and > looks like [3] in the "snap interfaces" output now. > > ciao > oli > > [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ > [2] http://pinout.xyz/# > [3] http://paste.ubuntu.com/23822613/ > -- > 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 manik at canonical.com Fri Jan 20 18:46:31 2017 From: manik at canonical.com (Manik Taneja) Date: Fri, 20 Jan 2017 13:46:31 -0500 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: <1484755177.4288.19.camel@ubuntu.com> References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: Fantastic work Ogra. Cheers, Manik On Wed, Jan 18, 2017 at 10:59 AM, Oliver Grawert wrote: > hi, > > at [1] you can now find a daily image build for the Pi2 and Pi3 that > both have full GLES support and all 26 GPIOs exposed through > interfaces, some test feedback would be nice :) > > the GPIO numbering and pin mapping follows the community map at [2] and > looks like [3] in the "snap interfaces" output now. > > ciao > oli > > [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ > [2] http://pinout.xyz/# > [3] http://paste.ubuntu.com/23822613/ > -- > 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 jian.luo.cn at gmail.com Fri Jan 20 20:46:54 2017 From: jian.luo.cn at gmail.com (Jian LUO) Date: Fri, 20 Jan 2017 21:46:54 +0100 Subject: GPG error during "sudo apt update" in "classic" snap Message-ID: Hi list, as the topic suggested I got GPG error in classic snap exactly like Bug #1577926 [1] described. strace leads me to this syscall error: [pid 2650] execve("/usr/bin/apt-key", ["/usr/bin/apt-key", "--quiet", "--readonly", "verify", "--status-fd", "3", "/tmp/apt.sig.usElcl", "/tmp/apt.data.BATaU7"], [/* 32 vars */]) = -1 EPERM (Operation not permitted) Since I use a custom kernel, I assume some config options and/or patches are missing. Can someone please give a hint on the necessary kernel configs for classic to work? Here is some info on my device. root at localhost:~# uname -a Linux localhost.localdomain 4.4.24-rt33-xm21-i40-debug+ #1 PREEMPT RT Tue Nov 22 16:10:15 CET 2016 i686 i686 i686 GNU/Linux root at localhost:~# snap --version snap 2.20 snapd 2.20 series 16 root at localhost:~# snap info classic name: classic summary: "Classic environment" publisher: canonical description: | Classic environment commands: - classic - classic.create - classic.reset tracking: beta installed: 16.04 (17) 4kB devmode refreshed: 2016-10-05 10:18:36 +0200 CEST channels: beta: 16.04 (17) 0B devmode edge: 16.04 (17) 0B devmode Thanks a lot. Jian [1] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1577926 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Fri Jan 20 21:15:40 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Fri, 20 Jan 2017 22:15:40 +0100 Subject: Classic confinement success for LDC D compiler In-Reply-To: <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> Message-ID: On 20/01/17 13:58, Mark Shuttleworth wrote: > Congrats! What's the best way to get the D community aware of this? > Sounds like it would be a nice way for them to keep up to date. Thanks Mark :-) I'm going to be in touch with the LDC devs directly in the next days (they know me, and they have known that I'm working on this for some time). I'm going to ask them to take a glance over things as they stand and to see whether we can make this an official package of the LDC project from the start. Once something is in the devel or edge channels of the snap store, and it seems to be working OK, I'm going to make a more public announcement to the D community (and I'll try to also blog about the experience). From joseph.wakeling at webdrake.net Fri Jan 20 23:14:44 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 21 Jan 2017 00:14:44 +0100 Subject: Snap install apparmor error: 'profile has merged rule with conflicting x modifiers' Message-ID: <95eeb685-0268-143e-97f9-381dc2303487@webdrake.net> Hello folks, With my LDC snap seemingly sorted, I'm now turning attention to my snap for the DUB build system: https://github.com/WebDrake/dub.snap/pull/1/files I've been able to get this to build as a classic snap with minimal tweaks (just switching `strict` => `classic` confinement and adding stage-packages: - libconfig9 - libphobos2-ldc68 ... to the `ldc` part. All builds fine, but when I try to install with sudo snap install --classic --dangerous dub_1.1.1_amd64.snap I get an error message: ----------------------- error: cannot perform the following tasks: - Setup snap "dub" (unset) security profiles (cannot setup apparmor for snap "dub": cannot load apparmor profile "snap.dub.dub": cannot load apparmor profile: exit status 1 apparmor_parser output: profile has merged rule with conflicting x modifiers ERROR processing regexs for profile snap.dub.dub, failed to load ) - Setup snap "dub" (unset) security profiles (cannot load apparmor profile "snap.dub.dub": cannot load apparmor profile: exit status 1 apparmor_parser output: profile has merged rule with conflicting x modifiers ERROR processing regexs for profile snap.dub.dub, failed to load ) ----------------------- Can anyone suggest what could be wrong here? The package builds and installs fine with `strict` confinement. Thanks & best wishes, -- Joe From seth.arnold at canonical.com Fri Jan 20 23:32:53 2017 From: seth.arnold at canonical.com (Seth Arnold) Date: Fri, 20 Jan 2017 15:32:53 -0800 Subject: Snap install apparmor error: 'profile has merged rule with conflicting x modifiers' In-Reply-To: <95eeb685-0268-143e-97f9-381dc2303487@webdrake.net> References: <95eeb685-0268-143e-97f9-381dc2303487@webdrake.net> Message-ID: <20170120233253.GF25550@hunt> On Sat, Jan 21, 2017 at 12:14:44AM +0100, Joseph Rushton Wakeling wrote: > - Setup snap "dub" (unset) security profiles (cannot setup apparmor for snap > "dub": cannot load apparmor profile "snap.dub.dub": cannot load apparmor > profile: exit status 1 > apparmor_parser output: > profile has merged rule with conflicting x modifiers > ERROR processing regexs for profile snap.dub.dub, failed to load > ) > Can anyone suggest what could be wrong here? The package builds and > installs fine with `strict` confinement. Hello, classic doesn't work well with plugs or slots: https://bugs.launchpad.net/snappy/+bug/1655369 Try removing those from your yaml and see if that lets you move forward. 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 Fri Jan 20 23:36:44 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sat, 21 Jan 2017 00:36:44 +0100 Subject: Snap install apparmor error: 'profile has merged rule with conflicting x modifiers' In-Reply-To: <95eeb685-0268-143e-97f9-381dc2303487@webdrake.net> References: <95eeb685-0268-143e-97f9-381dc2303487@webdrake.net> Message-ID: <8edbc2a6-ddf1-bf7f-5c63-942063c7c192@webdrake.net> On 21/01/17 00:14, Joseph Rushton Wakeling wrote: > All builds fine, but when I try to install with > > sudo snap install --classic --dangerous dub_1.1.1_amd64.snap > > I get an error message: Hmm, I should have dug a bit deeper before writing. Turns out if I remove `network` from the list of plugs, it installs just fine. Does this mean that classic snaps automatically have network access? In any case it looks like requesting it explicitly causes a problem in generating the appropriate apparmor profile. From fcole90 at gmail.com Sat Jan 21 08:04:55 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Sat, 21 Jan 2017 09:04:55 +0100 Subject: Snapping webapps In-Reply-To: References: <74c53c86-308e-2935-1725-e34b8a0d8e47@canonical.com> Message-ID: Thank you very much :) Now it works correctly so I released it to Stable channel! Next step will be to figure out why the desktop file does not appear in the launcher, but that's another story :) Cheers, Fabio On 20 January 2017 at 15:10, Pat McGowan wrote: > > > On Fri, Jan 20, 2017 at 7:03 AM, Fabio Colella wrote: > >> Thank you. I built it using the Launchpad service, can I add the overlay >> ppa there? >> > Yes, when you Request Builds you can specify a PPA, or do so in the > configuration for automatic builds. > > BTW I find Kyle's post quite useful as a referrence > https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way > > Pat > >> I will check to have the overlay ppa enabled on my local machine and to >> have the latest snapd installed. >> >> Cheers, >> Fabio >> >> On Fri, 20 Jan 2017, 09:15 Alberto Mardegan, < >> alberto.mardegan at canonical.com> wrote: >> >>> On 19/01/2017 18:20, Fabio Colella wrote: >>> > Hello, >>> > I'm trying to snap a simple webapp for HexGL. >>> > >>> > Here's the code: https://github.com/fcole90/fcole-hexgl-webapp >>> > >>> > Unfortunately it's failing to start due to the following error: >>> > >>> > Qt: Session management error: None of the authentication protocols >>> > specified are supported >>> > QGtkStyle could not resolve GTK. Make sure you have installed the >>> proper >>> > libraries. >>> > "file:///build/webbrowser-app-4Hx99o/webbrowser-app-0.23+16. >>> 04.20160413/src/app/webcontainer/webapp-container.qml:-1 >>> > File not found\n" >>> >>> Hi Fabio! >>> As Pat already wrote, you should build it using xenial + >>> stable-phone-overlay PPA. The reason for this is that the >>> webapp-container in xenial is too old and doesn't support being run >>> inside a snap. >>> >>> Also, in general, when using the ubuntu-app-platform snap (the >>> webapp-helper part is using it) one should build the snap in >>> xenial+overlay in order to make sure that he's using the same library >>> versions as those provided by the ubuntu-app-platform snap. >>> >>> Ciao, >>> Alberto >>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Sat Jan 21 10:33:44 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sat, 21 Jan 2017 11:33:44 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: <1484934185.4288.65.camel@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> Message-ID: On Fri, Jan 20, 2017 at 6:43 PM, Oliver Grawert wrote: > yes, please start by filing it under the snappy umbrella [1] project > and we'll add the necessary bug tasks for all bits and pieces involved > then. Done. While I wait for it to be fixed, is there a way to build a custom Ubuntu Core image where I can change by myself some bits of the rootfs? --Luca From l-snapcraft at znn.info Sat Jan 21 13:01:44 2017 From: l-snapcraft at znn.info (l-snapcraft at znn.info) Date: Sat, 21 Jan 2017 14:01:44 +0100 Subject: Best practise for gstreamer plugins? Message-ID: <5a5107e7-f7d7-ebcd-76b6-676e0ebeb8e1@znn.info> What is the best practise when working with gstreamer plugins? When packaging feedreader, an app with some video and music capabilities, i hit the problem that it calls gst-plugin-scanner which is not included in the package. So the application does not run. (feedreader:26336): GStreamer-WARNING **: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though. What is the "snap way" of solving this? When i include gstreamer in the snap it will cross the 100MB mark. Thanks From mark at ubuntu.com Sun Jan 22 12:18:33 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sun, 22 Jan 2017 04:18:33 -0800 Subject: Snap install apparmor error: 'profile has merged rule with conflicting x modifiers' In-Reply-To: <8edbc2a6-ddf1-bf7f-5c63-942063c7c192@webdrake.net> References: <95eeb685-0268-143e-97f9-381dc2303487@webdrake.net> <8edbc2a6-ddf1-bf7f-5c63-942063c7c192@webdrake.net> Message-ID: <981f7c78-f029-7695-71b7-1608c93a259a@ubuntu.com> On 20/01/17 15:36, Joseph Rushton Wakeling wrote: > Does this mean that classic snaps automatically have network access? > In any case it looks like requesting it explicitly causes a problem in > generating the appropriate apparmor profile. Yes, we're untangling the confinement logic at the moment, so for now drop plugs and slots from classic snaps. The intent, though, is that you can add them safely and test with --jailmode as part of your journey to strict confinement. --jailmode is the opposite of --devmode, it lets you impose the confinement with plugs and slots in cases (like --classic) where that confinement would not automatically be imposed. Mark From xiaoguo.liu at canonical.com Mon Jan 23 02:48:58 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 23 Jan 2017 10:48:58 +0800 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: Hi Olivier, Based on the snapcraft release 2.25, I have made an example at: https://github.com/liu-xiao-guo/helloworld-desktop So, far, I do not have any problems with it. Is there anything I am doing wrongly? I can see the launchers in the Ubuntu dash without any problems and the apps are launched well. By the way, I have created a blog for it at http://blog.csdn.net/ubuntutouch/article/details/54691673. It has the captured pictures. Thanks & best regards, XiaoGuo On Sat, Jan 21, 2017 at 12:09 AM, Olivier Tilloy < olivier.tilloy at canonical.com> wrote: > On Thu, Jan 19, 2017 at 3:47 AM, Sergio Schvezov > wrote: > > Hello snapcrafters! > > > > We are pleased to announce the release of version `2.25` of snapcraft > has been released: > > https://launchpad.net/snapcraft/+milestone/2.25 > > > > This release is now available on xenial-updates, yakkety-updates and > zesty. > > What follows are the full release notes (the prettier version can be > read at https://github.com/snapcore/snapcraft/releases/tag/2.25) > > > > # New in this release > > > > ## Support for hooks > > Hooks support has arrived. There are currently two ways to use them, > either with a by-convention path or by using a `part` and installing into > an expected path in the part's install directory. > > > > Find out more about this feature at https://github.com/snapcore/ > snapcraft/blob/master/docs/hooks.md > > > > ## Desktop file support > > Aside from the by-convention functionality already in place, you can now > declare a desktop file from your app within an `apps` entry using a path > relative to the `prime` directory pointing to a desktop file, snapcraft > will take care of the rest. > > I would not recommend starting to use that new feature because of > https://launchpad.net/bugs/1658123. This will hopefully be usable in > time for 2.26. > > > > So if your project already has a desktop file, say in `./prime/usr/share/applications/my-app.desktop` > all you need to do is something like this: > > > > ```yaml > > apps: > > my-app: > > command: my-app > > desktop: usr/share/applications/my-app.desktop > > ``` > > > > That said, it is worth mentioning that the by-convention mechanism is > still supported. > > > > ## rust plugin > > The `rust` plugin has seen an improvement and a couple of bug fixes. > > > > The added feature allow for one to set `rust-features` which is a list > of strings used to build optional dependencies (run `snapcraft help rust` > for a bit more details). > > > > The bug fixes relate to: > > > > - Allowing to build with `Cargo.toml` not in the base source directory. > > - Repecting the other `rust` plugin properties: `rust-channel` and > `rust-revision`. > > > > ## nodejs plugin > > The plugin now correctly downloads dependencies in `package.json` to the > correct location. > > > > ## godeps plugin > > This plugin is now no longer affected by `GOBIN` being set in the > environment. > > > > ## deb sources > > `deb` sources are now being handled with `python-debian` which does > incorrecly handle symlinks. > > > > ## More modes for daemon's in apps > > You can now set the `daemon` property in an `apps` entry to `notify` > (and it will follow systemd's expected behavior for this service type). > > > > ## Deprecations > > Some new deprecations have been introduced, for `parts` the `prime` > keyword is now favored over the `snap` one. When using the `snap` keyword a > link to http://snapcraft.io/docs/deprecation-notices/dn1 will be > presented with more information and the migration path. > > > > Plugins that are part of snapcraft that were displaying `DEPRECATED` > notices have all been updated to use the newer plugin API. > > > > ## Classic confinement > > Some improvements were made to classic confinement with a more > comprehensive error when the prerequisites to build a classic confined snap > are not met. > > > > ## parts > > Improvements were made to the core parts management of snapcraft: > > > > - `stage` entries now don't need to be replicated in `prime`. > > - cleaning all parts works correctly even if `snapcraft.yaml` is broken. > > > > ## Others > > For the full list of things available on 2.25 feel free to check > https://launchpad.net/snapcraft/+milestone/2.25 > > > > # 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: > > > > - Chris Holcombe > > - Jonathon Love > > - Kit Randel > > - Marco Trevisan > > - Matthew Aguirre > > - Olivier Tilloy > > > > # Final Notes > > To get the source for this release check it out at > > https://github.com/snapcore/snapcraft/releases/tag/2.25 > > > > 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 > > > > -- > > 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 > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.bishop at canonical.com Mon Jan 23 04:35:28 2017 From: stuart.bishop at canonical.com (Stuart Bishop) Date: Mon, 23 Jan 2017 11:35:28 +0700 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: On 20 January 2017 at 19:59, Mark Shuttleworth wrote: > > Any recommendations for dealing with those? > Do exec* and friends need to be patched somehow, so that if processes are spawned from a classic snap with targets outside snapd containment then the environment is cleaned? I think this will affect all classic snaps that need to run subprocesses, such as screen, vim, tmux... with other wrapper variables like the LD_* settings leaking :-( -- Stuart Bishop -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 10:37:28 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 08:37:28 -0200 Subject: create-user primitive In-Reply-To: References: Message-ID: It's okay that the command itself isn't super visible. The main reason it exists is to back console-conf, which is very visible and should be properly documented. On Wed, Jan 18, 2017 at 3:37 PM, Manik Taneja wrote: > > > On Wed, Jan 18, 2017 at 4:33 AM, Gustavo Niemeyer > wrote: > >> Don't see a reason to go beyond not listing it. The command works fine, >> including proper help and reasonable error messages. >> >> The reason it prevents creating users when one already exists is so we >> don't see scripts opening back doors by mistake. As Michael points out, >> this may be overriden with --force-managed. >> >> i would suggest that we document this somewhere. the only way i knew > about its existence was the fact that i had seen the primitive in an > earlier version of snapd. for others who are not familiar, this might not > even show up on their radar. > > /manik > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 11:09:04 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 09:09:04 -0200 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: I'm wondering if maybe we should simply drop all snapcraft wrappers for classic snaps, specifically. As it is, the amount of magic that is actually intended for strict snaps seems to be hurting the behavior and understanding of classic snaps. I doubt adding even more magic will help. On Mon, Jan 23, 2017 at 2:35 AM, Stuart Bishop wrote: > > > On 20 January 2017 at 19:59, Mark Shuttleworth wrote: > >> >> Any recommendations for dealing with those? >> > > Do exec* and friends need to be patched somehow, so that if processes are > spawned from a classic snap with targets outside snapd containment then the > environment is cleaned? > > I think this will affect all classic snaps that need to run subprocesses, > such as screen, vim, tmux... with other wrapper variables like the LD_* > settings leaking :-( > > > -- > Stuart Bishop > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 11:50:26 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 09:50:26 -0200 Subject: Best practise for gstreamer plugins? In-Reply-To: <5a5107e7-f7d7-ebcd-76b6-676e0ebeb8e1@znn.info> References: <5a5107e7-f7d7-ebcd-76b6-676e0ebeb8e1@znn.info> Message-ID: First thing I would do is include whatever you need inside the snap itself, and get things working quickly. Then, there are a few different ways you can move from there. The first one is actually to do nothing.. the whole snap infrastructure (snapcraft, snapd, uploads, downloads) is becoming delta-aware right now, which means even if the total size is 100MB, you'll generally be dealing with only a few megs. Another option, once you're unhappy with that, is using a content interface which allows sharing data across your snaps. This is a bit more complex, so I wouldn't bother unless there are benefits you're looking for, other than just size. On Sat, Jan 21, 2017 at 11:01 AM, wrote: > What is the best practise when working with gstreamer plugins? > > When packaging feedreader, an app with some video and music > capabilities, i hit the problem that it calls gst-plugin-scanner which > is not included in the package. So the application does not run. > > (feedreader:26336): GStreamer-WARNING **: External plugin loader > failed. This most likely means that the plugin loader helper binary was > not found or could not be run. You might need to set the > GST_PLUGIN_SCANNER environment variable if your setup is unusual. This > should normally not be required though. > > What is the "snap way" of solving this? When i include gstreamer in the > snap it will cross the 100MB mark. > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Mon Jan 23 11:57:43 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 09:57:43 -0200 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> Message-ID: Hi Luca, If you look under interfaces/builtin in the source code of snapd, you'll find some familliar names if you list *network* and *firewall* in there. I suspect that what you want is very easy to fix by simply introducing an additional apparmor entry in the right interface. If you want to test something locally sooner rather than later (say, today), then that would be best as it'd also tell us if the fix we'll commit into the tree will actually work for you. Otherwise, we can do that on our end and you just let us know if it worked for your case or if you need additional permissions which are lacking an interface for. On Sat, Jan 21, 2017 at 8:33 AM, Luca Dionisi wrote: > On Fri, Jan 20, 2017 at 6:43 PM, Oliver Grawert wrote: > > yes, please start by filing it under the snappy umbrella [1] project > > and we'll add the necessary bug tasks for all bits and pieces involved > > then. > > Done. > > While I wait for it to be fixed, is there a way to build a custom > Ubuntu Core image where I can change by myself some bits of the > rootfs? > > --Luca > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Mon Jan 23 12:17:57 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 23 Jan 2017 13:17:57 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> Message-ID: <1485173877.4288.70.camel@ubuntu.com> hi, Am Samstag, den 21.01.2017, 11:33 +0100 schrieb Luca Dionisi: > On Fri, Jan 20, 2017 at 6:43 PM, Oliver Grawert > wrote: > > > > yes, please start by filing it under the snappy umbrella [1] > > project > > and we'll add the necessary bug tasks for all bits and pieces > > involved > > then. > Done. > > While I wait for it to be fixed, is there a way to build a custom > Ubuntu Core image where I can change by myself some bits of the > rootfs? as mentioned in the bug ( http://pad.lv/1658298 ) the dir is now writable in the daily edge images (and in the respective core snap, on a stable image you can just "snap refresh --edge core" to get the updated version)...  we still need to discuss if route manipulation should have its own interface or be a part of the network-control interface though. ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Mon Jan 23 12:33:21 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 10:33:21 -0200 Subject: Ubuntu Core: how the file-system works In-Reply-To: <1485173877.4288.70.camel@ubuntu.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> Message-ID: Yes, it seems fine for network-control to allow it. On Mon, Jan 23, 2017 at 10:17 AM, Oliver Grawert wrote: > hi, > Am Samstag, den 21.01.2017, 11:33 +0100 schrieb Luca Dionisi: > > On Fri, Jan 20, 2017 at 6:43 PM, Oliver Grawert > > wrote: > > > > > > yes, please start by filing it under the snappy umbrella [1] > > > project > > > and we'll add the necessary bug tasks for all bits and pieces > > > involved > > > then. > > Done. > > > > While I wait for it to be fixed, is there a way to build a custom > > Ubuntu Core image where I can change by myself some bits of the > > rootfs? > > as mentioned in the bug ( http://pad.lv/1658298 ) the dir is now > writable in the daily edge images (and in the respective core snap, on > a stable image you can just "snap refresh --edge core" to get the > updated version)... > > we still need to discuss if route manipulation should have its own > interface or be a part of the network-control interface though. > > ciao > oli > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 12:44:41 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 10:44:41 -0200 Subject: GPG error during "sudo apt update" in "classic" snap In-Reply-To: References: Message-ID: This smells like an apparmor denial, which shouldn't happen inside the classic snap itself. Can you reproduce the issue when using the stock kernel? On Fri, Jan 20, 2017 at 6:46 PM, Jian LUO wrote: > Hi list, > > as the topic suggested I got GPG error in classic snap exactly like Bug > #1577926 [1] described. strace leads me to this syscall error: > [pid 2650] execve("/usr/bin/apt-key", ["/usr/bin/apt-key", "--quiet", > "--readonly", "verify", "--status-fd", "3", "/tmp/apt.sig.usElcl", > "/tmp/apt.data.BATaU7"], [/* 32 vars */]) = -1 EPERM (Operation not > permitted) > > Since I use a custom kernel, I assume some config options and/or patches > are missing. Can someone please give a hint on the necessary kernel configs > for classic to work? > > Here is some info on my device. > root at localhost:~# uname -a > Linux localhost.localdomain 4.4.24-rt33-xm21-i40-debug+ #1 PREEMPT RT Tue > Nov 22 16:10:15 CET 2016 i686 i686 i686 GNU/Linux > root at localhost:~# snap --version > snap 2.20 > snapd 2.20 > series 16 > root at localhost:~# snap info classic > name: classic > summary: "Classic environment" > publisher: canonical > description: | > Classic environment > commands: > - classic > - classic.create > - classic.reset > tracking: beta > installed: 16.04 (17) 4kB devmode > refreshed: 2016-10-05 10:18:36 +0200 CEST > channels: > beta: 16.04 (17) 0B devmode > edge: 16.04 (17) 0B devmode > > Thanks a lot. > > Jian > > [1] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1577926 > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 12:46:31 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 10:46:31 -0200 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: <1484755177.4288.19.camel@ubuntu.com> References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: Super nice indeed. Thanks, Oliver! Has anyone tried the new GL and gpios? How did it go? Perhaps we can ask for some extra millage on the pi community list itself? On Wed, Jan 18, 2017 at 1:59 PM, Oliver Grawert wrote: > hi, > > at [1] you can now find a daily image build for the Pi2 and Pi3 that > both have full GLES support and all 26 GPIOs exposed through > interfaces, some test feedback would be nice :) > > the GPIO numbering and pin mapping follows the community map at [2] and > looks like [3] in the "snap interfaces" output now. > > ciao > oli > > [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ > [2] http://pinout.xyz/# > [3] http://paste.ubuntu.com/23822613/ > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.lenton at canonical.com Mon Jan 23 13:06:29 2017 From: john.lenton at canonical.com (John Lenton) Date: Mon, 23 Jan 2017 13:06:29 +0000 Subject: Error using custom image In-Reply-To: References: <1484846299.4288.22.camel@ubuntu.com> <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> <1484903207.4288.25.camel@ubuntu.com> Message-ID: On 20 January 2017 at 18:24, Luke Williams wrote: > Any ideas on this error? what is your kernel snap called, and what is your /proc/cmdline? From fcole90 at gmail.com Mon Jan 23 13:27:16 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Mon, 23 Jan 2017 14:27:16 +0100 Subject: desktop file not appearing Message-ID: Hello, I snapped an app. It works but I'm not able to make the desktop launcher appear in the menu. Do you know if there's any problem in my code? https://github.com/fcole90/fcole-hexgl-webapp If you want to try it, you can install it by snap install fcole90-hexgl-webapp and run it by fcole90-hexgl-webapp.hexgl-webapp. Please, let me know if you find any issue. Cheers, Fabio -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.tilloy at canonical.com Mon Jan 23 13:50:34 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Mon, 23 Jan 2017 14:50:34 +0100 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: Hi XiaoGuo, Your example happens to work because no app in the snap is named like the snap itself. For such snaps, using the new desktop feature should be safe. Cheers, Olivier On Mon, Jan 23, 2017 at 3:48 AM, XiaoGuo Liu wrote: > Hi Olivier, > > Based on the snapcraft release 2.25, I have made an example at: > > https://github.com/liu-xiao-guo/helloworld-desktop > > So, far, I do not have any problems with it. Is there anything I am doing > wrongly? I can see the launchers in the Ubuntu dash without any problems and > the apps are launched well. > > By the way, I have created a blog for it at > http://blog.csdn.net/ubuntutouch/article/details/54691673. It has the > captured pictures. > > Thanks & best regards, > XiaoGuo > > On Sat, Jan 21, 2017 at 12:09 AM, Olivier Tilloy > wrote: >> >> On Thu, Jan 19, 2017 at 3:47 AM, Sergio Schvezov >> wrote: >> > Hello snapcrafters! >> > >> > We are pleased to announce the release of version `2.25` of snapcraft >> > has been released: >> > https://launchpad.net/snapcraft/+milestone/2.25 >> > >> > This release is now available on xenial-updates, yakkety-updates and >> > zesty. >> > What follows are the full release notes (the prettier version can be >> > read at https://github.com/snapcore/snapcraft/releases/tag/2.25) >> > >> > # New in this release >> > >> > ## Support for hooks >> > Hooks support has arrived. There are currently two ways to use them, >> > either with a by-convention path or by using a `part` and installing into an >> > expected path in the part's install directory. >> > >> > Find out more about this feature at >> > https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md >> > >> > ## Desktop file support >> > Aside from the by-convention functionality already in place, you can now >> > declare a desktop file from your app within an `apps` entry using a path >> > relative to the `prime` directory pointing to a desktop file, snapcraft will >> > take care of the rest. >> >> I would not recommend starting to use that new feature because of >> https://launchpad.net/bugs/1658123. This will hopefully be usable in >> time for 2.26. >> >> >> > So if your project already has a desktop file, say in >> > `./prime/usr/share/applications/my-app.desktop` all you need to do is >> > something like this: >> > >> > ```yaml >> > apps: >> > my-app: >> > command: my-app >> > desktop: usr/share/applications/my-app.desktop >> > ``` >> > >> > That said, it is worth mentioning that the by-convention mechanism is >> > still supported. >> > >> > ## rust plugin >> > The `rust` plugin has seen an improvement and a couple of bug fixes. >> > >> > The added feature allow for one to set `rust-features` which is a list >> > of strings used to build optional dependencies (run `snapcraft help rust` >> > for a bit more details). >> > >> > The bug fixes relate to: >> > >> > - Allowing to build with `Cargo.toml` not in the base source directory. >> > - Repecting the other `rust` plugin properties: `rust-channel` and >> > `rust-revision`. >> > >> > ## nodejs plugin >> > The plugin now correctly downloads dependencies in `package.json` to the >> > correct location. >> > >> > ## godeps plugin >> > This plugin is now no longer affected by `GOBIN` being set in the >> > environment. >> > >> > ## deb sources >> > `deb` sources are now being handled with `python-debian` which does >> > incorrecly handle symlinks. >> > >> > ## More modes for daemon's in apps >> > You can now set the `daemon` property in an `apps` entry to `notify` >> > (and it will follow systemd's expected behavior for this service type). >> > >> > ## Deprecations >> > Some new deprecations have been introduced, for `parts` the `prime` >> > keyword is now favored over the `snap` one. When using the `snap` keyword a >> > link to http://snapcraft.io/docs/deprecation-notices/dn1 will be presented >> > with more information and the migration path. >> > >> > Plugins that are part of snapcraft that were displaying `DEPRECATED` >> > notices have all been updated to use the newer plugin API. >> > >> > ## Classic confinement >> > Some improvements were made to classic confinement with a more >> > comprehensive error when the prerequisites to build a classic confined snap >> > are not met. >> > >> > ## parts >> > Improvements were made to the core parts management of snapcraft: >> > >> > - `stage` entries now don't need to be replicated in `prime`. >> > - cleaning all parts works correctly even if `snapcraft.yaml` is broken. >> > >> > ## Others >> > For the full list of things available on 2.25 feel free to check >> > https://launchpad.net/snapcraft/+milestone/2.25 >> > >> > # 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: >> > >> > - Chris Holcombe >> > - Jonathon Love >> > - Kit Randel >> > - Marco Trevisan >> > - Matthew Aguirre >> > - Olivier Tilloy >> > >> > # Final Notes >> > To get the source for this release check it out at >> > https://github.com/snapcore/snapcraft/releases/tag/2.25 >> > >> > 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 >> > >> > -- >> > 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 > > > > > -- > XiaoGuo, Liu > > -- > 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 Mon Jan 23 13:51:42 2017 From: jian.luo.cn at gmail.com (Jian LUO) Date: Mon, 23 Jan 2017 14:51:42 +0100 Subject: GPG error during "sudo apt update" in "classic" snap In-Reply-To: References: Message-ID: Hi Gustavo, Unfortunately the stock kernel refused to run on my target. Would it be useful if I upload my kernel configuration? I got same error message on another omap4460 target which runs ti-rt-linux-4.4.y[1]. My rpi 2 w/ official image however does not have this problem. I'll try kernel w/o real-time patch next time. Will let you guys know if it works. Or if someone can kindly show me where can I find a functional BBB kernel (ideally w/ snapcraft.yaml), I'll try it on the omap 4460 target. Thanks! Jian [1] git.ti.com/ti-linux-kernel On Jan 23, 2017 13:45, "Gustavo Niemeyer" wrote: This smells like an apparmor denial, which shouldn't happen inside the classic snap itself. Can you reproduce the issue when using the stock kernel? On Fri, Jan 20, 2017 at 6:46 PM, Jian LUO wrote: > Hi list, > > as the topic suggested I got GPG error in classic snap exactly like Bug > #1577926 [1] described. strace leads me to this syscall error: > [pid 2650] execve("/usr/bin/apt-key", ["/usr/bin/apt-key", "--quiet", > "--readonly", "verify", "--status-fd", "3", "/tmp/apt.sig.usElcl", > "/tmp/apt.data.BATaU7"], [/* 32 vars */]) = -1 EPERM (Operation not > permitted) > > Since I use a custom kernel, I assume some config options and/or patches > are missing. Can someone please give a hint on the necessary kernel configs > for classic to work? > > Here is some info on my device. > root at localhost:~# uname -a > Linux localhost.localdomain 4.4.24-rt33-xm21-i40-debug+ #1 PREEMPT RT Tue > Nov 22 16:10:15 CET 2016 i686 i686 i686 GNU/Linux > root at localhost:~# snap --version > snap 2.20 > snapd 2.20 > series 16 > root at localhost:~# snap info classic > name: classic > summary: "Classic environment" > publisher: canonical > description: | > Classic environment > commands: > - classic > - classic.create > - classic.reset > tracking: beta > installed: 16.04 (17) 4kB devmode > refreshed: 2016-10-05 10:18:36 +0200 CEST > channels: > beta: 16.04 (17) 0B devmode > edge: 16.04 (17) 0B devmode > > Thanks a lot. > > Jian > > [1] https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1577926 > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -- Snapcraft mailing 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 mhall119 at gmail.com Mon Jan 23 13:59:23 2017 From: mhall119 at gmail.com (Michael Hall) Date: Mon, 23 Jan 2017 08:59:23 -0500 Subject: desktop file not appearing In-Reply-To: References: Message-ID: Hi Fabio, Most likely the problem is in your .desktop file's Exec= line. This should point to the executable name in /snap/bin/ which, looking at your snapcraft.yaml, would be fcole90-hexgl-webapp.hexgl-webapp If you change it to: Exec=fcole90-hexgl-webapp.hexgl-webapp It should work. Michael Hall mhall119 at gmail.com On 01/23/2017 08:27 AM, Fabio Colella wrote: > Hello, > I snapped an app. It works but I'm not able to make the desktop launcher > appear in the menu. Do you know if there's any problem in my code? > > https://github.com/fcole90/fcole-hexgl-webapp > > If you want to try it, you can install it by snap install > fcole90-hexgl-webapp and run it by fcole90-hexgl-webapp.hexgl-webapp. > > Please, let me know if you find any issue. > > > Cheers, > Fabio > > From ogra at ubuntu.com Mon Jan 23 14:02:01 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 23 Jan 2017 15:02:01 +0100 Subject: GPG error during "sudo apt update" in "classic" snap In-Reply-To: References: Message-ID: <1485180121.4288.74.camel@ubuntu.com> hi, Am Montag, den 23.01.2017, 14:51 +0100 schrieb Jian LUO: >  > > I'll try kernel w/o real-time patch next time. Will let you guys know > if it works. Or if someone can kindly show me where can I find a > functional BBB kernel (ideally w/ snapcraft.yaml), I'll try it on the > omap 4460 target. > we have bbb images at [1] ... but they just use the generic kernel from the archive (it will also not help with OMAP since the BBB does not use an OMAP chip). afaik the kernel team (paolo specifically) has a set of required config options noted down somewhere, perhaps he can point you to it. ciao oli [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ -------------- 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 fcole90 at gmail.com Mon Jan 23 14:03:24 2017 From: fcole90 at gmail.com (Fabio Colella) Date: Mon, 23 Jan 2017 15:03:24 +0100 Subject: desktop file not appearing In-Reply-To: References: Message-ID: Thank you very much, that was the issue! Cheers, Fabio On 23 January 2017 at 14:59, Michael Hall wrote: > Hi Fabio, > > Most likely the problem is in your .desktop file's Exec= line. This > should point to the executable name in /snap/bin/ which, looking at your > snapcraft.yaml, would be fcole90-hexgl-webapp.hexgl-webapp > > If you change it to: > Exec=fcole90-hexgl-webapp.hexgl-webapp > > It should work. > > Michael Hall > mhall119 at gmail.com > > On 01/23/2017 08:27 AM, Fabio Colella wrote: > > Hello, > > I snapped an app. It works but I'm not able to make the desktop launcher > > appear in the menu. Do you know if there's any problem in my code? > > > > https://github.com/fcole90/fcole-hexgl-webapp > > > > If you want to try it, you can install it by snap install > > fcole90-hexgl-webapp and run it by fcole90-hexgl-webapp.hexgl-webapp. > > > > Please, let me know if you find any issue. > > > > > > Cheers, > > Fabio > > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Mon Jan 23 14:09:28 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 23 Jan 2017 15:09:28 +0100 Subject: Error using custom image In-Reply-To: References: <1484846299.4288.22.camel@ubuntu.com> <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> <1484903207.4288.25.camel@ubuntu.com> Message-ID: <1485180568.4288.78.camel@ubuntu.com> hi, Am Freitag, den 20.01.2017, 10:24 -0800 schrieb Luke Williams: > Hi, > So I now get a listing when I use 'snap list' of the installed snaps > compared to in the past where it would ask to install a snap. > However, my /lib/modules/ directory and /lib/firmware directory are > empty, however, when I look in /snap/kernel/x1 the kernel.img, > initrd.img, the .dep and .dep.bin and the modules and firmware > directories are all there. I look in the syslog and dmesg and I don't > see any errors other than systemd cannot find my dependency file in > /lib/modules/4.8.0-RC5/modules.dep.bin. > Any ideas on this error? as john said, it would be interesting to know whats in your /proc/cmdline (i suspect there might be a confusion between x1 and 4.8.0-RC5, the boot should use the latter for the snap_kernel= variable)...  also a link to the kernel snap would be interesting. did you check that the modules.dep.bin file exists inside the snap (theoretically the snapcraft kernel plugin should make sure it is created, but you never know ;) ) 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 xiaoguo.liu at canonical.com Mon Jan 23 14:21:24 2017 From: xiaoguo.liu at canonical.com (XiaoGuo Liu) Date: Mon, 23 Jan 2017 22:21:24 +0800 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: Hi Olivier, Sorry, I do not understand what exactly you mean "no app in the snap is named like the snap itself". Could you please elaborate it more? Thanks & best regards, XiaoGuo On Mon, Jan 23, 2017 at 9:50 PM, Olivier Tilloy < olivier.tilloy at canonical.com> wrote: > Hi XiaoGuo, > > Your example happens to work because no app in the snap is named like > the snap itself. For such snaps, using the new desktop feature should > be safe. > > Cheers, > > Olivier > > > On Mon, Jan 23, 2017 at 3:48 AM, XiaoGuo Liu > wrote: > > Hi Olivier, > > > > Based on the snapcraft release 2.25, I have made an example at: > > > > https://github.com/liu-xiao-guo/helloworld-desktop > > > > So, far, I do not have any problems with it. Is there anything I am doing > > wrongly? I can see the launchers in the Ubuntu dash without any problems > and > > the apps are launched well. > > > > By the way, I have created a blog for it at > > http://blog.csdn.net/ubuntutouch/article/details/54691673. It has the > > captured pictures. > > > > Thanks & best regards, > > XiaoGuo > > > > On Sat, Jan 21, 2017 at 12:09 AM, Olivier Tilloy > > wrote: > >> > >> On Thu, Jan 19, 2017 at 3:47 AM, Sergio Schvezov > >> wrote: > >> > Hello snapcrafters! > >> > > >> > We are pleased to announce the release of version `2.25` of snapcraft > >> > has been released: > >> > https://launchpad.net/snapcraft/+milestone/2.25 > >> > > >> > This release is now available on xenial-updates, yakkety-updates and > >> > zesty. > >> > What follows are the full release notes (the prettier version can be > >> > read at https://github.com/snapcore/snapcraft/releases/tag/2.25) > >> > > >> > # New in this release > >> > > >> > ## Support for hooks > >> > Hooks support has arrived. There are currently two ways to use them, > >> > either with a by-convention path or by using a `part` and installing > into an > >> > expected path in the part's install directory. > >> > > >> > Find out more about this feature at > >> > https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md > >> > > >> > ## Desktop file support > >> > Aside from the by-convention functionality already in place, you can > now > >> > declare a desktop file from your app within an `apps` entry using a > path > >> > relative to the `prime` directory pointing to a desktop file, > snapcraft will > >> > take care of the rest. > >> > >> I would not recommend starting to use that new feature because of > >> https://launchpad.net/bugs/1658123. This will hopefully be usable in > >> time for 2.26. > >> > >> > >> > So if your project already has a desktop file, say in > >> > `./prime/usr/share/applications/my-app.desktop` all you need to do is > >> > something like this: > >> > > >> > ```yaml > >> > apps: > >> > my-app: > >> > command: my-app > >> > desktop: usr/share/applications/my-app.desktop > >> > ``` > >> > > >> > That said, it is worth mentioning that the by-convention mechanism is > >> > still supported. > >> > > >> > ## rust plugin > >> > The `rust` plugin has seen an improvement and a couple of bug fixes. > >> > > >> > The added feature allow for one to set `rust-features` which is a list > >> > of strings used to build optional dependencies (run `snapcraft help > rust` > >> > for a bit more details). > >> > > >> > The bug fixes relate to: > >> > > >> > - Allowing to build with `Cargo.toml` not in the base source > directory. > >> > - Repecting the other `rust` plugin properties: `rust-channel` and > >> > `rust-revision`. > >> > > >> > ## nodejs plugin > >> > The plugin now correctly downloads dependencies in `package.json` to > the > >> > correct location. > >> > > >> > ## godeps plugin > >> > This plugin is now no longer affected by `GOBIN` being set in the > >> > environment. > >> > > >> > ## deb sources > >> > `deb` sources are now being handled with `python-debian` which does > >> > incorrecly handle symlinks. > >> > > >> > ## More modes for daemon's in apps > >> > You can now set the `daemon` property in an `apps` entry to `notify` > >> > (and it will follow systemd's expected behavior for this service > type). > >> > > >> > ## Deprecations > >> > Some new deprecations have been introduced, for `parts` the `prime` > >> > keyword is now favored over the `snap` one. When using the `snap` > keyword a > >> > link to http://snapcraft.io/docs/deprecation-notices/dn1 will be > presented > >> > with more information and the migration path. > >> > > >> > Plugins that are part of snapcraft that were displaying `DEPRECATED` > >> > notices have all been updated to use the newer plugin API. > >> > > >> > ## Classic confinement > >> > Some improvements were made to classic confinement with a more > >> > comprehensive error when the prerequisites to build a classic > confined snap > >> > are not met. > >> > > >> > ## parts > >> > Improvements were made to the core parts management of snapcraft: > >> > > >> > - `stage` entries now don't need to be replicated in `prime`. > >> > - cleaning all parts works correctly even if `snapcraft.yaml` is > broken. > >> > > >> > ## Others > >> > For the full list of things available on 2.25 feel free to check > >> > https://launchpad.net/snapcraft/+milestone/2.25 > >> > > >> > # 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: > >> > > >> > - Chris Holcombe > >> > - Jonathon Love > >> > - Kit Randel > >> > - Marco Trevisan > >> > - Matthew Aguirre > >> > - Olivier Tilloy > >> > > >> > # Final Notes > >> > To get the source for this release check it out at > >> > https://github.com/snapcore/snapcraft/releases/tag/2.25 > >> > > >> > 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 > >> > > >> > -- > >> > 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 > > > > > > > > > > -- > > XiaoGuo, Liu > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- XiaoGuo, Liu -------------- next part -------------- An HTML attachment was scrubbed... URL: From luke.williams at canonical.com Mon Jan 23 14:26:48 2017 From: luke.williams at canonical.com (Luke Williams) Date: Mon, 23 Jan 2017 14:26:48 +0000 Subject: Error using custom image In-Reply-To: <1485180568.4288.78.camel@ubuntu.com> References: <1484846299.4288.22.camel@ubuntu.com> <9E8CE406-D9A7-47CD-8449-A69C912860DF@canonical.com> <1484903207.4288.25.camel@ubuntu.com> <1485180568.4288.78.camel@ubuntu.com> Message-ID: I created a bug and uploaded my snapcraft.yaml to the bug as well as the kernel.snap. It is bug https://bugs.launchpad.net/ubuntu-image/+bug/1658177 The cmdline boots kernel.img from my snap using the x1 revision. (Fb-kernel-x1.snap) which is located in /bar/lib/snapd/snaps Let me know if you need any more information. Thanks, Luke On Mon, Jan 23, 2017 at 6:09 AM Oliver Grawert wrote: > hi, > > Am Freitag, den 20.01.2017, 10:24 -0800 schrieb Luke Williams: > > > Hi, > > > So I now get a listing when I use 'snap list' of the installed snaps > > > compared to in the past where it would ask to install a snap. > > > However, my /lib/modules/ directory and /lib/firmware directory are > > > empty, however, when I look in /snap/kernel/x1 the kernel.img, > > > initrd.img, the .dep and .dep.bin and the modules and firmware > > > directories are all there. I look in the syslog and dmesg and I don't > > > see any errors other than systemd cannot find my dependency file in > > > /lib/modules/4.8.0-RC5/modules.dep.bin. > > > Any ideas on this error? > > > > as john said, it would be interesting to know whats in your > > /proc/cmdline (i suspect there might be a confusion between x1 and > > 4.8.0-RC5, the boot should use the latter for the snap_kernel= > > variable)... > > > > also a link to the kernel snap would be interesting. did you check that > > the modules.dep.bin file exists inside the snap (theoretically the > > snapcraft kernel plugin should make sure it is created, but you never > > know ;) ) > > > > 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 mhall119 at ubuntu.com Mon Jan 23 14:54:10 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Mon, 23 Jan 2017 09:54:10 -0500 Subject: [NEWS] KDE Application snaps in stable channel Message-ID: With the release of Snapd 2.20 (and corresponding Snapcraft release) that introduced the new dbus interface, Harold Sitter from KDE was unblocked on the last thing keeping KDE applications from being cleanly snapped and published in the Snap Store. https://apachelog.wordpress.com/2017/01/20/snapping-dbus/ These KDE App snaps also take advantage of the content interface to share a common kde-frameworks-5 snap that contains the bulk of their platform dependencies. This keeps the individual application snap sizes down to 5mb or less. You can find the currently published apps with "snap find kde", and there are more that are in the process of being snapped and published. -- Michael Hall mhall119 at ubuntu.com From jamie.bennett at canonical.com Mon Jan 23 15:18:21 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Mon, 23 Jan 2017 15:18:21 +0000 Subject: [NEWS] KDE Application snaps in stable channel In-Reply-To: References: Message-ID: > On 23 Jan 2017, at 14:54, Michael Hall wrote: > > With the release of Snapd 2.20 (and corresponding Snapcraft release) > that introduced the new dbus interface, Harold Sitter from KDE was > unblocked on the last thing keeping KDE applications from being cleanly > snapped and published in the Snap Store. > > https://apachelog.wordpress.com/2017/01/20/snapping-dbus/ > > These KDE App snaps also take advantage of the content interface to > share a common kde-frameworks-5 snap that contains the bulk of their > platform dependencies. This keeps the individual application snap sizes > down to 5mb or less. The framework snap is 203.44mb but indeed, the other apps are pretty small. One caveat is that you must install the framework first before any KDE application and that there is no auto-installation of the framework if you do it in the wrong order. Installing the application first, then the framework results in an "error while loading shared libraries: libKF5Crash.so.5: cannot open shared object file: No such file or directory” error until you remove the app and reinstall. Still, it’s a great step forward with just a few kinks to iron out, great work and I’m looking forward to more KDE snaps! > You can find the currently published apps with "snap find kde", and > there are more that are in the process of being snapped and published. > > -- > Michael Hall > mhall119 at ubuntu.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From kristijan.zic at gmail.com Mon Jan 23 15:28:27 2017 From: kristijan.zic at gmail.com (=?UTF-8?Q?Kristijan_=C5=BDic?=) Date: Mon, 23 Jan 2017 15:28:27 +0000 Subject: [NEWS] KDE Application snaps in stable channel In-Reply-To: References: Message-ID: It should be giving an instruction to install framework snap and prevent snap installation like it does when ubuntu-app-platform snap is missing for the snaps that require it. On Mon, 23 Jan 2017, 3:54 p.m. Michael Hall, wrote: > With the release of Snapd 2.20 (and corresponding Snapcraft release) > that introduced the new dbus interface, Harold Sitter from KDE was > unblocked on the last thing keeping KDE applications from being cleanly > snapped and published in the Snap Store. > > https://apachelog.wordpress.com/2017/01/20/snapping-dbus/ > > These KDE App snaps also take advantage of the content interface to > share a common kde-frameworks-5 snap that contains the bulk of their > platform dependencies. This keeps the individual application snap sizes > down to 5mb or less. > > You can find the currently published apps with "snap find kde", and > there are more that are in the process of being snapped and published. > > -- > Michael Hall > mhall119 at ubuntu.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- Kristijan Žic -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Mon Jan 23 16:17:59 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Mon, 23 Jan 2017 17:17:59 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> Message-ID: Hi all I see that the issue has been taken care of. I will immediately download a daily-build image and check that the file rt_tables is writeable. I haven't built a snap for my app yet, so I cannot test for the moment if my needs are all already fitted in the builtin interfaces. I will try as soon as I can to craft a snap in devmode and afterwards in strict mode. But I can't predict time. Bear with me if I ask again, cause maybe the question went off the radar: is it possible to build an image where the rootfs has been modified a bit from what is in 'core' by default? --Luca From gustavo at niemeyer.net Mon Jan 23 16:26:27 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 14:26:27 -0200 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> Message-ID: It's definitely possible. It's just not very convenient yet. For tests, easiest might be to bind mount your modifications at runtime. On Mon, Jan 23, 2017 at 2:17 PM, Luca Dionisi wrote: > Hi all > > I see that the issue has been taken care of. I will immediately > download a daily-build image and check that the file rt_tables > is writeable. > > I haven't built a snap for my app yet, so I cannot test for the > moment if my needs are all already fitted in the builtin > interfaces. I will try as soon as I can to craft a snap in devmode > and afterwards in strict mode. But I can't predict time. > > Bear with me if I ask again, cause maybe the question went off the > radar: is it possible to build an image where the rootfs has been > modified a bit from what is in 'core' by default? > > --Luca > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 16:34:18 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 14:34:18 -0200 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: <1484757278.7772.47.camel@canonical.com> References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> <1484756134.7772.42.camel@canonical.com> <1484757278.7772.47.camel@canonical.com> Message-ID: Sounds good. If you think ubuntu-download-manager is the way to go, let's move on with it. On Wed, Jan 18, 2017 at 2:34 PM, Mike Sheldon wrote: > Ah, my mistake. I'd suspect UDM is less likely to change since it's > already a public facing API being used in third party apps. But it > sounds like we don't lose anything if we start it off as unity8- > download-manager whilst bundled with unity8 if we can then add an > additional interface once its distributed in its own snap (although I > guess that snap would have to advertise itself as providing both > interfaces to keep compatibility with existing snaps). > > I'm not sure if we gain much in this particular case though since we'd > need to be maintaining a stable API to work with existing apps > regardless? > > On Wed, 2017-01-18 at 14:24 -0200, Gustavo Niemeyer wrote: > > Sorry for not being clear. In addition to the suggestion about > > ubuntu-download-manager, I also wrote this: > > > > "Note that part of the rationale of having unity8-contacts and > > unity8-calendar named like that was that these interfaces are likely > > to change in meaningful and incompatible ways in the near future. If > > the download manager is going to be bundled with unity8, it may be > > wise to do the same. We can always introduce a more general interface > > later.. not so nice to get out of a general interface that doesn't > > work." > > > > What's your take on it? > > > > > > > > On Wed, Jan 18, 2017 at 2:15 PM, Mike Sheldon > cal.com> wrote: > > > Sorry, that was my entire point, I guess I should have expanded on > > > it a > > > bit. I agree with ubuntu-download-manager as a name, since that's > > > the > > > name developers will be interacting with if they're using our SDK. > > > For > > > example under QML they're importing Ubuntu.DownloadManager and the > > > C++ > > > namespace is Ubuntu::DownloadManager. So the interface being named > > > ubuntu-download-manager seems perfectly natural to me (in fact this > > > was > > > the initial name I proposed for it, before it was suggested that > > > download-manager might be a better name). > > > > > > On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > > > > The second part of the point was cut out. Can you please at least > > > let > > > > us know how you feel about it, so we can be in sync about the > > > right > > > > decision. > > > > > > > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" > > l.co > > > > m> wrote: > > > > ubuntu-download-manager makes sense as a name to me, especially > > > as > > > > it's > > > > one of the APIs in the Ubuntu SDK. > > > > > > > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > > > > > > > The real issue with download-manager is that it's too general. > > > We > > > > all > > > > > have several download managers in our systems, so this gives no > > > > hint > > > > > of what it's really talking about. > > > > > > > > > > We can call it ubuntu-download-manager if that's how the > > > software > > > > was > > > > > named. Note that part of the rationale of having unity8- > > > contacts > > > > and > > > > > unity8-calendar named like that was that these interfaces are > > > > likely > > > > > to change in meaningful and incompatible ways in the near > > > future. > > > > If > > > > > the download manager is going to be bundled with unity8, it may > > > be > > > > > wise to do the same. We can always introduce a more general > > > > interface > > > > > later.. not so nice to get out of a general interface that > > > doesn't > > > > > work. > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > > @can > > > > on > > > > > ical.com> wrote: > > > > > > Hi all, > > > > > > > > > > > > Currently the interface for UDM (Ubuntu Download Manager) > > > has > > > > been > > > > > > named unity8-download-manager. It's my understanding that > > > whilst > > > > we > > > > > > might initially be bundling UDM within the unity8 snap to > > > make > > > > the > > > > > > first stages of development easier (e.g. so it can talk > > > directly > > > > to > > > > > > unity8's transfer indicator), the long term plan would be for > > > it > > > > to > > > > > > be > > > > > > available separately. > > > > > > > > > > > > Having UDM permanently tied to unity8 would seem to add a > > > strong > > > > > > disincentive for app developers to make use of it at all, as > > > > their > > > > > > apps > > > > > > would then no-longer be portable across different desktop > > > > > > environments. > > > > > > > > > > > > As such, I'm wondering if the naming of this interface is > > > > perhaps > > > > > > misleading? > > > > > > > > > > > > Thanks, > > > > > > Mike > > > > > > > > > > > > -- > > > > > > Snapcraft mailing list > > > > > > Snapcraft at lists.snapcraft.io > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > > ailm > > > > an > > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > gustavo @ http://niemeyer.net > > > > > -- > > > > > Snapcraft mailing list > > > > > Snapcraft at lists.snapcraft.io > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mai > > > lman > > > > /l > > > > > istinfo/snapcraft > > > > > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > > an/l > > > > istinfo/snapcraft > > > > > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > > an/l > > > > istinfo/snapcraft > > > > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > > /listinfo/snapcraft > > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > > istinfo/snapcraft > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Mon Jan 23 16:41:20 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 14:41:20 -0200 Subject: systemd reload (ExevReload) support In-Reply-To: References: Message-ID: Nice change, Boris! Would you like to submit a PR for that? We have a CLA you can easily sign online assuming you're happy with the terms: https://www.ubuntu.com/legal/contributors On Tue, Jan 17, 2017 at 11:51 AM, Boris Rybalkin wrote: > Yes, I had to add support on our branch before we get official > Implementation: > > https://github.com/syncloud/snapd/blob/master/wrappers/services.go#L185 > > I have also created a bug: > > https://bugs.launchpad.net/snapd/+bug/1657116 > > On 17 Jan 2017 13:19, "Zygmunt Krynicki" > wrote: > >> Quick grep tells me that this is not currently supported. >> >> On Sat, Jan 14, 2017 at 4:55 PM, Boris Rybalkin >> wrote: >> > Hi, >> > >> > Could you tell me if there is systemd ExecReload support in snap.yaml? >> > >> > Thank you. >> > >> > -- >> > 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 >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Mon Jan 23 17:07:14 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Mon, 23 Jan 2017 18:07:14 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> Message-ID: On Mon, Jan 23, 2017 at 5:26 PM, Gustavo Niemeyer wrote: > It's definitely possible. It's just not very convenient yet. > > For tests, easiest might be to bind mount your modifications at runtime. Ok, thanks. bind mount. From michael.sheldon at canonical.com Mon Jan 23 17:19:20 2017 From: michael.sheldon at canonical.com (Mike Sheldon) Date: Mon, 23 Jan 2017 17:19:20 +0000 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> <1484756134.7772.42.camel@canonical.com> <1484757278.7772.47.camel@canonical.com> Message-ID: <1485191960.8553.4.camel@canonical.com> Okay great, should I prepare a new branch that does the renaming? On Mon, 2017-01-23 at 14:34 -0200, Gustavo Niemeyer wrote: > Sounds good. If you think ubuntu-download-manager is the way to go, > let's move on with it. > > On Wed, Jan 18, 2017 at 2:34 PM, Mike Sheldon cal.com> wrote: > > Ah, my mistake. I'd suspect UDM is less likely to change since it's > > already a public facing API being used in third party apps. But it > > sounds like we don't lose anything if we start it off as unity8- > > download-manager whilst bundled with unity8 if we can then add an > > additional interface once its distributed in its own snap (although > > I > > guess that snap would have to advertise itself as providing both > > interfaces to keep compatibility with existing snaps).  > > > > I'm not sure if we gain much in this particular case though since > > we'd > > need to be maintaining a stable API to work with existing apps > > regardless? > > > > On Wed, 2017-01-18 at 14:24 -0200, Gustavo Niemeyer wrote: > > > Sorry for not being clear. In addition to the suggestion about > > > ubuntu-download-manager, I also wrote this: > > > > > > "Note that part of the rationale of having unity8-contacts and > > > unity8-calendar named like that was that these interfaces are > > likely > > > to change in meaningful and incompatible ways in the near future. > > If > > > the download manager is going to be bundled with unity8, it may > > be > > > wise to do the same. We can always introduce a more general > > interface > > > later.. not so nice to get out of a general interface that > > doesn't > > > work." > > > > > > What's your take on it? > > > > > > > > > > > > On Wed, Jan 18, 2017 at 2:15 PM, Mike Sheldon > noni > > > cal.com> wrote: > > > > Sorry, that was my entire point, I guess I should have expanded > > on > > > > it a > > > > bit. I agree with ubuntu-download-manager as a name, since > > that's > > > > the > > > > name developers will be interacting with if they're using our > > SDK. > > > > For > > > > example under QML they're importing Ubuntu.DownloadManager and > > the > > > > C++ > > > > namespace is Ubuntu::DownloadManager. So the interface being > > named > > > > ubuntu-download-manager seems perfectly natural to me (in fact > > this > > > > was > > > > the initial name I proposed for it, before it was suggested > > that > > > > download-manager might be a better name). > > > > > > > > On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > > > > > The second part of the point was cut out. Can you please at > > least > > > > let > > > > > us know how you feel about it, so we can be in sync about the > > > > right > > > > > decision. > > > > > > > > > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" > nica > > > > l.co > > > > > m> wrote: > > > > > ubuntu-download-manager makes sense as a name to me, > > especially > > > > as > > > > > it's > > > > > one of the APIs in the Ubuntu SDK. > > > > > > > > > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > > > > > > > > > The real issue with download-manager is that it's too > > general. > > > > We > > > > > all > > > > > > have several download managers in our systems, so this > > gives no > > > > > hint > > > > > > of what it's really talking about. > > > > > > > > > > > > We can call it ubuntu-download-manager if that's how the > > > > software > > > > > was > > > > > > named. Note that part of the rationale of having unity8- > > > > contacts > > > > > and > > > > > > unity8-calendar named like that was that these interfaces > > are > > > > > likely > > > > > > to change in meaningful and incompatible ways in the near > > > > future. > > > > > If > > > > > > the download manager is going to be bundled with unity8, it > > may > > > > be > > > > > > wise to do the same. We can always introduce a more general > > > > > interface > > > > > > later.. not so nice to get out of a general interface that > > > > doesn't > > > > > > work. > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > > > > > @can > > > > > on > > > > > > ical.com> wrote: > > > > > > > Hi all, > > > > > > > > > > > > > >  Currently the interface for UDM (Ubuntu Download > > Manager) > > > > has > > > > > been > > > > > > > named unity8-download-manager. It's my understanding that > > > > whilst > > > > > we > > > > > > > might initially be bundling UDM within the unity8 snap to > > > > make > > > > > the > > > > > > > first stages of development easier (e.g. so it can talk > > > > directly > > > > > to > > > > > > > unity8's transfer indicator), the long term plan would be > > for > > > > it > > > > > to > > > > > > > be > > > > > > > available separately. > > > > > > > > > > > > > >  Having UDM permanently tied to unity8 would seem to add > > a > > > > strong > > > > > > > disincentive for app developers to make use of it at all, > > as > > > > > their > > > > > > > apps > > > > > > > would then no-longer be portable across different desktop > > > > > > > environments. > > > > > > > > > > > > > >  As such, I'm wondering if the naming of this interface > > is > > > > > perhaps > > > > > > > misleading? > > > > > > > > > > > > > > Thanks, > > > > > > >  Mike > > > > > > > > > > > > > > -- > > > > > > > Snapcraft mailing list > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.c > > om/m > > > > ailm > > > > > an > > > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > > > > > > > > > --  > > > > > > > > > > > > gustavo @ http://niemeyer.net > > > > > > --  > > > > > > Snapcraft mailing list > > > > > > Snapcraft at lists.snapcraft.io > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com > > /mai > > > > lman > > > > > /l > > > > > > istinfo/snapcraft > > > > > > > > > > -- > > > > > Snapcraft mailing list > > > > > Snapcraft at lists.snapcraft.io > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > ailm > > > > an/l > > > > > istinfo/snapcraft > > > > > > > > > > --  > > > > > Snapcraft mailing list > > > > > Snapcraft at lists.snapcraft.io > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > ailm > > > > an/l > > > > > istinfo/snapcraft > > > > > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mai > > lman > > > > /listinfo/snapcraft > > > > > > > > > > > > > --  > > > > > > gustavo @ http://niemeyer.net > > > --  > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > an/l > > > istinfo/snapcraft > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > --  > > gustavo @ http://niemeyer.net > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft From gustavo at niemeyer.net Mon Jan 23 17:23:06 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 15:23:06 -0200 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: <1485191960.8553.4.camel@canonical.com> References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> <1484756134.7772.42.camel@canonical.com> <1484757278.7772.47.camel@canonical.com> <1485191960.8553.4.camel@canonical.com> Message-ID: That'd be ideal, thanks! On Mon, Jan 23, 2017 at 3:19 PM, Mike Sheldon wrote: > Okay great, should I prepare a new branch that does the renaming? > > On Mon, 2017-01-23 at 14:34 -0200, Gustavo Niemeyer wrote: > > Sounds good. If you think ubuntu-download-manager is the way to go, > > let's move on with it. > > > > On Wed, Jan 18, 2017 at 2:34 PM, Mike Sheldon > cal.com> wrote: > > > Ah, my mistake. I'd suspect UDM is less likely to change since it's > > > already a public facing API being used in third party apps. But it > > > sounds like we don't lose anything if we start it off as unity8- > > > download-manager whilst bundled with unity8 if we can then add an > > > additional interface once its distributed in its own snap (although > > > I > > > guess that snap would have to advertise itself as providing both > > > interfaces to keep compatibility with existing snaps). > > > > > > I'm not sure if we gain much in this particular case though since > > > we'd > > > need to be maintaining a stable API to work with existing apps > > > regardless? > > > > > > On Wed, 2017-01-18 at 14:24 -0200, Gustavo Niemeyer wrote: > > > > Sorry for not being clear. In addition to the suggestion about > > > > ubuntu-download-manager, I also wrote this: > > > > > > > > "Note that part of the rationale of having unity8-contacts and > > > > unity8-calendar named like that was that these interfaces are > > > likely > > > > to change in meaningful and incompatible ways in the near future. > > > If > > > > the download manager is going to be bundled with unity8, it may > > > be > > > > wise to do the same. We can always introduce a more general > > > interface > > > > later.. not so nice to get out of a general interface that > > > doesn't > > > > work." > > > > > > > > What's your take on it? > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 2:15 PM, Mike Sheldon > > noni > > > > cal.com> wrote: > > > > > Sorry, that was my entire point, I guess I should have expanded > > > on > > > > > it a > > > > > bit. I agree with ubuntu-download-manager as a name, since > > > that's > > > > > the > > > > > name developers will be interacting with if they're using our > > > SDK. > > > > > For > > > > > example under QML they're importing Ubuntu.DownloadManager and > > > the > > > > > C++ > > > > > namespace is Ubuntu::DownloadManager. So the interface being > > > named > > > > > ubuntu-download-manager seems perfectly natural to me (in fact > > > this > > > > > was > > > > > the initial name I proposed for it, before it was suggested > > > that > > > > > download-manager might be a better name). > > > > > > > > > > On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > > > > > > The second part of the point was cut out. Can you please at > > > least > > > > > let > > > > > > us know how you feel about it, so we can be in sync about the > > > > > right > > > > > > decision. > > > > > > > > > > > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" > > nica > > > > > l.co > > > > > > m> wrote: > > > > > > ubuntu-download-manager makes sense as a name to me, > > > especially > > > > > as > > > > > > it's > > > > > > one of the APIs in the Ubuntu SDK. > > > > > > > > > > > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer wrote: > > > > > > > > > > > > > > The real issue with download-manager is that it's too > > > general. > > > > > We > > > > > > all > > > > > > > have several download managers in our systems, so this > > > gives no > > > > > > hint > > > > > > > of what it's really talking about. > > > > > > > > > > > > > > We can call it ubuntu-download-manager if that's how the > > > > > software > > > > > > was > > > > > > > named. Note that part of the rationale of having unity8- > > > > > contacts > > > > > > and > > > > > > > unity8-calendar named like that was that these interfaces > > > are > > > > > > likely > > > > > > > to change in meaningful and incompatible ways in the near > > > > > future. > > > > > > If > > > > > > > the download manager is going to be bundled with unity8, it > > > may > > > > > be > > > > > > > wise to do the same. We can always introduce a more general > > > > > > interface > > > > > > > later.. not so nice to get out of a general interface that > > > > > doesn't > > > > > > > work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > > > > > > > @can > > > > > > on > > > > > > > ical.com> wrote: > > > > > > > > Hi all, > > > > > > > > > > > > > > > > Currently the interface for UDM (Ubuntu Download > > > Manager) > > > > > has > > > > > > been > > > > > > > > named unity8-download-manager. It's my understanding that > > > > > whilst > > > > > > we > > > > > > > > might initially be bundling UDM within the unity8 snap to > > > > > make > > > > > > the > > > > > > > > first stages of development easier (e.g. so it can talk > > > > > directly > > > > > > to > > > > > > > > unity8's transfer indicator), the long term plan would be > > > for > > > > > it > > > > > > to > > > > > > > > be > > > > > > > > available separately. > > > > > > > > > > > > > > > > Having UDM permanently tied to unity8 would seem to add > > > a > > > > > strong > > > > > > > > disincentive for app developers to make use of it at all, > > > as > > > > > > their > > > > > > > > apps > > > > > > > > would then no-longer be portable across different desktop > > > > > > > > environments. > > > > > > > > > > > > > > > > As such, I'm wondering if the naming of this interface > > > is > > > > > > perhaps > > > > > > > > misleading? > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > > > > > > > > -- > > > > > > > > Snapcraft mailing list > > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.c > > > om/m > > > > > ailm > > > > > > an > > > > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > gustavo @ http://niemeyer.net > > > > > > > -- > > > > > > > Snapcraft mailing list > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com > > > /mai > > > > > lman > > > > > > /l > > > > > > > istinfo/snapcraft > > > > > > > > > > > > -- > > > > > > Snapcraft mailing list > > > > > > Snapcraft at lists.snapcraft.io > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > > ailm > > > > > an/l > > > > > > istinfo/snapcraft > > > > > > > > > > > > -- > > > > > > Snapcraft mailing list > > > > > > Snapcraft at lists.snapcraft.io > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > > ailm > > > > > an/l > > > > > > istinfo/snapcraft > > > > > > > > > > -- > > > > > Snapcraft mailing list > > > > > Snapcraft at lists.snapcraft.io > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mai > > > lman > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > -- > > > > > > > > gustavo @ http://niemeyer.net > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > > an/l > > > > istinfo/snapcraft > > > > > > -- > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > > /listinfo/snapcraft > > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > > istinfo/snapcraft > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Mon Jan 23 17:28:47 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 23 Jan 2017 11:28:47 -0600 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> Message-ID: <1485192527.3222.77.camel@canonical.com> On Mon, 2017-01-23 at 17:17 +0100, Luca Dionisi wrote: > Hi all > > I see that the issue has been taken care of. I will immediately > download a daily-build image and check that the file rt_tables > is writeable. > > I haven't built a snap for my app yet, so I cannot test for the > moment if my needs are all already fitted in the builtin > interfaces. I will try as soon as I can to craft a snap in devmode > and afterwards in strict mode. But I can't predict time. I will be looking at the security policy side of this so if you can, please comment in the bug what specific commands you are using in your snap for using rt_tables so I can repeat tham and make sure they are supported. [1]https://bugs.launchpad.net/snappy/+bug/1658298 -- 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 Mon Jan 23 18:48:36 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Mon, 23 Jan 2017 13:48:36 -0500 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: So I've been able to get it to work by creating /etc/systemd/system/snapd.service.d/proxy.conf with the correct settings. Any suggestions on getting that to persist across reboots? Thanks, Max On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > > On 13 January 2017 at 08:14, Max Brustkern > wrote: > >> So I created a system directory with the contents of /lib/systemd/system. >> I edited that file to contain the environment variables: >> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >> [Unit] >> Description=Snappy daemon >> Requires=snapd.socket >> >> [Service] >> ExecStart=/usr/lib/snapd/snapd >> EnvironmentFile=/etc/environment >> Restart=always >> http_proxy=http://squid.internal:3128 >> https_proxy=https://squid.internal:3128 >> > > That's not the right syntax, it should be > > Environment=http_proxy=http://squid.internal:3128 https_proxy= > https://squid.internal:3128 > > See man systemd.exec for more details on this. > > Cheers, > mwh > > >> [Install] >> WantedBy=multi-user.target >> >> I then did: >> nuclearbob at localhost:~$ sudo systemctl daemon-reload >> nuclearbob at localhost:~$ sudo service snapd restart >> >> I still don't seem to see snapd picking up on the proxy. I tried: >> sudo systemctl edit snapd >> I pasted in the file contents to there, but after that I get: >> nuclearbob at localhost:~$ sudo service snapd restart >> Failed to restart snapd.service: Unit snapd.service is not loaded >> properly: Invalid argument. >> See system logs and 'systemctl status snapd.service' for details. >> nuclearbob at localhost:~$ systemctl status snapd.service >> ● snapd.service - Snappy daemon >> Loaded: error (Reason: Invalid argument) >> Drop-In: /etc/systemd/system/snapd.service.d >> └─override.conf >> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min 26s >> ago >> Main PID: 1339 (snapd) >> CGroup: /system.slice/snapd.service >> └─1339 /usr/lib/snapd/snapd >> >> Any additional tips to get snapd running on ubuntu core in the lab? >> >> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >> stuart.bishop at canonical.com> wrote: >> >>> >>> >>> On 12 January 2017 at 01:44, Max Brustkern >>> wrote: >>> >>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal lab >>>> that requires a web proxy. This bug: >>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>> seems to cover how to do this on classic ubuntu, but the files that >>>> hold the environment variables used by snapd on an ubuntu core system are >>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>> for snapd on that system? >>>> >>> >>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >>> adding support for proxies to snapd (rather than have it use the system >>> environment variables, which is one implementation option but not always >>> what you want since that affects everything on the system). But that >>> doesn't help with your read-only filesystem sorry :-( >>> >>> (Hmm... disgusting hack idea.... since you can't create >>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, try >>> mounting that directory from somewhere. Extra points for using systemd to >>> mount the systemd service file overrides and setting up dependencies so it >>> does everything in the right order :-) ) >>> >>> >>> -- >>> Stuart Bishop >>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Mon Jan 23 19:04:20 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 17:04:20 -0200 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: This should work fine across reboots. On Jan 23, 2017 4:49 PM, "Max Brustkern" wrote: > So I've been able to get it to work by creating > /etc/systemd/system/snapd.service.d/proxy.conf > with the correct settings. Any suggestions on getting that to persist > across reboots? > > Thanks, > Max > > On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < > michael.hudson at canonical.com> wrote: > >> >> >> On 13 January 2017 at 08:14, Max Brustkern >> wrote: >> >>> So I created a system directory with the contents of >>> /lib/systemd/system. I edited that file to contain the environment >>> variables: >>> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >>> [Unit] >>> Description=Snappy daemon >>> Requires=snapd.socket >>> >>> [Service] >>> ExecStart=/usr/lib/snapd/snapd >>> EnvironmentFile=/etc/environment >>> Restart=always >>> http_proxy=http://squid.internal:3128 >>> https_proxy=https://squid.internal:3128 >>> >> >> That's not the right syntax, it should be >> >> Environment=http_proxy=http://squid.internal:3128 https_proxy= >> https://squid.internal:3128 >> >> See man systemd.exec for more details on this. >> >> Cheers, >> mwh >> >> >>> [Install] >>> WantedBy=multi-user.target >>> >>> I then did: >>> nuclearbob at localhost:~$ sudo systemctl daemon-reload >>> nuclearbob at localhost:~$ sudo service snapd restart >>> >>> I still don't seem to see snapd picking up on the proxy. I tried: >>> sudo systemctl edit snapd >>> I pasted in the file contents to there, but after that I get: >>> nuclearbob at localhost:~$ sudo service snapd restart >>> Failed to restart snapd.service: Unit snapd.service is not loaded >>> properly: Invalid argument. >>> See system logs and 'systemctl status snapd.service' for details. >>> nuclearbob at localhost:~$ systemctl status snapd.service >>> ● snapd.service - Snappy daemon >>> Loaded: error (Reason: Invalid argument) >>> Drop-In: /etc/systemd/system/snapd.service.d >>> └─override.conf >>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min 26s >>> ago >>> Main PID: 1339 (snapd) >>> CGroup: /system.slice/snapd.service >>> └─1339 /usr/lib/snapd/snapd >>> >>> Any additional tips to get snapd running on ubuntu core in the lab? >>> >>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>> stuart.bishop at canonical.com> wrote: >>> >>>> >>>> >>>> On 12 January 2017 at 01:44, Max Brustkern >>> > wrote: >>>> >>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal lab >>>>> that requires a web proxy. This bug: >>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>> hold the environment variables used by snapd on an ubuntu core system are >>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>>> for snapd on that system? >>>>> >>>> >>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >>>> adding support for proxies to snapd (rather than have it use the system >>>> environment variables, which is one implementation option but not always >>>> what you want since that affects everything on the system). But that >>>> doesn't help with your read-only filesystem sorry :-( >>>> >>>> (Hmm... disgusting hack idea.... since you can't create >>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, try >>>> mounting that directory from somewhere. Extra points for using systemd to >>>> mount the systemd service file overrides and setting up dependencies so it >>>> does everything in the right order :-) ) >>>> >>>> >>>> -- >>>> Stuart Bishop >>>> >>>> -- >>>> 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/mailm >>> an/listinfo/snapcraft >>> >>> >> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jian.luo.cn at gmail.com Mon Jan 23 19:04:39 2017 From: jian.luo.cn at gmail.com (Jian LUO) Date: Mon, 23 Jan 2017 20:04:39 +0100 Subject: GPG error during "sudo apt update" in "classic" snap In-Reply-To: <1485180121.4288.74.camel@ubuntu.com> References: <1485180121.4288.74.camel@ubuntu.com> Message-ID: Hi Oli, Thanks for the information. I think I'll just wait for the notes. Jian On Jan 23, 2017 15:02, "Oliver Grawert" wrote: hi, Am Montag, den 23.01.2017, 14:51 +0100 schrieb Jian LUO: > > > I'll try kernel w/o real-time patch next time. Will let you guys know > if it works. Or if someone can kindly show me where can I find a > functional BBB kernel (ideally w/ snapcraft.yaml), I'll try it on the > omap 4460 target. > we have bbb images at [1] ... but they just use the generic kernel from the archive (it will also not help with OMAP since the BBB does not use an OMAP chip). afaik the kernel team (paolo specifically) has a set of required config options noted down somewhere, perhaps he can point you to it. ciao oli [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ -- 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 max.brustkern at canonical.com Mon Jan 23 19:25:48 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Mon, 23 Jan 2017 14:25:48 -0500 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: Okay, you're right. I was testing with snap download, which doesn't seem to use to proxy, whereas snap refresh does. Is that intended behavior, or should I report it somewhere? Thanks, Max On Mon, Jan 23, 2017 at 2:04 PM, Gustavo Niemeyer < gustavo.niemeyer at canonical.com> wrote: > This should work fine across reboots. > > On Jan 23, 2017 4:49 PM, "Max Brustkern" > wrote: > >> So I've been able to get it to work by creating >> /etc/systemd/system/snapd.service.d/proxy.conf >> with the correct settings. Any suggestions on getting that to persist >> across reboots? >> >> Thanks, >> Max >> >> On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < >> michael.hudson at canonical.com> wrote: >> >>> >>> >>> On 13 January 2017 at 08:14, Max Brustkern >>> wrote: >>> >>>> So I created a system directory with the contents of >>>> /lib/systemd/system. I edited that file to contain the environment >>>> variables: >>>> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >>>> [Unit] >>>> Description=Snappy daemon >>>> Requires=snapd.socket >>>> >>>> [Service] >>>> ExecStart=/usr/lib/snapd/snapd >>>> EnvironmentFile=/etc/environment >>>> Restart=always >>>> http_proxy=http://squid.internal:3128 >>>> https_proxy=https://squid.internal:3128 >>>> >>> >>> That's not the right syntax, it should be >>> >>> Environment=http_proxy=http://squid.internal:3128 https_proxy= >>> https://squid.internal:3128 >>> >>> See man systemd.exec for more details on this. >>> >>> Cheers, >>> mwh >>> >>> >>>> [Install] >>>> WantedBy=multi-user.target >>>> >>>> I then did: >>>> nuclearbob at localhost:~$ sudo systemctl daemon-reload >>>> nuclearbob at localhost:~$ sudo service snapd restart >>>> >>>> I still don't seem to see snapd picking up on the proxy. I tried: >>>> sudo systemctl edit snapd >>>> I pasted in the file contents to there, but after that I get: >>>> nuclearbob at localhost:~$ sudo service snapd restart >>>> Failed to restart snapd.service: Unit snapd.service is not loaded >>>> properly: Invalid argument. >>>> See system logs and 'systemctl status snapd.service' for details. >>>> nuclearbob at localhost:~$ systemctl status snapd.service >>>> ● snapd.service - Snappy daemon >>>> Loaded: error (Reason: Invalid argument) >>>> Drop-In: /etc/systemd/system/snapd.service.d >>>> └─override.conf >>>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min 26s >>>> ago >>>> Main PID: 1339 (snapd) >>>> CGroup: /system.slice/snapd.service >>>> └─1339 /usr/lib/snapd/snapd >>>> >>>> Any additional tips to get snapd running on ubuntu core in the lab? >>>> >>>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>>> stuart.bishop at canonical.com> wrote: >>>> >>>>> >>>>> >>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>> max.brustkern at canonical.com> wrote: >>>>> >>>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal lab >>>>>> that requires a web proxy. This bug: >>>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>>> hold the environment variables used by snapd on an ubuntu core system are >>>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>>>> for snapd on that system? >>>>>> >>>>> >>>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >>>>> adding support for proxies to snapd (rather than have it use the system >>>>> environment variables, which is one implementation option but not always >>>>> what you want since that affects everything on the system). But that >>>>> doesn't help with your read-only filesystem sorry :-( >>>>> >>>>> (Hmm... disgusting hack idea.... since you can't create >>>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, >>>>> try mounting that directory from somewhere. Extra points for using systemd >>>>> to mount the systemd service file overrides and setting up dependencies so >>>>> it does everything in the right order :-) ) >>>>> >>>>> >>>>> -- >>>>> Stuart Bishop >>>>> >>>>> -- >>>>> 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/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Mon Jan 23 20:30:37 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Mon, 23 Jan 2017 21:30:37 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: <1485192527.3222.77.camel@canonical.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> <1485192527.3222.77.camel@canonical.com> Message-ID: On Mon, Jan 23, 2017 at 6:28 PM, Jamie Strandboge wrote: > I will be looking at the security policy side of this so if you can, please > comment in the bug what specific commands you are using in your snap for using > rt_tables so I can repeat tham and make sure they are supported. Done. From alejandro.cura at canonical.com Mon Jan 23 20:53:58 2017 From: alejandro.cura at canonical.com (Alejandro J. Cura) Date: Mon, 23 Jan 2017 17:53:58 -0300 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: Hey all, thanks for the hard work getting this image into shape. I've been trying to run on a Raspi3 the Mir-kiosk-apps demo from: https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ but I've not had much success. End of last week the demos would crash, and Mir would shut down after a few seconds. After refreshing the core today, I'm getting the very first frame, and when I try to move the mouse I see the cursor make a small jump (perhaps another frame?) and then it all hangs up. I can ssh into the raspi, and enable a different one of the demo apps with something like: $ snap set mir-kiosk-apps app="rssnews"; snap disable mir-kiosk-apps; snap disable mir-kiosk; snap enable mir-kiosk; snap enable mir-kiosk-apps But it still gets stuck on the first frame and only allows a small jump of the mouse before freezing. I've also tried the kodi demo snap mentioned here: https://plus.google.com/u/0/+OliverGrawert/posts/6S6U4MKG32y but that crashes with something like: alecu at localhost:~$ /snap/bin/kodi-mir-snapshot.kodi ERROR: Unable to create GUI. Exiting *** Error in `/snap/kodi-mir-snapshot/x1/lib/kodi/kodi.bin': free(): invalid pointer: 0x75d99844 *** /snap/kodi-mir-snapshot/x1/bin/runner_kodi: line 180: 2720 Aborted "$LIBDIR/${bin_name}/${bin_name}.bin" $SAVED_ARGS Crash report available at /home/alecu/snap/kodi-mir-snapshot/x1/kodi_crashlog-20170123_202923.log Any ideas on what I should try, or how to further debug this? I can upload the crash report if it helps. thanks! -- alecu On Mon, Jan 23, 2017 at 9:46 AM, Gustavo Niemeyer wrote: > > Super nice indeed. Thanks, Oliver! > > Has anyone tried the new GL and gpios? How did it go? > > Perhaps we can ask for some extra millage on the pi community list itself? > > On Wed, Jan 18, 2017 at 1:59 PM, Oliver Grawert wrote: >> >> hi, >> >> at [1] you can now find a daily image build for the Pi2 and Pi3 that >> both have full GLES support and all 26 GPIOs exposed through >> interfaces, some test feedback would be nice :) >> >> the GPIO numbering and pin mapping follows the community map at [2] and >> looks like [3] in the "snap interfaces" output now. >> >> ciao >> oli >> >> [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ >> [2] http://pinout.xyz/# >> [3] http://paste.ubuntu.com/23822613/ >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > > > > -- > > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Mon Jan 23 21:44:41 2017 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 23 Jan 2017 15:44:41 -0600 Subject: Yet more issues snapping In-Reply-To: <46eecfb7d8f858c82faed620d7994bcc@cliftonts.co.uk> References: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> <46eecfb7d8f858c82faed620d7994bcc@cliftonts.co.uk> Message-ID: On Wed, Jan 18, 2017 at 2:53 AM, wrote: > It is ok now thank you. I have had some excellent help and can use what I > now have to aid me going forward. It is those first few steps that seem > impossible. Hey Gareth, I'm happy to see you got it working. It would be really useful if you could help us improving the documentation from the things you learned these past weeks. Maybe some of the text should be clearer, or a few things are missing an explanation. We happily accept pull requests for the docs in https://github.com/snapcore/snapcraft/tree/master/docs, and another useful resource is to answer your own questions in askubuntu.com once you know the answer. pura vida. -- ¡paz y baile! http://www.ubuntu.com From max.brustkern at canonical.com Mon Jan 23 22:01:23 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Mon, 23 Jan 2017 17:01:23 -0500 Subject: Spread Tests with proxy (mostly go get) Message-ID: I'm trying to run spread tests on an ubuntu core VM in a lab that needs to use a proxy for web access. The mirrors are redirected, so the package installations work as expected, but I run into problems with go get: ++ classic 'GOPATH=/home/gopath go get ../../home/gopath/src/ github.com/snapcore/snapd/tests/lib/snapbuild' Cannot determine calling user, logging into classic as root mount: devpts is already mounted or /dev/pts busy devpts is already mounted on /dev/pts package gopkg.in/yaml.v2: unrecognized import path "gopkg.in/yaml.v2" (https fetch: Get https://gopkg.in/yaml.v2?go-get=1: dial tcp 45.33.69.124:443: i/o timeout) package gopkg.in/check.v1: unrecognized import path "gopkg.in/check.v1" (https fetch: Get https://gopkg.in/check.v1?go-get=1: dial tcp 45.33.69.124:443: i/o timeout) ++ sysctl -w net.ipv6.conf.all.disable_ipv6=0 net.ipv6.conf.all.disable_ipv6 = 0 ----- 2017/01/23 16:46:54 Restoring project on external:ubuntu-core-16-64... 2017/01/23 16:46:55 Successful tasks: 0 2017/01/23 16:46:55 Aborted tasks: 107 2017/01/23 16:46:55 Failed project prepare: 1 - external:ubuntu-core-16-64:project 2017/01/23 16:46:55 Keeping external:ubuntu-core-16-64 at 127.0.0.1:54323 error: unsuccessful run I'm using the following spread commands to run on the local VM: export SPREAD_EXTERNAL_ADDRESS=127.0.0.1:$PORT ./tests/lib/external/prepare-ssh.sh 127.0.0.1 $PORT $USER spread -v -reuse external:ubuntu-core-16-64 | tee $WORKSPACE/spread-output How should I configure spread to make go aware of the proxy? Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 22:04:17 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 20:04:17 -0200 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: Indeed, that smells like a bug, certainly because snap download doesn't use the local snaps to actually download the file. That should be transparent to the CLI though. Can you please file an issue? Thanks! On Jan 23, 2017 5:26 PM, "Max Brustkern" wrote: > Okay, you're right. I was testing with snap download, which doesn't seem > to use to proxy, whereas snap refresh does. Is that intended behavior, or > should I report it somewhere? > > Thanks, > Max > > On Mon, Jan 23, 2017 at 2:04 PM, Gustavo Niemeyer < > gustavo.niemeyer at canonical.com> wrote: > >> This should work fine across reboots. >> >> On Jan 23, 2017 4:49 PM, "Max Brustkern" >> wrote: >> >>> So I've been able to get it to work by creating >>> /etc/systemd/system/snapd.service.d/proxy.conf >>> with the correct settings. Any suggestions on getting that to persist >>> across reboots? >>> >>> Thanks, >>> Max >>> >>> On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < >>> michael.hudson at canonical.com> wrote: >>> >>>> >>>> >>>> On 13 January 2017 at 08:14, Max Brustkern >>> > wrote: >>>> >>>>> So I created a system directory with the contents of >>>>> /lib/systemd/system. I edited that file to contain the environment >>>>> variables: >>>>> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >>>>> [Unit] >>>>> Description=Snappy daemon >>>>> Requires=snapd.socket >>>>> >>>>> [Service] >>>>> ExecStart=/usr/lib/snapd/snapd >>>>> EnvironmentFile=/etc/environment >>>>> Restart=always >>>>> http_proxy=http://squid.internal:3128 >>>>> https_proxy=https://squid.internal:3128 >>>>> >>>> >>>> That's not the right syntax, it should be >>>> >>>> Environment=http_proxy=http://squid.internal:3128 https_proxy= >>>> https://squid.internal:3128 >>>> >>>> See man systemd.exec for more details on this. >>>> >>>> Cheers, >>>> mwh >>>> >>>> >>>>> [Install] >>>>> WantedBy=multi-user.target >>>>> >>>>> I then did: >>>>> nuclearbob at localhost:~$ sudo systemctl daemon-reload >>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>> >>>>> I still don't seem to see snapd picking up on the proxy. I tried: >>>>> sudo systemctl edit snapd >>>>> I pasted in the file contents to there, but after that I get: >>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>> Failed to restart snapd.service: Unit snapd.service is not loaded >>>>> properly: Invalid argument. >>>>> See system logs and 'systemctl status snapd.service' for details. >>>>> nuclearbob at localhost:~$ systemctl status snapd.service >>>>> ● snapd.service - Snappy daemon >>>>> Loaded: error (Reason: Invalid argument) >>>>> Drop-In: /etc/systemd/system/snapd.service.d >>>>> └─override.conf >>>>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min >>>>> 26s ago >>>>> Main PID: 1339 (snapd) >>>>> CGroup: /system.slice/snapd.service >>>>> └─1339 /usr/lib/snapd/snapd >>>>> >>>>> Any additional tips to get snapd running on ubuntu core in the lab? >>>>> >>>>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>>>> stuart.bishop at canonical.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>>> max.brustkern at canonical.com> wrote: >>>>>> >>>>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal >>>>>>> lab that requires a web proxy. This bug: >>>>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>>>> hold the environment variables used by snapd on an ubuntu core system are >>>>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>>>>> for snapd on that system? >>>>>>> >>>>>> >>>>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >>>>>> adding support for proxies to snapd (rather than have it use the system >>>>>> environment variables, which is one implementation option but not always >>>>>> what you want since that affects everything on the system). But that >>>>>> doesn't help with your read-only filesystem sorry :-( >>>>>> >>>>>> (Hmm... disgusting hack idea.... since you can't create >>>>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, >>>>>> try mounting that directory from somewhere. Extra points for using systemd >>>>>> to mount the systemd service file overrides and setting up dependencies so >>>>>> it does everything in the right order :-) ) >>>>>> >>>>>> >>>>>> -- >>>>>> Stuart Bishop >>>>>> >>>>>> -- >>>>>> 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/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> -- >>>> 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/mailm >>> an/listinfo/snapcraft >>> >>> >> -- >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Mon Jan 23 22:08:47 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 20:08:47 -0200 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: *the local snapd On Jan 23, 2017 8:04 PM, "Gustavo Niemeyer" wrote: Indeed, that smells like a bug, certainly because snap download doesn't use the local snaps to actually download the file. That should be transparent to the CLI though. Can you please file an issue? Thanks! On Jan 23, 2017 5:26 PM, "Max Brustkern" wrote: > Okay, you're right. I was testing with snap download, which doesn't seem > to use to proxy, whereas snap refresh does. Is that intended behavior, or > should I report it somewhere? > > Thanks, > Max > > On Mon, Jan 23, 2017 at 2:04 PM, Gustavo Niemeyer < > gustavo.niemeyer at canonical.com> wrote: > >> This should work fine across reboots. >> >> On Jan 23, 2017 4:49 PM, "Max Brustkern" >> wrote: >> >>> So I've been able to get it to work by creating >>> /etc/systemd/system/snapd.service.d/proxy.conf >>> with the correct settings. Any suggestions on getting that to persist >>> across reboots? >>> >>> Thanks, >>> Max >>> >>> On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < >>> michael.hudson at canonical.com> wrote: >>> >>>> >>>> >>>> On 13 January 2017 at 08:14, Max Brustkern >>> > wrote: >>>> >>>>> So I created a system directory with the contents of >>>>> /lib/systemd/system. I edited that file to contain the environment >>>>> variables: >>>>> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >>>>> [Unit] >>>>> Description=Snappy daemon >>>>> Requires=snapd.socket >>>>> >>>>> [Service] >>>>> ExecStart=/usr/lib/snapd/snapd >>>>> EnvironmentFile=/etc/environment >>>>> Restart=always >>>>> http_proxy=http://squid.internal:3128 >>>>> https_proxy=https://squid.internal:3128 >>>>> >>>> >>>> That's not the right syntax, it should be >>>> >>>> Environment=http_proxy=http://squid.internal:3128 https_proxy= >>>> https://squid.internal:3128 >>>> >>>> See man systemd.exec for more details on this. >>>> >>>> Cheers, >>>> mwh >>>> >>>> >>>>> [Install] >>>>> WantedBy=multi-user.target >>>>> >>>>> I then did: >>>>> nuclearbob at localhost:~$ sudo systemctl daemon-reload >>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>> >>>>> I still don't seem to see snapd picking up on the proxy. I tried: >>>>> sudo systemctl edit snapd >>>>> I pasted in the file contents to there, but after that I get: >>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>> Failed to restart snapd.service: Unit snapd.service is not loaded >>>>> properly: Invalid argument. >>>>> See system logs and 'systemctl status snapd.service' for details. >>>>> nuclearbob at localhost:~$ systemctl status snapd.service >>>>> ● snapd.service - Snappy daemon >>>>> Loaded: error (Reason: Invalid argument) >>>>> Drop-In: /etc/systemd/system/snapd.service.d >>>>> └─override.conf >>>>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min >>>>> 26s ago >>>>> Main PID: 1339 (snapd) >>>>> CGroup: /system.slice/snapd.service >>>>> └─1339 /usr/lib/snapd/snapd >>>>> >>>>> Any additional tips to get snapd running on ubuntu core in the lab? >>>>> >>>>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>>>> stuart.bishop at canonical.com> wrote: >>>>> >>>>>> >>>>>> >>>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>>> max.brustkern at canonical.com> wrote: >>>>>> >>>>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal >>>>>>> lab that requires a web proxy. This bug: >>>>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>>>> hold the environment variables used by snapd on an ubuntu core system are >>>>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>>>>> for snapd on that system? >>>>>>> >>>>>> >>>>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but about >>>>>> adding support for proxies to snapd (rather than have it use the system >>>>>> environment variables, which is one implementation option but not always >>>>>> what you want since that affects everything on the system). But that >>>>>> doesn't help with your read-only filesystem sorry :-( >>>>>> >>>>>> (Hmm... disgusting hack idea.... since you can't create >>>>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, >>>>>> try mounting that directory from somewhere. Extra points for using systemd >>>>>> to mount the systemd service file overrides and setting up dependencies so >>>>>> it does everything in the right order :-) ) >>>>>> >>>>>> >>>>>> -- >>>>>> Stuart Bishop >>>>>> >>>>>> -- >>>>>> 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/mailm >>>>> an/listinfo/snapcraft >>>>> >>>>> >>>> >>>> -- >>>> 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/mailm >>> an/listinfo/snapcraft >>> >>> >> -- >> 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/mailm > an/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.brustkern at canonical.com Mon Jan 23 22:13:13 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Mon, 23 Jan 2017 17:13:13 -0500 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: Here we go, thanks! https://bugs.launchpad.net/snapd/+bug/1658815 On Mon, Jan 23, 2017 at 5:08 PM, Gustavo Niemeyer wrote: > *the local snapd > > > On Jan 23, 2017 8:04 PM, "Gustavo Niemeyer" wrote: > > Indeed, that smells like a bug, certainly because snap download doesn't > use the local snaps to actually download the file. That should be > transparent to the CLI though. > > Can you please file an issue? > > Thanks! > > On Jan 23, 2017 5:26 PM, "Max Brustkern" > wrote: > >> Okay, you're right. I was testing with snap download, which doesn't seem >> to use to proxy, whereas snap refresh does. Is that intended behavior, or >> should I report it somewhere? >> >> Thanks, >> Max >> >> On Mon, Jan 23, 2017 at 2:04 PM, Gustavo Niemeyer < >> gustavo.niemeyer at canonical.com> wrote: >> >>> This should work fine across reboots. >>> >>> On Jan 23, 2017 4:49 PM, "Max Brustkern" >>> wrote: >>> >>>> So I've been able to get it to work by creating >>>> /etc/systemd/system/snapd.service.d/proxy.conf >>>> with the correct settings. Any suggestions on getting that to persist >>>> across reboots? >>>> >>>> Thanks, >>>> Max >>>> >>>> On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < >>>> michael.hudson at canonical.com> wrote: >>>> >>>>> >>>>> >>>>> On 13 January 2017 at 08:14, Max Brustkern < >>>>> max.brustkern at canonical.com> wrote: >>>>> >>>>>> So I created a system directory with the contents of >>>>>> /lib/systemd/system. I edited that file to contain the environment >>>>>> variables: >>>>>> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >>>>>> [Unit] >>>>>> Description=Snappy daemon >>>>>> Requires=snapd.socket >>>>>> >>>>>> [Service] >>>>>> ExecStart=/usr/lib/snapd/snapd >>>>>> EnvironmentFile=/etc/environment >>>>>> Restart=always >>>>>> http_proxy=http://squid.internal:3128 >>>>>> https_proxy=https://squid.internal:3128 >>>>>> >>>>> >>>>> That's not the right syntax, it should be >>>>> >>>>> Environment=http_proxy=http://squid.internal:3128 https_proxy= >>>>> https://squid.internal:3128 >>>>> >>>>> See man systemd.exec for more details on this. >>>>> >>>>> Cheers, >>>>> mwh >>>>> >>>>> >>>>>> [Install] >>>>>> WantedBy=multi-user.target >>>>>> >>>>>> I then did: >>>>>> nuclearbob at localhost:~$ sudo systemctl daemon-reload >>>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>>> >>>>>> I still don't seem to see snapd picking up on the proxy. I tried: >>>>>> sudo systemctl edit snapd >>>>>> I pasted in the file contents to there, but after that I get: >>>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>>> Failed to restart snapd.service: Unit snapd.service is not loaded >>>>>> properly: Invalid argument. >>>>>> See system logs and 'systemctl status snapd.service' for details. >>>>>> nuclearbob at localhost:~$ systemctl status snapd.service >>>>>> ● snapd.service - Snappy daemon >>>>>> Loaded: error (Reason: Invalid argument) >>>>>> Drop-In: /etc/systemd/system/snapd.service.d >>>>>> └─override.conf >>>>>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min >>>>>> 26s ago >>>>>> Main PID: 1339 (snapd) >>>>>> CGroup: /system.slice/snapd.service >>>>>> └─1339 /usr/lib/snapd/snapd >>>>>> >>>>>> Any additional tips to get snapd running on ubuntu core in the lab? >>>>>> >>>>>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>>>>> stuart.bishop at canonical.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>>>> max.brustkern at canonical.com> wrote: >>>>>>> >>>>>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal >>>>>>>> lab that requires a web proxy. This bug: >>>>>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>>>>> hold the environment variables used by snapd on an ubuntu core system are >>>>>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>>>>>> for snapd on that system? >>>>>>>> >>>>>>> >>>>>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but >>>>>>> about adding support for proxies to snapd (rather than have it use the >>>>>>> system environment variables, which is one implementation option but not >>>>>>> always what you want since that affects everything on the system). But that >>>>>>> doesn't help with your read-only filesystem sorry :-( >>>>>>> >>>>>>> (Hmm... disgusting hack idea.... since you can't create >>>>>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, >>>>>>> try mounting that directory from somewhere. Extra points for using systemd >>>>>>> to mount the systemd service file overrides and setting up dependencies so >>>>>>> it does everything in the right order :-) ) >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Stuart Bishop >>>>>>> >>>>>>> -- >>>>>>> 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/mailm >>>>>> an/listinfo/snapcraft >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alejandro.cura at canonical.com Mon Jan 23 22:22:27 2017 From: alejandro.cura at canonical.com (Alejandro J. Cura) Date: Mon, 23 Jan 2017 19:22:27 -0300 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: Perhaps something else is broken, because I'm trying installing mir-libs, mir-kiosk and mir-kiosk-apps on the latest raspi 2 image (on a Raspberry Pi 2, of course), and on the amd64 image on a kvm, and I can't even get mir-kiosk to launch and show the black screen with the pointer. Both the raspi2 and kvm get stuck at the text mode login. The following in syslog seems relevant: Jan 23 07:37:29 localhost snap[1658]: Unknown command line options: --vt 1 Jan 23 07:37:30 localhost snap[1658]: /snap/mir-kiosk/20/bin/run-miral: line 59: 1674 Terminated $SNAP/usr/bin/inotifywait -e modify ${CONFIG_FILE} Jan 23 07:37:30 localhost snap[1658]: Shutting down miral-kiosk (pid: 1673) Jan 23 07:37:30 localhost snap[1658]: /snap/mir-kiosk/20/bin/run-miral: line 64: kill: (1673) - No such process Jan 23 07:37:30 localhost snap[1658]: miral-kiosk was already dead! alecu at localhost:~$ snap list Name Version Rev Developer Notes core 16.04.1 964 canonical - mir-kiosk 0.1 20 canonical - mir-kiosk-apps 0.1 11 canonical - mir-libs 0.1 20 canonical devmode pi2 16.04-0.17 36 canonical - pi2-kernel 4.4.0-1040-47 26 canonical - cheers, -- alecu On Mon, Jan 23, 2017 at 5:53 PM, Alejandro J. Cura wrote: > > Hey all, thanks for the hard work getting this image into shape. > > I've been trying to run on a Raspi3 the Mir-kiosk-apps demo from: https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ but I've not had much success. End of last week the demos would crash, and Mir would shut down after a few seconds. After refreshing the core today, I'm getting the very first frame, and when I try to move the mouse I see the cursor make a small jump (perhaps another frame?) and then it all hangs up. > > I can ssh into the raspi, and enable a different one of the demo apps with something like: > $ snap set mir-kiosk-apps app="rssnews"; snap disable mir-kiosk-apps; snap disable mir-kiosk; snap enable mir-kiosk; snap enable mir-kiosk-apps > > But it still gets stuck on the first frame and only allows a small jump of the mouse before freezing. > > I've also tried the kodi demo snap mentioned here: https://plus.google.com/u/0/+OliverGrawert/posts/6S6U4MKG32y > but that crashes with something like: > > alecu at localhost:~$ /snap/bin/kodi-mir-snapshot.kodi > ERROR: Unable to create GUI. Exiting > *** Error in `/snap/kodi-mir-snapshot/x1/lib/kodi/kodi.bin': free(): invalid pointer: 0x75d99844 *** > /snap/kodi-mir-snapshot/x1/bin/runner_kodi: line 180: 2720 Aborted "$LIBDIR/${bin_name}/${bin_name}.bin" $SAVED_ARGS > Crash report available at /home/alecu/snap/kodi-mir-snapshot/x1/kodi_crashlog-20170123_202923.log > > Any ideas on what I should try, or how to further debug this? I can upload the crash report if it helps. > > thanks! > -- > alecu > > > > On Mon, Jan 23, 2017 at 9:46 AM, Gustavo Niemeyer wrote: > > > > Super nice indeed. Thanks, Oliver! > > > > Has anyone tried the new GL and gpios? How did it go? > > > > Perhaps we can ask for some extra millage on the pi community list itself? > > > > On Wed, Jan 18, 2017 at 1:59 PM, Oliver Grawert wrote: > >> > >> hi, > >> > >> at [1] you can now find a daily image build for the Pi2 and Pi3 that > >> both have full GLES support and all 26 GPIOs exposed through > >> interfaces, some test feedback would be nice :) > >> > >> the GPIO numbering and pin mapping follows the community map at [2] and > >> looks like [3] in the "snap interfaces" output now. > >> > >> ciao > >> oli > >> > >> [1] http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ > >> [2] http://pinout.xyz/# > >> [3] http://paste.ubuntu.com/23822613/ > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > >> > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > From jamie at canonical.com Mon Jan 23 22:49:18 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 23 Jan 2017 16:49:18 -0600 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: <1485211758.3222.78.camel@canonical.com> On Mon, 2017-01-23 at 19:22 -0300, Alejandro J. Cura wrote: > Perhaps something else is broken, because I'm trying installing > mir-libs, mir-kiosk and mir-kiosk-apps on the latest raspi 2 image (on > a Raspberry Pi 2, of course), and on the amd64 image on a kvm, and I > can't even get mir-kiosk to launch and show the black screen with the > pointer. Both the raspi2 and kvm get stuck at the text mode login. > > The following in syslog seems relevant: > > Jan 23 07:37:29 localhost snap[1658]: Unknown command line options: --vt 1 > Jan 23 07:37:30 localhost snap[1658]: > /snap/mir-kiosk/20/bin/run-miral: line 59:  1674 Terminated >   $SNAP/usr/bin/inotifywait -e modify ${CONFIG_FILE} > Jan 23 07:37:30 localhost snap[1658]: Shutting down miral-kiosk (pid: 1673) > Jan 23 07:37:30 localhost snap[1658]: > /snap/mir-kiosk/20/bin/run-miral: line 64: kill: (1673) - No such > process > Jan 23 07:37:30 localhost snap[1658]: miral-kiosk was already dead! > > alecu at localhost:~$ snap list > Name            Version        Rev  Developer  Notes > core            16.04.1        964  canonical  - > mir-kiosk       0.1            20   canonical  - > mir-kiosk-apps  0.1            11   canonical  - > mir-libs        0.1            20   canonical  devmode > pi2             16.04-0.17     36   canonical  - > pi2-kernel      4.4.0-1040-47  26   canonical  - Are the interfaces connected? What is the output of 'snap interfaces'? -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From aaron.hampt at gmail.com Tue Jan 24 03:15:57 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Mon, 23 Jan 2017 22:15:57 -0500 Subject: SDL2 / Kivy keyboard event not firing in Snap Message-ID: Hi, I'm trying to use Kivy ( https://kivy.org/#home ) inside a snap. It mostly works, but some SDL2 events don't occur. If I run the application from outside of a snap the events do happen. Specifically, the textinput event works outside of a snap, not inside of a snap. This is the code I'm using: https://github.com/hamptus/kivy-snap I have asked in the Kivy IRC, but didn't get very far there. Are there any permissions I should be aware of? Any other packages I need installed for all the SDL2 events to work? Thanks ahead of time! Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Tue Jan 24 03:49:19 2017 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 23 Jan 2017 21:49:19 -0600 Subject: classic snap fails to find libraries In-Reply-To: References: Message-ID: After reading the other thread about a similar issue, I moved my libraries to stage-packages and that worked. My problem now is that ssh can't call a binary from a snap, it will only work using the full path. Let's say I have the hello snap installed in 192.168.122.24. Then: elopio at ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello elopio at 192.168.122.24's password: bash: hello: command not found elopio at ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello elopio at 192.168.122.24's password: Hello, world! I seem to remember that there was a bug open about this, but I can't find it. Anyone remembers what's the problem here? This is not blocking the mosh snap, but in order to make it work one would have to call it like this: mosh 192.168.122.24 --server=/snap/bin/mosh-server after enabling the alias. From dank at kegel.com Tue Jan 24 03:54:26 2017 From: dank at kegel.com (Dan Kegel) Date: Mon, 23 Jan 2017 19:54:26 -0800 Subject: classic snap fails to find libraries In-Reply-To: References: Message-ID: I dunno if there's a bug open for it, but I mentioned another workaround earlier this month: https://lists.ubuntu.com/archives/snapcraft/2017-January/002307.html On Mon, Jan 23, 2017 at 7:49 PM, Leo Arias wrote: > After reading the other thread about a similar issue, I moved my > libraries to stage-packages and that worked. > > My problem now is that ssh can't call a binary from a snap, it will > only work using the full path. Let's say I have the hello snap > installed in 192.168.122.24. Then: > > elopio at ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello > elopio at 192.168.122.24's password: > bash: hello: command not found > elopio at ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello > elopio at 192.168.122.24's password: > Hello, world! > > I seem to remember that there was a bug open about this, but I can't > find it. Anyone remembers what's the problem here? > > This is not blocking the mosh snap, but in order to make it work one > would have to call it like this: > > mosh 192.168.122.24 --server=/snap/bin/mosh-server > > after enabling the alias. > > -- > 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 Jan 24 09:36:05 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 24 Jan 2017 10:36:05 +0100 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> Message-ID: <1485250565.4288.98.camel@ubuntu.com> hi, Am Montag, den 23.01.2017, 17:53 -0300 schrieb Alejandro J. Cura: >  > ... > Any ideas on what I should try, or how to further debug this? I can > upload the crash report if it helps. first of all make sure to only use the very latest daily edge image (url is in my original mail, the setup only works with the right gadget and kernel, they need to be in sync).  all issues with mir were fixed with the most recent mir-kiosk snap so you can just snap install them from the store from the edge channel (i just tested them on two fresh installs on the pi2 and 3) ...  there is however the content sharing interface involved in using the mir-libs which still has issues, make sure you did the disable/disconnect/connect/enable dance described on the mir wiki the least you should get is a black screen with a mouse cursor right after (well about 15-30 sec after) boot ... it definitely works for me on both test boards. 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 Jan 24 09:59:16 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 24 Jan 2017 10:59:16 +0100 Subject: classic snap fails to find libraries In-Reply-To: References: Message-ID: <1485251956.4288.109.camel@ubuntu.com> hi, Am Montag, den 23.01.2017, 21:49 -0600 schrieb Leo Arias: > After reading the other thread about a similar issue, I moved my > libraries to stage-packages and that worked. > > My problem now is that ssh can't call a binary from a snap, it will > only work using the full path. Let's say I have the hello snap > installed in 192.168.122.24. Then: > > elopio at ubuntu-xenial:~/mosh$ ssh 192.168.122.24 hello > elopio at 192.168.122.24's password: > bash: hello: command not found > elopio at ubuntu-xenial:~/mosh$ ssh 192.168.122.24 /snap/bin/hello > elopio at 192.168.122.24's password: > Hello, world! > > I seem to remember that there was a bug open about this, but I can't > find it. Anyone remembers what's the problem here? > bash actually checks the calling process and will not source the env if it is invoked by sshd or rshd as non-login shell (it checks if the SSH_CLIENT environment variable is set and uses a different code path internally). the follwing works: $ ssh 192.168.2.91 env|grep PATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/ games:/usr/local/games $ ssh 192.168.2.91 bash -lc env|grep PATH PATH=/home/ogra/bin:/home/ogra/.local/bin:/usr/local/sbin:/usr/local/bi n:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin you could also do something like: ssh 192.168.2.91 "source /etc/profile; hello" i dont think we have a bug open for this and technically it is expected behaviour (not different from any other ubuntu install), but given how annoying it is i guess you should file one and we should find a proper workaround or fix to ship in the image ... 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 olivier.tilloy at canonical.com Tue Jan 24 10:22:45 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Tue, 24 Jan 2017 11:22:45 +0100 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: References: Message-ID: On Tue, Jan 24, 2017 at 4:15 AM, Aaron Hampton wrote: > Hi, > > I'm trying to use Kivy ( https://kivy.org/#home ) inside a snap. It mostly > works, but some SDL2 events don't occur. If I run the application from > outside of a snap the events do happen. > > Specifically, the textinput event works outside of a snap, not inside of a > snap. This is the code I'm using: > > https://github.com/hamptus/kivy-snap > > I have asked in the Kivy IRC, but didn't get very far there. Are there any > permissions I should be aware of? Any other packages I need installed for > all the SDL2 events to work? That sounds very similar to the issue I was having with the 0ad snap, which after much debugging I fixed by exporting $XLOCALEDIR, see details here: https://bazaar.launchpad.net/~osomon/+junk/0ad-snap/revision/8. Let us know if that did the trick. Also, this should be documented somehow for people snapping X11/SDL games. Do we have a place for such tips and tricks? Cheers, Olivier From olivier.tilloy at canonical.com Tue Jan 24 11:15:47 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Tue, 24 Jan 2017 12:15:47 +0100 Subject: Snapcraft 2.25 has been released. In-Reply-To: References: Message-ID: On Mon, Jan 23, 2017 at 3:21 PM, XiaoGuo Liu wrote: > Hi Olivier, > > Sorry, I do not understand what exactly you mean "no app in the snap is > named like > the snap itself". Could you please elaborate it more? Your snap is named "hello-xiaoguo", and your apps are named "env", "evil", "sh", "hello-world", "createfile", "createfiletohome", "writetocommon". There is no app named "hello-xiaoguo", so your example is not affected by https://launchpad.net/bugs/1658123. > On Mon, Jan 23, 2017 at 9:50 PM, Olivier Tilloy > wrote: >> >> Hi XiaoGuo, >> >> Your example happens to work because no app in the snap is named like >> the snap itself. For such snaps, using the new desktop feature should >> be safe. >> >> Cheers, >> >> Olivier >> >> >> On Mon, Jan 23, 2017 at 3:48 AM, XiaoGuo Liu >> wrote: >> > Hi Olivier, >> > >> > Based on the snapcraft release 2.25, I have made an example at: >> > >> > https://github.com/liu-xiao-guo/helloworld-desktop >> > >> > So, far, I do not have any problems with it. Is there anything I am >> > doing >> > wrongly? I can see the launchers in the Ubuntu dash without any problems >> > and >> > the apps are launched well. >> > >> > By the way, I have created a blog for it at >> > http://blog.csdn.net/ubuntutouch/article/details/54691673. It has the >> > captured pictures. >> > >> > Thanks & best regards, >> > XiaoGuo >> > >> > On Sat, Jan 21, 2017 at 12:09 AM, Olivier Tilloy >> > wrote: >> >> >> >> On Thu, Jan 19, 2017 at 3:47 AM, Sergio Schvezov >> >> wrote: >> >> > Hello snapcrafters! >> >> > >> >> > We are pleased to announce the release of version `2.25` of snapcraft >> >> > has been released: >> >> > https://launchpad.net/snapcraft/+milestone/2.25 >> >> > >> >> > This release is now available on xenial-updates, yakkety-updates and >> >> > zesty. >> >> > What follows are the full release notes (the prettier version can be >> >> > read at https://github.com/snapcore/snapcraft/releases/tag/2.25) >> >> > >> >> > # New in this release >> >> > >> >> > ## Support for hooks >> >> > Hooks support has arrived. There are currently two ways to use them, >> >> > either with a by-convention path or by using a `part` and installing >> >> > into an >> >> > expected path in the part's install directory. >> >> > >> >> > Find out more about this feature at >> >> > https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md >> >> > >> >> > ## Desktop file support >> >> > Aside from the by-convention functionality already in place, you can >> >> > now >> >> > declare a desktop file from your app within an `apps` entry using a >> >> > path >> >> > relative to the `prime` directory pointing to a desktop file, >> >> > snapcraft will >> >> > take care of the rest. >> >> >> >> I would not recommend starting to use that new feature because of >> >> https://launchpad.net/bugs/1658123. This will hopefully be usable in >> >> time for 2.26. >> >> >> >> >> >> > So if your project already has a desktop file, say in >> >> > `./prime/usr/share/applications/my-app.desktop` all you need to do is >> >> > something like this: >> >> > >> >> > ```yaml >> >> > apps: >> >> > my-app: >> >> > command: my-app >> >> > desktop: usr/share/applications/my-app.desktop >> >> > ``` >> >> > >> >> > That said, it is worth mentioning that the by-convention mechanism is >> >> > still supported. >> >> > >> >> > ## rust plugin >> >> > The `rust` plugin has seen an improvement and a couple of bug fixes. >> >> > >> >> > The added feature allow for one to set `rust-features` which is a >> >> > list >> >> > of strings used to build optional dependencies (run `snapcraft help >> >> > rust` >> >> > for a bit more details). >> >> > >> >> > The bug fixes relate to: >> >> > >> >> > - Allowing to build with `Cargo.toml` not in the base source >> >> > directory. >> >> > - Repecting the other `rust` plugin properties: `rust-channel` and >> >> > `rust-revision`. >> >> > >> >> > ## nodejs plugin >> >> > The plugin now correctly downloads dependencies in `package.json` to >> >> > the >> >> > correct location. >> >> > >> >> > ## godeps plugin >> >> > This plugin is now no longer affected by `GOBIN` being set in the >> >> > environment. >> >> > >> >> > ## deb sources >> >> > `deb` sources are now being handled with `python-debian` which does >> >> > incorrecly handle symlinks. >> >> > >> >> > ## More modes for daemon's in apps >> >> > You can now set the `daemon` property in an `apps` entry to `notify` >> >> > (and it will follow systemd's expected behavior for this service >> >> > type). >> >> > >> >> > ## Deprecations >> >> > Some new deprecations have been introduced, for `parts` the `prime` >> >> > keyword is now favored over the `snap` one. When using the `snap` >> >> > keyword a >> >> > link to http://snapcraft.io/docs/deprecation-notices/dn1 will be >> >> > presented >> >> > with more information and the migration path. >> >> > >> >> > Plugins that are part of snapcraft that were displaying `DEPRECATED` >> >> > notices have all been updated to use the newer plugin API. >> >> > >> >> > ## Classic confinement >> >> > Some improvements were made to classic confinement with a more >> >> > comprehensive error when the prerequisites to build a classic >> >> > confined snap >> >> > are not met. >> >> > >> >> > ## parts >> >> > Improvements were made to the core parts management of snapcraft: >> >> > >> >> > - `stage` entries now don't need to be replicated in `prime`. >> >> > - cleaning all parts works correctly even if `snapcraft.yaml` is >> >> > broken. >> >> > >> >> > ## Others >> >> > For the full list of things available on 2.25 feel free to check >> >> > https://launchpad.net/snapcraft/+milestone/2.25 >> >> > >> >> > # 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: >> >> > >> >> > - Chris Holcombe >> >> > - Jonathon Love >> >> > - Kit Randel >> >> > - Marco Trevisan >> >> > - Matthew Aguirre >> >> > - Olivier Tilloy >> >> > >> >> > # Final Notes >> >> > To get the source for this release check it out at >> >> > https://github.com/snapcore/snapcraft/releases/tag/2.25 >> >> > >> >> > 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 >> >> > >> >> > -- >> >> > 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 >> > >> > >> > >> > >> > -- >> > XiaoGuo, Liu >> > >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > XiaoGuo, Liu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From aaron.hampt at gmail.com Tue Jan 24 13:04:25 2017 From: aaron.hampt at gmail.com (Aaron Hampton) Date: Tue, 24 Jan 2017 08:04:25 -0500 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: References: Message-ID: That solved it. Thank you so much! On Tue, Jan 24, 2017 at 5:22 AM, Olivier Tilloy < olivier.tilloy at canonical.com> wrote: > On Tue, Jan 24, 2017 at 4:15 AM, Aaron Hampton > wrote: > > Hi, > > > > I'm trying to use Kivy ( https://kivy.org/#home ) inside a snap. It > mostly > > works, but some SDL2 events don't occur. If I run the application from > > outside of a snap the events do happen. > > > > Specifically, the textinput event works outside of a snap, not inside of > a > > snap. This is the code I'm using: > > > > https://github.com/hamptus/kivy-snap > > > > I have asked in the Kivy IRC, but didn't get very far there. Are there > any > > permissions I should be aware of? Any other packages I need installed for > > all the SDL2 events to work? > > That sounds very similar to the issue I was having with the 0ad snap, > which after much debugging I fixed by exporting $XLOCALEDIR, see > details here: https://bazaar.launchpad.net/~osomon/+junk/0ad-snap/ > revision/8. > > Let us know if that did the trick. > Also, this should be documented somehow for people snapping X11/SDL > games. Do we have a place for such tips and tricks? > > Cheers, > > Olivier > > -- > 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 alan.pope at canonical.com Tue Jan 24 13:47:56 2017 From: alan.pope at canonical.com (Alan Pope) Date: Tue, 24 Jan 2017 13:47:56 +0000 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: References: Message-ID: On 24 January 2017 at 10:22, Olivier Tilloy wrote: > That sounds very similar to the issue I was having with the 0ad snap, > which after much debugging I fixed by exporting $XLOCALEDIR, see > details here: https://bazaar.launchpad.net/~osomon/+junk/0ad-snap/revision/8. > You're a star. I have had a LÖVE (also SDL) game on the back burner because keyboard input didn't work, this fixed it, and should open the door for other games built using LÖVE into the store! > Let us know if that did the trick. > Also, this should be documented somehow for people snapping X11/SDL > games. Do we have a place for such tips and tricks? > Maybe we need an X11/SDL plain launcher remote part which people can pull in, that includes this kind of detail? Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From mhall119 at ubuntu.com Tue Jan 24 14:04:15 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Tue, 24 Jan 2017 09:04:15 -0500 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: References: Message-ID: <2208e004-dc99-cc23-d772-e8057742d2d4@ubuntu.com> On 01/24/2017 08:47 AM, Alan Pope wrote: > On 24 January 2017 at 10:22, Olivier Tilloy > wrote: >> That sounds very similar to the issue I was having with the 0ad snap, >> which after much debugging I fixed by exporting $XLOCALEDIR, see >> details here: https://bazaar.launchpad.net/~osomon/+junk/0ad-snap/revision/8. >> > > You're a star. I have had a LÖVE (also SDL) game on the back burner > because keyboard input didn't work, this fixed it, and should open the > door for other games built using LÖVE into the store! > >> Let us know if that did the trick. >> Also, this should be documented somehow for people snapping X11/SDL >> games. Do we have a place for such tips and tricks? >> > > Maybe we need an X11/SDL plain launcher remote part which people can > pull in, that includes this kind of detail? > > Cheers, > Is there any reason not to add it to the desktop-helpers remote part? XLOCALEDIR isn't SDL-specific, it just seems to be the first thing that's brought it to our attention. -- Michael Hall mhall119 at ubuntu.com From alan.pope at canonical.com Tue Jan 24 14:18:41 2017 From: alan.pope at canonical.com (Alan Pope) Date: Tue, 24 Jan 2017 14:18:41 +0000 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: <2208e004-dc99-cc23-d772-e8057742d2d4@ubuntu.com> References: <2208e004-dc99-cc23-d772-e8057742d2d4@ubuntu.com> Message-ID: Hi Michael, On 24 January 2017 at 14:04, Michael Hall wrote: > Is there any reason not to add it to the desktop-helpers remote part? > XLOCALEDIR isn't SDL-specific, it just seems to be the first thing > that's brought it to our attention. > Can add it there too for sure. I thought it might be preferable to have a leaner launcher for things which are neither GTK nor QT. Something which just launches an SDL window doesn't necessarily need all the other pieces. Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From mhall119 at ubuntu.com Tue Jan 24 14:19:52 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Tue, 24 Jan 2017 09:19:52 -0500 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: References: <2208e004-dc99-cc23-d772-e8057742d2d4@ubuntu.com> Message-ID: <3139eaeb-635f-78c2-f074-1725e5011bd2@ubuntu.com> On 01/24/2017 09:18 AM, Alan Pope wrote: > Hi Michael, > > On 24 January 2017 at 14:04, Michael Hall wrote: >> Is there any reason not to add it to the desktop-helpers remote part? >> XLOCALEDIR isn't SDL-specific, it just seems to be the first thing >> that's brought it to our attention. >> > > Can add it there too for sure. > > I thought it might be preferable to have a leaner launcher for things > which are neither GTK nor QT. Something which just launches an SDL > window doesn't necessarily need all the other pieces. > > Cheers, > There is the glib-only launcher, will that do or would we need something between glib-only and gtk/qt? Michael Hall mhall119 at ubuntu.com From adam.stokes at canonical.com Tue Jan 24 14:44:54 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Tue, 24 Jan 2017 14:44:54 +0000 Subject: Issue with classic snap on 14.04 that uses systemd scripts Message-ID: I've got a working classic snap on 16.04 that utilizes a oneshot systemd service for making sure my iptables and network bridge is persisted through reboots. When attempting to get the same snap working on 14.04 I run into a snap install error: ubuntu at darthbawlz:~$ sudo snap install conjure-up --classic --edge error: cannot perform the following tasks: - Start snap "conjure-up" (34) services ([start snap.conjure-up.bridge.service] failed with exit status 1: Job for snap.conjure-up.bridge.service failed. See 'systemctl status snap.conjure-up.bridge.service' and 'journalctl -xn' for details. ) ubuntu at darthbawlz:~$ systemctl status snap.conjure-up.bridge.service snap.conjure-up.bridge.service Loaded: error (Reason: No such file or directory) Active: failed (Result: core-dump) since Tue 2017-01-24 13:52:32 UTC; 47s ago Main PID: 1548 (code=dumped, signal=SEGV) This is on snapd 2.21 from trusty-proposed and my snapcraft repo is @ https://github.com/conjure-up/conjure-up-snap Is there something I need to be doing different to get those systemd scripts working on trusty? Also a side note: We need more hooks for things like cleaning up iptables rules if I uninstall conjure-up. I know we want to keep snap building simple but deb packaging has maintainer scripts for this very reason. (https://bugs.launchpad.net/snappy/+bug/1611638 but expanded to things like postrm etc) -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.sheldon at canonical.com Tue Jan 24 14:47:43 2017 From: michael.sheldon at canonical.com (Mike Sheldon) Date: Tue, 24 Jan 2017 14:47:43 +0000 Subject: Naming for the Ubuntu Download Manager interface In-Reply-To: References: <1484747261.7772.34.camel@canonical.com> <1484751694.7772.37.camel@canonical.com> <1484756134.7772.42.camel@canonical.com> <1484757278.7772.47.camel@canonical.com> <1485191960.8553.4.camel@canonical.com> Message-ID: <1485269263.8553.14.camel@canonical.com> I've submitted a branch for this here:   https://github.com/snapcore/snapd/pull/2694 Thanks!  Mike On Mon, 2017-01-23 at 15:23 -0200, Gustavo Niemeyer wrote: > That'd be ideal, thanks! > > On Mon, Jan 23, 2017 at 3:19 PM, Mike Sheldon cal.com> wrote: > > Okay great, should I prepare a new branch that does the renaming? > > > > On Mon, 2017-01-23 at 14:34 -0200, Gustavo Niemeyer wrote: > > > Sounds good. If you think ubuntu-download-manager is the way to > > go, > > > let's move on with it. > > > > > > On Wed, Jan 18, 2017 at 2:34 PM, Mike Sheldon > noni > > > cal.com> wrote: > > > > Ah, my mistake. I'd suspect UDM is less likely to change since > > it's > > > > already a public facing API being used in third party apps. But > > it > > > > sounds like we don't lose anything if we start it off as > > unity8- > > > > download-manager whilst bundled with unity8 if we can then add > > an > > > > additional interface once its distributed in its own snap > > (although > > > > I > > > > guess that snap would have to advertise itself as providing > > both > > > > interfaces to keep compatibility with existing snaps).  > > > > > > > > I'm not sure if we gain much in this particular case though > > since > > > > we'd > > > > need to be maintaining a stable API to work with existing apps > > > > regardless? > > > > > > > > On Wed, 2017-01-18 at 14:24 -0200, Gustavo Niemeyer wrote: > > > > > Sorry for not being clear. In addition to the suggestion > > about > > > > > ubuntu-download-manager, I also wrote this: > > > > > > > > > > "Note that part of the rationale of having unity8-contacts > > and > > > > > unity8-calendar named like that was that these interfaces are > > > > likely > > > > > to change in meaningful and incompatible ways in the near > > future. > > > > If > > > > > the download manager is going to be bundled with unity8, it > > may > > > > be > > > > > wise to do the same. We can always introduce a more general > > > > interface > > > > > later.. not so nice to get out of a general interface that > > > > doesn't > > > > > work." > > > > > > > > > > What's your take on it? > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 2:15 PM, Mike Sheldon > n at ca > > > > noni > > > > > cal.com> wrote: > > > > > > Sorry, that was my entire point, I guess I should have > > expanded > > > > on > > > > > > it a > > > > > > bit. I agree with ubuntu-download-manager as a name, since > > > > that's > > > > > > the > > > > > > name developers will be interacting with if they're using > > our > > > > SDK. > > > > > > For > > > > > > example under QML they're importing Ubuntu.DownloadManager > > and > > > > the > > > > > > C++ > > > > > > namespace is Ubuntu::DownloadManager. So the interface > > being > > > > named > > > > > > ubuntu-download-manager seems perfectly natural to me (in > > fact > > > > this > > > > > > was > > > > > > the initial name I proposed for it, before it was suggested > > > > that > > > > > > download-manager might be a better name). > > > > > > > > > > > > On Wed, 2017-01-18 at 13:22 -0200, Gustavo Niemeyer wrote: > > > > > > > The second part of the point was cut out. Can you please > > at > > > > least > > > > > > let > > > > > > > us know how you feel about it, so we can be in sync about > > the > > > > > > right > > > > > > > decision. > > > > > > > > > > > > > > On Jan 18, 2017 1:02 PM, "Mike Sheldon" > cano > > > > nica > > > > > > l.co > > > > > > > m> wrote: > > > > > > > ubuntu-download-manager makes sense as a name to me, > > > > especially > > > > > > as > > > > > > > it's > > > > > > > one of the APIs in the Ubuntu SDK. > > > > > > > > > > > > > > On Wed, 2017-01-18 at 12:34 -0200, Gustavo Niemeyer > > wrote: > > > > > > > > > > > > > > > > The real issue with download-manager is that it's too > > > > general. > > > > > > We > > > > > > > all > > > > > > > > have several download managers in our systems, so this > > > > gives no > > > > > > > hint > > > > > > > > of what it's really talking about. > > > > > > > > > > > > > > > > We can call it ubuntu-download-manager if that's how > > the > > > > > > software > > > > > > > was > > > > > > > > named. Note that part of the rationale of having > > unity8- > > > > > > contacts > > > > > > > and > > > > > > > > unity8-calendar named like that was that these > > interfaces > > > > are > > > > > > > likely > > > > > > > > to change in meaningful and incompatible ways in the > > near > > > > > > future. > > > > > > > If > > > > > > > > the download manager is going to be bundled with > > unity8, it > > > > may > > > > > > be > > > > > > > > wise to do the same. We can always introduce a more > > general > > > > > > > interface > > > > > > > > later.. not so nice to get out of a general interface > > that > > > > > > doesn't > > > > > > > > work. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Jan 18, 2017 at 11:47 AM, Mike Sheldon > > > > > > > > > @can > > > > > > > on > > > > > > > > ical.com> wrote: > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > > >  Currently the interface for UDM (Ubuntu Download > > > > Manager) > > > > > > has > > > > > > > been > > > > > > > > > named unity8-download-manager. It's my understanding > > that > > > > > > whilst > > > > > > > we > > > > > > > > > might initially be bundling UDM within the unity8 > > snap to > > > > > > make > > > > > > > the > > > > > > > > > first stages of development easier (e.g. so it can > > talk > > > > > > directly > > > > > > > to > > > > > > > > > unity8's transfer indicator), the long term plan > > would be > > > > for > > > > > > it > > > > > > > to > > > > > > > > > be > > > > > > > > > available separately. > > > > > > > > > > > > > > > > > >  Having UDM permanently tied to unity8 would seem to > > add > > > > a > > > > > > strong > > > > > > > > > disincentive for app developers to make use of it at > > all, > > > > as > > > > > > > their > > > > > > > > > apps > > > > > > > > > would then no-longer be portable across different > > desktop > > > > > > > > > environments. > > > > > > > > > > > > > > > > > >  As such, I'm wondering if the naming of this > > interface > > > > is > > > > > > > perhaps > > > > > > > > > misleading? > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > >  Mike > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Snapcraft mailing list > > > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > > > Modify settings or unsubscribe at: https://lists.ubun > > tu.c > > > > om/m > > > > > > ailm > > > > > > > an > > > > > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --  > > > > > > > > > > > > > > > > gustavo @ http://niemeyer.net > > > > > > > > --  > > > > > > > > Snapcraft mailing list > > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu > > .com > > > > /mai > > > > > > lman > > > > > > > /l > > > > > > > > istinfo/snapcraft > > > > > > > > > > > > > > -- > > > > > > > Snapcraft mailing list > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.c > > om/m > > > > ailm > > > > > > an/l > > > > > > > istinfo/snapcraft > > > > > > > > > > > > > > --  > > > > > > > Snapcraft mailing list > > > > > > > Snapcraft at lists.snapcraft.io > > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.c > > om/m > > > > ailm > > > > > > an/l > > > > > > > istinfo/snapcraft > > > > > > > > > > > > -- > > > > > > Snapcraft mailing list > > > > > > Snapcraft at lists.snapcraft.io > > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com > > /mai > > > > lman > > > > > > /listinfo/snapcraft > > > > > > > > > > > > > > > > > > > > > --  > > > > > > > > > > gustavo @ http://niemeyer.net > > > > > --  > > > > > Snapcraft mailing list > > > > > Snapcraft at lists.snapcraft.io > > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/m > > ailm > > > > an/l > > > > > istinfo/snapcraft > > > > > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.snapcraft.io > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mai > > lman > > > > /listinfo/snapcraft > > > > > > > > > > > > > --  > > > > > > gustavo @ http://niemeyer.net > > > --  > > > Snapcraft mailing list > > > Snapcraft at lists.snapcraft.io > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > > an/l > > > istinfo/snapcraft > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > --  > > gustavo @ http://niemeyer.net > --  > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/l > istinfo/snapcraft From ribalkin at gmail.com Tue Jan 24 15:56:14 2017 From: ribalkin at gmail.com (Boris Rybalkin) Date: Tue, 24 Jan 2017 15:56:14 +0000 Subject: systemd reload (ExevReload) support In-Reply-To: References: Message-ID: Here it is: https://github.com/snapcore/snapd/pull/2697 Also signed the agreement. Thanks. On 23 Jan 2017 16:42, "Gustavo Niemeyer" wrote: > Nice change, Boris! > > Would you like to submit a PR for that? > > We have a CLA you can easily sign online assuming you're happy with the > terms: > > https://www.ubuntu.com/legal/contributors > > > > On Tue, Jan 17, 2017 at 11:51 AM, Boris Rybalkin > wrote: > >> Yes, I had to add support on our branch before we get official >> Implementation: >> >> https://github.com/syncloud/snapd/blob/master/wrappers/services.go#L185 >> >> I have also created a bug: >> >> https://bugs.launchpad.net/snapd/+bug/1657116 >> >> On 17 Jan 2017 13:19, "Zygmunt Krynicki" >> wrote: >> >>> Quick grep tells me that this is not currently supported. >>> >>> On Sat, Jan 14, 2017 at 4:55 PM, Boris Rybalkin >>> wrote: >>> > Hi, >>> > >>> > Could you tell me if there is systemd ExecReload support in snap.yaml? >>> > >>> > Thank you. >>> > >>> > -- >>> > 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 >>> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing 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 michael.hudson at canonical.com Tue Jan 24 19:17:17 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Wed, 25 Jan 2017 08:17:17 +1300 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: Hm, I was assuming that the PYTHONHOME leaking was due to things in the snap specifically (is the source to the snap available?), but are they set by snapd or snap-confine or something? Cheers, mwh On 24 January 2017 at 00:09, Gustavo Niemeyer wrote: > > I'm wondering if maybe we should simply drop all snapcraft wrappers for > classic snaps, specifically. > > As it is, the amount of magic that is actually intended for strict snaps > seems to be hurting the behavior and understanding of classic snaps. I > doubt adding even more magic will help. > > > > On Mon, Jan 23, 2017 at 2:35 AM, Stuart Bishop < > stuart.bishop at canonical.com> wrote: > >> >> >> On 20 January 2017 at 19:59, Mark Shuttleworth wrote: >> >>> >>> Any recommendations for dealing with those? >>> >> >> Do exec* and friends need to be patched somehow, so that if processes are >> spawned from a classic snap with targets outside snapd containment then the >> environment is cleaned? >> >> I think this will affect all classic snaps that need to run subprocesses, >> such as screen, vim, tmux... with other wrapper variables like the LD_* >> settings leaking :-( >> >> >> -- >> Stuart Bishop >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/snapcraft >> >> > > > -- > > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing 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 alejandro.cura at canonical.com Tue Jan 24 19:30:35 2017 From: alejandro.cura at canonical.com (Alejandro J. Cura) Date: Tue, 24 Jan 2017 16:30:35 -0300 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: <1485250565.4288.98.camel@ubuntu.com> References: <1484755177.4288.19.camel@ubuntu.com> <1485250565.4288.98.camel@ubuntu.com> Message-ID: After installing with --devmode the very latest mir-kiosk that Albert just uploaded to the store in edge, and then reinstalling mir-kiosk-apps with devmode as well, I've got it all running on a raspi2. alecu at localhost:~$ snap list Name Version Rev Developer Notes core 16.04.1 976 canonical - mir-kiosk 0.1 22 canonical devmode mir-kiosk-apps 0.1 11 canonical devmode mir-libs 0.1 20 canonical devmode pi2 16.04-0.17 36 canonical - pi2-kernel 4.4.0-1040-47 26 canonical - alecu at localhost:~$ snap interfaces | grep mir :network mir-kiosk-apps :opengl mir-kiosk,mir-kiosk-apps mir-kiosk:mir mir-kiosk-apps mir-libs:mir-libs mir-kiosk,mir-kiosk-apps alecu at localhost:~$ I'll give it a try on the raspi3 now. big thanks to Ogra and Albert that helped me debug this on #snappy. cheers, -- alecu On Tue, Jan 24, 2017 at 6:36 AM, Oliver Grawert wrote: > hi, > Am Montag, den 23.01.2017, 17:53 -0300 schrieb Alejandro J. Cura: > > > > ... > > Any ideas on what I should try, or how to further debug this? I can > > upload the crash report if it helps. > > first of all make sure to only use the very latest daily edge image > (url is in my original mail, the setup only works with the right gadget > and kernel, they need to be in sync). > > all issues with mir were fixed with the most recent mir-kiosk snap so > you can just snap install them from the store from the edge channel (i > just tested them on two fresh installs on the pi2 and 3) ... > > there is however the content sharing interface involved in using the > mir-libs which still has issues, make sure you did the > disable/disconnect/connect/enable dance described on the mir wiki > > the least you should get is a black screen with a mouse cursor right > after (well about 15-30 sec after) boot ... it definitely works for me > on both test boards. > > 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 alejandro.cura at canonical.com Tue Jan 24 19:34:44 2017 From: alejandro.cura at canonical.com (Alejandro J. Cura) Date: Tue, 24 Jan 2017 16:34:44 -0300 Subject: devmode flag disappears after disabling+re-enabling a snap Message-ID: Is that the expected behavior? alecu at localhost:~$ snap list Name Version Rev Developer Notes core 16.04.1 976 canonical - mir-kiosk 0.1 22 canonical devmode mir-kiosk-apps 0.1 11 canonical devmode mir-libs 0.1 20 canonical devmode pi2 16.04-0.17 36 canonical - pi2-kernel 4.4.0-1040-47 26 canonical - alecu at localhost:~$ snap disable mir-kiosk-apps mir-kiosk-apps disabled alecu at localhost:~$ snap enable mir-kiosk-apps mir-kiosk-apps enabled alecu at localhost:~$ snap list Name Version Rev Developer Notes core 16.04.1 976 canonical - mir-kiosk 0.1 22 canonical devmode mir-kiosk-apps 0.1 11 canonical - mir-libs 0.1 20 canonical devmode pi2 16.04-0.17 36 canonical - pi2-kernel 4.4.0-1040-47 26 canonical - alecu at localhost:~$ cheers, -- alecu -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Tue Jan 24 19:49:10 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 24 Jan 2017 11:49:10 -0800 Subject: devmode flag disappears after disabling+re-enabling a snap In-Reply-To: References: Message-ID: <1f1e3f0e-edae-b36d-3e46-9b5b63072765@canonical.com> On 01/24/2017 11:34 AM, Alejandro J. Cura wrote: > Is that the expected behavior? > > alecu at localhost:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 976 canonical - > mir-kiosk 0.1 22 canonical devmode > mir-kiosk-apps 0.1 11 canonical devmode > mir-libs 0.1 20 canonical devmode > pi2 16.04-0.17 36 canonical - > pi2-kernel 4.4.0-1040-47 26 canonical - > alecu at localhost:~$ snap disable mir-kiosk-apps > mir-kiosk-apps disabled > alecu at localhost:~$ snap enable mir-kiosk-apps > mir-kiosk-apps enabled > alecu at localhost:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 976 canonical - > mir-kiosk 0.1 22 canonical devmode > mir-kiosk-apps 0.1 11 canonical - > mir-libs 0.1 20 canonical devmode > pi2 16.04-0.17 36 canonical - > pi2-kernel 4.4.0-1040-47 26 canonical - > alecu at localhost:~$ Well that's interesting. Does it stop working at that point, or is it still actually in devmode? -- 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 alejandro.cura at canonical.com Tue Jan 24 19:56:51 2017 From: alejandro.cura at canonical.com (Alejandro J. Cura) Date: Tue, 24 Jan 2017 16:56:51 -0300 Subject: devmode flag disappears after disabling+re-enabling a snap In-Reply-To: <1f1e3f0e-edae-b36d-3e46-9b5b63072765@canonical.com> References: <1f1e3f0e-edae-b36d-3e46-9b5b63072765@canonical.com> Message-ID: On Tue, Jan 24, 2017 at 4:49 PM, Kyle Fazzari wrote: > > On 01/24/2017 11:34 AM, Alejandro J. Cura wrote: > > Is that the expected behavior? > > > > alecu at localhost:~$ snap list > > Name Version Rev Developer Notes > > core 16.04.1 976 canonical - > > mir-kiosk 0.1 22 canonical devmode > > mir-kiosk-apps 0.1 11 canonical devmode > > mir-libs 0.1 20 canonical devmode > > pi2 16.04-0.17 36 canonical - > > pi2-kernel 4.4.0-1040-47 26 canonical - > > alecu at localhost:~$ snap disable mir-kiosk-apps > > mir-kiosk-apps disabled > > alecu at localhost:~$ snap enable mir-kiosk-apps > > mir-kiosk-apps enabled > > alecu at localhost:~$ snap list > > Name Version Rev Developer Notes > > core 16.04.1 976 canonical - > > mir-kiosk 0.1 22 canonical devmode > > mir-kiosk-apps 0.1 11 canonical - > > mir-libs 0.1 20 canonical devmode > > pi2 16.04-0.17 36 canonical - > > pi2-kernel 4.4.0-1040-47 26 canonical - > > alecu at localhost:~$ > > Well that's interesting. Does it stop working at that point, or is it > still actually in devmode? How can I tell exactly? mir-kiosk-apps still works after that, and I think it was devmode that fixed it, so it seems to be in devmode still. cheers, -- alecu From kyle.fazzari at canonical.com Tue Jan 24 20:06:42 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 24 Jan 2017 12:06:42 -0800 Subject: devmode flag disappears after disabling+re-enabling a snap In-Reply-To: References: <1f1e3f0e-edae-b36d-3e46-9b5b63072765@canonical.com> Message-ID: <43cc05dd-97c1-47e5-99d3-5a022b9b44ce@canonical.com> On 01/24/2017 11:56 AM, Alejandro J. Cura wrote: > On Tue, Jan 24, 2017 at 4:49 PM, Kyle Fazzari > wrote: >> >> On 01/24/2017 11:34 AM, Alejandro J. Cura wrote: >>> Is that the expected behavior? >>> >>> alecu at localhost:~$ snap list >>> Name Version Rev Developer Notes >>> core 16.04.1 976 canonical - >>> mir-kiosk 0.1 22 canonical devmode >>> mir-kiosk-apps 0.1 11 canonical devmode >>> mir-libs 0.1 20 canonical devmode >>> pi2 16.04-0.17 36 canonical - >>> pi2-kernel 4.4.0-1040-47 26 canonical - >>> alecu at localhost:~$ snap disable mir-kiosk-apps >>> mir-kiosk-apps disabled >>> alecu at localhost:~$ snap enable mir-kiosk-apps >>> mir-kiosk-apps enabled >>> alecu at localhost:~$ snap list >>> Name Version Rev Developer Notes >>> core 16.04.1 976 canonical - >>> mir-kiosk 0.1 22 canonical devmode >>> mir-kiosk-apps 0.1 11 canonical - >>> mir-libs 0.1 20 canonical devmode >>> pi2 16.04-0.17 36 canonical - >>> pi2-kernel 4.4.0-1040-47 26 canonical - >>> alecu at localhost:~$ >> >> Well that's interesting. Does it stop working at that point, or is it >> still actually in devmode? > > How can I tell exactly? > mir-kiosk-apps still works after that, and I think it was devmode that > fixed it, so it seems to be in devmode still. Yeah I was assuming it required devmode to work. I suspect this is not desired behavior; it would probably be worth logging a bug. -- 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 alejandro.cura at canonical.com Tue Jan 24 20:11:02 2017 From: alejandro.cura at canonical.com (Alejandro J. Cura) Date: Tue, 24 Jan 2017 17:11:02 -0300 Subject: Pi2 and 3 image improvements (GLES, GPIO) In-Reply-To: References: <1484755177.4288.19.camel@ubuntu.com> <1485250565.4288.98.camel@ubuntu.com> Message-ID: It's all working perfectly on the raspi3, both with an hdmi monitor plus a mouse, and with the original raspberry pi 7" touchscreen. thanks again! -- alecu On Tue, Jan 24, 2017 at 4:30 PM, Alejandro J. Cura wrote: > After installing with --devmode the very latest mir-kiosk that Albert just > uploaded to the store in edge, and then reinstalling mir-kiosk-apps with > devmode as well, I've got it all running on a raspi2. > alecu at localhost:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 976 canonical - > mir-kiosk 0.1 22 canonical devmode > mir-kiosk-apps 0.1 11 canonical devmode > mir-libs 0.1 20 canonical devmode > pi2 16.04-0.17 36 canonical - > pi2-kernel 4.4.0-1040-47 26 canonical - > alecu at localhost:~$ snap interfaces | grep mir > :network mir-kiosk-apps > :opengl mir-kiosk,mir-kiosk-apps > mir-kiosk:mir mir-kiosk-apps > mir-libs:mir-libs mir-kiosk,mir-kiosk-apps > alecu at localhost:~$ > > I'll give it a try on the raspi3 now. > > big thanks to Ogra and Albert that helped me debug this on #snappy. > > cheers, > -- > alecu > > On Tue, Jan 24, 2017 at 6:36 AM, Oliver Grawert wrote: >> >> hi, >> Am Montag, den 23.01.2017, 17:53 -0300 schrieb Alejandro J. Cura: >> > >> > ... >> > Any ideas on what I should try, or how to further debug this? I can >> > upload the crash report if it helps. >> >> first of all make sure to only use the very latest daily edge image >> (url is in my original mail, the setup only works with the right gadget >> and kernel, they need to be in sync). >> >> all issues with mir were fixed with the most recent mir-kiosk snap so >> you can just snap install them from the store from the edge channel (i >> just tested them on two fresh installs on the pi2 and 3) ... >> >> there is however the content sharing interface involved in using the >> mir-libs which still has issues, make sure you did the >> disable/disconnect/connect/enable dance described on the mir wiki >> >> the least you should get is a black screen with a mouse cursor right >> after (well about 15-30 sec after) boot ... it definitely works for me >> on both test boards. >> >> ciao >> oli >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > From gustavo.niemeyer at canonical.com Tue Jan 24 20:34:39 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 24 Jan 2017 18:34:39 -0200 Subject: devmode flag disappears after disabling+re-enabling a snap In-Reply-To: References: Message-ID: Definitely a bug. Thanks for reporting it. On Jan 24, 2017 5:35 PM, "Alejandro J. Cura" wrote: > Is that the expected behavior? > > alecu at localhost:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 976 canonical - > mir-kiosk 0.1 22 canonical devmode > mir-kiosk-apps 0.1 11 canonical devmode > mir-libs 0.1 20 canonical devmode > pi2 16.04-0.17 36 canonical - > pi2-kernel 4.4.0-1040-47 26 canonical - > alecu at localhost:~$ snap disable mir-kiosk-apps > mir-kiosk-apps disabled > alecu at localhost:~$ snap enable mir-kiosk-apps > mir-kiosk-apps enabled > alecu at localhost:~$ snap list > Name Version Rev Developer Notes > core 16.04.1 976 canonical - > mir-kiosk 0.1 22 canonical devmode > mir-kiosk-apps 0.1 11 canonical - > mir-libs 0.1 20 canonical devmode > pi2 16.04-0.17 36 canonical - > pi2-kernel 4.4.0-1040-47 26 canonical - > alecu at localhost:~$ > > cheers, > -- > alecu > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Tue Jan 24 22:02:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 24 Jan 2017 22:02:00 +0000 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: On Wed, 25 Jan 2017 08:17:17 +1300, Michael Hudson-Doyle wrote: > Hm, I was assuming that the PYTHONHOME leaking was due to things in the > snap specifically (is the source to the snap available?), but are they set > by snapd or snap-confine or something? Might be easier to follow in the bug Dave logged and linked to earlier, but in a nutshell: snapcraft sets up a couple of variables to get things going. There seems to be conflicts with classic systems but are only viewable now with trusty enablement. I am guessing the snapcraft.yaml for this looks like parts: asciinema: plugin: python python-packages: [asciinema] I've added python3 as a part and did some environment tweaks locally and it works like a charm. -- Sent using Dekko from my Ubuntu device From michael.hudson at canonical.com Tue Jan 24 22:28:30 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Wed, 25 Jan 2017 11:28:30 +1300 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: On 25 January 2017 at 11:02, Sergio Schvezov wrote: > On Wed, 25 Jan 2017 08:17:17 +1300, Michael Hudson-Doyle wrote: > > Hm, I was assuming that the PYTHONHOME leaking was due to things in the > > snap specifically (is the source to the snap available?), but are they > set > > by snapd or snap-confine or something? > > Might be easier to follow in the bug Dave logged and linked to earlier, > but in a nutshell: snapcraft sets up a couple of variables to get things > going. There seems to be conflicts with classic systems but are only > viewable now with trusty enablement. > Well no, what I am complaining about is something perhaps related to that bug but not the same. > I am guessing the snapcraft.yaml for this looks like > > parts: > asciinema: > plugin: python > python-packages: [asciinema] > > I've added python3 as a part and did some environment tweaks locally and > it works like a charm. > But if you did that, PYTHONHOME is presumably still set in the environment of the command you are recording with asciinema. I was trying to record me using a new widget in a program using urwid and getting this sort of thing: mwhudson at aeglos:/opt/opensource$ asciinema rec -c 'python3 urwid/examples/pop_up.py ' ~ Asciicast recording started. ~ Hit Ctrl-D or type "exit" to finish. Traceback (most recent call last): File "urwid/examples/pop_up.py", line 3, in import urwid ImportError: No module named 'urwid' ~ Asciicast recording finished. ~ Press to upload, to cancel. You have to do this "asciinema rec -c 'PYTHONHOME=/usr python3 urwid/examples/pop_up.py '" instead (and even that ends up using python3 from the core snap, not the one I have installed). Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.hudson at canonical.com Tue Jan 24 22:33:40 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Wed, 25 Jan 2017 11:33:40 +1300 Subject: Please test my asciinema snap In-Reply-To: References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> Message-ID: On 25 January 2017 at 11:28, Michael Hudson-Doyle < michael.hudson at canonical.com> wrote: > > You have to do this "asciinema rec -c 'PYTHONHOME=/usr python3 > urwid/examples/pop_up.py '" instead (and even that ends up using python3 > from the core snap, not the one I have installed). > More generally, classic snaps introduce the potential for confusion between the "snap world" and the "classic world". When poking about the filesystem, this isn't so bad because we have the classic world at / but when it comes to process state, I expect the process launched by asciinema to be in the classic world, and the environment variables mean it isn't, quite. I guess this is what Stuart was getting at when he talked about patching the exec* syscalls (can you use seccomp-bpf to unset an environment var if the executable being launched comes from a path other than /snap? Sounds pretty hair-raising). Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From elfgoh at yahoo.com Tue Jan 24 23:53:42 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 24 Jan 2017 23:53:42 +0000 (UTC) Subject: Relationship between snaps and containers, if any References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> Message-ID: <1212848131.76057.1485302022332@mail.yahoo.com> I seek clarity in understanding how docker containers are different from snaps. The question originated as I pondered if docker containers are the equivalent of snaps. Is there a blog post or FAQ somewhere that already addresses this? I also read this article[1], though dated, mentions docker support in Snappy, which makes me wonder: - the scenarios that I would want to deploy docker containers alongside snaps - snapping a docker container. Appreciate if someone can enlighten me. Thanks. -- Luther [1] http://thenewstack.io/snappy-ubuntu-a-new-cloud-os-with-support-for-docker-in-a-post-shellshock-era/ From elfgoh at yahoo.com Tue Jan 24 23:59:28 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Tue, 24 Jan 2017 23:59:28 +0000 (UTC) Subject: Snap install issues upon hard kill with Ctrl + c References: <207031955.94668.1485302368207.ref@mail.yahoo.com> Message-ID: <207031955.94668.1485302368207@mail.yahoo.com> I encountered an issue when I did a ctrl + c as snap was installing my helloworld snap. Essentially, I am unable to resume an install, or do any other snap installs. Is there any known way to resolve this should I encounter it again in future? This occured on Debian. I had to do an uninstall + reinstall of snapd. But even that failed. It only succeeded after I removed /var/lib/snap after uninstall, before the reinstallation step. -- Luther ================== [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:44:33 PM # snap install ./hello_2.10_armhf.snap --dangerous ubuntu-core 6.11 MB / 64.41 MB [=======>-----------------------------------------------------------------------] 9.48% 434.74 KB/s 2m17s^C [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:14 PM # snap list No snaps are installed yet. Try "snap install hello-world". [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:16 PM # snap install ./hello_2.10_armhf.snap --dangerous error: cannot install snap file: Get https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=stable&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:31 PM # snap install ./hello_2.10_armhf.snap --dangerous error: cannot install snap file: snap "ubuntu-core" has changes in progress From kyle.fazzari at canonical.com Wed Jan 25 00:12:03 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 24 Jan 2017 16:12:03 -0800 Subject: Snap install issues upon hard kill with Ctrl + c In-Reply-To: <207031955.94668.1485302368207@mail.yahoo.com> References: <207031955.94668.1485302368207.ref@mail.yahoo.com> <207031955.94668.1485302368207@mail.yahoo.com> Message-ID: <9f3af5b4-5ba7-315e-9dcb-22a4de91b6b8@canonical.com> On 01/24/2017 03:59 PM, Luther Goh Lu Feng wrote: > I encountered an issue when I did a ctrl + c as snap was installing my helloworld snap. Essentially, I am unable to resume an install, or do any other snap installs. Is there any known way to resolve this should I encounter it again in future? > > This occured on Debian. I had to do an uninstall + reinstall of snapd. But even that failed. It only succeeded after I removed /var/lib/snap after uninstall, before the reinstallation step. > > -- Luther > > > ================== > > [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:44:33 PM > # snap install ./hello_2.10_armhf.snap --dangerous > ubuntu-core 6.11 MB / 64.41 MB [=======>-----------------------------------------------------------------------] 9.48% 434.74 KB/s 2m17s^C > [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:14 PM > # snap list > No snaps are installed yet. Try "snap install hello-world". > [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:16 PM > # snap install ./hello_2.10_armhf.snap --dangerous > error: cannot install snap file: Get https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=stable&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) > [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:31 PM > # snap install ./hello_2.10_armhf.snap --dangerous > error: cannot install snap file: snap "ubuntu-core" has changes in progress > tl;dr this is a known bug: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1596077 A decent explanation of the issue is here if you're curious: https://askubuntu.com/questions/790969/how-do-i-remove-an-incomplete-or-broken-snap-installation-of-nextcloud-on-a-rasp/790975 -- 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 gareth.france at cliftonts.co.uk Wed Jan 25 08:43:25 2017 From: gareth.france at cliftonts.co.uk (gareth.france at cliftonts.co.uk) Date: Wed, 25 Jan 2017 08:43:25 +0000 Subject: Yet more issues snapping In-Reply-To: References: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> <46eecfb7d8f858c82faed620d7994bcc@cliftonts.co.uk> Message-ID: <19b00cc53e56b67303ac253878c49601@cliftonts.co.uk> On 2017-01-23 21:44, Leo Arias wrote: > On Wed, Jan 18, 2017 at 2:53 AM, > wrote: > It is ok now thank you. I have had some excellent help and can use what > I > now have to aid me going forward. It is those first few steps that seem > impossible. > > Hey Gareth, I'm happy to see you got it working. > > It would be really useful if you could help us improving the > documentation from the things you learned these past weeks. Maybe some > of the text should be clearer, or a few things are missing an > explanation. We happily accept pull requests for the docs in > https://github.com/snapcore/snapcraft/tree/master/docs, and another > useful resource is to answer your own questions in askubuntu.com once > you know the answer. > > pura vida. > -- > ¡paz y baile! > http://www.ubuntu.com Hi, Thanks for suggesting this, however the problem is that I really don't understand anything still. I should explain I'm dyspraxic and so I have my own methods for learning which work for me and I often find the way this stuff is presented is just a struggle for me. Some very helpful people have helped me package 2 python scripts, one terminal based and one gtk so on a basic level I can now do that. However I am able to include packages in the gtk version but not in the terminal version due to the way the snapcraft.yaml is layed out. I need to add one but don't know enough yet to modify the file and nobody has yet stepped forward to provide the answer. I work far better through the doing rather than tons of reading and given a little more help will start to have an understanding of the methods but I'm not quite there yet. So although I'd love to identify some ways to improve the documentation I really can't until I know the answers myself. Gareth From pawel.stolowski at canonical.com Wed Jan 25 09:09:56 2017 From: pawel.stolowski at canonical.com (Pawel Stolowski) Date: Wed, 25 Jan 2017 10:09:56 +0100 Subject: Snap install issues upon hard kill with Ctrl + c In-Reply-To: <9f3af5b4-5ba7-315e-9dcb-22a4de91b6b8@canonical.com> References: <207031955.94668.1485302368207.ref@mail.yahoo.com> <207031955.94668.1485302368207@mail.yahoo.com> <9f3af5b4-5ba7-315e-9dcb-22a4de91b6b8@canonical.com> Message-ID: Hi, The ctrl+c behavior (bug #1596077 mentioned by Kyle) on snap install was fixed in December and released shortly afterwards, at least in Ubuntu. The current version of snapd (2.20.1) in ubuntu should work - hitting ctrl+c now aborts the installation as expected: $ sudo snap install mongo33 mongo33 2.84 MB / 93.59 MB [====>------------------------------------------------------------------------------------------------------------------------------------------------------------] 3.04% 4.73 MB/s 19serror: cannot perform the following tasks: - Download snap "mongo33" (2) from channel "stable" (net/http: request canceled) Cheers, Pawel On 25.01.2017 01:12, Kyle Fazzari wrote: > > On 01/24/2017 03:59 PM, Luther Goh Lu Feng wrote: >> I encountered an issue when I did a ctrl + c as snap was installing my helloworld snap. Essentially, I am unable to resume an install, or do any other snap installs. Is there any known way to resolve this should I encounter it again in future? >> >> This occured on Debian. I had to do an uninstall + reinstall of snapd. But even that failed. It only succeeded after I removed /var/lib/snap after uninstall, before the reinstallation step. >> >> -- Luther >> >> >> ================== >> >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:44:33 PM >> # snap install ./hello_2.10_armhf.snap --dangerous >> ubuntu-core 6.11 MB / 64.41 MB [=======>-----------------------------------------------------------------------] 9.48% 434.74 KB/s 2m17s^C >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:14 PM >> # snap list >> No snaps are installed yet. Try "snap install hello-world". >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:16 PM >> # snap install ./hello_2.10_armhf.snap --dangerous >> error: cannot install snap file: Get https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=stable&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:31 PM >> # snap install ./hello_2.10_armhf.snap --dangerous >> error: cannot install snap file: snap "ubuntu-core" has changes in progress >> > tl;dr this is a known bug: > > https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1596077 > > A decent explanation of the issue is here if you're curious: > > > https://askubuntu.com/questions/790969/how-do-i-remove-an-incomplete-or-broken-snap-installation-of-nextcloud-on-a-rasp/790975 > > > From elfgoh at yahoo.com Wed Jan 25 09:22:49 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Wed, 25 Jan 2017 09:22:49 +0000 (UTC) Subject: Snap install issues upon hard kill with Ctrl + c In-Reply-To: References: <207031955.94668.1485302368207.ref@mail.yahoo.com> <207031955.94668.1485302368207@mail.yahoo.com> <9f3af5b4-5ba7-315e-9dcb-22a4de91b6b8@canonical.com> Message-ID: <2025332487.352863.1485336169756@mail.yahoo.com> Indeed, the issue is resolved with a more updated version of snapd. Thanks! -- Luther On Wednesday, January 25, 2017 5:10 PM, Pawel Stolowski wrote: Hi, The ctrl+c behavior (bug #1596077 mentioned by Kyle) on snap install was fixed in December and released shortly afterwards, at least in Ubuntu. The current version of snapd (2.20.1) in ubuntu should work - hitting ctrl+c now aborts the installation as expected: $ sudo snap install mongo33 mongo33 2.84 MB / 93.59 MB [====>------------------------------------------------------------------------------------------------------------------------------------------------------------] 3.04% 4.73 MB/s 19serror: cannot perform the following tasks: - Download snap "mongo33" (2) from channel "stable" (net/http: request canceled) Cheers, Pawel On 25.01.2017 01:12, Kyle Fazzari wrote: > > On 01/24/2017 03:59 PM, Luther Goh Lu Feng wrote: >> I encountered an issue when I did a ctrl + c as snap was installing my helloworld snap. Essentially, I am unable to resume an install, or do any other snap installs. Is there any known way to resolve this should I encounter it again in future? >> >> This occured on Debian. I had to do an uninstall + reinstall of snapd. But even that failed. It only succeeded after I removed /var/lib/snap after uninstall, before the reinstallation step. >> >> -- Luther >> >> >> ================== >> >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:44:33 PM >> # snap install ./hello_2.10_armhf.snap --dangerous >> ubuntu-core 6.11 MB / 64.41 MB [=======>-----------------------------------------------------------------------] 9.48% 434.74 KB/s 2m17s^C >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:14 PM >> # snap list >> No snaps are installed yet. Try "snap install hello-world". >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:16 PM >> # snap install ./hello_2.10_armhf.snap --dangerous >> error: cannot install snap file: Get https://search.apps.ubuntu.com/api/v1/snaps/details/ubuntu-core?channel=stable&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) >> [foo at beaglebone ~/snappy/dockerbuild/snap2] Tue 24 Jan 2017 12:45:31 PM >> # snap install ./hello_2.10_armhf.snap --dangerous >> error: cannot install snap file: snap "ubuntu-core" has changes in progress >> > tl;dr this is a known bug: > > https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1596077 > > A decent explanation of the issue is here if you're curious: > > > https://askubuntu.com/questions/790969/how-do-i-remove-an-incomplete-or-broken-snap-installation-of-nextcloud-on-a-rasp/790975 > > > -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From loic.minier at ubuntu.com Wed Jan 25 11:32:18 2017 From: loic.minier at ubuntu.com (=?UTF-8?B?TG/Dr2MgTWluaWVy?=) Date: Wed, 25 Jan 2017 12:32:18 +0100 Subject: Relationship between snaps and containers, if any In-Reply-To: <1212848131.76057.1485302022332@mail.yahoo.com> References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> Message-ID: Hi Luther! Docker containers and snaps are different but sometimes overlap in solving certain classes of technical problems. For instance, "software distribution" as a broad problem is addressed by both snaps and Docker containers, but with very different implementations. First of all, yes you can run Docker on top of an all-snaps system such as Ubuntu Core, and the Docker snap will also give you a Docker engine runtime on Ubuntu classic. Docker containers and snaps are built on different goals. Snaps will typically look and feel like system or user apps running directly on your regular system: you see them in the process list, they see each other if the sandboxing allows it, they may interact with the screen/USB devices/whatever if permissions allow it etc.. Docker containers feel more like very efficient virtual machines that you connect to, they allow for sandboxing as well – where the whole container is sandboxed – and for resource quotas. On your question of snapping a docker container: yes, you would be able to wrap a Docker image inside a snap which would be a client of the Docker snap. On the top of my head, I can personally think of two main cases where you would want to run containers on top of an all snap system: when your workload is already packaged as a container, or when you want to use the resource limits featured in Docker or LXD (e.g. limit network usage, CPU usage etc.). Cheers, - Loïc Minier On Wed, Jan 25, 2017 at 12:53 AM, Luther Goh Lu Feng wrote: > I seek clarity in understanding how docker containers are different from > snaps. The question originated as I pondered if docker containers are the > equivalent of snaps. Is there a blog post or FAQ somewhere that already > addresses this? > > > I also read this article[1], though dated, mentions docker support in > Snappy, which makes me wonder: > > - the scenarios that I would want to deploy docker containers alongside > snaps > - snapping a docker container. > > Appreciate if someone can enlighten me. Thanks. > > > -- Luther > [1] http://thenewstack.io/snappy-ubuntu-a-new-cloud-os-with- > support-for-docker-in-a-post-shellshock-era/ > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- - Loïc -------------- next part -------------- An HTML attachment was scrubbed... URL: From n13m3y3r at gmail.com Mon Jan 23 22:04:47 2017 From: n13m3y3r at gmail.com (Gustavo Niemeyer) Date: Mon, 23 Jan 2017 20:04:47 -0200 Subject: Configuring snapd on ubuntu core for a web proxy In-Reply-To: References: Message-ID: *the local snapd On Jan 23, 2017 8:04 PM, "Gustavo Niemeyer" wrote: > Indeed, that smells like a bug, certainly because snap download doesn't > use the local snaps to actually download the file. That should be > transparent to the CLI though. > > Can you please file an issue? > > Thanks! > > On Jan 23, 2017 5:26 PM, "Max Brustkern" > wrote: > >> Okay, you're right. I was testing with snap download, which doesn't seem >> to use to proxy, whereas snap refresh does. Is that intended behavior, or >> should I report it somewhere? >> >> Thanks, >> Max >> >> On Mon, Jan 23, 2017 at 2:04 PM, Gustavo Niemeyer < >> gustavo.niemeyer at canonical.com> wrote: >> >>> This should work fine across reboots. >>> >>> On Jan 23, 2017 4:49 PM, "Max Brustkern" >>> wrote: >>> >>>> So I've been able to get it to work by creating >>>> /etc/systemd/system/snapd.service.d/proxy.conf >>>> with the correct settings. Any suggestions on getting that to persist >>>> across reboots? >>>> >>>> Thanks, >>>> Max >>>> >>>> On Thu, Jan 12, 2017 at 2:28 PM, Michael Hudson-Doyle < >>>> michael.hudson at canonical.com> wrote: >>>> >>>>> >>>>> >>>>> On 13 January 2017 at 08:14, Max Brustkern < >>>>> max.brustkern at canonical.com> wrote: >>>>> >>>>>> So I created a system directory with the contents of >>>>>> /lib/systemd/system. I edited that file to contain the environment >>>>>> variables: >>>>>> nuclearbob at localhost:~$ cat /lib/systemd/system/snapd.service >>>>>> [Unit] >>>>>> Description=Snappy daemon >>>>>> Requires=snapd.socket >>>>>> >>>>>> [Service] >>>>>> ExecStart=/usr/lib/snapd/snapd >>>>>> EnvironmentFile=/etc/environment >>>>>> Restart=always >>>>>> http_proxy=http://squid.internal:3128 >>>>>> https_proxy=https://squid.internal:3128 >>>>>> >>>>> >>>>> That's not the right syntax, it should be >>>>> >>>>> Environment=http_proxy=http://squid.internal:3128 https_proxy= >>>>> https://squid.internal:3128 >>>>> >>>>> See man systemd.exec for more details on this. >>>>> >>>>> Cheers, >>>>> mwh >>>>> >>>>> >>>>>> [Install] >>>>>> WantedBy=multi-user.target >>>>>> >>>>>> I then did: >>>>>> nuclearbob at localhost:~$ sudo systemctl daemon-reload >>>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>>> >>>>>> I still don't seem to see snapd picking up on the proxy. I tried: >>>>>> sudo systemctl edit snapd >>>>>> I pasted in the file contents to there, but after that I get: >>>>>> nuclearbob at localhost:~$ sudo service snapd restart >>>>>> Failed to restart snapd.service: Unit snapd.service is not loaded >>>>>> properly: Invalid argument. >>>>>> See system logs and 'systemctl status snapd.service' for details. >>>>>> nuclearbob at localhost:~$ systemctl status snapd.service >>>>>> ● snapd.service - Snappy daemon >>>>>> Loaded: error (Reason: Invalid argument) >>>>>> Drop-In: /etc/systemd/system/snapd.service.d >>>>>> └─override.conf >>>>>> Active: active (running) since Thu 2017-01-12 19:11:46 UTC; 2min >>>>>> 26s ago >>>>>> Main PID: 1339 (snapd) >>>>>> CGroup: /system.slice/snapd.service >>>>>> └─1339 /usr/lib/snapd/snapd >>>>>> >>>>>> Any additional tips to get snapd running on ubuntu core in the lab? >>>>>> >>>>>> On Wed, Jan 11, 2017 at 11:49 PM, Stuart Bishop < >>>>>> stuart.bishop at canonical.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 12 January 2017 at 01:44, Max Brustkern < >>>>>>> max.brustkern at canonical.com> wrote: >>>>>>> >>>>>>>> I'm trying to run ubuntu core 16 in a kvm instance in an internal >>>>>>>> lab that requires a web proxy. This bug: >>>>>>>> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1579652 >>>>>>>> seems to cover how to do this on classic ubuntu, but the files that >>>>>>>> hold the environment variables used by snapd on an ubuntu core system are >>>>>>>> all on read-only filesystems. How do I set HTTPS_PROXY in a persistent way >>>>>>>> for snapd on that system? >>>>>>>> >>>>>>> >>>>>>> https://bugs.launchpad.net/snappy/+bug/1533899 is similar, but >>>>>>> about adding support for proxies to snapd (rather than have it use the >>>>>>> system environment variables, which is one implementation option but not >>>>>>> always what you want since that affects everything on the system). But that >>>>>>> doesn't help with your read-only filesystem sorry :-( >>>>>>> >>>>>>> (Hmm... disgusting hack idea.... since you can't create >>>>>>> /etc/systemd/system/snapd.service.d/ on your read-only filesystem, >>>>>>> try mounting that directory from somewhere. Extra points for using systemd >>>>>>> to mount the systemd service file overrides and setting up dependencies so >>>>>>> it does everything in the right order :-) ) >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Stuart Bishop >>>>>>> >>>>>>> -- >>>>>>> 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/mailm >>>>>> an/listinfo/snapcraft >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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/mailm >>>> an/listinfo/snapcraft >>>> >>>> >>> -- >>> 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/mailm >> an/listinfo/snapcraft >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Wed Jan 25 13:51:29 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Wed, 25 Jan 2017 13:51:29 +0000 Subject: Relationship between snaps and containers, if any In-Reply-To: References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> Message-ID: The best way to think of this is to know that snaps are GREAT when you have a precise 1:1 relationship between "machines" and "running instances". And Docker is GREAT when you want an elastic relationship. So for example, if you want a MySQL "appliance" on a device, there will only ever be 1 MySQL instance on that device, you want a snap. If you want a cluster where there may be 1-many instances of MySQl on each actual machine or VM, then you want Docker. The reason for this is that Docker gives each running process its own IP address. That's perfect for the hyper-elastic case - each extra MySQSL is just another IP address to talk to. But if you have a machine where you already have an IP address and all you want is a MySQL there then a snap will be easier. This is why a snap of the Docker daemon makes such sense - in your cluster, you want exactly one copy of Docker itself running on each machine, and that is best pulled in as a snap. That docker process then manages an arbitrary number of docker processes on each machine. Make sense? Mark From jamie at canonical.com Wed Jan 25 14:11:28 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 25 Jan 2017 08:11:28 -0600 Subject: DHCP and /etc/resolv.conf In-Reply-To: References: Message-ID: <1485353488.10013.2.camel@canonical.com> On Mon, 2017-01-16 at 21:39 +0000, Joe Coates wrote: > I'm snapping an app which includes a DHCP client replacement.   Ultimately it > wants to update/replace /etc/resolv.conf.     My snap is connected to all the > "network" interfaces available in my ubuntu-core, but none seem to allow write > access to this file.  Shouldn't an interface like "network-control" allow > write access to /etc/resolv.conf ? > FYI, this is merged in master and the upcoming snapd 2.22 will allow access to resolvconf. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Wed Jan 25 14:13:05 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 25 Jan 2017 12:13:05 -0200 Subject: Relationship between snaps and containers, if any In-Reply-To: References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> Message-ID: Interesting.. I actually don't see that line between snaps and Docker. Just like you can run "docker run mysql" several times, one may run "mysnap.mysql" several times. In both cases the daemon will be visible to the external world via a separate port of the local host's public IP address. In both cases mysql will be isolated from the local environment by confinement. It's even a bit more convenient to do that using a snap. Easier to manage the process on a systemd unit, for example, since the mysql process will indeed be a child of systemd/etc instead of a child of the docker daemon. On Wed, Jan 25, 2017 at 11:51 AM, Mark Shuttleworth wrote: > > The best way to think of this is to know that snaps are GREAT when you > have a precise 1:1 relationship between "machines" and "running > instances". And Docker is GREAT when you want an elastic relationship. > So for example, if you want a MySQL "appliance" on a device, there will > only ever be 1 MySQL instance on that device, you want a snap. If you > want a cluster where there may be 1-many instances of MySQl on each > actual machine or VM, then you want Docker. > > The reason for this is that Docker gives each running process its own IP > address. That's perfect for the hyper-elastic case - each extra MySQSL > is just another IP address to talk to. But if you have a machine where > you already have an IP address and all you want is a MySQL there then a > snap will be easier. > > This is why a snap of the Docker daemon makes such sense - in your > cluster, you want exactly one copy of Docker itself running on each > machine, and that is best pulled in as a snap. That docker process then > manages an arbitrary number of docker processes on each machine. > > Make sense? > Mark > > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Wed Jan 25 14:16:44 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 25 Jan 2017 08:16:44 -0600 Subject: Ubuntu Core: how the file-system works In-Reply-To: References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> <1485192527.3222.77.camel@canonical.com> Message-ID: <1485353804.10013.4.camel@canonical.com> On Mon, 2017-01-23 at 21:30 +0100, Luca Dionisi wrote: > On Mon, Jan 23, 2017 at 6:28 PM, Jamie Strandboge wrote: > > > > I will be looking at the security policy side of this so if you can, please > > comment in the bug what specific commands you are using in your snap for > > using > > rt_tables so I can repeat tham and make sure they are supported. > Done. > Thanks! The security policy changes are merged in master and you will be able to manipulate rt_tables by connecting the network-control interface in the upcoming snapd 2.22. -- 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 luca.dionisi at gmail.com Wed Jan 25 14:26:43 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Wed, 25 Jan 2017 15:26:43 +0100 Subject: Ubuntu Core: how the file-system works In-Reply-To: <1485353804.10013.4.camel@canonical.com> References: <1484921654.4288.33.camel@ubuntu.com> <1484924045.4288.46.camel@ubuntu.com> <93fe0eb0-47fa-f6c4-c644-1648b36743d2@ubuntu.com> <1484934185.4288.65.camel@ubuntu.com> <1485173877.4288.70.camel@ubuntu.com> <1485192527.3222.77.camel@canonical.com> <1485353804.10013.4.camel@canonical.com> Message-ID: On Wed, Jan 25, 2017 at 3:16 PM, Jamie Strandboge wrote: > The security policy changes are merged in master and you will be able to > manipulate rt_tables by connecting the network-control interface in the upcoming > snapd 2.22. Wooohooo! From till.kamppeter at gmail.com Wed Jan 25 17:29:54 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 25 Jan 2017 15:29:54 -0200 Subject: CUPS in a snap: avahi-daemon needed Message-ID: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Hi, I am currently snapping CUPS (both for server and for desktop/phone printing needs) and testing it on Ubuntu Core. Here I have found out that there is no avahi-daemon (which CUPS needs for sharing local printers and for discovering remote network printers. Now I want to know what I have to do. Is there already a snap of avahi-daemon? How can I make it a dependency of the CUPS snap? What have I to do with the CUPS snap so that I can actually use the avahi-daemon snap? If there is no avahi-daemon snap, do I need to ship avahi-daemon with the CUPS snap? Is there anyone who needs avahi-daemon for his snap and has solved the problem already? If yes, how? Till From till.kamppeter at gmail.com Wed Jan 25 17:38:24 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 25 Jan 2017 15:38:24 -0200 Subject: CUPS in a snap: Need to create system group "lpadmin" Message-ID: <963c873f-52aa-bbdf-6b80-906caf3b5afc@gmail.com> Hi, I am currently snapping CUPS (both for server and for desktop/phone printing needs) and testing it on Ubuntu Core. Here I have found out that there is no "lpadmin" system group. Now I want to know how to create system groups and users out of a snap, so that they get created on installation and removed on uninstall of the snap (and conserved during an update of the snap). Till From till.kamppeter at gmail.com Wed Jan 25 18:29:04 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 25 Jan 2017 16:29:04 -0200 Subject: CUPS in a snap: Using content interface to connect printer driver snaps Message-ID: Hi, I am currently snapping CUPS (both for server and for desktop/phone printing needs) and testing it on Ubuntu Core. Another reason to put CUPS into a snap is that one could also snap printer drivers to have them in a distribution-independent package format (so that manufacturers need to publish only one driver package, not one per distro) and couple the driver snap to the CUPS snap as a kind of plug-in. As there can be any arbitrary number of different printers connected to one machine running CUPS, it must be possible to connect any combination of driver snaps to the installed CUPS snap, also the CUPS snap should not be required to know which driver snaps exist. Manufacturers should be able to publish a new driver snap at any time and every CUPS snap user should be immediately able to use the new driver snap. Each driver snap should provide files to CUPS, PPDs in some form (PPDs themselves, PPD generator executable, or *.drv file), if needed, driver executable/CUPS filter, and auxiliary files. These files are the plug of each driver snap. So CUPS needs to provide a slot to take these files somehow and this slot needs to accept any printer driver snap and any number of printer driver snaps. Can one do this with the "content" interface? And if yes, how? Till From jim.hodapp at canonical.com Wed Jan 25 18:43:43 2017 From: jim.hodapp at canonical.com (Jim Hodapp) Date: Wed, 25 Jan 2017 13:43:43 -0500 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Message-ID: I'm not exactly sure how functional it is in the snapweb package, but you can see that snapweb does package and use avahi to provide the ability to type a mdns address into a browser to get to the snapweb store by default: https://github.com/snapcore/snapweb On Wed, Jan 25, 2017 at 12:29 PM, Till Kamppeter wrote: > Hi, > > I am currently snapping CUPS (both for server and for desktop/phone > printing needs) and testing it on Ubuntu Core. > > Here I have found out that there is no avahi-daemon (which CUPS needs for > sharing local printers and for discovering remote network printers. > > Now I want to know what I have to do. Is there already a snap of > avahi-daemon? How can I make it a dependency of the CUPS snap? What have I > to do with the CUPS snap so that I can actually use the avahi-daemon snap? > > If there is no avahi-daemon snap, do I need to ship avahi-daemon with the > CUPS snap? > > Is there anyone who needs avahi-daemon for his snap and has solved the > problem already? If yes, how? > > Till > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Wed Jan 25 18:52:44 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 25 Jan 2017 10:52:44 -0800 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Message-ID: <05c1f520-76ab-2346-dbb4-9d02f49465af@canonical.com> Well there's a difference between using avahi and just broadcasting mDNS yourself, which is what I believe snapweb does, correct? On 01/25/2017 10:43 AM, Jim Hodapp wrote: > I'm not exactly sure how functional it is in the snapweb package, but > you can see that snapweb does package and use avahi to provide the > ability to type a mdns address into a browser to get to the snapweb > store by default: > > https://github.com/snapcore/snapweb > > On Wed, Jan 25, 2017 at 12:29 PM, Till Kamppeter > > wrote: > > Hi, > > I am currently snapping CUPS (both for server and for desktop/phone > printing needs) and testing it on Ubuntu Core. > > Here I have found out that there is no avahi-daemon (which CUPS > needs for sharing local printers and for discovering remote network > printers. > > Now I want to know what I have to do. Is there already a snap of > avahi-daemon? How can I make it a dependency of the CUPS snap? What > have I to do with the CUPS snap so that I can actually use the > avahi-daemon snap? > > If there is no avahi-daemon snap, do I need to ship avahi-daemon > with the CUPS snap? > > Is there anyone who needs avahi-daemon for his snap and has solved > the problem already? If yes, how? > > Till > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- 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 till.kamppeter at gmail.com Wed Jan 25 19:00:03 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 25 Jan 2017 17:00:03 -0200 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: <05c1f520-76ab-2346-dbb4-9d02f49465af@canonical.com> References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> <05c1f520-76ab-2346-dbb4-9d02f49465af@canonical.com> Message-ID: On 01/25/2017 04:52 PM, Kyle Fazzari wrote: > Well there's a difference between using avahi and just broadcasting mDNS > yourself, which is what I believe snapweb does, correct? > CUPS is not able to broadcast shared printers by itself. It registers them at avahi-daemon and avahi-daemon broadcasts them. CUPS uses libavahi-common and libavahi-client to communicate with avahi-daemon. cups-browsed also uses avahi-daemon to find mDNS-broadcasted remote printers. cups-browsed uses libavahi-common, libavahi-client, and libavahi-glib to do this. Till From sergio.schvezov at canonical.com Wed Jan 25 19:18:07 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Wed, 25 Jan 2017 19:18:07 +0000 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Message-ID: On Wed, 25 Jan 2017 13:43:43 -0500, Jim Hodapp wrote: > I'm not exactly sure how functional it is in the snapweb package, but you > can see that snapweb does package and use avahi to provide the ability to > type a mdns address into a browser to get to the snapweb store by default: > > https://github.com/snapcore/snapweb snapweb uses a small mdns implementation written in go; avahi is much more than that. That said, the original versions of snapweb, formerlly known as webdm did have a full blown avahi-daemon inside, but it is really cumbersome if not needed. -- Sent using Dekko from my Ubuntu device From till.kamppeter at gmail.com Wed Jan 25 19:30:10 2017 From: till.kamppeter at gmail.com (Till Kamppeter) Date: Wed, 25 Jan 2017 17:30:10 -0200 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Message-ID: On 01/25/2017 05:18 PM, Sergio Schvezov wrote: > snapweb uses a small mdns implementation written in go; avahi is much more than that. > That said, the original versions of snapweb, formerlly known as webdm did have a full blown avahi-daemon inside, but it is really cumbersome if not needed. > Is the old avahi-daemon-using webdm package (source) still publicly available somewhere? Or should we better make a separate avahi-daemon snap so that other services can use it, too (and not end up with two avahi-daemons running in parallel). Till From jamie at canonical.com Wed Jan 25 19:54:55 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Wed, 25 Jan 2017 13:54:55 -0600 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Message-ID: <1485374095.10013.57.camel@canonical.com> On Wed, 2017-01-25 at 15:29 -0200, Till Kamppeter wrote: > Hi, > > I am currently snapping CUPS (both for server and for desktop/phone  > printing needs) and testing it on Ubuntu Core. > > Here I have found out that there is no avahi-daemon (which CUPS needs  > for sharing local printers and for discovering remote network printers. > > Now I want to know what I have to do. Is there already a snap of  > avahi-daemon? I just checked the store: not yet. > How can I make it a dependency of the CUPS snap? Snaps don't have dependencies per se. How it works is through interfaces such that CUPS would say it wants to use avahi and it would be installable only on systems where there the slot is available. I'm not up to date on this, but last I heard the bits about auto-installing slot implementations, recommending what slot to install, blocking when a slot snap isn't installed, etc is not implemented yet, but it will be. > What have  > I to do with the CUPS snap so that I can actually use the avahi-daemon snap? > > If there is no avahi-daemon snap, do I need to ship avahi-daemon with  > the CUPS snap? > > Is there anyone who needs avahi-daemon for his snap and has solved the  > problem already? If yes, how? As mentioned, there isn't an avahi-daemon snap at this time, but I think it would be useful for people generall. What is available is the 'avahi-observe' interface on classic systems. cups- browsed can today 'plugs: [ avahi-observe ]' to find printers on the network via avahi on classic systems. For advertising your printers you would need to create a new interface and to make this work on all-snaps (Ubuntu Core) systems as well as classic. Here is what I suggest:  * first snap avahi-daemon using devmode  * update the avahi-observe interface to be used with your avahi-daemon snap    which will now 'slots: [avahi-observe]' such that people can use 'snap     connect' to connect snaps that 'plugs: [avahi-observe]' to your snap and be     able find services that your snap sees on the network  * create the avahi-advertise interface to be used with your avahi-daemon snap    which will now 'slots: [avahi-advertise]' such that people can use 'snap    connect' to connect snaps that 'plugs: [avahi-advertise]' to your snap and be    able to advertise services via your snap. Also account for using    avahi-advertise on classic systems where avahi-daemon is installed as a deb  * adjust your avahi-daemon snap to work in strict mode, updating the connected     plug/slot policy as necessary and creating the permanent slot policy in the     avahi-observe and avahi-advertise interfaces you just created  * submit the PR and enjoy :) Look at location-observe and location-control as examples on how to split the interfaces for a single service as inspiration for avahi-observe and avahi- advertise. Look at pulseaudio for how to make avahi-observe and avahi-advertise work for both classic and all-snaps systems. To do the above, I suggest you read Zygmunt's blog series: http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html -- 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 Wed Jan 25 23:56:27 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 26 Jan 2017 00:56:27 +0100 Subject: Version numbers for snap packages Message-ID: <654a30fc-e257-ce41-e06f-a78310fcb6c3@webdrake.net> Hello all, Quick question about version numbering (as in, the `version:` field of `snapcraft.yaml`). The logical choice here is to use the version of the app being packaged, but what's the recommended way to handle changes to the snap package alone that don't change the version of the underlying app? Is a scheme like x.y.z-n advisable (where n is the revision number of the snap itself for this version of the app), or are there alternative suggestions? More generally, what are recommended practices for setting the `version:` field of snap packages? Thanks & best wishes, -- Joe From kyle.fazzari at canonical.com Thu Jan 26 00:17:46 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Wed, 25 Jan 2017 16:17:46 -0800 Subject: Version numbers for snap packages In-Reply-To: <654a30fc-e257-ce41-e06f-a78310fcb6c3@webdrake.net> References: <654a30fc-e257-ce41-e06f-a78310fcb6c3@webdrake.net> Message-ID: On 01/25/2017 03:56 PM, Joseph Rushton Wakeling wrote: > Hello all, > > Quick question about version numbering (as in, the `version:` field of > `snapcraft.yaml`). The logical choice here is to use the version of the > app being packaged, but what's the recommended way to handle changes to > the snap package alone that don't change the version of the underlying app? > > Is a scheme like x.y.z-n advisable (where n is the revision number of > the snap itself for this version of the app), or are there alternative > suggestions? > > More generally, what are recommended practices for setting the > `version:` field of snap packages? I personally use `version: snap1`. Then if I release an update that is snapping the same version of upstream but has snap-specific changes (wrappers, part changes, etc.) I can just release `snap2`. -- 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 spencertparkin at gmail.com Thu Jan 26 06:27:49 2017 From: spencertparkin at gmail.com (Spencer) Date: Wed, 25 Jan 2017 23:27:49 -0700 Subject: Version numbers for snap packages In-Reply-To: References: <654a30fc-e257-ce41-e06f-a78310fcb6c3@webdrake.net> Message-ID: <45DFC47D-FD0F-4A8A-BA0A-311F072664F6@gmail.com> I totally disagree. Use Gaussian integers for your major version number and transcendental numbers for the minor. The product of these must not lie in the range between a pair of twin primes, unless your using the ratio of a circle's circumference to its diameter, the base of the natural logarithm, or the square root of either. If only snap changes are being made, decrement the minor version number by 5 and increment the major version number by -5. This is the way, gentlemen. This is how we do proper versioning. Think about it. > On Jan 25, 2017, at 5:17 PM, Kyle Fazzari wrote: > > > >> On 01/25/2017 03:56 PM, Joseph Rushton Wakeling wrote: >> Hello all, >> >> Quick question about version numbering (as in, the `version:` field of >> `snapcraft.yaml`). The logical choice here is to use the version of the >> app being packaged, but what's the recommended way to handle changes to >> the snap package alone that don't change the version of the underlying app? >> >> Is a scheme like x.y.z-n advisable (where n is the revision number of >> the snap itself for this version of the app), or are there alternative >> suggestions? >> >> More generally, what are recommended practices for setting the >> `version:` field of snap packages? > > I personally use `version: snap1`. Then if I release > an update that is snapping the same version of upstream but has > snap-specific changes (wrappers, part changes, etc.) I can just release > `snap2`. > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From elfgoh at yahoo.com Thu Jan 26 06:44:49 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Thu, 26 Jan 2017 06:44:49 +0000 (UTC) Subject: Relationship between snaps and containers, if any In-Reply-To: References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> Message-ID: <776644856.1114726.1485413089994@mail.yahoo.com> Thanks Mark, your explanation is clear. But I am also thinking along similar lines to Gustavo's suggestion of running a snap multiple times, and wondering if that is the same as having multiple docker processes. -- Luther On Wednesday, January 25, 2017 10:13 PM, Gustavo Niemeyer wrote: Interesting.. I actually don't see that line between snaps and Docker. Just like you can run "docker run mysql" several times, one may run "mysnap.mysql" several times. In both cases the daemon will be visible to the external world via a separate port of the local host's public IP address. In both cases mysql will be isolated from the local environment by confinement. It's even a bit more convenient to do that using a snap. Easier to manage the process on a systemd unit, for example, since the mysql process will indeed be a child of systemd/etc instead of a child of the docker daemon. On Wed, Jan 25, 2017 at 11:51 AM, Mark Shuttleworth wrote: >The best way to think of this is to know that snaps are GREAT when you >have a precise 1:1 relationship between "machines" and "running >instances". And Docker is GREAT when you want an elastic relationship. >So for example, if you want a MySQL "appliance" on a device, there will >only ever be 1 MySQL instance on that device, you want a snap. If you >want a cluster where there may be 1-many instances of MySQl on each >actual machine or VM, then you want Docker. > >The reason for this is that Docker gives each running process its own IP >address. That's perfect for the hyper-elastic case - each extra MySQSL >is just another IP address to talk to. But if you have a machine where >you already have an IP address and all you want is a MySQL there then a >snap will be easier. > >This is why a snap of the Docker daemon makes such sense - in your >cluster, you want exactly one copy of Docker itself running on each >machine, and that is best pulled in as a snap. That docker process then >manages an arbitrary number of docker processes on each machine. > >Make sense? >Mark > > > > > >-- >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 elfgoh at yahoo.com Thu Jan 26 06:55:32 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Thu, 26 Jan 2017 06:55:32 +0000 (UTC) Subject: Creating a snap using make or autotools References: <796287426.1057114.1485413732702.ref@mail.yahoo.com> Message-ID: <796287426.1057114.1485413732702@mail.yahoo.com> This probably isn't the right place to ask, but I thought I should ask in case it does matter in the context of snapping: when creating a snap of say, a hello world program in C[1], should I use the make or autotools plugin? Is one better than the other when it comes to snap creation? A quick visual scan of snappy playpen seems to indicate that more project use autotools than make, though I am unsure if the numbers are reflective of actual preferences. Appreciate if anyone can share more. Full disclosure: I am unfamiliar with both make and autotools. Thanks. [1] http://groups.engin.umd.umich.edu/CIS/course.des/cis400/c/hworld.html From alberto.mardegan at canonical.com Thu Jan 26 07:50:15 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Thu, 26 Jan 2017 10:50:15 +0300 Subject: CUPS in a snap: Using content interface to connect printer driver snaps In-Reply-To: References: Message-ID: <11255c34-e9ab-8776-9d02-90d88eb0661a@canonical.com> On 25/01/2017 21:29, Till Kamppeter wrote: > So CUPS needs to provide a slot to take these files somehow and this > slot needs to accept any printer driver snap and any number of printer > driver snaps. > > Can one do this with the "content" interface? And if yes, how? Note: snapd developers are very welcome to correct me if I'm wrong. :-) My understanding is that this is currently not possible, but it's being worked on in an effort called "interface hooks": these are executables shipped by your snap which will be run whenever an interface gets connected. They can be provided either by the consumer snap (plug) or by the provider snap (socket), or both. You could use them to register the driver into cups. By the way, do we have an ETA for this feature? I'm also in a badly need for it. :-) Ciao, Alberto From elfgoh at yahoo.com Thu Jan 26 08:16:36 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Thu, 26 Jan 2017 08:16:36 +0000 (UTC) Subject: Issues installing snap References: <820611472.1113367.1485418596871.ref@mail.yahoo.com> Message-ID: <820611472.1113367.1485418596871@mail.yahoo.com> I have successfully created a snap using snapcraft. However, I encountered issues when trying to install the snap. The device is a Beaglebone black with a shield containing a temperature sensor. The program that has been snapped returns the temperature, and works correctly outside of the snap. Will appreciate if someone can give me pointers. Thanks. Distribution: Debian SBC: BBB Linux Kernel: 4.4.9-ti-r25 snapd(on debian): 2.20-2 snapcraft (ubuntu docker): 2.25 C program: http://dpaste.com/2F1T39C Makefile: default: gcc temperature.c -o temperature install: temperature install -m 0755 temperature $(DESTDIR)/ Logs: $ systemctl status snap-ambient-x1.mount ● snap-ambient-x1.mount - Mount unit for ambient Loaded: loaded (/etc/systemd/system/snap-ambient-x1.mount; enabled) Active: failed (Result: signal) since Thu 2017-01-26 15:41:59 SGT; 1min 58s ago Where: /snap/ambient/x1 What: /var/lib/snapd/snaps/ambient_x1.snap Process: 4379 ExecMount=/bin/mount -n /var/lib/snapd/snaps/ambient_x1.snap /snap/ambient/x1 -t squashfs (code=killed, signal=SEGV) Jan 26 15:41:59 beaglebone systemd[1]: snap-ambient-x1.mount mount process exited, code=killed status=11 Jan 26 15:41:59 beaglebone systemd[1]: Failed to mount Mount unit for ambient. Jan 26 15:42:00 beaglebone systemd[1]: Unit snap-ambient-x1.mount entered failed state. $ journalctl -xn -- Logs begin at Sat 2000-01-01 08:00:03 SGT, end at Thu 2017-01-26 15:44:02 SGT. -- Jan 26 15:41:59 beaglebone systemd[1]: Failed to mount Mount unit for ambient. -- Subject: Unit snap-ambient-x1.mount has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit snap-ambient-x1.mount has failed. -- -- The result is failed. Jan 26 15:42:00 beaglebone systemd[1]: Unit snap-ambient-x1.mount entered failed state. Jan 26 15:42:00 beaglebone /usr/lib/snapd/snapd[410]: task.go:303: DEBUG: 2017-01-26T15:42:00+08:00 ERROR [start snap-ambient-x1.mount] fa Jan 26 15:42:00 beaglebone /usr/lib/snapd/snapd[410]: taskrunner.go:353: DEBUG: Running task 77 on Undo: Prepare snap "/tmp/snapd-sideload Jan 26 15:43:01 beaglebone main[1078]: % Total % Received % Xferd Average Speed Time Time Time Current Jan 26 15:43:01 beaglebone main[1078]: Dload Upload Total Spent Left Speed Jan 26 15:43:01 beaglebone main[1078]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (56) Recv failure Jan 26 15:44:02 beaglebone main[1078]: % Total % Received % Xferd Average Speed Time Time Time Current Jan 26 15:44:02 beaglebone main[1078]: Dload Upload Total Spent Left Speed Jan 26 15:44:02 beaglebone main[1078]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (56) Recv failure From elfgoh at yahoo.com Thu Jan 26 09:25:16 2017 From: elfgoh at yahoo.com (Luther Goh Lu Feng) Date: Thu, 26 Jan 2017 09:25:16 +0000 (UTC) Subject: Issues installing snap In-Reply-To: <820611472.1113367.1485418596871@mail.yahoo.com> References: <820611472.1113367.1485418596871.ref@mail.yahoo.com> <820611472.1113367.1485418596871@mail.yahoo.com> Message-ID: <1916656065.1112886.1485422716049@mail.yahoo.com> Just to share, I move the source, makefile, yaml files to a new clean directory and rebuild, and achieved a successful installation. I am guessing the build may not have been a clean pne even though I ran $ snapcraft clean Is there any possible explanation what went wrong? Thanks -- Luther On Thursday, January 26, 2017 4:16 PM, Luther Goh Lu Feng wrote: I have successfully created a snap using snapcraft. However, I encountered issues when trying to install the snap. The device is a Beaglebone black with a shield containing a temperature sensor. The program that has been snapped returns the temperature, and works correctly outside of the snap. Will appreciate if someone can give me pointers. Thanks. Distribution: Debian SBC: BBB Linux Kernel: 4.4.9-ti-r25 snapd(on debian): 2.20-2 snapcraft (ubuntu docker): 2.25 C program: http://dpaste.com/2F1T39C Makefile: default: gcc temperature.c -o temperature install: temperature install -m 0755 temperature $(DESTDIR)/ Logs: $ systemctl status snap-ambient-x1.mount ● snap-ambient-x1.mount - Mount unit for ambient Loaded: loaded (/etc/systemd/system/snap-ambient-x1.mount; enabled) Active: failed (Result: signal) since Thu 2017-01-26 15:41:59 SGT; 1min 58s ago Where: /snap/ambient/x1 What: /var/lib/snapd/snaps/ambient_x1.snap Process: 4379 ExecMount=/bin/mount -n /var/lib/snapd/snaps/ambient_x1.snap /snap/ambient/x1 -t squashfs (code=killed, signal=SEGV) Jan 26 15:41:59 beaglebone systemd[1]: snap-ambient-x1.mount mount process exited, code=killed status=11 Jan 26 15:41:59 beaglebone systemd[1]: Failed to mount Mount unit for ambient. Jan 26 15:42:00 beaglebone systemd[1]: Unit snap-ambient-x1.mount entered failed state. $ journalctl -xn -- Logs begin at Sat 2000-01-01 08:00:03 SGT, end at Thu 2017-01-26 15:44:02 SGT. -- Jan 26 15:41:59 beaglebone systemd[1]: Failed to mount Mount unit for ambient. -- Subject: Unit snap-ambient-x1.mount has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit snap-ambient-x1.mount has failed. -- -- The result is failed. Jan 26 15:42:00 beaglebone systemd[1]: Unit snap-ambient-x1.mount entered failed state. Jan 26 15:42:00 beaglebone /usr/lib/snapd/snapd[410]: task.go:303: DEBUG: 2017-01-26T15:42:00+08:00 ERROR [start snap-ambient-x1.mount] fa Jan 26 15:42:00 beaglebone /usr/lib/snapd/snapd[410]: taskrunner.go:353: DEBUG: Running task 77 on Undo: Prepare snap "/tmp/snapd-sideload Jan 26 15:43:01 beaglebone main[1078]: % Total % Received % Xferd Average Speed Time Time Time Current Jan 26 15:43:01 beaglebone main[1078]: Dload Upload Total Spent Left Speed Jan 26 15:43:01 beaglebone main[1078]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (56) Recv failure Jan 26 15:44:02 beaglebone main[1078]: % Total % Received % Xferd Average Speed Time Time Time Current Jan 26 15:44:02 beaglebone main[1078]: Dload Upload Total Spent Left Speed Jan 26 15:44:02 beaglebone main[1078]: 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0curl: (56) Recv failure From olivier.tilloy at canonical.com Thu Jan 26 09:36:30 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Thu, 26 Jan 2017 10:36:30 +0100 Subject: Creating a snap using make or autotools In-Reply-To: <796287426.1057114.1485413732702@mail.yahoo.com> References: <796287426.1057114.1485413732702.ref@mail.yahoo.com> <796287426.1057114.1485413732702@mail.yahoo.com> Message-ID: On Thu, Jan 26, 2017 at 7:55 AM, Luther Goh Lu Feng wrote: > This probably isn't the right place to ask, but I thought I should ask in case it does matter in the context of snapping: when creating a snap of say, a hello world program in C[1], should I use the make or autotools plugin? > > Is one better than the other when it comes to snap creation? > > A quick visual scan of snappy playpen seems to indicate that more project use autotools than make, though I am unsure if the numbers are reflective of actual preferences. Appreciate if anyone can share more. > > Full disclosure: I am unfamiliar with both make and autotools. Thanks. > > [1] http://groups.engin.umd.umich.edu/CIS/course.des/cis400/c/hworld.html Snapcraft supports both equally well, so it’s just a matter of personal preference, really. If you’re snapping an upstream application, then use whatever build system upstream provides. If you’re authoring your application from scratch, use whatever you’re more comfortable with. You’re not limited to make or autotools by the way, there are more modern build systems available as snapcraft plugins, such as SCons or CMake. If you’re not familiar with either of those, you’ll need to pick one and learn at least the very basics (for such a simple hello world kind of example, the build files should be trivial with any decent build system). HTH, Olivier From jamie.bennett at canonical.com Thu Jan 26 10:06:29 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Thu, 26 Jan 2017 10:06:29 +0000 Subject: CUPS in a snap: Using content interface to connect printer driver snaps In-Reply-To: <11255c34-e9ab-8776-9d02-90d88eb0661a@canonical.com> References: <11255c34-e9ab-8776-9d02-90d88eb0661a@canonical.com> Message-ID: > On 26 Jan 2017, at 07:50, Alberto Mardegan wrote: > > On 25/01/2017 21:29, Till Kamppeter wrote: >> So CUPS needs to provide a slot to take these files somehow and this >> slot needs to accept any printer driver snap and any number of printer >> driver snaps. >> >> Can one do this with the "content" interface? And if yes, how? > > Note: snapd developers are very welcome to correct me if I'm wrong. :-) > > My understanding is that this is currently not possible, but it's being > worked on in an effort called "interface hooks": these are executables > shipped by your snap which will be run whenever an interface gets > connected. They can be provided either by the consumer snap (plug) or by > the provider snap (socket), or both. You could use them to register the > driver into cups. > > By the way, do we have an ETA for this feature? I'm also in a badly need > for it. :-) The work is progressing nicely but no definitive ETA at the moment. We are all looking forward to seeing it as soon as possible. > Ciao, > Alberto Regards, Jamie. From sergio.schvezov at canonical.com Thu Jan 26 10:35:20 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Thu, 26 Jan 2017 10:35:20 +0000 Subject: Creating a snap using make or autotools In-Reply-To: <796287426.1057114.1485413732702@mail.yahoo.com> References: <796287426.1057114.1485413732702.ref@mail.yahoo.com> <796287426.1057114.1485413732702@mail.yahoo.com> Message-ID: On Thu, 26 Jan 2017 06:55:32 +0000, Luther Goh Lu Feng wrote: > This probably isn't the right place to ask, but I thought I > should ask in case it does matter in the context of snapping: > when creating a snap of say, a hello world program in C[1], > should I use the make or autotools plugin? This is exactly the right place to ask > Is one better than the other when it comes to snap creation? They should both produce working results. > A quick visual scan of snappy playpen seems to indicate that > more project use autotools than make, though I am unsure if the > numbers are reflective of actual preferences. Appreciate if > anyone can share more. Because it was trendy in linux-land for a while. cmake is also popular these days, traditional unix commands used to just use Makefiles. > Full disclosure: I am unfamiliar with both make and autotools. Thanks. I cannot open [1], but if that is just driven by make, then use make, if there is no build mechanism you can write your own or even just script the commands manually. > [1] http://groups.engin.umd.umich.edu/CIS/course.des/cis400/c/hworld.html -- Sent using Dekko from my Ubuntu device From david.barth at canonical.com Thu Jan 26 10:37:02 2017 From: david.barth at canonical.com (David Barth) Date: Thu, 26 Jan 2017 11:37:02 +0100 Subject: CUPS in a snap: avahi-daemon needed In-Reply-To: References: <2ba437a0-ef70-3271-a8a2-755990373c08@gmail.com> Message-ID: On Wed, Jan 25, 2017 at 8:30 PM, Till Kamppeter wrote: > On 01/25/2017 05:18 PM, Sergio Schvezov wrote: > > snapweb uses a small mdns implementation written in go; avahi is much more >> than that. >> That said, the original versions of snapweb, formerlly known as webdm did >> have a full blown avahi-daemon inside, but it is really cumbersome if not >> needed. >> >> > Is the old avahi-daemon-using webdm package (source) still publicly > available somewhere? > Till, You can find the project source tree at https://code.launchpad.net/snapweb It references both the bzr branches of webdm and the latest master git branch sync'ed with github.com/snapcore/snapweb which is now the main code repository. The mDNS implementation used by snapweb is here https://github.com/snapcore/snapweb/blob/master/avahi/avahi.go, based on https://github.com/presotto/go-mdns-sd. Previously it was using https://github.com/davecheney/mdns but that had issues at startup and was causing snapweb to exit on mDNS errors. I couldn't find the older avahi wrapper doing a quick history search, but as Sergio and Jamie suggested, that won't really help. New interfaces are needed. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Thu Jan 26 11:29:30 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Thu, 26 Jan 2017 09:29:30 -0200 Subject: Relationship between snaps and containers, if any In-Reply-To: <776644856.1114726.1485413089994@mail.yahoo.com> References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> <776644856.1114726.1485413089994@mail.yahoo.com> Message-ID: It's similar.. it's actually a bit closer to just running a normal process multiple times than Docker is. For example, commands from the snap are in your local path, the child/parent process relationship is the traditional one instead of being the child of a daemon, and so on. Even then, the processes live in a confined world, with its boundaries defined by which interface connections are established. On Thu, Jan 26, 2017 at 4:44 AM, Luther Goh Lu Feng wrote: > Thanks Mark, your explanation is clear. But I am also thinking along > similar lines to Gustavo's suggestion of running a snap multiple times, and > wondering if that is the same as having multiple docker processes. > > > -- Luther > > On Wednesday, January 25, 2017 10:13 PM, Gustavo Niemeyer < > gustavo.niemeyer at canonical.com> wrote: > > > > > Interesting.. I actually don't see that line between snaps and Docker. > Just like you can run "docker run mysql" several times, one may run > "mysnap.mysql" several times. In both cases the daemon will be visible to > the external world via a separate port of the local host's public IP > address. In both cases mysql will be isolated from the local environment by > confinement. > > It's even a bit more convenient to do that using a snap. Easier to manage > the process on a systemd unit, for example, since the mysql process will > indeed be a child of systemd/etc instead of a child of the docker daemon. > > > > On Wed, Jan 25, 2017 at 11:51 AM, Mark Shuttleworth > wrote: > > > >The best way to think of this is to know that snaps are GREAT when you > >have a precise 1:1 relationship between "machines" and "running > >instances". And Docker is GREAT when you want an elastic relationship. > >So for example, if you want a MySQL "appliance" on a device, there will > >only ever be 1 MySQL instance on that device, you want a snap. If you > >want a cluster where there may be 1-many instances of MySQl on each > >actual machine or VM, then you want Docker. > > > >The reason for this is that Docker gives each running process its own IP > >address. That's perfect for the hyper-elastic case - each extra MySQSL > >is just another IP address to talk to. But if you have a machine where > >you already have an IP address and all you want is a MySQL there then a > >snap will be easier. > > > >This is why a snap of the Docker daemon makes such sense - in your > >cluster, you want exactly one copy of Docker itself running on each > >machine, and that is best pulled in as a snap. That docker process then > >manages an arbitrary number of docker processes on each machine. > > > >Make sense? > >Mark > > > > > > > > > > > >-- > >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 > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier.tilloy at canonical.com Thu Jan 26 12:06:36 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Thu, 26 Jan 2017 13:06:36 +0100 Subject: SDL2 / Kivy keyboard event not firing in Snap In-Reply-To: <2208e004-dc99-cc23-d772-e8057742d2d4@ubuntu.com> References: <2208e004-dc99-cc23-d772-e8057742d2d4@ubuntu.com> Message-ID: On Tue, Jan 24, 2017 at 3:04 PM, Michael Hall wrote: > On 01/24/2017 08:47 AM, Alan Pope wrote: >> On 24 January 2017 at 10:22, Olivier Tilloy >> wrote: >>> That sounds very similar to the issue I was having with the 0ad snap, >>> which after much debugging I fixed by exporting $XLOCALEDIR, see >>> details here: https://bazaar.launchpad.net/~osomon/+junk/0ad-snap/revision/8. >>> >> >> You're a star. I have had a LÖVE (also SDL) game on the back burner >> because keyboard input didn't work, this fixed it, and should open the >> door for other games built using LÖVE into the store! >> >>> Let us know if that did the trick. >>> Also, this should be documented somehow for people snapping X11/SDL >>> games. Do we have a place for such tips and tricks? >>> >> >> Maybe we need an X11/SDL plain launcher remote part which people can >> pull in, that includes this kind of detail? >> >> Cheers, >> > > Is there any reason not to add it to the desktop-helpers remote part? > XLOCALEDIR isn't SDL-specific, it just seems to be the first thing > that's brought it to our attention. There you go: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/41 Not actually tested with an app using the desktop helpers, so feedback welcome! From mark at ubuntu.com Thu Jan 26 13:12:28 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 26 Jan 2017 13:12:28 +0000 Subject: Relationship between snaps and containers, if any In-Reply-To: References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> <776644856.1114726.1485413089994@mail.yahoo.com> Message-ID: <60fd56de-f6bf-38b7-6848-ddecbc728dda@ubuntu.com> Well, from an *external* point of view, all the docker mysql processes are the same, on the same port, just with different IP addresses. That's the very nice property of docker for "hyper-elastic" workloads. I don't think snaps will be useful in that context, unless snaps find a way to live inside docker containers, but that's OK since snaps are useful in other contexts. Mark From gustavo.niemeyer at canonical.com Thu Jan 26 13:55:55 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Thu, 26 Jan 2017 11:55:55 -0200 Subject: Relationship between snaps and containers, if any In-Reply-To: <60fd56de-f6bf-38b7-6848-ddecbc728dda@ubuntu.com> References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> <776644856.1114726.1485413089994@mail.yahoo.com> <60fd56de-f6bf-38b7-6848-ddecbc728dda@ubuntu.com> Message-ID: It seems that the most common way to deploy Docker is by mapping ports out of the private IP addresses into the local host's public IP, which means it's completely analogous to multiple processes in the same host. Even when assigning the docker container to an external IP, a commonly recommended practice is to use -p ::, which means the public IP is sitting on the external host. E.g.: http://stackoverflow.com/questions/26539727/giving-a- docker-container-a-routable-ip-address That also maps exactly to just asking the process bind to the particular IP. On Thu, Jan 26, 2017 at 11:12 AM, Mark Shuttleworth wrote: > > Well, from an *external* point of view, all the docker mysql processes > are the same, on the same port, just with different IP addresses. That's > the very nice property of docker for "hyper-elastic" workloads. I don't > think snaps will be useful in that context, unless snaps find a way to > live inside docker containers, but that's OK since snaps are useful in > other contexts. > > Mark > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.vogt at canonical.com Thu Jan 26 14:28:28 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Thu, 26 Jan 2017 15:28:28 +0100 Subject: New stable "core" and "ubuntu-core" snaps released Message-ID: <20170126142828.GH23539@bod> Hi, The Snappy Team are happy to announce that we have a new version of the "core" and "ubuntu-core" snaps in the stable channel. They are based on snapd 2.21 and contains all the features of 2.21 that got announced in [1]. As always, your devices will update and reboot automatically. Please let us know if you notice any issues and enjoy the new release! Cheers, Michael (on behalf of the snappy team) [1] https://lists.ubuntu.com/archives/snapcraft/2017-January/002493.html From marcoshalano at gmail.com Thu Jan 26 15:30:35 2017 From: marcoshalano at gmail.com (Marcos Alano) Date: Thu, 26 Jan 2017 13:30:35 -0200 Subject: Difference between 'core' and 'ubuntu-core' snaps Message-ID: Hi everybody! I was looking for this question for sometime but I can't find an answer. The question is pretty simples: what is the difference between the 'core' and 'ubuntu-core' snaps? I have both installed on my computer but after look inside them, they seems almost the same. From ogra at ubuntu.com Thu Jan 26 15:42:41 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 26 Jan 2017 16:42:41 +0100 Subject: Difference between 'core' and 'ubuntu-core' snaps In-Reply-To: References: Message-ID: <1485445361.4288.111.camel@ubuntu.com> hi, Am Donnerstag, den 26.01.2017, 13:30 -0200 schrieb Marcos Alano: > Hi everybody! > > I was looking for this question for sometime but I can't find an > answer. > The question is pretty simples: what is the difference between the > 'core' and 'ubuntu-core' snaps? I have both installed on my computer > but > after look inside them, they seems almost the same. > > i explained this a few weeks ago in: https://lists.ubuntu.com/archives/snapcraft/2017-January/002332.html 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 Thu Jan 26 15:50:27 2017 From: ogra at ubuntu.com (Oliver Grawert) Date: Thu, 26 Jan 2017 16:50:27 +0100 Subject: Difference between 'core' and 'ubuntu-core' snaps In-Reply-To: <1485445361.4288.111.camel@ubuntu.com> References: <1485445361.4288.111.camel@ubuntu.com> Message-ID: <1485445827.4288.113.camel@ubuntu.com> hi, Am Donnerstag, den 26.01.2017, 16:42 +0100 schrieb Oliver Grawert: > hi, >  > i explained this a few weeks ago in: > > https://lists.ubuntu.com/archives/snapcraft/2017-January/002332.html > and i should add that there is active work going on to automatically transition all users of ubuntu-core to core since that mail was written. eventually you will just magically find "core" instead of "ubuntu-core" in your snap list output. 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 marcoshalano at gmail.com Thu Jan 26 15:52:12 2017 From: marcoshalano at gmail.com (Marcos H. Alano) Date: Thu, 26 Jan 2017 13:52:12 -0200 Subject: Difference between 'core' and 'ubuntu-core' snaps In-Reply-To: <1485445361.4288.111.camel@ubuntu.com> References: <1485445361.4288.111.camel@ubuntu.com> Message-ID: <839652ca-5d57-4683-b789-6c6607e2a4ef@gmail.com> Thanks Oliver! Now I know how snap to keep installed and why the snaps was not the same. :) Cheers! On Jan 26, 2017, Oliver Grawert wrote: >hi, >Am Donnerstag, den 26.01.2017, 13:30 -0200 schrieb Marcos Alano: >> Hi everybody! >> >> I was looking for this question for sometime but I can't find an >> answer. >> The question is pretty simples: what is the difference between the >> 'core' and 'ubuntu-core' snaps? I have both installed on my computer >> but >> after look inside them, they seems almost the same. >> >> >i explained this a few weeks ago in: > >https://lists.ubuntu.com/archives/snapcraft/2017-January/002332.html > >ciao > oli > >------------------------------------------------------------------------ > >-- >Snapcraft mailing list >Snapcraft at lists.snapcraft.io >Modify settings or unsubscribe at: >https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Sent with K-@ Mail - the evolution of emailing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.brustkern at canonical.com Thu Jan 26 16:16:10 2017 From: max.brustkern at canonical.com (Max Brustkern) Date: Thu, 26 Jan 2017 11:16:10 -0500 Subject: Spread Tests with proxy (mostly go get) In-Reply-To: References: Message-ID: Digging into this further, I'm wondering if there's a way to set a proxy for the whole classic environment? This would cover go as well as any other commands I might need to run. On Mon, Jan 23, 2017 at 5:01 PM, Max Brustkern wrote: > I'm trying to run spread tests on an ubuntu core VM in a lab that needs to > use a proxy for web access. The mirrors are redirected, so the package > installations work as expected, but I run into problems with go get: > > ++ classic 'GOPATH=/home/gopath go get ../../home/gopath/src/github. > com/snapcore/snapd/tests/lib/snapbuild' > Cannot determine calling user, logging into classic as root > mount: devpts is already mounted or /dev/pts busy > devpts is already mounted on /dev/pts > package gopkg.in/yaml.v2: unrecognized import path "gopkg.in/yaml.v2" > (https fetch: Get https://gopkg.in/yaml.v2?go-get=1: dial tcp > 45.33.69.124:443: i/o timeout) > package gopkg.in/check.v1: unrecognized import path "gopkg.in/check.v1" > (https fetch: Get https://gopkg.in/check.v1?go-get=1: dial tcp > 45.33.69.124:443: i/o timeout) > ++ sysctl -w net.ipv6.conf.all.disable_ipv6=0 > net.ipv6.conf.all.disable_ipv6 = 0 > ----- > 2017/01/23 16:46:54 Restoring project on external:ubuntu-core-16-64... > 2017/01/23 16:46:55 Successful tasks: 0 > 2017/01/23 16:46:55 Aborted tasks: 107 > 2017/01/23 16:46:55 Failed project prepare: 1 > - external:ubuntu-core-16-64:project > 2017/01/23 16:46:55 Keeping external:ubuntu-core-16-64 at 127.0.0.1:54323 > error: unsuccessful run > > I'm using the following spread commands to run on the local VM: > export SPREAD_EXTERNAL_ADDRESS=127.0.0.1:$PORT > ./tests/lib/external/prepare-ssh.sh 127.0.0.1 $PORT $USER > spread -v -reuse external:ubuntu-core-16-64 | tee $WORKSPACE/spread-output > > How should I configure spread to make go aware of the proxy? > > Thanks, > Max > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Thu Jan 26 21:04:02 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 26 Jan 2017 22:04:02 +0100 Subject: Classic confinement success for LDC D compiler In-Reply-To: <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> Message-ID: <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> On 20/01/17 13:58, Mark Shuttleworth wrote: > Congrats! What's the best way to get the D community aware of this? > Sounds like it would be a nice way for them to keep up to date. Just to follow up on this: the LDC devs have agreed to allow me to move forward with this in the name of the project. The new git repo is available at: https://github.com/ldc-developers/ldc2.snap Question about setting up a developer account to start publishing: is it possible to create a 'group' account with multiple members to act in the name of the LDC project? Or should I just create a single developer account and add the email addresses of others who are interested in having account access? From bret.barker at canonical.com Thu Jan 26 21:34:45 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Thu, 26 Jan 2017 16:34:45 -0500 Subject: Classic confinement success for LDC D compiler In-Reply-To: <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> Message-ID: <20170126213444.GL40202@abitrandom.net> On Thu, Jan 26, 2017 at 10:04:02PM +0100, Joseph Rushton Wakeling wrote: > On 20/01/17 13:58, Mark Shuttleworth wrote: > >Congrats! What's the best way to get the D community aware of this? > >Sounds like it would be a nice way for them to keep up to date. > > Just to follow up on this: the LDC devs have agreed to allow me to move > forward with this in the name of the project. The new git repo is available > at: > https://github.com/ldc-developers/ldc2.snap > > Question about setting up a developer account to start publishing: is it > possible to create a 'group' account with multiple members to act in the > name of the LDC project? Or should I just create a single developer account > and add the email addresses of others who are interested in having account > access? > We don't have group accounts, but the best practice is to create an account for the owner/publisher of the snap and then use the Collaboaration feature (on a snap's detail page on myapps.developer.ubuntu.com after an initial snap upload) to grant other accounts access to pushing and releasing revisions. -bret From mark at ubuntu.com Thu Jan 26 21:36:09 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 26 Jan 2017 21:36:09 +0000 Subject: Classic confinement success for LDC D compiler In-Reply-To: <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> Message-ID: <00b80bc9-e03e-c3f1-5958-2f78b0d05c14@ubuntu.com> On 26/01/17 21:04, Joseph Rushton Wakeling wrote: > Question about setting up a developer account to start publishing: is > it possible to create a 'group' account with multiple members to act > in the name of the LDC project? Or should I just create a single > developer account and add the email addresses of others who are > interested in having account access? The plan is that there will be a mechanism for the publisher to list accounts that can push and release revisions. For now I would suggest you use your own account until we have that, then we can move to something more representative. Congrats! This will be lovely for the D crowd. Mark From mark at ubuntu.com Thu Jan 26 21:36:45 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 26 Jan 2017 21:36:45 +0000 Subject: Classic confinement success for LDC D compiler In-Reply-To: <20170126213444.GL40202@abitrandom.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> <20170126213444.GL40202@abitrandom.net> Message-ID: <42a45bfe-b763-f736-2d41-567af0150381@ubuntu.com> On 26/01/17 21:34, Bret A. Barker wrote: > We don't have group accounts, but the best practice is to create an account for the owner/publisher of the snap and then use the Collaboaration feature (on a snap's detail page on myapps.developer.ubuntu.com after an initial snap upload) to grant other accounts access to pushing and releasing revisions. Ah, thanks Bret good to know this is already possible! Mark From joseph.wakeling at webdrake.net Thu Jan 26 22:04:29 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 26 Jan 2017 23:04:29 +0100 Subject: Classic confinement success for LDC D compiler In-Reply-To: <00b80bc9-e03e-c3f1-5958-2f78b0d05c14@ubuntu.com> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> <00b80bc9-e03e-c3f1-5958-2f78b0d05c14@ubuntu.com> Message-ID: On 26/01/17 22:36, Mark Shuttleworth wrote: > The plan is that there will be a mechanism for the publisher to list > accounts that can push and release revisions. > > For now I would suggest you use your own account until we have that, > then we can move to something more representative. Ack, I already registered an extra account in the name of 'LDC Developers'. I hope there's no harm in using that ... :-) The `ldc2` name is apparently reserved (I requested it); if I temporarily choose a different name, will I wind up with the issue of all my programs being called something like my-temporary-snap-name.ldc2 etc.? > Congrats! This will be lovely for the D crowd. Yes, it should be good. The LDC folks certainly seem happy :-) The snap for DUB (a package/build manager for D programs) is also working nicely AFAICT so I'll follow up with that soon (I'd like to have one published snap for people to try and verify before I proceed with any others). From joseph.wakeling at webdrake.net Thu Jan 26 22:14:42 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 26 Jan 2017 23:14:42 +0100 Subject: Snap package licenses Message-ID: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> Hello all, I'm just about to upload the ldc2 snap, but have one last question first. LDC itself is released under the terms of the BSD license, but some components it links to are released under other licenses (Boost, Artistic License and LGPL). All of this is covered under the setup/license.txt file. However, the submission form wants a specific license. Would BSD be adequate in this case or is it better to specify 'Other open source' ... ? Thanks & best wishes, -- Joe From joseph.wakeling at webdrake.net Thu Jan 26 22:16:12 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 26 Jan 2017 23:16:12 +0100 Subject: Classic confinement success for LDC D compiler In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> <00b80bc9-e03e-c3f1-5958-2f78b0d05c14@ubuntu.com> Message-ID: On 26/01/17 23:04, Joseph Rushton Wakeling wrote: > The `ldc2` name is apparently reserved (I requested it); if I temporarily choose > a different name, will I wind up with the issue of all my programs being called > something like my-temporary-snap-name.ldc2 etc.? ... no need: permission was granted VERY quickly. I don't know if anyone acted to reserve the name anticipating my submission, but if so, thank you :-) From bret.barker at canonical.com Thu Jan 26 22:31:03 2017 From: bret.barker at canonical.com (Bret A. Barker) Date: Thu, 26 Jan 2017 17:31:03 -0500 Subject: Classic confinement success for LDC D compiler In-Reply-To: References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> <00b80bc9-e03e-c3f1-5958-2f78b0d05c14@ubuntu.com> Message-ID: <20170126223102.GM40202@abitrandom.net> On Thu, Jan 26, 2017 at 11:16:12PM +0100, Joseph Rushton Wakeling wrote: > On 26/01/17 23:04, Joseph Rushton Wakeling wrote: > >The `ldc2` name is apparently reserved (I requested it); if I temporarily choose > >a different name, will I wind up with the issue of all my programs being called > >something like my-temporary-snap-name.ldc2 etc.? > > ... no need: permission was granted VERY quickly. I don't know if anyone > acted to reserve the name anticipating my submission, but if so, thank you > :-) > We just added a feature to notify us on new name requests and it caught me before EOD. You should be good to go now, but please reach out here or in the #snapcraft channel if you need any further assistance with releasing the snap. -bret From mark at ubuntu.com Thu Jan 26 22:35:25 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 26 Jan 2017 22:35:25 +0000 Subject: Snap package licenses In-Reply-To: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> Message-ID: <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> We should allow a plaintext field there for this situation. Yes, go ahead with "Other open source". On 26/01/17 22:14, Joseph Rushton Wakeling wrote: > Hello all, > > I'm just about to upload the ldc2 snap, but have one last question > first. LDC itself is released under the terms of the BSD license, but > some components it links to are released under other licenses (Boost, > Artistic License and LGPL). All of this is covered under the > setup/license.txt file. > > However, the submission form wants a specific license. Would BSD be > adequate in this case or is it better to specify 'Other open source' > ... ? > > Thanks & best wishes, > > -- Joe > From joseph.wakeling at webdrake.net Thu Jan 26 22:41:06 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Thu, 26 Jan 2017 23:41:06 +0100 Subject: Classic confinement success for LDC D compiler In-Reply-To: <20170126223102.GM40202@abitrandom.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> <00b80bc9-e03e-c3f1-5958-2f78b0d05c14@ubuntu.com> <20170126223102.GM40202@abitrandom.net> Message-ID: <21822b65-6771-4a28-81fc-16d46915fafb@webdrake.net> On 26/01/17 23:31, Bret A. Barker wrote: > We just added a feature to notify us on new name requests and it caught me before EOD. Well, thank you VERY much. Your advice and support has been great. > You should be good to go now, but please reach out here or in the #snapcraft channel if you need any further assistance with releasing the snap. Yes, all looks good. Everything is uploaded and just awaiting manual review. From ngompa13 at gmail.com Thu Jan 26 23:58:09 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Thu, 26 Jan 2017 18:58:09 -0500 Subject: Snap package licenses In-Reply-To: <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth wrote: > > We should allow a plaintext field there for this situation. Yes, go > ahead with "Other open source". > It would probably make sense to support SPDX license tags and expressions[1]. This is used in AppStream, so a great amount of software is already classified in this manner. Furthermore, openSUSE uses SPDX tags for their license metadata for packages, and Debian uses a subset of it as part of the copyright file structure in Debian Source Control packaging. While we in Fedora use our own license tag list[2] that predates SPDX (used by a great deal of Linux distributions), we maintain a mapping to SPDX for AppStream support. Having verifiable license information (either Fedora style or SPDX style) is also useful for ensuring things are "compatible" or "desired" on a system, depending on whatever preference you may have. [1]: https://spdx.org/licenses/ [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List -- 真実はいつも一つ！/ Always, there's only one truth! From leo.arias at canonical.com Fri Jan 27 02:12:03 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 26 Jan 2017 20:12:03 -0600 Subject: Yet more issues snapping In-Reply-To: <19b00cc53e56b67303ac253878c49601@cliftonts.co.uk> References: <0fec2ca8-b360-5ce5-b889-292abb122ba5@cliftonts.co.uk> <46eecfb7d8f858c82faed620d7994bcc@cliftonts.co.uk> <19b00cc53e56b67303ac253878c49601@cliftonts.co.uk> Message-ID: Interesting. Well, I hope you keep telling us about your experience, and we'll keep trying to make it better. I might have missed your problem related to packages in the terminal version. Send me a ping in rocket and I will give it a look. pura vida. From stgraber at ubuntu.com Fri Jan 27 02:17:25 2017 From: stgraber at ubuntu.com (=?iso-8859-1?Q?St=E9phane?= Graber) Date: Thu, 26 Jan 2017 21:17:25 -0500 Subject: Ubuntu Core LXD images available for testing Message-ID: <20170127021725.GK5095@dakara> Hello, Today I'm pleased to announce that we have our first Ubuntu Core LXD images available for testing. Those images will be re-generated weekly from whatever is the latest set of Ubuntu Core disk images. As those disk images aren't refreshed very often, it means that the LXD images will typically need a good snap refresh after their first boot. I expect this limitation to go away when those LXD images get picked up by the Ubuntu Cloud team and they make their way to the official Ubuntu image server as they will then benefit from the same image build pipeline used for the Ubuntu Cloud images. In the mean time, our test images are available on https://images.linuxcontainers.org and can be used by any LXD user running an up to date version of Ubuntu and LXD with: lxc launch images:ubuntu-core/16 Should you run into any problem with those images, please file a bug here: https://github.com/lxc/lxc-ci/issues Some extra notes: - LXD passes your cloud-init configuration to the container. However the current Ubuntu Core images have cloud-init disabled. So if you intend to use that LXD facility, you'll need to manually re-enable cloud-init in your container. - This LXD image has a mock bootloader which pretends to be grub. This allows for the expected upgrade experience to work. Updates to the core snap will be attempted on the following boot and reverted on failure. - Using snaps inside LXD containers only works for unprivileged containers. Setting security.privileged to true on your container will break it. This is due to the way Apparmor namespacing works. - Normal LXD security policies apply. So if you intend to install the LXD snap inside your Ubuntu Core container, you'll need to set security.nesting to true. - As mentioned, those images are meant for testing use. Supported production images will soon be available on the official Ubuntu image server and will be based on those generated for the cloud. Enjoy! -- Stéphane Graber Ubuntu developer http://www.ubuntu.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From leo.arias at canonical.com Fri Jan 27 02:29:43 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 26 Jan 2017 20:29:43 -0600 Subject: Ubuntu Core LXD images available for testing In-Reply-To: <20170127021725.GK5095@dakara> References: <20170127021725.GK5095@dakara> Message-ID: Woohoo \o/ Thank you, you have just made my live so much easier. From leo.arias at canonical.com Fri Jan 27 03:11:32 2017 From: leo.arias at canonical.com (Leo Arias) Date: Thu, 26 Jan 2017 21:11:32 -0600 Subject: classic snap fails to find libraries In-Reply-To: <1485251956.4288.109.camel@ubuntu.com> References: <1485251956.4288.109.camel@ubuntu.com> Message-ID: Thanks for the details ogra. Here is the bug: https://bugs.launchpad.net/snappy/+bug/1659719 From adam.stokes at canonical.com Fri Jan 27 06:29:38 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Fri, 27 Jan 2017 06:29:38 +0000 Subject: [ANN] conjure-up classic snap available Message-ID: Conjure-up is a power tool for getting started with big software. Conjure-up lets you summon up a big-software stack as a “spell” - a model of the stack, combined with extra know-how to get you from an installed stack to a fully usable one. Start using your big software instead of learning how to deploy it. To install run: $ sudo snap install conjure-up --classic --beta * Note: snapd v2.21 is required and was released to xenial-updates yesterday so please make sure you're on the latest version for classic installs to work. Getting started: $ conjure-up To teardown any deployments run: $ conjure-down I plan on having this the recommended way to deploy big software, so please help me in ironing out any potential issues that may be seen while running this as a snap. The snap source can be found @ https://github.com/conjure-up/conjure-up-snap conjure-up website @ http://conjure-up.io Thank you, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Fri Jan 27 07:50:42 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Fri, 27 Jan 2017 08:50:42 +0100 Subject: Ubuntu Core LXD images available for testing In-Reply-To: References: <20170127021725.GK5095@dakara> Message-ID: +1 On Fri, Jan 27, 2017 at 3:29 AM, Leo Arias wrote: > Woohoo \o/ > Thank you, you have just made my live so much easier. > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From alberto.mardegan at canonical.com Fri Jan 27 08:55:52 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Fri, 27 Jan 2017 11:55:52 +0300 Subject: Error when publishing a snap Message-ID: <89299592-fb41-0da2-6595-3b683b037a67@canonical.com> Hi all, I'm encountering an error when publishing a newer version of a facebook webapp. Here are the changes from the previous version: http://bazaar.launchpad.net/~mardy/webapps-core/amazon-snap/revision/154 Note that the amazon and google webapps, which have exactly the same changes, could be published just fine. I even tried running "snapcraft clean" and rebuilding the package, but it didn't help: http://paste.ubuntu.com/23873837/ Any idea of what's going wrong? Ciao, Alberto From celso.providelo at canonical.com Fri Jan 27 11:23:13 2017 From: celso.providelo at canonical.com (Celso Providelo) Date: Fri, 27 Jan 2017 11:23:13 +0000 Subject: Error when publishing a snap In-Reply-To: <89299592-fb41-0da2-6595-3b683b037a67@canonical.com> References: <89299592-fb41-0da2-6595-3b683b037a67@canonical.com> Message-ID: On Fri, Jan 27, 2017 at 6:56 AM Alberto Mardegan < alberto.mardegan at canonical.com> wrote: > Hi all, > I'm encountering an error when publishing a newer version of a > facebook webapp. Here are the changes from the previous version: > > http://bazaar.launchpad.net/~mardy/webapps-core/amazon-snap/revision/154 > > Note that the amazon and google webapps, which have exactly the same > changes, could be published just fine. I even tried running "snapcraft > clean" and rebuilding the package, but it didn't help: > > http://paste.ubuntu.com/23873837/ > > Any idea of what's going wrong? > > Yes, the Store is being super unhelpful with this error message, snapcraft and the snap changes are fine. It should be telling you that you have no permission to upload new revisions on 'facebook-webapp' because the name was claimed by someone else (who have not used it yet, btw). Which snapcraft version are you using ? 2.25 should check permissions before uploading the file to the store: https://bugs.launchpad.net/snapcraft/+bug/1610776 Please let me know if the error message is clearer there. Also, it looks like you can dispute the 'facebook-webapp' name https://myapps.developer.ubuntu.com/dev/click-apps/register-name/ by trying to register it again and following the instructions. [] -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.pope at canonical.com Fri Jan 27 14:44:20 2017 From: alan.pope at canonical.com (Alan Pope) Date: Fri, 27 Jan 2017 14:44:20 +0000 Subject: Snaps are not just for the serious things ... Message-ID: Hi, Happy Friday everyone. I discovered 'bucklespring' in the snap store recently. You may enjoy it too... https://www.youtube.com/watch?v=4cp6j42NXnM We need more of these kinds of fun things :) Cheers, -- Alan Pope Community Manager Canonical - Ubuntu Engineering and Services +44 (0) 7973 620 164 alan.pope at canonical.com http://ubuntu.com/ From leo.arias at canonical.com Fri Jan 27 14:46:05 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 27 Jan 2017 08:46:05 -0600 Subject: Relationship between snaps and containers, if any In-Reply-To: References: <1212848131.76057.1485302022332.ref@mail.yahoo.com> <1212848131.76057.1485302022332@mail.yahoo.com> <776644856.1114726.1485413089994@mail.yahoo.com> <60fd56de-f6bf-38b7-6848-ddecbc728dda@ubuntu.com> Message-ID: This is a common question, one of the yarn developers just asked this. It would be great to have a nice answer here, to add to our FAQ: http://askubuntu.com/questions/808524/whats-the-main-difference-between-docker-and-snap If somebody has something to add there, please go ahead. pura vida. From jamie.bennett at canonical.com Fri Jan 27 14:47:19 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Fri, 27 Jan 2017 14:47:19 +0000 Subject: Snaps are not just for the serious things ... In-Reply-To: References: Message-ID: > On 27 Jan 2017, at 14:44, Alan Pope wrote: > > Hi, > > Happy Friday everyone. > > I discovered 'bucklespring' in the snap store recently. You may enjoy it too... > > https://www.youtube.com/watch?v=4cp6j42NXnM Love this! > We need more of these kinds of fun things :) > > Cheers, > -- > Alan Pope > Community Manager > > Canonical - Ubuntu Engineering and Services > +44 (0) 7973 620 164 > alan.pope at canonical.com > http://ubuntu.com/ > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirkland at canonical.com Fri Jan 27 14:52:34 2017 From: kirkland at canonical.com (Dustin Kirkland) Date: Fri, 27 Jan 2017 08:52:34 -0600 Subject: Snaps are not just for the serious things ... In-Reply-To: References: Message-ID: If *ever* there was an app, begging to be a keylogger, this is it :-) Dustin Kirkland Ubuntu Product & Strategy Canonical, Ltd. On Fri, Jan 27, 2017 at 8:44 AM, Alan Pope wrote: > Hi, > > Happy Friday everyone. > > I discovered 'bucklespring' in the snap store recently. You may enjoy it too... > > https://www.youtube.com/watch?v=4cp6j42NXnM > > We need more of these kinds of fun things :) > > Cheers, > -- > Alan Pope > Community Manager > > Canonical - Ubuntu Engineering and Services > +44 (0) 7973 620 164 > alan.pope at canonical.com > http://ubuntu.com/ > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From matthias.seidel at hamburg.de Fri Jan 27 15:37:47 2017 From: matthias.seidel at hamburg.de (Matthias Seidel) Date: Fri, 27 Jan 2017 16:37:47 +0100 Subject: Snaps are not just for the serious things ... In-Reply-To: References: Message-ID: At the UbuCon last year in Essen I sat in a room together with Marius and some others who were doing REAL SERIOUS work. And me, just launching bucklespring, tapping on my keyboard and giggling... ;-) Am 27.01.2017 um 15:44 schrieb Alan Pope: > Hi, > > Happy Friday everyone. > > I discovered 'bucklespring' in the snap store recently. You may enjoy it too... > > https://www.youtube.com/watch?v=4cp6j42NXnM > > We need more of these kinds of fun things :) > > Cheers, -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: From jcoates at extremenetworks.com Fri Jan 27 16:07:49 2017 From: jcoates at extremenetworks.com (Joe Coates) Date: Fri, 27 Jan 2017 16:07:49 +0000 Subject: DHCP and /etc/resolv.conf In-Reply-To: <1485353488.10013.2.camel@canonical.com> References: , <1485353488.10013.2.camel@canonical.com> Message-ID: Thanks for the great turnaround! ________________________________________ From: snapcraft-bounces at lists.snapcraft.io on behalf of Jamie Strandboge Sent: Wednesday, January 25, 2017 9:11:28 AM To: Snapcraft Subject: Re: DHCP and /etc/resolv.conf On Mon, 2017-01-16 at 21:39 +0000, Joe Coates wrote: > I'm snapping an app which includes a DHCP client replacement. Ultimately it > wants to update/replace /etc/resolv.conf. My snap is connected to all the > "network" interfaces available in my ubuntu-core, but none seem to allow write > access to this file. Shouldn't an interface like "network-control" allow > write access to /etc/resolv.conf ? > FYI, this is merged in master and the upcoming snapd 2.22 will allow access to resolvconf. -- Jamie Strandboge | http://www.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 adam.stokes at canonical.com Fri Jan 27 17:40:13 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Fri, 27 Jan 2017 17:40:13 +0000 Subject: A UX question about requiring users to pass in --classic Message-ID: Since releasing the conjure-up snap I have gotten a few questions as to why we have to pass in --classic when the snapcraft.yaml defines the confinement mode already. I understand that this is similar to if a user was to snap install a snap that was strictly devmode. We do want make the user aware of what they are installing and any possible caveats that go along with that. Forcing the use of --classic and --devmode make sense in the overall picture, however, cosmetically and user happiness (i guess?) this just seems like a _lot_ of typing. So I'm not arguing the use of --classic or --devmode but what if we take another approach and treat both --classic and --devmode as a 'force/yes' in the apt world and provide a simple Y/n prompt asking the user if they are sure they wish to install said snap because of it's current confinement mode? I much rather advertise running: $ snap install conjure-up And the experience be: Fetching info..checking confinement mode.. This is a classic snap, are you sure you wish to continue? [Y/n] conjure-up installed Thoughts? -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Fri Jan 27 18:34:48 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 27 Jan 2017 12:34:48 -0600 Subject: A UX question about requiring users to pass in --classic In-Reply-To: References: Message-ID: I like it. It's always better to not tell the user to retype what he just typed. Can you please report a bug? From sergio.schvezov at canonical.com Fri Jan 27 18:48:14 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Fri, 27 Jan 2017 18:48:14 +0000 Subject: A UX question about requiring users to pass in --classic In-Reply-To: References: Message-ID: On Fri, 27 Jan 2017 17:40:13 +0000, Adam Stokes wrote: > Since releasing the conjure-up snap I have gotten a few questions as to why > we have to pass in --classic when the snapcraft.yaml defines the > confinement mode already. > > I understand that this is similar to if a user was to snap install a snap > that was strictly devmode. We do want make the user aware of what they are > installing and any possible caveats that go along with that. Forcing the > use of --classic and --devmode make sense in the overall picture, however, > cosmetically and user happiness (i guess?) this just seems like a _lot_ of > typing. > > So I'm not arguing the use of --classic or --devmode but what if we take > another approach and treat both --classic and --devmode as a 'force/yes' in > the apt world and provide a simple Y/n prompt asking the user if they are > sure they wish to install said snap because of it's current confinement > mode? > > I much rather advertise running: > > $ snap install conjure-up This *should* be what you advertise and I think snapd 2.22 solves that. > And the experience be: > > Fetching info..checking confinement mode.. > This is a classic snap, are you sure you wish to continue? [Y/n] > conjure-up installed > > Thoughts? +1 (if on an interactive shell), if not it should fail with a nice message telling me this needs explicit concent as it is a classic confined snap. -- Sent using Dekko from my Ubuntu device From adam.stokes at canonical.com Fri Jan 27 18:57:40 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Fri, 27 Jan 2017 18:57:40 +0000 Subject: A UX question about requiring users to pass in --classic In-Reply-To: References: Message-ID: Thank you all, I filed a bug here: https://bugs.launchpad.net/snapd/+bug/1659925 On Fri, Jan 27, 2017 at 1:49 PM Sergio Schvezov < sergio.schvezov at canonical.com> wrote: > On Fri, 27 Jan 2017 17:40:13 +0000, Adam Stokes wrote: > > Since releasing the conjure-up snap I have gotten a few questions as to > why > > we have to pass in --classic when the snapcraft.yaml defines the > > confinement mode already. > > > > I understand that this is similar to if a user was to snap install a snap > > that was strictly devmode. We do want make the user aware of what they > are > > installing and any possible caveats that go along with that. Forcing the > > use of --classic and --devmode make sense in the overall picture, > however, > > cosmetically and user happiness (i guess?) this just seems like a _lot_ > of > > typing. > > > > So I'm not arguing the use of --classic or --devmode but what if we take > > another approach and treat both --classic and --devmode as a 'force/yes' > in > > the apt world and provide a simple Y/n prompt asking the user if they are > > sure they wish to install said snap because of it's current confinement > > mode? > > > > I much rather advertise running: > > > > $ snap install conjure-up > > This *should* be what you advertise and I think snapd 2.22 solves that. > > > And the experience be: > > > > Fetching info..checking confinement mode.. > > This is a classic snap, are you sure you wish to continue? [Y/n] > > conjure-up installed > > > > Thoughts? > > +1 (if on an interactive shell), if not it should fail with a nice message > telling me this needs explicit concent as it is a classic confined snap. > > -- > Sent using Dekko from my Ubuntu device > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Fri Jan 27 19:32:13 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 27 Jan 2017 13:32:13 -0600 Subject: A UX question about requiring users to pass in --classic In-Reply-To: References: Message-ID: <1485545533.10013.92.camel@canonical.com> On Fri, 2017-01-27 at 17:40 +0000, Adam Stokes wrote: > Since releasing the conjure-up snap I have gotten a few questions as to why > we have to pass in --classic when the snapcraft.yaml defines the > confinement mode already. > > I understand that this is similar to if a user was to snap install a snap > that was strictly devmode. We do want make the user aware of what they are > installing and any possible caveats that go along with that. Forcing the > use of --classic and --devmode make sense in the overall picture, however, > cosmetically and user happiness (i guess?) this just seems like a _lot_ of > typing. > > So I'm not arguing the use of --classic or --devmode but what if we take > another approach and treat both --classic and --devmode as a 'force/yes' in > the apt world and provide a simple Y/n prompt asking the user if they are > sure they wish to install said snap because of it's current confinement > mode? > > I much rather advertise running: > > $ snap install conjure-up > > And the experience be: > > Fetching info..checking confinement mode.. > This is a classic snap, are you sure you wish to continue? [Y/n] > conjure-up installed > AIUI (please correct me) the reason why we have --classic and --devmode is very intentional so that the user has to type and think about what is happening since this is allowing the publisher access to everything on your system. The example text in the prompt you provide doesn't convey this and I worry that what many people will see (regardless of phrasing) is: $ snap install foo blah blah..checking blah blah.. Do you want me to install what you just told me to install? [Y/n] y foo installed -- 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 Jan 27 19:45:07 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Fri, 27 Jan 2017 19:45:07 +0000 Subject: A UX question about requiring users to pass in --classic In-Reply-To: References: Message-ID: On Fri, Jan 27, 2017 at 1:49 PM Sergio Schvezov < sergio.schvezov at canonical.com> wrote: > On Fri, 27 Jan 2017 17:40:13 +0000, Adam Stokes wrote: > > Since releasing the conjure-up snap I have gotten a few questions as to > why > > we have to pass in --classic when the snapcraft.yaml defines the > > confinement mode already. > > > > I understand that this is similar to if a user was to snap install a snap > > that was strictly devmode. We do want make the user aware of what they > are > > installing and any possible caveats that go along with that. Forcing the > > use of --classic and --devmode make sense in the overall picture, > however, > > cosmetically and user happiness (i guess?) this just seems like a _lot_ > of > > typing. > > > > So I'm not arguing the use of --classic or --devmode but what if we take > > another approach and treat both --classic and --devmode as a 'force/yes' > in > > the apt world and provide a simple Y/n prompt asking the user if they are > > sure they wish to install said snap because of it's current confinement > > mode? > > > > I much rather advertise running: > > > > $ snap install conjure-up > > This *should* be what you advertise and I think snapd 2.22 solves that. > Does this mean we don't require users to 'snap login' anymore? > > > And the experience be: > > > > Fetching info..checking confinement mode.. > > This is a classic snap, are you sure you wish to continue? [Y/n] > > conjure-up installed > > > > Thoughts? > > +1 (if on an interactive shell), if not it should fail with a nice message > telling me this needs explicit concent as it is a classic confined snap. > > -- > Sent using Dekko from my Ubuntu device > > -- > 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 tyhicks at canonical.com Fri Jan 27 20:37:16 2017 From: tyhicks at canonical.com (Tyler Hicks) Date: Fri, 27 Jan 2017 14:37:16 -0600 Subject: A UX question about requiring users to pass in --classic In-Reply-To: <1485545533.10013.92.camel@canonical.com> References: <1485545533.10013.92.camel@canonical.com> Message-ID: <25051e0c-6fe0-51d0-f2d9-bcf86cf842c9@canonical.com> On 01/27/2017 01:32 PM, Jamie Strandboge wrote: > On Fri, 2017-01-27 at 17:40 +0000, Adam Stokes wrote: >> Since releasing the conjure-up snap I have gotten a few questions as to why >> we have to pass in --classic when the snapcraft.yaml defines the >> confinement mode already. >> >> I understand that this is similar to if a user was to snap install a snap >> that was strictly devmode. We do want make the user aware of what they are >> installing and any possible caveats that go along with that. Forcing the >> use of --classic and --devmode make sense in the overall picture, however, >> cosmetically and user happiness (i guess?) this just seems like a _lot_ of >> typing. >> >> So I'm not arguing the use of --classic or --devmode but what if we take >> another approach and treat both --classic and --devmode as a 'force/yes' in >> the apt world and provide a simple Y/n prompt asking the user if they are >> sure they wish to install said snap because of it's current confinement >> mode? >> >> I much rather advertise running: >> >> $ snap install conjure-up >> >> And the experience be: >> >> Fetching info..checking confinement mode.. >> This is a classic snap, are you sure you wish to continue? [Y/n] >> conjure-up installed >> > AIUI (please correct me) the reason why we have --classic and --devmode is very > intentional so that the user has to type and think about what is happening since > this is allowing the publisher access to everything on your system. The example > text in the prompt you provide doesn't convey this and I worry that what many > people will see (regardless of phrasing) is: > > $ snap install foo > blah blah..checking blah blah.. > Do you want me to install what you just told me to install? [Y/n] y > foo installed You're correct. Not only will it become click-through security but it'll also make it more appealing to simply not care about achieving proper confinement with your snap. I'm more worried about --devmode in that regard but it is also something to consider for --classic. Tyler -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From leo.arias at canonical.com Fri Jan 27 20:41:26 2017 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 27 Jan 2017 14:41:26 -0600 Subject: A UX question about requiring users to pass in --classic In-Reply-To: <25051e0c-6fe0-51d0-f2d9-bcf86cf842c9@canonical.com> References: <1485545533.10013.92.camel@canonical.com> <25051e0c-6fe0-51d0-f2d9-bcf86cf842c9@canonical.com> Message-ID: Thanks! I've copied your comments in the bug. From manik at canonical.com Fri Jan 27 22:41:36 2017 From: manik at canonical.com (Manik Taneja) Date: Fri, 27 Jan 2017 14:41:36 -0800 Subject: Ubuntu Core LXD images available for testing In-Reply-To: <20170127021725.GK5095@dakara> References: <20170127021725.GK5095@dakara> Message-ID: Thank you Stephane. This is super! Cheers, Manik On Thu, Jan 26, 2017 at 6:17 PM, Stéphane Graber wrote: > Hello, > > Today I'm pleased to announce that we have our first Ubuntu Core LXD > images available for testing. > > Those images will be re-generated weekly from whatever is the latest set > of Ubuntu Core disk images. As those disk images aren't refreshed very > often, it means that the LXD images will typically need a good snap > refresh after their first boot. > > I expect this limitation to go away when those LXD images get picked up > by the Ubuntu Cloud team and they make their way to the official Ubuntu > image server as they will then benefit from the same image build pipeline > used for the Ubuntu Cloud images. > > > In the mean time, our test images are available on > https://images.linuxcontainers.org and can be used by any LXD user > running an up to date version of Ubuntu and LXD with: > > lxc launch images:ubuntu-core/16 > > Should you run into any problem with those images, please file a bug here: > https://github.com/lxc/lxc-ci/issues > > > Some extra notes: > - LXD passes your cloud-init configuration to the container. However the > current Ubuntu Core images have cloud-init disabled. So if you intend to > use that LXD facility, you'll need to manually re-enable cloud-init in > your container. > > - This LXD image has a mock bootloader which pretends to be grub. This > allows for the expected upgrade experience to work. Updates to the core > snap will be attempted on the following boot and reverted on failure. > > - Using snaps inside LXD containers only works for unprivileged > containers. Setting security.privileged to true on your container will > break it. This is due to the way Apparmor namespacing works. > > - Normal LXD security policies apply. So if you intend to install the > LXD snap inside your Ubuntu Core container, you'll need to set > security.nesting to true. > > - As mentioned, those images are meant for testing use. Supported > production images will soon be available on the official Ubuntu image > server and will be based on those generated for the cloud. > > Enjoy! > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri Jan 27 14:31:45 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 27 Jan 2017 14:31:45 +0000 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: On 26/01/17 23:58, Neal Gompa wrote: > On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth wrote: >> We should allow a plaintext field there for this situation. Yes, go >> ahead with "Other open source". >> > It would probably make sense to support SPDX license tags and > expressions[1]. > > [1]: https://spdx.org/licenses/ > [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List +1 From roger.peppe at canonical.com Sat Jan 28 18:24:46 2017 From: roger.peppe at canonical.com (roger peppe) Date: Sat, 28 Jan 2017 18:24:46 +0000 Subject: Raspberry Pi hardware real-time-clock? In-Reply-To: <1483182905.18985.14.camel@ubuntu.com> References: <1482951518.25946.5.camel@ubuntu.com> <1483182905.18985.14.camel@ubuntu.com> Message-ID: On 31 December 2016 at 11:15, Oliver Grawert wrote: > no worries, we'll get it working, but it might take a bit to find all > the pieces needed and make sure they work correctly, this is simply a > hw setup that has not come around yet ;) Any update on this, or suggestions as to how I might move this forward? For the next week or so I'm at the site where I'm planning to deploy the Pi as a controller and it would be great if I could leave it deployed with a working RTC-backed system clock. I have spare time to contribute if needed. cheers, rog. From anton at huge.geek.nz Sun Jan 29 13:52:02 2017 From: anton at huge.geek.nz (Anton Smith) Date: Sun, 29 Jan 2017 14:52:02 +0100 Subject: Snap Health checks/monitoring running status Message-ID: I got a question that I couldn't find any answers to on google/mailing lists etc. How do you keep a snap application alive, i.e. let's say I have an FFMPEG session that needs to run 24/7 (recording a camera), and on occasion it crashes. Traditionally I have used monit to "watch it" and restart it when it dies. How does this work with snaps? Regards, Anton -------------- next part -------------- An HTML attachment was scrubbed... URL: From luca.dionisi at gmail.com Sun Jan 29 14:18:37 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Sun, 29 Jan 2017 15:18:37 +0100 Subject: Snap Health checks/monitoring running status In-Reply-To: References: Message-ID: Have a look here: https://tutorials.ubuntu.com/tutorial/build-a-nodejs-service --Luca On Sun, Jan 29, 2017 at 2:52 PM, Anton Smith wrote: > I got a question that I couldn't find any answers to on google/mailing lists > etc. > > How do you keep a snap application alive, i.e. let's say I have an FFMPEG > session that needs to run 24/7 (recording a camera), and on occasion it > crashes. Traditionally I have used monit to "watch it" and restart it when > it dies. > > How does this work with snaps? > > Regards, > Anton > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From joseph.wakeling at webdrake.net Sun Jan 29 18:48:39 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 29 Jan 2017 19:48:39 +0100 Subject: Classic snap for D reference compiler DMD Message-ID: <403025d2-10e3-e74f-1836-472cf414922d@webdrake.net> Hello all, Following successes snapping LDC (the LLVM-based D compiler) and DUB (a build and package manager for D projects), I decided to turn my attention to the D programming language's reference compiler, DMD. This is in principle a rather trickier project: while LDC uses a very nice and simple cmake build system, which requires little manual intervention, building DMD actually involves building code from 3 different git repos, each of which relies on the output of its predecessors. Anyway, everyone here has obviously been very good at teaching me the tricks of the snapcraft trade (for which, thank you!), because in practice this was very, very easy, and the results are here: https://github.com/WebDrake/dmd.snap/pull/1 ... where as you can see a combination of `after:`, `make-parameters:` and the occasional `organize:` and `stage:` were all that was necessary to get things working right. Nevertheless, I have a few questions, so here goes. First: the dmd install includes manpages, which wind up being placed in `/snap/dmd/current/man`, but the host system `man` command can't find them (not a big surprise). Any advice on whether it would be possible to get this working? Second: the `source-tag:` settings for the 3 parts should all match. Is there any way of defining a common value that they can all use (to make sure that in future there is less risk of accidentally failing to update one of them)? Thanks and best wishes, -- Joe From michael.hudson at canonical.com Sun Jan 29 20:37:29 2017 From: michael.hudson at canonical.com (Michael Hudson-Doyle) Date: Mon, 30 Jan 2017 09:37:29 +1300 Subject: Classic snap for D reference compiler DMD In-Reply-To: <403025d2-10e3-e74f-1836-472cf414922d@webdrake.net> References: <403025d2-10e3-e74f-1836-472cf414922d@webdrake.net> Message-ID: On 30 January 2017 at 07:48, Joseph Rushton Wakeling < joseph.wakeling at webdrake.net> wrote: > Hello all, > [...] > Second: the `source-tag:` settings for the 3 parts should all match. Is > there any way of defining a common value that they can all use (to make > sure that in future there is less risk of accidentally failing to update > one of them)? > You can do this just using yaml features: mwhudson at aeglos:~/tmp$ cat foo.yaml parts: part-a: source-tag: &the-tag v1.7 part-b: source-tag: *the-tag part-c: source-tag: *the-tag mwhudson at aeglos:~/tmp$ python3 -c 'import yaml;print(yaml.dump(yaml.load(open("foo.yaml"))))' parts: part-a: {source-tag: v1.7} part-b: {source-tag: v1.7} part-c: {source-tag: v1.7} Cheers, mwh -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.wakeling at webdrake.net Sun Jan 29 21:42:16 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Sun, 29 Jan 2017 22:42:16 +0100 Subject: Classic snap for D reference compiler DMD In-Reply-To: References: <403025d2-10e3-e74f-1836-472cf414922d@webdrake.net> Message-ID: <1aac3e1d-69c6-ec8b-eab2-9ef3145cacee@webdrake.net> On 29/01/17 21:37, Michael Hudson-Doyle wrote: > You can do this just using yaml features: Great, thanks! Exactly what I was looking for. :-) From spencertparkin at gmail.com Mon Jan 30 06:56:11 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Sun, 29 Jan 2017 23:56:11 -0700 Subject: glGetUniformLocation fails in confinement mode Message-ID: Hi, I have a program that has successfully snapped and run in confinement mode, but then I added a pixel and vertex shader which works when run on my classic system, but not in strict confinement as a snap. I've tried to narrow down the earliest fail point, and I believe it is at the point where I'm calling glGetUniformFromLocation. This is returning -1 in confinement mode. I'm able to read, compile and link my shader program, and bind it, but the first call to glGetUniformFromLocation fails. Is OpenGL being denied read-access to a portion of protected memory? If so, it certainly would fail to write there as well with a call to glUniform3f, for example. I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu core's, then running the scanlog, but the only app-armer denial I get is, I believe, unrelated to the problem. In any case, I will give it here... Log: apparmer="DENIED" operation="open" profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/" pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000 ouid=0 File: /usr/share/glib-2.0/schemas/ (read) Hmmm. After looking up "glib" on the internet, perhaps this is the problem? It seems like a generic low-level library that OpenGL extensions may be built upon. I have uploaded my snap on the release channel despite this error. You can take a look at it using... sudo snap install twistypuzzle Thanks for any help or ideas anyone is able to provide in trying to trouble-shoot this problem. I have no idea how to go further with this for now. My code can be found here... https://github.com/spencerparkin/TwistyPuzzle Thanks, --Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: From timo.jyrinki at gmail.com Mon Jan 30 12:26:35 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Mon, 30 Jan 2017 14:26:35 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 Message-ID: Hi, ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around 5 months of upstream LTS bugfixes. It passed QA and everything seems to work normally, but you might find some pet bug to be fixed. Since this is the first point release update done in ubuntu-app-platform I thought to do an announcement. To recap, the platform snap is mostly to be used by apps that target Ubuntu Personal and require a shared Qt with backported patches and other libraries. For most Qt applications snappers, either simply staging from archives or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are probably more interesting. See the blog post at https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for more information. Qt 5.6.3 should follow in 6 months or so. -Timo From matthias.seidel at hamburg.de Mon Jan 30 12:54:01 2017 From: matthias.seidel at hamburg.de (Matthias Seidel) Date: Mon, 30 Jan 2017 13:54:01 +0100 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: Just a quick note: Ubuntu-calculator-app doesn't work anymore: seidel at Seidel-ThinkPad:~$ ubuntu-calculator-app QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries. qml: PageWithBottomEdge_QMLTYPE_29_QML_47(0x1568670)"Calculator": In Ubuntu.Components 1.3, the use of Page.title, Page.flickable and Page.head is deprecated. Use Page.header and the PageHeader component instead. qml: Database upgraded to 1 qml: [LOG]: Detecting first time run by user. Starting welcome wizard. XmbTextListToTextProperty result code -2 Speicherzugriffsfehler (Speicherabzug geschrieben) Kind regards, Matthias Am 30.01.2017 um 13:26 schrieb Timo Jyrinki: > Hi, > > ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around > 5 months of upstream LTS bugfixes. It passed QA and everything seems > to work normally, but you might find some pet bug to be fixed. Since > this is the first point release update done in ubuntu-app-platform I > thought to do an announcement. > > To recap, the platform snap is mostly to be used by apps that target > Ubuntu Personal and require a shared Qt with backported patches and > other libraries. > > For most Qt applications snappers, either simply staging from archives > or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are > probably more interesting. See the blog post at > https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for > more information. > > Qt 5.6.3 should follow in 6 months or so. > > -Timo > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: From dpniel at ubuntu.com Mon Jan 30 13:01:03 2017 From: dpniel at ubuntu.com (Dan Chapman) Date: Mon, 30 Jan 2017 13:01:03 +0000 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: Hi Timo, How are apps using ubuntu-app-platform supposed to handle this? This change has left all apps currently using ubuntu-app-platform unusable without a rebuild of the consuming snap. Which is a rather unpleasant UX and causes unnecessary issues for the developers. Should it not be that the contents of the ubuntu-app-platform snap never change without a change to the name? i.e ubuntu-app-platform2. Otherwise there is always going to be an endless cycle of broken snaps because developers weren't around to rebuild every 6 months or so. Cheers Dan On Mon, 30 Jan 2017 14:26:35 +0200, Timo Jyrinki wrote: > Hi, > > ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around > 5 months of upstream LTS bugfixes. It passed QA and everything seems > to work normally, but you might find some pet bug to be fixed. Since > this is the first point release update done in ubuntu-app-platform I > thought to do an announcement. > > To recap, the platform snap is mostly to be used by apps that target > Ubuntu Personal and require a shared Qt with backported patches and > other libraries. > > For most Qt applications snappers, either simply staging from archives > or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are > probably more interesting. See the blog post at > https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for > more information. > > Qt 5.6.3 should follow in 6 months or so. > > -Timo > -- Sent using Dekko from my Ubuntu device From timo.jyrinki at canonical.com Mon Jan 30 13:33:54 2017 From: timo.jyrinki at canonical.com (Timo Jyrinki) Date: Mon, 30 Jan 2017 15:33:54 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: Hi Dan (and Matthias), We tested among else webbrowser, UITK gallery and calendar app and they run fine. We didn't anticipate problems, but as there are this would then be the point to introduce "ubuntu-app-platform2" (currently at ubuntu-app-platform1) as it seems that it's not the drop in replacement hoped for. Even though at this point I'm unsure what's causing the problem as there are no API changes to speak of. So far we have already been adding libraries and upgrading for example Oxide while keeping the "ubuntu-app-platform1". I will bump the content field to "2" now. -Timo On Mon, Jan 30, 2017 at 3:01 PM, Dan Chapman wrote: > Hi Timo, > > How are apps using ubuntu-app-platform supposed to handle this? > > This change has left all apps currently using ubuntu-app-platform unusable without a rebuild of the consuming snap. Which is a rather unpleasant UX and causes unnecessary issues for the developers. > > Should it not be that the contents of the ubuntu-app-platform snap never change without a change to the name? i.e ubuntu-app-platform2. Otherwise there is always going to be an endless > cycle of broken snaps because developers weren't around to rebuild every 6 months or so. > > Cheers > > Dan > > On Mon, 30 Jan 2017 14:26:35 +0200, Timo Jyrinki wrote: >> Hi, >> >> ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around >> 5 months of upstream LTS bugfixes. It passed QA and everything seems >> to work normally, but you might find some pet bug to be fixed. Since >> this is the first point release update done in ubuntu-app-platform I >> thought to do an announcement. >> >> To recap, the platform snap is mostly to be used by apps that target >> Ubuntu Personal and require a shared Qt with backported patches and >> other libraries. >> >> For most Qt applications snappers, either simply staging from archives >> or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are >> probably more interesting. See the blog post at >> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for >> more information. >> >> Qt 5.6.3 should follow in 6 months or so. >> >> -Timo >> > > -- > Sent using Dekko from my Ubuntu device > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From timo.jyrinki at gmail.com Mon Jan 30 13:44:23 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Mon, 30 Jan 2017 15:44:23 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: ubuntu-calculator-app seems to be broken with the previous stable #22 too though, with a similar error report. We did notice that too now that I read the chat log, but didn't consider for this upgrade as it seemed to be the status quo. But just in case, and as per Dan's e-mail indicating also a problem in some app, I reverted Stable channel back to the #22 and will bump the content: field to ubuntu-app-platform2 and version to 2. However, I'm not aware of store support of supporting two such different versions in stable channel at the same time, so I'm currently unsure how this would work without renaming the whole package too. Until I know more, I'll keep the stable at #22 and the upcoming #26 in the other channels. -Timo 2017-01-30 14:54 GMT+02:00 Matthias Seidel : > Just a quick note: > > Ubuntu-calculator-app doesn't work anymore: > > seidel at Seidel-ThinkPad:~$ ubuntu-calculator-app > QGtkStyle could not resolve GTK. Make sure you have installed the proper > libraries. > qml: PageWithBottomEdge_QMLTYPE_29_QML_47(0x1568670)"Calculator": In > Ubuntu.Components 1.3, the use of Page.title, Page.flickable and > Page.head is deprecated. Use Page.header and the PageHeader component > instead. > qml: Database upgraded to 1 > qml: [LOG]: Detecting first time run by user. Starting welcome wizard. > XmbTextListToTextProperty result code -2 > Speicherzugriffsfehler (Speicherabzug geschrieben) > > Kind regards, Matthias > > > Am 30.01.2017 um 13:26 schrieb Timo Jyrinki: >> Hi, >> >> ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around >> 5 months of upstream LTS bugfixes. It passed QA and everything seems >> to work normally, but you might find some pet bug to be fixed. Since >> this is the first point release update done in ubuntu-app-platform I >> thought to do an announcement. >> >> To recap, the platform snap is mostly to be used by apps that target >> Ubuntu Personal and require a shared Qt with backported patches and >> other libraries. >> >> For most Qt applications snappers, either simply staging from archives >> or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are >> probably more interesting. See the blog post at >> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for >> more information. >> >> Qt 5.6.3 should follow in 6 months or so. >> >> -Timo >> > > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > From stephen.webb at canonical.com Mon Jan 30 13:47:56 2017 From: stephen.webb at canonical.com (Stephen M. Webb) Date: Mon, 30 Jan 2017 08:47:56 -0500 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: References: Message-ID: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> On 2017-01-30 01:56 AM, Spencer Parkin wrote: > > I have a program that has successfully snapped and run in confinement mode, but then I added a pixel and vertex shader > which works when run on my classic system, but not in strict confinement as a snap. I've tried to narrow down the > earliest fail point, and I believe it is at the point where I'm calling glGetUniformFromLocation. This is returning -1 > in confinement mode. I'm able to read, compile and link my shader program, and bind it, but the first call to > glGetUniformFromLocation fails. Is OpenGL being denied read-access to a portion of protected memory? If so, it > certainly would fail to write there as well with a call to glUniform3f, for example. > > I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu core's, then running the scanlog, but the > only app-armer denial I get is, I believe, unrelated to the problem. In any case, I will give it here... > > Log: apparmer="DENIED" operation="open" profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/" > pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000 ouid=0 > File: /usr/share/glib-2.0/schemas/ (read) That error message is because the launcher program "desktop-launch" can not find the gsettings. I don't know what impact that will have (if any) but it's not going to affect how OpenGL works internally. Your glGetUniformFromLocation() sounds more like you haven't compiled the shader. You code contains no error handling if the shader file itself is not found, only if the shader file is found and fails to compile. My guess is the shader sources are not getting found under confinement. -- Stephen M. Webb From michael.vogt at canonical.com Mon Jan 30 13:48:25 2017 From: michael.vogt at canonical.com (Michael Vogt) Date: Mon, 30 Jan 2017 14:48:25 +0100 Subject: New snapd 2.22 release Message-ID: <20170130134825.GA23432@bod> Hello everyone, after slightly more than two weeks we have a new release of snapd! We are happy to announce the new snapd 2.22. One of the most important aspects of this release is that we transition users who have the "ubuntu-core" snap installed over to the new "core" snap. It should be totally transparent and you will only notice if you look into `snap changes`. But if you notice any issues, please do let us know! Some highlights: - automatically transition ubuntu-core snaps to core - support for X-Ayatana-Desktop-Shortcuts in desktop files - improve retry handling on network errors further - support for disabling sshd from the core config - support new "reload-command" in snap.yaml - fix snap try with classic confinement - many more bugfixes - interface improvements: - opengl, default, network-control, network-manager - new interfaces: - unity8-download-manager, evolution, account-control, core-support This release is uploaded to the Ubuntu 14.04/16.04/16.10 "proposed" pocket. It is also available in 17.04 and in the "candidate" channel for the "core" and "ubuntu-core" snaps. Other distros will follow shortly. The stable channel continues to have the 2.21 version. If you would like to test out this new snapd version on your Ubuntu Core device you can use the command: $ snap refresh --candidate core On the classic distribution you can help testing by enabling -proposed and then installing snapd [1]. Enjoy the new release! And as always, plese get in touch if you notice any issues or if you have suggestions for improvements. Cheers, Michael [1] https://wiki.ubuntu.com/Testing/EnableProposed From marco.ceppi at canonical.com Mon Jan 30 13:58:27 2017 From: marco.ceppi at canonical.com (Marco Ceppi) Date: Mon, 30 Jan 2017 13:58:27 +0000 Subject: GEM/Ruby snapcraft plugin? Message-ID: Hi all, I've recently had to share a lot of code via Github gists which renders my previous `pastebinit` workflow hindered. There's a gist[0] command, but it's a Gem/Ruby project and I'm not too keen on jumping through hoops to use gem on my laptop. I didn't notice any gem plugins for snapcraft, is there one planned? If not I may try to figure one out. [0]: http://defunkt.io/gist/ Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpniel at ubuntu.com Mon Jan 30 14:01:26 2017 From: dpniel at ubuntu.com (Dan Chapman) Date: Mon, 30 Jan 2017 14:01:26 +0000 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: <8y9zp2.okliyg.1hge19r-qmf@smtp.gmail.com> Thanks for the quick response! FTR https://bugs.launchpad.net/canonical-devices-system-image/+bug/1660016 is the bug report for the issue I mentioned. I'd be interested to hear how the change in version will be handled with the store etc once you know more ;) Cheers Dan On Mon, 30 Jan 2017 15:44:23 +0200, Timo Jyrinki wrote: > ubuntu-calculator-app seems to be broken with the previous stable #22 > too though, with a similar error report. We did notice that too now > that I read the chat log, but didn't consider for this upgrade as it > seemed to be the status quo. > > But just in case, and as per Dan's e-mail indicating also a problem in > some app, I reverted Stable channel back to the #22 and will bump the > content: field to ubuntu-app-platform2 and version to 2. > > However, I'm not aware of store support of supporting two such > different versions in stable channel at the same time, so I'm > currently unsure how this would work without renaming the whole > package too. Until I know more, I'll keep the stable at #22 and the > upcoming #26 in the other channels. > > -Timo > > 2017-01-30 14:54 GMT+02:00 Matthias Seidel : >> Just a quick note: >> >> Ubuntu-calculator-app doesn't work anymore: >> >> seidel at Seidel-ThinkPad:~$ ubuntu-calculator-app >> QGtkStyle could not resolve GTK. Make sure you have installed the proper >> libraries. >> qml: PageWithBottomEdge_QMLTYPE_29_QML_47(0x1568670)"Calculator": In >> Ubuntu.Components 1.3, the use of Page.title, Page.flickable and >> Page.head is deprecated. Use Page.header and the PageHeader component >> instead. >> qml: Database upgraded to 1 >> qml: [LOG]: Detecting first time run by user. Starting welcome wizard. >> XmbTextListToTextProperty result code -2 >> Speicherzugriffsfehler (Speicherabzug geschrieben) >> >> Kind regards, Matthias >> >> >> Am 30.01.2017 um 13:26 schrieb Timo Jyrinki: >>> Hi, >>> >>> ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around >>> 5 months of upstream LTS bugfixes. It passed QA and everything seems >>> to work normally, but you might find some pet bug to be fixed. Since >>> this is the first point release update done in ubuntu-app-platform I >>> thought to do an announcement. >>> >>> To recap, the platform snap is mostly to be used by apps that target >>> Ubuntu Personal and require a shared Qt with backported patches and >>> other libraries. >>> >>> For most Qt applications snappers, either simply staging from archives >>> or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are >>> probably more interesting. See the blog post at >>> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for >>> more information. >>> >>> Qt 5.6.3 should follow in 6 months or so. >>> >>> -Timo >>> >> >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> > -- Sent using Dekko from my Ubuntu device From adam.stokes at canonical.com Mon Jan 30 14:33:06 2017 From: adam.stokes at canonical.com (Adam Stokes) Date: Mon, 30 Jan 2017 14:33:06 +0000 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: There isn't a plugin yet and I did ask Sergio about this at our last sprint. AFAIK there isn't one planned and I would be willing to collaborate with you to get one written and merged upstream. On Mon, Jan 30, 2017 at 8:59 AM Marco Ceppi wrote: > Hi all, > > I've recently had to share a lot of code via Github gists which renders my > previous `pastebinit` workflow hindered. There's a gist[0] command, but > it's a Gem/Ruby project and I'm not too keen on jumping through hoops to > use gem on my laptop. > > I didn't notice any gem plugins for snapcraft, is there one planned? If > not I may try to figure one out. > > [0]: http://defunkt.io/gist/ > > Marco > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Mon Jan 30 14:33:50 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 30 Jan 2017 14:33:50 +0000 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: On Mon, 30 Jan 2017 15:33:54 +0200, Timo Jyrinki wrote: > Hi Dan (and Matthias), > > We tested among else webbrowser, UITK gallery and calendar app and > they run fine. We didn't anticipate problems, but as there are this > would then be the point to introduce "ubuntu-app-platform2" (currently > at ubuntu-app-platform1) as it seems that it's not the drop in > replacement hoped for. Even though at this point I'm unsure what's > causing the problem as there are no API changes to speak of. > > So far we have already been adding libraries and upgrading for example > Oxide while keeping the "ubuntu-app-platform1". I will bump the > content field to "2" now. Same for $ ubuntu-terminal-app ... ... Cannot mix incompatible Qt library (version 0x50602) with this library (version 0x50601) Aborted (core dumped) -- Sent using Dekko from my Ubuntu device From jamie at canonical.com Mon Jan 30 14:39:11 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Mon, 30 Jan 2017 08:39:11 -0600 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> References: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> Message-ID: <1485787151.10013.118.camel@canonical.com> On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote: > On 2017-01-30 01:56 AM, Spencer Parkin wrote: > > > > > > I have a program that has successfully snapped and run in confinement mode, > > but then I added a pixel and vertex shader > > which works when run on my classic system, but not in strict confinement as > > a snap.  I've tried to narrow down the > > earliest fail point, and I believe it is at the point where I'm calling > > glGetUniformFromLocation.  This is returning -1 > > in confinement mode.  I'm able to read, compile and link my shader program, > > and bind it, but the first call to > > glGetUniformFromLocation fails.  Is OpenGL being denied read-access to a > > portion of protected memory?  If so, it > > certainly would fail to write there as well with a call to glUniform3f, for > > example. > > > > I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu > > core's, then running the scanlog, but the > > only app-armer denial I get is, I believe, unrelated to the problem.  In any > > case, I will give it here... > > > > Log: apparmer="DENIED" operation="open" > > profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/" > > pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000 > > ouid=0 > > File: /usr/share/glib-2.0/schemas/ (read) > That error message is because the launcher program "desktop-launch" can not > find the gsettings.  I don't know what > impact that will have (if any) but it's not going to affect how OpenGL works > internally. > AIUI, the desktop part is doing this as part of its bootstrap to generate what it needs in ~/snap/SNAP_NAME/SNAP_REVISION and it will only do this the first time a new revision of the snap is launched. This denial is harmless and should only happen on classic (since /usr/share/glib-2.0/schemas doesn't exist on Ubuntu Core). While harmless, it is also confusing. I'm not super familiar with the desktop part and wonder how we can improve this. Didier or Seb, would the bootstrapping process work ok if we allowed read on the /usr/share/glib-2.0/schemas/ directory in the unity7 (and maybe the x11) transitional classic interfaces? -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From timo.jyrinki at gmail.com Mon Jan 30 15:01:37 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Mon, 30 Jan 2017 17:01:37 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: <8y9zp2.okliyg.1hge19r-qmf@smtp.gmail.com> References: <8y9zp2.okliyg.1hge19r-qmf@smtp.gmail.com> Message-ID: Thanks for the bug! That might be a more complicated issue if there are multiple sources of Qt modules like QPA plugins in use. The overlay PPA is however harmonized to 5.6.2 already. Apps itselves should not be directly affected as the Qt internal version conflict detection only covers Qt modules. The current store models implies a new renamed package for the intended bump, but let's see if that is done now or at some later point. -Timo maanantai 30. tammikuuta 2017 Dan Chapman kirjoitti: > Thanks for the quick response! > > FTR https://bugs.launchpad.net/canonical-devices-system-image/+bug/1660016 is the bug > report for the issue I mentioned. > > I'd be interested to hear how the change in version will be handled with the store > etc once you know more ;) > > Cheers > > Dan > > On Mon, 30 Jan 2017 15:44:23 +0200, Timo Jyrinki wrote: >> ubuntu-calculator-app seems to be broken with the previous stable #22 >> too though, with a similar error report. We did notice that too now >> that I read the chat log, but didn't consider for this upgrade as it >> seemed to be the status quo. >> >> But just in case, and as per Dan's e-mail indicating also a problem in >> some app, I reverted Stable channel back to the #22 and will bump the >> content: field to ubuntu-app-platform2 and version to 2. >> >> However, I'm not aware of store support of supporting two such >> different versions in stable channel at the same time, so I'm >> currently unsure how this would work without renaming the whole >> package too. Until I know more, I'll keep the stable at #22 and the >> upcoming #26 in the other channels. >> >> -Timo >> >> 2017-01-30 14:54 GMT+02:00 Matthias Seidel : >>> Just a quick note: >>> >>> Ubuntu-calculator-app doesn't work anymore: >>> >>> seidel at Seidel-ThinkPad:~$ ubuntu-calculator-app >>> QGtkStyle could not resolve GTK. Make sure you have installed the proper >>> libraries. >>> qml: PageWithBottomEdge_QMLTYPE_29_QML_47(0x1568670)"Calculator": In >>> Ubuntu.Components 1.3, the use of Page.title, Page.flickable and >>> Page.head is deprecated. Use Page.header and the PageHeader component >>> instead. >>> qml: Database upgraded to 1 >>> qml: [LOG]: Detecting first time run by user. Starting welcome wizard. >>> XmbTextListToTextProperty result code -2 >>> Speicherzugriffsfehler (Speicherabzug geschrieben) >>> >>> Kind regards, Matthias >>> >>> >>> Am 30.01.2017 um 13:26 schrieb Timo Jyrinki: >>>> Hi, >>>> >>>> ubuntu-app-platform #26 has Qt 5.6.2 (up from 5.6.1), including around >>>> 5 months of upstream LTS bugfixes. It passed QA and everything seems >>>> to work normally, but you might find some pet bug to be fixed. Since >>>> this is the first point release update done in ubuntu-app-platform I >>>> thought to do an announcement. >>>> >>>> To recap, the platform snap is mostly to be used by apps that target >>>> Ubuntu Personal and require a shared Qt with backported patches and >>>> other libraries. >>>> >>>> For most Qt applications snappers, either simply staging from archives >>>> or using the Qt 5.7 / 5.8 cloud parts offering pure upstream Qt are >>>> probably more interesting. See the blog post at >>>> https://developer.ubuntu.com/en/blog/2016/11/16/snapping-qt-apps/ for >>>> more information. >>>> >>>> Qt 5.6.3 should follow in 6 months or so. >>>> >>>> -Timo >>>> >>> >>> >>> >>> -- >>> Snapcraft mailing list >>> Snapcraft at lists.snapcraft.io >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> >> > > -- > Sent using Dekko from my Ubuntu device > > -- > 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 spencertparkin at gmail.com Mon Jan 30 15:50:17 2017 From: spencertparkin at gmail.com (Spencer) Date: Mon, 30 Jan 2017 08:50:17 -0700 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> References: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> Message-ID: Oh, you're right! I don't know why I silently fail when the file doesn't exist. That was stupid. And I can see that I'm installing all resource files except for the shaders directory. That's the problem. My bad; I'm an idiot. Thanks. I'll resnap later today after work when I get the chance between toddler screams and house work. > On Jan 30, 2017, at 6:47 AM, Stephen M. Webb wrote: > >> On 2017-01-30 01:56 AM, Spencer Parkin wrote: >> >> I have a program that has successfully snapped and run in confinement mode, but then I added a pixel and vertex shader >> which works when run on my classic system, but not in strict confinement as a snap. I've tried to narrow down the >> earliest fail point, and I believe it is at the point where I'm calling glGetUniformFromLocation. This is returning -1 >> in confinement mode. I'm able to read, compile and link my shader program, and bind it, but the first call to >> glGetUniformFromLocation fails. Is OpenGL being denied read-access to a portion of protected memory? If so, it >> certainly would fail to write there as well with a call to glUniform3f, for example. >> >> I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu core's, then running the scanlog, but the >> only app-armer denial I get is, I believe, unrelated to the problem. In any case, I will give it here... >> >> Log: apparmer="DENIED" operation="open" profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/" >> pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000 ouid=0 >> File: /usr/share/glib-2.0/schemas/ (read) > > That error message is because the launcher program "desktop-launch" can not find the gsettings. I don't know what > impact that will have (if any) but it's not going to affect how OpenGL works internally. > > Your glGetUniformFromLocation() sounds more like you haven't compiled the shader. You code contains no error handling > if the shader file itself is not found, only if the shader file is found and fails to compile. My guess is the shader > sources are not getting found under confinement. > > -- > Stephen M. Webb > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From spencertparkin at gmail.com Mon Jan 30 15:57:50 2017 From: spencertparkin at gmail.com (Spencer) Date: Mon, 30 Jan 2017 08:57:50 -0700 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: References: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> Message-ID: <99E0A072-F489-4943-A5D8-4F51C463B751@gmail.com> Okay, I remember now. I was silently skipping absent shader files because, as I understand it, a shader program may consist of only a vertex program or only a fragment program or some other permutation of vertex, fragment, geometry and compute shaders. In a better API, I would flag the permutation I'm expecting, then barf if that is not what's found on disk. Thanks again for your help. I was kind of hoping it wasn't me being dumb, but alas, it was. > On Jan 30, 2017, at 8:50 AM, Spencer wrote: > > Oh, you're right! I don't know why I silently fail when the file doesn't exist. That was stupid. > > And I can see that I'm installing all resource files except for the shaders directory. That's the problem. > > My bad; I'm an idiot. Thanks. I'll resnap later today after work when I get the chance between toddler screams and house work. > >>> On Jan 30, 2017, at 6:47 AM, Stephen M. Webb wrote: >>> >>> On 2017-01-30 01:56 AM, Spencer Parkin wrote: >>> >>> I have a program that has successfully snapped and run in confinement mode, but then I added a pixel and vertex shader >>> which works when run on my classic system, but not in strict confinement as a snap. I've tried to narrow down the >>> earliest fail point, and I believe it is at the point where I'm calling glGetUniformFromLocation. This is returning -1 >>> in confinement mode. I'm able to read, compile and link my shader program, and bind it, but the first call to >>> glGetUniformFromLocation fails. Is OpenGL being denied read-access to a portion of protected memory? If so, it >>> certainly would fail to write there as well with a call to glUniform3f, for example. >>> >>> I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu core's, then running the scanlog, but the >>> only app-armer denial I get is, I believe, unrelated to the problem. In any case, I will give it here... >>> >>> Log: apparmer="DENIED" operation="open" profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/" >>> pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000 ouid=0 >>> File: /usr/share/glib-2.0/schemas/ (read) >> >> That error message is because the launcher program "desktop-launch" can not find the gsettings. I don't know what >> impact that will have (if any) but it's not going to affect how OpenGL works internally. >> >> Your glGetUniformFromLocation() sounds more like you haven't compiled the shader. You code contains no error handling >> if the shader file itself is not found, only if the shader file is found and fails to compile. My guess is the shader >> sources are not getting found under confinement. >> >> -- >> Stephen M. Webb >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From geoffroy.vancutsem at intel.com Mon Jan 30 16:01:05 2017 From: geoffroy.vancutsem at intel.com (VanCutsem, Geoffroy) Date: Mon, 30 Jan 2017 16:01:05 +0000 Subject: Issue with snapcraft nodejs plugin (and the local npm cache) Message-ID: Hi folks, I've hit an issue building a snap that uses the nodejs plugin. The error displayed on the console is pasted below for your convenience. This used to work up until last Friday, then the nodejs dependency chain for one of the part got updated and a newer version of a dependency is needed (this is expressed via the package.json file). That newer version of the package was also updated recently and is available via the npm registry, but it's not seen by my build system when calling 'snapcraft'. It looks like 'npm' from the 'nodejs' plugin of snapcraft uses a local cache and indefinitely re-uses it as it's given the "--cache-min=Infinity" argument (https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/nodejs.py#L133). Being able to re-use the npm cache is definitely desirable but never refreshing it ever is possibly not the best option for this. Is there a way for the 'nodejs' plugin to handle this more gracefully, perhaps by checking is 'npm outdated' returns any outdated package (that would be needed) and conditionally updating the packages in the dependency chain accordingly? A more brute-force approach would be to just remove that argument from the plugin. In my case, I ended up solving the issue by called 'npm update' directly on my build machine but a more automated mechanism built into snapcraft would be nicer in my opinion. Geoffroy gvancuts at gvancuts-nuc:~/iot-rest-api-server$ snapcraft Preparing to pull meta-iot-web Pulling meta-iot-web >From https://github.com/01org/iot-rest-api-server * branch master -> FETCH_HEAD Already up-to-date. Downloading 'node-v4.4.4-linux-x64.tar.gz'[===========================================================================================================================================================] 100% npm --cache-min=Infinity install npm ERR! Linux 4.4.0-59-generic npm ERR! argv "/home/gvancuts/iot-rest-api-server/parts/meta-iot-web/install/bin/node" "/home/gvancuts/iot-rest-api-server/parts/meta-iot-web/install/bin/npm" "--cache-min=Infinity" "install" npm ERR! node v4.4.4 npm ERR! npm v2.15.1 npm ERR! code ETARGET npm ERR! notarget No compatible version found: iotivity-node@'>=1.2.0-1 <2.0.0' npm ERR! notarget Valid install targets: npm ERR! notarget ["0.9.2-0","0.9.2-1","1.0.0-0","1.0.0-1","1.0.0-2","1.0.0-3","1.0.0-4","1.0.1-0","1.0.1-1","1.1.0-1","1.1.0-2","1.1.0-3","1.1.0-4","1.1.0-5","1.1.1-0","1.1.1-1","1.1.1-2","1.1.1-3","1.2.0-0"] npm ERR! notarget npm ERR! notarget This is most likely not a problem with npm itself. npm ERR! notarget In most cases you or one of your dependencies are requesting npm ERR! notarget a package version that doesn't exist. npm ERR! notarget npm ERR! notarget It was specified as a dependency of 'iot-rest-api-server' npm ERR! notarget npm ERR! Please include the following file with any support request: npm ERR! /home/gvancuts/iot-rest-api-server/parts/meta-iot-web/src/npm-debug.log Command '['/bin/sh', '/tmp/tmpmchipfnc', 'npm', '--cache-min=Infinity', 'install']' returned non-zero exit status 1 Technical Marketing Engineer Manager Open-Source Technology Centre Tel: +32 (0)3 450 0851 ----------------------------------------------- Intel Corporation NV/SA Kings Square, Veldkant 31 2550 Kontich RPM (Bruxelles) 0415.497.718. Citibank, Brussels, account 570/1031255/09 From spencertparkin at gmail.com Mon Jan 30 17:27:31 2017 From: spencertparkin at gmail.com (Spencer Parkin) Date: Mon, 30 Jan 2017 10:27:31 -0700 Subject: [SPAM] snapping with Qt vs. wx Message-ID: Hi, I was just curious what people's preferences were for snaps: Qt or wx? I believe Qt has support for mobile devices, but I don't think wxWidgets does. Other than that, should I switch over to using Qt? I've been a wxWidgets guy for a long time, and I'm a big fan of it. What do you think? Is there something better than either? I've never written a mobile app, but if I did, I might look into the Ubuntu phone platform. I own an iPhone, though. Is Ubuntu phone better? --Spencer -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Mon Jan 30 19:21:13 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Mon, 30 Jan 2017 17:21:13 -0200 Subject: Snap Health checks/monitoring running status In-Reply-To: References: Message-ID: The short answer is that daemons are naturally restarted, so you shouldn't have to do anything other than ensuring you're using the proper daemon type (simple, forking, etc). See Luca's recommended URL for more details. On Sun, Jan 29, 2017 at 11:52 AM, Anton Smith wrote: > I got a question that I couldn't find any answers to on google/mailing > lists etc. > > How do you keep a snap application alive, i.e. let's say I have an FFMPEG > session that needs to run 24/7 (recording a camera), and on occasion it > crashes. Traditionally I have used monit to "watch it" and restart it when > it dies. > > How does this work with snaps? > > Regards, > Anton > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.arias at canonical.com Tue Jan 31 00:04:28 2017 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 30 Jan 2017 18:04:28 -0600 Subject: Issue with snapcraft nodejs plugin (and the local npm cache) In-Reply-To: References: Message-ID: Hello Geoffroy, thanks for all the information. Can you please report a bug? https://bugs.launchpad.net/snapcraft/+filebug pura vida. From joseph.wakeling at webdrake.net Tue Jan 31 00:05:30 2017 From: joseph.wakeling at webdrake.net (Joseph Rushton Wakeling) Date: Tue, 31 Jan 2017 01:05:30 +0100 Subject: LDC snap published in edge channel In-Reply-To: <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> References: <71cbbef7-8cf0-f5f8-a6a9-3730861d813d@webdrake.net> <36942dcf-7ac4-1a0c-01d8-9d617c37ce80@ubuntu.com> <804eac6d-b0b3-1484-5f56-8c65b688b4dd@webdrake.net> Message-ID: On 26/01/17 22:04, Joseph Rushton Wakeling wrote: > Just to follow up on this: the LDC devs have agreed to allow me to move forward > with this in the name of the project. The new git repo is available at: > https://github.com/ldc-developers/ldc2.snap The snap packaged passed manual review today, so earlier this evening I published it to the edge channel (accessing the developer site from an Ubuntu phone, appropriately enough:-). It should be possible to install with: sudo snap install --edge --classic ldc2 Would be really grateful if anyone would be prepared to try it out and confirm that it works for them (especially people using snapd on non-Ubuntu distros). If you need inspiration for some D code to write, you could play with some of the examples available at https://dlang.org/ :-) Thanks very much to everyone who gave so much generous advice and support to help me get this package ready. Best wishes, -- Joe From leo.arias at canonical.com Tue Jan 31 00:37:05 2017 From: leo.arias at canonical.com (Leo Arias) Date: Mon, 30 Jan 2017 18:37:05 -0600 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: On Mon, Jan 30, 2017 at 8:33 AM, Adam Stokes wrote: > There isn't a plugin yet and I did ask Sergio about this at our last sprint. > AFAIK there isn't one planned and I would be willing to collaborate with you > to get one written and merged upstream. Do you know ruby Adam? Welcome to the team! :D This bug is for you: https://bugs.launchpad.net/snapcraft/+bug/1612818 :D Marco, there's also gistup. Pretty nice. However, it can't be snapped because of https://bugs.launchpad.net/snappy/+bug/1630690 It could be a classic snap, but that doesn't sound correct. pura vida. -- ¡paz y baile! http://www.ubuntu.com From manik at canonical.com Tue Jan 31 04:35:18 2017 From: manik at canonical.com (Manik Taneja) Date: Mon, 30 Jan 2017 20:35:18 -0800 Subject: snapcraft parts cache and webservice Message-ID: hi there, just wanted to find out the status of- https://trello.com/c/R4PP2b8P/142-parts-build-cache-and-webservice cheers, manik -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin.mcpherson at canonical.com Tue Jan 31 06:58:00 2017 From: justin.mcpherson at canonical.com (Justin McPherson) Date: Tue, 31 Jan 2017 16:58:00 +1000 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: I know a fair bit about ruby and gems, happy to help with this task. Being able to snap a rails app is something I'd also like to be possible. - Justin On Tue, Jan 31, 2017 at 10:37 AM, Leo Arias wrote: > On Mon, Jan 30, 2017 at 8:33 AM, Adam Stokes > wrote: > > There isn't a plugin yet and I did ask Sergio about this at our last > sprint. > > AFAIK there isn't one planned and I would be willing to collaborate with > you > > to get one written and merged upstream. > > Do you know ruby Adam? Welcome to the team! :D > This bug is for you: https://bugs.launchpad.net/snapcraft/+bug/1612818 :D > > Marco, there's also gistup. Pretty nice. However, it can't be snapped > because of https://bugs.launchpad.net/snappy/+bug/1630690 > It could be a classic snap, but that doesn't sound correct. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alberto.mardegan at canonical.com Tue Jan 31 08:23:20 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Tue, 31 Jan 2017 11:23:20 +0300 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: Message-ID: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> On 30/01/2017 16:44, Timo Jyrinki wrote: > ubuntu-calculator-app seems to be broken with the previous stable #22 > too though, with a similar error report. We did notice that too now > that I read the chat log, but didn't consider for this upgrade as it > seemed to be the status quo. > > But just in case, and as per Dan's e-mail indicating also a problem in > some app, I reverted Stable channel back to the #22 and will bump the > content: field to ubuntu-app-platform2 and version to 2. Do we have a clear understanding of why this happens? Qt apps are supposed to be binary compatible against newer releases. One exception could be if the app itself is shipping some plugins, because in that case I believe that these plugins are somehow bound to a specific Qt version. And I wonder, maybe we should think of a different versioning scheme for the interface? Otherwise, we should have a documentation page which maps the snap version numbers to the Qt version contained within them. Given that Qt is at the core of ubuntu-app-platform and that a change of the Qt version is something we want all developers to be aware of, maybe the snap (and the "content" interface field) should contain also an indication of the Qt version they provide? Ciao, Alberto From alberto.mardegan at canonical.com Tue Jan 31 08:32:10 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Tue, 31 Jan 2017 11:32:10 +0300 Subject: [SPAM] snapping with Qt vs. wx In-Reply-To: References: Message-ID: Hi Spencer, your mail is definitely not spam. It's a bit off-topic, possibly :-) On 30/01/2017 20:27, Spencer Parkin wrote: > I was just curious what people's preferences were for snaps: Qt or wx? > I believe Qt has support for mobile devices, but I don't think wxWidgets > does. Other than that, should I switch over to using Qt? I've been a > wxWidgets guy for a long time, and I'm a big fan of it. What do you > think? Is there something better than either? I don't know wx much; I love Qt and QML and I'd recommend you to at least have a try at it, then you decide for yourself. > I've never written a mobile app, but if I did, I might look into the > Ubuntu phone platform. I own an iPhone, though. Is Ubuntu phone better? Well, I'm in love with my Ubuntu phone, but it's not for everyone. If you are a geek, then it's probably the best thing you could ever dream of, but it has its shortcomings (which will eventually be addressed). But Qt does run on iOS too, so there's no need for you to switch, if you only want to try out Qt on mobile. As far as snaps are concerned, you definitely want to know that the snap format is not supported by iOS, nor (currently) by Ubuntu phones. Ciao, Alberto From stephen.stewart at canonical.com Tue Jan 31 11:29:33 2017 From: stephen.stewart at canonical.com (Stephen Stewart) Date: Tue, 31 Jan 2017 11:29:33 +0000 Subject: Issue with snapcraft nodejs plugin (and the local npm cache) In-Reply-To: References: Message-ID: Hi, Another quick fix: I believe the nodejs plugin uses the global npm cache, which will be ~/.npm[1], so you could try deleting that folder. Consider having the nodejs plugin support per project .npmrc so users can set cache options themselves rather than set via args in the plugin. [1] https://docs.npmjs.com/cli/cache#cache Hope this helps, Stephen On Tue, Jan 31, 2017 at 12:05 AM Leo Arias wrote: Hello Geoffroy, thanks for all the information. Can you please report a bug? https://bugs.launchpad.net/snapcraft/+filebug pura vida. -- 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 geoffroy.vancutsem at intel.com Tue Jan 31 12:56:43 2017 From: geoffroy.vancutsem at intel.com (VanCutsem, Geoffroy) Date: Tue, 31 Jan 2017 12:56:43 +0000 Subject: Issue with snapcraft nodejs plugin (and the local npm cache) In-Reply-To: References: Message-ID: I’m no expert at all on nodejs and npm but doing an `npm update` feels more appropriate than deleting the entire cache, or am I missing something? A bug has been filed: https://bugs.launchpad.net/snapcraft/+bug/1660614 Thanks, Geoffroy From: snapcraft-bounces at lists.snapcraft.io [mailto:snapcraft-bounces at lists.snapcraft.io] On Behalf Of Stephen Stewart Sent: Tuesday, January 31, 2017 12:30 PM To: Snapcraft Subject: Re: Issue with snapcraft nodejs plugin (and the local npm cache) Hi, Another quick fix: I believe the nodejs plugin uses the global npm cache, which will be ~/.npm[1], so you could try deleting that folder. Consider having the nodejs plugin support per project .npmrc so users can set cache options themselves rather than set via args in the plugin. [1] https://docs.npmjs.com/cli/cache#cache Hope this helps, Stephen On Tue, Jan 31, 2017 at 12:05 AM Leo Arias > wrote: Hello Geoffroy, thanks for all the information. Can you please report a bug? https://bugs.launchpad.net/snapcraft/+filebug pura vida. -- Snapcraft mailing list Snapcraft at lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Tue Jan 31 13:01:46 2017 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Tue, 31 Jan 2017 13:01:46 +0000 Subject: snapd available in Trusty Tahr Message-ID: Hi, The team are pleased to announce that, after extensive testing in proposed, snapd is officially available in the Trusty Tahr updates archive [1]. If you are running a 14.04 system we encourage you to give it a try and report any issues [2]. Thanks to all involved in making this happen. Regards, Jamie. [1] https://launchpad.net/ubuntu/trusty/+source/snapd [2] https://bugs.launchpad.net/ubuntu/+source/snapd From timo.jyrinki at gmail.com Tue Jan 31 13:12:46 2017 From: timo.jyrinki at gmail.com (Timo Jyrinki) Date: Tue, 31 Jan 2017 15:12:46 +0200 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: 2017-01-31 10:23 GMT+02:00 Alberto Mardegan : > Do we have a clear understanding of why this happens? Qt apps are > supposed to be binary compatible against newer releases. > One exception could be if the app itself is shipping some plugins, > because in that case I believe that these plugins are somehow bound to a > specific Qt version. Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on Qt version which should not be the case when the platform snap is used. Qt detects loading of modules with different versions and throws the error message. Technically we could patch Qt to not do this maybe over enthusiastic detection (Qt 5.6 point releases should naturally be 100% forward and backward compatible sans fixed bugs), but then again it's good that we detected these extra libraries being shipped. > And I wonder, maybe we should think of a different versioning scheme for > the interface? Otherwise, we should have a documentation page which maps > the snap version numbers to the Qt version contained within them. I think it's ok for now to keep the version "1" in the content field and not introduce a new package version or a package rename. I understood there are new features in development that could allow multiple releases to be available from the store at the same time, and maybe that would mean that package requiring content: ubuntu-app-platform1 could continue to get the last one with that version while developers could move to ubuntu-app-platform2 when such is decided to be released eventually. > Given that Qt is at the core of ubuntu-app-platform and that a change of > the Qt version is something we want all developers to be aware of, maybe > the snap (and the "content" interface field) should contain also an > indication of the Qt version they provide? The platform snap's description does contain the version of Qt included. However, the snap also contains lots of other libraries and more transparency would be useful. Certainly some documentation will be needed. -Timo From olivier.tilloy at canonical.com Tue Jan 31 15:21:41 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Tue, 31 Jan 2017 16:21:41 +0100 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki wrote: > 2017-01-31 10:23 GMT+02:00 Alberto Mardegan : >> Do we have a clear understanding of why this happens? Qt apps are >> supposed to be binary compatible against newer releases. >> One exception could be if the app itself is shipping some plugins, >> because in that case I believe that these plugins are somehow bound to a >> specific Qt version. > > Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on > Qt version which should not be the case when the platform snap is > used. This is a bit tricky: when packaging a Qt application that uses the platform snap, snapcraft will use ldd to crawl the app’s binaries and will automagically add the libraries that it depends on to the resulting snap (those libs are taken from the host system). There is a way around that, but it’s rather counter-intuitive and error-prone: add the packages containing those libs to the list of stage-packages, then explicitly exclude them from the resulting snap using the prime/snap keyword. You won’t be able to exclude them if you didn’t include them through the stage packages first. This is what we do in the webbrowser-app snap, and it works well (proof is that this Qt update didn’t break it), but it makes packagers’ lives unnecessarily complicated. What can we do to make it easy for snap packagers to use the platform snap with their Qt app? Add some logic to snapcraft so that it becomes aware of the contents of the platform snap, maybe? Cheers, Olivier > Qt detects loading of modules with different versions and throws the > error message. Technically we could patch Qt to not do this maybe over > enthusiastic detection (Qt 5.6 point releases should naturally be 100% > forward and backward compatible sans fixed bugs), but then again it's > good that we detected these extra libraries being shipped. > >> And I wonder, maybe we should think of a different versioning scheme for >> the interface? Otherwise, we should have a documentation page which maps >> the snap version numbers to the Qt version contained within them. > > I think it's ok for now to keep the version "1" in the content field > and not introduce a new package version or a package rename. I > understood there are new features in development that could allow > multiple releases to be available from the store at the same time, and > maybe that would mean that package requiring content: > ubuntu-app-platform1 could continue to get the last one with that > version while developers could move to ubuntu-app-platform2 when such > is decided to be released eventually. > >> Given that Qt is at the core of ubuntu-app-platform and that a change of >> the Qt version is something we want all developers to be aware of, maybe >> the snap (and the "content" interface field) should contain also an >> indication of the Qt version they provide? > > The platform snap's description does contain the version of Qt > included. However, the snap also contains lots of other libraries and > more transparency would be useful. Certainly some documentation will > be needed. > > -Timo > > -- > 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 Jan 31 15:32:04 2017 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 31 Jan 2017 15:32:04 +0000 Subject: snapd available in Trusty Tahr In-Reply-To: References: Message-ID: <74b407ab-0b33-2ea2-a1b1-af88a2348d6f@ubuntu.com> On 31/01/17 13:01, Jamie Bennett wrote: > The team are pleased to announce that, after extensive testing in proposed, snapd is officially available in the Trusty Tahr updates archive [1]. If you are running a 14.04 system we encourage you to give it a try and report any issues [2]. Thanks to all involved in making this happen. The work involved in getting snapd onto 14.04 will also help enable snapd on non-systemd distros, so testing a range of snaps would be very useful. Thanks! Mark From luca.dionisi at gmail.com Tue Jan 31 15:37:13 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Tue, 31 Jan 2017 16:37:13 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. Message-ID: I want to prepare a snap for a software written in Vala. It needs a library written in Vala too. I made a 'part' that depends on another one with 'after'. The library part is pulled, built and staged. When it tries to build the app part, the file .vapi is not found by the vala-compiler. The vapi file is present in ./stage/share/vala/vapi and also in ./parts/[mylibpart]/install/share/vala/vapi. Which one should the compiler be instructed to look at? And why doesn't it? Is Vala support not present yet or do I miss something in the snapcraft.yaml? --Luca From alberto.mardegan at canonical.com Tue Jan 31 15:39:20 2017 From: alberto.mardegan at canonical.com (Alberto Mardegan) Date: Tue, 31 Jan 2017 18:39:20 +0300 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: <0e3b3924-2339-0a5c-7d4a-7c558d614172@canonical.com> On 31/01/2017 18:21, Olivier Tilloy wrote: > This is a bit tricky: when packaging a Qt application that uses the > platform snap, snapcraft will use ldd to crawl the app’s binaries and > will automagically add the libraries that it depends on to the > resulting snap (those libs are taken from the host system). > > There is a way around that, but it’s rather counter-intuitive and > error-prone: add the packages containing those libs to the list of > stage-packages, then explicitly exclude them from the resulting snap > using the prime/snap keyword. You won’t be able to exclude them if you > didn’t include them through the stage packages first. Actually, I found a simpler solution (not sure if it would work in all cases): just explicitly list the files you need to be primed. https://gitlab.com/mardy/snapcraft-webapp-helper/blob/master/snapcraft.yaml This works for our webapps, which consist only of the webapp-container binary (and therefore are only about 600KB in size). Ciao, Alberto From mhall119 at ubuntu.com Tue Jan 31 15:49:03 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Tue, 31 Jan 2017 10:49:03 -0500 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: Message-ID: <98753033-e6fc-2c03-84f4-2c43c995eae5@ubuntu.com> The compiler should automatically look for it in ./stage/ but you need to make sure that your library is listed in the after: [] stanza on your application part, so that it will be built and staged for your app to use. There's an example you can look at here: https://github.com/ubuntu/snappy-playpen/blob/pantheon-mail/pantheon-mail/snapcraft.yaml Michael Hall mhall119 at ubuntu.com On 01/31/2017 10:37 AM, Luca Dionisi wrote: > I want to prepare a snap for a software written in Vala. > It needs a library written in Vala too. > > I made a 'part' that depends on another one with 'after'. > > The library part is pulled, built and staged. > When it tries to build the app part, the file .vapi is not found by the > vala-compiler. > > The vapi file is present in ./stage/share/vala/vapi and also in > ./parts/[mylibpart]/install/share/vala/vapi. > > Which one should the compiler be instructed to look at? > > And why doesn't it? Is Vala support not present yet or do I > miss something in the snapcraft.yaml? > > --Luca > From leo.arias at canonical.com Tue Jan 31 15:49:54 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 31 Jan 2017 09:49:54 -0600 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: Thanks for the offer Justin! Whenever you are ready to start, join us in https://rocket.ubuntu.com/channel/snapcraft We will be there in case you need a hand with the API, code style and tests. It would be great if the two of you pair to write the code, or one writes the code and the other makes the PR review. We are trying very hard to make hacking in snapcraft a pleasant experience for all the new contributors, so we'll also appreciate if you file bugs about any shortcomings there. pura vida. From leo.arias at canonical.com Tue Jan 31 15:56:06 2017 From: leo.arias at canonical.com (Leo Arias) Date: Tue, 31 Jan 2017 09:56:06 -0600 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On Tue, Jan 31, 2017 at 9:21 AM, Olivier Tilloy wrote: > This is a bit tricky: when packaging a Qt application that uses the > platform snap, snapcraft will use ldd to crawl the app’s binaries and > will automagically add the libraries that it depends on to the > resulting snap (those libs are taken from the host system). > > There is a way around that, but it’s rather counter-intuitive and > error-prone: add the packages containing those libs to the list of > stage-packages, then explicitly exclude them from the resulting snap > using the prime/snap keyword. You won’t be able to exclude them if you > didn’t include them through the stage packages first. Isn't this what Kyle fixed by adding build-attributes: [no-system-libraries] ? http://snapcraft.io/docs/build-snaps/syntax#parts From olivier.tilloy at canonical.com Tue Jan 31 16:02:02 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Tue, 31 Jan 2017 17:02:02 +0100 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: <0e3b3924-2339-0a5c-7d4a-7c558d614172@canonical.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <0e3b3924-2339-0a5c-7d4a-7c558d614172@canonical.com> Message-ID: On Tue, Jan 31, 2017 at 4:39 PM, Alberto Mardegan wrote: > On 31/01/2017 18:21, Olivier Tilloy wrote: >> This is a bit tricky: when packaging a Qt application that uses the >> platform snap, snapcraft will use ldd to crawl the app’s binaries and >> will automagically add the libraries that it depends on to the >> resulting snap (those libs are taken from the host system). >> >> There is a way around that, but it’s rather counter-intuitive and >> error-prone: add the packages containing those libs to the list of >> stage-packages, then explicitly exclude them from the resulting snap >> using the prime/snap keyword. You won’t be able to exclude them if you >> didn’t include them through the stage packages first. > > Actually, I found a simpler solution (not sure if it would work in all > cases): just explicitly list the files you need to be primed. > > https://gitlab.com/mardy/snapcraft-webapp-helper/blob/master/snapcraft.yaml > > This works for our webapps, which consist only of the webapp-container > binary (and therefore are only about 600KB in size). Sure, but this boils down to the same thing: you need to either explicitly exclude the files you don't want or explicitly include only the files you want. In that specific case you don’t need to add extra stage packages because you're using the webapp-container package already (which implicitly pulls in all its Qt dependencies as stage packages). That wouldn't work if you built webapp-container from source, in which case you would need to specify your dependencies as stage-packages. From didier.roche at canonical.com Tue Jan 31 16:04:06 2017 From: didier.roche at canonical.com (Didier Roche) Date: Tue, 31 Jan 2017 17:04:06 +0100 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: <1485787151.10013.118.camel@canonical.com> References: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> <1485787151.10013.118.camel@canonical.com> Message-ID: <407c502a-a7bf-6d79-6f64-75504d2db57d@canonical.com> Le 30/01/2017 à 15:39, Jamie Strandboge a écrit : > On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote: >> On 2017-01-30 01:56 AM, Spencer Parkin wrote: >>> >>> >>> I have a program that has successfully snapped and run in confinement mode, >>> but then I added a pixel and vertex shader >>> which works when run on my classic system, but not in strict confinement as >>> a snap. I've tried to narrow down the >>> earliest fail point, and I believe it is at the point where I'm calling >>> glGetUniformFromLocation. This is returning -1 >>> in confinement mode. I'm able to read, compile and link my shader program, >>> and bind it, but the first call to >>> glGetUniformFromLocation fails. Is OpenGL being denied read-access to a >>> portion of protected memory? If so, it >>> certainly would fail to write there as well with a call to glUniform3f, for >>> example. >>> >>> I've tried hooking up the snappy-debug's log-observe plug to that of ubuntu >>> core's, then running the scanlog, but the >>> only app-armer denial I get is, I believe, unrelated to the problem. In any >>> case, I will give it here... >>> >>> Log: apparmer="DENIED" operation="open" >>> profile="snap.twistypuzzle.twistypuzzle" name="/usr/share/glib-2.0/schemas/" >>> pid=23593 comm="desktop-launch" request_mask="r" denied_mask="r" fsuid=1000 >>> ouid=0 >>> File: /usr/share/glib-2.0/schemas/ (read) >> That error message is because the launcher program "desktop-launch" can not >> find the gsettings. I don't know what >> impact that will have (if any) but it's not going to affect how OpenGL works >> internally. >> > AIUI, the desktop part is doing this as part of its bootstrap to generate what > it needs in ~/snap/SNAP_NAME/SNAP_REVISION and it will only do this the first > time a new revision of the snap is launched. This denial is harmless and should > only happen on classic (since /usr/share/glib-2.0/schemas doesn't exist on > Ubuntu Core). > > While harmless, it is also confusing. I'm not super familiar with the desktop > part and wonder how we can improve this. Didier or Seb, would the bootstrapping > process work ok if we allowed read on the /usr/share/glib-2.0/schemas/ directory > in the unity7 (and maybe the x11) transitional classic interfaces? > The issue is indeed that there is classic confinement vs core only. I thought that it makes sense to read all traditional glib schema paths, test that they exists, and if they exist, compile the gsetting schemas alongside the snap specific ones. /usr/share/glib-2.0/schemas/, as Jamie told, don't exist on core, so we just skip it and don't have that denial. On classic however, it does. I'm surprised thought hat there is even a denial: I thought classic gave you access to your whole host system and this kind of things won't happen, do you mind giving some precisions Jamie to fix my twisted perception? For the paths we are checking, we are basing ourself on $XDG_DATA_DIRS, appending glib-2.0/schemas to each of them. On 16.04 LTS, this is: $ echo $XDG_DATA_DIRS /usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop As you can see, quite some paths are involved (even if in practice, only /usr/share/glib-2.0/schemas/ would exist in general). Hope that helps clarifying out! Cheers, Didier From sergio.schvezov at canonical.com Tue Jan 31 16:18:18 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 31 Jan 2017 16:18:18 +0000 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: > On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki > wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> Do we have a clear understanding of why this happens? Qt apps are >>> supposed to be binary compatible against newer releases. >>> One exception could be if the app itself is shipping some plugins, >>> because in that case I believe that these plugins are somehow bound to a >>> specific Qt version. >> >> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >> Qt version which should not be the case when the platform snap is >> used. > > This is a bit tricky: when packaging a Qt application that uses the > platform snap, snapcraft will use ldd to crawl the app’s binaries and > will automagically add the libraries that it depends on to the > resulting snap (those libs are taken from the host system). This will be disabled by default and snapcraft will error on missing libraries unless you tell it is ok. -- Sent using Dekko from my Ubuntu device From olivier.tilloy at canonical.com Tue Jan 31 16:29:36 2017 From: olivier.tilloy at canonical.com (Olivier Tilloy) Date: Tue, 31 Jan 2017 17:29:36 +0100 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> Message-ID: On Tue, Jan 31, 2017 at 4:56 PM, Leo Arias wrote: > On Tue, Jan 31, 2017 at 9:21 AM, Olivier Tilloy > wrote: >> This is a bit tricky: when packaging a Qt application that uses the >> platform snap, snapcraft will use ldd to crawl the app’s binaries and >> will automagically add the libraries that it depends on to the >> resulting snap (those libs are taken from the host system). >> >> There is a way around that, but it’s rather counter-intuitive and >> error-prone: add the packages containing those libs to the list of >> stage-packages, then explicitly exclude them from the resulting snap >> using the prime/snap keyword. You won’t be able to exclude them if you >> didn’t include them through the stage packages first. > > Isn't this what Kyle fixed by adding build-attributes: [no-system-libraries] ? > > http://snapcraft.io/docs/build-snaps/syntax#parts Yes, that seems to be it, indeed. Thanks for the pointer Leo, I wasn’t aware of this new feature. With this, no need to artificially add stage packages. Neat! From didier.roche at canonical.com Tue Jan 31 16:31:23 2017 From: didier.roche at canonical.com (Didier Roche) Date: Tue, 31 Jan 2017 17:31:23 +0100 Subject: ubuntu-app-platform updated to Qt 5.6.2 In-Reply-To: <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> Message-ID: <163b80f7-d774-3aa2-bd20-b1946595ec93@canonical.com> Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : > On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >> wrote: >>>> Do we have a clear understanding of why this happens? Qt apps are >>>> supposed to be binary compatible against newer releases. >>>> One exception could be if the app itself is shipping some plugins, >>>> because in that case I believe that these plugins are somehow bound to a >>>> specific Qt version. >>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >>> Qt version which should not be the case when the platform snap is >>> used. >> This is a bit tricky: when packaging a Qt application that uses the >> platform snap, snapcraft will use ldd to crawl the app’s binaries and >> will automagically add the libraries that it depends on to the >> resulting snap (those libs are taken from the host system). > This will be disabled by default and snapcraft will error on missing libraries > unless you tell it is ok. > I'm a little bit uncomfortable with this statement for 2 reasons: From kyle.fazzari at canonical.com Tue Jan 31 16:32:05 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 31 Jan 2017 08:32:05 -0800 Subject: GEM/Ruby snapcraft plugin? In-Reply-To: References: Message-ID: <14800014-36e7-45a5-ded0-c5178a9c356c@canonical.com> On 01/30/2017 10:58 PM, Justin McPherson wrote: > > I know a fair bit about ruby and gems, happy to help with this task. > > Being able to snap a rails app is something I'd also like to be possible. Same here, there just hasn't been time. Happy to review! -- 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 didrocks at ubuntu.com Tue Jan 31 16:40:09 2017 From: didrocks at ubuntu.com (Didier Roche) Date: Tue, 31 Jan 2017 17:40:09 +0100 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> Message-ID: <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : > On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >> wrote: >>>> Do we have a clear understanding of why this happens? Qt apps are >>>> supposed to be binary compatible against newer releases. >>>> One exception could be if the app itself is shipping some plugins, >>>> because in that case I believe that these plugins are somehow bound to a >>>> specific Qt version. >>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >>> Qt version which should not be the case when the platform snap is >>> used. >> This is a bit tricky: when packaging a Qt application that uses the >> platform snap, snapcraft will use ldd to crawl the app’s binaries and >> will automagically add the libraries that it depends on to the >> resulting snap (those libs are taken from the host system). > This will be disabled by default and snapcraft will error on missing libraries > unless you tell it is ok. > (first, sorry for the bad control+enter on my previous email) I'm a little bit uncomfortable with that statement for mainly 2 reasons: * Changing default behavior is always cumbersome to developers who just wants to work on their app. Here, we are introducing a breaking change (snaps that used to build won't build anymore, especially those on core). It's annoying also for people who did hook up their CI to autopublish a snap. This is why we need to justify and carefully explain the change, in a clear, defined way. I would suggest coordinating with David for a blog post that we promote here and on the developer website: 1. Why are we changing this? -> we are not doing this just to bother you, developer, here is the technical reason why we are doing it. 2. A small and minimal snippet of code of before/after so that people aren't lost and know what to do 3. When is it going to be released. Version, date, upgrade process. As this default behavior changes a lot of things, we need to ensure as well that all our code snippet and tutorials are updated. So coordinating all the way, please! * The second one is that it seems there is a disable mechanism, mainly telling "I know what I'm doing". I think this isn't what we want to achieve and it's not fine-grained enough. A common use-case I can see is an app depending on a platform snap and embedding additional libraries for some functionality. If we have to disable the check for not erroring out on the platform snap libs, we may miss, on snap creation, or upgrade or more… additional library checks. It seems we shouldn't use a big hammer like this (if it's really what I'm understanding from this statement), but rather trying to get a way more fine-grained and precise approach. Thoughts? Didier From gustavo.niemeyer at canonical.com Tue Jan 31 16:43:35 2017 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 31 Jan 2017 14:43:35 -0200 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: That's an interesting idea. Is there a known repository for license texts which are not standard? I see SPDX uses a LicenseRef- kind of reference, but it's not clear what that is referencing. Just another field inside the XML in the case of AppStream, I suppose? On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa wrote: > On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth > wrote: > > > > We should allow a plaintext field there for this situation. Yes, go > > ahead with "Other open source". > > > > It would probably make sense to support SPDX license tags and > expressions[1]. This is used in AppStream, so a great amount of > software is already classified in this manner. Furthermore, openSUSE > uses SPDX tags for their license metadata for packages, and Debian > uses a subset of it as part of the copyright file structure in Debian > Source Control packaging. > > While we in Fedora use our own license tag list[2] that predates SPDX > (used by a great deal of Linux distributions), we maintain a mapping > to SPDX for AppStream support. > > Having verifiable license information (either Fedora style or SPDX > style) is also useful for ensuring things are "compatible" or > "desired" on a system, depending on whatever preference you may have. > > [1]: https://spdx.org/licenses/ > [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyle.fazzari at canonical.com Tue Jan 31 17:02:17 2017 From: kyle.fazzari at canonical.com (Kyle Fazzari) Date: Tue, 31 Jan 2017 09:02:17 -0800 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Message-ID: On 01/31/2017 08:40 AM, Didier Roche wrote: > Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : >> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >>> wrote: >>>>> Do we have a clear understanding of why this happens? Qt apps are >>>>> supposed to be binary compatible against newer releases. >>>>> One exception could be if the app itself is shipping some plugins, >>>>> because in that case I believe that these plugins are somehow bound to a >>>>> specific Qt version. >>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >>>> Qt version which should not be the case when the platform snap is >>>> used. >>> This is a bit tricky: when packaging a Qt application that uses the >>> platform snap, snapcraft will use ldd to crawl the app’s binaries and >>> will automagically add the libraries that it depends on to the >>> resulting snap (those libs are taken from the host system). >> This will be disabled by default and snapcraft will error on missing libraries >> unless you tell it is ok. >> > (first, sorry for the bad control+enter on my previous email) > > I'm a little bit uncomfortable with that statement for mainly 2 reasons: > * Changing default behavior is always cumbersome to developers who just > wants to work on their app. Here, we are introducing a breaking change > (snaps that used to build won't build anymore, especially those on > core). It's annoying also for people who did hook up their CI to > autopublish a snap. > > This is why we need to justify and carefully explain the change, in a > clear, defined way. I would suggest coordinating with David for a blog > post that we promote here and on the developer website: > 1. Why are we changing this? -> we are not doing this just to bother > you, developer, here is the technical reason why we are doing it. > 2. A small and minimal snippet of code of before/after so that people > aren't lost and know what to do > 3. When is it going to be released. Version, date, upgrade process. > > As this default behavior changes a lot of things, we need to ensure as > well that all our code snippet and tutorials are updated. So > coordinating all the way, please! I completely agree. > * The second one is that it seems there is a disable mechanism, mainly > telling "I know what I'm doing". I think this isn't what we want to > achieve and it's not fine-grained enough. Without knowing much about this change, I figure something like this would fit into build-attributes, which is per-part at least. > A common use-case I can see is an app depending on a platform snap and > embedding additional libraries for some functionality. If we have to > disable the check for not erroring out on the platform snap libs, we may > miss, on snap creation, or upgrade or more… additional library checks. > It seems we shouldn't use a big hammer like this (if it's really what > I'm understanding from this statement), but rather trying to get a way > more fine-grained and precise approach. You mean like asking the snap developer to provide an explicit list of libraries to error on? Or an explicit list of libraries to pull from the system if missing? Anything more fine-grained sounds messy to maintain from a snap developer perspective. And this applies to either direction: automatically pulling in dependencies from the system, or erroring on missing libraries. Note that, in your example, the consumer app should likely be built with the providing snap unpacked into the staging area. This guarantees that the consumer is build with the libraries etc. actually contained in the providing snap. Using this workflow, snapcraft doesn't do anything special with the libs contained in the staging area, even if they're filtered out of the final snap via the `prime` keyword. Where "anything special" is defined as trying to pull them in from the system, etc. I figure the "error on missing libs" would follow the same logic, and not error if the libs are satisfied in stage. -- 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 sergio.schvezov at canonical.com Tue Jan 31 17:33:04 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 31 Jan 2017 17:33:04 +0000 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Message-ID: <7g3ysh.oknnf9.1hge9g2-qmf@smtp.googlemail.com> On Tue, 31 Jan 2017 17:40:09 +0100, Didier Roche wrote: > Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : >> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >>> wrote: >>>>> Do we have a clear understanding of why this happens? Qt apps are >>>>> supposed to be binary compatible against newer releases. >>>>> One exception could be if the app itself is shipping some plugins, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> specific Qt version. >>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >>>> Qt version which should not be the case when the platform snap is >>>> used. >>> This is a bit tricky: when packaging a Qt application that uses the >>> platform snap, snapcraft will use ldd to crawl the app’s binaries and >>> will automagically add the libraries that it depends on to the >>> resulting snap (those libs are taken from the host system). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >> unless you tell it is ok. >> > (first, sorry for the bad control+enter on my previous email) > > I'm a little bit uncomfortable with that statement for mainly 2 reasons: > * Changing default behavior is always cumbersome to developers who just > wants to work on their app. Here, we are introducing a breaking change > (snaps that used to build won't build anymore, especially those on > core). It's annoying also for people who did hook up their CI to > autopublish a snap. > > This is why we need to justify and carefully explain the change, in a > clear, defined way. I would suggest coordinating with David for a blog > post that we promote here and on the developer website: > 1. Why are we changing this? -> we are not doing this just to bother > you, developer, here is the technical reason why we are doing it. The reason is simple, we are leaking libraries by default, like libsupersecrect.so.1 and you won't even know about it. -- Sent using Dekko from my Ubuntu device From bill.filler at canonical.com Tue Jan 31 17:55:19 2017 From: bill.filler at canonical.com (Bill Filler) Date: Tue, 31 Jan 2017 12:55:19 -0500 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Message-ID: On Tue, Jan 31, 2017 at 12:02 PM, Kyle Fazzari wrote: > > > On 01/31/2017 08:40 AM, Didier Roche wrote: > > Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : > >> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: > >>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki > >>> wrote: > >>>>> Do we have a clear understanding of why this happens? Qt apps are > >>>>> supposed to be binary compatible against newer releases. > >>>>> One exception could be if the app itself is shipping some plugins, > >>>>> because in that case I believe that these plugins are somehow bound > to a > >>>>> specific Qt version. > >>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on > >>>> Qt version which should not be the case when the platform snap is > >>>> used. > >>> This is a bit tricky: when packaging a Qt application that uses the > >>> platform snap, snapcraft will use ldd to crawl the app’s binaries and > >>> will automagically add the libraries that it depends on to the > >>> resulting snap (those libs are taken from the host system). > >> This will be disabled by default and snapcraft will error on missing > libraries > >> unless you tell it is ok. > >> > > (first, sorry for the bad control+enter on my previous email) > > > > I'm a little bit uncomfortable with that statement for mainly 2 reasons: > > * Changing default behavior is always cumbersome to developers who just > > wants to work on their app. Here, we are introducing a breaking change > > (snaps that used to build won't build anymore, especially those on > > core). It's annoying also for people who did hook up their CI to > > autopublish a snap. > > > > This is why we need to justify and carefully explain the change, in a > > clear, defined way. I would suggest coordinating with David for a blog > > post that we promote here and on the developer website: > > 1. Why are we changing this? -> we are not doing this just to bother > > you, developer, here is the technical reason why we are doing it. > > 2. A small and minimal snippet of code of before/after so that people > > aren't lost and know what to do > > 3. When is it going to be released. Version, date, upgrade process. > > > > As this default behavior changes a lot of things, we need to ensure as > > well that all our code snippet and tutorials are updated. So > > coordinating all the way, please! > > I completely agree. > > > * The second one is that it seems there is a disable mechanism, mainly > > telling "I know what I'm doing". I think this isn't what we want to > > achieve and it's not fine-grained enough. > > Without knowing much about this change, I figure something like this > would fit into build-attributes, which is per-part at least. > > > A common use-case I can see is an app depending on a platform snap and > > embedding additional libraries for some functionality. If we have to > > disable the check for not erroring out on the platform snap libs, we may > > miss, on snap creation, or upgrade or more… additional library checks. > > It seems we shouldn't use a big hammer like this (if it's really what > > I'm understanding from this statement), but rather trying to get a way > > more fine-grained and precise approach. > > You mean like asking the snap developer to provide an explicit list of > libraries to error on? Or an explicit list of libraries to pull from the > system if missing? Anything more fine-grained sounds messy to maintain > from a snap developer perspective. And this applies to either direction: > automatically pulling in dependencies from the system, or erroring on > missing libraries. > > Note that, in your example, the consumer app should likely be built with > the providing snap unpacked into the staging area. This guarantees that > the consumer is build with the libraries etc. actually contained in the > providing snap. Using this workflow, snapcraft doesn't do anything > special with the libs contained in the staging area, even if they're > filtered out of the final snap via the `prime` keyword. Where "anything > special" is defined as trying to pull them in from the system, etc. I > figure the "error on missing libs" would follow the same logic, and not > error if the libs are satisfied in stage. > >From a developers perspective, it would be great if a workflow like the following could happen: - if my snap uses other snaps via content-sharing, the providing snaps would be automatically unpacked during the build and used to satisfy depends so the libs are not copied into my snap - if missing lib errors occur, give me the option to ignore and use system libs, or error-out with the list of missing deps This would satisfy use cases where the providing snap contains all the libs my snap needs or just a portion of them. Sounds like we have most of this already in some form but not exactly.. > > -- > Kyle Fazzari (kyrofa) > Software Engineer > Canonical Ltd. > kyle at canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Tue Jan 31 18:05:06 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 31 Jan 2017 18:05:06 +0000 Subject: Changing default snapcraft behavior and erroring on missing libraries In-Reply-To: References: <81181d15-7901-4e68-5f64-61a56dd0f962@canonical.com> <4yqht2.oknjyp.1hge17a-qmf@smtp.googlemail.com> <7e6c49fc-9f5b-3386-857e-f2bbe741ec2a@ubuntu.com> Message-ID: On Tue, 31 Jan 2017 12:55:19 -0500, Bill Filler wrote: > On Tue, Jan 31, 2017 at 12:02 PM, Kyle Fazzari > wrote: > >> >> >> On 01/31/2017 08:40 AM, Didier Roche wrote: >> > Le 31/01/2017 à 17:18, Sergio Schvezov a écrit : >> >> On Tue, 31 Jan 2017 16:21:41 +0100, Olivier Tilloy wrote: >> >>> On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki >> >>> wrote: >> >>>>> Do we have a clear understanding of why this happens? Qt apps are >> >>>>> supposed to be binary compatible against newer releases. >> >>>>> One exception could be if the app itself is shipping some plugins, >> >>>>> because in that case I believe that these plugins are somehow bound >> to a >> >>>>> specific Qt version. >> >>>> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on >> >>>> Qt version which should not be the case when the platform snap is >> >>>> used. >> >>> This is a bit tricky: when packaging a Qt application that uses the >> >>> platform snap, snapcraft will use ldd to crawl the app’s binaries and >> >>> will automagically add the libraries that it depends on to the >> >>> resulting snap (those libs are taken from the host system). >> >> This will be disabled by default and snapcraft will error on missing >> libraries >> >> unless you tell it is ok. >> >> >> > (first, sorry for the bad control+enter on my previous email) >> > >> > I'm a little bit uncomfortable with that statement for mainly 2 reasons: >> > * Changing default behavior is always cumbersome to developers who just >> > wants to work on their app. Here, we are introducing a breaking change >> > (snaps that used to build won't build anymore, especially those on >> > core). It's annoying also for people who did hook up their CI to >> > autopublish a snap. >> > >> > This is why we need to justify and carefully explain the change, in a >> > clear, defined way. I would suggest coordinating with David for a blog >> > post that we promote here and on the developer website: >> > 1. Why are we changing this? -> we are not doing this just to bother >> > you, developer, here is the technical reason why we are doing it. >> > 2. A small and minimal snippet of code of before/after so that people >> > aren't lost and know what to do >> > 3. When is it going to be released. Version, date, upgrade process. >> > >> > As this default behavior changes a lot of things, we need to ensure as >> > well that all our code snippet and tutorials are updated. So >> > coordinating all the way, please! >> >> I completely agree. >> >> > * The second one is that it seems there is a disable mechanism, mainly >> > telling "I know what I'm doing". I think this isn't what we want to >> > achieve and it's not fine-grained enough. >> >> Without knowing much about this change, I figure something like this >> would fit into build-attributes, which is per-part at least. >> >> > A common use-case I can see is an app depending on a platform snap and >> > embedding additional libraries for some functionality. If we have to >> > disable the check for not erroring out on the platform snap libs, we may >> > miss, on snap creation, or upgrade or more… additional library checks. >> > It seems we shouldn't use a big hammer like this (if it's really what >> > I'm understanding from this statement), but rather trying to get a way >> > more fine-grained and precise approach. >> >> You mean like asking the snap developer to provide an explicit list of >> libraries to error on? Or an explicit list of libraries to pull from the >> system if missing? Anything more fine-grained sounds messy to maintain >> from a snap developer perspective. And this applies to either direction: >> automatically pulling in dependencies from the system, or erroring on >> missing libraries. >> >> Note that, in your example, the consumer app should likely be built with >> the providing snap unpacked into the staging area. This guarantees that >> the consumer is build with the libraries etc. actually contained in the >> providing snap. Using this workflow, snapcraft doesn't do anything >> special with the libs contained in the staging area, even if they're >> filtered out of the final snap via the `prime` keyword. Where "anything >> special" is defined as trying to pull them in from the system, etc. I >> figure the "error on missing libs" would follow the same logic, and not >> error if the libs are satisfied in stage. >> > > From a developers perspective, it would be great if a workflow like the > following could happen: > - if my snap uses other snaps via content-sharing, the providing snaps > would be automatically unpacked during the build and used to satisfy > depends so the libs are not copied into my snap This is why I told the SDK team to build a "release tarball" of whatever their framework is, with this people would just `after` it and it would just work. This will avoid the need for adding build packages equivalent to those of whatever that snap provides or for you guys to depend on a PPA to be able to build. > - if missing lib errors occur, give me the option to ignore and use system > libs, or error-out with the list of missing deps This is planned. > This would satisfy use cases where the providing snap contains all the libs > my snap needs or just a portion of them. Sounds like we have most of this > already in some form but not exactly.. Right. Also, this is just planned, but the details and execution haven't been finalized given that I haven't discussed with everyone. -- Sent using Dekko from my Ubuntu device From ngompa13 at gmail.com Tue Jan 31 18:24:44 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Tue, 31 Jan 2017 13:24:44 -0500 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: SUSE has their own list of non-standard references[1], but my understanding is that SPDX is working on making this a bit more flexible in this regard. This was one of the reasons we haven't switched to it in Fedora (the other being the mismatch of BSD/MIT tags to SPDX equivalents). AppStream metainfo files shipped with software include the SPDX license tags[2]. One of the reasons I personally favor the Fedora tags more is because it's not obnoxious with dealing with classes of licenses. However, AppStream does mandate SPDX, and harmonizing snap metadata with AppStream metadata makes it easier to keep things sane and in sync, especially if developers want to use their metainfo files as input for generating parts of the snap metadata. Of course, maintaining harmony does not imply that SPDX license tags need to be used in snap data, only that some kind of automatic mapping from SPDX to another system is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu Software) has such a mechanism for going from Fedora/SUSE-classic to SPDX[3], and the other way around is considerably simpler. [1]: https://github.com/openSUSE/obs-service-format_spec_file [2]: https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html [3]: https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L555 On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer wrote: > That's an interesting idea. Is there a known repository for license texts > which are not standard? I see SPDX uses a LicenseRef- kind of > reference, but it's not clear what that is referencing. Just another field > inside the XML in the case of AppStream, I suppose? > > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa wrote: >> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth >> wrote: >> > >> > We should allow a plaintext field there for this situation. Yes, go >> > ahead with "Other open source". >> > >> >> It would probably make sense to support SPDX license tags and >> expressions[1]. This is used in AppStream, so a great amount of >> software is already classified in this manner. Furthermore, openSUSE >> uses SPDX tags for their license metadata for packages, and Debian >> uses a subset of it as part of the copyright file structure in Debian >> Source Control packaging. >> >> While we in Fedora use our own license tag list[2] that predates SPDX >> (used by a great deal of Linux distributions), we maintain a mapping >> to SPDX for AppStream support. >> >> Having verifiable license information (either Fedora style or SPDX >> style) is also useful for ensuring things are "compatible" or >> "desired" on a system, depending on whatever preference you may have. >> >> [1]: https://spdx.org/licenses/ >> [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_License_List >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- 真実はいつも一つ！/ Always, there's only one truth! From luca.dionisi at gmail.com Tue Jan 31 18:34:00 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Tue, 31 Jan 2017 19:34:00 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: <98753033-e6fc-2c03-84f4-2c43c995eae5@ubuntu.com> References: <98753033-e6fc-2c03-84f4-2c43c995eae5@ubuntu.com> Message-ID: On Tue, Jan 31, 2017 at 4:49 PM, Michael Hall wrote: > The compiler should automatically look for it in ./stage/ but you need > to make sure that your library is listed in the after: [] stanza on your > application part, so that it will be built and staged for your app to use. That I already did. The vapi file *is* in ./stage/share/vala/vapi/. Does it need to be directly in ./stage/? Maybe I should also say that in fact I have a library X that needs another library Y and both are in Vala. I think it does not matter, though. I use the autotools plugin (for the app part) and it issues this command: /usr/bin/valac -H mylib-x.h --library mylib-x --pkg mylib-y -C main.vala more.vala So, there is nothing telling the compiler to search for mylib-y.vapi in ./stage... Or is there an env-variable that should do it? > There's an example you can look at here: > https://github.com/ubuntu/snappy-playpen/blob/pantheon-mail/pantheon-mail/snapcraft.yaml I am having a look, but it is different in that it uses cmake. I don't know how to use cmake. --Luca From gustavo at niemeyer.net Tue Jan 31 19:03:43 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 31 Jan 2017 17:03:43 -0200 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: Using the license ids from SPDX seems straightforward, and that's what AppStream seems to encourage. But it doesn't mention support for SPDX license expressions (has a custom and/or rule), or what to do on custom licenses. So the harmony seems shallow, if you see what I mean. Or am I missing something? On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa wrote: > SUSE has their own list of non-standard references[1], but my > understanding is that SPDX is working on making this a bit more > flexible in this regard. This was one of the reasons we haven't > switched to it in Fedora (the other being the mismatch of BSD/MIT tags > to SPDX equivalents). AppStream metainfo files shipped with software > include the SPDX license tags[2]. > > One of the reasons I personally favor the Fedora tags more is because > it's not obnoxious with dealing with classes of licenses. However, > AppStream does mandate SPDX, and harmonizing snap metadata with > AppStream metadata makes it easier to keep things sane and in sync, > especially if developers want to use their metainfo files as input for > generating parts of the snap metadata. Of course, maintaining harmony > does not imply that SPDX license tags need to be used in snap data, > only that some kind of automatic mapping from SPDX to another system > is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu > Software) has such a mechanism for going from Fedora/SUSE-classic to > SPDX[3], and the other way around is considerably simpler. > > [1]: https://github.com/openSUSE/obs-service-format_spec_file > [2]: https://www.freedesktop.org/software/appstream/docs/chap- > Quickstart.html > [3]: https://github.com/hughsie/appstream-glib/blob/master/ > libappstream-glib/as-utils.c#L555 > > On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer > wrote: > > That's an interesting idea. Is there a known repository for license > texts > > which are not standard? I see SPDX uses a LicenseRef- kind of > > reference, but it's not clear what that is referencing. Just another > field > > inside the XML in the case of AppStream, I suppose? > > > > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa wrote: > >> > >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth > >> wrote: > >> > > >> > We should allow a plaintext field there for this situation. Yes, go > >> > ahead with "Other open source". > >> > > >> > >> It would probably make sense to support SPDX license tags and > >> expressions[1]. This is used in AppStream, so a great amount of > >> software is already classified in this manner. Furthermore, openSUSE > >> uses SPDX tags for their license metadata for packages, and Debian > >> uses a subset of it as part of the copyright file structure in Debian > >> Source Control packaging. > >> > >> While we in Fedora use our own license tag list[2] that predates SPDX > >> (used by a great deal of Linux distributions), we maintain a mapping > >> to SPDX for AppStream support. > >> > >> Having verifiable license information (either Fedora style or SPDX > >> style) is also useful for ensuring things are "compatible" or > >> "desired" on a system, depending on whatever preference you may have. > >> > >> [1]: https://spdx.org/licenses/ > >> [2]: https://fedoraproject.org/wiki/Licensing:Main#Software_ > License_List > >> > >> -- > >> 真実はいつも一つ！/ Always, there's only one truth! > >> > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > > > > > -- > > gustavo @ http://niemeyer.net > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/ > mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngompa13 at gmail.com Tue Jan 31 19:22:39 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Tue, 31 Jan 2017 14:22:39 -0500 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: No, you're not missing something. AppStream doesn't really have a great way to represent custom licenses. But license expressions are supported, as you can see in this example[1]. I suspect the "proper" way to handle it would be to have the license bundled in the metadata when "Custom" or "Proprietary" is used, so that the resource is available for review prior to installing. With the standardized licenses, usually the software centers render hyperlinks that users can click to see the terms. I'd potentially argue that BSD and MIT licenses would probably need to be handled the same way, given that copyright owners are declared in the license text. [1]: https://gitlab.com/osslugaru/lugaru/blob/master/Dist/Linux/lugaru.appdata.xml On Tue, Jan 31, 2017 at 2:03 PM, Gustavo Niemeyer wrote: > > Using the license ids from SPDX seems straightforward, and that's what > AppStream seems to encourage. But it doesn't mention support for SPDX > license expressions (has a custom and/or rule), or what to do on custom > licenses. So the harmony seems shallow, if you see what I mean. Or am I > missing something? > > On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa wrote: >> >> SUSE has their own list of non-standard references[1], but my >> understanding is that SPDX is working on making this a bit more >> flexible in this regard. This was one of the reasons we haven't >> switched to it in Fedora (the other being the mismatch of BSD/MIT tags >> to SPDX equivalents). AppStream metainfo files shipped with software >> include the SPDX license tags[2]. >> >> One of the reasons I personally favor the Fedora tags more is because >> it's not obnoxious with dealing with classes of licenses. However, >> AppStream does mandate SPDX, and harmonizing snap metadata with >> AppStream metadata makes it easier to keep things sane and in sync, >> especially if developers want to use their metainfo files as input for >> generating parts of the snap metadata. Of course, maintaining harmony >> does not imply that SPDX license tags need to be used in snap data, >> only that some kind of automatic mapping from SPDX to another system >> is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu >> Software) has such a mechanism for going from Fedora/SUSE-classic to >> SPDX[3], and the other way around is considerably simpler. >> >> [1]: https://github.com/openSUSE/obs-service-format_spec_file >> [2]: >> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html >> [3]: >> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L555 >> >> On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer >> wrote: >> > That's an interesting idea. Is there a known repository for license >> > texts >> > which are not standard? I see SPDX uses a LicenseRef- kind of >> > reference, but it's not clear what that is referencing. Just another >> > field >> > inside the XML in the case of AppStream, I suppose? >> > >> > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa wrote: >> >> >> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth >> >> wrote: >> >> > >> >> > We should allow a plaintext field there for this situation. Yes, go >> >> > ahead with "Other open source". >> >> > >> >> >> >> It would probably make sense to support SPDX license tags and >> >> expressions[1]. This is used in AppStream, so a great amount of >> >> software is already classified in this manner. Furthermore, openSUSE >> >> uses SPDX tags for their license metadata for packages, and Debian >> >> uses a subset of it as part of the copyright file structure in Debian >> >> Source Control packaging. >> >> >> >> While we in Fedora use our own license tag list[2] that predates SPDX >> >> (used by a great deal of Linux distributions), we maintain a mapping >> >> to SPDX for AppStream support. >> >> >> >> Having verifiable license information (either Fedora style or SPDX >> >> style) is also useful for ensuring things are "compatible" or >> >> "desired" on a system, depending on whatever preference you may have. >> >> >> >> [1]: https://spdx.org/licenses/ >> >> [2]: >> >> https://fedoraproject.org/wiki/Licensing:Main#Software_License_List >> >> >> >> -- >> >> 真実はいつも一つ！/ Always, there's only one truth! >> >> >> >> -- >> >> Snapcraft mailing list >> >> Snapcraft at lists.snapcraft.io >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> > >> > >> > >> > -- >> > gustavo @ http://niemeyer.net >> > >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- 真実はいつも一つ！/ Always, there's only one truth! From luca.dionisi at gmail.com Tue Jan 31 19:26:26 2017 From: luca.dionisi at gmail.com (Luca Dionisi) Date: Tue, 31 Jan 2017 20:26:26 +0100 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: <98753033-e6fc-2c03-84f4-2c43c995eae5@ubuntu.com> Message-ID: Sadly the CMakeLists look to me like a mess. Do you know of any example snap of a dependency on a vala library using autotools? From gustavo at niemeyer.net Tue Jan 31 19:30:51 2017 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Tue, 31 Jan 2017 17:30:51 -0200 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: Yes, that's the custom and/or rule I mentioned. This is not the SPDX license expression format: https://spdx.org/spdx-specification-21-web-version On Tue, Jan 31, 2017 at 5:22 PM, Neal Gompa wrote: > No, you're not missing something. AppStream doesn't really have a > great way to represent custom licenses. But license expressions are > supported, as you can see in this example[1]. I suspect the "proper" > way to handle it would be to have the license bundled in the metadata > when "Custom" or "Proprietary" is used, so that the resource is > available for review prior to installing. With the standardized > licenses, usually the software centers render hyperlinks that users > can click to see the terms. > > I'd potentially argue that BSD and MIT licenses would probably need to > be handled the same way, given that copyright owners are declared in > the license text. > > [1]: https://gitlab.com/osslugaru/lugaru/blob/master/Dist/Linux/l > ugaru.appdata.xml > > On Tue, Jan 31, 2017 at 2:03 PM, Gustavo Niemeyer > wrote: > > > > Using the license ids from SPDX seems straightforward, and that's what > > AppStream seems to encourage. But it doesn't mention support for SPDX > > license expressions (has a custom and/or rule), or what to do on custom > > licenses. So the harmony seems shallow, if you see what I mean. Or am I > > missing something? > > > > On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa wrote: > >> > >> SUSE has their own list of non-standard references[1], but my > >> understanding is that SPDX is working on making this a bit more > >> flexible in this regard. This was one of the reasons we haven't > >> switched to it in Fedora (the other being the mismatch of BSD/MIT tags > >> to SPDX equivalents). AppStream metainfo files shipped with software > >> include the SPDX license tags[2]. > >> > >> One of the reasons I personally favor the Fedora tags more is because > >> it's not obnoxious with dealing with classes of licenses. However, > >> AppStream does mandate SPDX, and harmonizing snap metadata with > >> AppStream metadata makes it easier to keep things sane and in sync, > >> especially if developers want to use their metainfo files as input for > >> generating parts of the snap metadata. Of course, maintaining harmony > >> does not imply that SPDX license tags need to be used in snap data, > >> only that some kind of automatic mapping from SPDX to another system > >> is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu > >> Software) has such a mechanism for going from Fedora/SUSE-classic to > >> SPDX[3], and the other way around is considerably simpler. > >> > >> [1]: https://github.com/openSUSE/obs-service-format_spec_file > >> [2]: > >> https://www.freedesktop.org/software/appstream/docs/chap-Qui > ckstart.html > >> [3]: > >> https://github.com/hughsie/appstream-glib/blob/master/libapp > stream-glib/as-utils.c#L555 > >> > >> On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer > >> wrote: > >> > That's an interesting idea. Is there a known repository for license > >> > texts > >> > which are not standard? I see SPDX uses a LicenseRef- kind of > >> > reference, but it's not clear what that is referencing. Just another > >> > field > >> > inside the XML in the case of AppStream, I suppose? > >> > > >> > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa > wrote: > >> >> > >> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth > >> >> wrote: > >> >> > > >> >> > We should allow a plaintext field there for this situation. Yes, go > >> >> > ahead with "Other open source". > >> >> > > >> >> > >> >> It would probably make sense to support SPDX license tags and > >> >> expressions[1]. This is used in AppStream, so a great amount of > >> >> software is already classified in this manner. Furthermore, openSUSE > >> >> uses SPDX tags for their license metadata for packages, and Debian > >> >> uses a subset of it as part of the copyright file structure in Debian > >> >> Source Control packaging. > >> >> > >> >> While we in Fedora use our own license tag list[2] that predates SPDX > >> >> (used by a great deal of Linux distributions), we maintain a mapping > >> >> to SPDX for AppStream support. > >> >> > >> >> Having verifiable license information (either Fedora style or SPDX > >> >> style) is also useful for ensuring things are "compatible" or > >> >> "desired" on a system, depending on whatever preference you may have. > >> >> > >> >> [1]: https://spdx.org/licenses/ > >> >> [2]: > >> >> https://fedoraproject.org/wiki/Licensing:Main#Software_License_List > >> >> > >> >> -- > >> >> 真実はいつも一つ！/ Always, there's only one truth! > >> >> > >> >> -- > >> >> Snapcraft mailing list > >> >> Snapcraft at lists.snapcraft.io > >> >> Modify settings or unsubscribe at: > >> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > >> > > >> > > >> > > >> > > >> > -- > >> > gustavo @ http://niemeyer.net > >> > > >> > -- > >> > Snapcraft mailing list > >> > Snapcraft at lists.snapcraft.io > >> > Modify settings or unsubscribe at: > >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft > >> > > >> > >> > >> > >> -- > >> 真実はいつも一つ！/ Always, there's only one truth! > >> > >> -- > >> Snapcraft mailing list > >> Snapcraft at lists.snapcraft.io > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > > > > > -- > > > > gustavo @ http://niemeyer.net > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.snapcraft.io > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ngompa13 at gmail.com Tue Jan 31 19:33:31 2017 From: ngompa13 at gmail.com (Neal Gompa) Date: Tue, 31 Jan 2017 14:33:31 -0500 Subject: Snap package licenses In-Reply-To: References: <4b836e21-7622-c99c-6050-0e8438255784@webdrake.net> <70569b98-a277-e047-2129-eea0fec6e10f@ubuntu.com> Message-ID: Ah, you're talking about the full SPDX spec. That is a completely different beast. I don't know of anyone using that right now... On Tue, Jan 31, 2017 at 2:30 PM, Gustavo Niemeyer wrote: > Yes, that's the custom and/or rule I mentioned. This is not the SPDX license > expression format: > > https://spdx.org/spdx-specification-21-web-version > > > On Tue, Jan 31, 2017 at 5:22 PM, Neal Gompa wrote: >> >> No, you're not missing something. AppStream doesn't really have a >> great way to represent custom licenses. But license expressions are >> supported, as you can see in this example[1]. I suspect the "proper" >> way to handle it would be to have the license bundled in the metadata >> when "Custom" or "Proprietary" is used, so that the resource is >> available for review prior to installing. With the standardized >> licenses, usually the software centers render hyperlinks that users >> can click to see the terms. >> >> I'd potentially argue that BSD and MIT licenses would probably need to >> be handled the same way, given that copyright owners are declared in >> the license text. >> >> [1]: >> https://gitlab.com/osslugaru/lugaru/blob/master/Dist/Linux/lugaru.appdata.xml >> >> On Tue, Jan 31, 2017 at 2:03 PM, Gustavo Niemeyer >> wrote: >> > >> > Using the license ids from SPDX seems straightforward, and that's what >> > AppStream seems to encourage. But it doesn't mention support for SPDX >> > license expressions (has a custom and/or rule), or what to do on custom >> > licenses. So the harmony seems shallow, if you see what I mean. Or am I >> > missing something? >> > >> > On Tue, Jan 31, 2017 at 4:24 PM, Neal Gompa wrote: >> >> >> >> SUSE has their own list of non-standard references[1], but my >> >> understanding is that SPDX is working on making this a bit more >> >> flexible in this regard. This was one of the reasons we haven't >> >> switched to it in Fedora (the other being the mismatch of BSD/MIT tags >> >> to SPDX equivalents). AppStream metainfo files shipped with software >> >> include the SPDX license tags[2]. >> >> >> >> One of the reasons I personally favor the Fedora tags more is because >> >> it's not obnoxious with dealing with classes of licenses. However, >> >> AppStream does mandate SPDX, and harmonizing snap metadata with >> >> AppStream metadata makes it easier to keep things sane and in sync, >> >> especially if developers want to use their metainfo files as input for >> >> generating parts of the snap metadata. Of course, maintaining harmony >> >> does not imply that SPDX license tags need to be used in snap data, >> >> only that some kind of automatic mapping from SPDX to another system >> >> is available. Richard Hughes' appstream-glib (used by GNOME/Ubuntu >> >> Software) has such a mechanism for going from Fedora/SUSE-classic to >> >> SPDX[3], and the other way around is considerably simpler. >> >> >> >> [1]: https://github.com/openSUSE/obs-service-format_spec_file >> >> [2]: >> >> >> >> https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html >> >> [3]: >> >> >> >> https://github.com/hughsie/appstream-glib/blob/master/libappstream-glib/as-utils.c#L555 >> >> >> >> On Tue, Jan 31, 2017 at 11:43 AM, Gustavo Niemeyer >> >> wrote: >> >> > That's an interesting idea. Is there a known repository for license >> >> > texts >> >> > which are not standard? I see SPDX uses a LicenseRef- kind of >> >> > reference, but it's not clear what that is referencing. Just another >> >> > field >> >> > inside the XML in the case of AppStream, I suppose? >> >> > >> >> > On Thu, Jan 26, 2017 at 9:58 PM, Neal Gompa >> >> > wrote: >> >> >> >> >> >> On Thu, Jan 26, 2017 at 5:35 PM, Mark Shuttleworth >> >> >> wrote: >> >> >> > >> >> >> > We should allow a plaintext field there for this situation. Yes, >> >> >> > go >> >> >> > ahead with "Other open source". >> >> >> > >> >> >> >> >> >> It would probably make sense to support SPDX license tags and >> >> >> expressions[1]. This is used in AppStream, so a great amount of >> >> >> software is already classified in this manner. Furthermore, openSUSE >> >> >> uses SPDX tags for their license metadata for packages, and Debian >> >> >> uses a subset of it as part of the copyright file structure in >> >> >> Debian >> >> >> Source Control packaging. >> >> >> >> >> >> While we in Fedora use our own license tag list[2] that predates >> >> >> SPDX >> >> >> (used by a great deal of Linux distributions), we maintain a mapping >> >> >> to SPDX for AppStream support. >> >> >> >> >> >> Having verifiable license information (either Fedora style or SPDX >> >> >> style) is also useful for ensuring things are "compatible" or >> >> >> "desired" on a system, depending on whatever preference you may >> >> >> have. >> >> >> >> >> >> [1]: https://spdx.org/licenses/ >> >> >> [2]: >> >> >> https://fedoraproject.org/wiki/Licensing:Main#Software_License_List >> >> >> >> >> >> -- >> >> >> 真実はいつも一つ！/ Always, there's only one truth! >> >> >> >> >> >> -- >> >> >> Snapcraft mailing list >> >> >> Snapcraft at lists.snapcraft.io >> >> >> Modify settings or unsubscribe at: >> >> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > >> >> > >> >> > >> >> > >> >> > -- >> >> > gustavo @ http://niemeyer.net >> >> > >> >> > -- >> >> > Snapcraft mailing list >> >> > Snapcraft at lists.snapcraft.io >> >> > Modify settings or unsubscribe at: >> >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > >> >> >> >> >> >> >> >> -- >> >> 真実はいつも一つ！/ Always, there's only one truth! >> >> >> >> -- >> >> Snapcraft mailing list >> >> Snapcraft at lists.snapcraft.io >> >> Modify settings or unsubscribe at: >> >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> > >> > >> > >> > -- >> > >> > gustavo @ http://niemeyer.net >> > >> > -- >> > Snapcraft mailing list >> > Snapcraft at lists.snapcraft.io >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/snapcraft >> > >> >> >> >> -- >> 真実はいつも一つ！/ Always, there's only one truth! >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.snapcraft.io >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing list > Snapcraft at lists.snapcraft.io > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- 真実はいつも一つ！/ Always, there's only one truth! From jamie at canonical.com Tue Jan 31 19:35:37 2017 From: jamie at canonical.com (Jamie Strandboge) Date: Tue, 31 Jan 2017 13:35:37 -0600 Subject: glGetUniformLocation fails in confinement mode In-Reply-To: <407c502a-a7bf-6d79-6f64-75504d2db57d@canonical.com> References: <9ad0201e-ab3c-0cb4-500c-bb3c6d655a1e@canonical.com> <1485787151.10013.118.camel@canonical.com> <407c502a-a7bf-6d79-6f64-75504d2db57d@canonical.com> Message-ID: <1485891337.10013.193.camel@canonical.com> On Tue, 2017-01-31 at 17:04 +0100, Didier Roche wrote: > Le 30/01/2017 à 15:39, Jamie Strandboge a écrit : > > On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote: > > > On 2017-01-30 01:56 AM, Spencer Parkin wrote: > > While harmless, it is also confusing. I'm not super familiar with the > > desktop > > part and wonder how we can improve this. Didier or Seb, would the > > bootstrapping > > process work ok if we allowed read on the /usr/share/glib-2.0/schemas/ > > directory > > in the unity7 (and maybe the x11) transitional classic interfaces? > > > The issue is indeed that there is classic confinement vs core only. I > thought that it makes sense to read all traditional glib schema paths, > test that they exists, and if they exist, compile the gsetting schemas > alongside the snap specific ones. > > /usr/share/glib-2.0/schemas/, as Jamie told, don't exist on core, so we > just skip it and don't have that denial. On classic however, it does. > > I'm surprised thought hat there is even a denial: I thought classic gave > you access to your whole host system and this kind of things won't > happen, do you mind giving some precisions Jamie to fix my twisted > perception? > 'classic' is an overloaded term. There is 'classic distro' (eg Ubuntu Desktop) and there is 'classic confinement' (ie, 'confinement: classic'). What the above denial is about is 'confinement: strict' on classic Ubuntu and my question was if the desktop part would work ok if we allowed /usr/share/glib-2.0/schemas/ with 'confinement: strict'. Based on your comment, it sounds like 'yes', but can you confirm? > For the paths we are checking, we are basing ourself on $XDG_DATA_DIRS, > appending glib-2.0/schemas to each of them. > On 16.04 LTS, this is: > $ echo $XDG_DATA_DIRS > /usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snap > d/desktop > > As you can see, quite some paths are involved (even if in practice, only > /usr/share/glib-2.0/schemas/ would exist in general). I'll keep these in mind. -- 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 mhall119 at ubuntu.com Tue Jan 31 19:47:16 2017 From: mhall119 at ubuntu.com (Michael Hall) Date: Tue, 31 Jan 2017 14:47:16 -0500 Subject: Vala and Snapcraft. Issues with a library part in Vala. In-Reply-To: References: <98753033-e6fc-2c03-84f4-2c43c995eae5@ubuntu.com> Message-ID: <31ffa70a-cd98-b8d2-d2e9-663b105c6d1c@ubuntu.com> Sorry, that's the only Vala project I've tried. I don't think there was anything special about it though, the main thing was just getting libgranite built and staged before building pantheon. Michael Hall mhall119 at ubuntu.com On 01/31/2017 02:26 PM, Luca Dionisi wrote: > Sadly the CMakeLists look to me like a mess. > > Do you know of any example snap of a dependency on a vala library > using autotools? > From sergio.schvezov at canonical.com Tue Jan 31 21:10:00 2017 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 31 Jan 2017 21:10:00 +0000 Subject: Please test my asciinema snap In-Reply-To: <20170118161146.0863631e@Stryder> References: <2139fe5f-8435-8363-94a2-9d99bcb45cbf@ubuntu.com> <20170118114149.64bfe73e@Stryder> <8210d84e-0947-2cb2-8564-39babbcb27d6@ubuntu.com> <20170118161146.0863631e@Stryder> Message-ID: To followup here for those not tracking the bug about trusty: https://asciinema.org/a/1bwmj57y51i25afq0ss54q0iz This will be available when using snapcraft 2.27 if no major blocker shows up (two PRs need to land). -- Sent using Dekko from my Ubuntu device