[00:19] PR snapd#1975 closed: tests: add test benchmark script === ben_r_ is now known as ben_r [01:25] PR snapd#1578 closed: image: add meta/gadget.yaml infrastructure [01:38] PR snapd#1953 closed: snap, daemon, store: pass through screenshots from store [02:02] PR snapd#2000 closed: snap, daemon, store: pass through screenshots from store [03:56] PR snapcraft#832 opened: WIP LP: #1627880 [04:18] Bug #1597784 changed: "PermissionError: [Errno 13] Permission denied" executing a snap === chihchun_afk is now known as chihchun === hikiko_ is now known as hikiko === chihchun_afk is now known as chihchun === chihchun_afk is now known as chihchun [05:59] Mirv: ping [06:06] lpotter: pong [06:07] lpotter: I commented on your MP already and merged it, thanks a lot! really happy about getting the locally built qmake into use. [06:07] I can help with qt-ubuntu snap. I have it building with the local qmake, but it's installing to wonky director [06:07] directory [06:08] the build plugin dont recognize $SNAP. [06:08] lpotter: in what sense? the current snap in the store installs to usr/lib/arch/ (libs) and usr/lib/arch/qt5 (plugins, qml) [06:09] ah, "NAP" :) [06:09] :) [06:09] I wonder if it's needed at all in the config or not [06:10] it is, as without prefix it tries to use / which is not writable to the snap [06:11] and I ran into an issue with libpng-dev for some reason [06:12] and that libicu will cause issues too [06:14] lpotter: I was building on yakkety. As commented on github, it's libpn12-dev on xenial. Fixed it now. [06:16] ok, cool [06:16] ogra_, hi, is the pi2-kernel snap available now? ubuntu-image complains as it cannot download it, and I do not see it with "snap find" [06:26] good morning [07:11] has anyone of you dealt with node issues like the following already? what's a good way of going about them? "npm ERR! version not found: cheerio@0.20.0" [07:31] PR snapd#2001 opened: overlord/boot: switch to using assertstate.Batch === dpm is now known as dpm-afk [08:09] pitti: is it possible to delete the successful test of ppc64el for snapd? I think this successful test was a mistake, i.e. it happend when there was actually no test executed due to a mistake [08:25] zyga: ping: https://github.com/zyga/snapcore-fedora/pull/6 [08:25] PR zyga/snapcore-fedora#6: Flesh out snapd-glib spec [08:26] mvo, why is snapd-xdg-open not under the io.snapcraft.* namespace? [08:26] on the bus [08:26] everything else has moved onto that namespace, so it's weird that this one still retains com.canonical.* [08:28] mvo: how do you mean? There isn't just one pass in http://autopkgtest.ubuntu.com/packages/snapd/yakkety/ppc64el but many, and 2.13+16.10 actually did run tests [08:29] Son_Goku: uh, thank you, that looks like an oversight [08:29] believe it or not, I actually check these things before letting zyga push them into Fedora ;) [08:30] Son_Goku: heh :) [08:30] pitti: sorry, I was wrong, tests did run but they were not really useful "OK: 1 passed, 2 skipped" [08:31] pitti: now we have ~80 tests that are run, 4 fail on ppc64el, I work on skipping or making them pass (our test snaps we uploaded seem to be not fully working on ppc64el) [08:32] Son_Goku: and sorry that I have not got back to your mail :/ life is a bit busy right now due to some looming deadlines [08:32] :( [08:33] well, I was hoping that something could be done before the October sprint, so that I would have something cool to show off, but no worries if not [08:33] Son_Goku: thats going to be tricky but maybe we can get some quality hack time during the sprint [08:33] I hope so [08:34] I've already got that selinux policy module that I need to test to see if it resolves https://github.com/zyga/snapcore-fedora/issues/1 [08:35] mvo: so I can mark the currnet version on ppc64el as "ignore failure" [08:36] pitti: please do, I will work on making them work again but until then it owuld be great to ignore-failure them so that they do not block the other arches [08:36] mvo: that won't help much though, as it also regresses on both x86 [08:38] pitti: that will be fixed soon, its actually a regression from snpa-confine [08:39] pitti: triggered by snap-confine which is used in the tests, but zyga fixed that so the next upload should fix it [08:39] mvo: ah, good, then we can just retry those; I'll add the ppc hint then [08:41] PR snapd#2001 closed: overlord/boot: switch to using assertstate.Batch [08:41] pitti: thank you [08:51] zyga: any chance to get the snap-confine SRU in xenial verified? [08:51] (sitting there for 20 days) [08:51] zyga: the next version has already been sitting in unapproved for a week, but is blocked by ^ [09:02] abeato, did you pick the right channel ? (we didnt rellease to stable yet) [09:03] ogra_, yes, I found out that was the issue in the end, thanks [09:49] PR snapd#2002 opened: tests: use new spread `debug` feature [09:49] pitti: I'll check what's going on there, thanks for telling me about it [09:51] Hmm stumbled upon this in another context. Could/ do snaps take advantage of ksm (kernel page sharing) to address memory waste? https://www.kernel.org/doc/Documentation/vm/ksm.txt [09:51] kalikiana, yes [09:51] (has been discussed multiple times ... i'm not sure about the verdict though) [09:52] ogra_: Ah, cool. Would there be any documentation of what features are currently being used? I wouldn't want to stir up the discussion for the nth time if it's already sorted. [09:52] you have to ask the core team ... mvo or niemeyer would know more [09:53] ogra_: yes? [09:53] zyga, ? [09:53] kalikiana: reading the document I see that this requires MADV_MERGEABLE [09:53] kalikiana: so only applications explicitly doing that would benefit [09:54] zyga, isnt that a wrapper thing ? i.e. ubuntu-core-launcher [09:54] kalikiana: so snaps could take advantage of this [09:54] ogra_: no [09:54] PR snapd#1921 closed: tests: replace systemd-run with on-the-fly generation of units [09:54] ogra_: and besides, we cannot do that for the application [09:55] kalikiana: so I think a more balanced answer is that snapd doesn't prevent apps from using ksm [09:55] kalikiana: so if they are written to take advantage of it, they can [09:55] our kernels have definitely switched it on ... [09:56] (at least the official ones) [09:56] ogra_: right but applications need to use it, otherwise it does nothing [09:56] zyga, well, then i dont understand how al the cloud services can make use of it on behzalf of the apps that run in their containers/VMs [09:57] afaik they a use that on a VM level [09:57] ogra_: with madvise(and MADV_MERGABLE) [09:57] zyga: Supposedly qemu can share memory of multiple instances - I wonder how they do it in that general way [09:57] kalikiana: ^^ [09:57] dunno, i dont thionk all debs that are used in ubuntu clouds are patched on the fly :) [09:58] application developers need to explicitly mark private memory pages as mergable [09:58] probably only virtualization tools use this feature [09:58] afaik the sharing theer works on application level and people are surely not using modified debs [09:58] PR snapd#1994 closed: snap: add `snap known --remote` [09:59] so the VM must do something here that snapd/ubuntu-core-launcher should be able to do as well [09:59] no [10:00] ogra_: snap-confine lives for a millisecond [10:00] ogra_: and execs an application [10:00] ogra_: the appication must understand what is going on and actually sensibly use madvise [10:00] ogra_: it cannot be blindly enabled [10:01] ogra_: VMs enable that so that that they can share memory across memory-heavy virtualization but we don't pay that price and we cannot enable it in any way [10:01] ogra_: but if there's a snap with VM inside then that snap can use this feature internally [10:01] ogra_: so snapd is not related to ksm in any way, this is application responsibility to use [10:04] PR snapd#2003 opened: debian: adjust packaging setup for trusty/deputy systemd [10:17] PR snapd#2004 opened: cmd/snap: make the buy tests run again and fix the failures === hikiko is now known as hikiko|ln === marcoceppi_ is now known as marcoceppi [11:29] PR snapd#2005 opened: many: introduce a device-init hook, let it optionally configure device registration and the serial-request [11:30] PR snapd#1865 closed: overlord/devicestate: POC to parametrise serial-request content/sending === hikiko|ln is now known as hikiko === mp is now known as Guest73139 [12:15] ogra_: at which time is a new OS snap for edge build daily? [12:16] ogra@lillypilly:~$ crontab -l [12:16] 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1 [12:16] 0,30 * * * * /home/ogra/public_html/ubuntu-core-builds/generate-core.sh >>/home/ogra/public_html/ubuntu-core-builds/generate.log 2>&1 [12:16] ogra@lillypilly:~$ [12:16] 4:30 UTC [12:17] thanks [12:17] ogra_: is this generate-core script available somewhere? [12:17] morphis_, note though that the store is buggy ... sometimes i get 404s for existing snaps ... which results in them not to have a channel and not being published [12:18] ok [12:18] sure, on people.canonical.com ;) [12:18] (the path is right in there ) [12:18] thats always the latest version ... its a bit out of sync, but it is also in lp:snappy-dev/ubuntu-core [12:24] ogra_: ok [12:26] https://code.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk .... in the cron-scripts dir [12:34] morphis_, i brought the branch in sync now [12:36] there is also a README in the cron-scripts dir, describing what you need to prepare when using it yourself [12:48] pstolowski, hi, was wondering how the kmod interface works. If I add a module to an interface, which permissions do I get? can I do modprobe on it? === ycheng_ is now known as ycheng [12:52] abeato: no, you get that module loaded but you cannot load it yourself [12:52] abeato: kmod is not an interface it is a "security backend" [12:52] abeato: interfaces can choose to use it [12:53] zyga, so the module would get loaded when you connect to a plug that requires that, correct? [12:53] PR snapd#2006 opened: debian: merge 2.15.2ubuntu1 release [12:53] abeato: it depends on the design of the interface [12:54] abeato: is there a particular use case you have in mind? [12:54] zyga: good morning/afternoon zyga :) [12:54] and hello abeato :) [12:54] jdstrand: hello [12:54] jdstrand, loading ppp modules [12:54] jdstrand, morning :) [12:55] jdstrand: I'm working on SRU verification, eh, I "love" our fragmented releases [12:55] abeato: yep, that was the other one that I thought people would add things to immediately === dpm-afk is now known as dpm [12:55] zyga, snappy will fix that :P [12:55] zyga: heh. you can spin that another way-- it is motivating to get things right before release :P [12:55] PR snapd#1979 closed: assertions: add system-user assertion [12:56] jdstrand, zyga just want to load ppp_generic when somebody connects to the ppp interface [12:56] jdstrand: the problem is the release is right but now I'm in some weird partial state that is never tested [12:56] abeato, yeah, as zyga says [12:56] ogra_: it was supposed to ;) [12:56] :) [12:56] ogra_: but not for snappy :-( [12:57] abeato: that's a two-liner then [12:57] yeah, there was some irony in my sentence ;) [12:57] abeato: or maybe even one liner, depending on syntax [12:57] pstolowski, zyga so this should be just fine, isn't it?: http://paste.ubuntu.com/23242066/ [12:57] abeato: yeah, take a look at firewall-control. ppp will be the same. you won't need anything special [12:57] ogra_: yeah, I know :/ [12:57] abeato: specify the modules you want and snapd will handle the rest on interface connect [12:58] alright, thanks [12:58] yep [13:00] zyga: oh hrmm-- I was hoping the snapd autopkgtest fixes were going to be in place before snap-confine (which is why I suggested that whoever uploads snapd should upload snap-confine) [13:00] oh well, there is a bug in the devel release that will get fixed [13:01] that's happened on occasion :) [13:11] after $ sudo snap try prime and prime is removed/changed, I get into a state where I can't remove the snap because: /snap/ubuntu-system-settings/x1: not mounted [13:12] it make sense, but it's not known to me how to get out of that situation [13:14] any ideas? === Guest54996 is now known as pmp === pmp is now known as Guest60909 [13:19] jdstrand: I'd love to know about that docker workaround [13:19] jdstrand: I see what it does but OMG what is this doing to make the problem go away [13:20] zyga: it is arguably a bug in docker. it is looking in mountinfo to find where the cgroup directory is. it finds /tmp/snap.rootfs_... and thinks it is there [13:20] zyga: so we let it keep thinking that [13:21] zyga: I noticed in looking at mountinfo from inside a snap that we are leaking those mount locations and also all the mounted snaps [13:22] zyga: ideally we would have a clean mountinfo and we could remove the workaround [13:24] zyga: docker could also update their FindCgroupMountpoint() in runc/libcontainer/cgroups/utils.go, but went with a non-patch approach for now until we decide if there is something we can do (even if it is terribly) [13:24] terribly ugly [13:27] nick pmp [13:27] <-- sry, what an idiot [13:34] PR snapd#2007 opened: interfaces: ppp: load needed kernel module [13:36] jdstrand: interesting, that explains a lot [13:36] jdstrand: I don't think that obtaining clean mountinfo is possible though [13:36] jdstrand: unless I'm missing something it will always contain the real data, even if we managed to unmount everything in clasic (which we cannot) [13:37] zyga the important question is, are you going to target the correct mailing list for the announcement this time ;-) [13:37] sergiusens: for what? :) [13:38] jdstrand: as for SRU we have a more nested problem to solve, I need to talk to pitti about it [13:38] pitti: can you perhaps help me with a little SRU problem [13:39] zyga snapd, snap-confine, ubuntu-core [13:39] zyga I feel like I am the only one using snapcraft-announce! [13:39] pitti: there's snap-confine 1.0.38-0ubuntu0-something as a pending SRU, I'd like to kill that one and instead upload the one that is currently in the queue here: [13:39] sergiusens: I agree and I really should use it [13:39] pitti: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= [13:40] pitti: or perhaps even .42 from yakkety if mvo manages to release snapd today [13:41] pitti: I starte verifying the .38 version but I realized it errnously links to bug https://bugs.launchpad.net/snap-confine/+bug/1597842 [13:41] Bug #1597842: Allow access to the currently running kernel sources from /usr/src

[13:43] pitti: from my POV the version under SRU currently is okay except that it doesn't fix this particular bug; we can probably either mark it as failed, remove the bug and mark it as passing elsewhere or just skip it entirely and go to .41 or .42 [13:43] pitti: I want to avoid extra delays so I'd appreciate any insight you may give me [13:43] PR snapd#2006 closed: debian: merge 2.15.2ubuntu1 release === mzanetti_ is now known as mzanetti [13:49] PR snapd#2008 opened: overlord/state: prune old empty changes [13:50] jdstrand: do you have a suggestion on how snap-confine could do something differently to make docker work? [13:57] hmm [13:58] zyga: no problem, I can cancel that SRU if you want, i. e. we remove it from -proposed; does the next upload address the same bugs also? [13:58] pitti: yes, it's a superset [13:58] zyga: if it doesn't fix everything, that's not a problem -- there will always be the next SRU [13:58] pitti: (full upstream releae rather than a cherry-picked one) [13:59] zyga: we just must pull an SRU if it regresses something that worked before [13:59] pitti: hmm [13:59] pitti: that's not the case here [13:59] pitti: the fix in .38-0ubuntusomething is just partial [13:59] pitti: there are no regressions, I just want to find a smooth way to eventually update everyone to .42 [13:59] zyga: hm, http://launchpadlibrarian.net/285662383/snap-confine_1.0.38-0ubuntu0.16.04.10_1.0.41-0ubuntu2~16.04.1.diff.gz removes a metric ton of previous changelogs -- is that a rebase error? [14:00] ah, it's more like a backport [14:00] zyga: well, as you wish -- verify 38 and we release it, or skip it and I review/acept .41 "over" it [14:00] pitti: yes, I think that's more accurate [14:01] pitti: ok, I cna finish the verification, what should I do about bug https://bugs.launchpad.net/snap-confine/+bug/1597842 then? just mark it as verification-done? [14:01] Bug #1597842: Allow access to the currently running kernel sources from /usr/src

[14:02] zyga: I'd just reopen it and clear the tag after releasing the update (that auto-closes the bug) [14:02] ok [14:02] so I'll reopen and re-verify this with .41 that really fixes it [14:04] zyga: ok; otherwise current SRU is good? [14:04] pitti: let me verify the last two items [14:04] pitti: thanks a lot for https://launchpad.net/ubuntu/+source/nplan/0.12~16.04 ! [14:05] zyga: rihgt, please officially say "works" on some of the bugs [14:05] jdstrand: curious, how did you debug the docker issue, I think that is pretty esoteric :) [14:05] pitti: will do [14:05] morphis_: yw! it needs to grind through the machinery now, and we can hopefully release it in a week === tachyons is now known as tachyons_ === tachyons_ is now known as tachyons [14:17] zyga: since we are in our own mount namespace, I would think we could unmount other snaps to close down the info leak (so long as the unmount didn't propogate. I'm not sure how that would work for /tmp/snap.rootfs_* [14:18] zyga: I found it by noticing that the docker log entry was complaining about that file not existing. I was assuming it was confused about the mount namespace and that /sys was mounted wrong, but thought I'd check out the low hanging fruit and just take docker at its word about the file it was trying to access not existing [14:19] zyga: and that turned out to be the problem [14:21] jdstrand: well, we might (extra complexity for content sharing) but why why would that matter? we'd still see the load of tmpfs entries [14:22] zyga: I don't think that would complicate content sharing-- we are still mounting the target in SNAP_DATA [14:23] Hello. Just updated my classic image. Now getting this: Sep 27 14:21:34 ubuntu snap[6727]: this GOARM=6 binary. Recompile using GOARM=5. [14:23] This snap ran before just fine [14:23] Any idea what's going on [14:23] zyga: that wouldn't matter for the docker case, you are right. that would only prevent an info leak (leaking all installed snaps) via mountinfo. as it happens there are other leaks there due to accesses in /proc, but we have work items to address that in the medium term [14:23] jdstrand: I can experiment quickly but I doubt that would change anything for docker [14:23] jdstrand: mountinfo requires devmode, it's not readable [14:24] zyga: or mount-observe [14:24] zyga: I'm not saying it is a world burning problem [14:24] jdstrand: hmm, interesting, yes [14:25] just that it is a leak [14:25] unfortunately due to noisy denials due to various libraries, I suspect people will specify mount-observe a lo [14:26] t [14:26] but, like I said, we leak things via /proc. this shouldn't distract for /media or network-namespace or really whatever else is on your plate atm. just wanted to mention it [14:27] as for /tmp/snap.rootfs_*, that would be worth looking into I think (at least after a few high prioirty items are off your list), but I'm not sure what to do there [14:28] zyga: ^ [14:30] sergiusens: https://github.com/snapcore/snapcraft/pull/813 is ready for a review when you have a spare moment [14:30] PR snapcraft#813: "snapcraft validate" and "snapcraft gated" commands [14:30] jdstrand: well, yeah, I think this is a tough problem, mouninfo will always tell the truth [14:31] ralsina will do, thanks for working on this! [14:32] zyga: the good news is there shouldn't be a lot of software that is parsing mountinfo for the reasons that docker is, and we have a workaround for docker (and again, it is arguably a bug in docker) [14:32] sergiusens: np, ping me for anything you see there.. 1st snapcraft branch so there will surely be something horrible :-) [14:33] ralsina nah, all good, I am holding off moving away from docopt until this lands so you don't take a hit [14:33] wee, kill docopt :-) [14:34] mectors: hey, did you get my email regarding bug #1627309 ? [14:34] Bug #1627309: bluetooth-control noble.js not working [14:42] Hello. After updating classic image I am now getting this for all of my snaps which were working before... Any ideas? : Sep 27 14:21:34 ubuntu snap[6727]: this GOARM=6 binary. Recompile using GOARM=5. [14:48] sborovkov, was that something cross compiled ? [14:49] * ogra_ wonders why anything would use 5 or 6 on ubuntu ... given we only support ARMv7 [14:50] PR snapd#2009 opened: tests: add firewall-control interface test [14:50] ogra_: no [14:51] so it only howed up ater a snapd upgrade ? [14:51] ogra_: I compiled that snap on rpi3 on ubuntu mate. everything worked. Got latest updates. So I guess newer snapd. After that everything stopped working with those errors. And something about not supported floating architecture [14:51] *showed up after [14:52] right, looks like napd itself was built for ARMv6 without hardfloat [14:52] *snapd [14:52] mvo, zyga ^^^ [14:52] (i dont see such issue on the allo-snap images though) [14:52] *all- [14:53] I am pretty sure someone else had similar issue some time ago. I remember seeing this here. But don't remember when it happened or why. [14:53] right [14:55] Bug #1627692 opened: Error when model file is not in $HOME [14:56] sborovkov, ogra_: I think this is fixed with a updated snap-confine, the aux vector was not passed along and this confused go programs [14:56] jdstrand: hmm [14:56] er [14:56] hmm [14:56] jdstrand: sorry, I didn't notice your name was in the bugger [14:56] buffer [14:56] mvo, ah, perhaps the snap-confine that is stuck in proposed ? [14:57] snapd should have a versioned dep if thats the case [14:57] ah ok. So I guess I need to use proposed to make sure it works. [14:58] sborovkov: try the ppa perhaps [14:58] sborovkov: or build 1.0.42 from the tarball on github [14:58] sborovkov: packaging is on git.launchpad.net/snap-confine [15:00] ogra_: I think something else broke it, but I don't remember the details [15:00] ogra_: hm, maybe I do [15:00] zyga: what ppa should I use? [15:00] well, if we break everyones RPi classic install regarding snaps after we told everyone to use classic, thats a bad thing [15:01] sborovkov: aww, I never remember, sorry [15:01] sborovkov: can you try the package in yakkety? [15:02] zyga: ok. I will try it today/tomorrow. Will tell you if that does not work. (if either of them does not work). [15:02] sborovkov: thanks [15:09] zyga: no worries [15:11] PR snapd#2010 opened: many: create auth.json for the freshly created user in `snap create-user` [15:15] jdstrand: can I just mark https://bugs.launchpad.net/snap-confine/+bug/1584456 as verification-done based on the presence of the extra apparmor rule? [15:15] Bug #1584456: apparmor denial using ptmx char device

[15:16] * ogra_ puts on an evil grin ... [15:17] zyga: yes. you can also say that 'apparmor_parser -QTK /etc/apparmor.d/usr.lib.snapd.snap-confine' returns with no errors and show that it is present in 'sudo aa-status|grep snap-confine' [15:17] mvo, so where is that script you said you would write if you ever had to touch meta again ? (i see you added xdelta today) [15:17] :) [15:17] zyga: that is sufficient for these policy updates that only allow more access (ie, it can't regress with more access and you demonstrate the policy compiles and is loaded) [15:18] zyga: (sufficient when there isn't a simple test case) [15:19] zyga: it is nice to prove that it fixes it, but when you don't have the ability to do that, proving it doesn't regress is good enough with policy updates like this [15:21] jdstrand: thank you :) [15:22] hmm, why does the PPA actually check package versions against proposed ... it tells me nplan and initramfs-tools have newer versions available ... [15:22] * ogra_ checks the PPA setup ... [15:23] no, definitely pointing to -updates ... as it should ... weird [15:23] cjwatson, is there a bug open for that ? ^^ [15:24] * ogra_ assumes there is ... i cant be the first one noticing that [15:28] ogra_: not sure, probably, various bugs about ancestry not being ideal [15:28] yeah, k [15:28] i wont file one then [15:29] (even though it is a lie, it is a good warning mechanism that i need to take action before it migrates) [15:32] oh man ... that initramfs-tools in -proposed will make the size explode :/ [15:33] ogra_: Yeah, that's why it wouldn't be trivial to change. It would probably need multiple indicators that look slightly different. [15:34] ok, verification done [15:34] pitti: I've verified all the other issues, I will now ask for the SRU in ubuntu-release [15:35] cyphermox, hmm, looking at http://launchpadlibrarian.net/286301974/initramfs-tools_0.122ubuntu8.1_0.122ubuntu8.2.diff.gz ... how do you actually make sure dhclient is in the initrd ? i dont see a hook anywhere that would copy it in [15:36] cydizen, oh, ignore me ... i see it in the isc-dhcp package === daniel1 is now known as Odd_Bloke [15:37] err, sorry cydizen, that was for cyphermox [15:37] isc-dhcp has the hook. [15:37] yeah, just saw it [15:37] it only adds 500k [15:38] thats a lot [15:38] no choice. [15:38] (for an initrd that is only 2.5MB and has no NIC drivers in it at all :) ) [15:38] (like ours) [15:39]