[00:03] is there a getting started guide to snappy on the dragonboard? [00:12] oh, it works! [00:12] slowly [00:12] and i still don't have serial [01:35] PR snapd#1700 closed: add mir to implicit for running gui snaps on unity8 classic desktop [02:02] PR snapd#1948 opened: add run/udev/data paths to mir interface [04:06] blargh [04:07] where is the/a dragonboard model assertion? [04:07] ah http://people.canonical.com/~vorlon/official-models/ [04:07] mwhudson: right, obviously ;) [04:07] slangasek: where else could they possibly be! [04:08] slangasek: actually the hardest part was remembering your unix username [04:08] hahaha [05:26] o/ [06:38] hey hey [06:39] good morning dholbach [06:40] happy snappy playpen day: https://daniel.holba.ch/blog/2016/09/get-your-software-snapped-tomorrow/ :-) [06:43] * zyga works on snap-confine SRU paperwork [06:51] hey dholbach, happy snappy day to you ;-) [06:57] and the same to you seb128! [07:10] nice to see we have a bunch of new bits added to the sandpit: https://github.com/ubuntu/snappy-playpen/wiki/SandPit [07:11] ^ can you add your almost-fully-working snaps to that list too? [07:24] Bug #1624963 changed: pulseaudio interface (still) missing permissions [07:42] seb128, is https://github.com/wandrewkeech/snappy-playpen/blob/gimp-git/gimp-git/README.md easy to fix? do you know? [07:43] diddledan, does corebird work with devmode? [07:45] dholbach, no idea sorry, I didn't try to use gobjectintrospection in snaps [07:45] ok [07:48] ogra_: hey i pushed a new probert / subiquity into the canonical-foundations/ubuntu-image ppa today [07:48] ogra_: copy to snappy-dev/image? [07:48] quite a lot of fixes === chihchun is now known as chihchun_afk [07:51] dholbach: I can't remember. I'll need to check this evening [07:56] cool, thanks diddledan === chihchun_afk is now known as chihchun [08:36] mwhudson: I'm pushing through the 1.0.41 SRU process, that will probably take all my day; As a part of that I will have to upload it to yakkety [08:36] mwhudson: do you think you could do the yakkety upload? [08:37] zyga: you don't want to upload it to debian and wait until we can sync it, i guess? [08:37] mwhudson: no, because we're running out of time [08:37] zyga: ok [08:37] mwhudson: mainly on the SRU overhead [08:38] mwhudson: I pushed packaging to git.launchpad.net/snap-confine [08:38] mwhudson: the master branch there can be merged into the 16.10 branch for yakkety [08:40] zyga: want to put the 1.0.41 release on github? [08:40] mwhudson: it's there already [08:40] oh wait you did [08:40] mwhudson: yep :) [08:40] * mwhudson pokes uscan with a stick [08:40] hehe [08:40] mwhudson: fedora has a live system where it detects the tag and files an update bug [08:40] it's pretty damn impressive [08:41] s/damn/darn/ [08:41] but fedora will be more complex as I need to work on the /snap move there as well and this needs some more handholding [08:41] zyga: oh, there's no snap-confine-1.0.41.tar.gz [08:41] zyga: just the 1.0.41.tgz [08:42] zyga: do you usually do a make dist & upload that or something? [08:42] dholbach: I'm writing a snap that uses autotools and doesn't have an install step, how do I get everything in parts//build into the snap? [08:42] mwhudson: oh? that's odd [08:42] mwhudson: oh right!!! [08:42] mwhudson: let me upload it, I forgot :/ [08:42] davidcalle, custom plugin and copy over? :-( [08:42] mhall119: ping [08:43] dch, mhall119 lives in the US to it might take a while until he responds [08:43] aha [08:43] anything anyone else could help with? [08:44] dholbach: hmmm, I already did one to get rid of the Install step of the default autotools... Yeah, I guess that's the way to go [08:44] dholbach: thanks. I'm one of the committers for apache couchdb & am working on the debian packages as well atm. so I'm quite interested to pair up wrt snaps. I'm pretty sure I can save him quite a bit of time with questions [08:44] mwhudson: done [08:44] mhall119: ^ I'm in EU time zone but will be online tonight ~ 20h00 UTC if we can cross paths. I'm usually in #couchdb-dev of course [08:45] dholbach: one of the questions I did have was is it possible to allow a snap to access data dirs from the previous debian-style package [08:45] hello, i would like to install Niagara Supervisor on Ubuntu Core. Supervisor need librariers with dependencies, how i can do use APT manager or can i use another manager? [08:46] dch, nice! did anyone of the two of you start the snap journey for couchdb yet? [08:46] specifically /var/lib/couchdb/ and /var/log/couchdb and /etc/couchdb/ [08:46] dholbach: apparently he is already underway [08:46] zyga: so there's no non-trivial packaging changes this time? [08:46] I have a customer who does medical appliances, so snaps are a little *too* new for them -- updates are very very hard to do, the whole thing needs re-certification. But I hope we can get the community underway very soon. [08:47] dch, yes, that sounds like a good plan :) [08:47] dch, http://snapcraft.io/docs/reference/env explains the world view of a snap quite well [08:47] mwhudson: no, it should be a relatively smooth ride [08:48] mwhudson: there's a new executable [08:48] mwhudson: but nothing else [08:48] mwhudson: oh wait [08:48] mwhudson: maybe there is [08:48] mwhudson: I believe we need to bump our dependency on apparmor [08:48] zyga: that doesn't seem to be in your packaging? [08:48] zyga: debian/patches/0001-Don-t-shellcheck-files-spread-prepare-script.patch can be dropped i take it [08:48] mwhudson: the packag contains it automatically, no change was required [08:48] oh ok [08:49] mwhudson: (spread tests ran against this packaging all the time so if it wasn't packaged it would not be possible to test it) [08:49] dholbach: the main issue is /var/lib/couchdb as people have 100gb upwards in these and "just" copying them around is dangerous & slow. from what I've read so far, I've not seen anything about making that possible to access. [08:49] zyga: heh [08:49] mwhudson: since I change spread to use packaging and real dist tarballs releases should be relatively painless [08:49] mwhudson: let me grep for the right apparmor version to depend on [08:49] zyga: and 0001-Stop-using-deprecated-readdir_r.patch too? [08:50] mwhudson: all patches are dropped [08:51] cool [08:52] mwhudson: 17:44 < tyhicks> zyga: you should depend on 2.10.95-0ubuntu2.2 or newer [08:52] mwhudson: please merge that change into master if you can [08:52] mwhudson: do you have commit access to git.launchpad.net/snap-confine? [08:52] zyga: i doubt it [08:52] * zyga looks [08:53] zyga: 'master' ? [08:53] in my tree master is upstream master [08:53] there is a debian branch, and i guess i'm about to create one called ubuntu, or ubuntu-yakkety or something like that :) [08:53] mwhudson: you need to request access https://launchpad.net/~snappy-dev [08:53] mwhudson: [08:54] zyga: restricted team, i can only be added [08:54] mvo: ^ can you please add mwhudson there [08:54] dch, I'm not quite sure - I'll ping the snapd guys to get an answer on this one. :) [08:54] mwhudson: so that repo is a bit weird; it contains just the debian directory and has branches for each distro version [08:54] * mwhudson updates his schroots [08:55] mwhudson: I found this easier to work with than a few separate repos for the "traditional" approach [08:55] ah ok [08:55] mwhudson: I'm happy to change it as long as we can also use it in spread [08:56] mwhudson: note that spread just branches the appropriate branch and builds the package against the debian directory there and the tarball [08:56] mwhudson: if we had the full git tree it would probably work as well but might be less obvious that only the debian directory is relevant [08:56] mwhudson: and no dedicated tooling seems to work with this approach [08:57] zyga: uupdate? [08:57] mwhudson: (because it is uncommont to maintain many distro revisions in the debian world; I suspect) [08:57] uupdate? [08:58] you could use that with the debian branch from alioth i think [08:58] bah i have too many chroots [08:58] mwhudson: I want to include debian in this repo [08:58] mwhudson: and merge those [08:58] mwhudson: (those repositories) [08:59] yes, makes sense [08:59] mwhudson: ideally there'd be one repo with a branch per release and master where all new things get added [08:59] mwhudson: we can keep it on alioth, that's perfectly fine, I just need to finally do that paperwork for it [08:59] zyga: branch per distro, surely? [08:59] mwhudson: yes [08:59] good :) [08:59] mwhudson: branch per distro*release [08:59] well distroseries, in launchpad terminology [08:59] yeah [09:00] mwhudson: nice :) [09:00] zyga: what i do for go (and i don't know if this really makes sense here) is to have the debian bits on alioth but i only push the ubuntu bits to git.lp.net [09:01] (except occasionally when i screw up and have to delete 10s of tags from alioth) [09:01] mwhudson: I guess we might do that, it is per-branch after all [09:01] :D [09:03] zyga: where are the spread bits that make the packages? [09:16] zyga: ok, builds fine in my yakkety and sid chroots, just waiting on that apparmor version :-) [09:20] mwhudson: ^ [09:20] zyga: oops [09:20] mwhudson: I pasted it above [09:20] sorry, on a call [09:21] mwhudson: in snap-confine master, look for spread-prepare.sh [09:23] zyga: i guess i'll depend on >= 2.10.95-0 for the debian upload [09:23] er -1 [09:24] actually no, the ubuntu version should be fine there [09:24] no sense carrying a delta for no reason [09:26] zyga, lost you :) [09:27] zyga: ok, ready to upload, do you want to look at a debdiff or do you trust me? :) [09:32] zyga: http://paste.ubuntu.com/23206344/ [09:42] re [09:42] * zyga looks [09:42] mwhudson: I trust you but I can review it :) [09:42] :) [09:43] ouch :) [09:43] I stopped at ~1000 [09:43] let's get it in [09:43] zyga: heh maybe search for debian :) [09:43] but ok [09:43] PR snapd#1911 closed: snap: add additional checks for snap run symlinks [09:44] PR snapd#1774 closed: tests: add test for current snapd with ubuntu-core/edge interactions [09:47] zyga: uploaded to yakkety & sid [09:50] mwhudson: woot, thank you [09:51] when I install a snap that I packaged and uploaded some time ago on the latest image, I got this error: [09:51] - Fetch and check assertions for snap "shadowsocks" (5) (cannot verify snap "shadowsocks", no matching signatures found) [09:51] what does that mean? [09:55] Try --force-dangerous [09:55] trying now [09:56] kalikiana, doesn't work :( [09:56] ypwong: upload it again to the store [09:57] ypwong: store will sign it now [09:57] zyga, thx, will try that [10:10] PR snapd#1949 opened: ensure http{,s}_proxy is defined inside the fake-store [10:25] zyga: ftbfs https://launchpadlibrarian.net/285513548/buildlog_ubuntu-yakkety-amd64.snap-confine_1.0.41-0ubuntu1_BUILDING.txt.gz [10:25] zyga: possibly old kernel on the builders? [10:32] mwhudson: possibly [10:32] mwhudson: hmm [10:33] mwhudson: but perhaps not [10:33] zyga: only failed on intel fwiw [10:33] mwhudson: intel as in i386? [10:33] zyga: i386 & amd64 [10:33] zyga: https://launchpad.net/ubuntu/+source/snap-confine/1.0.41-0ubuntu1 [10:34] mwhudson: NSFS_MAGIC is taken from an include file, I don't hardcode it [10:34] mwhudson: hmm hmm, thanks, let me see if I can reproduce it [10:34] zyga: kernel version is just my go-to blame target when a build fails on the builders but not my machine [10:34] mwhudson: but it builds for you in sbuild, right? [10:34] yes [10:34] just building again to be sure... [10:35] mwhudson: right, so I'm not going crazy [10:35] * zyga does the same [10:35] zyga: well, not for this reason anyway [10:35] yeah, built fine here again [10:36] mwhudson: what kind of options do we have? [10:36] zyga: the failing kernels are much older, 3.13 vs at least 4.2 for the others [10:36] mwhudson: disable that test or .. dunno? [10:36] zyga: i guess disabling the test for now if uname -r < whatever [10:36] mwhudson: can you please look at the test and tell me if the code there makes sense to you? [10:37] zyga: i hear people want snappy to work on trusty, so some lucky person gets to figure out if this matters :-) [10:37] mwhudson: that's tvoss but the solution is to use new kernels [10:37] hey ogra_ :) i'm not able to boot the latest dragonboard beta image http://paste.ubuntu.com/23206434/ it hangs in the last line, is this a known issue? [10:37] ah ok [10:37] mwhudson: as for 3.1X for devices, lots of backporting I guess [10:37] mwhudson: so wait, what is the kernel version on the builders? [10:37] we have a ticket open to upgrade builders to xenial, but it will take a while [10:37] zyga: it's on the third line of the build log mwhudson pasted above [10:38] zyga: it's the first or second line in the build log [10:38] mwhudson: Kernel: Linux 3.13.0-96-generic amd64 (x86_64) [10:38] is that i? [10:38] it [10:38] yes [10:38] yeah [10:38] okay, that might explain it [10:38] let me try that kernel locally [10:38] that's trusty kernel with xenial/yakkety chroot? [10:38] yes [10:38] yakkety, in this case [10:38] perfect [10:38] mwhudson: I guess we'll need a patch but let me explore it first [10:39] NSFS_MAGIC changing between kernel versions would be ... something [10:39] mwhudson: can you fild a bug for tracking this with the relevent part of the log [10:40] maybe older kernels just didn't set it at all or something [10:40] zyga: on github or lp? [10:40] mwhudson: on launchpad please [10:44] 40864 seems to be PROC_SUPER_MAGIC [10:44] zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1625565 [10:44] Bug #1625565: 1.0.41-0ubuntu1 ftbfs on amd64, i386 [10:44] mwhudson: thanks [10:45] and NSFS_MAGIC was only added to the kernel in a commit from Sat Nov 1 10:57:28 2014 -0400 [10:45] so that's not going to be in the 14.04 release kernel [10:46] 3.19+ [10:46] mwhudson: so even the kernel headers have that macro, the relevant files in the kernel don't use it? [10:47] zyga: well the kernel headers you are building against are from yakkety presumably [10:47] mwhudson: yes, I just checked that :/ [10:47] mwhudson: the mount namespace file in the kernel is indeed procfs [10:47] mwhudson: I guess this test needs to be skipped [10:47] mwhudson: and we might need a separate check for this in snap-confine proper [10:48] so that if we open and see PROC_SUPER_MAGIC we can die() [10:48] mwhudson: I'll work on a patch, can you still upload it in Â£30 minutes? [10:48] ~ [10:49] zyga: getting pretty late, i'm sure you can find another core dev [10:49] ok [10:49] thanks, I'll talk to you tomoror :) [10:49] tomorrow :) [10:49] zyga: ttyl! [10:49] o/ [11:02] mvo, how hard would it be to make snap prepare-image alo print the revision number when printing the "Fetching $package" ? [11:02] *also [11:03] (that would really help regarding getting the manifest) [11:06] possible to use a ppa in addition to whatever snapcraft uses to install debs? [11:06] yes, just have it in your hosts sources.list [11:07] ogra_, okay, that's great [11:08] (not sure how you do it with cleanbuild though, i guess you need a pre-made lxc image for that) [11:08] ogra_, what uses cleanbuild? [11:08] ogra_: I like the idea [11:08] you ? [11:08] mvo, i'll file a bug [11:09] ogra_, I use $ snapcraft [11:09] jgdx, to build a snap you can call "snapcraft cleanbuild" ... while a normal call of snapcraft will just use the host, cleanbuild does the build inside a clean lxc container [11:11] good to know, thanks [11:14] ppisati, hmm, more OOPS fun on bbb ... http://paste.ubuntu.com/23206676/ === hikiko is now known as hikiko|ln [11:14] it seems to hang in resizing the disk and eventually oopses after a few min [11:20] To install a snap locally, do I always need to provide --force-dangerous argument? [11:20] mwhudson: if around by any chance: https://github.com/snapcore/snap-confine/pull/150/files [11:20] PR snap-confine#150: Skip tests that require Linux kernel 3.19+ [11:20] * zyga needs a reviewer for a simple patch ^^ [11:21] ypwong, the option will soon change to just be --dangerous ... and --devmode selets it automatically ... if you install a local snap you always need it (but dont need to specify it when using --devmode) [11:23] ogra_, [11:23] ogra_, will plugs be automatically connected? [11:23] seems when i use --force-dangerous, it doesn't [11:23] the auto-connect ones will, sure ... [11:23] hmm [11:23] strange, let me dig deeper then [11:24] I use network and network-bind, these should be auto-connect [11:24] yes === Michaela is now known as Mikaela [11:25] though i'm not sure actually ... zyga should know if --dangerous kills auto-connect [11:25] ogra_: I don't think so but let me grep [11:26] mwhudson, http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has the latest probert/subiquity [11:27] ogra_: no, it has no inpact on this [11:28] thought so ... [11:28] thanks [11:28] ypwong, ^^^^ [11:29] ogra_, zyga: thx, i will investigate what's wrong [11:30] ogra_: i'm looking into the previous one [11:31] ogra_: i stuck some debug code in the sysfs code, but i still can't find where it writes [11:31] ppisati, heh, yeah, i was just hoping that brings perhaps more hints [11:31] ogra_: my bet is that it removes all the network devices [11:31] PR snapcraft#808 closed: Don't litter /tmp with test artifacts [11:31] i've seen quite some fixes about PM code and TI device removal [11:32] so i'll give that a shot too [11:32] but this one is new [11:32] doh! [11:32] :P [11:32] ogra_: btw, is is so difficult to roll a new image for BB? [11:32] you need a signed assertion and the snap that you want to replace locally [11:34] ppisati, see pm [11:36] ogra_: ok, i'll give it shot later on [11:36] * ppisati is accumulating later shots [11:43] jdstrand: hey [11:43] jdstrand: could you please add a comment to https://github.com/snapcore/snap-confine/pull/97 that confirms you are okay with the change that lowers the restriction on encrypted home directory (we drop the owner stanza) [11:43] PR snap-confine#97: Restore creation of $SNAP_USER_DATA [11:43] jdstrand: just some paperwork for SRU [11:43] jdstrand: I recall you +1'd it but I need a paper trail for the whole process [11:44] jdstrand: and I cannot see that +1 on the pull request there [11:47] zyga: I don't recall ever giving a +1 on that. I recall a +1 on the 'new-style encrypted $HOME' [11:47] zyga: why doesn't owner match work? shouldn't we have already dropped privs to the user when creating SNAP_USER_DATA? [11:49] jdstrand: beuse we run as root via sudo [11:49] *because [11:49] jdstrand: this is just for the sudo case [11:49] the bug https://bugs.launchpad.net/snap-confine/+bug/1612291 has a lot more details now [11:49] Bug #1612291: cannot create $SNAP_USER_DATA when using ecryptfs and sudo

[11:50] (this is in xenial for a while FYI) [11:51] OH GEEZ !!!!! [11:51] ogra_: ?!? [11:52] so i wasted a full day trying to fix a prob that wasn't actually one, just because i missed that the store did unset the channel for a manually published snap ! [11:53] (well, it was actually auto-published, but failed the review ... seems the manual review approval auto-unsets the channel that had been originally selected for the package) [11:53] so the uploaded fix never made it into the image ... since it caused snap list to not work i couldnt actually find out that the fixed snap was a revision behind ... [11:54] what a mess [12:00] niemeyer: let me know if I am not using the 'Reviewed' tag correctly. I see you like to mark things 'Reviewed' after you leave feedback. If I respond to your feedback, I remove 'Reviewed'. If the process is different, please let me know [12:00] jdstrand: the reviewed tag is gone now [12:00] jdstrand: with new github features it is not required [12:01] jdstrand: same as blocked [12:01] zyga: well, maybe, but it showed up with a review from last night/this morning [12:02] zyga: no, after futher thinking, we are still using the labels [12:02] zyga: you don't see the other stuff in the PRs list for one [12:02] pedronis: yes? [12:03] pedronis: I think gustavo wrote about this yesterday but perhaps I didn't see a follow-up that undoes it [12:03] zyga: right, so I read that bug but I think this is just papering over the larger issue of sudo creating things in the user's dir rather than /root [12:03] zyga: he wrote something else, we are using the features and we are using the labels [12:03] the discussion about the labels was in chat [12:03] jdstrand: that's interesting, I think we could consider switching to /root when sudo is used but I don't think we made that choice yet [12:04] pedronis: ah, that explains it, I only read my mail about that [12:04] pedronis: thanks! [12:04] zyga: I maintain we should not be doing that. HOME should be set to the root user if run under sudo because we will never get the permissions right in the user's directory cause half the time we will be right and half the time wrong regardless of the decision, but if creating in /root at least it is consistent [12:05] zyga: I was literally just going to ask if an architect took a definitive stance on that [12:05] I thought someone did, and I thought it was for /root, but I may be misremembering [12:06] jdstrand: I think we did that for /root and *services* [12:06] 'it is consistent and we aren't creating permissions problems for the user' [12:06] jdstrand: well, FYI this is in xenial :/ [12:06] jdstrand: I'm just massaging the paperwork now [12:07] jdstrand: I think there's a strong distinction between servies and sudo [12:07] jdstrand: but still, regardless, I wonder how to proceed now [12:07] * zyga is *sure* we talked about this [12:07] * ogra_ grumbles and files bug 1625605 [12:07] Bug #1625605: manual review should not unset the channel for auto-uploaded snap [12:07] perhaps that was tyhicks [12:08] Bug #1625605 opened: manual review should not unset the channel for auto-uploaded snap [12:10] zyga: I gave a +0 that at least gives you a "won't block" from the security team [12:10] zyga: (see comment in the PR) [12:12] jdstrand: thank you [12:12] jdstrand: I'll raise this today with gustavo [12:12] jdstrand: I'm happy to change it if we so desire though I wonder if we should just change sudo [12:12] jdstrand: after all, this is sudo's code that preserves HOME [12:12] there is a bug on that [12:13] jdstrand: and that was a vert conscious choice on our end (our == ubuntu) [12:13] yes [12:13] jdstrand: can you share the bug please? [12:13] s/vert/very/ [12:14] the difference is that in ubuntu running the sudo command, the command most often does not create files in the user's home dir (it is highly application dependent). in snappy, running a snap command 100% of the time creates the directories and files with root ownership [12:14] (when they don't already exist) [12:14] mvo, bug 1625607 for you [12:14] Bug #1625607: snap prepare-image should print the revision used in the "Fetching $package" output === hikiko|ln is now known as hikiko [12:17] jdstrand: that's true though I'd say that "it is application dependent" is very common [12:17] Bug #1625607 opened: snap prepare-image should print the revision used in the "Fetching $package" output [12:17] zyga: https://bugs.launchpad.net/snappy/+bug/1466234/comments/6 [12:17] Bug #1466234: Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root