[01:18] <sergiusens> kyrofa one more look at https://github.com/snapcore/snapcraft/pull/707 maybe?
[01:18] <mup> PR snapcraft#707: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
[03:07] <sergiusens> kyrofa if you are still around can you do a review of this for me ? https://github.com/snapcore/snapcraft/pull/689
[03:07] <mup> PR snapcraft#689: kernel plugin: kernel targets depending on debarch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/689>
[03:13] <mup> PR snapcraft#709 opened: Improve the go plugins usability <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/709>
[03:54] <mup> PR snapd#1631 opened: client, osutil: chown the auth file	 <Created by chipaca> <https://github.com/snapcore/snapd/pull/1631>
[05:23] <trijntje> Hi all, I'm looking for a snap that requires the user to accept a license before installing. Is there a way to browse all snaps in the ubuntu store and filter for license?
[06:26] <mup> PR snapd#1632 opened: Do not install a snap if it is already valid <Created by mvo5> <https://github.com/snapcore/snapd/pull/1632>
[06:35] <dholbach> hey hey
[06:38] <didrocks> good morning dholbach
[06:38] <dholbach> salut didrocks
[06:40] <seb128> hey dholbach, re didrocks
[06:40] <dholbach> salut seb128
[06:56] <mup> PR snapd#1561 closed: many: remove integration-test coverage metrics  <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1561>
[07:16]  * dholbach relocates to the office, bbiab
[08:10] <Odd_Bloke> ogra_: o/ I was told to bug you about advice on how to install a snap within a chroot; any ideas?
[08:26] <brendand> is vivid really the latest image available for raspberry pi2?
[08:27] <mup> PR snapd#1632 closed: Do not install a snap again if it is already valid <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1632>
[08:30] <mvo> brendand: yes, but we are working (hard) on updated images, the goal is to have them today
[08:30] <brendand> mvo, what a nice coincidence :)
[08:31] <brendand> mvo, so there must be something i can test ;)
[08:31] <mvo> brendand: the branch above (#1632) was the last blocker we are/were aware of, so once that is fully build I will create a new test image, if nothing goes wrong  ~30min to 1h
[08:32] <mvo> (then the test image is ready for … testing :)
[08:32] <brendand> hth
[08:35] <mup> PR snapcraft#708 closed: Add support for use of pip constraints <Created by javacruft> <Closed by javacruft> <https://github.com/snapcore/snapcraft/pull/708>
[09:19] <mup> PR snapd#1572 closed: interfaces: add bluetooth-control interfaces <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1572>
[09:28] <mwhudson> mvo: hey, i was wondering, are there any other expected users for snap create-user other than first boot stuff?
[09:29] <mwhudson> mvo: it would be convenient if it reported the new user's username in a easier to parse form :-)
[09:31] <mvo> mwhudson: happy to store it in whatever way you want
[09:32] <mvo> mwhudson: first-boot is the big use-cas
[09:32] <mwhudson> mvo: in the longer term, it would also be good to know if the user had ssh keys or not
[09:32] <mwhudson> mvo: so, i dunno, yaml on stdout or something?
[09:33] <ogra_> Odd_Bloke, uuh, no idea, i dont think that can work
[09:33] <mvo> mwhudson: I can give you a switch for this I think, probably not as default
[09:33] <ogra_> a container might
[09:33] <mwhudson> mvo: yeah, makes sense
[09:33] <mwhudson> mvo: i wonder if "sudoer or not" should be a switch too?
[09:34] <mvo> mwhudson: yeah, probably
[09:35] <Odd_Bloke> ogra_: Oh. :(
[09:36] <mwhudson> mvo: should i comment on the pr to this effect or do you remember when people badger you on irc? :)
[09:36] <Cavan> I'm trying to set up an eviorment to get my snap to run in confined, I keep getting the error: Issues while validating snapcraft.yaml: Additional properties are not allowed ('environment' was unexpected)
[09:37] <ogra_> Cavan, i'm not sure the environment handling has been released yet
[09:38] <Odd_Bloke> ogra_: So is there currently a plan to handle pre-installing snaps in classic images built by the buildds?  (I'm guessing this is a pretty similar issue.)
[09:39] <Cavan> I was following the 'https://bugs.launchpad.net/snappy/+bug/1583259' but if its not released yet thats fair enough. Any Idea when it will be? can't complete my snap because it wont run in confined
[09:39] <mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Triaged by sergiusens> <Snappy:New> <click-reviewers-tools (Ubuntu):Fix Released>
[09:39] <mup> <click-reviewers-tools (Ubuntu Xenial):In Progress> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
[09:39] <mvo> mwhudson: a short comment (or irc paste) of this in the PR would be great, sometimes I have the memory of a goldfish
[09:40] <ogra_> Odd_Bloke, that would likely happen at install time, not prior to it
[09:41] <Odd_Bloke> Ah, OK.
[09:41] <Odd_Bloke> That makes things awkward in the cloud image world. :/
[09:43] <mwhudson> ogra_: hey did you see my mail about making things writable?
[09:43] <mwhudson> things == /etc/netplan, /var/lib/firstboot or something
[09:43] <ogra_> mwhudson, yeah, i'll take care of the change today
[09:44] <mwhudson> ogra_: yay
[09:44] <Cavan> So is the enviorment handling realeased, I'm confused sorry aha?
[09:44] <ogra_> mvo, dragon fails to start the login service again and cloud-init falls on its face too ... was it szupposed to work yet ?
[09:45] <ogra_> Cavan, if you mean snap-confine, i think it is still sitting in xenial-proposed
[09:45] <ogra_> https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu0.16.04.4
[09:45] <ogra_> yeah
[09:47] <Cavan> ogra_, sorry what does 'xenial-proposed' mean?
[09:47] <mvo> ogra_: not yet, soon
[09:47] <ogra_> Cavan, the test archive where things go for testing before they go into xenial-updates
[09:47] <ogra_> mvo, ah, k ...
[09:47] <mvo> ogra_: in ~30min maybe
[09:48] <ogra_> no huryy, just wanted to know if i should expect anything :)
[09:49] <ogra_> mvo, when exactly do we mount the snaps, are we sure that happens only after resizing ?
[09:49]  * ogra_ would like to know why the first boot fails differently to the others
[09:50] <Cavan> ogra_, ah thanks. Is there anyway around my 'calling nohup' problem until then or should I just wait?
[09:52] <ogra_> Cavan, the xenial task of that bug is still "In Progress" :)
[09:56] <mvo> ogra_: please give dragonboard a go again
[09:56] <mvo> ogra_: I will not do images for now because we are still missing the final gadget/kernel name
[09:58] <ogra_> mvo, yeah ... dobnt forget they should go to cdimage (which means we can definitely not use it anymore for builds now until we rip out the publishing)
[09:59] <ogra_> hmm, pi2 bootd very slow but not a single failure yet
[09:59] <mvo> ogra_: yeah, happy to push them to cdimage once we had a chance to test them a little bit more
[09:59] <mvo> ogra_: cloud init makes it slow
[09:59] <mvo> ogra_: same here fwiw, no error, I'm re-doing the amd64 image now
[09:59] <ogra_> well, it prints:
[09:59] <ogra_>          Mounting Mount unit for ubuntu-core...
[09:59] <ogra_> [  OK  ] Mounted Mount unit for ubuntu-core.
[09:59] <ogra_> does it copy the snaps around ?
[10:00] <mvo> ogra_: no, just mounts them to /snap/ubuntu-core/243324
[10:00] <ogra_> (and yes, cloud-init starts before that but the output makes it look like the mount is super slow)
[10:01] <ogra_> dragon is dd'ing ...
[10:01] <mvo> cool
[10:01]  * ogra_ snap installs htop on the pi
[10:02] <ogra_> curious if the interfaces are actually there and working
[10:05] <ogra_> yay, cool
[10:05] <ogra_> works after connection system-observe
[10:05] <ogra_> *connecting
[10:06] <ogra_> nice ... the OS eats less than 50MB RAM ...
[10:06] <ogra_> (when idling)
[10:07] <ogra_> mvo, dragon looks pretty good, i'm at the login prompt
[10:08] <ogra_> no networking indeed :/
[10:10]  * ogra_ creates a manual /e/n/i.d entry and reboots
[10:12] <ogra_> woah ... htop on the dragon shows 85MB ram usage on idle ...
[10:12] <ogra_> mvo, so looks like both images are good here
[10:14] <ogra_> hmm ...
[10:14] <ogra_> i wonder if classic mode works
[10:14] <sheh_> How can I update the ubuntu-core package without internet connection?
[10:15] <ogra_> i dont think you can
[10:15] <ogra_> you could try to snap install it from a local .snap file, but not sure that will work
[10:16] <ogra_> WHEEE !
[10:17] <ogra_> ubuntu@localhost:~$ sudo classic.shell
[10:17] <ogra_> (classic)ubuntu@localhost:~$ uname -a
[10:17] <ogra_> Linux localhost.localdomain 4.4.0-1022-snapdragon #25-Ubuntu SMP Fri Jul 22 22:11:20 UTC 2016 aarch64 aarch64 aarch64 GNU/Linux
[10:17] <ogra_> (classic)ubuntu@localhost:~$
[10:17] <ogra_> mvo, ^^^
[10:17] <ogra_> we need to add more output to "sudo classic.create" ... it sits there for a long time very quietly before it starts to do anything
[10:18] <ogra_> oh
[10:18] <ogra_> and we need to make sudo work
[10:18] <ogra_> (classic)ubuntu@localhost:~$ sudo apt-get update
[10:18] <ogra_> sudo: no tty present and no askpass program specified
[10:19] <timothy> ogra_: adding NOPASSWD in sudoers should fix it
[10:21] <ogra_> timothy, yeah, but i want it to ask for a password ...
[10:21] <ogra_> the wrapper script needs to properly mount /dev/pts
[10:26] <ogra_> bug 1564369
[10:26] <mup> Bug #1564369: sudo broken in latest classic <Snappy:Confirmed> <https://launchpad.net/bugs/1564369>
[10:26] <mvo> ogra_: good stuff. I will upload that once we have final names
[10:26] <ogra_> (it is a rergression)
[10:27] <ogra_> /dev/pts needs its own mount in the script ... currently only /dev is bind mounted
[10:28] <mvo> ogra_: let me upload a fix
[10:29] <ogra_> hmm, there is more
[10:29] <ogra_> logging in with "sudo SUDO_USER="" classic.shell" gets me a root shell ...
[10:29] <mvo> ogra_: can you please try r5
[10:29] <ogra_> but apt update falls over
[10:30] <ogra_> 0% [1 InRelease gpgv 247 kB] [2 InRelease 43.0 kB/95.7 kB 45%]Couldn't create tempfiles for splitting up /var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-Err:1 http://ports.ubuntu.com/ubuntu-ports xenial InRelease
[10:30] <ogra_> seems we are also missing some additional writable places
[10:30] <ogra_> err
[10:30] <ogra_> or not
[10:30] <ogra_> Could not execute 'apt-key' to verify signature (is gnupg installed?)
[10:31] <ogra_> i guess we neerd that in the tarball
[10:32] <ogra_> oh
[10:32] <ogra_> apt-get works, just apt doesnt
[10:32] <ogra_> thats interesting
[10:33] <mvo> ogra_: indeed, looking
[10:37] <ogra_> aha
[10:37] <ogra_> drwxr-xr-x   2 root root 4096 Aug  4 10:33 tmp
[10:37] <ogra_> i guess thats the issue
[10:37] <mvo> ogra_: yes
[10:38] <ogra_> yeah, works
[10:38] <mvo> ogra_: /tmp in the core snap has the wrong permissions
[10:38] <mvo> ogra_: probably a livecd rootfs fix
[10:38] <ogra_> mvo, no, that was a snapcraft issue i fixed in the PPA
[10:39] <ogra_> mvo, are you sure that snap was built with the PPA on ?
[10:39] <ogra_> (the ubuntu-core one)
[10:39] <mvo> ogra_: yeah, I triggered it from the ppa
[10:39] <ogra_> weird
[10:39]  * ogra_ downloads
[10:40]  * mvo lunches
[10:43] <ogra_> mvo, hmm the patch is in and i.e. /home7ubuntu has the right permissions  .. but /tmp is still  wrong, so you might be right that we need to chmod it from a hook
[11:07] <mwhudson> oh yeah, i noticed that too
[11:44] <mup> Bug #1609757 opened: Enable ordering of services provided by a snap <Snappy:New> <https://launchpad.net/bugs/1609757>
[11:53] <mup> Bug #1609762 opened: Enable snaps to run before SSH comes up in classic boot process <Snappy:New> <https://launchpad.net/bugs/1609762>
[11:57] <Odd_Bloke> niemeyer: Any movement/further thoughts on https://bugs.launchpad.net/snappy/+bug/1607710 ?
[11:57] <mup> Bug #1607710: Use passwd to determine user home directory <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1607710>
[12:00] <ogra_> Odd_Bloke, that wouldnt work on snappy images
[12:00] <ogra_> (because /etc/passwd is only used for system users created at ubuntu-core snap creation time and is readonly)
[12:01] <ogra_> you should rather use a tool that can handle the different backends
[12:02] <Odd_Bloke> ogra_: Well, I'm not that bothered about how it's implemented, but the jenkins user should really be able to write to its home directory (i.e. /var/lib/jenkins).
[12:04] <Odd_Bloke> I've changed the title to "Home directories listed in /etc/passwd should be honoured by home interface".
[12:05] <ogra_> Odd_Bloke, well, that still weouldnt solve the issue ... if a juju snap on a snappy image would creat a user it would be handled by libnss-extrausers and not show up in /etc/passwd
[12:06] <Odd_Bloke> I'm not proposing a generic solution to this problem; I am describing a part of the problem space which has (presumably) not yet been considered.#
[12:20] <mup> PR snapcraft#710 opened: Make formatting of daemon options consistent <Created by OddBloke> <https://github.com/snapcore/snapcraft/pull/710>
[12:27] <Chipaca> ogra_: the problem with what Odd_Bloke needs is that it implies a level of dynamism in apparmor rules i'm not sure we support
[12:27] <Chipaca> it's not really a niemeyer question but a jdstrand question, as such
[12:27] <ogra_> yeah
[12:27] <ogra_> Chipaca, well, it brings up a general question about images vs classic too
[12:28] <Chipaca> ogra_: how so?
[12:29] <ogra_> Chipaca, if a snap is ever allowed to create its own user the user will not end up in /etc/passwd on images
[12:29] <brendand> mvo, something i can try yet?
[12:29] <ogra_> so you cant just grep it from there
[12:29] <mup> PR snapcraft#710 closed: Make formatting of daemon options consistent <Created by OddBloke> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/710>
[12:29] <Chipaca> ogra_: I mean, Odd_Bloke's request is to use passwd-the-data-structure, not explicitly /etc/passwd, as i read it
[12:30] <Chipaca> ogra_: ie getpwent or whatever it is called
[12:30] <mvo> brendand: ups, sorry http://people.canonical.com/~mvo/all-snaps/16/all-snaps-pi2.img.xz
[12:31] <Chipaca> ogra_: snap install xbill-xaw :-p
[12:31] <Chipaca> no highscores as yet, didn't feel like patching it
[12:31] <ogra_> xbill !!!
[12:34] <Chipaca> jdstrand: any updates on shipping i386 binaries in amd64 snaps?
[12:34] <Chipaca> I've got a rather old binary I'd like to snap :-D
[12:48] <jdstrand> Chipaca: re /etc/passwd-- that file is read and we could read any other file. apparmor itself needs to know ahead of time, but there are ways of doing that, for example, updating /etc/apparmor.d/tunables/home.d
[12:48] <jdstrand> drop files in there and @{HOME} can expand to other things
[12:53] <mup> Bug #1602845 opened: unity7 interface does not work with libnotify <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1602845>
[12:56] <mup> Bug #1596717 opened: please add getsockopt to pulseaudio interface <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1596717>
[12:57] <mup> Bug #1605768 opened: incomplete 'opengl' interface <snapd-interface> <Snappy:Fix Committed by jdstrand> <https://launchpad.net/bugs/1605768>
[12:57] <jdstrand> Chipaca: as for i386 binaries on amd64, that is a seccomp limitation. I'm trying to find the bug
[12:57] <Chipaca> jdstrand: :-(
[12:58] <jdstrand> bug #1592022
[12:58] <mup> Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1592022>
[13:12] <mup> Bug #1609792 opened: Interface to access .git directories <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1609792>
[13:19] <brendand> what's an easy way to make an arm build of a snap?
[13:20] <ogra_> cjwatson, so whom do i have to bribe to have s390x for https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ? (the setup page just talks about "Admins" )
[13:20] <brendand> do i need to perform the build on the desired arch, or is there another way?
[13:20] <ogra_> brendand, right, you need to do it natively
[13:20] <ogra_> iirc kernel snaps are an exception (since they dont really use dependencies)
[13:23] <Odd_Bloke> ogra_: I generally ask for architectures to be added to (livefses|PPAs) in #webops in Canonical IRC; I expect it's similar.
[13:31] <sborovkov> brendand: for rpi I use Ubuntu Mate and build there. So you could do the similar thing I guess
[13:33] <ogra_> sborovkov, well, there should be new snappy images before EOW
[13:34] <ogra_> so you can just use the classic shell on it and install snapcraft
[13:34] <sborovkov> oh right, that works as well
[13:34] <sborovkov> I just have Mate for that since 15.04
[13:35]  * ogra_ too, but i hate having to swap SD cards all the time
[13:47] <mup> PR snapd#1630 closed: daemon: stop using group membership as succedaneous of running things with sudo <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1630>
[14:05] <Odd_Bloke> I'm snapping something which has some npm dependencies, but then needs to run a "compilation" command using the installed dependencies.
[14:05] <Odd_Bloke> I'm using a nodejs part at the moment, to get all the dependencies, but I'm not sure how to go about then running that command with all the things in place.
[14:08] <ogra_> mvo, hmmm
[14:08] <ogra_> ubuntu@localhost:~$ sudo classic.shell
[14:08] <ogra_> Failed to start transient scope unit: Unit classic.scope already exists.
[14:08] <ogra_> i am already logged in and have a classic shell running from another machine ... is there a way that we can allow multiple ones ?
[14:08] <mvo> ogra_: yes, a simple matter of programming
[14:09] <ogra_> k
[14:15] <beowulf> Odd_Bloke: what's the compilation command?
[14:15] <Odd_Bloke> "browserify -t coffeeify -d js/git-deps-graph.coffee -o js/bundle.js"
[14:16] <Odd_Bloke> (Which I'll then need to put in the right place for it to be found by a Flask web server :)
[14:25] <beowulf> Odd_Bloke: i'm not sure what the correct snapcraft way would be, but i might look at wrapping the nodejs thing you are using in an npm package and using an npm postinstall hook to run the transform (which would use local browserify) https://docs.npmjs.com/misc/scripts
[14:32] <SamYaple> sergiusens: what do you think of javacrufts suggestion to create a common python base class for python2 and python3?
[14:32] <SamYaple> sergiusens: should only take me a day or so to implement and would get rid of alot of dup
[14:42] <popey> Anyone ( dholbach / didrocks ?) had "Error: unsupported locale setting" when launching a snapped app at all?
[14:43] <popey> I tried snapping calibre (the ebook manager) and it barfs on launch:- http://paste.ubuntu.com/22183092/
[14:43] <dholbach> hum, no I haven't seen that one yet
[14:43] <popey> ok
[14:47] <sergiusens> SamYaple sure, if you feel like it would make for a good improvement, go ahead; when there is so much duplication like this we have been preferring to just make the plugin parametrizable like the qmake one... due to backwards compatibility woes I guess we cannot atm
[14:48] <sergiusens> SamYaple btw, I went a ahead and fixed this https://github.com/snapcore/snapcraft/pull/707
[14:48] <mup> PR snapcraft#707: Use the proper requirements.txt path <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
[14:48] <sergiusens> not sure you mind if I go ahead and get it in
[14:49] <SamYaple> sergiusens: do your thing. i dont mind rebasing
[14:49] <SamYaple> ill look into the qmake one to see the deal
[14:51] <didrocks> popey: not that one by itself
[14:51] <SamYaple> sergiusens: we can do what is done with qmake and create a new plugin called python, having python2 and python3 extend the new python plugin and then deprecate python2 and python3
[14:51] <didrocks> some different variant, but I can it's about missing locales in general
[14:51] <ogra_> popey, add libc and the locale package to your snap and make sure to a) generate the right locales on first startup and b) point the env variables to the generated locales
[14:52] <ogra_> popey, see nethack.sh and snapcraft.yaml https://github.com/ogra1/nethack
[14:52] <popey> hm
[14:52] <popey> okay, thanks
[14:52] <ogra_> line 7-21 in netchack.sh specifrically
[14:53] <popey> thank you
[14:53] <sergiusens> SamYaple sounds a lot better; while you are at it; if you don't mind experementing; make the stage-packages python-dev one a build-package and see if everything still works fine
[14:54] <sergiusens> SamYaple that might be asking for too much, but it would make for smaller default python snaps
[14:54] <SamYaple> sergiusens: im going to be working on the python plugins for a while as i need ot make changes for what im packaging (openstack in this case) so ill play with that
[14:54] <SamYaple> sergiusens: i am still hitting C901 in that PR though.
[14:54] <sergiusens> SamYaple \o/
[14:54] <SamYaple> cant reproduce that locally
[14:55] <sergiusens> SamYaple hmm, might be the version of flake8/mccabe being used
[14:55] <sergiusens> we've seen these before
[14:55] <cmagina> can you give an app access to fchown on files it created itself?
[14:56] <sergiusens> cmagina anything can be done really, the thing is, why would you need that?
[14:56] <sergiusens> sqlite?
[14:56] <SamYaple> sergiusens: ah. youre using the deb and im pip installing. let me test that
[14:56] <sergiusens> SamYaple if you are on latest and greatest I think we pip install everything now
[14:57] <cmagina> sergiusens: its trying to verify the files weren't created via a sudo run. not really an issue in a snap environment, but its a workaround for non-snap environments :)
[14:57] <cmagina> sergiusens: fish
[14:57] <cmagina> figured it was simple, see what limitations it hits, i figured it would hit some :)
[14:57] <sergiusens> cmagina can't that logic be removed then?
[14:57] <SamYaple> sergiusens: https://travis-ci.org/snapcore/snapcraft/jobs/149773303 <--- it seems no. python3-flake8
[14:57] <sergiusens> in the end, something will need to change for tihis to work
[14:58] <sergiusens> SamYaple ah, interesting; elopio any reason for using python3-flake8 instead of a requirements-test.txt one?
[14:58] <SamYaple> and i am confirming that is the delta
[14:58] <SamYaple> latest flake8 doesnt have the c901 issue
[14:58] <cmagina> sergiusens: yeah, that wouldn't fly with upstream. why can't snap allow a program to change permissions on its own files?
[14:59] <sergiusens> cmagina I would ask jdstrand who is in the security team
[14:59] <cmagina> sergiusens: ok, thanks
[14:59] <sergiusens> SamYaple ah, good to know, in any case we'd lock down the version to the one in xenial to be able to continue building with it
[15:00] <cmagina> jdstrand: trying to snap a shell, fish, and it has code to ensure ownership of its history file using fchown, this causes a seccomp error with snap
[15:00] <ogra_> cmagina, to what would you change these permissions, given you cant create a user or anything
[15:00] <SamYaple> sergiusens: thanks for the help. ill get the PR into shape and work on the refactor of python
[15:01] <ogra_> and if you copy somethiong to $SNAP_USER_DATA for eth executing user it should automatically be created with the ownership of the calling user
[15:07] <cmagina> ogra_: yeah, the permissions look correct, not sure why its falling into this code path yet. it works fine in devmode of course
[15:09] <sergiusens> SamYaple thank you!
[15:24] <jdstrand> cmagina: we'll fix that when the snap-confine is available in 16.04
[15:24] <cmagina> jdstrand: awesome, thanks
[15:24] <jdstrand> cmagina: it has a required feature called seccomp arg filtering that we can use to open up things like chown
[15:25] <cmagina> jdstrand: alright, good to hear
[15:33] <jdstrand> cmagina: for now, feel free to use --devmode or if you are trying to test locally, you can add the syscalls to /var/lib/snapd/seccomp/profiles/snap.your.app (they won't survive a snap refresh/reinstall/etc but the technique can be handy)
[15:35] <cmagina> jdstrand: yeah, i used devmode already, but i will look into adding the syscalls, thanks for that pointer
[15:46] <mup> Bug #1609864 opened: Enable a command to be run on machine shutdown <Snappy:New> <https://launchpad.net/bugs/1609864>
[15:54] <elopio> sergiusens: I don't know. I think we only use it in travis, so the one from pip should work.
[15:55] <elopio> it is in the dep8 integration tests as a dependency, but I think that's wrong. We should remove it.
[15:55] <elopio> SamYaple: can you please file a bug? Bonus points for fixing it too :)
[15:56] <elopio> sergiusens: https://github.com/snapcore/snapcraft/pull/687 Ready.
[15:56] <mup> PR snapcraft#687: Enable integration tests to run in the production store <Created by elopio> <https://github.com/snapcore/snapcraft/pull/687>
[15:56] <SamYaple> elopio: are you saying we _want_ to be using flake8 from pip rather than package install?
[15:57] <SamYaple> once i knew what version to install the test passed locally. honestly this might be a bug in flake8
[15:57] <mhall119> zyga: I'm in another call still, do you want to reschedule ours?
[15:59] <elopio> SamYaple: I think that for people hacking snapcraft it would be nicer to set up the environment in a virtualenv.
[15:59] <elopio> with the recent changes in requirements.txt, that's doable now easily. So yes, maybe from pip is a good idea, and it will be more recent than the one in debian.
[16:00] <elopio> what do you think?
[16:04] <trijntje> Is there a list of what kind of issues will trigger a manual review when publishing a snap? I made a hello world snap with a license that has to be accepted and its status is now 'manual review pending'
[16:09] <mup> PR snapd#1633 opened: many: move to purely hash based key lookup and to new key/signature format (v1) <Created by emgee> <https://github.com/snapcore/snapd/pull/1633>
[16:09] <elopio> trijntje: you can run the click reviewers tool.
[16:09] <elopio> https://launchpad.net/click-reviewers-tools
[16:12] <trijntje> elopio: http://pastebin.com/nB2K7VqR
[16:13] <elopio> trijntje: you need at least one app in there, or user architectures: [all]
[16:13] <elopio> the policy vendor thing, I don't know. Haven't seen that before.
[16:16] <trijntje> elopio: can you elaborate on the user architectures bit? I haven't seen that anywhere
[16:17] <kyrofa> jdstrand, zyga how is that snap-confine SRU going?
[16:19] <kyrofa> Ah nevermind, I see another discussion about it
[16:21] <elopio> trijntje: https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/basic/snapcraft.yaml#L5
[16:25] <mup> Bug #1609883 opened: Add an interface to allow access to /var/lock and/or /run/lock/ <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1609883>
[16:27] <trijntje> elopio: thanks, I couldn't find that metadata field in the docs for some reason
[16:30] <Odd_Bloke> In the following, is my snap trying to execute /sbin/hwclock in the system or in the ubuntu-core snap:  audit: type=1400 audit(1470327924.785:509): apparmor="ALLOWED" operation="exec" profile="snap.gce-compute-image-packages.google-clock-skew-daemon" name="/sbin/hwclock" pid=3230 comm="python3" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
[16:30] <Odd_Bloke> target="snap.gce-compute-image-packages.google-clock-skew-daemon//null-/sbin/hwclock"
[16:35] <SamYaple> elopio: i agree. the reason im in this situation is because im using a virtualenv
[16:35] <SamYaple> elopio: ill file the bug, though im not familiar with the testing suite for snapcraft, ill look at it
[16:43] <slangasek> Odd_Bloke: wrt pre-installing of snaps, I'm afraid I hadn't noticed this issue.  There needs to be some way to preinstall a snap, certainly
[16:43] <slangasek> Odd_Bloke: a model assertion declares a list of required snaps
[16:44] <slangasek> Odd_Bloke, gaughen: and 'snap prepare-image' (which, afaik, hasn't landed to trunk yet) should download these and put them all in the right place, without relying on a snapd running on the host system
[16:45] <slangasek> Odd_Bloke, gaughen: so perhaps the right answer is simply "put it in the model assertion, and trust that this will shake out over the next couple of weeks"?  (Since it's required for RTM)
[16:45] <slangasek> oh shoot
[16:46] <slangasek> you're talking about pre-installing snaps for an image that is not an all-snap image
[16:46] <Odd_Bloke> slangasek: So this specific question fell out of classic images.
[16:46]  * slangasek think think
[16:46] <Odd_Bloke> Yeah.
[16:46]  * gaughen nods
[16:46] <slangasek> ok
[16:46] <slangasek> we're going to have a 'snap fetch', I think?
[16:46] <Odd_Bloke> Yeah, I've heard about that in the context of caching a snap for later installation.
[16:47] <slangasek> Odd_Bloke: right.  So I think that we may need to do a 'snap fetch', followed by a bit of manual fiddling to put the snap bits in the right place as part of the image build
[16:47] <mup> PR snapcraft#711 opened: Add make-install-var field to the make plugin <Created by blakerouse> <https://github.com/snapcore/snapcraft/pull/711>
[16:47] <slangasek> niemeyer: ^^ maybe you'd be able to comment on this problem (pre-installing snaps as part of a classic image build, which happens in a chroot with no running snapd service)
[16:49] <mup> Bug #1609792 changed: Interface to access .git directories <snapd-interface> <Snappy:Invalid> <https://launchpad.net/bugs/1609792>
[16:53] <mup> PR snapcraft#687 closed: Enable integration tests to run in the production store <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/687>
[17:01] <Odd_Bloke> slangasek: Shall I file a bug so we have somewhere more persistent than IRC to track this?
[17:13] <slangasek> Odd_Bloke: seems advisable
[17:19] <Odd_Bloke> slangasek: niemeyer: I've filed that as https://bugs.launchpad.net/snappy/+bug/1609903
[17:19] <mup> Bug #1609903: Enable the installation of snaps in a classic chroot <Snappy:New> <https://launchpad.net/bugs/1609903>
[17:20] <mup> Bug #1609903 opened: Enable the installation of snaps in a classic chroot <Snappy:New> <https://launchpad.net/bugs/1609903>
[17:48] <aatchison> hello
[17:57] <ahoneybun> mm they removed the snap find ?
[17:57] <ahoneybun> commdn
[17:58] <mup> PR snapd#1634 opened: store: add device nonce API support <Created by matiasb> <https://github.com/snapcore/snapd/pull/1634>
[18:09] <aatchison> lol, hi ahoneybun
[18:10] <aatchison> So, I either need to be able to call one part from inside another, or call an application from within another snap, is that possible at this time?
[18:10] <ahoneybun> not sure, I'm a noobie at this
[18:11] <aatchison> I made some progress with mycroft, but I need to call mimic...
[18:12] <ahoneybun> oh aatchison
[18:12] <aatchison> what's up hehe
[18:12] <ahoneybun> I'm on the slack channel
[18:13] <ahoneybun> for Mycroft
[18:15] <aatchison> ahh, cool
[18:15] <aatchison> I'm just asking around these parts for some snap specific stuff
[18:16] <ahoneybun> yea I tried to make a snap for pithos but got stuck
[18:17] <ahoneybun> I think mycroft would hit the same bug as it would make a service
[18:18] <ahoneybun> yay finally got into to my Mycroft unit!
[18:18]  * ogra_ notes that Chipaca has his own article on omgubuntu.co.uk today
[18:19] <ahoneybun> I don't see anything about Chipaca
[18:19] <ogra_> ahoneybun, Chipaca is john lenton ... quoted about 50 times in the snap find article
[18:20] <kyrofa> Ouch
[18:20] <ogra_> ("felt" 50 times, i didnt actually count them :) )
[18:20] <aatchison> I'm using daemon: simple, and the services are running ok
[18:20] <aatchison> I just need to reference one app from another, or an app from another snap
[18:20] <aatchison> aka, mimic
[18:21] <ahoneybun> is there a mycroft room aatchison?
[18:22] <aatchison> yeah, #mycroft is the channel on freenode, but it's bridged to our general slack channel
[18:22] <kyrofa> aatchison, you can't reference one app from another in that mycroft.app1 can't call mycroft.app2 (defined by those present in /snap/bin/)
[18:22] <kyrofa> aatchison, but you can still call the command itself
[18:23] <aatchison> hmm. So, in my case, I've tried to add a part for mimic, and it runs on it's own, but calling 'mimic' doesn't work, as there is the mycroft-core.mimic prefix. I tried calling it by that name as well, maybe I'm doign something wrong
[18:24] <aatchison> wait, command itself?
[18:24] <aatchison> no need to define an app?
[18:27] <ahoneybun> mm we can make snaps from deb's right?>
[18:28] <aatchison> not that I know of
[18:30] <ahoneybun> I mean it's not that different from source
[18:31] <kalikiana> ahoneybun: "from debs" meaning what exactly?
[18:31] <ahoneybun> https://github.com/kasramp/UbuntuIndicatorWeather/releases/download/v0.5/indicator-weather_0.5ubuntu_all.deb
[18:31] <brendand> is there any detailed tutorial on how interfaces/plugs/slots work? the docs i can find seem a bit sparse
[18:31] <kalikiana> ahoneybun:  you could have a snap that just pulls in stage-packages for indicator-weather if that's what you mean
[18:32] <ahoneybun> I guess I could just install the deb
[18:32] <kyrofa> aatchison, snaps don't have access to /snap/bin, so they can't call things that are in there
[18:33] <ogra_> you can also pull the deb source and dpkg-buildpackage/debuild it :)
[18:33] <kyrofa> aatchison, but they can definitely call things within themselves, so just use the `command` you used for the app
[18:33] <kalikiana> ahoneybun: It may be worth asking another question first: (how) can an indicator be snapped so that it shows up in the panel
[18:33] <kyrofa> apps are for exporting for _users_ to call
[18:33] <kyrofa> (or services)
[18:33] <ogra_> (i do that in some snaps via a Makefile and the make plugin)
[18:33] <ahoneybun> kalikiana: if it has access to the panel
[18:34] <kalikiana> ahoneybun: well, it'd be somewhat pointless without that, no? :-D
[18:35] <ahoneybun> yea it would
[18:35] <ahoneybun> lol
[18:35] <kalikiana> I'm guessing it would be using daemon
[18:35] <kalikiana> But not sure about the dbus side
[18:35] <ogra_> thats a tricky one ...
[18:35] <ahoneybun> yea dbus can't be accessed with services or something
[18:36] <ogra_> daemon actually refers to a system deamon
[18:36] <ogra_> which an indicator isnt
[18:36] <ogra_> we'd need something like "session-daemon" for that specific usecase
[18:36] <ahoneybun> pithos needed access as well
[18:37] <ogra_> (and it might need to hook into a systemd user session ... which ubuntu has only in yakkety ... which in turn isnt really a snappy target)
[18:38] <mup> PR snapcraft#690 closed: Preserve file ownership for 'os' snaps <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/690>
[18:38] <ogra_> \o/
[18:38]  * ogra_ hugs sergiusens 
[18:39] <Chipaca> ogra_, omgubuntu really needs to practice its reading comprehension before writing these articles
[18:39] <ogra_> heh
[18:39] <Chipaca> responded as well as i could
[18:39] <aatchison> I'm also having a boatload of problems trying to run ubuntu core on the pi3 :D
[18:39] <ogra_> he makes sound a bit like that was solely your decision
[18:40] <ogra_> aatchison, http://people.canonical.com/~ogra/snappy/all-snaps/ fresh from the press
[18:40] <aatchison> hurray!
[18:40] <aatchison> Always saving my bum
[18:41] <ogra_> still experimental, mind you :)
[18:41] <ogra_> but should be good enough for tinkering
[18:41] <aatchison> everything I'm working with is hehe
[18:41] <aatchison> cool
[18:41] <ogra_> :)
[18:41] <sergiusens> Chipaca congrats on the promotion to marketting btw
[18:41] <ogra_> LOL
[18:42] <Chipaca> sergiusens, I come from U1. Bring it on.
[18:43] <niemeyer> jdstrand: Some updates on snapd#1409.. can you please have a look when you have a moment and let me know what you think
[18:43] <mup> PR snapd#1409: docs/interfaces.md: improve interfaces documentation <Created by jdstrand> <Conflict> <https://github.com/snapcore/snapd/pull/1409>
[18:44] <niemeyer> jdstrand: Would like to get that to a conclusion soonish, or else break it down into pieces we can more easily agree upon
[18:45] <mup> PR snapd#1635 opened: interfaces: builtin: add pluggable storage interface <Created by ssweeny> <https://github.com/snapcore/snapd/pull/1635>
[18:50] <ahoneybun> Chipaca: was there really a reason to remove snap find (I'm just curous)
[18:52] <sergiusens> ahoneybun it is not removed
[18:52] <sergiusens> ahoneybun it just requires a search param
[18:52] <trijntje> I'm trying to create a snap that requires accepting a license before install, but I don't get asked to accept the license when using snap install. Who can tell me what I did wrong? http://pastebin.com/bdzQLxuC
[18:53] <ahoneybun> snap find tele was a good way
[18:56] <niemeyer> jdstrand: One more: fgimenez addressed your comments on snapd#1550.. can you please re-review when you have a spare moment?
[18:56] <mup> PR snapd#1550: tests: base security spread tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1550>
[18:56] <niemeyer> trijntje: You didn't do anything wrong, we did! :)
[18:57] <niemeyer> trijntje: We dropped the license logic before 16.04 as we didn't want to commit to the form just yet
[18:57] <niemeyer> trijntje: This is coming back soon as a first-class term-acceptance mechanism
[18:57] <trijntje> niemeyer: ah, thats too bad, I just noticed deprecation warnings about license as well
[18:57] <niemeyer> trijntje: It will definitely come back
[18:57] <niemeyer> trijntje: For the time being, this may be done on the app side
[18:58] <niemeyer> trijntje: Hooking some logic that runs on the first execution
[19:00] <trijntje> niemeyer: I think I'll wait for the real mechanism to land. I've been talking to the owners of some popular bioinformatics software about snapping their products, but they require all users to accept their 'non comercial use' license
[19:01] <trijntje> So they want to see what the license implementation looks like before they'll allow their product on the ubuntu store
[19:01] <trijntje> Is there somewhere I can follow the development of this feature, or find a rough timeline for this?
[19:02] <jdstrand> niemeyer: ack
[19:04] <niemeyer> trijntje: Not sure if we have a ticket open.. would you mind to open one?
[19:04] <niemeyer> jdstrand: Thanks!
[19:05] <niemeyer> trijntje: I wouldn't block on it, though.. it seems so easy to show people the LICENSE file the first time they run the application
[19:05] <mup> PR snapcraft#707 closed: Use the proper requirements.txt path <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/707>
[19:06] <trijntje> niemeyer: where should I open a ticket for this?
[19:06] <elopio> thanks SamYaple. Let me know if I can help you with the test suite.
[19:06] <elopio> cprov: my branch landed in master. So remember to add TEST_STORE=staging
[19:07] <niemeyer> https://bugs.launchpad.net/snappy/+filebug
[19:07] <niemeyer> trijntje: ^
[19:07] <trijntje> niemeyer: I'll contact them and let them know that for now we can show the license on first use as a work around.
[19:07] <trijntje> But it will probably go to their legal team so they might want to opt to wait for the full feature to land
[19:08] <cprov> elopio: thanks, let me try.
[19:16] <trijntje> niemeyer: https://bugs.launchpad.net/snappy/+bug/1609930
[19:16] <mup> Bug #1609930: wishlist: re-enable mandatory click-through license for snaps <Snappy:New> <https://launchpad.net/bugs/1609930>
[19:17] <trijntje> to all: please set this bug to 'affects me' if you want this fixed ;)
[19:17] <mup> Bug #1609930 opened: wishlist: re-enable mandatory click-through license for snaps <Snappy:New> <https://launchpad.net/bugs/1609930>
[19:23] <niemeyer> trijntje: It affects all of us :)
[19:23] <niemeyer> trijntje: It'll definitely be fixed
[19:24] <trijntje> niemeyer: that is good to know, I'll contact the developers as well and see how they feel about having a workaround
[19:41] <niemeyer> morphis: Another one on #1623
[19:41] <niemeyer> morphis: Another one on snapd#1623
[19:41] <mup> PR snapd#1623: interfaces/udev,osutil: avoid doubled rules and put all in a per snap file <Reviewed> <Created by morphis> <https://github.com/snapcore/snapd/pull/1623>
[19:41] <niemeyer> trijntje: Let us know how it goes
[20:04] <Pharaoh_Atem> niemeyer: I figured you might get a kick out of this: https://www.yoctoproject.org/blogs/khem/2013/get-smart-smart-package-manager
[20:05] <kgunn> jdstrand: got a sec for some questions?
[20:05] <jdstrand> kgunn: I suspect it will be longer than a sec, but shoot :)
[20:07] <Pharaoh_Atem> niemeyer: https://www.yoctoproject.org/blogs/jefro/2013/yocto-project-14-dylan-released
[20:07] <Pharaoh_Atem> Smart is now used in most Yocto derived distros I know of: Wind River Linux, JunOS NG, etc
[20:08] <niemeyer> Pharaoh_Atem: Nice :)
[20:08] <Pharaoh_Atem> there's even a variant of Tizen that runs on Yocto where it uses smartpm instead of zypper
[20:09] <Chipaca> trijntje, they're aware they can make them private to get them working confined and all that, without blocking on this?
[20:21] <kgunn> jdstrand: got a sec for some questions? (sorry if this is a repeat)
[20:21]  * kgunn is having fun with network and irc
[20:23] <ali1234> is snapcraft cleanbuild supposed to work?
[20:27] <jdstrand> 15:05 < jdstrand> kgunn: I suspect it will be longer than a sec, but shoot :)
[20:37] <jdstrand> kgunn: 15:27 < jdstrand> 15:05 < jdstrand> kgunn: I suspect it will be longer than a sec, but shoot :)
[20:40] <kgunn> :)
[20:41] <kgunn> jdstrand: so i'm down to tuning as you know, and when i have
[20:41] <kgunn> unix (receive, send) type=seqpacket addr=none,
[20:41] <kgunn> it will connect fine
[20:41] <kgunn> sorry....when i have that in my connectedplug snippet
[20:41] <kgunn> but when i try to change that to
[20:42] <kgunn> unix (receive, send) peer=(label=###SLOT_SECURITY_TAGS###) type=seqpacket addr=none,
[20:42] <kgunn> i get a failure on the snap connect call
[20:42] <kgunn> like so
[20:42] <kgunn> https://pastebin.canonical.com/162369/
[20:43] <tsimonq2> kgunn: people not employed at Canonical can't see that
[20:46] <kgunn> sorry bad habit
[20:46] <kgunn> http://pastebin.ubuntu.com/22224395/
[20:46] <jdstrand> kgunn: use: unix (receive, send) type=seqpacket addr=none peer=(label=###SLOT_SECURITY_TAGS###),
[20:47] <jdstrand> kgunn: it appears ordering matters
[20:47] <kgunn> jdstrand: thanks
[20:48] <jdstrand> kgunn: fyi, a technique I use is copy a known good profile from somewhere to /path/to/profile, then modify /path/to/profile with rules I want, then see if it compiles with apparmor_parser -QTK /path/to/profile
[20:51] <jdstrand> kgunn: something like this: http://paste.ubuntu.com/22225124/
[21:03] <mup> Bug #1609965 opened: snapweb store is a blank page <Snappy:New> <snapweb:New> <https://launchpad.net/bugs/1609965>
[21:35] <kyrofa> jdstrand, I get "cannot remain in %s, please run this snap from another location" from snap-confine no matter what. Can you explain the logic there?
[21:36] <kyrofa> jdstrand, the %s is whatever path I'm in
[21:36] <kyrofa> Ah, I had to get back into /home apparenty
[21:36] <kyrofa> That's odd
[21:37] <jdstrand> kyrofa: I know there is some check for being in /tmp
[21:37] <jdstrand> otherwise the private /tmp isn't applied
[21:37] <kyrofa> jdstrand, I was in /gopath (and various subdirectories)
[21:37] <jdstrand> maybe cause that dir doesn't exist in the runtime env?
[21:38] <jdstrand> seems the error message could be better
[21:40] <kyrofa> jdstrand, so I can't run any commands from something that isn't accessible from the runtime environment? That seems problematic
[21:40] <kyrofa> s/something/somewhere/
[21:47] <jdstrand> I suggest filing a bug with your use case. this is the area zyga hsa worked most with
[21:48] <jdstrand> in terms of security, a strategically placed chdir(/) is enough to make sure all the bind mounts apply (and a corresponding chdir(orig) after)
[21:51] <kyrofa> jdstrand, use-case: all snapd's spread tests :P
[21:52] <kyrofa> But we can probably relocate them
[22:26] <tianon> there's not a snap of snapcraft yet? :o
[22:34] <mup> Bug #1610001 opened: Regression: snap run no longer runs hooks <Snappy:In Progress by kyrofa> <https://launchpad.net/bugs/1610001>
[22:51] <mup> PR snapd#1636 opened: snap: don't load unsupported implicit hooks <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1636>
[22:53] <mup> PR snapd#1637 opened: cmd/snap,cmd/snap-exec: support hooks again <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1637>
[22:53] <mup> PR snapcraft#697 closed: Also use INSTALLROOT for make plugin <Created by jhobbs> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/697>
[22:59] <tianon> kyrofa: kudos for snapcraft#680 :D  (went digging into why "plugin: python2" was creating bad shebangs for me and found you'd fixed in master already :D)
[22:59] <mup> PR snapcraft#680: Rewrite shebangs generated by the python plugins <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/680>
[23:50] <mup> PR snapcraft#709 closed: Improve the go plugins usability <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/709>
[23:59] <mup> PR snapcraft#711 closed: Add make-install-var field to the make plugin <Created by blakerouse> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/711>