[02:03] PR snapcraft#2214 closed: sentry: support disabling error reporting [02:03] PR snapcraft#2215 closed: provider changes [02:34] PR snapd#5665 opened: tests: set ubuntu-core-18 as manual === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:59] PR snapd#5663 closed: overlord/devicestate: fix tests, set seeded in registration through proxy tests [05:05] morning [05:06] hey mborzecki, good morning [05:06] mvo: hey, you're up early [05:06] mborzecki: yeah, a one-off [05:06] mvo: did i miss anything interesting yday? [05:07] 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] mborzecki: but other than that it was relatively tame [05:07] mvo: master broken, how so? [05:08] mborzecki: yesterday two PRs got merged that had subtle interrelatiations [05:08] mborzecki: which broke unit tests [05:08] mvo: is the fix on review already? anyting i can help with? [05:09] mborzecki: tests are fine again, samuele fixed those last night [05:09] mborzecki: but spread is unhappy [05:09] mborzecki: because of core18 [05:09] mborzecki: no idea why yet, there was a new kernel yesterday and of course a new snapd [05:09] mborzecki: so maybe one of those broke things [05:10] mvo: aah interesting [05:17] nice (ish) - "error: invalid xz chunk" in early boot [05:18] mvo: initramfs is xz compresses? [05:18] mborzecki: yes and the kernel itself too iirc [05:19] mvo: uboot then? or is it amd64? [05:19] mborzecki: amd64 [05:21] mvo: https://github.com/kdave/grub/blob/master/grub-core/fs/squash4.c#L348 [05:27] mborzecki: the initrd seems to be the issue https://paste.ubuntu.com/p/zYBWc8rkZT/ [05:27] mborzecki: the kernel itself is gzip compressed === chihchun_afk is now known as chihchun [05:30] mvo: i guess decompressing it locally works right? [05:30] mborzecki: yes [05:30] mborzecki: but that is with xz/unxz [05:30] not the grub code [06:43] Good morning! [06:43] New backdrop, day one :-) [06:46] zyga: good morning [06:46] :-) [06:46] First day of real work after returning [06:46] Is anything on fire? [06:48] zyga: core18 is not booting but the kernel was just reverted so hopefully it will be RSN [06:49] In GCE or everywhere? [06:58] zyga: hey [07:01] mvo: there are some PRs that could land [07:02] mborzecki: which ones [07:02] mvo: https://github.com/snapcore/snapd/pull/5657 [07:02] PR #5657: interfaces: add cpu-control for setting CPU tunables [07:02] mborzecki: cool [07:02] mvo: this is real simple one https://github.com/snapcore/snapd/pull/5640 [07:02] PR #5640: tests: skip unsupported architectures for fedora-base-smoke test [07:03] mvo: this one too https://github.com/snapcore/snapd/pull/5651 [07:03] PR #5651: cmd/libsnap: unify detection of core/classic with go [07:03] I will begin the day with code reviews [07:04] https://github.com/snapcore/snapd/pull/5662 i'll restart the build in this one [07:04] PR snapd#5657 closed: interfaces: add cpu-control for setting CPU tunables [07:04] PR snapd#5658 closed: interfaces: add cpu-control for setting CPU tunables (2.35) [07:04] PR #5662: tests: avoid using the journalctl cursor when it has not been created yet [07:06] mvo: fwiw this one can land too https://github.com/snapcore/snapd/pull/5645 [07:06] PR #5645: tests: new test for udisks2 interface [07:07] PR snapd#5645 closed: tests: new test for udisks2 interface [07:07] PR snapd#5665 closed: tests: set ubuntu-core-18 as manual [07:08] mborzecki: 5635 should be an easy win [07:09] PR snapd#5631 closed: snapstate: ensure normal snaps wait for the "snapd" snap on refresh [07:09] PR snapd#5635 closed: tests: enable lxd again everywhere [07:11] coffee time === pstolowski|afk is now known as pstolowski [07:12] heyas [07:13] good morning pawel :) [07:16] hey pstolowski [07:16] mvo: hey! thanks for the feedback on udev mon! [07:24] pstolowski: hey [07:34] mvo: hi, how are things? let me know when you think we can chat [07:35] pedronis: just dealing with some autopkgtest failures, after that should be fine, so maybe in ~1h ? [07:35] ok, great [07:37] PR snapd#5666 opened: tests: fix autopkgtest failures in cosmic [07:37] good morning pedronis :) === gurmble is now known as grumble [08:36] mvo: morning [08:36] Chipaca: good morning [08:36] mvo: who amongst us knows of our use of fwupdate? you, ogra, ...? [08:37] Chipaca: I don't, but probably field engineering [08:37] Chipaca: iirc its just in some of their devices [08:37] mvo: asking because people are asking to drop it from main, replacing it wiht fwupd [08:41] hey Chipaca [08:41] Chipaca: interesting [08:41] we used one vs the other a while ago because of a customer request [08:42] zyga: on core itself, or in images for that customer? [08:42] core itself doesn't ship it [08:43] I think it's an image with extra tooling [08:43] that is, http://cdimage.ubuntu.com/ubuntu-core/16/ doesn't have it :-) [08:43] but my memory is rusty now [08:45] zyga: mvo: https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1787254/comments/7 [08:47] zyga: hah, so you've rewritten your memory in Rust? [08:47] mborzecki: I think he meant 'rustig' [08:48] mborzecki: I cannot remember since you hold onto that idea now [08:49] zyga: it's outlived by other memories [08:50] Chipaca: i'm sure this one would interest you too https://github.com/snapcore/snapd/pull/5667 [08:50] DENIED [08:50] * Chipaca marks everything CHANGES REQUESTED today [08:51] Chipaca: may i offer you some cookies? :) [08:51] NO [08:51] yes [08:51] denied :) [08:52] * Chipaca goes to make his own cookies, with blackjack and … hooks? chocolate jack daniels hook cookies? [08:54] so go 1.11 changes gofmt slightly? [08:54] mborzecki: why the change to the instancekey? [08:55] mborzecki: oh, that would be fun === mup_ is now known as mup [09:07] 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] mup: You ok, right? [09:07] niemeyer: I apologize, but I'm pretty strict about only responding to known commands. [09:08] mborzecki: That happened in other releases of gofmt as wlel [09:11] niemeyer: this one is quite subtle https://talks.godoc.org/github.com/mvdan/talks/2018/go1.11.slide#6 [09:11] mborzecki: no more winxp support /o\ !!! [09:12] mborzecki: Weird.. I don't recall seeing the first case I think [09:13] Ah, maybe because I already split out the long names anyway so it's visually nicer [09:13] I've fired a new review board: [09:14] https://forum.snapcraft.io/t/review-sprint-6/6901 [09:14] what does "Last release where godoc has a command-line interface" mean? 'godoc' is going away? [09:14] Chipaca, try cyphermox ... not sure who in field has any knowledge here, probably tony and alfonso [09:14] I know some of you are already on a review sprint somewhat, so just keep going :) [09:14] ogra: I'll chat with tony later, i think [09:15] +1 [09:17] Chipaca: godoc vs. go doc [09:17] niemeyer: but 'go doc' sucks :-/ [09:18] bah [09:18] maybe in .11 'go doc' grows an http server mode and all is well [09:20] PR snapd#5662 closed: tests: avoid using the journalctl cursor when it has not been created yet [09:20] Chipaca: I doubt.. that's the opposite of what happened [09:20] Chipaca: It used to have an http server [09:21] Right now it's a CLI, which isn't going away as I understand it [09:21] While godoc remains the web server [09:21] Doesn't seem bad..? [09:21] niemeyer: right, but 1.11 is the "last release where godoc has a command-line interface" [09:22] Chipaca: Yeah, that's the subject.. :) [09:22] niemeyer: a command-line interface is how I launch the http server [09:22] Chipaca: go doc will still have the CLI.. godoc will still have the web UI [09:22] niemeyer: if it doesn't have a command-line interface, it's just a library (or a gui app?) [09:23] Chipaca: Ah, one of us misunderstands.. I think what's going away is the text output [09:23] I'm fine with that. I hope it's that. [09:23] Chipaca: Of godoc.. it remains a web server [09:24] Chipaca: https://tip.golang.org/doc/go1.11 => [09:24] OTOH, we won't be using .11 until NEVER [09:24] "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] Chipaca: sorry was in a meeting, I have a look at 1787254 [09:25] niemeyer: phew [09:25] niemeyer: also! also! The godoc web server now shows which version of Go introduced new API features. <3 [09:25] Chipaca: Oh, sweet! Is there standard syntax we can use to tag our APIs? [09:26] niemeyer: I just read that bit, no idea :-) [09:26] niemeyer: it doesn't seem to be done with synta [09:26] x [09:29] Aww [09:36] https://github.com/snapcore/snapd/pull/5640 is an easy win [09:36] PR #5640: tests: skip unsupported architectures for fedora-base-smoke test [09:38] PR snapd#5640 closed: tests: skip unsupported architectures for fedora-base-smoke test [09:42] PR snapd#4951 closed: interfaces: add screencast-legacy for video and audio recording [09:57] Chipaca, pedronis https://pastebin.canonical.com/p/fZ29ck4wfG/ (sorry for the secured pastebin, not sure there is confidential info in the logs) [09:58] 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] I see, the logs looks regular there's as many "Waiting for system reboot" as there are "Requested system restart" [10:04] yeah, and the timestamps indicate that there was no 1:30 timeout [10:04] so at leasr from snapd own point of view, is shutting down as expected [10:04] right ... [10:04] i guess i'll have to wait for another one where it actually happens :( [10:05] 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] PR snapd#5667 closed: store: backward compatible instance-key handling for non-instance snaps

[10:05] i'll make sure to leave one VM off tonight so it does the refresh immediately after boot tomorrow [10:08] PR snapd#5668 opened: store: backward compatible instance-key handling for non-instance snaps (2.35) [10:08] mvo: ^^ a backport of 5667 for 2.35 [10:11] mborzecki: thank you [10:12] pstolowski: #4767 has reviews [10:12] PR #4767: interfaces: disconnect hooks

[10:13] niemeyer: yes, thanks, i've almost finished addressing the new comments [10:18] pstolowski: Sorry, I meant to say I just had new ones too [10:18] niemeyer: ah, ok, i saw mvo's comments only, allright [10:27] PR snapcraft#2218 opened: many: replace yaml.safe_load() with CSafeLoader [10:45] PR snapd#5668 closed: store: backward compatible instance-key handling for non-instance snaps (2.35) [10:46] zyga: #5307 reviewed [10:46] PR #5307: cmd,interfaces,tests: add mnt interface [10:46] thanks [10:46] PR snapd#5659 closed: tests: remove manual from openvswitch test [10:48] niemeyer: thank you, I'm going through another review now but I'll address this one today [10:49] zyga: Thanks! [10:52] PR snapd#5561 closed: overlord/snapstate: parallel snap install [10:59] PR snapd#5669 opened: asserts,image: support gaget tracks in the model assertion [10:59] mborzecki: btw, does 5596 have spread tests for parallel installs already? would be cool to add there to see itin action [11:00] mvo, hey [11:00] what did you do to fix core-18 builds? [11:04] cachio: I asked the kernel team to revert to r137 of the pc-kernel snap [11:04] cachio: the r140 version breaks [11:04] cachio: its not clear yet why sadly [11:04] mvo, ahhh, nice [11:04] cachio: but I was able to reproduce locally and I saw the grub failure in my qemu run [11:05] 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] mvo, I though it was a problem with the image [11:05] with a dependency [11:06] but didn't realize it was the kernel snap [11:06] nice catch [11:06] * niemeyer lunches [11:06] 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] mvo: the spread tests require a bit most stuff in the master branch [11:07] mvo: i'll be opening another bit after we're done with the review sprint [11:08] mborzecki: oh, we are in a review sprint? [11:08] mvo: shh, dont' tell anyone :P https://forum.snapcraft.io/t/review-sprint-6/6901 [11:09] mborzecki: hm, 2h ago? now I don't feel so bad anymore for not reading the memo in time [11:11] ogra: fwiw, I also updated the pi* builds to use the bionic chroots (to be consistent with the whole ubuntu 18 idea :) [11:12] mvo, makes sense for core 18 indeed [11:13] ogra: lets hope no subtle issues come up [11:13] mvo, well, you need to solve the update issues with dtb''s and firmware files in the gadget [11:13] ogra: you mean for upgrades? yeah, that is going to be "fun" [11:13] mvo, but IIRC you and niemeyer worked out plas for that with ondra, so i guess we're fine (are we ?) [11:14] yeah [11:14] 16 to 18 gadget upgrades [11:15] s/plas/plans/ [11:16] zyga: could you take a look at https://github.com/snapcore/snapd/pull/5654 later on? [11:16] PR #5654: cmd/snap-confine: establish snap directory mappings for parallel instances [11:18] PR pc-amd64-gadget#8 opened: snapcraft.yaml: bump version number [11:19] mborzecki: yes, added to my queue :) [11:19] zyga: great, thanks [11:19] PR pc-i386-gadget#6 opened: snapcraft.yaml: bump version number [11:24] PR pc-i386-gadget#6 closed: snapcraft.yaml: bump version number [11:24] PR pc-amd64-gadget#8 closed: snapcraft.yaml: bump version number [11:29] 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 === verterok` is now known as verterok === alan_g is now known as alan_g|lunch [12:08] PR snapd#5670 opened: daemon, overlord/snapstate: set instance name when installing from snap file === pstolowski is now known as pstolowski|lunch [12:10] mvo: would you like to have another look at https://github.com/snapcore/snapd/pull/4767 or can i land? [12:10] PR #4767: interfaces: disconnect hooks

[12:13] PR snapd#5636 closed: snap: fix advice json [12:17] pstolowski|lunch: updated https://github.com/snapcore/snapd/pull/5651 [12:17] PR #5651: cmd/libsnap: unify detection of core/classic with go [12:24] PR snapd#5666 closed: tests: fix autopkgtest failures in cosmic [12:40] pstolowski|lunch: sure, I check the disconnect hooks PR now [12:42] nice, down to 39 prs [12:45] Go go! :) [12:53] * Chipaca goes === pstolowski|lunch is now known as pstolowski [12:59] zyga: thanks [12:59] niemeyer: I have a conflicting meeting today, I will see if I can leave it early and may join later [13:00] 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] PR snapd#5651 closed: cmd/libsnap: unify detection of core/classic with go === alan_g|lunch is now known as alan_g [13:06] 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] zyga: hey, ask away [13:08] jdstrand: thanks, I'll write my questions down and paste after the standup [13:11] mvo: https://www.amazon.co.uk/dp/B003U4NO7Y [13:55] Chipaca: heh, the moto of my life [13:59] * zyga runs for lunch [14:01] niemeyer: https://forum.snapcraft.io/t/defer-snapd-refresh-on-wake-from-suspend/4943?u=chipaca [14:08] Thanks [14:12] PR snapd#5671 opened: tests: basic test for parlalel installs from the store [14:13] mborzecki: for what installs? [14:13] :-) [14:20] Chipaca: plaplapel [14:20] :) [14:35] niemeyer: https://github.com/snapcore/spread/pull/67 that's the MATCH fix [14:36] PR spread#67: spread: run MATCH in a subshell [14:36] mborzecki: Thanks! Let me merge that and release it [14:42] mborzecki: Please give it a shot [14:48] 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] PR #4767: interfaces: disconnect hooks

[14:49] mvo: i'm sorry, i think i missed it, checking [14:50] 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] PR #4767: interfaces: disconnect hooks

[14:51] 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] 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] ? [14:52] PR snapcraft#2219 opened: Release changelog for 2.43 [14:55] Taking a break here [14:55] 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] mvo: pushed [14:55] pstolowski: no worries [14:55] pstolowski: thank you [14:57] i hope travis is still in good and cooperative mood today ;) [14:58] * pstolowski is knocking the wood [14:59] 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] niemeyer, about the secrets for the spread cron project [15:00] niemeyer, what can I do for that? [15:00] 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] pedronis: that's paralell to stuff being landed which happens at it's own pace [15:01] mborzecki: ok, there might be more code that has similar issues as aliases, we can discuss when you get to alias stuff [15:01] pedronis: ack [15:02] pedronis: off the top of your head do you recall what that might be? [15:02] mborzecki: refreshing assertions and relatedly refresh-control/validation code [15:03] in some cases might just be that we do things too many times (instead of once), other they might be bug [15:03] mborzecki: as I said, its code that is sort of assuming that one snap id <-> 1 snap so far === chihchun is now known as chihchun_afk [15:05] pedronis: nice, thank you [15:05]