[02:03] <mup> PR snapcraft#2214 closed: sentry: support disabling error reporting <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2214>
[02:03] <mup> PR snapcraft#2215 closed: provider changes <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2215>
[02:34] <mup> PR snapd#5665 opened: tests: set ubuntu-core-18 as manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5665>
[04:59] <mup> PR snapd#5663 closed: overlord/devicestate: fix tests, set seeded in registration through proxy tests <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5663>
[05:05] <mborzecki> morning
[05:06] <mvo> hey mborzecki, good morning
[05:06] <mborzecki> mvo: hey, you're up early
[05:06] <mvo> mborzecki: yeah, a one-off
[05:06] <mborzecki> mvo: did i miss anything interesting yday?
[05:07] <mvo> mborzecki: not that much, a bit of thinking about what the best place for the udevmonitor is in the code, but that is more something for pawel. master is broken right now, thats not good (core18 seems to be not booting)
[05:07] <mvo> mborzecki: but other than that it was relatively tame
[05:07] <mborzecki> mvo: master broken, how so?
[05:08] <mvo> mborzecki: yesterday two PRs got merged that had subtle interrelatiations
[05:08] <mvo> mborzecki: which broke unit tests
[05:08] <mborzecki> mvo: is the fix on review already? anyting i can help with?
[05:09] <mvo> mborzecki: tests are fine again, samuele fixed those last night
[05:09] <mvo> mborzecki: but spread is unhappy
[05:09] <mvo> mborzecki: because of core18
[05:09] <mvo> mborzecki: no idea why yet, there was a new kernel yesterday and of course a new snapd
[05:09] <mvo> mborzecki: so maybe one of those broke things
[05:10] <mborzecki> mvo: aah interesting
[05:17] <mvo> nice (ish) - "error: invalid xz chunk" in early boot
[05:18] <mborzecki> mvo: initramfs is xz compresses?
[05:18] <mvo> mborzecki: yes and the kernel itself too iirc
[05:19] <mborzecki> mvo: uboot then? or is it amd64?
[05:19] <mvo> mborzecki: amd64
[05:21] <mborzecki> mvo: https://github.com/kdave/grub/blob/master/grub-core/fs/squash4.c#L348
[05:27] <mvo> mborzecki: the initrd seems to be the issue https://paste.ubuntu.com/p/zYBWc8rkZT/
[05:27] <mvo> mborzecki: the kernel itself is gzip compressed
[05:30] <mborzecki> mvo: i guess decompressing it locally works right?
[05:30] <mvo> mborzecki: yes
[05:30] <mvo> mborzecki: but that is with xz/unxz
[05:30] <mvo> not the grub code
[06:43] <zyga> Good morning!
[06:43] <zyga> New backdrop, day one :-)
[06:46] <mvo> zyga: good morning
[06:46] <zyga> :-)
[06:46] <zyga> First day of real work after returning
[06:46] <zyga> Is anything on fire?
[06:48] <mvo> zyga: core18 is not booting but the kernel was just reverted so hopefully it will be RSN
[06:49] <zyga> In GCE or everywhere?
[06:58] <mborzecki> zyga: hey
[07:01] <mborzecki> mvo: there are some PRs that could land
[07:02] <mvo> mborzecki: which ones
[07:02] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/5657
[07:02] <mup> PR #5657: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5657>
[07:02] <mvo> mborzecki: cool
[07:02] <mborzecki> mvo: this is real simple one https://github.com/snapcore/snapd/pull/5640
[07:02] <mup> PR #5640: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>
[07:03] <mborzecki> mvo: this one too https://github.com/snapcore/snapd/pull/5651
[07:03] <mup> PR #5651: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>
[07:03] <zyga> I will begin the day with code reviews
[07:04] <mborzecki> https://github.com/snapcore/snapd/pull/5662 i'll restart the build in this one
[07:04] <mup> PR snapd#5657 closed: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5657>
[07:04] <mup> PR snapd#5658 closed: interfaces: add cpu-control for setting CPU tunables (2.35) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5658>
[07:04] <mup> PR #5662: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5662>
[07:06] <mborzecki> mvo: fwiw this one can land too https://github.com/snapcore/snapd/pull/5645
[07:06] <mup> PR #5645: tests: new test for udisks2 interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5645>
[07:07] <mup> PR snapd#5645 closed: tests: new test for udisks2 interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5645>
[07:07] <mup> PR snapd#5665 closed: tests: set ubuntu-core-18 as manual <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5665>
[07:08] <mvo> mborzecki: 5635 should be an easy win
[07:09] <mup> PR snapd#5631 closed: snapstate: ensure normal snaps wait for the "snapd" snap on refresh <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5631>
[07:09] <mup> PR snapd#5635 closed: tests: enable lxd again everywhere <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5635>
[07:11] <mborzecki> coffee time
[07:12] <pstolowski> heyas
[07:13] <zyga> good morning pawel :)
[07:16] <mvo> hey pstolowski
[07:16] <pstolowski> mvo: hey! thanks for the feedback on udev mon!
[07:24] <mborzecki> pstolowski: hey
[07:34] <pedronis> mvo: hi,  how are things?  let me know when you think we can chat
[07:35] <mvo> pedronis: just dealing with some autopkgtest failures, after that should be fine, so maybe in ~1h ?
[07:35] <pedronis> ok, great
[07:37] <mup> PR snapd#5666 opened: tests: fix autopkgtest failures in cosmic <Created by mvo5> <https://github.com/snapcore/snapd/pull/5666>
[07:37] <zyga> good morning pedronis :)
[08:36] <Chipaca> mvo: morning
[08:36] <mvo> Chipaca: good morning
[08:36] <Chipaca> mvo: who amongst us knows of our use of fwupdate? you, ogra, ...?
[08:37] <mvo> Chipaca: I don't, but probably field engineering
[08:37] <mvo> Chipaca: iirc its just in some of their devices
[08:37] <Chipaca> mvo: asking because people are asking to drop it from main, replacing it wiht fwupd
[08:41] <zyga> hey Chipaca
[08:41] <zyga> Chipaca: interesting
[08:41] <zyga> we used one vs the other a while ago because of a customer request
[08:42] <Chipaca> zyga: on core itself, or in images for that customer?
[08:42] <Chipaca> core itself doesn't ship it
[08:43] <zyga> I think it's an image with extra tooling
[08:43] <Chipaca> that is, http://cdimage.ubuntu.com/ubuntu-core/16/ doesn't have it :-)
[08:43] <zyga> but my memory is rusty now
[08:45] <Chipaca> zyga: mvo: https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1787254/comments/7
[08:47] <mborzecki> zyga: hah, so you've rewritten your memory in Rust?
[08:47] <Chipaca> mborzecki: I think he meant 'rustig'
[08:48] <zyga> mborzecki: I cannot remember since you hold onto that idea now
[08:49] <mborzecki> zyga: it's outlived by other memories
[08:50] <mborzecki> Chipaca: i'm sure this one would interest you too https://github.com/snapcore/snapd/pull/5667
[08:50] <Chipaca> DENIED
[08:50]  * Chipaca marks everything CHANGES REQUESTED today
[08:51] <mborzecki> Chipaca: may i offer you some cookies? :)
[08:51] <Chipaca> NO
[08:51] <Chipaca> yes
[08:51] <mborzecki> denied :)
[08:52]  * Chipaca goes to make his own cookies, with blackjack and … hooks? chocolate jack daniels hook cookies?
[08:54] <mborzecki> so go 1.11 changes gofmt slightly?
[08:54] <Chipaca> mborzecki: why the change to the instancekey?
[08:55] <zyga> mborzecki: oh, that would be fun
[09:07] <niemeyer> mup is back.. I still need to fix its identifying logic with nickserv so that he can speak here when he logs back in
[09:07] <niemeyer> mup: You ok, right?
[09:07] <mup> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
[09:08] <niemeyer> mborzecki: That happened in other releases of gofmt as wlel
[09:11] <mborzecki> niemeyer: this one is quite subtle https://talks.godoc.org/github.com/mvdan/talks/2018/go1.11.slide#6
[09:11] <Chipaca> mborzecki: no more winxp support /o\ !!!
[09:12] <niemeyer> mborzecki: Weird.. I don't recall seeing the first case I think
[09:13] <niemeyer> Ah, maybe because I already split out the long names anyway so it's visually nicer
[09:13] <niemeyer> I've fired a new review board:
[09:14] <niemeyer> https://forum.snapcraft.io/t/review-sprint-6/6901
[09:14] <Chipaca> what does "Last release where godoc has a command-line interface" mean? 'godoc' is going away?
[09:14] <ogra> Chipaca, try cyphermox ... not sure who in field has any knowledge here, probably tony and alfonso
[09:14] <niemeyer> I know some of you are already on a review sprint somewhat, so just keep going :)
[09:14] <Chipaca> ogra: I'll chat with tony later, i think
[09:15] <ogra> +1
[09:17] <niemeyer> Chipaca: godoc vs. go doc
[09:17] <Chipaca> niemeyer: but 'go doc' sucks :-/
[09:18] <Chipaca> bah
[09:18] <Chipaca> maybe in .11 'go doc' grows an http server mode and all is well
[09:20] <mup> PR snapd#5662 closed: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5662>
[09:20] <niemeyer> Chipaca: I doubt.. that's the opposite of what happened
[09:20] <niemeyer> Chipaca: It used to have an http server
[09:21] <niemeyer> Right now it's a CLI, which isn't going away as I understand it
[09:21] <niemeyer> While godoc remains the web server
[09:21] <niemeyer> Doesn't seem bad..?
[09:21] <Chipaca> niemeyer: right, but 1.11 is the "last release where godoc has a command-line interface"
[09:22] <niemeyer> Chipaca: Yeah, that's the subject.. :)
[09:22] <Chipaca> niemeyer: a command-line interface is how I launch the http server
[09:22] <niemeyer> Chipaca: go doc will still have the CLI.. godoc will still have the web UI
[09:22] <Chipaca> niemeyer: if it doesn't have a command-line interface, it's just a library (or a gui app?)
[09:23] <niemeyer> Chipaca: Ah, one of us misunderstands.. I think what's going away is the text output
[09:23] <Chipaca> I'm fine with that. I hope it's that.
[09:23] <niemeyer> Chipaca: Of godoc.. it remains a web server
[09:24] <niemeyer> Chipaca: https://tip.golang.org/doc/go1.11 =>
[09:24] <Chipaca> OTOH, we won't be using .11 until NEVER
[09:24] <niemeyer> "Go 1.11 will be the last release to support godoc's command-line interface. In future releases, godoc will only be a web server. Users should use go doc for command-line help output instead. "
[09:25] <mvo> Chipaca: sorry was in a meeting, I have a look at 1787254
[09:25] <Chipaca> niemeyer: phew
[09:25] <Chipaca> niemeyer: also! also! The godoc web server now shows which version of Go introduced new API features. <3
[09:25] <niemeyer> Chipaca: Oh, sweet!  Is there standard syntax we can use to tag our APIs?
[09:26] <Chipaca> niemeyer: I just read that bit, no idea :-)
[09:26] <Chipaca> niemeyer: it doesn't seem to be done with synta
[09:26] <Chipaca> x
[09:29] <niemeyer> Aww
[09:36] <mborzecki> https://github.com/snapcore/snapd/pull/5640 is an easy win
[09:36] <mup> PR #5640: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>
[09:38] <mup> PR snapd#5640 closed: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5640>
[09:42] <mup> PR snapd#4951 closed: interfaces: add screencast-legacy for video and audio recording <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4951>
[09:57] <ogra> Chipaca, pedronis https://pastebin.canonical.com/p/fZ29ck4wfG/ (sorry for the secured pastebin, not sure there is confidential info in the logs)
[09:58] <ogra> this is from this mornings auto-refresh ... sadly i cant tell if the 1:30 timeout happened there since i was sleepig when it happened
[10:02] <pedronis> I see,  the logs looks regular there's as many "Waiting for system reboot" as there are "Requested system restart"
[10:04] <ogra> yeah, and the timestamps indicate that there was no 1:30 timeout
[10:04] <pedronis> so at leasr from snapd own point of view, is shutting down as expected
[10:04] <ogra> right ...
[10:04] <ogra> i guess i'll have to wait for another one where it actually happens :(
[10:05] <ogra> this is annoying, i have seeen it a lot and on all my VMs for days ... typically if the core update happens right after booting up though
[10:05] <mup> PR snapd#5667 closed: store: backward compatible instance-key handling for non-instance snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5667>
[10:05] <ogra> i'll make sure to leave one VM off tonight so it does the refresh immediately after boot tomorrow
[10:08] <mup> PR snapd#5668 opened: store: backward compatible instance-key handling for non-instance snaps (2.35) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5668>
[10:08] <mborzecki> mvo: ^^ a backport of 5667 for 2.35
[10:11] <mvo> mborzecki: thank you
[10:12] <niemeyer> pstolowski: #4767 has reviews
[10:12] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[10:13] <pstolowski> niemeyer: yes, thanks, i've almost finished addressing the new comments
[10:18] <niemeyer> pstolowski: Sorry, I meant to say I just had new ones too
[10:18] <pstolowski> niemeyer: ah, ok, i saw mvo's comments only, allright
[10:27] <mup> PR snapcraft#2218 opened: many: replace yaml.safe_load() with CSafeLoader <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/2218>
[10:45] <mup> PR snapd#5668 closed: store: backward compatible instance-key handling for non-instance snaps (2.35) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5668>
[10:46] <niemeyer> zyga: #5307 reviewed
[10:46] <mup> PR #5307: cmd,interfaces,tests: add mnt interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>
[10:46] <zyga> thanks
[10:46] <mup> PR snapd#5659 closed: tests: remove manual from openvswitch test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5659>
[10:48] <zyga> niemeyer: thank you, I'm going through another review now but I'll address this one today
[10:49] <niemeyer> zyga: Thanks!
[10:52] <mup> PR snapd#5561 closed: overlord/snapstate: parallel snap install <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5561>
[10:59] <mup> PR snapd#5669 opened: asserts,image: support gaget tracks in the model assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5669>
[10:59] <mvo> mborzecki: btw, does 5596 have spread tests for parallel installs already? would be cool to add there to see itin action
[11:00] <cachio> mvo, hey
[11:00] <cachio> what did you do to fix core-18 builds?
[11:04] <mvo> cachio: I asked the kernel team to revert to r137 of the pc-kernel snap
[11:04] <mvo> cachio: the r140 version breaks
[11:04] <mvo> cachio: its not clear yet why sadly
[11:04] <cachio> mvo, ahhh, nice
[11:04] <mvo> cachio: but I was able to reproduce locally and I saw the grub failure in my qemu run
[11:05] <mvo> cachio: I ran with SPREAD_QEMU_GUI=1 which made it easier (I think serial port would probably also have worked, but not sure)
[11:05] <cachio> mvo, I though it was a problem with the image
[11:05] <cachio> with a dependency
[11:06] <cachio> but didn't realize it was the kernel snap
[11:06] <cachio> nice catch
[11:06]  * niemeyer lunches
[11:06] <mvo> cachio: yeah, it was very non-obvious what triggered it :/ I looked at the recent changes and noctied the kernel snap update from a couple of hours ago
[11:06] <mborzecki> mvo: the spread tests require a bit most stuff in the master branch
[11:07] <mborzecki> mvo: i'll be opening another bit after we're done with the review sprint
[11:08] <mvo> mborzecki: oh, we are in a review sprint?
[11:08] <mborzecki> mvo: shh, dont' tell anyone :P https://forum.snapcraft.io/t/review-sprint-6/6901
[11:09] <mvo> mborzecki: hm, 2h ago? now I don't feel so bad anymore for not reading the memo in time
[11:11] <mvo> ogra: fwiw, I also updated the pi* builds to use the bionic chroots (to be consistent with the whole ubuntu 18 idea :)
[11:12] <ogra> mvo, makes sense for core 18 indeed
[11:13] <mvo> ogra: lets hope no subtle issues come up
[11:13] <ogra> mvo, well, you need to solve the update issues with dtb''s and firmware files in the gadget
[11:13] <mvo> ogra: you mean for upgrades? yeah, that is going to be "fun"
[11:13] <ogra> mvo, but IIRC you and niemeyer worked out plas for that with ondra, so i guess we're fine (are we ?)
[11:14] <ogra> yeah
[11:14] <ogra> 16 to 18 gadget upgrades
[11:15] <ogra> s/plas/plans/
[11:16] <mborzecki> zyga: could you take a look at https://github.com/snapcore/snapd/pull/5654 later on?
[11:16] <mup> PR #5654: cmd/snap-confine: establish snap directory mappings for parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5654>
[11:18] <mup> PR pc-amd64-gadget#8 opened: snapcraft.yaml: bump version number <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/8>
[11:19] <zyga> mborzecki: yes, added to my queue :)
[11:19] <mborzecki> zyga: great, thanks
[11:19] <mup> PR pc-i386-gadget#6 opened: snapcraft.yaml: bump version number <Created by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/6>
[11:24] <mup> PR pc-i386-gadget#6 closed: snapcraft.yaml: bump version number <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/6>
[11:24] <mup> PR pc-amd64-gadget#8 closed: snapcraft.yaml: bump version number <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/8>
[11:29] <ogra> niemeyer, since you were asking for non-dismissive arguments regarding the unified pi gadgets, i'd appreciate if you could read https://forum.snapcraft.io/t/model-assertions-for-core18/6870/6 (if you did not read it yet) ... note that i do not expect an answer or change of the decision and i will let the topic rest, but i'd at least like that the decision making parties know all the technical backgrounds
[12:08] <mup> PR snapd#5670 opened: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670>
[12:10] <pstolowski|lunch> mvo: would you like to have another look at https://github.com/snapcore/snapd/pull/4767 or can i land?
[12:10] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[12:13] <mup> PR snapd#5636 closed: snap: fix advice json <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5636>
[12:17] <zyga> pstolowski|lunch: updated https://github.com/snapcore/snapd/pull/5651
[12:17] <mup> PR #5651: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>
[12:24] <mup> PR snapd#5666 closed: tests: fix autopkgtest failures in cosmic <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5666>
[12:40] <mvo> pstolowski|lunch: sure, I check the disconnect hooks PR now
[12:42] <mvo> nice, down to 39 prs
[12:45] <niemeyer> Go go! :)
[12:53]  * Chipaca goes
[12:59] <pstolowski> zyga: thanks
[12:59] <mvo> niemeyer: I have a conflicting meeting today, I will see if I can leave it early and may join later
[13:00] <mvo> niemeyer: one important piece for the standup is that we need to figure out why r140 of the pc-kernel snap does not boot
[13:03] <mup> PR snapd#5651 closed: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5651>
[13:06] <zyga> jdstrand: I have some questions about the changes to dbus wrt apparmor, when would be a good time to ask you some of those?
[13:07] <jdstrand> zyga: hey, ask away
[13:08] <zyga> jdstrand: thanks, I'll write my questions down and paste after the standup
[13:11] <Chipaca> mvo: https://www.amazon.co.uk/dp/B003U4NO7Y
[13:55] <mvo> Chipaca: heh, the moto of my life
[13:59]  * zyga runs for lunch
[14:01] <Chipaca> niemeyer: https://forum.snapcraft.io/t/defer-snapd-refresh-on-wake-from-suspend/4943?u=chipaca
[14:08] <niemeyer> Thanks
[14:12] <mup> PR snapd#5671 opened: tests: basic test for parlalel installs from the store <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5671>
[14:13] <Chipaca> mborzecki: for what installs?
[14:13] <Chipaca> :-)
[14:20] <mborzecki> Chipaca: plaplapel
[14:20] <mborzecki> :)
[14:35] <mborzecki> niemeyer: https://github.com/snapcore/spread/pull/67 that's the MATCH fix
[14:36] <mup> PR spread#67: spread: run MATCH in a subshell <Created by mvo5> <https://github.com/snapcore/spread/pull/67>
[14:36] <niemeyer> mborzecki: Thanks! Let me merge that and release it
[14:42] <niemeyer> mborzecki: Please give it a shot
[14:48] <mvo> pstolowski: could you please check https://github.com/snapcore/snapd/pull/4767#discussion_r210180691 - I wonder if the name of the test still matches what is done given that its now a (retry) error
[14:48] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[14:49] <pstolowski> mvo: i'm sorry, i think i missed it, checking
[14:50] <mvo> pstolowski: thanks! one more https://github.com/snapcore/snapd/pull/4767/files#r195361520 - i think GH was hidding those from you :) I had to manually expand
[14:50] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[14:51] <mvo> pstolowski: if you need to do code change give me a shout and I send a diff to you, but only then, its not super important but if it does a full test run anyway I might as well propose my diff
[14:51] <pedronis> mborzecki: in your task/todo sequencing when are you thinking of attacking alias code and other places that assume snap-id <-> 1 snap
[14:52] <pedronis> ?
[14:52] <mup> PR snapcraft#2219 opened: Release changelog for 2.43 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2219>
[14:55] <niemeyer> Taking a break here
[14:55] <pstolowski> mvo: grr, indeed, thanks. i'm not sure why i missed them, i'm pretty sure i looked at the 'files' tab, not 'conversation'
[14:55] <pstolowski> mvo: pushed
[14:55] <mvo> pstolowski: no worries
[14:55] <mvo> pstolowski: thank you
[14:57] <pstolowski> i hope travis is still in good and cooperative mood today ;)
[14:58]  * pstolowski is knocking the wood
[14:59] <pedronis> mvo: btw some of the tasks/todo we discussed this morning were mentioned here:  https://forum.snapcraft.io/t/seeding-snaps-that-plug-the-content-interface/5579/3
[15:00] <cachio__> niemeyer, about the secrets for the spread cron project
[15:00] <cachio__> niemeyer, what can I do for that?
[15:00] <mborzecki> pedronis: up next is adding mkdir of for snap name in handlers code when instance one is installed and cleanup, then i plan to look into aliases and the store hash stuff after that
[15:01] <mborzecki> pedronis: that's paralell to stuff being landed which happens at it's own pace
[15:01] <pedronis> mborzecki: ok, there might be more code that has similar issues as aliases, we can discuss when you get to alias stuff
[15:01] <mborzecki> pedronis: ack
[15:02] <mborzecki> pedronis: off the top of your head do you recall what that might be?
[15:02] <pedronis> mborzecki: refreshing assertions and relatedly refresh-control/validation code
[15:03] <pedronis> in some cases might just be that we do things too many times (instead of once), other they might be bug
[15:03] <pedronis> mborzecki: as I said, its code that is sort of assuming that  one snap id <->  1 snap so far
[15:05] <mvo> pedronis: nice, thank you
[15:05] <pedronis> mborzecki: also Update code might have that problem
[15:05] <Chipaca> niemeyer: I went through all your feedback on the snapshotstate pr and replied (but I didn't have any argument with any of it, it's all "yep, done")
[15:05] <pedronis> or maybe you fixed that already
[15:05] <mborzecki> pedronis: as in snapstate.Update?
[15:05] <pedronis> UpdateMany
[15:06] <pedronis> mborzecki: this kind of code:   snapst := stateByID[update.SnapID]
[15:07] <pedronis> seems to still be there
[15:08] <mborzecki> pedronis: yeah, see that, ok, so that piece is up next then
[15:08] <pedronis> mborzecki: so there is various code like that
[15:08] <pedronis> in the places I mentioned
[15:09] <pedronis> most of it I think is close/around Update/UpdateMany
[15:11] <mborzecki> pedronis: thanks, noted that down
[15:12] <pedronis> mborzecki: it mostly lives in snapstate and assertsstate I think
[15:13] <mborzecki> wish i had a tool to integrate org-mode notes with the forum :) hopefully's niemeyer will fill that gap
[15:14]  * cachio__ lunch
[15:16] <mup> PR snapd#5672 opened: tests: make nfs test available for more systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5672>
[15:27] <mvo> jdstrand: if you have a moment, a comment on https://github.com/snapcore/snapd/pull/5615#discussion_r210516258 would be great, not sure if its worth persuing or if I should land as is and just iterate if the people using it have problems (i.e. if those are symlinks for them as well)
[15:27] <mup> PR #5615: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <https://github.com/snapcore/snapd/pull/5615>
[15:33] <mup> PR snapd#4767 closed: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4767>
[15:34] <jdstrand> mvo: commented
[15:35] <mvo> jdstrand: ta!
[15:35] <pstolowski> woot, yay \o/
[15:36] <mup> PR snapd#5673 opened: ifstate: extra common code into checkAutoConflicts() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5673>
[15:37] <mvo> pstolowski: yeah, good stuff!
[15:38] <jdstrand> zyga: you mentioned something about a list of questions after a meeting?
[15:56] <zyga> jdstrand: re, yeah sorry I just got carried away by things I was doing locally
[15:57] <zyga> jdstrand: so I was looking at that PR that reacts to dbus changes
[15:57] <zyga> jdstrand: and I wasn't quite sure how some of the actual differences made by the patches fit into labelling and activation
[15:58] <zyga> jdstrand: let me pull up an example
[15:58] <mup> PR snapd#5615 closed: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5615>
[16:00] <jdstrand> zyga: it might help if I mention that clients don't have to do anything to activate a service, they just start using it. how they start is client dependent
[16:00] <jdstrand> zyga: hostnamectl does via a GetAll(). I know others do Introspect()
[16:00] <zyga> right, I see
[16:01] <jdstrand> zyga: so I just focused on those rather than discarding the label check entirely
[16:01] <zyga> jdstrand: as a quick patch in the branch let's look at https://github.com/snapcore/snapd/pull/5664/commits/64ea1623b9b383cd649da48d315e54bc56d37822 - I was expecting to see removal of peer=(label=unconfined), instead there is some more logic
[16:01] <jdstrand> zyga: figuring if we get a bug, we would address it
[16:01] <mup> PR #5664: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>
[16:02] <jdstrand> zyga: I added Get and GetAll proactively
[16:02] <zyga> I also don't understand why some have send and some both send and receive
[16:02] <zyga> aha
[16:02] <jdstrand> zyga: they should be send
[16:03] <jdstrand> I can fix that
[16:03] <zyga> so I can expect various patches to add Introspect and Get, GetAll
[16:03] <zyga> like this one https://github.com/snapcore/snapd/pull/5664/commits/06f8e5b7f0e33c454b2ea8516958d61cca39761a
[16:03] <mup> PR #5664: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>
[16:04] <jdstrand> zyga: well, each interface is slightly different. I noticed in that interface there was only the Inhibit rule, no Get, GetAll or Introspect, so I updated it
[16:05] <zyga> jdstrand: ok, with the send vs receive resolved and with your explanation on new methods I think I understand what this is doing
[16:05] <zyga> thanks, I will approve it now
[16:06] <jdstrand> zyga: I'll check for receive/send and make sure it is correct. it is likely just in a couple of places where I copied a broad send/receive rule to a particular path and forgot to remove the receive
[16:09] <t1mp> hello
[16:09] <zyga> hey t1mp
[16:10] <t1mp> question: why is snapcraft trying to pull my package wheel file from PyPI, if I built that in a previous part with the python plugin?
[16:10] <zyga> kyrofa, sergiusens: ^
[16:11] <t1mp> hmm, let me check something, maybe I have that explicitly defined somewhere :)
[16:11] <ogra> because you didnt feed enough cake to snapcrafts AI ?
[16:11] <niemeyer> Chipaca: Thanks!
[16:11]  * Chipaca checks his pockets
[16:11] <t1mp> ogra: yeah, probably something like that :)
[16:11] <ogra> :)
[16:11] <Chipaca> niemeyer: you're welcome!
[16:11] <sergiusens> t1mp: maybe it is not on the expected path.
[16:12] <t1mp> I didn't want to build the python wheel file in snapcraft actually because I did that in a previous stage on jenkins. But I don't see a way to use a local .whl instead of pulling it from PyPI, except building it in an earlier stage
[16:12] <jdstrand> mvo: oh, I was surprised you merged PR 5615...
[16:12] <mup> PR #5615: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5615>
[16:12] <sergiusens> t1mp: pip has some rules that if you download the wheel to specific locations would satisfy the dependency
[16:12] <sergiusens> but I will need to forward you to a search engine to find that path.
[16:13] <jdstrand> mvo: I commented here https://github.com/snapcore/snapd/pull/5615#discussion_r210643334 - that is what I meant before. sorry if I was unclear
[16:14] <t1mp> sergiusens: ah ok, that might be useful. I think that is something to put in the pip config file, which I could just copy into the snap
[16:14] <t1mp> thanks :)
[16:14] <mvo> jdstrand: I replied via mail, apparently someone looked at this and considered it okay
[16:15] <jdstrand> ah. I'm still slogging through email
[16:15] <mvo> jdstrand: I'm not sure it is but even if it is not I will have to add one extra commit
[16:15]  * jdstrand nods
[16:15] <mvo> jdstrand: so if I add the commit now or later seems to be the same, testing it as is leaves the (small) chance it may actually be not symlinks in the kernel they use
[16:15] <mvo> jdstrand: but if its symlinks and its not stable we have a problem :(
[16:16] <jdstrand> mvo: it might not be so bad. depends on what the target is
[16:16] <mvo> jdstrand: aha, if its always the same range you mean? yeah, then it will be okay
[16:17] <jdstrand> mvo: eg, maybe /sys/devices/**/i2c/<name>/** or something
[16:17]  * mvo nods
[16:17] <jdstrand> the /sys/devices/**/ would be the non-deterministic part, but we could glob that away
[16:17] <jdstrand> at least, that is my hope :)
[16:18] <mvo> jdstrand: yeah, it appears to be like this on amd64 at least so I should probably do the followup in any case to make this useful on amd64
[16:18] <mvo> jdstrand: but dinner first :) thanks for your input, thats good stuff
[16:19] <jdstrand> mvo: enjoy! :)
[16:20] <mvo> jdstrand: I added a comment and will work on it later/tomorrow.
[16:20] <mvo> ttfn
[16:21] <jdstrand> mvo: thanks! :)
[16:35] <pedronis> Chipaca: not sure exactly what you are struggle on, but gave one of the examples I had in mind
[16:35] <pedronis> *struggling on
[16:35] <Chipaca> pedronis: thank you
[16:35] <Chipaca> pedronis: I probably just need a break
[16:35] <Chipaca> pedronis: :-)
[16:36] <Chipaca> also i need to stop context-switching like a deranged chipmunk
[16:37] <Chipaca> pedronis: as for you, go away :-) let's talk tomorrow if I'm still stuck.
[16:40] <om26er> alan_g: Hello!
[16:41] <alan_g> om26er, hellp
[16:41] <om26er> alan_g: This tutorial is useful https://tutorials.ubuntu.com/tutorial/graphical-snaps#0 but is there a more "complete" one that actually launches a Qt/Gtk based app on UbuntuCore system ?
[16:42] <om26er> we have a snap that works fine on wayland desktop and are looking to make that a kiosk-mode app.
[16:43] <alan_g> om26er, not yet. But there's an example: https://forum.snapcraft.io/t/shipping-later-qt-with-snap/6873
[16:44] <om26er> alan_g: how far along is Mir/Wayland on UbuntuCore being "production" ready ?
[16:44] <om26er> for now we are doing a demo but I believe if this goes well, we'll be doing a full-blown product, so wanted to know.
[16:45]  * zyga -> walk
[16:46] <alan_g> om26er, Basically, it works now. There's one thing we want to iron out, but that shouldn't worry you: https://community.ubuntu.com/t/snaps-and-sharing-mirs-wayland-socket/7539/1
[16:47] <alan_g> greyback, is working on that, and will update and extend the tutorials "real soon now".
[16:49] <greyback> om26er: hey, I'll share something like that when I've all theekinks ironed out
[16:49] <om26er> also the "layouts" feature is also experimental, though I hope it'll graduate some time soon ?
[16:51] <om26er> greyback: that'd be helpful. I am currently trying to run a PySide2 (Qt for Python) app on a UbuntuCore based system. namely Siemen's SIMATIC ipc327e.
[16:52] <om26er> it runs on my wayland session (desktop) (fully confined)
[16:52] <greyback> om26er: ack. What version of Qt are you using?
[16:52] <om26er> greyback: Qt 5.11, its shipped with PySide's .whl
[16:53] <om26er> source https://download.qt.io/snapshots/ci/pyside/5.11/latest/pyside2/?C=M;O=D
[16:53] <greyback> om26er: ok, good, it's nice and new. That shouldn't have any issues with Mir
[16:58] <Chipaca> pedronis: I was not adding the taskset to a change. Can I have a dunce emoji?
[17:03] <alan_g> om26er, BYW if you need to test with a Mir based Wayland session there's https://snapcraft.io/egmde
[17:17] <pedronis> Chipaca: ah, couple of methods of state don't return tasks unless they are attached to a change
[17:25] <om26er> cool my snap PySide2 snap works in egmde session.
[17:25] <om26er> s/snap//
[18:37] <cachio> kyrofa, hey
[18:40] <niemeyer> cachio: We can see the spead-cron issue soon if you'll be around
[18:40] <cachio> niemeyer, yes
[18:40] <cachio> just ping me
[18:41] <niemeyer> Cool
[18:53] <kyrofa> Hey there cachio
[18:54] <cachio> kyrofa, hey, quick question, are you setting travis for snapcraft on gce west zone?
[18:54] <cachio> I saw some instances on us-west1-b yesterday
[18:54] <kyrofa> cachio, indeed I am, west1-b
[18:55] <kyrofa> Yep, probably us
[18:55] <cachio> kyrofa, ahh, could you please use the us-east1-b for travis?
[18:55] <cachio> so machines with more than 2 hours will be automatically removed
[18:56] <kyrofa> Ah, we only garbage collect that region eh? Sure, we can switch
[18:56] <cachio> yes, it is by region
[18:56] <cachio> thanks
[19:03] <Chipaca> niemeyer: snapshotstate is ready for a look
[19:04] <mborzecki> cachio: you around? left a note for you https://github.com/snapcore/snapd/pull/5624#discussion_r210707985
[19:04] <mup> PR #5624: tests: get the linux-image-extra available for the current kernel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5624>
[19:04] <cachio> mborzecki, sure
[19:04] <mborzecki> cachio: there was a typo in the code i suggested :P i missed a space
[19:11] <cachio> mborzecki, let me test it with the new kernels
[19:13] <cachio> mborzecki, I see a difference between your function and the one I did, and it is that what we return when the first option does not match
[19:18] <niemeyer> Chipaca: Danke!
[19:19] <niemeyer> cachio: Alright.. do you have a build log for the failure?
[19:19] <Chipaca> niemeyer: nichts zu danken
[19:19] <cachio> niemeyer, yes, 1 min please
[19:20] <cachio> niemeyer, https://travis-ci.org/snapcore/spread-cron/builds/416898556#L548
[19:20] <niemeyer> Chipaca: danke für deine Freundlichkeit
[19:21] <niemeyer> (hope Google Translate did a good job there... ;P)
[19:22] <cachio> niemeyer, Chipaca Jeder spricht Deutsch mit Google Translate
[19:22] <niemeyer> cachio: Hmmm.. that's a strange log
[19:23] <niemeyer> cachio: I hope it's just auth, because it doesn't really look like it
[19:23] <cachio> niemeyer, we can try generating the secrets for this project and see
[19:25]  * niemeyer installs travis client from some guy named kyrofa 
[19:27] <mborzecki> cachio: hm with this change you'll install the package matching your kernel (probably something we want?)
[19:28] <cachio> mborzecki, yes
[19:28] <cachio> I tested that with the problematic kernel and worked
[19:29] <cachio> mborzecki, I'll push the change
[19:30] <cachio> mborzecki, lets see how it goes
[19:30] <niemeyer> kyrofa: It's not working :(
[19:30] <niemeyer> % travis encrypt foo
[19:30] <niemeyer> Outdated CLI version, run `gem install travis`.
[19:30] <niemeyer> No such file or directory - git
[19:30] <niemeyer> for a full error report, run travis report
[19:31] <kyrofa> What.
[19:31] <kyrofa> I didn't realize it did a version check
[19:31] <cachio> mborzecki, if you give the +1 I can merge it wwhen the tests are in green
[19:31] <cachio> mborzecki, so I can update the ubuntu xenial 64 images
[19:31] <niemeyer> kyrofa: Most things I run seem to result in that error
[19:31] <niemeyer> --help works tho
[19:32] <mborzecki> cachio: +1'ed :)
[19:32] <kyrofa> niemeyer, yeah it must check it server-side. I'll update it
[19:32] <cachio> mborzecki, thanks
[19:32] <kyrofa> What the heck. They tagged it four hours ago
[19:41] <niemeyer> cachio: Can you please put an "env" call just above the spread call so I can have a vague idea of what's the context there?
[19:42] <cachio> niemeyer, sure
[19:44] <cachio> niemeyer, https://travis-ci.org/snapcore/spread-cron/builds/416972345
[19:56] <sergiusens> niemeyer cachio another option is to setup the encrypted keys from https://travis-ci.org/snapcore/spread-cron/settings
[19:56] <sergiusens> I cannot see that url fwiw as I am not in a relevant team for that
[19:58] <sergiusens> I don't know what key is used there though
[20:01] <cachio> sergiusens, well, not sure which is the problem itself
[20:02] <cachio> niemeyer, is it not fixed by doing the same you did for snapd project?
[20:02] <niemeyer> cachio: SHould be, but I'll need to find a working travis tool.. will need to get dinner before that
[20:02] <cachio> niemeyer, sure
[20:02] <mup> PR snapd#5624 closed: tests: get the linux-image-extra available for the current kernel <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5624>
[20:41] <mup> PR snapd#5674 opened: tests: add the original function to fix the errors on new kernels <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5674>
[20:41] <jdstrand_> zyga: wrt fedora base, I forgot about this: https://forum.snapcraft.io/t/process-for-reviewing-base-snaps/3040
[21:04] <niemeyer> cachio: I've sent the data for travis.yaml in spread-cron privately
[21:04] <niemeyer> cachio: Please add it and give it a shot
[21:11] <niemeyer> And with that success I call it a night and end on the right foot.
[21:12] <niemeyer> See you all tomorrow.. same time, same place
[21:15] <kyrofa> niemeyer, travis snap should be better now
[21:20] <cachio> niemeyer, see you, thanks for this help