=== JanC_ is now known as JanC [01:18] kyrofa one more look at https://github.com/snapcore/snapcraft/pull/707 maybe? [01:18] PR snapcraft#707: Use the proper requirements.txt path [03:07] kyrofa if you are still around can you do a review of this for me ? https://github.com/snapcore/snapcraft/pull/689 [03:07] PR snapcraft#689: kernel plugin: kernel targets depending on debarch [03:13] PR snapcraft#709 opened: Improve the go plugins usability [03:54] PR snapd#1631 opened: client, osutil: chown the auth file === chihchun_afk is now known as chihchun [05:23] 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] PR snapd#1632 opened: Do not install a snap if it is already valid [06:35] hey hey [06:38] good morning dholbach [06:38] salut didrocks [06:40] hey dholbach, re didrocks [06:40] salut seb128 [06:56] PR snapd#1561 closed: many: remove integration-test coverage metrics === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:16] * dholbach relocates to the office, bbiab === chihchun is now known as chihchun_afk [08:10] ogra_: o/ I was told to bug you about advice on how to install a snap within a chroot; any ideas? === dholbach_ is now known as dholbach [08:26] is vivid really the latest image available for raspberry pi2? [08:27] PR snapd#1632 closed: Do not install a snap again if it is already valid [08:30] brendand: yes, but we are working (hard) on updated images, the goal is to have them today [08:30] mvo, what a nice coincidence :) [08:31] mvo, so there must be something i can test ;) [08:31] 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] (then the test image is ready for … testing :) [08:32] hth [08:35] PR snapcraft#708 closed: Add support for use of pip constraints === chihchun_afk is now known as chihchun [09:19] PR snapd#1572 closed: interfaces: add bluetooth-control interfaces === chihchun is now known as chihchun_afk [09:28] mvo: hey, i was wondering, are there any other expected users for snap create-user other than first boot stuff? [09:29] mvo: it would be convenient if it reported the new user's username in a easier to parse form :-) [09:31] mwhudson: happy to store it in whatever way you want [09:32] mwhudson: first-boot is the big use-cas [09:32] mvo: in the longer term, it would also be good to know if the user had ssh keys or not [09:32] mvo: so, i dunno, yaml on stdout or something? [09:33] Odd_Bloke, uuh, no idea, i dont think that can work [09:33] mwhudson: I can give you a switch for this I think, probably not as default [09:33] a container might [09:33] mvo: yeah, makes sense [09:33] mvo: i wonder if "sudoer or not" should be a switch too? [09:34] mwhudson: yeah, probably [09:35] ogra_: Oh. :( [09:36] mvo: should i comment on the pr to this effect or do you remember when people badger you on irc? :) [09:36] 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] Cavan, i'm not sure the environment handling has been released yet [09:38] 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] 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] Bug #1583259: Snappy needs to influence environment variables in applications

[09:39]

[09:39] 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] Odd_Bloke, that would likely happen at install time, not prior to it [09:41] Ah, OK. [09:41] That makes things awkward in the cloud image world. :/ [09:43] ogra_: hey did you see my mail about making things writable? [09:43] things == /etc/netplan, /var/lib/firstboot or something [09:43] mwhudson, yeah, i'll take care of the change today [09:44] ogra_: yay [09:44] So is the enviorment handling realeased, I'm confused sorry aha? [09:44] 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] Cavan, if you mean snap-confine, i think it is still sitting in xenial-proposed [09:45] https://launchpad.net/ubuntu/+source/snap-confine/1.0.38-0ubuntu0.16.04.4 [09:45] yeah [09:47] ogra_, sorry what does 'xenial-proposed' mean? [09:47] ogra_: not yet, soon [09:47] Cavan, the test archive where things go for testing before they go into xenial-updates [09:47] mvo, ah, k ... [09:47] ogra_: in ~30min maybe [09:48] no huryy, just wanted to know if i should expect anything :) [09:49] 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] ogra_, ah thanks. Is there anyway around my 'calling nohup' problem until then or should I just wait? [09:52] Cavan, the xenial task of that bug is still "In Progress" :) [09:56] ogra_: please give dragonboard a go again [09:56] ogra_: I will not do images for now because we are still missing the final gadget/kernel name [09:58] 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] hmm, pi2 bootd very slow but not a single failure yet [09:59] ogra_: yeah, happy to push them to cdimage once we had a chance to test them a little bit more [09:59] ogra_: cloud init makes it slow [09:59] ogra_: same here fwiw, no error, I'm re-doing the amd64 image now [09:59] well, it prints: [09:59] Mounting Mount unit for ubuntu-core... [09:59] [ OK ] Mounted Mount unit for ubuntu-core. [09:59] does it copy the snaps around ? [10:00] ogra_: no, just mounts them to /snap/ubuntu-core/243324 [10:00] (and yes, cloud-init starts before that but the output makes it look like the mount is super slow) [10:01] dragon is dd'ing ... [10:01] cool [10:01] * ogra_ snap installs htop on the pi [10:02] curious if the interfaces are actually there and working [10:05] yay, cool [10:05] works after connection system-observe [10:05] *connecting [10:06] nice ... the OS eats less than 50MB RAM ... [10:06] (when idling) [10:07] mvo, dragon looks pretty good, i'm at the login prompt [10:08] no networking indeed :/ [10:10] * ogra_ creates a manual /e/n/i.d entry and reboots [10:12] woah ... htop on the dragon shows 85MB ram usage on idle ... [10:12] mvo, so looks like both images are good here [10:14] hmm ... [10:14] i wonder if classic mode works [10:14] How can I update the ubuntu-core package without internet connection? [10:15] i dont think you can [10:15] you could try to snap install it from a local .snap file, but not sure that will work [10:16] WHEEE ! [10:17] ubuntu@localhost:~$ sudo classic.shell [10:17] (classic)ubuntu@localhost:~$ uname -a [10:17] 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] (classic)ubuntu@localhost:~$ [10:17] mvo, ^^^ [10:17] 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] oh [10:18] and we need to make sudo work [10:18] (classic)ubuntu@localhost:~$ sudo apt-get update [10:18] sudo: no tty present and no askpass program specified [10:19] ogra_: adding NOPASSWD in sudoers should fix it [10:21] timothy, yeah, but i want it to ask for a password ... [10:21] the wrapper script needs to properly mount /dev/pts [10:26] bug 1564369 [10:26] Bug #1564369: sudo broken in latest classic [10:26] ogra_: good stuff. I will upload that once we have final names [10:26] (it is a rergression) [10:27] /dev/pts needs its own mount in the script ... currently only /dev is bind mounted [10:28] ogra_: let me upload a fix [10:29] hmm, there is more [10:29] logging in with "sudo SUDO_USER="" classic.shell" gets me a root shell ... [10:29] ogra_: can you please try r5 [10:29] but apt update falls over [10:30] 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] seems we are also missing some additional writable places [10:30] err [10:30] or not [10:30] Could not execute 'apt-key' to verify signature (is gnupg installed?) [10:31] i guess we neerd that in the tarball [10:32] oh [10:32] apt-get works, just apt doesnt [10:32] thats interesting [10:33] ogra_: indeed, looking [10:37] aha [10:37] drwxr-xr-x 2 root root 4096 Aug 4 10:33 tmp [10:37] i guess thats the issue [10:37] ogra_: yes [10:38] yeah, works === willcooke_ is now known as willcooke [10:38] ogra_: /tmp in the core snap has the wrong permissions [10:38] ogra_: probably a livecd rootfs fix [10:38] mvo, no, that was a snapcraft issue i fixed in the PPA [10:39] mvo, are you sure that snap was built with the PPA on ? [10:39] (the ubuntu-core one) [10:39] ogra_: yeah, I triggered it from the ppa [10:39] weird [10:39] * ogra_ downloads [10:40] * mvo lunches [10:43] 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] oh yeah, i noticed that too [11:44] Bug #1609757 opened: Enable ordering of services provided by a snap [11:53] Bug #1609762 opened: Enable snaps to run before SSH comes up in classic boot process [11:57] niemeyer: Any movement/further thoughts on https://bugs.launchpad.net/snappy/+bug/1607710 ? [11:57] Bug #1607710: Use passwd to determine user home directory [12:00] Odd_Bloke, that wouldnt work on snappy images [12:00] (because /etc/passwd is only used for system users created at ubuntu-core snap creation time and is readonly) [12:01] you should rather use a tool that can handle the different backends [12:02] 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] I've changed the title to "Home directories listed in /etc/passwd should be honoured by home interface". [12:05] 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] 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] PR snapcraft#710 opened: Make formatting of daemon options consistent [12:27] 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] it's not really a niemeyer question but a jdstrand question, as such [12:27] yeah [12:27] Chipaca, well, it brings up a general question about images vs classic too [12:28] ogra_: how so? [12:29] 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] mvo, something i can try yet? [12:29] so you cant just grep it from there [12:29] PR snapcraft#710 closed: Make formatting of daemon options consistent [12:29] ogra_: I mean, Odd_Bloke's request is to use passwd-the-data-structure, not explicitly /etc/passwd, as i read it [12:30] ogra_: ie getpwent or whatever it is called [12:30] brendand: ups, sorry http://people.canonical.com/~mvo/all-snaps/16/all-snaps-pi2.img.xz [12:31] ogra_: snap install xbill-xaw :-p [12:31] no highscores as yet, didn't feel like patching it [12:31] xbill !!! [12:34] jdstrand: any updates on shipping i386 binaries in amd64 snaps? [12:34] I've got a rather old binary I'd like to snap :-D [12:48] 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] drop files in there and @{HOME} can expand to other things [12:53] Bug #1602845 opened: unity7 interface does not work with libnotify [12:56] Bug #1596717 opened: please add getsockopt to pulseaudio interface [12:57] Bug #1605768 opened: incomplete 'opengl' interface [12:57] Chipaca: as for i386 binaries on amd64, that is a seccomp limitation. I'm trying to find the bug [12:57] jdstrand: :-( [12:58] bug #1592022 [12:58] Bug #1592022: 32 bit applications on 64 bit system fail due to seccomp === chihchun_afk is now known as chihchun [13:12] Bug #1609792 opened: Interface to access .git directories [13:19] what's an easy way to make an arm build of a snap? [13:20] 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] do i need to perform the build on the desired arch, or is there another way? [13:20] brendand, right, you need to do it natively [13:20] iirc kernel snaps are an exception (since they dont really use dependencies) [13:23] ogra_: I generally ask for architectures to be added to (livefses|PPAs) in #webops in Canonical IRC; I expect it's similar. [13:31] brendand: for rpi I use Ubuntu Mate and build there. So you could do the similar thing I guess [13:33] sborovkov, well, there should be new snappy images before EOW [13:34] so you can just use the classic shell on it and install snapcraft [13:34] oh right, that works as well [13:34] 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] PR snapd#1630 closed: daemon: stop using group membership as succedaneous of running things with sudo [14:05] I'm snapping something which has some npm dependencies, but then needs to run a "compilation" command using the installed dependencies. [14:05] 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] mvo, hmmm [14:08] ubuntu@localhost:~$ sudo classic.shell [14:08] Failed to start transient scope unit: Unit classic.scope already exists. [14:08] 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] ogra_: yes, a simple matter of programming [14:09] k [14:15] Odd_Bloke: what's the compilation command? [14:15] "browserify -t coffeeify -d js/git-deps-graph.coffee -o js/bundle.js" === matiasb1 is now known as matiasb [14:16] (Which I'll then need to put in the right place for it to be found by a Flask web server :) [14:25] 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] sergiusens: what do you think of javacrufts suggestion to create a common python base class for python2 and python3? [14:32] sergiusens: should only take me a day or so to implement and would get rid of alot of dup === dholbach_ is now known as dholbach [14:42] Anyone ( dholbach / didrocks ?) had "Error: unsupported locale setting" when launching a snapped app at all? [14:43] I tried snapping calibre (the ebook manager) and it barfs on launch:- http://paste.ubuntu.com/22183092/ [14:43] hum, no I haven't seen that one yet [14:43] ok [14:47] 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] SamYaple btw, I went a ahead and fixed this https://github.com/snapcore/snapcraft/pull/707 [14:48] PR snapcraft#707: Use the proper requirements.txt path [14:48] not sure you mind if I go ahead and get it in [14:49] sergiusens: do your thing. i dont mind rebasing [14:49] ill look into the qmake one to see the deal [14:51] popey: not that one by itself [14:51] 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] some different variant, but I can it's about missing locales in general [14:51] 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] popey, see nethack.sh and snapcraft.yaml https://github.com/ogra1/nethack [14:52] hm [14:52] okay, thanks [14:52] line 7-21 in netchack.sh specifrically [14:53] thank you [14:53] 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] SamYaple that might be asking for too much, but it would make for smaller default python snaps [14:54] 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] sergiusens: i am still hitting C901 in that PR though. [14:54] SamYaple \o/ [14:54] cant reproduce that locally [14:55] SamYaple hmm, might be the version of flake8/mccabe being used [14:55] we've seen these before [14:55] can you give an app access to fchown on files it created itself? [14:56] cmagina anything can be done really, the thing is, why would you need that? [14:56] sqlite? [14:56] sergiusens: ah. youre using the deb and im pip installing. let me test that [14:56] SamYaple if you are on latest and greatest I think we pip install everything now [14:57] 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] sergiusens: fish [14:57] figured it was simple, see what limitations it hits, i figured it would hit some :) [14:57] cmagina can't that logic be removed then? [14:57] sergiusens: https://travis-ci.org/snapcore/snapcraft/jobs/149773303 <--- it seems no. python3-flake8 [14:57] in the end, something will need to change for tihis to work [14:58] SamYaple ah, interesting; elopio any reason for using python3-flake8 instead of a requirements-test.txt one? [14:58] and i am confirming that is the delta [14:58] latest flake8 doesnt have the c901 issue [14:58] sergiusens: yeah, that wouldn't fly with upstream. why can't snap allow a program to change permissions on its own files? [14:59] cmagina I would ask jdstrand who is in the security team [14:59] sergiusens: ok, thanks [14:59] 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] 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] cmagina, to what would you change these permissions, given you cant create a user or anything [15:00] sergiusens: thanks for the help. ill get the PR into shape and work on the refactor of python [15:01] 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] 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] SamYaple thank you! [15:24] cmagina: we'll fix that when the snap-confine is available in 16.04 [15:24] jdstrand: awesome, thanks [15:24] cmagina: it has a required feature called seccomp arg filtering that we can use to open up things like chown [15:25] jdstrand: alright, good to hear [15:33] 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] jdstrand: yeah, i used devmode already, but i will look into adding the syscalls, thanks for that pointer [15:46] Bug #1609864 opened: Enable a command to be run on machine shutdown === chihchun is now known as chihchun_afk [15:54] sergiusens: I don't know. I think we only use it in travis, so the one from pip should work. [15:55] it is in the dep8 integration tests as a dependency, but I think that's wrong. We should remove it. [15:55] SamYaple: can you please file a bug? Bonus points for fixing it too :) [15:56] sergiusens: https://github.com/snapcore/snapcraft/pull/687 Ready. [15:56] PR snapcraft#687: Enable integration tests to run in the production store [15:56] elopio: are you saying we _want_ to be using flake8 from pip rather than package install? [15:57] once i knew what version to install the test passed locally. honestly this might be a bug in flake8 [15:57] zyga: I'm in another call still, do you want to reschedule ours? [15:59] SamYaple: I think that for people hacking snapcraft it would be nicer to set up the environment in a virtualenv. [15:59] 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] what do you think? [16:04] 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] PR snapd#1633 opened: many: move to purely hash based key lookup and to new key/signature format (v1) [16:09] trijntje: you can run the click reviewers tool. [16:09] https://launchpad.net/click-reviewers-tools [16:12] elopio: http://pastebin.com/nB2K7VqR [16:13] trijntje: you need at least one app in there, or user architectures: [all] [16:13] the policy vendor thing, I don't know. Haven't seen that before. [16:16] elopio: can you elaborate on the user architectures bit? I haven't seen that anywhere [16:17] jdstrand, zyga how is that snap-confine SRU going? [16:19] Ah nevermind, I see another discussion about it [16:21] trijntje: https://github.com/snapcore/snapcraft/blob/master/integration_tests/snaps/basic/snapcraft.yaml#L5 [16:25] Bug #1609883 opened: Add an interface to allow access to /var/lock and/or /run/lock/ [16:27] elopio: thanks, I couldn't find that metadata field in the docs for some reason === chihchun_afk is now known as chihchun [16:30] 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] target="snap.gce-compute-image-packages.google-clock-skew-daemon//null-/sbin/hwclock" [16:35] elopio: i agree. the reason im in this situation is because im using a virtualenv [16:35] elopio: ill file the bug, though im not familiar with the testing suite for snapcraft, ill look at it [16:43] 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] Odd_Bloke: a model assertion declares a list of required snaps [16:44] 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] 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] oh shoot [16:46] you're talking about pre-installing snaps for an image that is not an all-snap image [16:46] slangasek: So this specific question fell out of classic images. [16:46] * slangasek think think [16:46] Yeah. [16:46] * gaughen nods [16:46] ok [16:46] we're going to have a 'snap fetch', I think? [16:46] Yeah, I've heard about that in the context of caching a snap for later installation. [16:47] 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] PR snapcraft#711 opened: Add make-install-var field to the make plugin [16:47] 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] Bug #1609792 changed: Interface to access .git directories [16:53] PR snapcraft#687 closed: Enable integration tests to run in the production store === chihchun is now known as chihchun_afk [17:01] slangasek: Shall I file a bug so we have somewhere more persistent than IRC to track this? [17:13] Odd_Bloke: seems advisable [17:19] slangasek: niemeyer: I've filed that as https://bugs.launchpad.net/snappy/+bug/1609903 [17:19] Bug #1609903: Enable the installation of snaps in a classic chroot [17:20]