/srv/irclogs.ubuntu.com/2019/12/20/#snappy.txt

mborzeckimorning06:04
mborzeckineed to drive the kids to school, back in 30 or so06:41
mborzeckire07:15
mupPR snapd#7948 opened: spread: drop copr repo with F30 build dependencies <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7948>08:08
pokkbesides the docker snapcraft not seeming to work it's rather fun to build snaps08:58
pokkwell done everyone!08:58
sdhd-saschaHello, I could need some advice: https://forum.snapcraft.io/t/interface-shared-memory/1475909:21
sdhd-saschaWhere should a access to a specific shared-mem be added?09:21
mvocachio: 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
cachiomvo, hey, sure12:02
mvocachio: thank you!12:02
cachiomvo, yaw12:02
mvocachio: i also enabled the smoke test and it works in qemu12:02
cachiomvo, I run core20 suite in gce and passed12:24
cachiomvo, I also see that it is running well on travis https://travis-ci.org/snapcore/snapd/jobs/627684724#L585112:26
cachiomvo, which error did you see?12:26
mvocachio: \o/12:27
mvocachio: I triggering it locally and saw an issuee connecting to the instance, it looked like it did not come back after a reboot12:28
cmatsuokacachio, mvo: good morning12:28
mvocachio: but maybe it was something local or something rare?12:28
mvocmatsuoka: good morning! happy friday :)12:28
cmatsuokacachio: do you know what this error is? https://pastebin.ubuntu.com/p/YzRSfTrpX7/12:28
mvocmatsuoka: could this be a leftover in parts/* that confused the dpkg-buildpackage run?12:29
cmatsuokamvo: yay, I'm following the irc conversation, congratulations!12:29
cmatsuokamvo: humm maybe, good idea, let me check12:29
mvocmatsuoka: thanks! yeah, if we get a green run in travis that will be an amazing christmas present12:30
cmatsuokaindeed it will!12:30
cachiomvo, 3 exececutions 2 passed12:47
cachio3/3 sorry12:47
cachioall passed12:47
cachioI'll test it more to make sure it works well12:51
cachioI added a loop to run the tests the whole day12:51
mupBug #1857128 opened: Missing configuration option to allow a snap to openFile without prompting <Snappy:New> <https://launchpad.net/bugs/1857128>12:53
* cachio afk 10 mins12:56
mborzeckimvo: left a question for ian in #7947, aiui bootloader.Options.Recovery triggers the new behavior12:57
mupPR #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)12:57
cmatsuokamborzecki: 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:13
mborzeckicmatsuoka: hahah13:14
cmatsuokai hate those magical fixes, especially when they work!13:14
* cmatsuoka really needs to understand how udev works13:15
mborzeckicmatsuoka: as we looked at the anaconda/blivet code they did use settle very often after any operation on storage13:15
cmatsuokaI don't doubt they did that after being bitten a few times13:16
=== ricab is now known as ricab|lunch
mborzeckihm this is interesting https://bugs.launchpad.net/snappy/+bug/1857128 isn't that covered by the portals too?13:22
mupBug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:New> <https://launchpad.net/bugs/1857128>13:22
jdstrandSaviq: 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:36
jdstrandSaviq: https://paste.ubuntu.com/p/X7bh7QygyQ/13:38
* jdstrand wanders off13:38
Saviqjdstrand: no, we never did this ourselves13:46
jdstrandweird13:48
jdstrandSaviq: well, fyi in case it comes up again, 2019-12-09T17:23:21.609994Z was the snapcraft-started-at in the manifest.yaml13:48
* jdstrand unmounts13:48
mvocachio: nice!13:51
cachiomvo, so far 100% pass13:52
mvomborzecki: cool, thanks! I still haven't reviewed this pr yet, will try to do some good reviews this aftersoon13:52
mvocachio: very cool13:52
cachio18 executions13:52
jdstrandSaviq: looking at the logs, it seems that org.gnome.Shell.HotplugSniffer was involved, so you can disregard13:52
cmatsuokacachio: going to the standup?14:01
=== ricab|lunch is now known as ricab
mupPR snapd#7949 opened: cmd/snap, daemon: stop over-normalising channels <Created by chipaca> <https://github.com/snapcore/snapd/pull/7949>14:37
mupPR snapd#7950 opened: overlord/snapstate: tracks are now sticky <Created by chipaca> <https://github.com/snapcore/snapd/pull/7950>14:40
Chipacamvo: mborzecki: two tiny PRs ^14:44
cachioChipaca, mvo cmatsuoka mborzecki could someone please take quick look to #785114:46
mupPR #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
Chipacasure14:46
cachioChipaca, just 36 files changed14:46
mvoChipaca: thanks, looking14:46
mvocachio: yes, looking14:47
cachiomvo, thanks!!14:47
mborzeckimvo: Chipaca: about portals, the whole diff is: https://paste.ubuntu.com/p/B66tNMNryV/14:48
Chipacacachio: why the change from test-snapd-sh to test-snapd-sh.sh?14:48
cachioChipaca, to be consistent bertween the local snap and the remote snap14:50
mvomborzecki: woah, that's nice and short14:50
Chipacacachio: fair14:50
cachiothe snap that we download uses test-snapd-sh.sh, so the change makes the local snap use the same14:50
cachiomvo, so you need a test-snapd-sh for uc20 right?14:51
Chipacamborzecki: WHen → When :-p14:51
Chipacamborzecki: doesn't that change it over unconditionally? ie without checking whether portals are there?14:52
mvocachio: yeah, I think that will make the test better14:53
cachioChipaca, thanks for the +114:53
cachiomvo, ok, I'll create it after lunch14:53
mvocachio: thank you!14:53
cachiothe same for test-snapd-tools right?14:54
mvocachio: I'm working on a fix now to not (ab)use snapd-core-fixup.sh to setup the user for spread :)14:54
mvocachio: yes14:54
mvocachio: but maybe we don't need test-snapd-tools anymore now that we have -sh14:54
mvocachio: wdyt?14:54
mupPR 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
cachiomvo, we use test-snapd-tools-core18 in 2 tests14:55
mvocachio: ok, thanks, I don't remember enough details, you can choose :)14:55
cachiomvo, ok, thanks14:56
mborzeckiChipaca: we try to ping the service by calling org.freedesktop.DBus.Peer.Ping() if that fails the snapd user session launcher is used14:56
* cachio lunch14:57
mupPR 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
mvocachio: for later - I ported https://github.com/snapcore/snapd/pull/7951 double check would be great14:59
mupPR #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>14:59
=== hggdh is now known as QuosqueTandem
mupPR snapd#7952 opened: snap-bootstrap: trigger udev after filesystem creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7952>15:46
mupPR snapd#7953 opened: tests: use new snapd.spread-tweaks.service unit <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7953>16:20
roadmrcachio, sil2100 : did either of you release core18 about 50min ago?16:56
ChipacaEOY for me. TTFN, HANEOY, etc etc etc17:05
Chipaca👋17:05
sil2100roadmr: 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
sil2100Since I should have done a no-percentage release when we reached 100%, but it popped out of my mind17:31
sil2100Probably shouldn't have been trigger happy and doing the no-percentage push now, since I guess 100% phasing != no-phased-percentage17:33
roadmrsil2100: did you use phasing for the release?17:34
roadmrsil2100: 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
sil2100roadmr: yes17:34
roadmrsil2100: interesting... so you started at what percentage?17:35
sil2100roadmr: and I think it should have been sitting in 100% phasing for a while17:35
sil2100roadmr: I think yesterday I started with 20%17:35
sil2100roadmr: when did the storm of requests start?17:35
roadmrsil2100: aha, that should have been ok17:35
roadmr16:34 UTC first alert, so it probably started shortly before that17:36
sil2100roadmr: so my phasing was a bit uneven this time, since yesterday it was 20, then 50, then 70 but with long periods in-between those17:36
sil2100But yeah, I'd expect most should have gotten it yesterday regardless17:37
roadmrsil2100: right, it makes no sense that the final 30% would break things, everyting else looked stable17:37
roadmrsil2100: ok, no problem - your procedure looks correct17:38
sil2100roadmr: also, as said, it was sitting on phasing 100% for quite a while, I only did the final no-progressive call those ~2 hours ago17:39
sil2100Since I always have to do the final release API call after phasing to 100%17:39
roadmrright and we saw the issue about 1h ago, so they don't seem to correlate that well :/17:39
roadmrnp sil2100, I'll keep digging for what else may have caused it17:40
roadmr(it could have been a tail of core18 stragglers + a vscode-insiders release)17:40
mupPR snapcraft#2850 opened: hooks: enable command-chain <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2850>19:31

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!