[06:20] <mborzecki> morning
[06:22] <mvo> hey mborzecki
[06:22] <mborzecki> mvo: hey
[06:22] <mborzecki> 47 PRs
[06:26] <mvo> mborzecki: indeed, looking good
[06:35] <mup> PR snapd#6434 closed: interfaces: add u2f-devices interface (2.37) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6434>
[06:44] <mup> PR snapd#6458 opened: snapd,state: improve error message on state reading failure <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6458>
[06:50] <mborzecki> mvo: about #6458, did that happen often in your tests?
[06:50] <mvo> mborzecki: just once
[06:50] <mup> PR #6458: snapd,state: improve error message on state reading failure <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6458>
[06:52] <mborzecki> mvo: 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:53] <mvo> mborzecki: yeah, its not super helpful but at least it gives people a clue
[06:53] <mvo> mborzecki: error: EOF is really saying nothing :/
[06:54] <mborzecki> mvo: we could have done worse, eg 'error: failed' :)
[06:54] <mvo> heh: "error: computer says no"
[06:55] <mvo> mborzecki: we should probably have noticed that the error is not great when writing the unit test with the error - oh well
[06:58] <mup> Issue core18#118 closed: fw_printenv is not present in core18 <bug> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/core18/issue/118>
[08:12] <mborzecki> mvo: #6417 can be landed now?
[08:12] <mup> PR #6417: snap: fix reexec from the snapd snap for classic snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6417>
[08:13] <mvo> mborzecki: yes, good catch
[08:14] <mup> PR 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>
=== pstolowski|afk is now known as pstolowski
[08:22] <pstolowski> mornings
[08:24] <mborzecki> pstolowski: hey
[08:27] <mvo> good morning pstolowski
[08:30] <mwhudson> when did /v2/find?name=foo start including information on whether the publisher was verified?
[08:30] <mwhudson> must be a while ago
[08:30] <pstolowski> mvo: will do beta validation core18 - upgrade pi3
[08:33] <mvo> pstolowski: thank you
[08:42] <pedronis> mwhudson: quite a while ago, yes
[08:43] <pedronis> mwhudson: https://forum.snapcraft.io/t/how-to-display-account-names-and-usernames/4007/4
[08:46] <pedronis> mvo: comment on 6458
[08:48] <mup> PR 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:50] <mvo> pedronis: thanks, checking
[08:50] <mup> PR snapd#6460 opened: snap: fix hook autodiscovery for parallel installed snaps (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6460>
[08:51] <mvo> pedronis: ta
[08:59] <mup> PR 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] <mup> PR 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] <mvo> mborzecki: thanks for your reviews btw :) really appreciated
[09:00] <mborzecki> mvo: had some suggestions in #6456, actually made me revisit gio again
[09:00] <mup> PR #6456: interfaces: add network-manager-observe interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6456>
[09:01] <pedronis> do we know why is targeted at 2.37
[09:01] <mvo> mborzecki: yeah, I saw that, its great feedback
[09:01] <pedronis> it's a full new interface
[09:01] <mvo> pedronis: probably just because jamie wants it there and its low regression risk
[09:01] <mvo> pedronis: not sure if there is more to it, it seems he is doing that for most of his interface PRs
[09:02] <pedronis> not completely a fan tough
[09:02] <pedronis> when is this interface supported
[09:02] <pedronis> 2.37.2
[09:02] <pedronis> not a nice answer
[09:03] <mvo> yeah, 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 that
[09:04] <pedronis> mvo: what if it's broken in some ways
[09:05] <pedronis> do we do a 2.37.3 ?
[09:05] <pedronis> I marked it blocked for now
[09:05] <pedronis> I would like to understand
[09:05] <pedronis> the urgence
[09:05] <mvo> pedronis: thats fine
[09:06] <pedronis> mvo: notice that there is no real spread test for this thing afaict
[09:08] <pedronis> mvo: we already added in u2f-devices in .1 right?
[09:08] <mborzecki> anyone updated go to 1.11.5 ?
[09:09] <pedronis> or is it for .2?
[09:10] <pedronis> mvo: as I said I find a bit problematic that these things don't come with real tests
[09:13] <mvo> pedronis: 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] <pedronis> mvo: I don't have a strong opinion, but merging them late and not tests doesn't seem a good combo
[09:14] <mvo> pedronis: *nod*
[09:15]  * zyga crawled to his laptop
[09:15] <zyga> I will be off today
[09:16] <mvo> zyga: get well!
[09:16] <pedronis> zyga: get well!
[09:22] <pedronis> mvo: but yes, a chat with jdstrand seems good
=== phoenix_firebrd is now known as murthy
[09:44] <pedronis> mvo: can we create a 2_38 tag in the forum
[09:44] <pedronis> mvo: for example for this: https://forum.snapcraft.io/t/risk-only-channel-requests-vs-pinned-default-tracks/9332
[09:48] <mvo> pedronis: sure
[09:49] <mvo> pedronis: done
[09:52] <pedronis> mvo: thank you
[09:55] <mup> PR 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:56] <mup> PR 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:58] <kissiel> mvo: 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 definition
[09:58] <kissiel> (https://github.com/kissiel/snapcraft/commit/8d5b91a3dd398d224a9d957344613401a2266570)
[09:59] <kissiel> mvo: but from what I can tell, that test was disabled since Oct '18. So that patch also re-enables it.
[09:59] <kissiel> mvo: makes sens? shall I propose that PR?
[10:01]  * Chipaca takes a break
[10:02] <pstolowski> mvo: 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:07] <mvo> pstolowski: 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:08] <mvo> pstolowski: I pasted your comment into the PR
[10:09] <pstolowski> mvo: right, thanks!
[10:11] <pedronis> mvo: I do plan to start looking at your big PRs today and tomorrw btw, I added myself to them
[10:13] <mvo> pedronis: thank you
[11:04] <pstolowski> mvo: 1-1?
[11:17] <mup> PR 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:29] <pstolowski> mvo: ah, false alarm, it's tomorrow ;)
[11:29] <pstolowski> sorry
[11:33] <mvo> pstolowski: :)
[11:34] <mvo> pstolowski: no worries
[11:54] <pedronis> Chipaca: hi, could you review when you have a moment the last commint in #6415
[11:54] <mup> PR #6415: snapstate, snap: allow update/switch requests with risk only channel to DTRT <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6415>
[12:11] <mup> PR snapd#6461 opened: snap-confine: provide proper error message on sc_sanity_timeout <Created by mvo5> <https://github.com/snapcore/snapd/pull/6461>
[12:18] <mup> PR snapd#6462 opened: snap-confine: fix incorrect "sanity timeout 3s" message <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6462>
[12:25] <Chipaca> pedronis: did you see my comment in that one?
[12:26] <pedronis> Chipaca: it didn't sound a blocker, tough? it's orthogonal no?
[12:27] <Chipaca> pedronis: ye
[12:27] <pedronis> Chipaca: does it still have your +1 ?
[12:27] <Chipaca> as i said i would, i added a card :-)
[12:27] <pedronis> that's my question
[12:27] <Chipaca> pedronis: it's even got an extra +1 for good measure
[12:33] <mup> PR snapd#6463 opened: [RFC] snap-confine: increase locking timeout to 30s  <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6463>
[12:34] <zyga> mvo: fyi, indent is unstable across systems
[12:35] <pedronis> Chipaca: thx
[12:36] <Chipaca> mvo: which indent?
[12:38] <pedronis> Chipaca: the C(++) formatter
[12:38] <pedronis> I think
[12:39] <mborzecki> zyga: mvo: we have a make target to call clang-format
[12:40] <zyga> we have one
[12:40] <zyga> read the makefile.am, there are two sets of files
[12:40] <zyga> one formatted with indent
[12:40] <zyga> other with clang-format
[12:40] <zyga> both are unstable though
[12:40] <zyga> so it's just what you prefer, I guess
[12:40] <zyga> note: clang-format is 10x better
[12:40] <pedronis> Chipaca: me is confused, isn't the order of channels in that message wrong
[12:40] <zyga> so over time we will switch
[12:40] <pedronis> ah, no
[12:40] <mborzecki> pedronis: which message?
[12:40] <pedronis> mborzecki: nvm
[12:43] <leinardi> Hi, 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/11
[12:43] <leinardi> any idea of what is the issue?
[12:46] <pstolowski> mvo: finished upgrade tests on rpi3, 2 failures http://paste.ubuntu.com/p/BmsVGpgTMF/ , both we had seen yesterday already
[12:55] <zyga> leinardi: replied
[12:55] <pedronis> pstolowski: btw, now that we switched to newer gos, we need to try to go back addressing the EnsureBefore issues
[12:55] <pstolowski> pedronis: right, great
[12:56] <pstolowski> will re-visit it
[13:01] <pedronis> pstolowski: thx
[13:07] <mborzecki> off to pick up the kids
[13:09] <jdstrand> oSoMoN: ok, u2f-devices will be in 2.37.2 (pr committed thanks to mvo)
[13:14] <jdstrand> pedronis (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 weeks
[13:14] <mup> PR #6457: interfaces: add network-manager-observe interface (2.37) <⛔ Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6457>
[13:14] <jdstrand> mborzecki: thanks for the feedback btw. I'll adjust
[13:15]  * jdstrand added a bunch of interfaces for 2.37 last week
[13:15] <jdstrand> so just did this the same. if you don't want it, nak it. that's fine
[13:18] <pedronis> jdstrand: 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 further
[13:18] <pedronis> jdstrand: it's a balance basically
[13:18] <jdstrand> pedronis: imho it would only have a profiling bug. we would not do a 2.37.3 just for it. profile fixes for 2.38
[13:19] <jdstrand> which 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 release
[13:19] <pedronis> jdstrand: .x don't stay around a lot in testing
[13:20] <jdstrand> but again, I'm not pushing for 2.37. it is there as a discussion point. if you don't want it, fine
[13:22] <pedronis> jdstrand: they can test things using edge
[13:22] <pedronis> btw
[13:22] <pedronis> so it's not so clear why they would need stable
[13:24] <pedronis> mvo: you said you have further changes planned for #6404 because of feedback, right?
[13:24] <mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
[13:24] <jdstrand> pedronis: don't feel pressure to say yes. I was only expressing my reasoning :) tbh, I didn't release dot releases got less verification
[13:24] <jdstrand> realize*
[13:25] <pedronis> jdstrand: well, the assumption is that they have targeted content to fix bugs
[13:25] <pedronis> adding features defeats that
[13:25] <pedronis> also at some point just the mechanics of landing things delays them a bit
[13:26] <pedronis> jdstrand: also the main PR for master got questions/comments
[13:27]  * jdstrand nods and is addressing that now
=== ricab is now known as ricab|lunch
[13:27] <pedronis> jdstrand: I closed the 2.37 one
[13:28] <mup> PR 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 nods
[13:45] <oSoMoN> jdstrand, mvo: re- u2f-devices in 2.37.2, many thanks!
[13:51] <mvo> pstolowski: thanks for the test-run
[13:52] <mvo> pedronis: 6404> yeah, iirc I wanted to add some more tests, need to look at the pr again though
[13:53] <Chipaca> pedronis: I'm seeing a lane having tasks with status that's a mix of Done, Undone, and Error
[13:53] <Chipaca> in tests, to be clear
[13:54] <Chipaca> pedronis: looks like I'm either missing to do something in the test, or the lane checker needs to be smarter
[13:54] <mup> PR 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] <Chipaca> not sure if I should make the tests more involved though
[13:54] <pedronis> Chipaca: me confused
[13:54] <pedronis> Chipaca: I misread your code?
[13:55] <pedronis> Chipaca: just a lane did not succeed
[13:55] <pedronis> s/just/such/
[13:55] <pedronis> but is ready
[13:55] <Chipaca> pedronis: right, but then I was expecting all tasks on a non-successful lane to be non-Ready
[13:55] <Chipaca> ie either Undone or Hold
[13:56] <Chipaca> er, not non-REady, i meant non-Done
[13:56] <pedronis> Chipaca: you can really only check the reverse
[13:56] <pedronis> everything DOne
[13:56] <pedronis> == success
[13:56] <pedronis> anything else
[13:56] <pedronis> not
[13:56] <Chipaca> sigh
[13:56] <Chipaca> ok
[13:56] <pedronis> sorry, I tought that was what the code was doing
[13:56] <pedronis> I misread, read too quickly
[13:56] <pedronis> I suppose
[13:56] <pedronis> anyway
[14:01] <Chipaca> whoops, standup, omw
=== ricab|lunch is now known as ricab
=== phoenix_firebrd is now known as murthy
[16:06] <pedronis> jdstrand: 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] <pedronis> jdstrand: seems hidraw is also like that
[16:21] <jdstrand> pedronis: 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)
=== phoenix_firebrd is now known as murthy
=== pstolowski is now known as pstolowski|afk
[17:01] <mup> Issue # closed: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
[17:01] <mup> PR # closed: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[17:04] <mup> Issue # opened: classic-snap#7, classic-snap#8, classic-snap#14, classic-snap#15
[17:04] <mup> PR # opened: classic-snap#24, classic-snap#27, classic-snap#28, classic-snap#30
[17:25] <sergiusens> plars: hey, about snapcraft 3.1 hitting candidate, did anything get triggered incorrectly on your side?
[17:25] <sergiusens> plars: this is what I am talking about btw https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-1/9712
[17:26] <plars> sergiusens: I can take a look... usually no news is good news on those tests, but it never hurts to check
[17:26] <sergiusens> plars: yeah, never hurts, if you don't mind adding a comment on that post when verified, that would be grand
[17:50] <plars> sergiusens: apparently we are still stuck on an earlier version because we still depend on remote parts
[17:57] <sergiusens> ah, ok
[17:59] <cwayne> Which we're looking into fixing
[19:30]  * zyga waves 
[19:30] <zyga> I feel a bit better, slept for most of the day
[19:30] <zyga> mvo: I hope to be operational tomorrow
[19:31] <mvo> zyga: cool, yeah, rest and lets sync tomorrow then
[19:31] <cwayne> ah, feel better soon zyga
[19:32] <zyga> thanks guys!
[19:57] <mwhudson> hm
[19:57] <mwhudson> how does version: git in snapcraft.yaml know which of the two git repos my snap is built out of to use?
[19:57] <mwhudson> and can i make it use both of them somehow
[20:11] <Chipaca> mwhudson: adopt-info: <some part> tells it to use the version from that part
[20:11] <Chipaca> mwhudson: do you have two git repos in the same part?
[20:12] <mwhudson> Chipaca: no, separate parts
[20:12] <Chipaca> mwhudson: and you have an adopt-info: <blah> somewhere?
[20:12] <mwhudson> no
[20:12] <mwhudson> i had never heard about adopt-info: until now :)
[20:14] <Chipaca> mwhudson: snapcraft uses it: https://github.com/snapcore/snapcraft/blob/master/snap/snapcraft.yaml
[20:15] <Chipaca> mwhudson: but I'm not sure this is what you want
[20:15] <Chipaca> sergiusens: what would you suggest?
[20:16] <Chipaca> sergiusens: (to have the version of a snap built from combining the versions from two git sources in two parts)
[20:16] <mwhudson> i guess i can do a version-script or whatever it is called
[20:16] <mwhudson> relatedly
[20:16] <mwhudson> is there an easy way to rebuild the snap when either git branch changes?
[20:17] <mwhudson> that's more a launchpad question i guess and i bet the answer is "no"
[20:52] <sergiusens> mwhudson: if you use build.snapcraft.io and host on github, change detection should just work
[20:53] <sergiusens> mwhudson: about `adopt-info`, that's documented here https://docs.snapcraft.io/extracting-information-from-sources-in-snapcraft-parts/4642
[21:37] <mwhudson> sergiusens: can't use bsi because of that thing about collaborators iirc
[21:49] <sergiusens> mwhudson: 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 Canonical
[21:49] <mwhudson> ah maybe that is fixed now