/srv/irclogs.ubuntu.com/2019/01/31/#snappy.txt

mborzeckimorning06:20
mvohey mborzecki06:22
mborzeckimvo: hey06:22
mborzecki47 PRs06:22
mvomborzecki: indeed, looking good06:26
mupPR snapd#6434 closed: interfaces: add u2f-devices interface (2.37) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6434>06:35
mupPR snapd#6458 opened: snapd,state: improve error message on state reading failure <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6458>06:44
mborzeckimvo: about #6458, did that happen often in your tests?06:50
mvomborzecki: just once06:50
mupPR #6458: snapd,state: improve error message on state reading failure <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6458>06:50
mborzeckimvo: error message will certainly be useful, i recall we had a case in the forums where state.json was corrupted and the contents were actually part of some other file :/06:52
mvomborzecki: yeah, its not super helpful but at least it gives people a clue06:53
mvomborzecki: error: EOF is really saying nothing :/06:53
mborzeckimvo: we could have done worse, eg 'error: failed' :)06:54
mvoheh: "error: computer says no"06:54
mvomborzecki: we should probably have noticed that the error is not great when writing the unit test with the error - oh well06:55
mupIssue core18#118 closed: fw_printenv is not present in core18 <bug> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/core18/issue/118>06:58
mborzeckimvo: #6417 can be landed now?08:12
mupPR #6417: snap: fix reexec from the snapd snap for classic snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6417>08:12
mvomborzecki: yes, good catch08:13
mupPR snapd#6417 closed: snap: fix reexec from the snapd snap for classic snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6417>08:14
=== pstolowski|afk is now known as pstolowski
pstolowskimornings08:22
mborzeckipstolowski: hey08:24
mvogood morning pstolowski08:27
mwhudsonwhen did /v2/find?name=foo start including information on whether the publisher was verified?08:30
mwhudsonmust be a while ago08:30
pstolowskimvo: will do beta validation core18 - upgrade pi308:30
mvopstolowski: thank you08:33
pedronismwhudson: quite a while ago, yes08:42
pedronismwhudson: https://forum.snapcraft.io/t/how-to-display-account-names-and-usernames/4007/408:43
pedronismvo: comment on 645808:46
mupPR snapd#6459 opened: tests: iterate getting journal logs to support delay on boards on daemon-notify test (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6459>08:48
mvopedronis: thanks, checking08:50
mupPR snapd#6460 opened: snap: fix hook autodiscovery for parallel installed snaps (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6460>08:50
mvopedronis: ta08:51
mupPR snapd#6454 closed: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6454>08:59
mupPR snapd#6455 closed: interfaces/apparmor: deny inet/inet6 in snap-update-ns profile (2.37) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6455>08:59
mvomborzecki: thanks for your reviews btw :) really appreciated08:59
mborzeckimvo: had some suggestions in #6456, actually made me revisit gio again09:00
mupPR #6456: interfaces: add network-manager-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6456>09:00
pedronisdo we know why is targeted at 2.3709:01
mvomborzecki: yeah, I saw that, its great feedback09:01
pedronisit's a full new interface09:01
mvopedronis: probably just because jamie wants it there and its low regression risk09:01
mvopedronis: not sure if there is more to it, it seems he is doing that for most of his interface PRs09:01
pedronisnot completely a fan tough09:02
pedroniswhen is this interface supported09:02
pedronis2.37.209:02
pedronisnot a nice answer09:02
mvoyeah, trouble is if we push it into .38 and there is a .2 then .38 will be delayed by ~2w or so and I guess jamie does not like that09:03
pedronismvo: what if it's broken in some ways09:04
pedronisdo we do a 2.37.3 ?09:05
pedronisI marked it blocked for now09:05
pedronisI would like to understand09:05
pedronisthe urgence09:05
mvopedronis: thats fine09:05
pedronismvo: notice that there is no real spread test for this thing afaict09:06
pedronismvo: we already added in u2f-devices in .1 right?09:08
mborzeckianyone updated go to 1.11.5 ?09:08
pedronisor is it for .2?09:09
pedronismvo: as I said I find a bit problematic that these things don't come with real tests09:10
mvopedronis: right - we should discuss this with jdstrand then - maybe we can offer help with this when sergio is back. we had no hard rule about it so far :/09:13
pedronismvo: I don't have a strong opinion, but merging them late and not tests doesn't seem a good combo09:13
mvopedronis: *nod*09:14
* zyga crawled to his laptop09:15
zygaI will be off today09:15
mvozyga: get well!09:16
pedroniszyga: get well!09:16
pedronismvo: but yes, a chat with jdstrand seems good09:22
=== phoenix_firebrd is now known as murthy
pedronismvo: can we create a 2_38 tag in the forum09:44
pedronismvo: for example for this: https://forum.snapcraft.io/t/risk-only-channel-requests-vs-pinned-default-tracks/933209:44
mvopedronis: sure09:48
mvopedronis: done09:49
pedronismvo: thank you09:52
mupPR snapd#6459 closed: tests: iterate getting journal logs to support delay on boards on daemon-notify test (2.37) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6459>09:55
mupPR snapd#6458 closed: snapd,state: improve error message on state reading failure <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6458>09:56
kissielmvo: hey! got a minute? I'd like to close that thread about checkbox crash you had couple of days ago. First of all, I think I fixed it - python wheel present on PyPI had some no longer supported syntax in its metadata. I removed it, and released a newer version that snaps fine. I modified the part accordingly in that test snap definition09:58
kissiel(https://github.com/kissiel/snapcraft/commit/8d5b91a3dd398d224a9d957344613401a2266570)09:58
kissielmvo: but from what I can tell, that test was disabled since Oct '18. So that patch also re-enables it.09:59
kissielmvo: makes sens? shall I propose that PR?09:59
* Chipaca takes a break10:01
pstolowskimvo: hey, thanks for refactoring of canInstallSnapdSnap, it's intention is now much cleaner! i'm still slightly confused though about what we want vs what's in the description of the PR (I'm probably missing something) - it seems we will transition automatically if base/model exists, regardless of the experimental flag, and the flag will only be used with other models. is that intended?10:02
mvopstolowski: its a good point you raise. all current models that use a base snap also have the snapd snap - however it is confusing so I will look if this can be expressed better. maybe the canInstallSnapdSnap is already too much - it mixes two things which is probably shouldn't (can-it-be-installed and should-it-be-installed is mixed)10:07
mvopstolowski: I pasted your comment into the PR10:08
pstolowskimvo: right, thanks!10:09
pedronismvo: I do plan to start looking at your big PRs today and tomorrw btw, I added myself to them10:11
mvopedronis: thank you10:13
pstolowskimvo: 1-1?11:04
mupPR snapd#6460 closed: snap: fix hook autodiscovery for parallel installed snaps (2.37) <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6460>11:17
pstolowskimvo: ah, false alarm, it's tomorrow ;)11:29
pstolowskisorry11:29
mvopstolowski: :)11:33
mvopstolowski: no worries11:34
pedronisChipaca: hi, could you review when you have a moment the last commint in #641511:54
mupPR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>11:54
mupPR snapd#6461 opened: snap-confine: provide proper error message on sc_sanity_timeout <Created by mvo5> <https://github.com/snapcore/snapd/pull/6461>12:11
mupPR snapd#6462 opened: snap-confine: fix incorrect "sanity timeout 3s" message <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6462>12:18
Chipacapedronis: did you see my comment in that one?12:25
pedronisChipaca: it didn't sound a blocker, tough? it's orthogonal no?12:26
Chipacapedronis: ye12:27
pedronisChipaca: does it still have your +1 ?12:27
Chipacaas i said i would, i added a card :-)12:27
pedronisthat's my question12:27
Chipacapedronis: it's even got an extra +1 for good measure12:27
mupPR snapd#6463 opened: [RFC] snap-confine: increase locking timeout to 30s  <â›” Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6463>12:33
zygamvo: fyi, indent is unstable across systems12:34
pedronisChipaca: thx12:35
Chipacamvo: which indent?12:36
pedronisChipaca: the C(++) formatter12:38
pedronisI think12:38
mborzeckizyga: mvo: we have a make target to call clang-format12:39
zygawe have one12:40
zygaread the makefile.am, there are two sets of files12:40
zygaone formatted with indent12:40
zygaother with clang-format12:40
zygaboth are unstable though12:40
zygaso it's just what you prefer, I guess12:40
zyganote: clang-format is 10x better12:40
pedronisChipaca: me is confused, isn't the order of channels in that message wrong12:40
zygaso over time we will switch12:40
pedronisah, no12:40
mborzeckipedronis: which message?12:40
pedronismborzecki: nvm12:40
leinardiHi, I'm still trying to distribute GWE with Snap but I'm stuck with this error: https://forum.snapcraft.io/t/help-porting-gwe-nvidia-info-and-overclock-app-to-snap/9440/1112:43
leinardiany idea of what is the issue?12:43
pstolowskimvo: finished upgrade tests on rpi3, 2 failures http://paste.ubuntu.com/p/BmsVGpgTMF/ , both we had seen yesterday already12:46
zygaleinardi: replied12:55
pedronispstolowski: btw, now that we switched to newer gos, we need to try to go back addressing the EnsureBefore issues12:55
pstolowskipedronis: right, great12:55
pstolowskiwill re-visit it12:56
pedronispstolowski: thx13:01
mborzeckioff to pick up the kids13:07
jdstrandoSoMoN: ok, u2f-devices will be in 2.37.2 (pr committed thanks to mvo)13:09
jdstrandpedronis (cc mvo): added PR 6457 for 2.37 in case you could accept it. it is fine if you don't. Adding new interfaces is low risk imho because nothing can regress cause nothing uses it. added that one cause it is of interest to kde and thought it would be nice for them instead of waiting N weeks13:14
mupPR #6457: interfaces: add network-manager-observe interface (2.37) <â›” Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6457>13:14
jdstrandmborzecki: thanks for the feedback btw. I'll adjust13:14
* jdstrand added a bunch of interfaces for 2.37 last week13:15
jdstrandso just did this the same. if you don't want it, nak it. that's fine13:15
pedronisjdstrand: my problem is if they have bugs, and they typically don't come with deep tests, to they create a need for more .x , pushing the next release further13:18
pedronisjdstrand: it's a balance basically13:18
jdstrandpedronis: imho it would only have a profiling bug. we would not do a 2.37.3 just for it. profile fixes for 2.3813:18
jdstrandwhich is part of why I did it this way-- get it out sooner for feedback. I mean, if it works perfect great, if not, iterate in the next release13:19
pedronisjdstrand: .x don't stay around a lot in testing13:19
jdstrandbut again, I'm not pushing for 2.37. it is there as a discussion point. if you don't want it, fine13:20
pedronisjdstrand: they can test things using edge13:22
pedronisbtw13:22
pedronisso it's not so clear why they would need stable13:22
pedronismvo: you said you have further changes planned for #6404 because of feedback, right?13:24
mupPR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>13:24
jdstrandpedronis: don't feel pressure to say yes. I was only expressing my reasoning :) tbh, I didn't release dot releases got less verification13:24
jdstrandrealize*13:24
pedronisjdstrand: well, the assumption is that they have targeted content to fix bugs13:25
pedronisadding features defeats that13:25
pedronisalso at some point just the mechanics of landing things delays them a bit13:25
pedronisjdstrand: also the main PR for master got questions/comments13:26
* jdstrand nods and is addressing that now13:27
=== ricab is now known as ricab|lunch
pedronisjdstrand: I closed the 2.37 one13:27
mupPR snapd#6457 closed: interfaces: add network-manager-observe interface (2.37) <â›” Blocked> <Created by jdstrand> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6457>13:28
* jdstrand nods13:28
oSoMoNjdstrand, mvo: re- u2f-devices in 2.37.2, many thanks!13:45
mvopstolowski: thanks for the test-run13:51
mvopedronis: 6404> yeah, iirc I wanted to add some more tests, need to look at the pr again though13:52
Chipacapedronis: I'm seeing a lane having tasks with status that's a mix of Done, Undone, and Error13:53
Chipacain tests, to be clear13:53
Chipacapedronis: looks like I'm either missing to do something in the test, or the lane checker needs to be smarter13:54
mupPR snapd#6461 closed: snap-confine: provide proper error message on sc_sanity_timeout <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6461>13:54
Chipacanot sure if I should make the tests more involved though13:54
pedronisChipaca: me confused13:54
pedronisChipaca: I misread your code?13:54
pedronisChipaca: just a lane did not succeed13:55
pedroniss/just/such/13:55
pedronisbut is ready13:55
Chipacapedronis: right, but then I was expecting all tasks on a non-successful lane to be non-Ready13:55
Chipacaie either Undone or Hold13:55
Chipacaer, not non-REady, i meant non-Done13:56
pedronisChipaca: you can really only check the reverse13:56
pedroniseverything DOne13:56
pedronis== success13:56
pedronisanything else13:56
pedronisnot13:56
Chipacasigh13:56
Chipacaok13:56
pedronissorry, I tought that was what the code was doing13:56
pedronisI misread, read too quickly13:56
pedronisI suppose13:56
pedronisanyway13:56
Chipacawhoops, standup, omw14:01
=== ricab|lunch is now known as ricab
=== phoenix_firebrd is now known as murthy
pedronisjdstrand: hi, did you see my question about the serial-port logic in https://forum.snapcraft.io/t/allowing-interfaces-to-disable-device-cgroup-udev/9630/11 ?16:06
pedronisjdstrand: seems hidraw is also like that16:06
jdstrandpedronis: I did and I responded (note, you typically do not need to ping me unless it is urgent since I read all forum mail; it's possible I might miss something, so if I don't after a little while, feel free to ping)16:21
=== phoenix_firebrd is now known as murthy
=== pstolowski is now known as pstolowski|afk
mupIssue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#1517:01
mupPR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#3017:01
mupIssue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#1517:04
mupPR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#3017:04
sergiusensplars: hey, about snapcraft 3.1 hitting candidate, did anything get triggered incorrectly on your side?17:25
sergiusensplars: this is what I am talking about btw https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-1/971217:25
plarssergiusens: I can take a look... usually no news is good news on those tests, but it never hurts to check17:26
sergiusensplars: yeah, never hurts, if you don't mind adding a comment on that post when verified, that would be grand17:26
plarssergiusens: apparently we are still stuck on an earlier version because we still depend on remote parts17:50
sergiusensah, ok17:57
cwayneWhich we're looking into fixing17:59
* zyga waves 19:30
zygaI feel a bit better, slept for most of the day19:30
zygamvo: I hope to be operational tomorrow19:30
mvozyga: cool, yeah, rest and lets sync tomorrow then19:31
cwayneah, feel better soon zyga19:31
zygathanks guys!19:32
mwhudsonhm19:57
mwhudsonhow does version: git in snapcraft.yaml know which of the two git repos my snap is built out of to use?19:57
mwhudsonand can i make it use both of them somehow19:57
Chipacamwhudson: adopt-info: <some part> tells it to use the version from that part20:11
Chipacamwhudson: do you have two git repos in the same part?20:11
mwhudsonChipaca: no, separate parts20:12
Chipacamwhudson: and you have an adopt-info: <blah> somewhere?20:12
mwhudsonno20:12
mwhudsoni had never heard about adopt-info: until now :)20:12
Chipacamwhudson: snapcraft uses it: https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml20:14
Chipacamwhudson: but I'm not sure this is what you want20:15
Chipacasergiusens: what would you suggest?20:15
Chipacasergiusens: (to have the version of a snap built from combining the versions from two git sources in two parts)20:16
mwhudsoni guess i can do a version-script or whatever it is called20:16
mwhudsonrelatedly20:16
mwhudsonis there an easy way to rebuild the snap when either git branch changes?20:16
mwhudsonthat's more a launchpad question i guess and i bet the answer is "no"20:17
sergiusensmwhudson: if you use build.snapcraft.io and host on github, change detection should just work20:52
sergiusensmwhudson: about `adopt-info`, that's documented here https://docs.snapcraft.io/extracting-information-from-sources-in-snapcraft-parts/464220:53
mwhudsonsergiusens: can't use bsi because of that thing about collaborators iirc21:37
sergiusensmwhudson: collaborators? As in you do not have ownership as it belongs to Canonical? I would talk to Saviq as multipass uses build.snapcraft.io and it is under Canonical21:49
mwhudsonah maybe that is fixed now21:49

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