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