[01:42] ok what I am missing, I am trying to creatte a classic snap. it builds but after I install it using --classic --dangerous and try and run the command it keeps getting unable to allocate memory errors after hanging for a while? [02:49] PR snapd#3819 closed: hooks: do not error when hook handler is not registered (2.27) [05:26] PR snapcraft#1515 opened: tests: use a fake pip, instead of mocking everything [05:51] mwhudson: so I checked and it looks like x/crypto/ssh/terminal brings in x/sys/unix - for 2.28 I need to find a way to make this build again on powerpc. I will poke a bit to see what can be done [06:48] PR snapd#3822 opened: vendor: use old golang.org/x/crypto/ssh/terminal to build on powerpc again [08:02] good morning, sorry for a late start, had some woes with kids [08:08] mvo: I saw some concenring test failures again [08:09] mvo: I assumed it was caused by my branch but then it failed only partially, [08:10] zyga-suse: what failures are those? [08:10] mvo: if you look at https://github.com/snapcore/snapd/pull/3621 you will see that upgrade/basic failed with Run install hook of "core" snap if present (internal error: no registered handlers for hook "install") [08:10] PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [08:10] the latest rebuild didn't fail this way [08:10] the log is in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170828_165347_9cd1b@/log.gz [08:11] I'm worried there's still a race somewhere that we don't handle [08:12] I'll look at the code there and try to figure out what must happen for this to show up [08:12] zyga-suse: it seems like 3816 has not landed yet, so seening this error seems to be ok still. or am i missing something? [08:12] zyga-suse: but yeah, please do go ahead [08:12] zyga-suse: and see if you can find out more [08:13] mvo: not sure if this is really related, [08:13] ok [08:13] that PR was to fix rollback/downgrades [08:13] here we fail on upgrade [08:13] so I suspect the mechanism of the failure is different [08:22] woo! go tyhicks [08:23] hey Chipaca :) [08:23] what is that about? [08:24] zyga-suse: recent seccomp efforts coming together [08:24] ah, indeed [08:24] zyga-suse: as far has me know that happend when changelog has the wrong version, so reexec doesn't work [08:25] s/has me/as we/ [08:25] pedronis: ah! perhaps that may explain it, I merged master later on [08:25] thank you! [08:31] Chipaca: hey, good morning! [08:32] Chipaca: would love to get your advice on 3815 - but ready when you are :) [08:39] PR snapd#3816 closed: hooks: do not error out when hook is optional and no hook handler is registered [08:41] PR snapd#3750 closed: snapstate: integration test for undoing a daemon restart on classic [08:42] mwhudson, pedronis: the powerpc build failure (because of the crypto update) should be fixed with 3822 - slightly ugly though [08:45] mvo: so... on core, source complexion.sh from /etc/skel/.bashrc ? [08:45] completion.sh i mean [08:45] Chipaca: yeah, that might be an option, will not help with exiting installs, but otherwise nice and simple [08:46] Chipaca: does the PR look otherwise ok? if it does I would love to see it merged as it blocks a lxd test [08:47] Chipaca: hi [08:47] mvo: me, I would've done it differently, but it's fine as it is [08:47] mvo, hey, 3773 has a conflict [08:47] mvo: I mean, I would've looked at having osutil.IsWritable(dirs.CompletersDir) or somesuch [08:47] Chipaca: happy to do it differently, what would be your approach? [08:48] Chipaca: aha, even better, yeah, let me do that [08:48] mvo: but that is more work :-) [08:48] pstolowski: thanks, checking [08:48] Chipaca: thats fine if quality(more_work) > quality(less_work) :) [08:49] mvo: but if that existed, then noCompletion := !osutil.IsWritable(dirs.CompletersDir) || !osutil.FileExists(dirs.CompleteSh) [08:49] mvo: and the rest stays unchanged [08:49] Chipaca: indeed, I will tweak [08:49] Chipaca: do you think we should rename "complexion" to "test-snapd-complexion" or just ignore that for now? [08:50] hopefully back [08:50] I learned that the new mac randomization thing doesn't love me [08:50] mvo: if it goes to the store, it needs renaming [08:50] zyga-suse: fwiw, I looked into the mount issue that lxd reported yesterday and it looks like real work (not just change two lines) :/ [08:50] mvo: if it doesn't go to the store i don't care :-) [08:50] Chipaca: I think I could tweak things so that it does not have to go through the store [08:50] Chipaca: I have a look [08:50] mvo: ah, i see it's already in the store? [08:51] mvo: I came to the same conclusion [08:51] mvo: I plan on working on that today [08:51] Chipaca: yes, but we can unpublish it again [08:51] mvo: if /tests/lib/snaps/complexion and test-snapd-complexion are the same thing, then yes let's rename the former [08:51] Chipaca: they are - ok, that works for me, I will tweak the branch [08:51] ok [08:52] pedronis: i know my pr has a conflict, but i'm also slight blocked waiting for a store issue so i'm in no hurry to deconflict it right now [08:52] as if that landed some people might panic [08:52] maybe i should label it [08:52] first coffee, then label [08:52] * Chipaca goes [08:54] zyga-suse: do you have a plan yet? it seems like we may need to get back and add a "WantedBy=local-fs-pre.target" with a special "snap-confine ensure-shared-mounts" (or snap-helper or somesuch). or what do you have in mind? [08:54] no plans yet, I'm still hoping we can do this somehow from snap-confine alone [08:54] even if it requires more wokr [08:55] zyga-suse: AIUI the problem is that systemd itself will load all the mount units at the same time (or before) it starts the daemons. so when snap-confine runs and fixes the /, /snap rshare thing stuff is already mounted there and that causes the havoc [08:56] zyga-suse: so AFAICS we need to tweak the system boot ordering to make sure the remount happens earlier [08:57] pstolowski: 3773 is de-conflicted [08:57] mvo: remember that snap-confine can remount anything inside its namespace so ... well, I need to look really [08:57] mvo, thx! [08:57] zyga-suse: ok [09:03] * zyga-suse fights his network plan [09:04] Chipaca: let's mark it blocked then [09:08] * zyga-suse wonders if anyone wants to review https://github.com/snapcore/snapd/pull/3621 [09:08] PR snapd#3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [09:08] mvo: ^ that's my top priority for 2.28 feature [09:08] just to see if it breaks people [09:09] zyga-suse: I would prefer the https://discuss.linuxcontainers.org/t/snapd-cant-remove-old-revisions-when-running-inside-lxd/452/3 fix first [09:10] mvo: sure but 3621 doesn't need any work from me anymore [09:10] zyga-suse: aha, cool [09:10] mvo: as I said I'm working on that, I only meant that that review is my only one that counts for 2.28 so far [09:14] zyga-suse: aha, I see. this is the thing you taged for 2.28, thats fine [09:14] yes [09:25] PR snapd#3818 closed: interfaces: fix network-manager plug [09:26] 3621 needs a jdstrand review though [09:27] zyga-suse: do you think we need input from jdstrand for 3818 ? [09:29] hmmm, sorry, perhaps yes [09:29] I was closing my tabs and I saw 2+1's [09:29] and since this affects all plugs, it's something we should still ask jamie about [09:29] zyga-suse: no worries, lets just make sure we do not release before he had a chance to weight in :) [09:29] +1 [09:30] * zyga-suse is fed up with the network, wants to call it quits and have a walk [09:30] I was trying to git push/pull for the past ten minutes [09:30] mvo: what's the state of snapd#3625 ? at least one of the snapcraft PRs it mentions isn't merged yet [09:30] PR snapd#3625: many: end-to-end support for the bare base snap [09:30] is it blocked? [09:31] pedronis: yes, it is blocked right now :/ [09:31] mvo: do we need any design for that [09:31] mvo: or just some coding? [09:31] it would be great if 2.28 had _a_ level of base snap support [09:33] you are getting ambitious there [09:33] Chipaca: do you plan to still do something in snapd#3398 ? [09:33] PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al [09:33] it seems unclear if it needs more work OTOH it has 2 +1 [09:34] zyga-suse: with 3625 we would have basic support, the snapcraft stuff is only needed for specialized tests, I can make simpler tests [09:34] mvo: not sure if priority, just saying it would be nice [09:34] zyga-suse: I think the two of us need to agree on how snap-confine should handle bases :) then this is good to go, I would love to have it for 2.28 as well and it seems like we are close [09:34] ok, let's try to discuss this in 2-3 hours [09:34] zyga-suse: sounds good! [09:35] pedronis: yeah, I will sort it out, if zyga and I can agree on snap-confine I will just write simpler tests for now until snapcraft is ready [09:35] zyga-suse: welcome back [09:35] zyga-suse: in 2-3h sounds good === JoshStrobl|Work is now known as JoshStrobl [09:35] mvo: it will likely be an IRC/telgram audio call [09:36] zyga-suse: sure [09:36] what should happen with snapd#3617 ? [09:36] PR snapd#3617: interfaces/builtin: use udev tagging more broadly [09:36] it's marked for 2.28 [09:37] zyga-suse: I know your bandwidth is limited currently, we can just discuss by typing [09:37] pedronis: wasn't it just one extra change that needed backing out, otherwise it was ok? if so, I guess I could do that [09:40] I don't know, I suppose zyga knows [09:41] it says to remove the opengl stuff [09:46] hmm? opengl stuff [09:47] ah [09:47] I see [09:47] let me look at what needs doing on that PR [09:47] it is a major change and bugfix for CE [09:48] aha [09:51] anyway lots of PRs needing jdstranda afaict [09:53] Chipaca: did you see my question? [09:53] i did not [09:53] Chipaca: do you plan to still do something in snapd#3398 ? [09:53] PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al [09:53] pedronis: working on it right now [09:54] ah ok [09:54] i'm going to need zyga and morphis' help to test this, at least [09:54] but it should work :-) [10:08] * Chipaca shoves it at linode [10:09] mvo: I'm going to tentatively merge snapd#3697 [10:09] PR snapd#3697: docs: add PULL_REQUEST_TEMPLATE.md [10:10] pedronis: ta! [10:11] PR snapd#3697 closed: docs: add PULL_REQUEST_TEMPLATE.md === JoshStrobl is now known as JoshStrobl|zzz [10:23] PR snapd#3823 opened: tests: rename complexion to test-snapd-complexion [10:23] PR snapcraft#1516 opened: lxd: LXD not installed when using remote [10:24] Chipaca: 3815 is ready for you [10:24] Chipaca: but no rush, its lunchtime here I think [10:46] * Chipaca ~> break & lunch [10:59] * zyga-suse_ considers taking today off [11:05] zyga-suse_, pedronis: I updated/de-conflicted 3617, this should be ready to do in now (waiting for tests still). but it has two +1 and looks sensible overall [11:08] mvo: I'm going to call it quits today [11:08] I'm just frustrated [11:08] trying to fix my network [11:08] need to put my mind at ease [11:16] PR snapd#3824 opened: Do not match any file or directory in or under /sys/bus/pci/devices/ [11:18] PR core#55 opened: Create mount points for use in exposing host system fontconfig === alan_g is now known as alan_g|lunch [12:29] mvo: install-store seems really unhappy in snapd#3815 [12:29] PR snapd#3815: wrappers: ensure bash completion snaps install on core === alan_g|lunch is now known as alan_g [12:50] mvo, morphis_, zyga-*, would appreciate your input on snapd#3398 [12:50] PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al [12:55] mvo: re nmcli: trunk has 'socket AF_NETLINK - -', so does release/2.27 [12:56] mvo: if this is on 2.27, then something isn't regenerating the policy [12:59] jdstrand: there's a branch for you to look at [12:59] jdstrand: https://github.com/snapcore/snapd/pull/3818 [12:59] PR snapd#3818: interfaces: fix network-manager plug [12:59] pedronis: ok [13:00] it was merged a bit too quickly but as far I understood mvo is waiting on your feedback there [13:00] mvo: so, it looks like snap.network-manager.networkmanager.src has 'socket AF_NETLINK - -', but snap.network-manager.nmcli.src does not [13:01] mvo: let me check the plugs, hold on [13:01] mvo: ah, yes, only the networkManagerPermanentSlotSecComp has 'socket AF_NETLINK - -' [13:02] mvo: nmcli may need an AF_NETLINK rule [13:02] (weird, people tested that) [13:02] mvo: I'll look into it and send something up [13:03] oh, you sent it up [13:03] KOBJECT_UEVENT, yeah, that's fine [13:03] * jdstrand comments [13:04] pedronis, mvo: +1d [13:04] mvo: thanks for looking into that [13:32] Chipaca: mvo: snapd#3815 needs a master merge now ? [13:32] PR snapd#3815: wrappers: ensure bash completion snaps install on core [13:39] pedronis: yeah, that's what we said in the standup i think [13:40] niemeyer: may I be curious and ask how you generate the review sprint page? [13:41] Chipaca: Go application that talks to both APIs [13:42] niemeyer: sounds very credential-y [13:43] niemeyer: i might have formatting suggestions, but i'll create them by hand before suggesting we code them [13:43] Chipaca: Not too much.. luckily both ends have simplified versions of the full fledged auth that just requires a token [13:43] also, not now, now -> reviews [13:43] Chipaca: That's generally what I do too [13:43] Chipaca: (looking at them by hand first) [13:44] niemeyer: snapd#3398 is the pr i mentioned in the standup, btw [13:44] PR snapd#3398: env: set XDG_DATA_DIRS for wayland et.al [13:44] it _has_ two greens, but the conversation in the pr prompted the extra work [13:44] Chipaca: Thanks [13:47] pedronis: I do the master merge now [13:47] jdstrand: thanks a bunch [13:47] jdstrand: I will backport that to 2.27 now [13:52] popey, hmm ... didnt oyu once have a xonotic ansp (or do i mis-remember) [13:52] *snap [13:52] snap find doesnt reveal one [13:52] yes [13:52] not in the store, because it was too huge [13:53] I didn't optimise the assets iirc [13:53] not looked at it for a few months though., i think flexiondotorg has looked at it more recently than me, and had other issues [13:54] ah, is size an issue ? [13:54] (apart from taking long for uploads) [13:54] * popey pokes flexiondotorg [13:54] * flexiondotorg feels a poke in ribs. [13:55] I was going for a headshot, but okay [13:55] Yep, I did start a Xonotic snap. [13:55] https://code.launchpad.net/~flexiondotorg/+junk/snap-xonotic [13:55] Haven't tested it recently. BUt last time I did there was no audio. [13:55] oh that was it [13:56] ah [13:59] Could well be fixed now, I've not tested in ages. [13:59] well, i was just curious, thanks [14:00] * popey kicks off a build to see [14:00] (i was pondering to package stage9 ... but it is 1.9G big so collecting some info about possible probs in advance) [14:12] Chipaca: 3398 looks great [14:13] mvo: just saw your comments; replying [14:15] a review for 3822 would be nice [14:15] Chipaca: my comments are mostly nitpick, I think this can go in [14:17] whoops, something is buggy in 3398 [14:17] tests failures look scary-real [14:20] Chipaca: Btw, on #3398, if there's extra work, the easiest way to make that clear is to just send another review saying Request Changes [14:20] Chipaca: This would put both GH and the board in the right state [14:20] mvo: Looking [14:21] Btw, just updated the board icons style.. seems much better now.. [14:21] Much easier to see the work [14:22] hmm, liked the grey blank box more than the questionmark, but otherwise it does seem clearer, yes [14:26] mvo: who groks the 14.04 delta? [14:26] Chipaca: nobody, code duplication == pain :/ [14:27] mvo: asking because I'd like to go over the diffs in rules and etc and make sure they're ok [14:30] PR snapcraft#1513 closed: lifecycle: outdated step should raise SnapcraftError [14:32] mvo: e.g. there's a block that re-sets VENDOR_ARGS in 14.04, that seems suspicious [14:32] in fact it looks like a whole block is dupe'd [14:33] mvo: i'll figure it out :-) [14:33] Chipaca: thank you, much appreciated [14:33] just a SMOP, and tea [14:35] PR snapd#3822 closed: vendor: use old golang.org/x/crypto/ssh/terminal to build on powerpc again [14:42] PR snapcraft#1505 closed: errors: introduce ContainerError [15:01] hi folks - would this be the right place to ask about getting https://bugs.launchpad.net/snapd/+bug/1699768 backported to xenial? It's a dependency for some k8s charm work [15:01] Bug #1699768: "snap set" causes snapd crash [15:02] https://blog.neon.kde.org/index.php/2017/08/29/great-web-browsing-coming-back-to-kde-with-falkon-new-packaging-formats-coming-to-kde-with-snap/ === cachio is now known as cachio_lunch [15:11] PR snapd#3815 closed: wrappers: ensure bash completion snaps install on core [15:14] mthaddon: xenial is what we ship to, so i'd assume it's getting backported [15:15] mthaddon: mvo might know more [15:15] mthaddon: also, hi :-) [15:15] Chipaca: o/ [15:15] Riddell: woo :-) [15:15] mvo: do you know if 14.04 needs/doesn't need --enable-static-libapparmor --enable-static-libseccomp? [15:22] pedronis: snapd#3616 has one review [15:22] PR snapd#3616: cmd/snap-repair: check signatures of repairs from Next [15:22] Anyone up for a second one? [15:29] ok back to figuring out why my hello world snap works fine until I change it to a classic snap! [15:30] boo, classic snaps :P [15:31] stormmore: what happens as a classic snap? [15:31] nacc: I keep getting a unable to allocate memory type error [15:32] stormmore: can you pastebin the full output? [15:32] stormmore: and/or maybe strace it? [15:33] niemeyer: thanks [15:33] stormmore: Logs might also help in some cases [15:33] stormmore: Ping jdstrand if you think it's something that the application is being blocked on [15:33] nacc: give me a few to make sure I wasn't "imagining things" yesterday but sure... I started using the hello expample from the docs and the only thing I changed was the containment to classic [15:33] pedronis: np [15:33] Lunch, biab for more [15:34] niemeyer: nacc: I suspect just a simple AppArmor problem but didn't get that far in troubleshooting [15:38] Chipaca: 14.04 does not need these static builds, we only need it for 16.04 and for the core snap [15:38] mthaddon: if you switch core to "candidate" this should work, we plan to release 2.27 on Monday [15:38] mvo: but 14.04 does need the static builds because of dependencies [15:38] Chipaca: oh, does it? in this case, ok [15:38] mvo: of libpcap [15:38] mvo: not of the other things [15:39] mvo: cool, thx [15:39] mvo: but, my question is, would you rather it weren't static? [15:39] Chipaca: either way is fine [15:39] mvo: that is: is it worth making the diff between the rules bigger? [15:39] Chipaca: I would like to keep the diff as small as possible :) [15:39] me too [15:40] mvo: i'd also like to know if we really need the override_dh_systemd_ blocks [15:40] Chipaca: yes, was wondering about that myself. wasn't it you who added it a *long* time ago :) ? [15:41] mvo: lies! [15:41] * Chipaca runs away [15:41] mvo: i'll test that separately [15:42] too many changes would be baad [15:43] Chipaca: +1 [15:57] Chipaca: you are working on the real failures in #3398 [15:57] ? [16:01] pedronis: yes [16:01] thx [16:03] nacc: niemeyer: actually got a different error this time /smh - https://pastebin.canonical.com/197040/ is the output from the commands from snap creation to running hello === cachio_lunch is now known as cachio [16:04] mvo, https://paste.ubuntu.com/25424909/ [16:04] stormmore: reading [16:05] mvo, I am trying to understand why this test is making the snapd service gives that error when it is stopped [16:05] mvo, any idea? [16:05] stormmore: my initial guess is a conflict between the go in your snap and the go on your system [16:06] stormmore: i'm not entirely sure how go works [16:06] PR snapd#3825 opened: tests: add nmcli regression test [16:08] dpkg-architecture: error: DEB_TARGET_ARCH is not a supported variable name [16:08] hmmm [16:08] stormmore: although if you didn't use cleanbuild, i'm not sure, i guess it just uses the host to build [16:08] Chipaca: manpage says since 1.17.14 :) [16:09] mvo: how do you spell “dpkg-architecture -qDEB_TARGET_ARCH” in Ye Olde Trvsty? [16:09] nacc: maybe you know then ^ :-) [16:09] nacc: not to mention the app is just the gnu-hello C package [16:11] stormmore: err, right :) but the backtrace is go something something :) [16:11] Chipaca: looking, i'm not sure off the top of my head [16:11] you dont happen to have a go "hello" in your path, do you ? :) [16:12] (overriding the snap) [16:15] Chipaca: still looking (spinning up a trusty env to see) [16:15] nacc: that's very kind of you, thanks! [16:16] maybe on trusty DEB_TARGET_ARCH would always be DEB_BUILD_ARCH? [16:17] Chipaca: -qDEB_HOST_ARCH probably but its not quite the same but should be close enough [16:17] Chipaca: let me know, I need to get dinner now but will read backlog [16:18] the lxd-test branch (3372) is GREEN for the first time evar I think :) [16:18] * mvo happy and & [16:18] Chipaca: yeah HOST_ARCH is the closest thing that's documented, at least [16:18] Chipaca: it seems like TARGET_ARCH wsa introduced for exactly this problem :) [16:18] nacc: ok strace hello showed an error about not being root! (running it as sudo strace hello right now filled my terminal backscroll so don't have the specifics right now) [16:19] i'm not sure target_arch is the one we wanted anyway [16:19] stormmore: ah yes, strace might need to be root [16:19] it says target is for when building cross-toolchain [16:19] stormmore: the strace would only have helped see what was giving back ENOMEM, but if you're not seeing that anymore, it's not likely to help [16:19] ie building something for running on A to build things for B [16:20] mvo: so, i'm going to change it to DEB_HOST_ARCH [16:20] nacc: I forget that as I don't use it as much as I probably should ;-) [16:20] Chipaca: yeah, techincally you have 3 build, host and target [16:20] mvo: as trusty has that, and it's what we want [16:20] nacc: yup [16:20]