[05:50] <mborzecki> morning
[06:19] <zyga> mborzecki: good morning
[06:21] <mborzecki> zyga: hey
[06:39] <mborzecki> deconflicted https://github.com/snapcore/snapd/pull/8464
[06:39] <mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
[06:39] <mborzecki> otherwise out doing errands, i'll be back for sprint meetings
[06:41] <mborzecki> oh and install/re(install)/recover worked with pc_98.snapm, pc-kernel_473.snap and snapd from edge
[06:41] <zyga> Good luck and see you later mborzecki
[07:02] <pstolowski> morning
[07:02] <zyga> hey pawel
[07:03] <zyga> this will be a quiet morning
[07:09] <pstolowski> yep
[07:16] <mup> PR snapd#8436 closed: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <⛔ Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8436>
[07:17] <mup> PR snapd#8436 opened: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <⛔ Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
[07:32] <zyga> pedronis: good morning
[07:32] <zyga> pedronis: I will write the details of the inhibit lock idea and share the link with you
[07:34] <pedronis> ok
[07:36] <mup> PR snapd#8562 opened: store: implement DownloadAssertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/8562>
[08:09] <zyga> pedronis: https://forum.snapcraft.io/t/wip-refresh-app-awareness/10736/33
[08:09]  * zyga AFK for some time
[08:13] <zyga> actually no
[08:16] <zyga> store is still responding with 429 - too many requests - sometimes
[08:26] <mup> PR snapd#8563 opened: asserts/internal: introduce Grouping and Groupings <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8563>
[08:29] <mup> PR snapd#8564 opened: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>
[09:13] <pedronis> lots of red again afaict
[09:16] <mvo> pedronis: do you have an example of a recent run with reds?
[09:16] <mvo> pedronis: what PR should I look at?
[09:17] <pedronis> mvo: here for example: https://github.com/snapcore/snapd/pull/8436  I suppose it's the store but haven't looked at the logs
[09:17] <mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <⛔ Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
[09:18] <mvo> pedronis: yeah, anything that fetches core runs into timeouts it seems
[09:19] <zyga> I saw store returning errors
[09:19] <zyga> 429
[09:22] <mup> PR snapd#8565 opened: osutil: expand FileLock to support shared locks and more <Created by zyga> <https://github.com/snapcore/snapd/pull/8565>
[09:32] <mborzecki> re (kind of)
[09:46] <mborzecki> mvo: pedronis: any high priority 2.45 PRs that need reviews/fixes?
[10:05] <mup> PR snapd#8566 opened: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
[10:12] <pstolowski> sil2100: hey! do you have a moment to take a look at https://github.com/snapcore/core-build/pull/59 ?
[10:12] <mup> PR core-build#59: initramfs: add new handle_writable_defaults() <Created by mvo5> <https://github.com/snapcore/core-build/pull/59>
[10:13] <sil2100> pstolowski: hey! Is this the same as for core20?
[10:15] <pstolowski> sil2100: no, core20 is separate (https://github.com/snapcore/core20/pull/46, which you commented on)
[10:15] <mup> PR core20#46: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
[10:29] <mup> PR snapd#8567 opened: o/devicestate: core20 early config from gadget defaults <Created by stolowski> <https://github.com/snapcore/snapd/pull/8567>
[11:32] <sil2100> pstolowski: yeah, I guess I'll have the same weird question here, since the code is the same - can someone explain the meaning of the -L check in that particular conditional?
[11:39] <mvo> sil2100: I replied in the PR, this is to ensure that broken symlinks will still get created
[11:40] <mvo> sil2100: as -e will follow the symlink target and return false if there is a symlink but it point's to the void
[11:40] <mvo> sil2100: hence we need -L in addition, there is a "unit" test for this as well
[11:44] <mup> PR core#112 opened: Fix English in comment around usage of spellcheck <Created by ykoehler> <https://github.com/snapcore/core/pull/112>
[11:54] <mup> PR snapd#8568 opened: asserts: rest of the Pool API <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8568>
[11:56] <mup> PR snapd#8569 opened: o/assertstate,asserts: use bulk refresh to refresh snap-declartions <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
[12:14] <mup> PR core#112 closed: Fix English in comment around usage of spellcheck <Created by ykoehler> <Merged by mvo5> <https://github.com/snapcore/core/pull/112>
[13:01] <ijohnson> zyga: is there no SU today?
[13:02] <zyga> hey
[13:02] <zyga> I don't think so
[13:02] <zyga> but we can meet if you have something to share
[13:02] <zyga> pstolowski: ^ ?
[13:02] <zyga> I have some cool stuff
[13:02] <ijohnson> my update is just UC20 UC20 UC20
[13:02] <zyga> https://meet.google.com/rni-xhsz-uqt
[13:02] <zyga> :)
[13:03] <pstolowski> zyga: ijohnson hi, i'm in the opening plenary
[13:03] <zyga> pstolowski: can you share the link in private?
[13:03] <pstolowski> perhaps when it's over?
[13:03] <zyga> ijohnson: join and I can share some fun stuff
[13:04] <ijohnson> sure
[13:04] <pstolowski> zyga: i can, it's from the calendar you gave me in the morning ;)
[13:11] <mup> PR snapd#8570 opened: many: allow using ~/.snapdata instead of ~/snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8570>
[13:13] <Gargoyle> Is it necessary for every snap app to spam the journal with these messages:- Apr 27 14:11:21 zion2 audit[359771]: AVC apparmor="DENIED" operation="connect" profile="snap.mysql-workbench-community.mysql-workbench-community" name="/run/uuidd/request" pid=359771 comm="mysql-workbench" requested_mask="w" denied_mask="w" fsuid=1000 ouid=0
[13:16] <mborzecki> Gargoyle: thanks for reproting, afaik access to /run/uuidd/request was part of one specific interface, but since 2.45 (to be released soon) is aprt of the base template
[13:17] <Gargoyle> Seems every snap I've installed (clean install of 20.04 a few days ago) is reporting the same message over and over.
[13:18] <ogra> the next snapd update will fix this as mborzecki said ...
[13:18] <pstolowski> zyga, ijohnson standup?
[13:18] <ijohnson> pstolowski: we are in zyga link above
[13:19] <Gargoyle> Ahh. OK
[13:19] <mborzecki> Gargoyle: yeah, seems like a popular way to obtain uuids (idk why /proc/sys/kernel/random/uuid isn't as popular and does not require a separate daemon)
[13:20] <zyga> pstolowski: can you join?
[13:20] <pstolowski> ijohnson, zyga 4 people are in regular standup HO
[13:20] <zyga> oh
[13:20] <zyga> I didn't get the link
[13:21] <ogra> you guys are entertaining today !
[13:59] <cmatsuoka> ijohnson, pstolowski, cachio: I just ran another test here and it works well before the refresh, but it fails at the-tool in the post-refresh boot
[13:59] <cmatsuoka> I'll try it non-encrypted to be able to see what's going on
[13:59] <ijohnson> cmatsuoka: I assume that's with edge everything and remastered kernel snap ?
[14:00] <cmatsuoka> ijohnson: it's core20 602, gadget 96, remastered kernel 470
[14:01] <cmatsuoka> ijohnson: did something important change in core20 or gadget?
[14:01] <cmatsuoka> I mean, core20 or kernel?
[14:01] <ijohnson> well the kernel was revved over the weekend, I see rev 473 on edge now
[14:01] <cachio> cmatsuoka, here it is still running
[14:02]  * cmatsuoka updates kernel
[14:05]  * zyga -> lunch
[14:05] <pstolowski> cmatsuoka: what about nested/basic core20 test? does it work
[14:10] <cachio> pstolowski, I am running these tests now
[14:10] <cachio> I'll tell you
[14:10] <pstolowski> cachio: ok, ty
[14:11] <cachio> pstolowski, I'll let you know
[14:15] <cmatsuoka> store is very, very slow right now
[14:16] <cachio> last run I got kill timeout downloing the kernel snap
[14:24] <zyga> re
[14:24] <zyga> cmatsuoka: yes, painfully slow :/
[14:28] <mborzecki> release effect stilll?
[14:30] <zyga> mborzecki: compound effect, more than one issue
[14:38] <zyga> I've updated https://github.com/snapcore/snapd/pull/8570 with some more expectations
[14:38] <mup> PR #8570: many: allow using ~/.snapdata instead of ~/snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8570>
[14:43] <cmatsuoka> ijohnson: apparently the problem was caused by a local change that I thought it would be totally harmless
[14:44] <ijohnson> cmatsuoka: good to know, what was the change?
[14:44] <cmatsuoka> ijohnson: experimentations moving the snap-bootstrap bootstrap and partition packages to gadget
[14:45] <ijohnson> ah I see
[14:48] <pedronis> cmatsuoka: that needs a bit of design btw, it's not just mechanical
[14:49] <pedronis> there is some semi-duplication between bits of gadget and partition
[14:49] <pedronis> that is not super clear what to do about
[14:49] <cmatsuoka> pedronis: yes, I noticed that it wouldn't be a simple move
[14:50] <pedronis> cmatsuoka: maybe you can have a chat with mborzecki, he might have input on that
[14:51] <pedronis> there's an unclear relation between the bits that existed for snap-image
[14:51] <pedronis> and the stuff for snap-bootstrap
[14:51] <cmatsuoka> pedronis: the other thing I was going to examine was to integrate the new helpers from secboot
[14:51] <cmatsuoka> pedronis: perhaps that would be a more productive thing to do right now?
[14:52] <pedronis> cmatsuoka: it might be easier,  if you look at that my comments on the measure model PRs, there are a couple of helper in snap-boostrap
[14:52] <pedronis> that belong in secboot I think
[14:53] <pedronis> cmatsuoka: a question is a bit whether we want them as functions or we want some kind of wrapper around a tpm connection
[14:53] <pedronis> that can be set up even if there's no tpm
[14:53] <cmatsuoka> pedronis: I'll have a look
[14:53] <pedronis> but then the functionaliy/some functionality becomes NOPs
[15:09] <cachio> pstolowski, tests are failing
[15:09] <cachio> pstolowski, can't validate the fix
[15:10] <pstolowski> cachio: kill timeouts? or store?
[15:10] <cachio> pstolowski, the store
[15:10] <cachio> getting kill timeout but downloading snaps
[15:12] <ijohnson> cachio: downloading snaps for me is incredibly slow right now
[15:13] <roadmr> having slow snap downloads? kill it then restart. Also wait a bit, things are being tweaked right now
[15:15] <ijohnson> roadmr: I've killed it at least 5 times now and keep getting 503s eventually
[15:15] <roadmr> then please wait a bit, things are being tweaked right now :)
[15:15] <ijohnson> sure
[15:17] <cachio> ijohnson, yes
[15:18] <cachio> ijohnson, it is making all the tests fail
[15:40] <zyga> is anyone upgrading to groovy yet?
[15:45] <ijohnson> hah
[15:45] <ijohnson> a
[15:46] <zyga> that's it, I'm moving to groovy ;)
[15:47] <roadmr> the name conflicting with groovy is slightly unfortunate heh
[15:48] <roadmr> "why do you move to groovy! it's java deep down inside,argh"
[15:57] <roadmr> cachio, ijohnson : are things  happier for you folks now?
[15:57] <ijohnson> roadmr: let me check now
[15:59] <cachio> roadmr, running tests, I'll let you know in few minutes
[15:59] <cachio> roadmr, thanks
[15:59] <roadmr> well "snap download whatever" and if it doesn't 503 or be dog-slow then you're ok :)
[16:00] <ijohnson> roadmr: much much much much much much much better now
[16:00] <ijohnson> thank you!
[16:00] <roadmr> I did nothing :)
[16:00] <ijohnson> (and the whole snapstore team in general too :-) )
[16:00] <roadmr> thanks !
[16:06] <cachio> roadmr, seems to be working much better now
[16:06] <roadmr> thanks for confirming cachio :)
[16:16] <zyga> degville: hey, not sure if you look at github notifications
[16:17] <zyga> degville: I've opened a small PR with two paragraphs of text
[16:17] <zyga> degville: I think the text I've used is terrible and I need some help
[16:17] <zyga> https://github.com/snapcore/snapd/pull/8571
[16:17] <mup> PR #8571: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <https://github.com/snapcore/snapd/pull/8571>
[16:17] <zyga> the text is right up front in the diff
[16:17] <mup> PR snapd#8571 opened: overlord/snapstate: warn of refresh/postpone events <Created by zyga> <https://github.com/snapcore/snapd/pull/8571>
[16:17] <zyga> in the tests below you can see how it would look like at runtime: https://github.com/snapcore/snapd/pull/8571/files#diff-5a74ab37983225c1b7fd74b7f20746e0R670
[16:18] <degville> zyga: thanks for letting me know! I'll take a look (I do try to keep on top of GH notifications)
[16:18] <zyga> if you have a moment I would love to get some better sentences instead
[16:18] <zyga> super, thank you :)
[16:23] <mup> PR snapd#8572 opened: packaging: add the inhibit directory <Created by zyga> <https://github.com/snapcore/snapd/pull/8572>
[16:34] <mup> PR snapd#8573 opened: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>
[16:42]  * zyga EODs
[16:49] <mup> PR snapd#8560 closed: tests: disable "searching" test <⚠ Critical> <⛔ Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8560>
[17:40] <cmatsuoka> ijohnson: have you seen this error before? https://pasteboard.co/J5Mjrds.png
[17:40] <ijohnson> cmatsuoka: no sorry I don't have time to debug it right now
[17:41] <ijohnson> and also to be clear I haven't seen that error
[17:41] <cmatsuoka> thanks, just checking
[18:25] <cachio> cmatsuoka, still I see the smae issue https://paste.ubuntu.com/p/3C8Xg6WjcZ/
[18:26] <cachio> cmatsuoka, at some point the message Press enter to configure. should appear
[18:26] <cachio> cmatsuoka, right?
[18:26] <cachio> I am runnign without the -cpu host
[18:26] <cachio> because it make qemu fail on google
[18:26] <cachio> cmatsuoka, should I try to find an alternative?
[18:27] <cachio> for -cpu host
[18:27] <pedronis> I suspect yes,  the default has other problems
[18:31] <cmatsuoka> cachio: checking the log...
[18:31] <cachio> I see this error. qemu-system-x86_64[62220]: qemu-system-x86_64: /build/qemu-74sXTC/qemu-4.2/target/i386/kvm.c:2680: kvm_buf_set_msrs: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed.
[18:32] <cachio> when I use -cpu host
[18:41] <cmatsuoka> cachio: it's a bit unclear to me what could be happening there, I'm researching a little bit
[18:43] <cachio> thanks
[18:44] <Saviq> jdstrand: hey, when you get a chance, could you please add `interface: home; read-all: true` to auto-connections for Multipass?
[18:45] <jdstrand> Saviq: why is that needed? (I need to document this)
[18:45] <Saviq> jdstrand: to allow launching images coming from user's homes
[18:46] <Saviq> jdstrand: we may avoid it long-term by amending our own profile runtime
[18:46] <Saviq> to allow access to that one file (which could be outside of /home at that point)
[18:47] <jdstrand> Saviq: ok, thanks
[18:48] <cmatsuoka> cachio: debugging msr failures seems to be hard: https://bugs.launchpad.net/qemu/+bug/1661386
[18:48] <mup> Bug #1661386: Assertion `ret == cpu->kvm_msr_buf->nmsrs' failed <QEMU:Fix Released> <https://launchpad.net/bugs/1661386>
[18:50] <Saviq> cachio, cmatsuoka: zyga came to us yesterday with a strangely similar issue, is this nested on VMWare Fusion? If not, please ignore :)
[18:51] <cmatsuoka> Saviq: it's nested but on gce
[18:52] <cmatsuoka> Saviq: I'm googling for similar reports and they're quite weird
[18:53] <cmatsuoka> Saviq: I think gce uses kvm
[18:54] <Saviq> the last update to qemu on bionic was in February, so unlikely for that to be related http://changelogs.ubuntu.com/changelogs/pool/main/q/qemu/qemu_2.11+dfsg-1ubuntu7.23/changelog
[18:55] <zyga> Saviq: could you rebase on core 20?
[18:56] <zyga> I suspect is is the same security they paper over
[18:56] <cmatsuoka> Saviq: what we actually need is a qemu cpu with rdrand so we're using -cpu host, and doing that triggered the msr problem cachio reported
[18:57] <zyga> This is the same as I debugged
[18:57] <zyga> Dropping -cpu host fixes it for me
[18:58] <cmatsuoka> hmm, I see that vmware rejects pmu msr accesses
[18:58] <cmatsuoka> zyga: is your problem related to pmu?
[18:59] <cmatsuoka> zyga: if so -cpu host,pmu=off might help
[19:00] <zyga> I did not use pmu
[19:55] <cmatsuoka> cachio: I don't have any good idea on how to address that, I think it's better to open a bug for kernel reporting it and see if anyone suggests a flag to use or a workaround
[19:55] <cmatsuoka> cachio: I see similar problems reported for azure and other nested cases, but not this problem exactly
[19:57] <cmatsuoka> cachio: I mean, for qemu
[19:59] <cmatsuoka> cachio: not kernel
[20:01] <cachio> cmatsuoka, it is weird because it was working 2 weeks ago
[20:01] <cachio> then a change made that it didnt work any more
[20:02] <cmatsuoka> cachio: oh really? hmm, what could have changed?
[20:03] <cachio> cmatsuoka, not sure
[20:03] <cachio> last week I started to see that new behaviour
[20:06] <cmatsuoka> cachio: can we try an older image to see if it still works?
[20:09] <cachio> no
[20:09] <cachio> cmatsuoka, we build the image in the test
[20:10] <cachio> I cant re-create an old image
[20:10] <cachio> but I could use snapd from beta
[20:10] <cachio> does it make sense?
[20:10] <pedronis> but the bug is in qemu
[20:10] <pedronis> so it's about the host
[20:10] <pedronis> not the uc image
[20:11] <cachio> pedronis, there are 2 things
[20:11] <pedronis> unless is the kernel in the uc image triggering something
[20:12] <cachio> a bug in qemu and also this issue that I see that the first boot does not finish
[20:12] <cachio> install mode goes well
[20:12] <cachio> then in run mode it does not finish
[20:12] <cachio> and it was working 2 weeks ago with the same qemu/kvm
[20:13] <cachio> pedronis, I'll try with an older kernel and older snapd to see what happens
[20:29] <roadmr> hey who knows a bit about spread? :) Cannot allocate lxd:ubuntu-18.04: cannot list lxd remotes: exec: "lxc": executable file not found in $PATH
[20:57] <mup> PR snapcraft#3090 closed: ci: move staging store tests to spread <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3090>
[20:58] <roadmr> sergiusens: maybe you know about that error I got above? lxc/d is installed, though from deb, not snap
[20:58] <roadmr> sergiusens: btw this looks much easier to set up / run than the old way :) thanks
[21:13] <mup> Bug #1875493 opened: [core] log rotation doesn't properly restart rsyslogd <Snappy:New> <https://launchpad.net/bugs/1875493>
[21:53] <ijohnson> roadmr: are you using spread via the snap ?
[21:53] <ijohnson> oh well nvm
[22:44] <diddledan> jdstrand, if you're about, is the gnome session manager dbus api (for uses other than screen-inhibit-control) omitted from the desktop or desktop-legacy plugs because we're expecting snaps to define their use via a custom plug?
[22:44] <diddledan> specifically it's on the session bus at endpoint org.gnome.SessionManager member RegisterClient
[22:45] <diddledan> possibly also an UnregisterClinet?
[22:46] <diddledan> for an example snap that is trying to use the api:: https://forum.snapcraft.io/t/openaudible-bounty/16835/8