[01:44] <sergiusens> elopio yeah, incomplete as I tend to add examples
[01:45] <sergiusens> and ack on the other
[01:45] <sergiusens> elopio btw, snapcraft#1555 has been updated
[01:45] <mup> PR snapcraft#1555: store: switch to new endpoints <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>
[01:49] <kyrofa> sergiusens, keep an eye on snapcraft#1549, it should be green any moment
[01:49] <mup> PR snapcraft#1549: plugins: extract pip from python plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1549>
[01:49] <kyrofa> It took virtually all day
[01:49] <sergiusens> kyrofa funny, I just looked to see if it was ready 🚱
[01:50] <kyrofa> We hammered travis today
[01:56] <sergiusens> kyrofa do you have the next PR in line ready?
[02:01] <mwhudson> what happened here??https://launchpadlibrarian.net/337615189/buildlog_snap_ubuntu_artful_ppc64el_subiquity_BUILDING.txt.gz
[02:06] <sergiusens> mwhudson did that work with cleanbuild?
[02:09] <mup> PR snapcraft#1549 closed: plugins: extract pip from python plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1549>
[02:24] <mwhudson> sergiusens: all the other arches built
[02:37] <sergiusens> 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] <mwhudson> sergiusens: yes, it usually builds fine on ppc64el :)
[02:37] <mwhudson> i suspect some kind of networking glitch but it's a bit silent
[02:37] <mwhudson> i guess i'll try again
[02:38] <sergiusens> mwhudson it seems to have been common today, I had a weird error earlier in a lxd container too and ev was reporting similarly
[02:54] <mwhudson> hmm reproducible it seems
[02:54] <mwhudson> (aka it failed three times in a row)
[02:58] <mup> Issue snapcraft#1452 closed: machine information <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1452>
[02:58] <mup> PR snapcraft#1529 closed: recording: record the packages installed in the machine <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1529>
[05:40] <zyga-ubuntu> good morning
[06:03] <zyga-ubuntu> hey morphis
[06:03] <zyga-ubuntu> how are you doing
[06:13] <zyga-ubuntu> mvo: good morning
[06:13] <mvo> hey zyga-ubuntu, good morning
[06:13] <zyga-ubuntu> mvo: could I ask you for a 2nd review?
[06:14] <mvo> zyga-ubuntu: sure
[06:14] <mvo> zyga-ubuntu: what branch?
[06:14] <zyga-ubuntu> https://github.com/snapcore/snapd/pull/3621
[06:14] <mup> PR #3621: cmd/snap-{confine,update-ns}: apply mount profiles using snap-update-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/3621>
[06:14] <zyga-ubuntu> jdstrand gave me a +1 but it's a huge branch and I'd like an extra look
[06:15] <zyga-ubuntu> just in case we missed something over the months
[06:15] <mvo> ok
[06:16]  * zyga-ubuntu edits the commit message there
[06:17] <mup> PR snapd#3905 closed: tests: add new test that checks that the compat snapd-xdg-open works <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3905>
[06:17] <mup> PR snapd#3920 closed: snap-confine: improve error message if core/u-core cannot be found <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3920>
[06:17] <mvo> zyga-ubuntu: I go over the queue right now and will take extra time for your Pr
[06:24] <zyga-ubuntu> mvo: thank you!
[06:40] <mup> PR snapd#3943 closed: tests: fix ubuntu core services  <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3943>
[06:41] <mup> PR snapd#3930 closed: cmd/snap-repair: integrate root public keys for repairs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3930>
[06:42] <mvo> hrm, hrm, artful cups-control-test seems to be broken everywhere
[06:42] <mup> PR snapd#3940 closed: dirs: fix classic support detection <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3940>
[06:44] <mvo> zyga-ubuntu: 3939 is still relevant in the light of yesterdays discussion, right?
[06:44] <zyga-ubuntu> I think so
[06:45] <zyga-ubuntu> though
[06:45] <zyga-ubuntu> not sure if we should land it now or add the ConnectedPlug and the other thing
[06:45] <zyga-ubuntu> mvo: one thing that doesn't match is the sequencing
[06:46] <mvo> zyga-ubuntu: ok, lets wait for pawel then, it just has two +1 so I was tempted :)
[06:46] <zyga-ubuntu> mvo: as gustavo outlined a sequence that has this way down, as step 5
[06:47] <pedronis> hi, yes, in light of yesterday discussion I think it's simple but premature
[06:48] <pedronis> seems travis had a big queue, seeing things still waiting from yesterday night
[06:49] <zyga-ubuntu> pedronis: yes, though you can easily start spread locally to test stuff in anticipation
[06:49] <pedronis> I want to land stuff
[06:49] <zyga-ubuntu> yes, don't we all
[06:50]  * zyga-ubuntu has much better mood today
[06:50] <pedronis> this is all repair stuff, it has no spread tests so far, so your comment is irrelevant either way
[06:51] <zyga-ubuntu> pedronis: in that case I'm sorry :/
[06:53] <pedronis> I'm even not quite sure how to run spread tests for it
[06:55] <mup> PR snapd#3936 closed: data/completion: small tweak to snap completion snippet <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3936>
[06:56] <pedronis> mvo: #3925 can be merged now , not surw if we want to merge it or squash it though
[06:56] <mup> PR #3925: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3925>
[06:58] <mvo> pedronis: I have a look, 3935 is almost ready one tests needs tweaking (see PR)
[06:58] <pedronis> mvo: it's the spread test that testeds it did nothing
[06:59] <pedronis> 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] <mvo> pedronis: yeah, just kill it
[06:59] <mup> PR snapd#3925 closed: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3925>
[07:03] <mup> PR snapd#3931 closed: interfaces/builtin: allow receiving dbus messages <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3931>
[07:04] <mup> PR snapd#3918 closed: hooks: substitute env vars when executing hooks <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3918>
[07:04] <mup> PR snapd#3926 closed: snap: implement `snap {repair,repairs}` and pass-through to snap-repair <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3926>
[07:11] <mvo> zyga-ubuntu: 3807 looks like it needs some test tweaks
[07:17] <zyga-ubuntu> mvo: looking
[07:17] <zyga-ubuntu> ah, exellent
[07:17] <zyga-ubuntu> CE asks about that often
[07:17]  * zyga-ubuntu looks
[07:20] <kalikiana> good morning, snappy
[07:24] <zyga-ubuntu> indeed, though it might rain later
[07:39] <pedronis> 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] <mup> PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
[07:42] <pedronis> mvo: commented in the PR as well
[07:43] <pedronis> otherwise it would be landable I think
[07:44] <mvo> pedronis: uh, sorry for this, I fix that in a bit
[07:48] <pedronis> mvo: btw, work to expose base in the store api has started
[07:48] <pedronis> but you might have been pinged already about that
[07:51] <mvo> pedronis: yes
[07:51] <zyga-ubuntu> hmm
[07:52] <zyga-ubuntu> "interface-cups-control" is a bit broken
[07:52] <mvo> zyga-ubuntu: yes, only in artful
[08:00] <pedronis> mvo: in #3933 we need to ignore if the symlink already exists
[08:00] <mup> PR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
[08:01] <pedronis> or remove and recreate
[08:04] <mvo> 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] <mvo> pedronis: 3934 also shows the error cases are under-tested, I fix that now too
[08:10] <pedronis> well some other tests failed
[08:10] <pedronis> but yes
[08:12] <mvo> pedronis: untested and buggy, once I add tests they show. oh well, tests ftw
[08:19] <mup> PR snapd#3901 closed: snap-seccomp: run secondary-arch tests via gcc-multilib <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3901>
[08:34] <pstolowski> 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] <zyga-ubuntu> pstolowski: looking
[08:35] <zyga-ubuntu> pstolowski: is the PR updated?
[08:35] <zyga-ubuntu> pstolowski: typically man pages are compressed
[08:36] <zyga-ubuntu> pstolowski: so maybe you need to change the rule to 1* or 1.gz or similar
[08:38] <pstolowski> 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] <pstolowski> zyga-ubuntu, PR updated now
[08:40] <zyga-ubuntu> pstolowski: let me look quickly
[08:40] <zyga-ubuntu> aha, I think I see it
[08:43] <zyga-ubuntu> pstolowski: pushing
[08:43] <zyga-ubuntu> (just letting tests finish actually)
[08:45] <pstolowski> zyga-ubuntu, what was it?
[08:45] <zyga-ubuntu> pstolowski: needless rule
[08:45] <zyga-ubuntu> you'll see in a moment
[08:46] <pstolowski> k
[08:48] <zyga-ubuntu> pstolowski: pushed now
[08:49] <pstolowski> zyga-ubuntu, I see.. hmm interesting. let me test
[08:49] <zyga-ubuntu> pstolowski: I tested locally
[08:49] <zyga-ubuntu> and spread will test for other systems
[08:53] <pedronis> 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] <mvo> pedronis: hm, yes, artful
[08:56] <pedronis> that's a EBADF btw
[08:56] <pedronis> ??
[08:59] <pedronis> mvo: are we forgetting to stop a mock server ? so weird fork interaction?
[08:59] <zyga-ubuntu> pedronis: 9 is EBADF
[08:59] <pedronis> zyga-ubuntu: I just wrote that
[09:00] <pedronis> s/so/some/
[09:00] <zyga-ubuntu> right, I thought you were asking for confirmation (because of the ?? below)
[09:00] <pedronis> no, just wondering how the go runtimee got one
[09:00] <pedronis> memory corruption?
[09:04] <pedronis> it's also i386 fwiw
[09:07] <pstolowski> zyga-ubuntu, it builds fine indeed, thanks!
[09:07] <pstolowski> zyga-ubuntu, I now need to tweak the formatting, it doesn't look as expected yet
[09:10] <zyga-ubuntu> pstolowski: you can test it locally easily
[09:10] <zyga-ubuntu> pstolowski: just open with man
[09:14] <pstolowski> zyga-ubuntu, yeah, just struggling with rst, is it documented anywhere?
[09:15] <pstolowski> zyga-ubuntu, nvm, found some docs
[09:15] <zyga-ubuntu> pstolowski: look at other man pages
[09:15] <zyga-ubuntu> pstolowski: there's very litte syntax to use
[09:16] <pstolowski> zyga-ubuntu, indeed, but it doesn't seem to like indentation in my {.. json snippet for example
[09:20] <pstolowski> zyga-ubuntu, ok, nailed it
[09:21] <zyga-ubuntu> pstolowski: \o/
[09:21] <ogra_> diddledan, wow, thats quite  a snapcraft.yaml (my test one only used the existing debs an a lot of hackery around them)
[09:27] <pstolowski> zyga-ubuntu, k, pushed, adressing your comments
[09:30] <zyga-ubuntu> thank you
[09:30] <pstolowski> ... and I just realized it will need an update when #3852 lands ;)
[09:30] <mup> PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>
[09:30] <pstolowski> but that's fine, let's just land
[09:38] <popey> 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] <popey> diddledan: ogra_ joedborg  https://docs.google.com/spreadsheets/d/1Ii1Q3MFY1W2Tt__JB4sZ05CzP05TwDgB4hN8Z6fR1Hw/edit#gid=0
[09:39] <popey> (so we can turn these janky things into bugs/docs)
[09:40] <joedborg> popey: will do!
[09:40] <popey> thanks
[09:45] <ppisati> 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] <ppisati> $ snap list
[09:45] <ppisati> No snaps are installed yet. Try "snap install hello-world".
[09:45] <ppisati> ogra_: it's the current daily FWIW
[09:48] <mvo> 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] <mup> PR #3915: cmd/snap: return empty document if snap has no configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/3915>
[09:53] <mvo> hrm, hrm, master broken in debian-unstable runner_test:296
[09:54] <pstolowski> mvo, looking
[09:55] <zyga-ubuntu> I see it
[09:55] <zyga-ubuntu> runner_test.go:390:
[09:55] <zyga-ubuntu>     c.Assert(err, Equals, repair.ErrRepairNotModified)
[09:55] <zyga-ubuntu> ... 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] <zyga-ubuntu> ... expected *errors.errorString = &errors.errorString{s:"repair was not modified"} ("repair was not modified")
[09:55] <zyga-ubuntu> hmmm
[09:56] <zyga-ubuntu> why on debian and not here though
[09:57] <mvo> zyga-ubuntu: yeah, also I tried to run tests with go 1.9 from the go snap and got no error
[09:58] <zyga-ubuntu> I'm waiting for debian to boot but no ideas yet
[09:58] <zyga-ubuntu> especially, why here, other tests also use mock server
[09:58] <zyga-ubuntu> could it be timing?
[09:58] <zyga-ubuntu> 5 retries
[09:58] <zyga-ubuntu> 1ms exponential
[09:59] <zyga-ubuntu> up to one second
[09:59] <mvo> 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] <zyga-ubuntu> mvo: my guess is debian kernel scheduling
[10:03]  * zyga-ubuntu cries whenever we use timing-based tests
[10:06] <pedronis> mvo: same epollwait problem on zesty, it seems a real issue somehow
[10:06] <pedronis> mvo: I wonder what is happening:  https://docs.google.com/document/d/1_8n09MPn8JHOyD6VrnLVcMJUvLFKeirCSayY6iEDD5w/edit#
[10:09] <zyga-ubuntu> mvo: so... it just passed for me on linode
[10:09] <zyga-ubuntu> hmmm
[10:14] <pedronis> oops
[10:14] <pedronis> mvo: wrong link
[10:14] <pedronis> 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] <zyga-ubuntu> 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] <pstolowski> 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] <Chipaca> niemeyer: added a couple of questions to the epochs topic, if you could when you can
[10:18] <ppisati> 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] <pedronis> zyga-ubuntu: mvo: there is code that closes statusW twice
[10:19] <pedronis> could that be it?
[10:19] <zyga-ubuntu> pedronis: yes
[10:19] <zyga-ubuntu> pedronis: that can definitely cause this
[10:20] <pedronis> I thought the runtime would check for something
[10:20] <zyga-ubuntu> pedronis: I don't think it can
[10:20] <mvo> pedronis: ohhh, that sounds like it
[10:20] <zyga-ubuntu> pedronis: well, in pure go world it could
[10:20] <zyga-ubuntu> pedronis: reset the fd to -1 or similar after closing
[10:20] <zyga-ubuntu> that's a safe way to do it
[10:21] <pedronis> zyga-ubuntu: I mean have a flag around things, but maybe it doesn't
[10:21]  * zyga-ubuntu nods
[10:22] <zyga-ubuntu> pedronis: are you making a PR to change this?
[10:24] <pstolowski> 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] <pedronis> zyga-ubuntu: ?
[10:24] <zyga-ubuntu> pedronis: "there is code that closes statusW twice"
[10:24] <mvo> pstolowski: yeah, its a bit tricky but of course there is a lot of conditions
[10:24] <pedronis> zyga-ubuntu: it's probably something for mvo to fix on the failing branch
[10:25] <mvo> pstolowski: anyway I might push something very small and see if I can go from there
[10:25] <pedronis> zyga-ubuntu: mvo wrote that code , I'm not even sure I remember why the code is like it is
[10:25] <pstolowski> mvo, on the positive side, we have good test coverage
[10:25] <mvo> pedronis: sure
[10:25] <mvo> pstolowski: yeah, that makes it very nice to work on the refactor \o/
[10:31] <mvo> pedronis: I'm looking at this code now
[10:39] <zyga-ubuntu> mvo: does this make any sense to you? http://pastebin.ubuntu.com/25578825/
[10:41] <mvo> zyga-ubuntu: not right away
[10:50] <mvo> 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] <mvo> pedronis: I fixed the double close, thanks for catching this
[10:57] <pedronis> mvo: hopefully it was that
[10:57] <mvo> +1
[10:59] <pedronis> 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] <pedronis> something about TestRepairHasCorrectPath
[10:59] <pedronis> but seems a timing issue
[11:00] <pedronis> or something
[11:00] <pedronis> bit confused
[11:01] <ogra_> 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] <niemeyer> Heya
[11:02] <niemeyer> Chipaca: Looking
[11:03] <pedronis> zyga-ubuntu: something very weird going on there
[11:03] <pstolowski> mvo, sounds good,thanks!
[11:15]  * sergiusens waves good morning
[11:18] <pedronis> mvo: the other branch also has double close problems
[11:18] <pedronis> bit of a whack-a-mole landing these last bits
[11:18] <pedronis> :/
[11:20] <mup> PR snapcraft#1555 closed: store: switch to new endpoints <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>
[11:36] <pedronis> mvo: is it annoying to split out the statusW fix to its own PR ?
[11:41] <pedronis> I'm getting a bit confused by all the autopkgtest red in your PRs
[11:45] <pedronis> I wonder why we didn't notice it before as well, that code is already on master :/
[11:48] <cachio> mvo, hey
[11:48] <cachio> still see + snap install --edge test-snapd-upower-observe-consumer
[11:48] <cachio> error: snap "test-snapd-upower-observe-consumer" not found (at least in channel
[11:48] <cachio>        "edge")
[11:51] <mvo> pedronis: no, I can split it out, no problem
[11:51] <pedronis> thank you
[11:51] <mvo> cachio: checking
[11:52] <pedronis> 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] <pedronis> s/Correct path/CorrectPath/
[11:55] <mvo> cachio: fixing this now
[11:56] <cachio> mvo, tx
[11:57] <cachio> mvo, i was researching yesterday the autoimport service issue
[11:57] <cachio> mvo, it is failing when the device is using user assertions to create users by default
[11:58] <cachio> mvo, does it make sense?
[11:58] <ondra> mzanetti are you around, mvo and pedronis are trying to figure out how to fix the problem
[12:01] <mup> PR snapd#3915 closed: cmd/snap: return empty document if snap has no configuration <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3915>
[12:01] <mup> PR snapd#3944 opened: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3944>
[12:01] <pedronis> mvo: thank you, let's see how that goes and then we can merge it in the others
[12:02] <diddledan> popey: I've just requested access to the google doc - my account is @bowlhat.net
[12:02] <ogra_> so british !
[12:02] <diddledan> :-p
[12:03] <mup> PR snapd#3945 opened: snap: refactor cmdGet.Execute() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3945>
[12:03] <popey> diddledone!
[12:03] <diddledan> yey
[12:03] <mvo> pedronis: +1
[12:03] <mvo> pedronis: thanks a lot for baby sitting these branches \o/
[12:06] <mvo> cachio: *now* it should be there, sorry, amd64 and arm64 are just too close :/ I overlooked it
[12:07] <mvo> cachio: it being test-snapd-upower-observer-consumer
[12:07] <cachio> mvo, great, tx
[12:07] <cachio> mvo, i am registering the device now but i have the same errror with the ubuntu-core-services
[12:08] <ogra_> mvo, that will be fixed once we switched to compiler names for arches ... aaaargh64 isnt that close to x86_64 :)
[12:08] <cachio> mvo, not sure if I need to refresh the core after that
[12:10] <mvo> ogra_: will we switch? it seems like we trade amd64/arm64 against x86/x86_64 which is arguable a bit better
[12:10] <ogra_> i dont know, i just know there was a discussion started about it
[12:11] <mvo> ondra, mzanetti: quick question, do you have the dns error just for refresh? or for any snapd network operation?
[12:12] <mvo> 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] <cachio> well, I have, 2 minutes, but it is really short the log
[12:13] <mvo> cachio: no rush, take your time :)
[12:15] <cachio> mvo, what I saw is that when I use a user assetion with the image that test fails
[12:15] <cachio> and if I run manually console conf to register hte user, the test pass
[12:16] <mvo> cachio: so the user assertion is valid? but does not work on first-boot?
[12:16] <diddledan> for your eyes only https://forum.snapcraft.io/t/proposal-additional-package-sources/2199
[12:16] <mvo> pedronis: 3933 is ready now but needs a second review
[12:17] <cachio> mvo, this is what I have https://paste.ubuntu.com/25579273/
[12:17] <mvo> cachio: that is ok Sep 19 18:38:05 localhost.localdomain snap[1072]: error: cannot create user: device already managed
[12:17] <mvo> cachio: I mean the error is expected if the machine is already managed
[12:18] <cachio> mvo,  Failed to start Auto import assertions from block devices.
[12:18] <cachio> mvo, not sure if it is related to the previous error in the log
[12:19] <mvo> cachio: yeah, its the followup on the previous error
[12:20] <mvo> 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] <mvo> (the later is probably the best choice)
[12:20] <cachio> ok
[12:21] <cachio> 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] <cachio> mvo, ~
[12:23] <pedronis> 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] <mup> PR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
[12:23] <pedronis> mvo: as I said TestRepairHasCorrectPath needs some tweak
[12:24] <mvo> cachio: probably, if the boot that does the tests does not have the block devices things should work
[12:25] <mvo> pedronis: ta
[12:25] <pedronis> mvo: I saw it fail also in another different way, but that might be the other branch
[12:25] <pedronis> where the new code is not there
[12:26] <pedronis> mvo:  we probably need to land #3944  #3933 and #3934 in that order
[12:26] <mup> PR #3944: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3944>
[12:26] <mup> PR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>
[12:26] <mup> PR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>
[12:27] <pedronis> mvo: otherwise is a bit too hard to tell if we solved the issues or not
[12:27] <mvo> pedronis: yeah
[12:29] <mvo> 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] <mvo> pedronis: sorry for the back-and-forth
[12:31] <mvo> zyga-ubuntu: yay, 3807 looks ready we just need to find a second reviewer
[12:31] <mvo> zyga-ubuntu: actually jdstrand said "looks fine" so…
[12:31] <zyga-ubuntu> mvo: yes, I asked jamie to review
[12:31] <zyga-ubuntu> oh, he did?
[12:31] <zyga-ubuntu> ah
[12:31] <zyga-ubuntu> I see, earlier
[12:32] <zyga-ubuntu> well, let's merge it, I can conjure the fix for NFS that CE requested
[12:32] <mvo> zyga-ubuntu: yeah, very early
[12:32] <mvo> zyga-ubuntu: done
[12:32] <zyga-ubuntu> great, thank you!
[12:32] <mup> PR snapd#3807 closed: cmd/snap-confine,packaging: import snapd-generated policy <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3807>
[12:32]  * zyga-ubuntu gave up debugging repair tests on debian
[12:32] <mvo> zyga-ubuntu: thats sad, it means I will have to do it
[12:33] <pedronis> those failures were strange
[12:33] <mvo> do you think they are transient? is master ok again?
[12:33] <pedronis> some seemed to be about the fake directories
[12:33] <pedronis> doesn't make much sense
[12:34] <zyga-ubuntu> mvo: they were failing each time the same way for me (interactively)
[12:37] <pedronis> anyway repair tests are a bit in a strange state atm
[12:37] <pedronis> I would wait to get a couple more things landed (with fixes)
[12:37] <pedronis> before pursuing that
[12:38]  * zyga-ubuntu nods
[12:44] <sergiusens> hey niemeyer, mind looking at https://forum.snapcraft.io/t/proposal-additional-package-sources/2199/2 ?
[12:55] <niemeyer> sergiusens: Looking
[13:23] <pedronis> mvo: it's not  statusW,  same issues in that branch :/
[13:23] <pedronis> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170920_125631_2e002@/log.gz
[13:24] <pedronis> or at least the change doesn't help
[13:44] <sergiusens> kalikiana do you have a fix lined up to only push snaps into the container if they differ?
[13:46]  * zyga-ubuntu goes to make food and will be back with layouts shortly
[13:46] <mvo> pedronis: yeah, I'm in a debian machine now and I can reproduce it ~50% of the time
[13:46] <mvo> pedronis: also the other errors are super strange
[13:47] <pedronis> mvo: I wonder which change introduced it though, because it appeared recently afaik
[13:47] <pedronis> time to bisect?
[13:47] <mvo> pedronis: yeah, if I don't find anything soon I will bisect
[13:47] <pedronis> also it seems indeed related to new go, because on 1.6 it doesn't seem to fail
[13:47] <mvo> yeah
[13:47] <mvo> or debian
[13:48] <mvo> I see the failure with go1.7.4
[13:48] <mvo> in testing
[13:48] <mvo> debian/testing
[13:48] <mvo> which is the same version that I have on my zesty system
[13:48] <mvo> so its even more mysterious
[13:48] <pedronis> well debian has a newer go,    we see it fail in zesty and artful
[13:48] <mvo> I can not reproduce the failure in my zesty system
[13:48] <zyga-ubuntu> mvo: also works on my artful FYI
[13:48] <pedronis> interesting I seen autopkgtest for zesty fail with that
[13:49] <mvo> so it migt be artful
[13:49] <pedronis> (unless I misremeber)
[13:49] <mvo> 4.9 is debian
[13:49] <mvo> 4.10 is what I have here
[13:49] <mvo> in zesty
[13:49] <mvo> pedronis: oh, interessting, I have a look at the autopkgtests
[13:49] <pedronis> mvo: this is a failure on zesty for example:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170920_131417_2e002@/log.gz
[13:50] <mvo> pedronis: yeah, also kernel 4.10
[13:50] <mvo> pedronis: so strange
[13:51] <sergiusens> kalikiana mind updating this branch https://github.com/snapcore/snapcraft/pull/1382 ?
[13:51] <mup> PR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>
[13:55] <pedronis> mvo: does go test -race tells anything interesting  on debian ?   (nothing interesing on 1.6)
[13:59] <mvo> pedronis: not right now
[13:59] <mvo> pedronis: I mean, no :/
[14:04] <pedronis> mvo: ok, I rememver correctly btw:  at least 1.6 had code such that calling Close twice shouldn't be a problem, at least from the same goroutine
[14:05] <cachio> pstolowski, https://paste.ubuntu.com/25579877/
[14:05] <cachio> this test is failing on edge for ubuntu core
[14:06] <zyga-ubuntu> apparently 15 years later schoolkids still bully kids with longer hair
[14:06] <cachio> pstolowski, is it new? first time i see it fail
[14:06] <pedronis> mvo: so double closing shouldn't be a problem,  later version have more complicated code but the result is the same
[14:07] <pedronis> mvo: calling Close twice should error, not close the descriptor again
[14:07] <zyga-ubuntu> pedronis: is the descriptor copied (as in memcpy) anywhere?
[14:07] <pstolowski> cachio, yes. it's very new, it just landed today or yesterday
[14:07] <pedronis> zyga-ubuntu: ?
[14:07] <pstolowski> cachio, I'll investigate
[14:08] <zyga-ubuntu> pedronis: golang runtime errors aside it means we somehow did close a descriptor that was still in the epoll
[14:08] <pedronis> zyga-ubuntu: yes, but I doubt it's us closing it
[14:08] <pedronis> I fear the runtime
[14:08] <zyga-ubuntu> aha
[14:08] <cachio> pstolowski, nice, we have fast feedback now :)
[14:08] <pedronis> mvo: have you tried print the StatusW/R   descriptor number to see if they even match with what is in the error?
[14:09] <pedronis> zyga-ubuntu: internally when we close a runtime fs it replaces the fd number with -1
[14:09] <pedronis> so the next Close should see that and error
[14:10] <mvo> pedronis: no, I'm working on the other failures right now
[14:10] <pedronis> ok
[14:10] <mvo> pedronis: but thanks for this, I will try that next
[14:15] <mvo> pedronis: I have a new theory, some of the other failures are because tests in autopkgtest runs as root but local run as user
[14:16] <pedronis> missing SetRootDir ?
[14:16] <mvo> pedronis: yeah, or incorrect paths, I'm just look at this
[14:19] <ondra> mvo more update from simon, so 10seconds delay helps, but does not cure it 100%, when they increased time out to 60 seconds, then they are not able to reproduce.
[14:19] <niemeyer> Chipaca: Forgot to mention, but your point about the conflict between snap pack and snap ack is a good one, btw...
[14:20] <sergiusens> mpt mind looking at https://forum.snapcraft.io/t/mechanisms-for-converging-store-and-snap-metadata/2200 ?
[14:20] <niemeyer> Chipaca: Thinking about something else that would be equivalently terse and nice..
[14:20] <ondra> mvo they are wondering if start of it is here https://github.com/snapcore/snapd/blob/release/2.27/httputil/retry.go#L87
[14:20] <Chipaca> niemeyer: yesterday in the standup i said it as well, and somebody proposed an alternative that was nice
[14:20] <Chipaca> but i don't remember it, or who
[14:20] <Chipaca> zyga-ubuntu: was it you?
[14:20] <niemeyer> sergiusens: Per note above, "pack" is probably changing due to the similarity with "ack"
[14:21] <ogra_> snap ack -> snapprove
[14:21] <ogra_> ;)
[14:22] <niemeyer> ogra_: That one has sailed
[14:22] <ogra_> i wasnt serious anyway :)
[14:22] <mvo> pedronis: and I also suspect the epoll issue is root specific for whatever reason
[14:23] <mvo> ondra: I have it on my list but there is amaster failure right now
[14:23] <mup> PR snapd#3946 opened: snap: add new `snap pack` and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3946>
[14:23] <sergiusens> niemeyer ok, it wasn't clear to me if you were intending to moving the "packing/assembling" logic back to the snap command though (back in Budapest September 2015) we had decided that `snappy build` would be `snapcraft snap`... to be clear, I am fine revisiting decisions made in the past :-)
[14:24] <ondra> mvo cool thanks
[14:24] <niemeyer> sergiusens: I'm not suggesting that change right now
[14:24] <ondra> mvo but please keep it high on priority list, as this is critical error for us
[14:25] <niemeyer> sergiusens: For now I'd just like to get a command name that is the same on snap and snapcraft
[14:25] <Chipaca> incident at the boys school, need to run
[14:25] <niemeyer> Chipaca: o/ take care
[14:25] <sergiusens> but if we do `snap <pack-placeholder-name>` we should ensure the snap command can be installed without snapd to support build systems
[14:25] <niemeyer> Chipaca: Hope it's all well there
[14:25]  * sergiusens is looking out the window from a coffee shop as the gusts of wind blow things
[14:25] <niemeyer> sergiusens: Yeah, let's not get there right now..
[14:26] <sergiusens> they announced 40km/h to 60km/h wind
[14:27] <mpt> looking
[14:27] <sergiusens> niemeyer gotcha on the home of the logic, we should still sleep on it to figure out a good name if `snap-dir` is not the best
[14:29] <niemeyer> How about... squash :)
[14:31] <niemeyer> sergiusens: ^
[14:31] <niemeyer> mvo: ^
[14:34] <sergiusens> sounds kind of weird to me at first sight but I'll let it sit there in the back of my head and see if I grow on it
[14:34] <zyga-ubuntu> mvo: about https://github.com/snapcore/snapd/pull/3946 - should there be a cmd_pack.go somewhere?
[14:34] <mup> PR #3946: snap: add new `snap pack` and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3946>
[14:34] <niemeyer> sergiusens: You mean it's weird to say squash when you're squashing something? :)
[14:35] <niemeyer> sergiusens: The outcome of this command consists almost entirely of running mksquashfs
[14:35] <zyga-ubuntu> mvo: did you forget to add it? I don't see how "snap pack" would work otherwise
[14:35] <mvo> zyga-ubuntu: oh oh
[14:37] <zyga-ubuntu> git add? :D
[14:37] <mvo> *cough*
[14:38] <mvo> zyga-ubuntu: good that it is renamed :)
[14:38] <niemeyer> sergiusens: With that said, I sort of agree otherwise.. for someone that isn't into the details, it may be an awkward choice
[14:38] <niemeyer> mvo: Let me look further into the dictionary :)
[14:38] <mvo> niemeyer: snap collect?
[14:39] <niemeyer> mvo: Misses the idea of "bundling".. actually.. bundle?
[14:40] <mvo> niemeyer: bunble works for me, the downside is that we can create a "bundle" of snaps in the future but I guess that is rather theoretical
[14:41] <sergiusens> niemeyer the first to things that popped into my mind were git squashing and the sport my wife plays :-)
[14:41] <sergiusens> bundle has a better ring
[14:42] <niemeyer> mvo: Hmm
[14:42] <niemeyer> mvo, sergiusens: "assemble" was my original idea back then.. it felt sort of long, but I'm starting to appreciate it again given these corners we're finding on each of the other options
[14:42] <sergiusens> we could go back to assemble
[14:43] <sergiusens> +1
[14:43] <mvo> +1 from me as well, long but pretty precise
[14:43] <sergiusens> it was originally called assemble :-)
[14:43] <sergiusens> in snapcraft at least
[14:45] <niemeyer> Cool, let's go with it then..
[14:45] <niemeyer> It's okay that it's long.. snapcraft is what most people will use anyway
[14:45]  * mvo will do
[14:46] <niemeyer> I was also looking for something that has a reasonable antonym for obvious reasons
[14:47] <niemeyer> disassemble will do
[14:50] <mup> PR snapd#3947 opened: snap-repair: fix tests when running as root <Created by mvo5> <https://github.com/snapcore/snapd/pull/3947>
[14:52] <mvo> pedronis: this should fix the first part of the failures
[14:52] <mvo> (the easy part sadly)
[14:52] <pedronis> ok
[14:53] <mup> PR snapd#3944 closed: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3944>
[14:59] <pedronis> mvo:  does running with -check.vv helps narrowing down the other issue to a single test?
[14:59] <pedronis> is the other issue related to root as well? or not?
[14:59] <mvo> pedronis: good news, I have not seent the other failure anymore, however I now see http://paste.ubuntu.com/25580143/ in ~1/10 runs
[15:00] <mvo> pedronis: I'm in the same debian machine with my first fix applied and no longer see the panic with the epoll, just this i/o timeout
[15:00] <mvo> pedronis: this one I only see in debian, I can not reproduce on zesty
[15:00] <pedronis> that is curious
[15:01] <pedronis> that the epoll went away like this
[15:01] <pedronis> but good I suppose
[15:03] <pedronis> mvo: is it always the same test that times out, or a particular one?
[15:03] <mvo> pedronis: I was wrong, its back, races are annoying
[15:03] <mvo> pedronis: it looks like its happning in TestFetch500
[15:03] <mvo> pedronis: looks like teardown
[15:07] <mvo> pedronis: checking, it appears to be only TestFetch500
[15:08] <pedronis> it doesn't do anything special
[15:08] <pedronis> afaict
[15:12] <mup> PR snapd#3942 closed: doc: snapctl man page <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3942>
[15:13] <zyga-ubuntu> niemeyer: ^ I'm somewhat unhappy about that manual page, it's fine to link to the forum but I think that manual page was well worth having, even if people find out about the forum
[15:13] <niemeyer> zyga-ubuntu: What specifically do you disagree with in my comments?
[15:15] <zyga-ubuntu> niemeyer: both I suspect
[15:15] <niemeyer> zyga-ubuntu: As you can imagine, I still have no idea about what you mean
[15:15]  * Chipaca back
[15:15] <zyga-ubuntu> niemeyer: we have non-generated manual pages today, not sure what makes it better if it is generated (in this particular case)
[15:16] <niemeyer> zyga-ubuntu: Do we have a non-generated manual page for the snap command?
[15:16] <zyga-ubuntu> niemeyer: and not sure why manual page cannot document how to use snpactl
[15:16] <zyga-ubuntu> niemeyer: we have non-generated manual pages for snap-confine, snap-discard-ns
[15:16] <niemeyer> zyga-ubuntu: Do we have a non-generated manual page for the snap command?
[15:18] <zyga-ubuntu> niemeyer: you know that I know the answer, I don't see the value of generating a piece of prose in the right format; there are no sophisticated options that we save time by maintaining automatically by generating anything
[15:19] <niemeyer> zyga-ubuntu: The question is specific, on purpose.. there's a reason why we don't have a hand-written manual page for the snap command, so I'm waiting for you to let that sink and acknowledge that reason
[15:19] <mvo> pedronis: its very strange, it looks like in TestFetch500 it hangs in runner.Fetch() and not hit the test server in some cases
[15:19] <zyga-ubuntu> niemeyer: is that reason the fact that it is a complex command with sub commands?
[15:20] <mvo> pedronis: almost as if httptest.NewServer() is not fully ready when it returns
[15:20] <niemeyer> zyga-ubuntu: No.. the reason is that we write documentation for every single one of those commands, already. Dozens of commands. There's literally zero value in hand-writing that exact same documentation again, elsewhere.
[15:21] <zyga-ubuntu> niemeyer: I disagree about the assumption that "foo --help" and "man foo" provide similar content
[15:21] <zyga-ubuntu> niemeyer: they provide a subset of the content that is the same but typically manual pages go to greater length about details
[15:21] <mvo> pedronis: sstrace shows me a EAGAIN error in accept4() but the trace is really hard to read
[15:22] <zyga-ubuntu> niemeyer: (and as I said, it's fine to say "more details are on the forum http://url/", but most people know about man pages and don't know about a software-specific forum
[15:22] <niemeyer> zyga-ubuntu: We've repeatedly failed to maintain documentation up-to-date in multiple places, and we're failing that again. See snapcraft.io if you want an example. There's absolutely no way we will have an ad-hoc hand-written manual page going in without us establishing a strategy for it not to fail.
[15:22] <pedronis> mvo: this is all bizarre because we have a lot of tests like this in many other unit tests, I wonder what is different here
[15:22] <niemeyer> zyga-ubuntu: We *have* a manual page for snap, today.
[15:23] <zyga-ubuntu> niemeyer: how is it any better if that prose is written in snapctl.go and echoed via --man mechanism? it's still text that needs maintenance
[15:23] <niemeyer> zyga-ubuntu: If you would like to improve the documentation about any of those commands, by all means please do. You know where to do that.
[15:23] <niemeyer> zyga-ubuntu: Exactly!
[15:23] <niemeyer> zyga-ubuntu: That text already exists!
[15:23] <mvo> pedronis: yes, especially since it is always the same test apparently but we have many that use the retry strategy and that use the mock server
[15:23] <niemeyer> zyga-ubuntu: Type in: snapctl get --help
[15:24] <pedronis> mvo: does it fail also run alone?
[15:24] <niemeyer> zyga-ubuntu: Why on earth would we maintain that by hand elsewhere?
[15:25] <zyga-ubuntu> niemeyer: "snapctl --help" doesn't tell you anything about the purpose of the tool
[15:25] <zyga-ubuntu> niemeyer: it's fine to generate everything if we can put that text somewhere
[15:25] <niemeyer> zyga-ubuntu: Feel free to fix that, after layouts. :)
[15:25] <zyga-ubuntu> niemeyer: (and arguably showing it in --help is not very useful)
[15:26] <niemeyer> zyga-ubuntu: Not okay to duplicate documentation. We've been there, I know where this goes.
[15:26] <mvo> pedronis: it does not, it works when I run it alone, it survived ~400 runs now
[15:26] <pedronis> mvo: so it's the combination with something else, but what?
[15:27] <zyga-ubuntu> niemeyer: I still feel that pawel did the work that's definitely good enough to be useful to people (people cared because we have a bug report on this) and we closed the PR because the text was not going through the generator
[15:27] <zyga-ubuntu> niemeyer: that's all I wanted to say, we've made our points I think
[15:28] <niemeyer> zyga-ubuntu: I closed the PR because it does something we don't want to do, for reasons I justified and backed by history. We're not having a loose piece of text that will definitely go unmaintained. Let's do it properly.
[15:30] <niemeyer> pstolowski: Please let me know if you'd like to discuss the approach further. As mentioned in the PR, just look at the handling of --man in cmd_help.go and you'll clearly see how this works.
[15:31] <pstolowski> yes, that's a bit disappointing and unexpected tbh, but I'm not going to argue about that. I knew of --man but as discussed earlier with zyga-ubuntu, this looked a bit limiting vs a more rich document
[15:32] <pstolowski> i was under impression (wrong one apparently) that we're moving away from auto-generated man
[15:33] <mvo> pedronis: ok, when I skip the fetch500 it appears in fetchBroken so it seems related to the retry strategy
[15:33] <niemeyer> pstolowski: Do you seriously want to write and maintain the snap manual page by hand?
[15:33] <pedronis> mvo: are we sure is not related to tests before?
[15:33] <pedronis> mvo: you said it works alone
[15:33] <mvo> pedronis: it could be, let me try some more
[15:33] <mvo> pedronis: it does
[15:34] <pstolowski> niemeyer, depends how rapidly the command changes. snapctl does't change too often
[15:34] <pedronis> mvo: what if you run just cmd_done_retry_skip_test.go and Fetch500 ?
[15:34] <pedronis> that's the only thing that is recent
[15:34] <pedronis> ly added
[15:34] <cachio> pstolowski, the snap-run-hook test is also failing on my dragonboard
[15:34] <niemeyer> pstolowski: It doesn't matter.. even if it changes just once every month, why do you want to maintain the exact same piece of information in two different places?
[15:34] <cachio> i have a debug session open
[15:34] <cachio> pstolowski, do you need some information?
[15:35] <niemeyer> pstolowski: ... when we tend to fail to maintain documentation up-to-date even when it is in *one* place.
[15:35] <pedronis> mvo: maybe just this  +go test -check.vv -check.f "StatusHappy|Fetch500"  ?
[15:36] <pstolowski> cachio, is it possible to recreate on linode? if so, can you give me the details (in the meantime I'm checking locally)
[15:36] <pedronis> mvo:  or +go test -check.vv -check.f "TestStatus|Fetch500"
[15:36] <mvo> pedronis: yeah
[15:37] <pedronis> does it fail like that?
[15:38] <mvo> pedronis: yes, I found it I think! misisng close in one of the status tests, thank you so much for your intuition on this one
[15:38] <pedronis> the os.Pipe in status Happy?
[15:38] <mvo> pedronis: yes
[15:38] <pedronis> seems a bug in the rumtime though :)
[15:38] <pedronis> sorry, I mean :(
[15:38] <pedronis> it shouldn't interfere like that
[15:38] <cachio> pstolowski, I can reproduce it just on real ubuntu cores
[15:39] <cachio> pstolowski,
[15:39] <cachio> https://paste.ubuntu.com/25580415/
[15:39] <cachio> it is not resolving the env vars
[15:39] <ppisati> ogra_: didn't we have a '--dangerous' switch (or something similar) when installing custom kernels? i mean, to avoid the "cannot replace signed kernel snap with an unasserted one" error
[15:39] <mvo> pedronis: definitely, very strange
[15:40] <cachio> TEST_COMMON=$SNAP_COMMON instead of TEST_COMMON=/var/snap/basic-hooks/common
[15:40] <ogra_> ppisati, i think that only works if the original kernel snap was actually a local snap when you built the image
[15:40] <mvo> pedronis: the side-effects of this are not at all obvious
[15:40] <cachio> pstolowski, you can create a vm with ubuntu core and reproduce it on there
[15:40] <ogra_> i.e. if snap list shows it as x1
[15:41] <ogra_> ppisati, but do you need the modules ? if just testing vmlinuz you can simply replace it on the vfat
[15:41] <ppisati> ogra_: uhm, ok, let me try that
[15:41] <cachio> pstolowski, i can provide you any information of the exec
[15:42] <mup> PR snapd#3948 opened: snap-repair: fix missing Close() in TestStatusHappy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3948>
[15:42] <cachio> pstolowski, just tell me what you need
[15:42] <pedronis> mvo: I know, I think I understand,  we are passing in the same runtime the  FD as a int
[15:42] <pedronis> mvo: so at that point is not under runtime control anymore
[15:42] <pedronis> so when it gets close we close something random
[15:43] <pedronis> mvo: if we don't do it ourselves
[15:44] <pedronis> mvo: we are causing a double close somehow
[15:45] <pedronis> mvo: I'm not even sure how to avoid it
[15:46] <mvo> pedronis: make sense. I need to take a break, lets see if the world is a more happy place once the branches are in
[15:47] <pedronis> mvo: does those close help?
[15:48] <pedronis> I suppose they do because we control when the double close happens
[15:48] <pedronis> it still happens though
[15:51] <pstolowski> cachio, indeed. it kinda looks like the problem of running "old" snap-exec vs the namespacing problem. zyga-ubuntu any idea if that could be it?
[15:52] <pedronis> yes, double close still happens and where we expect it
[15:52] <pedronis> zyga-ubuntu: so it was a double close but in a more interesting place
[16:01] <zyga-ubuntu> pedronis: oh, I'm curious to learn
[16:01] <zyga-ubuntu> pedronis: where was it?
[16:05] <pedronis> zyga-ubuntu: we have a test that passes around a fd through an env variable but in the same process, not across processes, fun ensues
[16:08] <zyga-ubuntu> pedronis: aah
[16:08] <zyga-ubuntu> pedronis: so it was "copied" as I was wondering
[16:08] <zyga-ubuntu> (well copied as in memcpy, not dup)
[16:08] <zyga-ubuntu> pedronis: interesting find, does that bring master to sanity?
[16:09] <cachio> pstolowski, I am updating the core from adge again
[16:09] <cachio> pstolowski, and rexec to see the results
[16:12] <pedronis> zyga-ubuntu: copied as we end up with two os.File with the same fd without the runtime knowning this
[16:12] <pedronis> apparently
[16:13]  * sergiusens is looking at his battery drop during the blackout
[16:13] <zyga-ubuntu> pedronis: right, sadly that's exactly the case
[16:13] <zyga-ubuntu> jdstrand: hey, I saw your nvidia PR, I'll get to it soon
[16:40] <lutostag_> anybody got an idea why I might be hitting https://bugs.launchpad.net/snappy/+bug/1659719 ?
[16:40] <mup> Bug #1659719: ssh can't call a binary from a snap without the full path <isv> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1659719>
[16:40]  * zyga-ubuntu looks
[16:40] <ogra_> lutostag_, is the file there ?
[16:41]  * ogra_ just commented on the bug a minute ago 
[16:42] <lutostag_> ogra_: indeed it is
[16:42] <ogra_> i definitely see it everywhere on classic installs as well as on devices
[16:42] <lutostag_> hah, good timing ;)
[16:42] <ogra_> lutostag_, hmm, do you use some weird shell like zsh ?
[16:42] <lutostag_> nope lxd, with bash
[16:42] <zyga-ubuntu> lutostag_: it might be ssh and pam doing some fancy variable sanitization
[16:42] <ogra_> (or some other that wouldnt parse profile.d on login)
[16:43] <lutostag_> if I do ssh ubuntu@ip "juju-crashdump" it fails
[16:43] <zyga-ubuntu> what is the target OS that hosts snaps?
[16:43] <ogra_> lutostag_, ah
[16:43] <ogra_> lutostag_, that wont spawn a shell
[16:43] <lutostag_> because profile isnt executed without -l
[16:43] <nacc> lutostag_: you need a login shell
[16:43] <ogra_> lutostag_, right
[16:43] <zyga-ubuntu> ah, that bug is pretty well triaged already
[16:44] <ogra_> well,
[16:44] <nacc> e.g., ssh ubuntu@ip bash -l -c juju-crashdump
[16:44] <ogra_> openssh people would tell you "notabug" :)
[16:44] <lutostag_> that is confusing for me, yeah
[16:44] <ogra_> its the "you're holding it wrong" of ssh ;)
[16:44] <lutostag_> I know why and all, just that we hit it as we expected /snap/bin to be a top-level PATH citizen, but...
[16:46] <ogra_> if you have control of the image build you could indeed modify /etc/environment
[16:46]  * zyga-ubuntu downloads ubuntu ISO for the Nth time in his life
[16:46] <zyga-ubuntu> I need to figure a way to keep those arund
[16:46] <zyga-ubuntu> *aroud
[16:46] <zyga-ubuntu> *around even
[16:46] <ogra_> pfft isos ...
[16:46] <lutostag_> and I guess bashrc in /etc/bashrc doesnt support .d directory loading so we could add the snippet from https://bugs.launchpad.net/snappy/+bug/1659719/comments/4
[16:46] <mup> Bug #1659719: ssh can't call a binary from a snap without the full path <isv> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1659719>
[16:47] <ogra_> lutostag_, doesnt help if you dont run bash ...
[16:47] <ogra_> ssh ubuntu@ip <command> will use /bin/sh ... not bash
[16:49]  * zyga-ubuntu sets up NFS in a VM, better safe than sorry
[16:50] <lutostag_> hmm... jenkins@juju-6f7422-solutions-qa-integration-1:~$ ssh ubuntu@10.62.42.103 "juju-crashdump"
[16:50] <lutostag_> Warning: Permanently added '10.62.42.103' (ECDSA) to the list of known hosts.
[16:50] <lutostag_> bash: juju-crashdump: command not found
[16:51] <lutostag_> seems like an error from bash for me...
[16:51] <nacc> lutostag_: you aren't running a login shell
[16:51] <ogra_> add -l or use /bin/bash -c
[16:51] <lutostag_> gotcha, thanks
[16:55] <lutostag_> ogra_: and I guess /etc/environment tweaking for the whole the default ubuntu as a whole is a no-go?
[16:55] <lutostag_> (for fresh installs)
[16:57] <ogra_> lutostag_, thats a question for foundations :)
[16:57] <nacc> heh
[16:57] <ogra_> you can definitely not do it retroactively though
[16:59] <ogra_> (so yes, the installer/iso  would have to have that change)
[17:03] <nacc> and presumably would need to dtrt on upgrades, etc.; seems pretty invasive :)
[17:07] <niemeyer> mvo, sergiusens: One last idea before closing down on assemble: fold/unfold
[17:09] <nacc> what voodoo do i need to invoke to have the beta/candidate channels for my snap follow edge as it is now?
[17:11] <niemeyer> mvo, sergiusens: I like this one a bit more than assemble because it has that very cheap feeling.. not a lot is happening when we fold
[17:11] <elopio> nacc: if you want edge, candidate and beta to be the same, release the revision to candidate, and close the other two.
[17:12] <nacc> elopio: yep, just realized that :)
[17:13]  * niemeyer steps out
[17:28]  * zyga-ubuntu is stuck in a traffic jam
[17:34] <nacc> it feels like this message could be improved (fro sudo snap refresh git-ubuntu): error: cannot refresh "git-ubuntu": snap "git-ubuntu" has changes in progress
[17:34] <nacc> changes where?
[17:35] <zyga-ubuntu> nacc: in snapd, there are "snap changes" that affect it
[17:36] <nacc> zyga-ubuntu: ah, meaning it's currently doing an update from the store?
[17:36] <zyga-ubuntu> nacc: `snap "git-ubuntu" is being processed by snapd`
[17:36] <zyga-ubuntu> nacc: any change involving that snap
[17:36] <nacc> zyga-ubuntu: ah ok, yeah that would be clearer to me
[17:36] <zyga-ubuntu> nacc: (refresh is one of possibilities but not the only one)
[17:36] <nacc> "cahnges in progress" implies (to me) that i have done some local modification
[17:46] <nacc> is it possible to remove an architecture from a snap? (e.g., currently i'm buildign for amd64 and i386, but the i386 version is fundamentally broken and unsupported)
[17:47] <nacc> so i'd like to just remove it from the store, untile we get around to enablinng it properly
[17:51] <zyga-ubuntu> nacc: ask store people, I don't know really
[17:52] <nacc> zyga-ubuntu: ok, thankns
[18:21] <Chipaca> ok, this epoch thing isn't going out today
[18:21]  * Chipaca wraps up
[18:22] <posi> I am building a snap for brave using electron-builder. When I go to snap install it I must use dangerous because "error: cannot find signatures with metadata for snap "dist/brave_0.21.0_amd64.snap""
[18:27] <nacc> posi: you're doing a local snap install (of a local snap file)?
[18:27] <posi> Well I build the snap file yea
[18:27] <posi> and then i wanted to test it
[18:27] <posi> and got that error
[18:27] <posi> perhaps i wont get it if it goes to a repo?
[18:27] <nacc> posi: yes, you'll need to use --dangerous
[18:27] <posi> just because it's not going through a signed repo?
[18:27] <nacc> posi: 'verified', in this context, i think means it comes from the store
[18:27] <nacc> posi: i'm not sure, though
[18:28] <posi> cools town
[18:28] <posi> i wont worry about it then
[18:28] <nacc> posi: i should say for our jenkins job that builds a snap from our repo for a test, we use dangerous to do a 'local install'
[18:28] <nacc> posi: so it's not surprisinng to me, at least :)
[18:28] <zyga-ubuntu> posi: yes, that's exactly what's going on
[18:28] <zyga-ubuntu> posi: you don't have store-signed assertion if you build locally
[18:28] <posi> makes total sense
[18:28] <posi> thanks y'all
[18:28] <nacc> zyga-ubuntu: thanks for confirming
[18:29] <posi> also
[18:29] <posi> we are using linux namespaces for security
[18:29] <posi> so i had to switch to confinement classic
[18:29] <posi> curious what y'all imagine apps should do who use user naemspaces like us and chromium
[18:31] <nacc> posi: there is some discussion here, but it's about snapd and user namespaces, i thinnk (https://forum.snapcraft.io/t/snappy-and-users-and-groups-obsolete/331)
[18:32] <zyga-ubuntu> posi: it's possible
[18:32] <nacc> posi: also, there's LP: #1586547
[18:32] <mup> Bug #1586547: allow browsers to use user namespaces in its sandbox <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1586547>
[18:32] <zyga-ubuntu> posi: depending on what you mean specifcally, chromium uses a number of thins together so it needs a privileged interface
[18:34] <jdstrand> posi: you don't have to use classic for linux namespaces with electron
[18:34] <jdstrand> posi: are you brave upstream?
[18:35] <jdstrand> posi: if you are, see https://github.com/snapcore/snapd/wiki/Interfaces#browser-support
[18:36] <posi> jdstrand: yes
[18:36] <posi> jdstrand: right it's not an electron thing
[18:36] <posi> jdstrand: it's a how we secure our rendering thread
[18:36] <jdstrand> posi: you can set an interface attribute. this is, for example, what the chromium snap is doing
[18:37] <jdstrand> posi: right. use 'allow-sandbox: true'. that should allow brave to do what it needs, just like chromium and chrome
[18:37] <posi> great!
[18:37] <jdstrand> in strict mdoe
[18:37] <jdstrand> mode*
[18:38] <jdstrand> posi: that attribute is intended to be used by trusted upstream browser publishers (eg, Chrome/Chromium, Firefox, ...). Brave certainly fits that category
[18:38] <posi> yep
[18:38] <zyga-ubuntu> jdstrand: o/
[18:39] <zyga-ubuntu> jdstrand: I didn't get to your nvidia PR yet, sorry
[18:39] <zyga-ubuntu> jdstrand: on the upside I'm working on tests for NFS
[18:39] <posi> Can I cleanup this conversation, remove your names and summerize it in a PR to the electron-builder community?
[18:39] <jdstrand> posi: to just get the snap going, iirc flexiondotorg didn't enable the user namespaces support so allow-sandbox: true wasn't needed, but I figured one day someone from Brave would ask about this
[18:39] <jdstrand> zyga-ubuntu: no worries
[18:40] <jdstrand> posi: well... for the average electron app, they should *not* use allow-sandbox: true
[18:40] <jdstrand> posi: and just rely on the snappy sandbox
[18:40] <posi> Right we'd add a allow blah
[18:41] <jdstrand> posi: if you summarize the conversation, it is really important you communicate that point, because use of 'browser-support' alone allows automated reviews to pass in the public Snap Store. specifying 'allow-sandbox: true' requires a conversation with a trusted publisher, because the policy it allows would allow a malicious snap to break out of confinement
[18:42] <jdstrand> posi: so we very tightly restrict its use
[18:42] <posi> Right
[18:42] <posi> so would we want both of them on
[18:42] <posi> in the case of a browser
[18:42] <posi> or is browser-support legit
[18:43] <jdstrand> browser-support is fine for a browser that is configured itself with --disable-sandbox
[18:43] <jdstrand> it relies on the snappy sandbox only
[18:43] <posi> no we want enable-sendbox
[18:43] <posi> *sandbox
[18:43] <jdstrand> I know you do
[18:43] <posi> ahh ok
[18:43] <posi> so i want both then
[18:43] <jdstrand> I'm saying for the general case
[18:43] <posi> sure
[18:44] <mup> PR snapd#3948 closed: snap-repair: fix missing Close() in TestStatusHappy <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3948>
[18:44] <jdstrand> a trusted publisher who has a browser that is in use by tons of users, allow-sandbox: true makes sense (Brave, Chrome, etc)
[18:44] <jdstrand> anyway, it is a fine point
[18:45] <jdstrand> I just want to make sure people don't see it and are like 'sure I want all of this' since there will be store friction
[18:46] <jdstrand> at some point, apparmor will better work with user namespaces and we won't need to guard this so carefully
[18:46] <jdstrand> ie, we need to grant 'capability sys_admin' to the snap
[18:46] <jdstrand> but the snap only needs sys_admin in the user namespace
[18:47] <jdstrand> but, today, it only shows up as sys_admin, regardless if it is system namespace or user namespace (this is but one example)
[18:47] <posi> yea
[18:47] <posi> dude, i still can't believe the archlinux would prefer a setuid binary to a linux namespace binary
[18:48] <jdstrand> posi: perhaps if you say something like 'Major browser manufacturers may want to use.... Use of 'allow-sandbox' will require permission for use in the public Snap Store at this time'
[18:48] <jdstrand> s/for use/for distribution/
[18:49] <jdstrand> wordsmith as desired
[18:49] <jdstrand> posi: well, it isn't like user namespaces haven't had any CVEs :P
[18:49] <posi> True but if they knew what i knew about how drm worked....
[18:49] <jdstrand> that code was a CVE factory for awhile :)
[18:50] <zyga-ubuntu> jdstrand: unprivileged user namespaces/
[18:50] <jdstrand> but the user ns/apparmor issues are known and on the roadmap to make better. I don't have a timeline for when that will left the restriction wrt browser-support, but we'll get there eventually
[18:51] <posi> https://github.com/electron-userland/electron-builder/issues/2100
[18:51] <jdstrand> zyga-ubuntu: that's what I was talking about, yes
[18:51] <jdstrand> will left?
[18:51] <zyga-ubuntu> right, I was just checking
[18:51] <jdstrand> we'll lift
[18:53] <jdstrand> posi: so, to be clear, Brave is fine to use allow-sandbox. I'm fine with you taking this conversation back to the electron community. we'll be working to make userns/snapd/apparmor work better together
[18:53] <posi> Yay
[18:53] <jdstrand> (but again, no fixed timeline)
[18:53] <jdstrand> in fact, I'll just grant it to the snap now so you can just upload away
[18:54]  * jdstrand thought he might've already done that
[18:54] <jdstrand> no, I did not
[18:58] <jdstrand> posi: ok granted. I'm not sure if you've used interface attributes before, so here you go: http://paste.ubuntu.com/25581549/
[19:12] <kyrofa> Hey everyone
[19:12] <zyga-ubuntu> hey kyle
[19:12] <kyrofa> sergiusens, I'm finally at the hotel and settled
[19:14] <sergiusens> kyrofa and I finally have electricity again!
[19:14] <zyga-ubuntu> 1st world / 3rd world problems
[19:14] <zyga-ubuntu> at least we are all on IRC
[19:15] <sergiusens> zyga-ubuntu apparently the 80km/h winds affected the grid :-/
[19:15] <kyrofa> Oh dang, storming down there eh?
[19:16] <zyga-ubuntu> sergiusens: I'm sorry, I was kidding, it's not a fun time for a good chunk of the world :/
[19:18] <sergiusens> zyga-ubuntu we are on the good side of it, our bad weather and flooding is around the middle of summer (Jan/Feb)
[19:26] <pedronis> mvo: thanks for merging, as you have seen I added some more description that you included
[19:32] <mup> PR snapd#3949 opened: cmd/snap-repair: skip disabled repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3949>
[19:39] <mup> PR snapd#3950 opened: cmd/snap-repair: prefer leaking unmanaged fds on test failure over closing random ones  <Created by pedronis> <https://github.com/snapcore/snapd/pull/3950>
[19:48] <mvo> pedronis: yeah, thank you for your extra comments
[20:01] <pedronis> mvo: I proposed my Dup variant (for extra paranoia)
[20:02] <sergiusens> elopio around?
[20:04] <elopio> sergiusens: pong
[20:05] <jdstrand> stgraber: hi! so I've noticed a number of lxd stable snap updates lately (cause the container restarts and I lose state). container restarts aside, I wonder if I should be tracking 2.0/stable? (though, it is still at 2.0.10 it looks like, far behind 2.17)
[20:05] <sergiusens> elopio well, retroactive ping then ;-)
[20:05] <sergiusens> elopio how about updating those PRs so they land?
[20:05] <stgraber> jdstrand: hmm, your containers reboot when lxd updates? that's not normal
[20:06] <stgraber> jdstrand: can you pastebin "journalctl -u snap.lxd.daemon"?
[20:06] <jdstrand> stgraber: well, I'm assuming. I ssh in then the connection drops. maybe it is something else?
[20:06] <mvo> pedronis: thanks, looking
[20:07] <jdstrand> (not immediately drops mind you-- I thought with updates, maybe not)
[20:07]  * jdstrand journalctls
[20:07] <stgraber> jdstrand: ah, LXD re-applies its network config on daemon startup, I wonder if that's somehow enough to disconnect ssh
[20:07] <elopio> sergiusens: on the snapd integration tests, I need to figure out a test for lib crawling. And on the shared cache, I'm not sure if we are +1 or -1
[20:08] <elopio> are you talking about those?
[20:08] <sergiusens> elopio yes, those; also followup on my docstrings
[20:08] <sergiusens> elopio and do you have a minute to run a test?
[20:08] <mvo> pedronis: one question inline, but I call it a day now, things look good
[20:09] <sergiusens> elopio need your publisher-id for staging (snapcraft whoami)
[20:09] <jdstrand> stgraber: http://paste.ubuntu.com/25581972/ (yes, snap refresh)
[20:10] <jdstrand> well
[20:10] <jdstrand> that was last night
[20:10] <stgraber> jdstrand: ok, that should be fine, it detected the refresh which means it shouldn't have brought down containers
[20:10] <jdstrand> stgraber: I don't have anything from the last few minutes in the log
[20:11] <elopio> sergiusens: sure. Do you need my id, or do I need my id to run the test?
[20:11] <jdstrand> stgraber: I did move from one wifi network to another. could that cause it?
[20:11] <jdstrand> where 'it' is network restart
[20:12] <stgraber> jdstrand: unless network-manager is doing something very very wrong, it shouldn't
[20:12] <stgraber> jdstrand: what's "uptime" showing inside one of your containers?
[20:12] <pedronis> mvo: we don't strictly need it, but otoh it makes the test very similar to what we have in Run (which I think is good)
[20:14] <jdstrand> stgraber: 20:13:48 up 11:15,  2 users,  load average: 0.42, 0.53, 0.68
[20:14] <stgraber> jdstrand: and you got disconnected less than 11 hours ago?
[20:14] <sergiusens> elopio I need your id to share a snap with you and then ask you to push a new version
[20:15] <jdstrand> stgraber: I thought so, but I have several others ssh sessions that are up that survived the AP change
[20:16] <jdstrand> stgraber: I closed that terminal. It might've been lingering since yesterday
[20:16] <jdstrand> (sorry for closing that one)
[20:16] <jdstrand> so, it sounds like a snap refresh might restart the network
[20:16] <elopio> sergiusens: wait, my user on staging has 2fa enabled, but the staging 2fa was my ubuntu phone.
[20:16] <elopio> let me register a new user.
[20:17] <stgraber> jdstrand: yeah, a refresh of the LXD snap would cause the daemon to be stopped and restarted, which will reset iptables rules, routes and IPs on the lxdbr0 bridge. But I'm unable to reproduce this causing ssh to drop here.
[20:17] <jdstrand> hmm
[20:17] <jdstrand> oh
[20:18] <jdstrand> stgraber: I wonder if it is because it got an IP address change
[20:19] <stgraber> that seems reasonably unlikely. While LXD's dnsmasq doesn't issue static leases, it does provide IPs based on a hash of the MAC, so that should keep things rather stable and avoid random IP changes.
[20:20] <jdstrand> stgraber: I have a pretty lame way I am sshing in: I run 'lxc exec <name> -- ip -4 addr show eth0', scrape the ip address and ssh into it
[20:20]  * jdstrand wonders if there is a better way
[20:20] <stgraber> Host *.lxd
[20:20] <stgraber>   StrictHostKeyChecking no
[20:20] <stgraber>   UserKnownHostsFile /dev/null
[20:20] <stgraber>   ProxyCommand nc $(lxc list -c s4 $(echo %h | sed "s/\.lxd//g") %h | grep RUNNING | cut -d' ' -f4) %p
[20:20] <stgraber> in .ssh/config
[20:21] <nacc> stgraber: feels like that should be in the manpage :)
[20:21] <jdstrand> stgraber: ok, so, we let me try to get more info the next time it disconnects and go from there. do you have a recommendation on stable vs 2.0/stable?
[20:21] <nacc> stgraber: i remember that makinng a huge difference to me :)
[20:22] <stgraber> jdstrand: 2.0/stable is the LTS release as you have it in xenial-updates. So it's quite a bit behind LXD 2.17/2.18 as far as features. It's also not fully supported as a snap yet (waiting for 2.0.11 which will get us there)
[20:22]  * jdstrand jots down the ssh/config entry
[20:22] <jdstrand> I see
[20:22] <jdstrand> well, I seem to be on the stable train then
[20:23] <elopio> sergiusens: DPKYnDYokujK66geceR4EdcVEi4tekzr
[20:26] <sergiusens> nessita I get this on pushes on the store now "Please choose the store for the mandm snap before uploading" for a snap I registered on Monday I believe (didn't we discuss using the default store by default?)
[20:26] <sergiusens> elopio will have to wait a bit :-)
[20:27] <sergiusens> well, the dashboard allowed me to fix, so no hurry here
[20:28] <jdstrand> stgraber: curious, does the *.lxd work with up-to-date artful and systemd-resolved?
[20:29] <jdstrand> I've had no end of trouble with resolved and libvirt and lxd
[20:29] <nacc> jdstrand: i'm on it currently and yes
[20:29] <nacc> jdstrand: note, not using the snnap, though, but i don't think that hsould matter on artful?
[20:29] <jdstrand> I wouldn't think so
[20:30] <sergiusens> elopio did you get an email or something? if not straight out make a simple modification to this http://paste.ubuntu.com/25582065/ and push please
[20:30] <Pharaoh_Atem> :/
[20:30] <sergiusens> Pharaoh_Atem out of nowhere non smiley emoticons are not allowed ;-)
[20:31] <kyrofa> But smiley ones totally are
[20:31] <Pharaoh_Atem> ^_^
[20:31] <nessita> sergiusens, hum yes! you should get the default store by default!
[20:31] <nessita> sergiusens, let me triple check
[20:32] <nessita> sergiusens, is this from snapcraft?
[20:32] <sergiusens> nessita yes
[20:32] <nessita> sergiusens, checking
[20:32] <nessita> sergiusens, is it a name you already own, right?
[20:33] <jdstrand> nacc: for libvirt, I have a crazy script to use gdbus to call SetLinkDNS and SetLinkDomains. it shouldn't be this hard
[20:33] <sergiusens> nessita https://pastebin.ubuntu.com/25582089/
[20:33] <jdstrand> nacc: you have a standard install?
[20:33] <sergiusens> nessita and yes, I think I registered it before you made the change, just never "pushed" anything until today
[20:34] <sergiusens> might be corner casey :-)
[20:34] <jdstrand> I should probably talk to xnox
[20:34] <nessita> sergiusens, it should still use the default store, let me find where the bug is
[20:34]  * jdstrand -> ubuntu-devel
[20:34] <elopio> sergiusens: no mail
[20:35] <nessita> sergiusens, could you please file me a critical bug while I fix?
[20:35] <nacc> jdstrand: yeah
[20:35]  * cmars looks up from the corner
[20:37] <nessita> sergiusens, hum I've just reproduced in prod, so I will fix asap
[20:37] <elopio> sergiusens: pushed revision 2
[20:42] <mup> PR snapcraft#1558 opened: tests: add fake pip fixture <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>
[20:51] <nessita> sergiusens, got my reply?
[21:00] <mup> PR snapd#3933 closed: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3933>
[21:19] <sergiusens> nessita yes, sure thing
[21:19] <sergiusens> went for a short walk to stretch my legs :-)
[21:20] <nessita> sergiusens, branch with fix is on its way to trunk but the bug would be good for tracking
[21:24] <sergiusens> nessita LP: #1718540 although I cannot set the Importance
[21:24] <mup> Bug #1718540: default store not set on registered snaps <Snap Store:New> <https://launchpad.net/bugs/1718540>
[21:24] <nessita> sergiusens, thanks!
[22:03] <sergiusens> kyrofa I am confused by your PR
[22:04] <kyrofa> sergiusens, I realized after I opened it that it contains roughly zero documentation :P
[22:04] <kyrofa> I'm fixing that. But are you confused beyond that?
[22:05] <kyrofa> Ah, I see your comment
[22:06] <kyrofa> First, you of course have a point that this is not yet heavily used, since the only tests that exist so far test the pip class itself and thus don't benefit very much from this. But for example, take a look at the test change here: https://github.com/snapcore/snapcraft/pull/1558/files#diff-0081187be45e5e561b2da7a6516c2f17R533
[22:06] <mup> PR snapcraft#1558: tests: add fake pip fixture <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>
[22:07] <kyrofa> While the change is small, it's suddenly testing more than just list
[22:07] <sergiusens> kyrofa oh, I forgot to mention, that was kind of like the only place it made sense
[22:08] <kyrofa> Yes, agreed. I'm proposing it now so that it can be used in the catkin and python PRs
[22:08] <sergiusens> it still feels a bit heavy
[22:08] <kyrofa> sergiusens, but it's also up for discussion, of course
[22:08] <sergiusens> as you end up calling fakes for those which "do things"
[22:08] <kyrofa> sergiusens, well, yeah, wouldn't it be a mock otherwise?
[22:09] <kyrofa> sergiusens, elopio was talking about how he wanted to test the entire path of the class (install something, list what you installed)
[22:09] <kyrofa> sergiusens, I'm not completely sold on this. Because in order to test using the Python plugin that way with full coverage we end up needing to parse e.g. requirement.txt files
[22:10] <kyrofa> You want to talk about heavy...
[22:10] <kyrofa> elopio, you around?
[22:10] <sergiusens> kyrofa I am divided on this one, let's see what elopio has to say.... to be clear, I am not saying no, I just feel there is too much involvement here
[22:10] <kyrofa> sergiusens, that's totally fair
[22:11] <kyrofa> sergiusens, ignoring the fake though, I love the spy
[22:11] <elopio> Yup
[22:11] <sergiusens> kyrofa it almost feels like creating a fake python interpreter you actually call which interacts with our code would be simpler and more straight forward
[22:11] <kyrofa> Hahaha
[22:12] <sergiusens> would feel more in line with the fake servers
[22:13] <kyrofa> elopio, I proposed the fake implementation I showed you when you get a minute to take a look
[22:13] <sergiusens> elopio thanks for the push of mandm btw, was a good test of collaboration, but the revoking doesn't seem to fit a lot. Mind pushing a "version: 0.3", it should fail so don't go crazy
[22:16] <elopio> I'm looking
[22:20] <elopio> sergiusens: this error: https://paste.ubuntu.com/25582589/
[22:29] <sergiusens> elopio good, I just don't like the error message :-)
[22:29] <sergiusens> that __all__ is just, ..., don't have the words...
[22:30] <elopio> I said the same ;)
[22:39] <kyrofa> Heh
[22:39]  * sergiusens will bbiab
[23:57] <mwhudson> anyone around to help write a spread test?
[23:58] <mwhudson> this line https://github.com/snapcore/snapd/pull/3872/files#diff-fbc5a3aafffbc409b850466293abe66dR20 fails with "/bin/bash: line 65: SNAPMOUNTDIR: unbound variable"
[23:58] <mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
[23:59] <mwhudson> which doesn't make any sense to me given the line just above