| mup | PR snapd#1975 closed: tests: add test benchmark script <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1975> | 00:19 |
|---|---|---|
| === ben_r_ is now known as ben_r | ||
| mup | PR snapd#1578 closed: image: add meta/gadget.yaml infrastructure <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1578> | 01:25 |
| mup | PR snapd#1953 closed: snap, daemon, store: pass through screenshots from store <Created by robert-ancell> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1953> | 01:38 |
| mup | PR snapd#2000 closed: snap, daemon, store: pass through screenshots from store <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2000> | 02:02 |
| mup | PR snapcraft#832 opened: WIP LP: #1627880 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/832> | 03:56 |
| mup | Bug #1597784 changed: "PermissionError: [Errno 13] Permission denied" executing a snap <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1597784> | 04:18 |
| === 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 | ||
| lpotter | Mirv: ping | 05:59 |
| Mirv | lpotter: pong | 06:06 |
| Mirv | 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 |
| lpotter | I can help with qt-ubuntu snap. I have it building with the local qmake, but it's installing to wonky director | 06:07 |
| lpotter | directory | 06:07 |
| lpotter | the build plugin dont recognize $SNAP. | 06:08 |
| Mirv | lpotter: in what sense? the current snap in the store installs to usr/lib/arch/ (libs) and usr/lib/arch/qt5 (plugins, qml) | 06:08 |
| Mirv | ah, "NAP" :) | 06:09 |
| lpotter | :) | 06:09 |
| Mirv | I wonder if it's needed at all in the config or not | 06:09 |
| lpotter | it is, as without prefix it tries to use / which is not writable to the snap | 06:10 |
| lpotter | and I ran into an issue with libpng-dev for some reason | 06:11 |
| lpotter | and that libicu will cause issues too | 06:12 |
| Mirv | lpotter: I was building on yakkety. As commented on github, it's libpn12-dev on xenial. Fixed it now. | 06:14 |
| lpotter | ok, cool | 06:16 |
| abeato | 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:16 |
| dholbach | good morning | 06:26 |
| dholbach | 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:11 |
| mup | PR snapd#2001 opened: overlord/boot: switch to using assertstate.Batch <Created by pedronis> <https://github.com/snapcore/snapd/pull/2001> | 07:31 |
| === dpm is now known as dpm-afk | ||
| mvo | 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:09 |
| Son_Goku | zyga: ping: https://github.com/zyga/snapcore-fedora/pull/6 | 08:25 |
| mup | PR zyga/snapcore-fedora#6: Flesh out snapd-glib spec <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/6> | 08:25 |
| Son_Goku | mvo, why is snapd-xdg-open not under the io.snapcraft.* namespace? | 08:26 |
| Son_Goku | on the bus | 08:26 |
| Son_Goku | everything else has moved onto that namespace, so it's weird that this one still retains com.canonical.* | 08:26 |
| pitti | 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:28 |
| mvo | Son_Goku: uh, thank you, that looks like an oversight | 08:29 |
| Son_Goku | believe it or not, I actually check these things before letting zyga push them into Fedora ;) | 08:29 |
| mvo | Son_Goku: heh :) | 08:30 |
| mvo | pitti: sorry, I was wrong, tests did run but they were not really useful "OK: 1 passed, 2 skipped" | 08:30 |
| mvo | 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:31 |
| mvo | 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 |
| Son_Goku | :( | 08:32 |
| Son_Goku | 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 |
| mvo | Son_Goku: thats going to be tricky but maybe we can get some quality hack time during the sprint | 08:33 |
| Son_Goku | I hope so | 08:33 |
| Son_Goku | 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:34 |
| pitti | mvo: so I can mark the currnet version on ppc64el as "ignore failure" | 08:35 |
| mvo | 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 |
| pitti | mvo: that won't help much though, as it also regresses on both x86 | 08:36 |
| mvo | pitti: that will be fixed soon, its actually a regression from snpa-confine | 08:38 |
| mvo | pitti: triggered by snap-confine which is used in the tests, but zyga fixed that so the next upload should fix it | 08:39 |
| pitti | mvo: ah, good, then we can just retry those; I'll add the ppc hint then | 08:39 |
| mup | PR snapd#2001 closed: overlord/boot: switch to using assertstate.Batch <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2001> | 08:41 |
| mvo | pitti: thank you | 08:41 |
| pitti | zyga: any chance to get the snap-confine SRU in xenial verified? | 08:51 |
| pitti | (sitting there for 20 days) | 08:51 |
| pitti | zyga: the next version has already been sitting in unapproved for a week, but is blocked by ^ | 08:51 |
| ogra_ | abeato, did you pick the right channel ? (we didnt rellease to stable yet) | 09:02 |
| abeato | ogra_, yes, I found out that was the issue in the end, thanks | 09:03 |
| mup | PR snapd#2002 opened: tests: use new spread `debug` feature <Created by mvo5> <https://github.com/snapcore/snapd/pull/2002> | 09:49 |
| zyga | pitti: I'll check what's going on there, thanks for telling me about it | 09:49 |
| kalikiana | 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 |
| ogra_ | kalikiana, yes | 09:51 |
| ogra_ | (has been discussed multiple times ... i'm not sure about the verdict though) | 09:51 |
| kalikiana | 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 |
| ogra_ | you have to ask the core team ... mvo or niemeyer would know more | 09:52 |
| zyga | ogra_: yes? | 09:53 |
| ogra_ | zyga, ? | 09:53 |
| zyga | kalikiana: reading the document I see that this requires MADV_MERGEABLE | 09:53 |
| zyga | kalikiana: so only applications explicitly doing that would benefit | 09:53 |
| ogra_ | zyga, isnt that a wrapper thing ? i.e. ubuntu-core-launcher | 09:54 |
| zyga | kalikiana: so snaps could take advantage of this | 09:54 |
| zyga | ogra_: no | 09:54 |
| mup | PR snapd#1921 closed: tests: replace systemd-run with on-the-fly generation of units <Reviewed> <Created by vosst> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1921> | 09:54 |
| zyga | ogra_: and besides, we cannot do that for the application | 09:54 |
| zyga | kalikiana: so I think a more balanced answer is that snapd doesn't prevent apps from using ksm | 09:55 |
| zyga | kalikiana: so if they are written to take advantage of it, they can | 09:55 |
| ogra_ | our kernels have definitely switched it on ... | 09:55 |
| ogra_ | (at least the official ones) | 09:56 |
| zyga | ogra_: right but applications need to use it, otherwise it does nothing | 09:56 |
| ogra_ | 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:56 |
| ogra_ | afaik they a use that on a VM level | 09:57 |
| zyga | ogra_: with madvise(and MADV_MERGABLE) | 09:57 |
| kalikiana | zyga: Supposedly qemu can share memory of multiple instances - I wonder how they do it in that general way | 09:57 |
| zyga | kalikiana: ^^ | 09:57 |
| ogra_ | dunno, i dont thionk all debs that are used in ubuntu clouds are patched on the fly :) | 09:57 |
| zyga | application developers need to explicitly mark private memory pages as mergable | 09:58 |
| zyga | probably only virtualization tools use this feature | 09:58 |
| ogra_ | afaik the sharing theer works on application level and people are surely not using modified debs | 09:58 |
| mup | PR snapd#1994 closed: snap: add `snap known --remote` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1994> | 09:58 |
| ogra_ | so the VM must do something here that snapd/ubuntu-core-launcher should be able to do as well | 09:59 |
| zyga | no | 09:59 |
| zyga | ogra_: snap-confine lives for a millisecond | 10:00 |
| zyga | ogra_: and execs an application | 10:00 |
| zyga | ogra_: the appication must understand what is going on and actually sensibly use madvise | 10:00 |
| zyga | ogra_: it cannot be blindly enabled | 10:00 |
| zyga | 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 |
| zyga | ogra_: but if there's a snap with VM inside then that snap can use this feature internally | 10:01 |
| zyga | ogra_: so snapd is not related to ksm in any way, this is application responsibility to use | 10:01 |
| mup | PR snapd#2003 opened: debian: adjust packaging setup for trusty/deputy systemd <Created by vosst> <https://github.com/snapcore/snapd/pull/2003> | 10:04 |
| mup | PR snapd#2004 opened: cmd/snap: make the buy tests run again and fix the failures <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2004> | 10:17 |
| === hikiko is now known as hikiko|ln | ||
| === marcoceppi_ is now known as marcoceppi | ||
| mup | PR snapd#2005 opened: many: introduce a device-init hook, let it optionally configure device registration and the serial-request <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2005> | 11:29 |
| mup | PR snapd#1865 closed: overlord/devicestate: POC to parametrise serial-request content/sending <Blocked> <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1865> | 11:30 |
| === hikiko|ln is now known as hikiko | ||
| === mp is now known as Guest73139 | ||
| morphis_ | ogra_: at which time is a new OS snap for edge build daily? | 12:15 |
| ogra_ | ogra@lillypilly:~$ crontab -l | 12:16 |
| ogra_ | 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1 | 12:16 |
| ogra_ | 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_ | ogra@lillypilly:~$ | 12:16 |
| ogra_ | 4:30 UTC | 12:16 |
| morphis_ | thanks | 12:17 |
| morphis_ | ogra_: is this generate-core script available somewhere? | 12:17 |
| ogra_ | 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:17 |
| morphis_ | ok | 12:18 |
| ogra_ | sure, on people.canonical.com ;) | 12:18 |
| ogra_ | (the path is right in there ) | 12:18 |
| ogra_ | thats always the latest version ... its a bit out of sync, but it is also in lp:snappy-dev/ubuntu-core | 12:18 |
| morphis_ | ogra_: ok | 12:24 |
| ogra_ | https://code.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk .... in the cron-scripts dir | 12:26 |
| ogra_ | morphis_, i brought the branch in sync now | 12:34 |
| ogra_ | there is also a README in the cron-scripts dir, describing what you need to prepare when using it yourself | 12:36 |
| abeato | 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? | 12:48 |
| === ycheng_ is now known as ycheng | ||
| zyga | abeato: no, you get that module loaded but you cannot load it yourself | 12:52 |
| zyga | abeato: kmod is not an interface it is a "security backend" | 12:52 |
| zyga | abeato: interfaces can choose to use it | 12:52 |
| abeato | zyga, so the module would get loaded when you connect to a plug that requires that, correct? | 12:53 |
| mup | PR snapd#2006 opened: debian: merge 2.15.2ubuntu1 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/2006> | 12:53 |
| zyga | abeato: it depends on the design of the interface | 12:53 |
| jdstrand | abeato: is there a particular use case you have in mind? | 12:54 |
| jdstrand | zyga: good morning/afternoon zyga :) | 12:54 |
| jdstrand | and hello abeato :) | 12:54 |
| zyga | jdstrand: hello | 12:54 |
| abeato | jdstrand, loading ppp modules | 12:54 |
| abeato | jdstrand, morning :) | 12:54 |
| zyga | jdstrand: I'm working on SRU verification, eh, I "love" our fragmented releases | 12:55 |
| jdstrand | abeato: yep, that was the other one that I thought people would add things to immediately | 12:55 |
| === dpm-afk is now known as dpm | ||
| ogra_ | zyga, snappy will fix that :P | 12:55 |
| jdstrand | zyga: heh. you can spin that another way-- it is motivating to get things right before release :P | 12:55 |
| mup | PR snapd#1979 closed: assertions: add system-user assertion <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1979> | 12:55 |
| abeato | jdstrand, zyga just want to load ppp_generic when somebody connects to the ppp interface | 12:56 |
| zyga | jdstrand: the problem is the release is right but now I'm in some weird partial state that is never tested | 12:56 |
| pstolowski | abeato, yeah, as zyga says | 12:56 |
| zyga | ogra_: it was supposed to ;) | 12:56 |
| ogra_ | :) | 12:56 |
| zyga | ogra_: but not for snappy :-( | 12:56 |
| zyga | abeato: that's a two-liner then | 12:57 |
| ogra_ | yeah, there was some irony in my sentence ;) | 12:57 |
| zyga | abeato: or maybe even one liner, depending on syntax | 12:57 |
| abeato | pstolowski, zyga so this should be just fine, isn't it?: http://paste.ubuntu.com/23242066/ | 12:57 |
| jdstrand | abeato: yeah, take a look at firewall-control. ppp will be the same. you won't need anything special | 12:57 |
| zyga | ogra_: yeah, I know :/ | 12:57 |
| jdstrand | abeato: specify the modules you want and snapd will handle the rest on interface connect | 12:57 |
| abeato | alright, thanks | 12:58 |
| pstolowski | yep | 12:58 |
| jdstrand | 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 |
| jdstrand | oh well, there is a bug in the devel release that will get fixed | 13:00 |
| jdstrand | that's happened on occasion :) | 13:01 |
| jgdx | 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:11 |
| jgdx | it make sense, but it's not known to me how to get out of that situation | 13:12 |
| jgdx | any ideas? | 13:14 |
| === Guest54996 is now known as pmp | ||
| === pmp is now known as Guest60909 | ||
| zyga | jdstrand: I'd love to know about that docker workaround | 13:19 |
| zyga | jdstrand: I see what it does but OMG what is this doing to make the problem go away | 13:19 |
| jdstrand | 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 |
| jdstrand | zyga: so we let it keep thinking that | 13:20 |
| jdstrand | 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:21 |
| jdstrand | zyga: ideally we would have a clean mountinfo and we could remove the workaround | 13:22 |
| jdstrand | 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 |
| jdstrand | terribly ugly | 13:24 |
| Guest60909 | nick pmp | 13:27 |
| Guest60909 | <-- sry, what an idiot | 13:27 |
| mup | PR snapd#2007 opened: interfaces: ppp: load needed kernel module <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2007> | 13:34 |
| zyga | jdstrand: interesting, that explains a lot | 13:36 |
| zyga | jdstrand: I don't think that obtaining clean mountinfo is possible though | 13:36 |
| zyga | 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:36 |
| sergiusens | zyga the important question is, are you going to target the correct mailing list for the announcement this time ;-) | 13:37 |
| zyga | sergiusens: for what? :) | 13:37 |
| zyga | jdstrand: as for SRU we have a more nested problem to solve, I need to talk to pitti about it | 13:38 |
| zyga | pitti: can you perhaps help me with a little SRU problem | 13:38 |
| sergiusens | zyga snapd, snap-confine, ubuntu-core | 13:39 |
| sergiusens | zyga I feel like I am the only one using snapcraft-announce! | 13:39 |
| zyga | 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 |
| zyga | sergiusens: I agree and I really should use it | 13:39 |
| zyga | pitti: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text= | 13:39 |
| zyga | pitti: or perhaps even .42 from yakkety if mvo manages to release snapd today | 13:40 |
| zyga | 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 |
| mup | Bug #1597842: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Invalid> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1597842> | 13:41 |
| zyga | 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 |
| zyga | pitti: I want to avoid extra delays so I'd appreciate any insight you may give me | 13:43 |
| mup | PR snapd#2006 closed: debian: merge 2.15.2ubuntu1 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2006> | 13:43 |
| === mzanetti_ is now known as mzanetti | ||
| mup | PR snapd#2008 opened: overlord/state: prune old empty changes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2008> | 13:49 |
| zyga | jdstrand: do you have a suggestion on how snap-confine could do something differently to make docker work? | 13:50 |
| zyga | hmm | 13:57 |
| pitti | 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 |
| zyga | pitti: yes, it's a superset | 13:58 |
| pitti | zyga: if it doesn't fix everything, that's not a problem -- there will always be the next SRU | 13:58 |
| zyga | pitti: (full upstream releae rather than a cherry-picked one) | 13:58 |
| pitti | zyga: we just must pull an SRU if it regresses something that worked before | 13:59 |
| zyga | pitti: hmm | 13:59 |
| zyga | pitti: that's not the case here | 13:59 |
| zyga | pitti: the fix in .38-0ubuntusomething is just partial | 13:59 |
| zyga | pitti: there are no regressions, I just want to find a smooth way to eventually update everyone to .42 | 13:59 |
| pitti | 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? | 13:59 |
| pitti | ah, it's more like a backport | 14:00 |
| pitti | zyga: well, as you wish -- verify 38 and we release it, or skip it and I review/acept .41 "over" it | 14:00 |
| zyga | pitti: yes, I think that's more accurate | 14:00 |
| zyga | 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 |
| mup | Bug #1597842: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Invalid> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1597842> | 14:01 |
| pitti | zyga: I'd just reopen it and clear the tag after releasing the update (that auto-closes the bug) | 14:02 |
| zyga | ok | 14:02 |
| zyga | so I'll reopen and re-verify this with .41 that really fixes it | 14:02 |
| pitti | zyga: ok; otherwise current SRU is good? | 14:04 |
| zyga | pitti: let me verify the last two items | 14:04 |
| morphis_ | pitti: thanks a lot for https://launchpad.net/ubuntu/+source/nplan/0.12~16.04 ! | 14:04 |
| pitti | zyga: rihgt, please officially say "works" on some of the bugs | 14:05 |
| zyga | jdstrand: curious, how did you debug the docker issue, I think that is pretty esoteric :) | 14:05 |
| zyga | pitti: will do | 14:05 |
| pitti | morphis_: yw! it needs to grind through the machinery now, and we can hopefully release it in a week | 14:05 |
| === tachyons is now known as tachyons_ | ||
| === tachyons_ is now known as tachyons | ||
| jdstrand | 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:17 |
| jdstrand | 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:18 |
| jdstrand | zyga: and that turned out to be the problem | 14:19 |
| zyga | 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:21 |
| jdstrand | zyga: I don't think that would complicate content sharing-- we are still mounting the target in SNAP_DATA | 14:22 |
| sborovkov | 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 |
| sborovkov | This snap ran before just fine | 14:23 |
| sborovkov | Any idea what's going on | 14:23 |
| jdstrand | 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 |
| zyga | jdstrand: I can experiment quickly but I doubt that would change anything for docker | 14:23 |
| zyga | jdstrand: mountinfo requires devmode, it's not readable | 14:23 |
| jdstrand | zyga: or mount-observe | 14:24 |
| jdstrand | zyga: I'm not saying it is a world burning problem | 14:24 |
| zyga | jdstrand: hmm, interesting, yes | 14:24 |
| jdstrand | just that it is a leak | 14:25 |
| jdstrand | unfortunately due to noisy denials due to various libraries, I suspect people will specify mount-observe a lo | 14:25 |
| jdstrand | t | 14:26 |
| jdstrand | 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:26 |
| jdstrand | 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:27 |
| jdstrand | zyga: ^ | 14:28 |
| ralsina | sergiusens: https://github.com/snapcore/snapcraft/pull/813 is ready for a review when you have a spare moment | 14:30 |
| mup | PR snapcraft#813: "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/813> | 14:30 |
| zyga | jdstrand: well, yeah, I think this is a tough problem, mouninfo will always tell the truth | 14:30 |
| sergiusens | ralsina will do, thanks for working on this! | 14:31 |
| jdstrand | 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 |
| ralsina | sergiusens: np, ping me for anything you see there.. 1st snapcraft branch so there will surely be something horrible :-) | 14:32 |
| sergiusens | ralsina nah, all good, I am holding off moving away from docopt until this lands so you don't take a hit | 14:33 |
| ralsina | wee, kill docopt :-) | 14:33 |
| jdstrand | mectors: hey, did you get my email regarding bug #1627309 ? | 14:34 |
| mup | Bug #1627309: bluetooth-control noble.js not working <Snappy:New> <https://launchpad.net/bugs/1627309> | 14:34 |
| sborovkov | 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:42 |
| ogra_ | sborovkov, was that something cross compiled ? | 14:48 |
| * ogra_ wonders why anything would use 5 or 6 on ubuntu ... given we only support ARMv7 | 14:49 | |
| mup | PR snapd#2009 opened: tests: add firewall-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2009> | 14:50 |
| sborovkov | ogra_: no | 14:50 |
| ogra_ | so it only howed up ater a snapd upgrade ? | 14:51 |
| sborovkov | 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 |
| ogra_ | *showed up after | 14:51 |
| ogra_ | right, looks like napd itself was built for ARMv6 without hardfloat | 14:52 |
| ogra_ | *snapd | 14:52 |
| ogra_ | mvo, zyga ^^^ | 14:52 |
| ogra_ | (i dont see such issue on the allo-snap images though) | 14:52 |
| ogra_ | *all- | 14:52 |
| sborovkov | 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 |
| ogra_ | right | 14:53 |
| mup | Bug #1627692 opened: Error when model file is not in $HOME <Snappy:Confirmed> <Ubuntu Image:Invalid> <https://launchpad.net/bugs/1627692> | 14:55 |
| mvo | 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 |
| zyga | jdstrand: hmm | 14:56 |
| zyga | er | 14:56 |
| zyga | hmm | 14:56 |
| zyga | jdstrand: sorry, I didn't notice your name was in the bugger | 14:56 |
| zyga | buffer | 14:56 |
| ogra_ | mvo, ah, perhaps the snap-confine that is stuck in proposed ? | 14:56 |
| ogra_ | snapd should have a versioned dep if thats the case | 14:57 |
| sborovkov | ah ok. So I guess I need to use proposed to make sure it works. | 14:57 |
| zyga | sborovkov: try the ppa perhaps | 14:58 |
| zyga | sborovkov: or build 1.0.42 from the tarball on github | 14:58 |
| zyga | sborovkov: packaging is on git.launchpad.net/snap-confine | 14:58 |
| mvo | ogra_: I think something else broke it, but I don't remember the details | 15:00 |
| mvo | ogra_: hm, maybe I do | 15:00 |
| sborovkov | zyga: what ppa should I use? | 15:00 |
| ogra_ | well, if we break everyones RPi classic install regarding snaps after we told everyone to use classic, thats a bad thing | 15:00 |
| zyga | sborovkov: aww, I never remember, sorry | 15:01 |
| zyga | sborovkov: can you try the package in yakkety? | 15:01 |
| sborovkov | 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 |
| zyga | sborovkov: thanks | 15:02 |
| jdstrand | zyga: no worries | 15:09 |
| mup | PR snapd#2010 opened: many: create auth.json for the freshly created user in `snap create-user` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2010> | 15:11 |
| zyga | 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 |
| mup | Bug #1584456: apparmor denial using ptmx char device <apparmor> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <linux (Ubuntu):Confirmed for tyhicks> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1584456> | 15:15 |
| * ogra_ puts on an evil grin ... | 15:16 | |
| jdstrand | 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 |
| ogra_ | 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 |
| ogra_ | :) | 15:17 |
| jdstrand | 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:17 |
| jdstrand | zyga: (sufficient when there isn't a simple test case) | 15:18 |
| jdstrand | 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:19 |
| zyga | jdstrand: thank you :) | 15:21 |
| ogra_ | 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:22 | |
| ogra_ | no, definitely pointing to -updates ... as it should ... weird | 15:23 |
| ogra_ | cjwatson, is there a bug open for that ? ^^ | 15:23 |
| * ogra_ assumes there is ... i cant be the first one noticing that | 15:24 | |
| cjwatson | ogra_: not sure, probably, various bugs about ancestry not being ideal | 15:28 |
| ogra_ | yeah, k | 15:28 |
| ogra_ | i wont file one then | 15:28 |
| ogra_ | (even though it is a lie, it is a good warning mechanism that i need to take action before it migrates) | 15:29 |
| ogra_ | oh man ... that initramfs-tools in -proposed will make the size explode :/ | 15:32 |
| cjwatson | ogra_: Yeah, that's why it wouldn't be trivial to change. It would probably need multiple indicators that look slightly different. | 15:33 |
| zyga | ok, verification done | 15:34 |
| zyga | pitti: I've verified all the other issues, I will now ask for the SRU in ubuntu-release | 15:34 |
| ogra_ | 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:35 |
| ogra_ | cydizen, oh, ignore me ... i see it in the isc-dhcp package | 15:36 |
| === daniel1 is now known as Odd_Bloke | ||
| ogra_ | err, sorry cydizen, that was for cyphermox | 15:37 |
| cyphermox | isc-dhcp has the hook. | 15:37 |
| ogra_ | yeah, just saw it | 15:37 |
| cyphermox | it only adds 500k | 15:37 |
| ogra_ | thats a lot | 15:38 |
| cyphermox | no choice. | 15:38 |
| ogra_ | (for an initrd that is only 2.5MB and has no NIC drivers in it at all :) ) | 15:38 |
| ogra_ | (like ours) | 15:38 |
| cyphermox | there isn't a choice --- there are conflicting priorities here, and IPv6 needs isc-dhcp in the initramfs to work. | 15:39 |
| cyphermox | (that's for MAAS, but it's relevant to any network where you want to "netboot" over ipv6) | 15:39 |
| ogra_ | well, we exclude all modules from the core initrd | 15:39 |
| ogra_ | so it wont affect us at all | 15:39 |
| ogra_ | just the growth will | 15:40 |
| cyphermox | well you can always explicitly remove the hook | 15:40 |
| ogra_ | indeed ... but ... well ... moar hacks | 15:40 |
| cyphermox | or I suppose we can come up with an environment parameter to say "no, don't install isc-dhcp" | 15:40 |
| cyphermox | there's only so much that can be done. | 15:40 |
| ogra_ | yeah, via initramfs.conf | 15:40 |
| ogra_ | our initrd has in general become a horrid thing ... | 15:41 |
| ogra_ | 34MB on my desktop install | 15:42 |
| cyphermox | heh | 15:42 |
| cyphermox | 34M is generally not a big deal | 15:42 |
| ogra_ | a few yeqars ago that would have counted as rootfs :P | 15:42 |
| ogra_ | it slows down your boot | 15:42 |
| zyga | jdstrand: I'm wondering if we can not mount all of / as rslave | 15:42 |
| ogra_ | you need to load it from disk | 15:42 |
| ogra_ | and then wait til the kernel decompressed it (on arches where that happens) | 15:43 |
| cyphermox | replacing klibc (which is partly why isc-dhcp comes in) is long overdue. | 15:43 |
| zyga | jdstrand: or do some trick that would let us do make / rslave and then bind mount "vanilla" /media over | 15:43 |
| ogra_ | well, you cant actually replace klibc | 15:43 |
| ogra_ | you only start duplicating more of it with glibc tuff | 15:43 |
| ogra_ | *stuff | 15:43 |
| cyphermox | of course you can get rid of it, most things already don't use it at all | 15:44 |
| ogra_ | well, once someone re-writes run-init you can | 15:44 |
| ogra_ | but i dont see that happen | 15:44 |
| cyphermox | ipconfig was the biggest bit, and that's mostly replaced by isc-dhcp, unless you use ancient network boot stuff | 15:44 |
| cjwatson | run-init could probably just be directly copied somewhere else and relinked against glibc | 15:45 |
| cjwatson | Maybe with very minor changes | 15:45 |
| ogra_ | i thought thats not possible | 15:45 |
| cyphermox | cjwatson: indeed. | 15:45 |
| * ogra_ suggested that years ago and was told so | 15:46 | |
| cjwatson | I think at the time it may not have been worth it because there was a ton of other stuff | 15:46 |
| ogra_ | ah | 15:46 |
| cjwatson | ipconfig was definitely more of an issue | 15:46 |
| cyphermox | run-init will be last on my list once I've run through $everythingelse and made sure there weren't packages elsewhere that depend on obscure other bits of klibc | 15:47 |
| ogra_ | well, getting rid of the duplication is surely a good thing ... getting rid of it in favour of massive growth ... not so much though | 15:48 |
| davidcalle | ogra_: hey, a quick question: I'm looking ant gadget snaps and wondering: is there another possible value than "kernel" for "device-tree-origin" in gadget.yaml? | 15:49 |
| davidcalle | looking at* | 15:49 |
| ogra_ | looking on my desktop that was originally installed with 3.13.0, the initrd has already grown by 5MB | 15:49 |
| ogra_ | davidcalle, "gadget" | 15:49 |
| ogra_ | davidcalle, but thats the default anyway ... so we dont bother to set "device-tree-origin" in gadgets where the dtb is shipped in the gadget | 15:50 |
| jdstrand | zyga: tyhicks had thoughts on that. I've forwarded you the info | 15:50 |
| zyga | thank you | 15:51 |
| davidcalle | ogra_: thanks! | 15:51 |
| ogra_ | *grown by 5MB between 3.13.0 and 4.4.0 | 15:51 |
| ogra_ | davidcalle, np ... | 15:51 |
| mup | PR snapd#2004 closed: cmd/snap: make the buy tests run again and fix the failures <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2004> | 16:05 |
| mup | PR snapd#2011 opened: client, cmd: change buy command to match UX document <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2011> | 16:08 |
| mup | PR snapd#2012 opened: interfaces/builtin: add missing rule to allow run-parts to execute all resolvconf scripts <Created by morphis> <https://github.com/snapcore/snapd/pull/2012> | 16:19 |
| mup | Bug #1628193 opened: please set TMPDIR=/tmp when launching snaps <Snappy:Triaged> <https://launchpad.net/bugs/1628193> | 16:20 |
| mup | PR snapd#2013 opened: many: finish `snap set` API <Created by kyrofa> <Conflict> <https://github.com/snapcore/snapd/pull/2013> | 16:24 |
| zyga | tyhicks: thank you for the investigation wrt /media sharing! | 16:29 |
| tyhicks | zyga: no problem - I hope it is helpful | 16:31 |
| === xnox_ is now known as xnox | ||
| * ogra_` feels net-splitted | 16:39 | |
| === Eleventh_Doctor is now known as Pharaoh_Atem | ||
| === popey_ is now known as popey | ||
| === LarreaMikel1 is now known as LarreaMikel | ||
| === leftyfb_ is now known as leftyfb | ||
| === beisner- is now known as beisner | ||
| === chihchun_afk is now known as chihchun | ||
| === jkridner|pd is now known as jkridner | ||
| === chihchun_afk is now known as chihchun | ||
| === wxl_ is now known as wxl | ||
| === ben_r_ is now known as ben_r | ||
| ogra_ | geez ... that net-splittery today is really annoying | 17:23 |
| om26er | Hi! I am trying to create a local snap for a python script, how can I add source for my script code that is a local directory ? | 17:25 |
| nacc | om26er: your snapcraft.yaml can copy/dump from local directoriees (source: ., iirc) | 17:25 |
| nacc | (and as an example) | 17:25 |
| === daker_ is now known as daker | ||
| om26er | nacc, I tried source: /my_path it didn't pick the code from there | 17:26 |
| ogra_ | also make sure to have the python plugin in use ... there is really no guarantee that the core snap has a python interpreter or a ceetain version of it | 17:26 |
| nacc | ogra_: good point :) | 17:26 |
| nacc | om26er: can you pastebin your snapcraft.yaml? | 17:26 |
| om26er | nacc, http://paste.ubuntu.com/23243296/ | 17:27 |
| ogra_ | i.e http://paste.ubuntu.com/23243298/ would get you the python2 interpreter (and just that) in your snap | 17:28 |
| ogra_ | ah, i see you are already using it | 17:32 |
| ogra_ | there are various issues in your snapcraft.yaml ... | 17:32 |
| ogra_ | source: /home/om26er/Desktop/source/ | 17:32 |
| ogra_ | that should be a relative path from where your snapcraft.yaml lives | 17:32 |
| ogra_ | command: python3 run | 17:32 |
| ogra_ | that would only work if "run" is actually living in a dir in $PATH | 17:32 |
| ogra_ | om26er, /my_path would mean you have actually a dir in / called my_path ... try ./my_path here | 17:32 |
| ogra_ | i.e. relative to your snap dir | 17:32 |
| nacc | ogra_: i wonder if the relative path requirement should be explicit in the help? the example does say ./..., but absolute paths don't work? | 17:32 |
| ogra_ | not sure, if $SNAP works here ... iirc there was a bug about that | 17:33 |
| ogra_ | absolute paths would be ugly since you need to include the snap name, version etc | 17:33 |
| ogra_ | they *can* work though ... if you put that data in | 17:33 |
| * nacc might be confused, but thought absolute paths worked with the copy plugin, at least | 17:33 | |
| nacc | not important, regardless :) | 17:34 |
| === vrruiz_ is now known as rvr | ||
| ogra_ | well, the copy plugin is dead for some obscure reason | 17:34 |
| nacc | yeah,that's why i said not important | 17:34 |
| pmcgowan | ogra_, I need help :( | 17:34 |
| om26er | ogra_, /my_path actually meant my local path i.e. /home/om26er/Desktop/source/ | 17:39 |
| ogra_ | right, try a relative one ... starting from where your snapcraft.yaml lives | 17:39 |
| om26er | ok | 17:39 |
| === tvansteenburgh1 is now known as tvansteenburgh | ||
| === chihchun_afk is now known as chihchun | ||
| mhall119 | check it out! http://mhall119.com/2016/09/desktop-app-snap-in-300kb/ | 18:22 |
| === mjl_ is now known as mjl | ||
| === popey_ is now known as popey | ||
| mup | PR snapd#2015 opened: asserts: introduce AttributeConstraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/2015> | 19:03 |
| === beisner- is now known as beisner | ||
| oparoz_ | Is there an interface in the works which would allow snaps to mount NFS and Samba shares? | 19:29 |
| === w1gz_ is now known as w1gz | ||
| === philroche_ is now known as philroche | ||
| nhaines | Is snapweb still broken on the RPi2? :) | 19:58 |
| jdstrand | nessita: hey, if someone wanted to file a bug against the store's review process, but not the review tools, what project would that be against? | 20:00 |
| pedronis | jdstrand: I think https://bugs.launchpad.net/software-center-agent | 20:02 |
| jdstrand | pedronis: | 20:04 |
| jdstrand | pedronis: thanks | 20:05 |
| zyga_ | tyhicks, jdstrand: https://twitter.com/zygoon/status/780858109950619649 | 20:09 |
| tyhicks | zyga_: that's quite a mount table you have there | 20:11 |
| zyga_ | tyhicks: yep, and the kernel nicely hangs when I ran 'umount -l' later on | 20:13 |
| zyga_ | tyhicks: you know that the kernel dies when the cursor stops blinking :) | 20:13 |
| tyhicks | :) | 20:15 |
| zyga_ | tyhicks: it's late today and I was supposed to go rinding but I can easily reproduce this with a few syscalls | 20:15 |
| zyga_ | tyhicks: perhaps a bug in the kernel, looks like it is trying to rbind the same thing recursively and happily runs out of memory, I killed the process when I saw 5GB of extra memory allocated in a few seconds | 20:15 |
| niemeyer | cjwatson: The spread snap doesn't work with qemu yet, sorry :( | 20:29 |
| niemeyer | cjwatson: It needs to be aware of the hosts file being elsewhere.. we need to address this problem in snappy itself, making it easier for that sort of reusability to occur someohw | 20:30 |
| cjwatson | niemeyer: aha, right, so I should just build it straight from the github repository or similar? | 20:31 |
| niemeyer | cjwatson: We're addressing that with lxd and docker by enabling communication with the daemons, but we don't yet have good support for reusing classic debs generically, as that's basically a deb dependency | 20:31 |
| cjwatson | (for now) | 20:32 |
| niemeyer | cjwatson: yeah, go get https://github.com/snapcore/spread/cmd/spread should land a bin on $GOPATH/bin | 20:32 |
| cjwatson | all right, will give that a try later, ta | 20:32 |
| niemeyer | cjwatson: Sorry for the trouble | 20:32 |
| cjwatson | np | 20:33 |
| mup | PR snapd#2013 closed: many: finish `snap set` API <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/2013> | 20:49 |
| nessita | jdstrand, http://bugs.launchpad.net/software-center-agent/+filebug :-) | 20:52 |
| mup | PR snapd#2016 opened: many: rename apply-config hook to config-changing <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2016> | 20:55 |
| kyrofa | ogra_, are you still around? | 21:01 |
| === robert_ancell_ is now known as robert_ancell | ||
| === Guest60909 is now known as pmp | ||
| mup | Bug #1628289 opened: snapd should depend on squashfuse (for use in containers) <lxd> <Snappy:New> <https://launchpad.net/bugs/1628289> | 21:43 |
| mup | PR snapd#2002 closed: tests: use new spread `debug` feature <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2002> | 22:30 |
| === Guest42562 is now known as devil__ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!