[01:44] elopio yeah, incomplete as I tend to add examples [01:45] and ack on the other [01:45] elopio btw, snapcraft#1555 has been updated [01:45] PR snapcraft#1555: store: switch to new endpoints [01:49] sergiusens, keep an eye on snapcraft#1549, it should be green any moment [01:49] PR snapcraft#1549: plugins: extract pip from python plugin [01:49] It took virtually all day [01:49] kyrofa funny, I just looked to see if it was ready 🚱 [01:50] We hammered travis today [01:56] kyrofa do you have the next PR in line ready? [02:01] what happened here??https://launchpadlibrarian.net/337615189/buildlog_snap_ubuntu_artful_ppc64el_subiquity_BUILDING.txt.gz [02:06] mwhudson did that work with cleanbuild? [02:09] PR snapcraft#1549 closed: plugins: extract pip from python plugin [02:24] sergiusens: all the other arches built [02:37] mwhudson oh, just taking notice of the architecture, is there a core snap for this architecture? For classic snaps it is sort of needing during linking as we force the linker to be the one in the snap [02:37] sergiusens: yes, it usually builds fine on ppc64el :) [02:37] i suspect some kind of networking glitch but it's a bit silent [02:37] i guess i'll try again [02:38] mwhudson it seems to have been common today, I had a weird error earlier in a lxd container too and ev was reporting similarly === JanC_ is now known as JanC [02:54] hmm reproducible it seems [02:54] (aka it failed three times in a row) [02:58] Issue snapcraft#1452 closed: machine information [02:58] PR snapcraft#1529 closed: recording: record the packages installed in the machine === ikey|work is now known as ikey|zzz === JoshStrobl is now known as JoshStrobl|zzz === chihchun_afk is now known as chihchun [05:40] good morning [06:03] hey morphis [06:03] how are you doing === chihchun is now known as chihchun_afk [06:13] mvo: good morning [06:13] hey zyga-ubuntu, good morning [06:13] mvo: could I ask you for a 2nd review? [06:14] zyga-ubuntu: sure [06:14] zyga-ubuntu: what branch? [06:14] https://github.com/snapcore/snapd/pull/3621 [06:14] PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns [06:14] jdstrand gave me a +1 but it's a huge branch and I'd like an extra look [06:15] just in case we missed something over the months [06:15] ok [06:16] * zyga-ubuntu edits the commit message there [06:17] PR snapd#3905 closed: tests: add new test that checks that the compat snapd-xdg-open works [06:17] PR snapd#3920 closed: snap-confine: improve error message if core/u-core cannot be found [06:17] zyga-ubuntu: I go over the queue right now and will take extra time for your Pr === chihchun_afk is now known as chihchun [06:24] mvo: thank you! [06:40] PR snapd#3943 closed: tests: fix ubuntu core services [06:41] PR snapd#3930 closed: cmd/snap-repair: integrate root public keys for repairs [06:42] hrm, hrm, artful cups-control-test seems to be broken everywhere [06:42] PR snapd#3940 closed: dirs: fix classic support detection [06:44] zyga-ubuntu: 3939 is still relevant in the light of yesterdays discussion, right? [06:44] I think so [06:45] though [06:45] not sure if we should land it now or add the ConnectedPlug and the other thing [06:45] mvo: one thing that doesn't match is the sequencing [06:46] zyga-ubuntu: ok, lets wait for pawel then, it just has two +1 so I was tempted :) [06:46] mvo: as gustavo outlined a sequence that has this way down, as step 5 [06:47] hi, yes, in light of yesterday discussion I think it's simple but premature [06:48] seems travis had a big queue, seeing things still waiting from yesterday night [06:49] pedronis: yes, though you can easily start spread locally to test stuff in anticipation [06:49] I want to land stuff [06:49] yes, don't we all [06:50] * zyga-ubuntu has much better mood today [06:50] this is all repair stuff, it has no spread tests so far, so your comment is irrelevant either way [06:51] pedronis: in that case I'm sorry :/ [06:53] I'm even not quite sure how to run spread tests for it [06:55] PR snapd#3936 closed: data/completion: small tweak to snap completion snippet [06:56] mvo: #3925 can be merged now , not surw if we want to merge it or squash it though [06:56] PR #3925: snap-repair: implement `snap-repair {done,skip,retry}` [06:58] pedronis: I have a look, 3935 is almost ready one tests needs tweaking (see PR) [06:58] mvo: it's the spread test that testeds it did nothing [06:59] mvo: I fear we just need to kill it, we could have a write a fake service but the end result wouldn't be that different from the integrationy unit test [06:59] pedronis: yeah, just kill it [06:59] PR snapd#3925 closed: snap-repair: implement `snap-repair {done,skip,retry}` [07:03] PR snapd#3931 closed: interfaces/builtin: allow receiving dbus messages [07:04] PR snapd#3918 closed: hooks: substitute env vars when executing hooks [07:04] PR snapd#3926 closed: snap: implement `snap {repair,repairs}` and pass-through to snap-repair [07:11] zyga-ubuntu: 3807 looks like it needs some test tweaks [07:17] mvo: looking [07:17] ah, exellent [07:17] CE asks about that often [07:17] * zyga-ubuntu looks [07:20] good morning, snappy [07:24] indeed, though it might rain later [07:39] mvo: I was looking at #3934 , it seems the rework to make WriteOutput/ScriptIndented to return error and make the caller deal isn't finished [07:39] PR #3934: snap-repair: implement `snap-repair {list,show}` [07:42] mvo: commented in the PR as well [07:43] otherwise it would be landable I think [07:44] pedronis: uh, sorry for this, I fix that in a bit [07:48] mvo: btw, work to expose base in the store api has started [07:48] but you might have been pinged already about that [07:51] pedronis: yes [07:51] hmm [07:52] "interface-cups-control" is a bit broken [07:52] zyga-ubuntu: yes, only in artful [08:00] mvo: in #3933 we need to ignore if the symlink already exists [08:00] PR #3933: snap-repair: make `repair` binary available for repair scripts [08:01] or remove and recreate [08:04] pedronis: aha, thanks for this, I check if the symlink exists but there is of course the TOCTOU issue, I fix accordingly. good catch [08:09] pedronis: 3934 also shows the error cases are under-tested, I fix that now too [08:10] well some other tests failed [08:10] but yes [08:12] pedronis: untested and buggy, once I add tests they show. oh well, tests ftw [08:19] PR snapd#3901 closed: snap-seccomp: run secondary-arch tests via gcc-multilib [08:34] zyga-ubuntu, mvo hey, any idea why .deb build fails on newly added man page like this http://pastebin.ubuntu.com/25578293/ ? Note the new manpage gets created in packaging/.../tmp [08:35] pstolowski: looking [08:35] pstolowski: is the PR updated? [08:35] pstolowski: typically man pages are compressed [08:36] pstolowski: so maybe you need to change the rule to 1* or 1.gz or similar [08:38] zyga-ubuntu, I think I followed all the patterns of snap-confine.5, also updated debian packaging files but apparently there is still somthin magic happening somewhere [08:38] zyga-ubuntu, PR updated now [08:40] pstolowski: let me look quickly [08:40] aha, I think I see it [08:43] pstolowski: pushing [08:43] (just letting tests finish actually) [08:45] zyga-ubuntu, what was it? [08:45] pstolowski: needless rule [08:45] you'll see in a moment [08:46] k [08:48] pstolowski: pushed now [08:49] zyga-ubuntu, I see.. hmm interesting. let me test [08:49] pstolowski: I tested locally [08:49] and spread will test for other systems [08:53] mvo: this is a bizarre failure: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/i386/s/snapd/20170920_081905_d1ef4@/log.gz epoll failing [08:55] pedronis: hm, yes, artful [08:56] that's a EBADF btw [08:56] ?? [08:59] mvo: are we forgetting to stop a mock server ? so weird fork interaction? [08:59] pedronis: 9 is EBADF [08:59] zyga-ubuntu: I just wrote that [09:00] s/so/some/ [09:00] right, I thought you were asking for confirmation (because of the ?? below) [09:00] no, just wondering how the go runtimee got one [09:00] memory corruption? [09:04] it's also i386 fwiw [09:07] zyga-ubuntu, it builds fine indeed, thanks! [09:07] zyga-ubuntu, I now need to tweak the formatting, it doesn't look as expected yet [09:10] pstolowski: you can test it locally easily [09:10] pstolowski: just open with man [09:14] zyga-ubuntu, yeah, just struggling with rst, is it documented anywhere? [09:15] zyga-ubuntu, nvm, found some docs [09:15] pstolowski: look at other man pages [09:15] pstolowski: there's very litte syntax to use [09:16] zyga-ubuntu, indeed, but it doesn't seem to like indentation in my {.. json snippet for example [09:20] zyga-ubuntu, ok, nailed it [09:21] pstolowski: \o/ [09:21] diddledan, wow, thats quite a snapcraft.yaml (my test one only used the existing debs an a lot of hackery around them) [09:27] zyga-ubuntu, k, pushed, adressing your comments [09:30] thank you [09:30] ... and I just realized it will need an update when #3852 lands ;) [09:30] PR #3852: hooks: commands for controlling own services from snapctl [09:30] but that's fine, let's just land [09:38] diddledan: ogra_ joedborg we're prepping a doc which captures the 'assumed knowledge' (bugs/lack of docs) 'we' (snapcrafting people) have when making snaps. Could you take a look and add anything you know you do which is probably a bug or not in a doc anywhere? [09:39] diddledan: ogra_ joedborg https://docs.google.com/spreadsheets/d/1Ii1Q3MFY1W2Tt__JB4sZ05CzP05TwDgB4hN8Z6fR1Hw/edit#gid=0 [09:39] (so we can turn these janky things into bugs/docs) [09:40] popey: will do! [09:40] thanks [09:45] ogra_: i just tested the daily snapdragon image, and it has the same problem as the 'old' rpi images - no snaps are listed [09:45] $ snap list [09:45] No snaps are installed yet. Try "snap install hello-world". [09:45] ogra_: it's the current daily FWIW [09:48] pstolowski: a question about https://github.com/snapcore/snapd/pull/3915/files#diff-a058ac805f223376d159acc796573e68R175 - do we have a test for this case? i.e. when can it happen? I am currently poking at this code a bit and was wondering about this case [09:48] PR #3915: cmd/snap: return empty document if snap has no configuration [09:53] hrm, hrm, master broken in debian-unstable runner_test:296 [09:54] mvo, looking [09:55] I see it [09:55] runner_test.go:390: [09:55] c.Assert(err, Equals, repair.ErrRepairNotModified) [09:55] ... obtained *url.Error = &url.Error{Op:"Get", URL:"http://127.0.0.1:43035/repairs/canonical/2", Err:(*net.OpError)(0xc420010640)} ("Get http://127.0.0.1:43035/repairs/canonical/2: dial tcp 127.0.0.1:43035: i/o timeout") [09:55] ... expected *errors.errorString = &errors.errorString{s:"repair was not modified"} ("repair was not modified") [09:55] hmmm [09:56] why on debian and not here though [09:57] zyga-ubuntu: yeah, also I tried to run tests with go 1.9 from the go snap and got no error [09:58] I'm waiting for debian to boot but no ideas yet [09:58] especially, why here, other tests also use mock server [09:58] could it be timing? [09:58] 5 retries [09:58] 1ms exponential [09:59] up to one second [09:59] pstolowski: context is https://github.com/snapcore/snapd/compare/master...mvo5:cmd-get-tweaks?expand=1 which was a bit of an experiment to get rid of some of the nesting in get (not sure if you like it or not, probably best to look at the resulting file not the diff) [10:03] mvo: my guess is debian kernel scheduling [10:03] * zyga-ubuntu cries whenever we use timing-based tests [10:06] mvo: same epollwait problem on zesty, it seems a real issue somehow [10:06] mvo: I wonder what is happening: https://docs.google.com/document/d/1_8n09MPn8JHOyD6VrnLVcMJUvLFKeirCSayY6iEDD5w/edit# [10:09] mvo: so... it just passed for me on linode [10:09] hmmm [10:14] oops [10:14] mvo: wrong link [10:14] mvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170920_095013_d1ef4@/log.gz [10:17] pedronis: looking at https://github.com/golang/go/issues/11498 (which is arguably an accidental match) it looks like we are closing something twice and hence killing an already reused FD number [10:17] mvo, added one more test case, however it's tricky to fully cover this case because 'isTerminal' prevents it - futher down we default to json output + warning on stderr instead of list because of that [10:18] niemeyer: added a couple of questions to the epochs topic, if you could when you can [10:18] ogra_: ah, never mind, apparently changing sd card fixed the 'snap list' issue [10:19] * Chipaca considers making epochs be written only in roman numerals [10:19] zyga-ubuntu: mvo: there is code that closes statusW twice [10:19] could that be it? === chihchun is now known as chihchun_afk [10:19] pedronis: yes [10:19] pedronis: that can definitely cause this [10:20] I thought the runtime would check for something [10:20] pedronis: I don't think it can [10:20] pedronis: ohhh, that sounds like it [10:20] pedronis: well, in pure go world it could [10:20] pedronis: reset the fd to -1 or similar after closing [10:20] that's a safe way to do it [10:21] zyga-ubuntu: I mean have a flag around things, but maybe it doesn't [10:21] * zyga-ubuntu nods [10:22] pedronis: are you making a PR to change this? [10:24] mvo, nb, thanks for looking at refactoring this.. the logic good convoluted indeed, i'm having hard time every time looking at it [10:24] zyga-ubuntu: ? [10:24] pedronis: "there is code that closes statusW twice" [10:24] pstolowski: yeah, its a bit tricky but of course there is a lot of conditions [10:24] zyga-ubuntu: it's probably something for mvo to fix on the failing branch [10:25] pstolowski: anyway I might push something very small and see if I can go from there [10:25] zyga-ubuntu: mvo wrote that code , I'm not even sure I remember why the code is like it is [10:25] mvo, on the positive side, we have good test coverage [10:25] pedronis: sure [10:25] pstolowski: yeah, that makes it very nice to work on the refactor \o/ [10:31] pedronis: I'm looking at this code now [10:39] mvo: does this make any sense to you? http://pastebin.ubuntu.com/25578825/ [10:41] zyga-ubuntu: not right away [10:50] pstolowski: 3915 can go in once tests are green, I send a small PR your way for review, once we are happy I can do a proper pr [10:51] pedronis: I fixed the double close, thanks for catching this [10:57] mvo: hopefully it was that [10:57] +1 [10:59] mvo: other unit test failure here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170920_100802_d1ef4@/log.gz [10:59] * zyga-ubuntu -> tea [10:59] something about TestRepairHasCorrectPath [10:59] but seems a timing issue [11:00] or something [11:00] bit confused [11:01] ppisati, well, keep an eye on it ... if changing the Sd fixes it there is something weird ... note thuogh that the snap list issue also typically happens if the SD was mounted during dd [11:02] Heya [11:02] Chipaca: Looking [11:03] zyga-ubuntu: something very weird going on there [11:03] mvo, sounds good,thanks! === JoshStrobl|zzz is now known as JoshStrobl [11:15] * sergiusens waves good morning [11:18] mvo: the other branch also has double close problems [11:18] bit of a whack-a-mole landing these last bits [11:18] :/ [11:20] PR snapcraft#1555 closed: store: switch to new endpoints [11:36] mvo: is it annoying to split out the statusW fix to its own PR ? [11:41] I'm getting a bit confused by all the autopkgtest red in your PRs [11:45] I wonder why we didn't notice it before as well, that code is already on master :/ [11:48] mvo, hey [11:48] still see + snap install --edge test-snapd-upower-observe-consumer [11:48] error: snap "test-snapd-upower-observe-consumer" not found (at least in channel [11:48] "edge") [11:51] pedronis: no, I can split it out, no problem [11:51] thank you [11:51] cachio: checking [11:52] mvo: it seems also that we have issues with TestRepairHasCorrect path, seems timeout is too low and also something is off on some releases [11:52] s/Correct path/CorrectPath/ [11:55] cachio: fixing this now [11:56] mvo, tx [11:57] mvo, i was researching yesterday the autoimport service issue [11:57] mvo, it is failing when the device is using user assertions to create users by default [11:58] mvo, does it make sense? [11:58] mzanetti are you around, mvo and pedronis are trying to figure out how to fix the problem [12:01] PR snapd#3915 closed: cmd/snap: return empty document if snap has no configuration [12:01] PR snapd#3944 opened: snap-repair: fix double close of statusW (thanks to Samuele) [12:01] mvo: thank you, let's see how that goes and then we can merge it in the others [12:02] popey: I've just requested access to the google doc - my account is @bowlhat.net [12:02] so british ! [12:02] :-p [12:03] PR snapd#3945 opened: snap: refactor cmdGet.Execute() [12:03] diddledone! [12:03] yey [12:03] pedronis: +1 [12:03] pedronis: thanks a lot for baby sitting these branches \o/ [12:06] cachio: *now* it should be there, sorry, amd64 and arm64 are just too close :/ I overlooked it [12:07] cachio: it being test-snapd-upower-observer-consumer [12:07] mvo, great, tx [12:07] mvo, i am registering the device now but i have the same errror with the ubuntu-core-services [12:08] mvo, that will be fixed once we switched to compiler names for arches ... aaaargh64 isnt that close to x86_64 :) [12:08] mvo, not sure if I need to refresh the core after that [12:10] ogra_: will we switch? it seems like we trade amd64/arm64 against x86/x86_64 which is arguable a bit better [12:10] i dont know, i just know there was a discussion started about it [12:11] ondra, mzanetti: quick question, do you have the dns error just for refresh? or for any snapd network operation? [12:12] cachio: sorry, I have too many parallel conversations right now, what is the same error for ubuntu-core-services? it means auto-import did not succeed but failed? and we have no log or any indication in what way it failed :( ? [12:13] well, I have, 2 minutes, but it is really short the log [12:13] cachio: no rush, take your time :) [12:15] mvo, what I saw is that when I use a user assetion with the image that test fails [12:15] and if I run manually console conf to register hte user, the test pass [12:16] cachio: so the user assertion is valid? but does not work on first-boot? [12:16] for your eyes only https://forum.snapcraft.io/t/proposal-additional-package-sources/2199 [12:16] pedronis: 3933 is ready now but needs a second review === ShalokShalom_ is now known as ShalokShalom [12:17] mvo, this is what I have https://paste.ubuntu.com/25579273/ [12:17] cachio: that is ok Sep 19 18:38:05 localhost.localdomain snap[1072]: error: cannot create user: device already managed [12:17] cachio: I mean the error is expected if the machine is already managed [12:18] mvo, Failed to start Auto import assertions from block devices. [12:18] mvo, not sure if it is related to the previous error in the log [12:19] cachio: yeah, its the followup on the previous error [12:20] cachio: are the test machines only configured this way that they have this auto-import assertion? if so we may just need to blacklist this test or just check that it was run at all, regardless of ok or not [12:20] (the later is probably the best choice) [12:20] ok [12:21] I am updating the code of the machines setup to first register a valid user and then refresh the core, does could help? [12:21] mvo, ~ [12:23] mvo: there were failures like this in #3933: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170920_100802_d1ef4@/log.gz [12:23] PR #3933: snap-repair: make `repair` binary available for repair scripts [12:23] mvo: as I said TestRepairHasCorrectPath needs some tweak [12:24] cachio: probably, if the boot that does the tests does not have the block devices things should work [12:25] pedronis: ta [12:25] mvo: I saw it fail also in another different way, but that might be the other branch [12:25] where the new code is not there [12:26] mvo: we probably need to land #3944 #3933 and #3934 in that order [12:26] PR #3944: snap-repair: fix double close of statusW (thanks to Samuele) [12:26] PR #3933: snap-repair: make `repair` binary available for repair scripts [12:26] PR #3934: snap-repair: implement `snap-repair {list,show}` [12:27] mvo: otherwise is a bit too hard to tell if we solved the issues or not [12:27] pedronis: yeah [12:29] pedronis: I just pushed a fix for 3933, this should be good now, once that is green I merge the fix into the other branches [12:29] pedronis: sorry for the back-and-forth [12:31] zyga-ubuntu: yay, 3807 looks ready we just need to find a second reviewer [12:31] zyga-ubuntu: actually jdstrand said "looks fine" so… [12:31] mvo: yes, I asked jamie to review [12:31] oh, he did? [12:31] ah [12:31] I see, earlier [12:32] well, let's merge it, I can conjure the fix for NFS that CE requested [12:32] zyga-ubuntu: yeah, very early [12:32] zyga-ubuntu: done [12:32] great, thank you! [12:32] PR snapd#3807 closed: cmd/snap-confine,packaging: import snapd-generated policy [12:32] * zyga-ubuntu gave up debugging repair tests on debian [12:32] zyga-ubuntu: thats sad, it means I will have to do it [12:33] those failures were strange [12:33] do you think they are transient? is master ok again? [12:33] some seemed to be about the fake directories [12:33] doesn't make much sense [12:34] mvo: they were failing each time the same way for me (interactively) [12:37] anyway repair tests are a bit in a strange state atm [12:37] I would wait to get a couple more things landed (with fixes) [12:37]