/srv/irclogs.ubuntu.com/2017/09/20/#snappy.txt

sergiusenselopio yeah, incomplete as I tend to add examples01:44
sergiusensand ack on the other01:45
sergiusenselopio btw, snapcraft#1555 has been updated01:45
mupPR snapcraft#1555: store: switch to new endpoints <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>01:45
kyrofasergiusens, keep an eye on snapcraft#1549, it should be green any moment01:49
mupPR snapcraft#1549: plugins: extract pip from python plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1549>01:49
kyrofaIt took virtually all day01:49
sergiusenskyrofa funny, I just looked to see if it was ready šŸš±01:49
kyrofaWe hammered travis today01:50
sergiusenskyrofa do you have the next PR in line ready?01:56
mwhudsonwhat happened here??https://launchpadlibrarian.net/337615189/buildlog_snap_ubuntu_artful_ppc64el_subiquity_BUILDING.txt.gz02:01
sergiusensmwhudson did that work with cleanbuild?02:06
mupPR snapcraft#1549 closed: plugins: extract pip from python plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1549>02:09
mwhudsonsergiusens: all the other arches built02:24
sergiusensmwhudson 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 snap02:37
mwhudsonsergiusens: yes, it usually builds fine on ppc64el :)02:37
mwhudsoni suspect some kind of networking glitch but it's a bit silent02:37
mwhudsoni guess i'll try again02:37
sergiusensmwhudson it seems to have been common today, I had a weird error earlier in a lxd container too and ev was reporting similarly02:38
=== JanC_ is now known as JanC
mwhudsonhmm reproducible it seems02:54
mwhudson(aka it failed three times in a row)02:54
mupIssue snapcraft#1452 closed: machine information <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1452>02:58
mupPR snapcraft#1529 closed: recording: record the packages installed in the machine <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1529>02:58
=== ikey|work is now known as ikey|zzz
=== JoshStrobl is now known as JoshStrobl|zzz
=== chihchun_afk is now known as chihchun
zyga-ubuntugood morning05:40
zyga-ubuntuhey morphis06:03
zyga-ubuntuhow are you doing06:03
=== chihchun is now known as chihchun_afk
zyga-ubuntumvo: good morning06:13
mvohey zyga-ubuntu, good morning06:13
zyga-ubuntumvo: could I ask you for a 2nd review?06:13
mvozyga-ubuntu: sure06:14
mvozyga-ubuntu: what branch?06:14
zyga-ubuntuhttps://github.com/snapcore/snapd/pull/362106:14
mupPR #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-ubuntujdstrand gave me a +1 but it's a huge branch and I'd like an extra look06:14
zyga-ubuntujust in case we missed something over the months06:15
mvook06:15
* zyga-ubuntu edits the commit message there06:16
mupPR 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
mupPR 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
mvozyga-ubuntu: I go over the queue right now and will take extra time for your Pr06:17
=== chihchun_afk is now known as chihchun
zyga-ubuntumvo: thank you!06:24
mupPR snapd#3943 closed: tests: fix ubuntu core services  <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3943>06:40
mupPR 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:41
mvohrm, hrm, artful cups-control-test seems to be broken everywhere06:42
mupPR snapd#3940 closed: dirs: fix classic support detection <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3940>06:42
mvozyga-ubuntu: 3939 is still relevant in the light of yesterdays discussion, right?06:44
zyga-ubuntuI think so06:44
zyga-ubuntuthough06:45
zyga-ubuntunot sure if we should land it now or add the ConnectedPlug and the other thing06:45
zyga-ubuntumvo: one thing that doesn't match is the sequencing06:45
mvozyga-ubuntu: ok, lets wait for pawel then, it just has two +1 so I was tempted :)06:46
zyga-ubuntumvo: as gustavo outlined a sequence that has this way down, as step 506:46
pedronishi, yes, in light of yesterday discussion I think it's simple but premature06:47
pedronisseems travis had a big queue, seeing things still waiting from yesterday night06:48
zyga-ubuntupedronis: yes, though you can easily start spread locally to test stuff in anticipation06:49
pedronisI want to land stuff06:49
zyga-ubuntuyes, don't we all06:49
* zyga-ubuntu has much better mood today06:50
pedronisthis is all repair stuff, it has no spread tests so far, so your comment is irrelevant either way06:50
zyga-ubuntupedronis: in that case I'm sorry :/06:51
pedronisI'm even not quite sure how to run spread tests for it06:53
mupPR 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:55
pedronismvo: #3925 can be merged now , not surw if we want to merge it or squash it though06:56
mupPR #3925: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3925>06:56
mvopedronis: I have a look, 3935 is almost ready one tests needs tweaking (see PR)06:58
pedronismvo: it's the spread test that testeds it did nothing06:58
pedronismvo: 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 test06:59
mvopedronis: yeah, just kill it06:59
mupPR snapd#3925 closed: snap-repair: implement `snap-repair {done,skip,retry}` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3925>06:59
mupPR snapd#3931 closed: interfaces/builtin: allow receiving dbus messages <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3931>07:03
mupPR 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
mupPR 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:04
mvozyga-ubuntu: 3807 looks like it needs some test tweaks07:11
zyga-ubuntumvo: looking07:17
zyga-ubuntuah, exellent07:17
zyga-ubuntuCE asks about that often07:17
* zyga-ubuntu looks07:17
kalikianagood morning, snappy07:20
zyga-ubuntuindeed, though it might rain later07:24
pedronismvo: I was looking at #3934 , it seems the rework to make WriteOutput/ScriptIndented to return error and make the caller deal isn't finished07:39
mupPR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>07:39
pedronismvo: commented in the PR as well07:42
pedronisotherwise it would be landable IĀ think07:43
mvopedronis: uh, sorry for this, I fix that in a bit07:44
pedronismvo: btw, work to expose base in the store api has started07:48
pedronisbut you might have been pinged already about that07:48
mvopedronis: yes07:51
zyga-ubuntuhmm07:51
zyga-ubuntu"interface-cups-control" is a bit broken07:52
mvozyga-ubuntu: yes, only in artful07:52
pedronismvo: in #3933 we need to ignore if the symlink already exists08:00
mupPR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>08:00
pedronisor remove and recreate08:01
mvopedronis: aha, thanks for this, I check if the symlink exists but there is of course the TOCTOU issue, I fix accordingly. good catch08:04
mvopedronis: 3934 also shows the error cases are under-tested, I fix that now too08:09
pedroniswell some other tests failed08:10
pedronisbut yes08:10
mvopedronis: untested and buggy, once I add tests they show. oh well, tests ftw08:12
mupPR 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:19
pstolowskizyga-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/.../tmp08:34
zyga-ubuntupstolowski: looking08:35
zyga-ubuntupstolowski: is the PR updated?08:35
zyga-ubuntupstolowski: typically man pages are compressed08:35
zyga-ubuntupstolowski: so maybe you need to change the rule to 1* or 1.gz or similar08:36
pstolowskizyga-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 somewhere08:38
pstolowskizyga-ubuntu, PR updated now08:38
zyga-ubuntupstolowski: let me look quickly08:40
zyga-ubuntuaha, I think I see it08:40
zyga-ubuntupstolowski: pushing08:43
zyga-ubuntu(just letting tests finish actually)08:43
pstolowskizyga-ubuntu, what was it?08:45
zyga-ubuntupstolowski: needless rule08:45
zyga-ubuntuyou'll see in a moment08:45
pstolowskik08:46
zyga-ubuntupstolowski: pushed now08:48
pstolowskizyga-ubuntu, I see.. hmm interesting. let me test08:49
zyga-ubuntupstolowski: I tested locally08:49
zyga-ubuntuand spread will test for other systems08:49
pedronismvo: 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 failing08:53
mvopedronis: hm, yes, artful08:55
pedronisthat's a EBADF btw08:56
pedronis??08:56
pedronismvo: are we forgetting to stop a mock server ? so weird fork interaction?08:59
zyga-ubuntupedronis: 9 is EBADF08:59
pedroniszyga-ubuntu: I just wrote that08:59
pedroniss/so/some/09:00
zyga-ubunturight, I thought you were asking for confirmation (because of the ?? below)09:00
pedronisno, just wondering how the go runtimee got one09:00
pedronismemory corruption?09:00
pedronisit's also i386 fwiw09:04
pstolowskizyga-ubuntu, it builds fine indeed, thanks!09:07
pstolowskizyga-ubuntu, I now need to tweak the formatting, it doesn't look as expected yet09:07
zyga-ubuntupstolowski: you can test it locally easily09:10
zyga-ubuntupstolowski: just open with man09:10
pstolowskizyga-ubuntu, yeah, just struggling with rst, is it documented anywhere?09:14
pstolowskizyga-ubuntu, nvm, found some docs09:15
zyga-ubuntupstolowski: look at other man pages09:15
zyga-ubuntupstolowski: there's very litte syntax to use09:15
pstolowskizyga-ubuntu, indeed, but it doesn't seem to like indentation in my {.. json snippet for example09:16
pstolowskizyga-ubuntu, ok, nailed it09:20
zyga-ubuntupstolowski: \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:21
pstolowskizyga-ubuntu, k, pushed, adressing your comments09:27
zyga-ubuntuthank you09:30
pstolowski... and I just realized it will need an update when #3852 lands ;)09:30
mupPR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852>09:30
pstolowskibut that's fine, let's just land09:30
popeydiddledan: 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:38
popeydiddledan: ogra_ joedborg  https://docs.google.com/spreadsheets/d/1Ii1Q3MFY1W2Tt__JB4sZ05CzP05TwDgB4hN8Z6fR1Hw/edit#gid=009:39
popey(so we can turn these janky things into bugs/docs)09:39
joedborgpopey: will do!09:40
popeythanks09:40
ppisatiogra_: i just tested the daily snapdragon image, and it has the same problem as the 'old' rpi images - no snaps are listed09:45
ppisati$ snap list09:45
ppisatiNo snaps are installed yet. Try "snap install hello-world".09:45
ppisatiogra_: it's the current daily FWIW09:45
mvopstolowski: 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 case09:48
mupPR #3915: cmd/snap: return empty document if snap has no configuration <Created by stolowski> <https://github.com/snapcore/snapd/pull/3915>09:48
mvohrm, hrm, master broken in debian-unstable runner_test:29609:53
pstolowskimvo, looking09:54
zyga-ubuntuI see it09:55
zyga-ubunturunner_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-ubuntuhmmm09:55
zyga-ubuntuwhy on debian and not here though09:56
mvozyga-ubuntu: yeah, also I tried to run tests with go 1.9 from the go snap and got no error09:57
zyga-ubuntuI'm waiting for debian to boot but no ideas yet09:58
zyga-ubuntuespecially, why here, other tests also use mock server09:58
zyga-ubuntucould it be timing?09:58
zyga-ubuntu5 retries09:58
zyga-ubuntu1ms exponential09:58
zyga-ubuntuup to one second09:59
mvopstolowski: 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)09:59
zyga-ubuntumvo: my guess is debian kernel scheduling10:03
* zyga-ubuntu cries whenever we use timing-based tests10:03
pedronismvo: same epollwait problem on zesty, it seems a real issue somehow10:06
pedronismvo: I wonder what is happening:  https://docs.google.com/document/d/1_8n09MPn8JHOyD6VrnLVcMJUvLFKeirCSayY6iEDD5w/edit#10:06
zyga-ubuntumvo: so... it just passed for me on linode10:09
zyga-ubuntuhmmm10:09
pedronisoops10:14
pedronismvo: wrong link10:14
pedronismvo: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20170920_095013_d1ef4@/log.gz10:14
zyga-ubuntupedronis: 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 number10:17
pstolowskimvo, 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 that10:17
Chipacaniemeyer: added a couple of questions to the epochs topic, if you could when you can10:18
ppisatiogra_: ah, never mind, apparently changing sd card fixed the 'snap list' issue10:18
* Chipaca considers making epochs be written only in roman numerals10:19
pedroniszyga-ubuntu: mvo: there is code that closes statusW twice10:19
pedroniscould that be it?10:19
=== chihchun is now known as chihchun_afk
zyga-ubuntupedronis: yes10:19
zyga-ubuntupedronis: that can definitely cause this10:19
pedronisI thought the runtime would check for something10:20
zyga-ubuntupedronis: I don't think it can10:20
mvopedronis: ohhh, that sounds like it10:20
zyga-ubuntupedronis: well, in pure go world it could10:20
zyga-ubuntupedronis: reset the fd to -1 or similar after closing10:20
zyga-ubuntuthat's a safe way to do it10:20
pedroniszyga-ubuntu: IĀ mean have a flag around things, but maybe it doesn't10:21
* zyga-ubuntu nods10:21
zyga-ubuntupedronis: are you making a PR to change this?10:22
pstolowskimvo, nb, thanks for looking at refactoring this.. the logic good convoluted indeed, i'm having hard time every time looking at it10:24
pedroniszyga-ubuntu: ?10:24
zyga-ubuntupedronis: "there is code that closes statusW twice"10:24
mvopstolowski: yeah, its a bit tricky but of course there is a lot of conditions10:24
pedroniszyga-ubuntu: it's probably something for mvo to fix on the failing branch10:24
mvopstolowski: anyway I might push something very small and see if I can go from there10:25
pedroniszyga-ubuntu: mvo wrote that code , I'm not even sure IĀ remember why the code is like it is10:25
pstolowskimvo, on the positive side, we have good test coverage10:25
mvopedronis: sure10:25
mvopstolowski: yeah, that makes it very nice to work on the refactor \o/10:25
mvopedronis: I'm looking at this code now10:31
zyga-ubuntumvo: does this make any sense to you? http://pastebin.ubuntu.com/25578825/10:39
mvozyga-ubuntu: not right away10:41
mvopstolowski: 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 pr10:50
mvopedronis: I fixed the double close, thanks for catching this10:51
pedronismvo: hopefully it was that10:57
mvo+110:57
pedronismvo: 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.gz10:59
* zyga-ubuntu -> tea10:59
pedronissomething about TestRepairHasCorrectPath10:59
pedronisbut seems a timing issue10:59
pedronisor something11:00
pedronisbit confused11:00
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 dd11:01
niemeyerHeya11:02
niemeyerChipaca: Looking11:02
pedroniszyga-ubuntu: something very weird going on there11:03
pstolowskimvo, sounds good,thanks!11:03
=== JoshStrobl|zzz is now known as JoshStrobl
* sergiusens waves good morning11:15
pedronismvo: the other branch also has double close problems11:18
pedronisbit of a whack-a-mole landing these last bits11:18
pedronis:/11:18
mupPR snapcraft#1555 closed: store: switch to new endpoints <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1555>11:20
pedronismvo: is it annoying to split out the statusW fix to its own PR ?11:36
pedronisI'm getting a bit confused by all the autopkgtest red in your PRs11:41
pedronisI wonder why we didn't notice it before as well, that code is already on master :/11:45
cachiomvo, hey11:48
cachiostill see + snap install --edge test-snapd-upower-observe-consumer11:48
cachioerror: snap "test-snapd-upower-observe-consumer" not found (at least in channel11:48
cachio       "edge")11:48
mvopedronis: no, I can split it out, no problem11:51
pedronisthank you11:51
mvocachio: checking11:51
pedronismvo: it seems also that we have issues with TestRepairHasCorrect path, seems timeout is too low and also something is off on some releases11:52
pedroniss/Correct path/CorrectPath/11:52
mvocachio: fixing this now11:55
cachiomvo, tx11:56
cachiomvo, i was researching yesterday the autoimport service issue11:57
cachiomvo, it is failing when the device is using user assertions to create users by default11:57
cachiomvo, does it make sense?11:58
ondramzanetti are you around, mvo and pedronis are trying to figure out how to fix the problem11:58
mupPR 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
mupPR 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
pedronismvo: thank you, let's see how that goes and then we can merge it in the others12:01
diddledanpopey: I've just requested access to the google doc - my account is @bowlhat.net12:02
ogra_so british !12:02
diddledan:-p12:02
mupPR snapd#3945 opened: snap: refactor cmdGet.Execute() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3945>12:03
popeydiddledone!12:03
diddledanyey12:03
mvopedronis: +112:03
mvopedronis: thanks a lot for baby sitting these branches \o/12:03
mvocachio: *now* it should be there, sorry, amd64 and arm64 are just too close :/ I overlooked it12:06
mvocachio: it being test-snapd-upower-observer-consumer12:07
cachiomvo, great, tx12:07
cachiomvo, i am registering the device now but i have the same errror with the ubuntu-core-services12:07
ogra_mvo, that will be fixed once we switched to compiler names for arches ... aaaargh64 isnt that close to x86_64 :)12:08
cachiomvo, not sure if I need to refresh the core after that12:08
mvoogra_: will we switch? it seems like we trade amd64/arm64 against x86/x86_64 which is arguable a bit better12:10
ogra_i dont know, i just know there was a discussion started about it12:10
mvoondra, mzanetti: quick question, do you have the dns error just for refresh? or for any snapd network operation?12:11
mvocachio: 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:12
cachiowell, I have, 2 minutes, but it is really short the log12:13
mvocachio: no rush, take your time :)12:13
cachiomvo, what I saw is that when I use a user assetion with the image that test fails12:15
cachioand if I run manually console conf to register hte user, the test pass12:15
mvocachio: so the user assertion is valid? but does not work on first-boot?12:16
diddledanfor your eyes only https://forum.snapcraft.io/t/proposal-additional-package-sources/219912:16
mvopedronis: 3933 is ready now but needs a second review12:16
=== ShalokShalom_ is now known as ShalokShalom
cachiomvo, this is what I have https://paste.ubuntu.com/25579273/12:17
mvocachio: that is ok Sep 19 18:38:05 localhost.localdomain snap[1072]: error: cannot create user: device already managed12:17
mvocachio: I mean the error is expected if the machine is already managed12:17
cachiomvo,  Failed to start Auto import assertions from block devices.12:18
cachiomvo, not sure if it is related to the previous error in the log12:18
mvocachio: yeah, its the followup on the previous error12:19
mvocachio: 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 not12:20
mvo(the later is probably the best choice)12:20
cachiook12:20
cachioI am updating the code of the machines setup to first register a valid user and then refresh the core, does could help?12:21
cachiomvo, ~12:21
pedronismvo: 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.gz12:23
mupPR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>12:23
pedronismvo: as I said TestRepairHasCorrectPath needs some tweak12:23
mvocachio: probably, if the boot that does the tests does not have the block devices things should work12:24
mvopedronis: ta12:25
pedronismvo:Ā I saw it fail also in another different way, but that might be the other branch12:25
pedroniswhere the new code is not there12:25
pedronismvo:  we probably need to land #3944  #3933 and #3934 in that order12:26
mupPR #3944: snap-repair: fix double close of statusW (thanks to Samuele) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3944>12:26
mupPR #3933: snap-repair: make `repair` binary available for repair scripts <Created by mvo5> <https://github.com/snapcore/snapd/pull/3933>12:26
mupPR #3934: snap-repair: implement `snap-repair {list,show}` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3934>12:26
pedronismvo: otherwise is a bit too hard to tell if we solved the issues or not12:27
mvopedronis: yeah12:27
mvopedronis: I just pushed a fix for 3933, this should be good now, once that is green I merge the fix into the other branches12:29
mvopedronis: sorry for the back-and-forth12:29
mvozyga-ubuntu: yay, 3807 looks ready we just need to find a second reviewer12:31
mvozyga-ubuntu: actually jdstrand said "looks fine" soā€¦12:31
zyga-ubuntumvo: yes, I asked jamie to review12:31
zyga-ubuntuoh, he did?12:31
zyga-ubuntuah12:31
zyga-ubuntuI see, earlier12:31
zyga-ubuntuwell, let's merge it, I can conjure the fix for NFS that CE requested12:32
mvozyga-ubuntu: yeah, very early12:32
mvozyga-ubuntu: done12:32
zyga-ubuntugreat, thank you!12:32
mupPR 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 debian12:32
mvozyga-ubuntu: thats sad, it means I will have to do it12:32
pedronisthose failures were strange12:33
mvodo you think they are transient? is master ok again?12:33
pedronissome seemed to be about the fake directories12:33
pedronisdoesn't make much sense12:33
zyga-ubuntumvo: they were failing each time the same way for me (interactively)12:34
pedronisanyway repair tests are a bit in a strange state atm12:37
pedronisIĀ would wait to get a couple more things landed (with fixes)12:37
pedronisbefore pursuing that12:37
* zyga-ubuntu nods12:38
sergiusenshey niemeyer, mind looking at https://forum.snapcraft.io/t/proposal-additional-package-sources/2199/2 ?12:44
niemeyersergiusens: Looking12:55
pedronismvo: it's not  statusW,  same issues in that branch :/13:23
pedronishttps://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170920_125631_2e002@/log.gz13:23
pedronisor at least the change doesn't help13:24
sergiusenskalikiana do you have a fix lined up to only push snaps into the container if they differ?13:44
* zyga-ubuntu goes to make food and will be back with layouts shortly13:46
mvopedronis: yeah, I'm in a debian machine now and I can reproduce it ~50% of the time13:46
mvopedronis: also the other errors are super strange13:46
pedronismvo: I wonder which change introduced it though, because it appeared recently afaik13:47
pedronistime to bisect?13:47
mvopedronis: yeah, if I don't find anything soon I will bisect13:47
pedronisalso it seems indeed related to new go, because on 1.6 it doesn't seem to fail13:47
mvoyeah13:47
mvoor debian13:47
mvoI see the failure with go1.7.413:48
mvoin testing13:48
mvodebian/testing13:48
mvowhich is the same version that I have on my zesty system13:48
mvoso its even more mysterious13:48
pedroniswell debian has a newer go,    we see it fail in zesty and artful13:48
mvoI can not reproduce the failure in my zesty system13:48
zyga-ubuntumvo: also works on my artful FYI13:48
pedronisinteresting I seen autopkgtest for zesty fail with that13:48
mvoso it migt be artful13:49
pedronis(unless IĀ misremeber)13:49
mvo4.9 is debian13:49
mvo4.10 is what I have here13:49
mvoin zesty13:49
mvopedronis: oh, interessting, I have a look at the autopkgtests13:49
pedronismvo: 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.gz13:49
mvopedronis: yeah, also kernel 4.1013:50
mvopedronis: so strange13:50
sergiusenskalikiana mind updating this branch https://github.com/snapcore/snapcraft/pull/1382 ?13:51
mupPR snapcraft#1382: rust plugin: make libc configurable <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1382>13:51
pedronismvo: does go test -race tells anything interesting  on debian ?   (nothing interesing on 1.6)13:55
mvopedronis: not right now13:59
mvopedronis: I mean, no :/13:59
pedronismvo: 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 goroutine14:04
cachiopstolowski, https://paste.ubuntu.com/25579877/14:05
cachiothis test is failing on edge for ubuntu core14:05
zyga-ubuntuapparently 15 years later schoolkids still bully kids with longer hair14:06
cachiopstolowski, is it new? first time i see it fail14:06
pedronismvo: so double closing shouldn't be a problem,  later version have more complicated code but the result is the same14:06
pedronismvo: calling Close twice should error, not close the descriptor again14:07
zyga-ubuntupedronis: is the descriptor copied (as in memcpy) anywhere?14:07
pstolowskicachio, yes. it's very new, it just landed today or yesterday14:07
pedroniszyga-ubuntu: ?14:07
pstolowskicachio, I'll investigate14:07
zyga-ubuntupedronis: golang runtime errors aside it means we somehow did close a descriptor that was still in the epoll14:08
pedroniszyga-ubuntu: yes, but IĀ doubt it's us closing it14:08
pedronisI fear the runtime14:08
zyga-ubuntuaha14:08
cachiopstolowski, nice, we have fast feedback now :)14:08
pedronismvo: have you tried print the StatusW/R   descriptor number to see if they even match with what is in the error?14:08
pedroniszyga-ubuntu: internally when we close a runtime fs it replaces the fd number with -114:09
pedronisso the next Close should see that and error14:09
mvopedronis: no, I'm working on the other failures right now14:10
pedronisok14:10
mvopedronis: but thanks for this, I will try that next14:10
mvopedronis: I have a new theory, some of the other failures are because tests in autopkgtest runs as root but local run as user14:15
pedronismissing SetRootDir ?14:16
mvopedronis: yeah, or incorrect paths, I'm just look at this14:16
ondramvo 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
niemeyerChipaca: Forgot to mention, but your point about the conflict between snap pack and snap ack is a good one, btw...14:19
sergiusensmpt mind looking at https://forum.snapcraft.io/t/mechanisms-for-converging-store-and-snap-metadata/2200 ?14:20
niemeyerChipaca: Thinking about something else that would be equivalently terse and nice..14:20
ondramvo they are wondering if start of it is here https://github.com/snapcore/snapd/blob/release/2.27/httputil/retry.go#L8714:20
Chipacaniemeyer: yesterday in the standup i said it as well, and somebody proposed an alternative that was nice14:20
Chipacabut i don't remember it, or who14:20
Chipacazyga-ubuntu: was it you?14:20
niemeyersergiusens: Per note above, "pack" is probably changing due to the similarity with "ack"14:20
ogra_snap ack -> snapprove14:21
ogra_;)14:21
niemeyerogra_: That one has sailed14:22
ogra_i wasnt serious anyway :)14:22
mvopedronis: and I also suspect the epoll issue is root specific for whatever reason14:22
mvoondra: I have it on my list but there is amaster failure right now14:23
mupPR snapd#3946 opened: snap: add new `snap pack` and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3946>14:23
sergiusensniemeyer 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:23
ondramvo cool thanks14:24
niemeyersergiusens: I'm not suggesting that change right now14:24
ondramvo but please keep it high on priority list, as this is critical error for us14:24
niemeyersergiusens: For now I'd just like to get a command name that is the same on snap and snapcraft14:25
Chipacaincident at the boys school, need to run14:25
niemeyerChipaca: o/ take care14:25
sergiusensbut if we do `snap <pack-placeholder-name>` we should ensure the snap command can be installed without snapd to support build systems14:25
niemeyerChipaca: Hope it's all well there14:25
* sergiusens is looking out the window from a coffee shop as the gusts of wind blow things14:25
niemeyersergiusens: Yeah, let's not get there right now..14:25
sergiusensthey announced 40km/h to 60km/h wind14:26
mptlooking14:27
sergiusensniemeyer 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 best14:27
niemeyerHow about... squash :)14:29
niemeyersergiusens: ^14:31
niemeyermvo: ^14:31
sergiusenssounds 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 it14:34
zyga-ubuntumvo: about https://github.com/snapcore/snapd/pull/3946 - should there be a cmd_pack.go somewhere?14:34
mupPR #3946: snap: add new `snap pack` and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3946>14:34
niemeyersergiusens: You mean it's weird to say squash when you're squashing something? :)14:34
niemeyersergiusens: The outcome of this command consists almost entirely of running mksquashfs14:35
zyga-ubuntumvo: did you forget to add it? I don't see how "snap pack" would work otherwise14:35
mvozyga-ubuntu: oh oh14:35
zyga-ubuntugit add? :D14:37
mvo*cough*14:37
mvozyga-ubuntu: good that it is renamed :)14:38
niemeyersergiusens: With that said, I sort of agree otherwise.. for someone that isn't into the details, it may be an awkward choice14:38
niemeyermvo: Let me look further into the dictionary :)14:38
mvoniemeyer: snap collect?14:38
niemeyermvo: Misses the idea of "bundling".. actually.. bundle?14:39
mvoniemeyer: bunble works for me, the downside is that we can create a "bundle" of snaps in the future but I guess that is rather theoretical14:40
sergiusensniemeyer the first to things that popped into my mind were git squashing and the sport my wife plays :-)14:41
sergiusensbundle has a better ring14:41
niemeyermvo: Hmm14:42
niemeyermvo, 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 options14:42
sergiusenswe could go back to assemble14:42
sergiusens+114:43
mvo+1 from me as well, long but pretty precise14:43
sergiusensit was originally called assemble :-)14:43
sergiusensin snapcraft at least14:43
niemeyerCool, let's go with it then..14:45
niemeyerIt's okay that it's long.. snapcraft is what most people will use anyway14:45
* mvo will do14:45
niemeyerI was also looking for something that has a reasonable antonym for obvious reasons14:46
niemeyerdisassemble will do14:47
=== cachio is now known as cachio_lunch
mupPR snapd#3947 opened: snap-repair: fix tests when running as root <Created by mvo5> <https://github.com/snapcore/snapd/pull/3947>14:50
mvopedronis: this should fix the first part of the failures14:52
mvo(the easy part sadly)14:52
pedronisok14:52
mupPR 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:53
pedronismvo:  does running with -check.vv helps narrowing down the other issue to a single test?14:59
pedronisis the other issue related to root as well? or not?14:59
mvopedronis: good news, I have not seent the other failure anymore, however I now see http://paste.ubuntu.com/25580143/ in ~1/10 runs14:59
mvopedronis: 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 timeout15:00
mvopedronis: this one I only see in debian, I can not reproduce on zesty15:00
pedronisthat is curious15:00
pedronisthat the epoll went away like this15:01
pedronisbut good IĀ suppose15:01
pedronismvo: is it always the same test that times out, or a particular one?15:03
mvopedronis: I was wrong, its back, races are annoying15:03
mvopedronis: it looks like its happning in TestFetch50015:03
mvopedronis: looks like teardown15:03
mvopedronis: checking, it appears to be only TestFetch50015:07
pedronisit doesn't do anything special15:08
pedronisafaict15:08
mupPR snapd#3942 closed: doc: snapctl man page <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3942>15:12
zyga-ubuntuniemeyer: ^ 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 forum15:13
niemeyerzyga-ubuntu: What specifically do you disagree with in my comments?15:13
zyga-ubuntuniemeyer: both I suspect15:15
niemeyerzyga-ubuntu: As you can imagine, I still have no idea about what you mean15:15
* Chipaca back15:15
zyga-ubuntuniemeyer: we have non-generated manual pages today, not sure what makes it better if it is generated (in this particular case)15:15
niemeyerzyga-ubuntu: Do we have a non-generated manual page for the snap command?15:16
zyga-ubuntuniemeyer: and not sure why manual page cannot document how to use snpactl15:16
zyga-ubuntuniemeyer: we have non-generated manual pages for snap-confine, snap-discard-ns15:16
niemeyerzyga-ubuntu: Do we have a non-generated manual page for the snap command?15:16
zyga-ubuntuniemeyer: 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 anything15:18
=== cachio_lunch is now known as cachio
niemeyerzyga-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 reason15:19
mvopedronis: its very strange, it looks like in TestFetch500 it hangs in runner.Fetch() and not hit the test server in some cases15:19
zyga-ubuntuniemeyer: is that reason the fact that it is a complex command with sub commands?15:19
mvopedronis: almost as if httptest.NewServer() is not fully ready when it returns15:20
niemeyerzyga-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:20
zyga-ubuntuniemeyer: I disagree about the assumption that "foo --help" and "man foo" provide similar content15:21
zyga-ubuntuniemeyer: they provide a subset of the content that is the same but typically manual pages go to greater length about details15:21
mvopedronis: sstrace shows me a EAGAIN error in accept4() but the trace is really hard to read15:21
zyga-ubuntuniemeyer: (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 forum15:22
niemeyerzyga-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
pedronismvo: this is all bizarre because we have a lot of tests like this in many other unit tests, I wonder what is different here15:22
niemeyerzyga-ubuntu: We *have* a manual page for snap, today.15:22
zyga-ubuntuniemeyer: how is it any better if that prose is written in snapctl.go and echoed via --man mechanism? it's still text that needs maintenance15:23
niemeyerzyga-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
niemeyerzyga-ubuntu: Exactly!15:23
niemeyerzyga-ubuntu: That text already exists!15:23
mvopedronis: yes, especially since it is always the same test apparently but we have many that use the retry strategy and that use the mock server15:23
niemeyerzyga-ubuntu: Type in: snapctl get --help15:23
pedronismvo: does it fail also run alone?15:24
niemeyerzyga-ubuntu: Why on earth would we maintain that by hand elsewhere?15:24
zyga-ubuntuniemeyer: "snapctl --help" doesn't tell you anything about the purpose of the tool15:25
zyga-ubuntuniemeyer: it's fine to generate everything if we can put that text somewhere15:25
niemeyerzyga-ubuntu: Feel free to fix that, after layouts. :)15:25
zyga-ubuntuniemeyer: (and arguably showing it in --help is not very useful)15:25
niemeyerzyga-ubuntu: Not okay to duplicate documentation. We've been there, I know where this goes.15:26
=== chihchun_afk is now known as chihchun
mvopedronis: it does not, it works when I run it alone, it survived ~400 runs now15:26
pedronismvo: so it's the combination with something else, but what?15:26
zyga-ubuntuniemeyer: 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 generator15:27
zyga-ubuntuniemeyer: that's all I wanted to say, we've made our points I think15:27
niemeyerzyga-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:28
niemeyerpstolowski: 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:30
pstolowskiyes, 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 document15:31
pstolowskii was under impression (wrong one apparently) that we're moving away from auto-generated man15:32
mvopedronis: ok, when I skip the fetch500 it appears in fetchBroken so it seems related to the retry strategy15:33
niemeyerpstolowski: Do you seriously want to write and maintain the snap manual page by hand?15:33
pedronismvo: are we sure is not related to tests before?15:33
pedronismvo: you said it works alone15:33
mvopedronis: it could be, let me try some more15:33
mvopedronis: it does15:33
pstolowskiniemeyer, depends how rapidly the command changes. snapctl does't change too often15:34
pedronismvo: what if you run just cmd_done_retry_skip_test.go and Fetch500 ?15:34
pedronisthat's the only thing that is recent15:34
pedronisly added15:34
=== ikey|zzz is now known as ikey
cachiopstolowski, the snap-run-hook test is also failing on my dragonboard15:34
niemeyerpstolowski: 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
cachioi have a debug session open15:34
cachiopstolowski, do you need some information?15:34
niemeyerpstolowski: ... when we tend to fail to maintain documentation up-to-date even when it is in *one* place.15:35
pedronismvo: maybe just this  +go test -check.vv -check.f "StatusHappy|Fetch500"  ?15:35
pstolowskicachio, is it possible to recreate on linode? if so, can you give me the details (in the meantime I'm checking locally)15:36
pedronismvo:  or +go test -check.vv -check.f "TestStatus|Fetch500"15:36
mvopedronis: yeah15:36
pedronisdoes it fail like that?15:37
mvopedronis: yes, I found it I think! misisng close in one of the status tests, thank you so much for your intuition on this one15:38
pedronisthe os.Pipe in status Happy?15:38
mvopedronis: yes15:38
pedronisseems a bug in the rumtime though :)15:38
pedronissorry, IĀ mean :(15:38
pedronisit shouldn't interfere like that15:38
cachiopstolowski, I can reproduce it just on real ubuntu cores15:38
cachiopstolowski,15:39
cachiohttps://paste.ubuntu.com/25580415/15:39
cachioit is not resolving the env vars15:39
ppisatiogra_: 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" error15:39
mvopedronis: definitely, very strange15:39
cachioTEST_COMMON=$SNAP_COMMON instead of TEST_COMMON=/var/snap/basic-hooks/common15:40
ogra_ppisati, i think that only works if the original kernel snap was actually a local snap when you built the image15:40
mvopedronis: the side-effects of this are not at all obvious15:40
cachiopstolowski, you can create a vm with ubuntu core and reproduce it on there15:40
ogra_i.e. if snap list shows it as x115:40
ogra_ppisati, but do you need the modules ? if just testing vmlinuz you can simply replace it on the vfat15:41
ppisatiogra_: uhm, ok, let me try that15:41
cachiopstolowski, i can provide you any information of the exec15:41
=== zyga-ubu1tu is now known as zyga-ubuntu
mupPR snapd#3948 opened: snap-repair: fix missing Close() in TestStatusHappy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3948>15:42
cachiopstolowski, just tell me what you need15:42
pedronismvo: IĀ know, IĀ think I understand,  we are passing in the same runtime the  FD as a int15:42
pedronismvo: so at that point is not under runtime control anymore15:42
pedronisso when it gets close we close something random15:42
pedronismvo:Ā if we don't do it ourselves15:43
pedronismvo: we are causing a double close somehow15:44
pedronismvo: I'm not even sure how to avoid it15:45
mvopedronis: make sense. I need to take a break, lets see if the world is a more happy place once the branches are in15:46
pedronismvo: does those close help?15:47
pedronisI suppose they do because we control when the double close happens15:48
pedronisit still happens though15:48
pstolowskicachio, 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:51
pedronisyes, double close still happens and where we expect it15:52
pedroniszyga-ubuntu: so it was a double close but in a more interesting place15:52
zyga-ubuntupedronis: oh, I'm curious to learn16:01
zyga-ubuntupedronis: where was it?16:01
pedroniszyga-ubuntu: we have a test that passes around a fd through an env variable but in the same process, not across processes, fun ensues16:05
zyga-ubuntupedronis: aah16:08
zyga-ubuntupedronis: so it was "copied" as I was wondering16:08
zyga-ubuntu(well copied as in memcpy, not dup)16:08
zyga-ubuntupedronis: interesting find, does that bring master to sanity?16:08
cachiopstolowski, I am updating the core from adge again16:09
cachiopstolowski, and rexec to see the results16:09
pedroniszyga-ubuntu: copied as we end up with two os.File with the same fd without the runtime knowning this16:12
pedronisapparently16:12
* sergiusens is looking at his battery drop during the blackout16:13
zyga-ubuntupedronis: right, sadly that's exactly the case16:13
zyga-ubuntujdstrand: hey, I saw your nvidia PR, I'll get to it soon16:13
=== chihchun is now known as chihchun_afk
lutostag_anybody got an idea why I might be hitting https://bugs.launchpad.net/snappy/+bug/1659719 ?16:40
mupBug #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 looks16:40
ogra_lutostag_, is the file there ?16:40
* ogra_ just commented on the bug a minute ago 16:41
lutostag_ogra_: indeed it is16:42
ogra_i definitely see it everywhere on classic installs as well as on devices16:42
lutostag_hah, good timing ;)16:42
ogra_lutostag_, hmm, do you use some weird shell like zsh ?16:42
lutostag_nope lxd, with bash16:42
zyga-ubuntulutostag_: it might be ssh and pam doing some fancy variable sanitization16:42
ogra_(or some other that wouldnt parse profile.d on login)16:42
lutostag_if I do ssh ubuntu@ip "juju-crashdump" it fails16:43
zyga-ubuntuwhat is the target OS that hosts snaps?16:43
ogra_lutostag_, ah16:43
ogra_lutostag_, that wont spawn a shell16:43
lutostag_because profile isnt executed without -l16:43
nacclutostag_: you need a login shell16:43
ogra_lutostag_, right16:43
zyga-ubuntuah, that bug is pretty well triaged already16:43
ogra_well,16:44
nacce.g., ssh ubuntu@ip bash -l -c juju-crashdump16:44
ogra_openssh people would tell you "notabug" :)16:44
lutostag_that is confusing for me, yeah16: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:44
ogra_if you have control of the image build you could indeed modify /etc/environment16:46
* zyga-ubuntu downloads ubuntu ISO for the Nth time in his life16:46
zyga-ubuntuI need to figure a way to keep those arund16:46
zyga-ubuntu*aroud16:46
zyga-ubuntu*around even16: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/416:46
mupBug #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:46
ogra_lutostag_, doesnt help if you dont run bash ...16:47
ogra_ssh ubuntu@ip <command> will use /bin/sh ... not bash16:47
* zyga-ubuntu sets up NFS in a VM, better safe than sorry16:49
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 found16:50
lutostag_seems like an error from bash for me...16:51
nacclutostag_: you aren't running a login shell16:51
ogra_add -l or use /bin/bash -c16:51
lutostag_gotcha, thanks16:51
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:55
ogra_lutostag_, thats a question for foundations :)16:57
naccheh16:57
ogra_you can definitely not do it retroactively though16:57
ogra_(so yes, the installer/iso  would have to have that change)16:59
naccand presumably would need to dtrt on upgrades, etc.; seems pretty invasive :)17:03
niemeyermvo, sergiusens: One last idea before closing down on assemble: fold/unfold17:07
naccwhat voodoo do i need to invoke to have the beta/candidate channels for my snap follow edge as it is now?17:09
niemeyermvo, sergiusens: I like this one a bit more than assemble because it has that very cheap feeling.. not a lot is happening when we fold17:11
elopionacc: if you want edge, candidate and beta to be the same, release the revision to candidate, and close the other two.17:11
naccelopio: yep, just realized that :)17:12
* niemeyer steps out17:13
* zyga-ubuntu is stuck in a traffic jam17:28
=== cachio is now known as cachio_afk
naccit feels like this message could be improved (fro sudo snap refresh git-ubuntu): error: cannot refresh "git-ubuntu": snap "git-ubuntu" has changes in progress17:34
naccchanges where?17:34
zyga-ubuntunacc: in snapd, there are "snap changes" that affect it17:35
nacczyga-ubuntu: ah, meaning it's currently doing an update from the store?17:36
zyga-ubuntunacc: `snap "git-ubuntu" is being processed by snapd`17:36
zyga-ubuntunacc: any change involving that snap17:36
nacczyga-ubuntu: ah ok, yeah that would be clearer to me17:36
zyga-ubuntunacc: (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 modification17:36
naccis 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:46
naccso i'd like to just remove it from the store, untile we get around to enablinng it properly17:47
zyga-ubuntunacc: ask store people, I don't know really17:51
nacczyga-ubuntu: ok, thankns17:52
Chipacaok, this epoch thing isn't going out today18:21
* Chipaca wraps up18:21
posiI 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:22
naccposi: you're doing a local snap install (of a local snap file)?18:27
posiWell I build the snap file yea18:27
posiand then i wanted to test it18:27
posiand got that error18:27
posiperhaps i wont get it if it goes to a repo?18:27
naccposi: yes, you'll need to use --dangerous18:27
posijust because it's not going through a signed repo?18:27
naccposi: 'verified', in this context, i think means it comes from the store18:27
naccposi: i'm not sure, though18:27
posicools town18:28
posii wont worry about it then18:28
naccposi: 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
naccposi: so it's not surprisinng to me, at least :)18:28
zyga-ubuntuposi: yes, that's exactly what's going on18:28
zyga-ubuntuposi: you don't have store-signed assertion if you build locally18:28
posimakes total sense18:28
posithanks y'all18:28
nacczyga-ubuntu: thanks for confirming18:28
posialso18:29
posiwe are using linux namespaces for security18:29
posiso i had to switch to confinement classic18:29
posicurious what y'all imagine apps should do who use user naemspaces like us and chromium18:29
naccposi: 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:31
zyga-ubuntuposi: it's possible18:32
naccposi: also, there's LP: #158654718:32
mupBug #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-ubuntuposi: depending on what you mean specifcally, chromium uses a number of thins together so it needs a privileged interface18:32
jdstrandposi: you don't have to use classic for linux namespaces with electron18:34
jdstrandposi: are you brave upstream?18:34
jdstrandposi: if you are, see https://github.com/snapcore/snapd/wiki/Interfaces#browser-support18:35
posijdstrand: yes18:36
posijdstrand: right it's not an electron thing18:36
posijdstrand: it's a how we secure our rendering thread18:36
jdstrandposi: you can set an interface attribute. this is, for example, what the chromium snap is doing18:36
jdstrandposi: right. use 'allow-sandbox: true'. that should allow brave to do what it needs, just like chromium and chrome18:37
posigreat!18:37
jdstrandin strict mdoe18:37
jdstrandmode*18:37
jdstrandposi: that attribute is intended to be used by trusted upstream browser publishers (eg, Chrome/Chromium, Firefox, ...). Brave certainly fits that category18:38
posiyep18:38
zyga-ubuntujdstrand: o/18:38
zyga-ubuntujdstrand: I didn't get to your nvidia PR yet, sorry18:39
zyga-ubuntujdstrand: on the upside I'm working on tests for NFS18:39
posiCan I cleanup this conversation, remove your names and summerize it in a PR to the electron-builder community?18:39
jdstrandposi: 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 this18:39
jdstrandzyga-ubuntu: no worries18:39
jdstrandposi: well... for the average electron app, they should *not* use allow-sandbox: true18:40
jdstrandposi: and just rely on the snappy sandbox18:40
posiRight we'd add a allow blah18:40
jdstrandposi: 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 confinement18:41
jdstrandposi: so we very tightly restrict its use18:42
posiRight18:42
posiso would we want both of them on18:42
posiin the case of a browser18:42
posior is browser-support legit18:42
jdstrandbrowser-support is fine for a browser that is configured itself with --disable-sandbox18:43
jdstrandit relies on the snappy sandbox only18:43
posino we want enable-sendbox18:43
posi*sandbox18:43
jdstrandI know you do18:43
posiahh ok18:43
posiso i want both then18:43
jdstrandI'm saying for the general case18:43
posisure18:43
mupPR 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
jdstranda trusted publisher who has a browser that is in use by tons of users, allow-sandbox: true makes sense (Brave, Chrome, etc)18:44
jdstrandanyway, it is a fine point18:44
jdstrandI just want to make sure people don't see it and are like 'sure I want all of this' since there will be store friction18:45
jdstrandat some point, apparmor will better work with user namespaces and we won't need to guard this so carefully18:46
jdstrandie, we need to grant 'capability sys_admin' to the snap18:46
jdstrandbut the snap only needs sys_admin in the user namespace18:46
jdstrandbut, today, it only shows up as sys_admin, regardless if it is system namespace or user namespace (this is but one example)18:47
posiyea18:47
posidude, i still can't believe the archlinux would prefer a setuid binary to a linux namespace binary18:47
jdstrandposi: 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
jdstrands/for use/for distribution/18:48
jdstrandwordsmith as desired18:49
jdstrandposi: well, it isn't like user namespaces haven't had any CVEs :P18:49
posiTrue but if they knew what i knew about how drm worked....18:49
jdstrandthat code was a CVE factory for awhile :)18:49
zyga-ubuntujdstrand: unprivileged user namespaces/18:50
jdstrandbut 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 eventually18:50
posihttps://github.com/electron-userland/electron-builder/issues/210018:51
jdstrandzyga-ubuntu: that's what I was talking about, yes18:51
jdstrandwill left?18:51
zyga-ubunturight, I was just checking18:51
jdstrandwe'll lift18:51
jdstrandposi: 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 together18:53
posiYay18:53
jdstrand(but again, no fixed timeline)18:53
jdstrandin fact, I'll just grant it to the snap now so you can just upload away18:53
* jdstrand thought he might've already done that18:54
jdstrandno, I did not18:54
jdstrandposi: ok granted. I'm not sure if you've used interface attributes before, so here you go: http://paste.ubuntu.com/25581549/18:58
kyrofaHey everyone19:12
zyga-ubuntuhey kyle19:12
kyrofasergiusens, I'm finally at the hotel and settled19:12
sergiusenskyrofa and I finally have electricity again!19:14
zyga-ubuntu1st world / 3rd world problems19:14
zyga-ubuntuat least we are all on IRC19:14
sergiusenszyga-ubuntu apparently the 80km/h winds affected the grid :-/19:15
kyrofaOh dang, storming down there eh?19:15
zyga-ubuntusergiusens: I'm sorry, I was kidding, it's not a fun time for a good chunk of the world :/19:16
sergiusenszyga-ubuntu we are on the good side of it, our bad weather and flooding is around the middle of summer (Jan/Feb)19:18
=== cachio_afk is now known as cachio
pedronismvo: thanks for merging, as you have seen IĀ added some more description that you included19:26
mupPR snapd#3949 opened: cmd/snap-repair: skip disabled repairs <Created by pedronis> <https://github.com/snapcore/snapd/pull/3949>19:32
mupPR 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:39
mvopedronis: yeah, thank you for your extra comments19:48
pedronismvo: IĀ proposed my Dup variant (for extra paranoia)20:01
sergiusenselopio around?20:02
elopiosergiusens: pong20:04
jdstrandstgraber: 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
sergiusenselopio well, retroactive ping then ;-)20:05
sergiusenselopio how about updating those PRs so they land?20:05
stgraberjdstrand: hmm, your containers reboot when lxd updates? that's not normal20:05
stgraberjdstrand: can you pastebin "journalctl -u snap.lxd.daemon"?20:06
jdstrandstgraber: well, I'm assuming. I ssh in then the connection drops. maybe it is something else?20:06
mvopedronis: thanks, looking20:06
jdstrand(not immediately drops mind you-- I thought with updates, maybe not)20:07
* jdstrand journalctls20:07
stgraberjdstrand: ah, LXD re-applies its network config on daemon startup, I wonder if that's somehow enough to disconnect ssh20:07
elopiosergiusens: 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 -120:07
elopioare you talking about those?20:08
sergiusenselopio yes, those; also followup on my docstrings20:08
sergiusenselopio and do you have a minute to run a test?20:08
mvopedronis: one question inline, but I call it a day now, things look good20:08
sergiusenselopio need your publisher-id for staging (snapcraft whoami)20:09
jdstrandstgraber: http://paste.ubuntu.com/25581972/ (yes, snap refresh)20:09
jdstrandwell20:10
jdstrandthat was last night20:10
stgraberjdstrand: ok, that should be fine, it detected the refresh which means it shouldn't have brought down containers20:10
jdstrandstgraber: I don't have anything from the last few minutes in the log20:10
=== JoshStrobl is now known as JoshStrobl|AFK
elopiosergiusens: sure. Do you need my id, or do I need my id to run the test?20:11
jdstrandstgraber: I did move from one wifi network to another. could that cause it?20:11
jdstrandwhere 'it' is network restart20:11
stgraberjdstrand: unless network-manager is doing something very very wrong, it shouldn't20:12
stgraberjdstrand: what's "uptime" showing inside one of your containers?20:12
pedronismvo: 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:12
jdstrandstgraber: 20:13:48 up 11:15,  2 users,  load average: 0.42, 0.53, 0.6820:14
stgraberjdstrand: and you got disconnected less than 11 hours ago?20:14
sergiusenselopio I need your id to share a snap with you and then ask you to push a new version20:14
jdstrandstgraber: I thought so, but I have several others ssh sessions that are up that survived the AP change20:15
jdstrandstgraber: I closed that terminal. It might've been lingering since yesterday20:16
jdstrand(sorry for closing that one)20:16
jdstrandso, it sounds like a snap refresh might restart the network20:16
elopiosergiusens: wait, my user on staging has 2fa enabled, but the staging 2fa was my ubuntu phone.20:16
elopiolet me register a new user.20:16
stgraberjdstrand: 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
jdstrandhmm20:17
jdstrandoh20:17
jdstrandstgraber: I wonder if it is because it got an IP address change20:18
stgraberthat 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:19
jdstrandstgraber: 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 it20:20
* jdstrand wonders if there is a better way20:20
stgraberHost *.lxd20:20
stgraber  StrictHostKeyChecking no20:20
stgraber  UserKnownHostsFile /dev/null20:20
stgraber  ProxyCommand nc $(lxc list -c s4 $(echo %h | sed "s/\.lxd//g") %h | grep RUNNING | cut -d' ' -f4) %p20:20
stgraberin .ssh/config20:20
naccstgraber: feels like that should be in the manpage :)20:21
jdstrandstgraber: 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
naccstgraber: i remember that makinng a huge difference to me :)20:21
stgraberjdstrand: 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 entry20:22
jdstrandI see20:22
jdstrandwell, I seem to be on the stable train then20:22
elopiosergiusens: DPKYnDYokujK66geceR4EdcVEi4tekzr20:23
sergiusensnessita 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
sergiusenselopio will have to wait a bit :-)20:26
sergiusenswell, the dashboard allowed me to fix, so no hurry here20:27
jdstrandstgraber: curious, does the *.lxd work with up-to-date artful and systemd-resolved?20:28
jdstrandI've had no end of trouble with resolved and libvirt and lxd20:29
naccjdstrand: i'm on it currently and yes20:29
naccjdstrand: note, not using the snnap, though, but i don't think that hsould matter on artful?20:29
jdstrandI wouldn't think so20:29
sergiusenselopio did you get an email or something? if not straight out make a simple modification to this http://paste.ubuntu.com/25582065/ and push please20:30
Pharaoh_Atem:/20:30
sergiusensPharaoh_Atem out of nowhere non smiley emoticons are not allowed ;-)20:30
kyrofaBut smiley ones totally are20:31
Pharaoh_Atem^_^20:31
nessitasergiusens, hum yes! you should get the default store by default!20:31
nessitasergiusens, let me triple check20:31
nessitasergiusens, is this from snapcraft?20:32
sergiusensnessita yes20:32
nessitasergiusens, checking20:32
nessitasergiusens, is it a name you already own, right?20:32
jdstrandnacc: for libvirt, I have a crazy script to use gdbus to call SetLinkDNS and SetLinkDomains. it shouldn't be this hard20:33
sergiusensnessita https://pastebin.ubuntu.com/25582089/20:33
jdstrandnacc: you have a standard install?20:33
sergiusensnessita and yes, I think I registered it before you made the change, just never "pushed" anything until today20:33
sergiusensmight be corner casey :-)20:34
jdstrandI should probably talk to xnox20:34
nessitasergiusens, it should still use the default store, let me find where the bug is20:34
* jdstrand -> ubuntu-devel20:34
elopiosergiusens: no mail20:34
nessitasergiusens, could you please file me a critical bug while I fix?20:35
naccjdstrand: yeah20:35
* cmars looks up from the corner20:35
nessitasergiusens, hum I've just reproduced in prod, so I will fix asap20:37
elopiosergiusens: pushed revision 220:37
mupPR snapcraft#1558 opened: tests: add fake pip fixture <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>20:42
nessitasergiusens, got my reply?20:51
mupPR 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:00
sergiusensnessita yes, sure thing21:19
sergiusenswent for a short walk to stretch my legs :-)21:19
nessitasergiusens, branch with fix is on its way to trunk but the bug would be good for tracking21:20
sergiusensnessita LP: #1718540 although I cannot set the Importance21:24
mupBug #1718540: default store not set on registered snaps <Snap Store:New> <https://launchpad.net/bugs/1718540>21:24
nessitasergiusens, thanks!21:24
sergiusenskyrofa I am confused by your PR22:03
kyrofasergiusens, I realized after I opened it that it contains roughly zero documentation :P22:04
kyrofaI'm fixing that. But are you confused beyond that?22:04
kyrofaAh, I see your comment22:05
kyrofaFirst, 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-0081187be45e5e561b2da7a6516c2f17R53322:06
mupPR snapcraft#1558: tests: add fake pip fixture <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1558>22:06
kyrofaWhile the change is small, it's suddenly testing more than just list22:07
sergiusenskyrofa oh, I forgot to mention, that was kind of like the only place it made sense22:07
kyrofaYes, agreed. I'm proposing it now so that it can be used in the catkin and python PRs22:08
sergiusensit still feels a bit heavy22:08
kyrofasergiusens, but it's also up for discussion, of course22:08
sergiusensas you end up calling fakes for those which "do things"22:08
kyrofasergiusens, well, yeah, wouldn't it be a mock otherwise?22:08
kyrofasergiusens, elopio was talking about how he wanted to test the entire path of the class (install something, list what you installed)22:09
kyrofasergiusens, 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 files22:09
kyrofaYou want to talk about heavy...22:10
kyrofaelopio, you around?22:10
sergiusenskyrofa 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 here22:10
kyrofasergiusens, that's totally fair22:10
kyrofasergiusens, ignoring the fake though, I love the spy22:11
elopioYup22:11
sergiusenskyrofa it almost feels like creating a fake python interpreter you actually call which interacts with our code would be simpler and more straight forward22:11
kyrofaHahaha22:11
sergiusenswould feel more in line with the fake servers22:12
kyrofaelopio, I proposed the fake implementation I showed you when you get a minute to take a look22:13
sergiusenselopio 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 crazy22:13
elopioI'm looking22:16
elopiosergiusens: this error: https://paste.ubuntu.com/25582589/22:20
sergiusenselopio good, I just don't like the error message :-)22:29
sergiusensthat __all__ is just, ..., don't have the words...22:29
elopioI said the same ;)22:30
kyrofaHeh22:39
* sergiusens will bbiab22:39
mwhudsonanyone around to help write a spread test?23:57
mwhudsonthis line https://github.com/snapcore/snapd/pull/3872/files#diff-fbc5a3aafffbc409b850466293abe66dR20 fails with "/bin/bash: line 65: SNAPMOUNTDIR: unbound variable"23:58
mupPR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>23:58
mwhudsonwhich doesn't make any sense to me given the line just above23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!