[06:04] <mborzecki> morning
[06:41] <mborzecki> need to drive the kids to school, back in 30 or so
[07:15] <mborzecki> re
[08:08] <mup> PR snapd#7948 opened: spread: drop copr repo with F30 build dependencies <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7948>
[08:58] <pokk> besides the docker snapcraft not seeming to work it's rather fun to build snaps
[08:58] <pokk> well done everyone!
[09:21] <sdhd-sascha> Hello, I could need some advice: https://forum.snapcraft.io/t/interface-shared-memory/14759
[09:21] <sdhd-sascha> Where should a access to a specific shared-mem be added?
[12:02] <mvo> cachio: hey, good morning! I pushed an update to 7943, but for some reason it's still not not quite working on gce - do you think you could run it with a console again?
[12:02] <cachio> mvo, hey, sure
[12:02] <mvo> cachio: thank you!
[12:02] <cachio> mvo, yaw
[12:02] <mvo> cachio: i also enabled the smoke test and it works in qemu
[12:24] <cachio> mvo, I run core20 suite in gce and passed
[12:26] <cachio> mvo, I also see that it is running well on travis https://travis-ci.org/snapcore/snapd/jobs/627684724#L5851
[12:26] <cachio> mvo, which error did you see?
[12:27] <mvo> cachio: \o/
[12:28] <mvo> cachio: I triggering it locally and saw an issuee connecting to the instance, it looked like it did not come back after a reboot
[12:28] <cmatsuoka> cachio, mvo: good morning
[12:28] <mvo> cachio: but maybe it was something local or something rare?
[12:28] <mvo> cmatsuoka: good morning! happy friday :)
[12:28] <cmatsuoka> cachio: do you know what this error is? https://pastebin.ubuntu.com/p/YzRSfTrpX7/
[12:29] <mvo> cmatsuoka: could this be a leftover in parts/* that confused the dpkg-buildpackage run?
[12:29] <cmatsuoka> mvo: yay, I'm following the irc conversation, congratulations!
[12:29] <cmatsuoka> mvo: humm maybe, good idea, let me check
[12:30] <mvo> cmatsuoka: thanks! yeah, if we get a green run in travis that will be an amazing christmas present
[12:30] <cmatsuoka> indeed it will!
[12:47] <cachio> mvo, 3 exececutions 2 passed
[12:47] <cachio> 3/3 sorry
[12:47] <cachio> all passed
[12:51] <cachio> I'll test it more to make sure it works well
[12:51] <cachio> I added a loop to run the tests the whole day
[12:53] <mup> Bug #1857128 opened: Missing configuration option to allow a snap to openFile without prompting <Snappy:New> <https://launchpad.net/bugs/1857128>
[12:56]  * cachio afk 10 mins
[12:57] <mborzecki> mvo: left a question for ian in #7947, aiui bootloader.Options.Recovery triggers the new behavior
[12:57] <mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
[12:57] <mborzecki> (or should trigger the new behavior)
[13:13] <cmatsuoka> mborzecki: that udevadm-calls-after-each-operation thing might hold some water, i added an extra trigger --settle after filesystem creation and it's not failing (so far)
[13:14] <mborzecki> cmatsuoka: hahah
[13:14] <cmatsuoka> i hate those magical fixes, especially when they work!
[13:15]  * cmatsuoka really needs to understand how udev works
[13:15] <mborzecki> cmatsuoka: as we looked at the anaconda/blivet code they did use settle very often after any operation on storage
[13:16] <cmatsuoka> I don't doubt they did that after being bitten a few times
[13:22] <mborzecki> hm this is interesting https://bugs.launchpad.net/snappy/+bug/1857128 isn't that covered by the portals too?
[13:22] <mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:New> <https://launchpad.net/bugs/1857128>
[13:36] <jdstrand> Saviq: hey (I'm not actually here), but I noticed in nautilus a 184M volume. it turns out it is a loopback mount in /media/jamie/disk that is the multipass snap. I did not do this myself. is this intended behavior?
[13:38] <jdstrand> Saviq: https://paste.ubuntu.com/p/X7bh7QygyQ/
[13:38]  * jdstrand wanders off
[13:46] <Saviq> jdstrand: no, we never did this ourselves
[13:48] <jdstrand> weird
[13:48] <jdstrand> Saviq: well, fyi in case it comes up again, 2019-12-09T17:23:21.609994Z was the snapcraft-started-at in the manifest.yaml
[13:48]  * jdstrand unmounts
[13:51] <mvo> cachio: nice!
[13:52] <cachio> mvo, so far 100% pass
[13:52] <mvo> mborzecki: cool, thanks! I still haven't reviewed this pr yet, will try to do some good reviews this aftersoon
[13:52] <mvo> cachio: very cool
[13:52] <cachio> 18 executions
[13:52] <jdstrand> Saviq: looking at the logs, it seems that org.gnome.Shell.HotplugSniffer was involved, so you can disregard
[14:01] <cmatsuoka> cachio: going to the standup?
[14:37] <mup> PR snapd#7949 opened: cmd/snap, daemon: stop over-normalising channels <Created by chipaca> <https://github.com/snapcore/snapd/pull/7949>
[14:40] <mup> PR snapd#7950 opened: overlord/snapstate: tracks are now sticky <Created by chipaca> <https://github.com/snapcore/snapd/pull/7950>
[14:44] <Chipaca> mvo: mborzecki: two tiny PRs ^
[14:46] <cachio> Chipaca, mvo cmatsuoka mborzecki could someone please take quick look to #7851
[14:46] <mup> PR #7851: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7851>
[14:46] <Chipaca> sure
[14:46] <cachio> Chipaca, just 36 files changed
[14:46] <mvo> Chipaca: thanks, looking
[14:47] <mvo> cachio: yes, looking
[14:47] <cachio> mvo, thanks!!
[14:48] <mborzecki> mvo: Chipaca: about portals, the whole diff is: https://paste.ubuntu.com/p/B66tNMNryV/
[14:48] <Chipaca> cachio: why the change from test-snapd-sh to test-snapd-sh.sh?
[14:50] <cachio> Chipaca, to be consistent bertween the local snap and the remote snap
[14:50] <mvo> mborzecki: woah, that's nice and short
[14:50] <Chipaca> cachio: fair
[14:50] <cachio> the snap that we download uses test-snapd-sh.sh, so the change makes the local snap use the same
[14:51] <cachio> mvo, so you need a test-snapd-sh for uc20 right?
[14:51] <Chipaca> mborzecki: WHen → When :-p
[14:52] <Chipaca> mborzecki: doesn't that change it over unconditionally? ie without checking whether portals are there?
[14:53] <mvo> cachio: yeah, I think that will make the test better
[14:53] <cachio> Chipaca, thanks for the +1
[14:53] <cachio> mvo, ok, I'll create it after lunch
[14:53] <mvo> cachio: thank you!
[14:54] <cachio> the same for test-snapd-tools right?
[14:54] <mvo> cachio: I'm working on a fix now to not (ab)use snapd-core-fixup.sh to setup the user for spread :)
[14:54] <mvo> cachio: yes
[14:54] <mvo> cachio: but maybe we don't need test-snapd-tools anymore now that we have -sh
[14:54] <mvo> cachio: wdyt?
[14:55] <mup> PR snapd#7851 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7851>
[14:55] <cachio> mvo, we use test-snapd-tools-core18 in 2 tests
[14:55] <mvo> cachio: ok, thanks, I don't remember enough details, you can choose :)
[14:56] <cachio> mvo, ok, thanks
[14:56] <mborzecki> Chipaca: we try to ping the service by calling org.freedesktop.DBus.Peer.Ping() if that fails the snapd user session launcher is used
[14:57]  * cachio lunch
[14:59] <mup> PR snapd#7951 opened: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7951>
[14:59] <mvo> cachio: for later - I ported https://github.com/snapcore/snapd/pull/7951 double check would be great
[14:59] <mup> PR #7951: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) <Created by mvo5> <https://github.com/snapcore/snapd/pull/7951>
[15:46] <mup> PR snapd#7952 opened: snap-bootstrap: trigger udev after filesystem creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7952>
[16:20] <mup> PR snapd#7953 opened: tests: use new snapd.spread-tweaks.service unit <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7953>
[16:56] <roadmr> cachio, sil2100 : did either of you release core18 about 50min ago?
[17:05] <Chipaca> EOY for me. TTFN, HANEOY, etc etc etc
[17:05] <Chipaca> 👋
[17:31] <sil2100> roadmr: ok, so it might have been me, but it was a bit earlier than that - since it was phased to 100% at the usual time but wasn't released fully, so I did the final push without phase percentage some time ago - did I break something with that...?
[17:31] <sil2100> Since I should have done a no-percentage release when we reached 100%, but it popped out of my mind
[17:33] <sil2100> Probably shouldn't have been trigger happy and doing the no-percentage push now, since I guess 100% phasing != no-phased-percentage
[17:34] <roadmr> sil2100: did you use phasing for the release?
[17:34] <roadmr> sil2100: we saw a storm of requests (like when core was released unphased and we'd have to scramble to throttle on our side)
[17:34] <sil2100> roadmr: yes
[17:35] <roadmr> sil2100: interesting... so you started at what percentage?
[17:35] <sil2100> roadmr: and I think it should have been sitting in 100% phasing for a while
[17:35] <sil2100> roadmr: I think yesterday I started with 20%
[17:35] <sil2100> roadmr: when did the storm of requests start?
[17:35] <roadmr> sil2100: aha, that should have been ok
[17:36] <roadmr> 16:34 UTC first alert, so it probably started shortly before that
[17:36] <sil2100> roadmr: so my phasing was a bit uneven this time, since yesterday it was 20, then 50, then 70 but with long periods in-between those
[17:37] <sil2100> But yeah, I'd expect most should have gotten it yesterday regardless
[17:37] <roadmr> sil2100: right, it makes no sense that the final 30% would break things, everyting else looked stable
[17:38] <roadmr> sil2100: ok, no problem - your procedure looks correct
[17:39] <sil2100> roadmr: also, as said, it was sitting on phasing 100% for quite a while, I only did the final no-progressive call those ~2 hours ago
[17:39] <sil2100> Since I always have to do the final release API call after phasing to 100%
[17:39] <roadmr> right and we saw the issue about 1h ago, so they don't seem to correlate that well :/
[17:40] <roadmr> np sil2100, I'll keep digging for what else may have caused it
[17:40] <roadmr> (it could have been a tail of core18 stragglers + a vscode-insiders release)
[19:31] <mup> PR snapcraft#2850 opened: hooks: enable command-chain <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2850>