[05:02] PR snapd#8854 closed: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir [05:12] PR snapd#8850 closed: dirs: delete unused Cloud var, fix typo [05:24] morning [05:25] hey mborzecki [05:26] mvo: hey [05:36] https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1858636 is interesting [05:36] Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium

[05:42] PR snapd#8837 closed: snap: add an activates-on property to apps for D-Bus activation [06:25] Hey guys [06:25] Unclear if I will work today, depending on ability [06:27] zyga: hey [06:28] Hey :-) [06:32] zyga: good morning [06:43] Hey mvo [06:44] I will file time of for Friday [06:48] zyga: yeah, please do [07:02] morning [07:03] pstolowski:hey [07:17] heh, even without font cache, spotify snap still segfaults on my host [07:21] hello [07:24] pstolowski: hi, I left some comments/questions in #8812 [07:24] PR #8812: o/snapstate: service-control task handler (4/N) [07:25] pstolowski: on a different note: is/can be #8532 useful or should we just close it? [07:25] PR #8532: tests: install new snapd deb into preseed image [07:26] pedronis: saw your comments, thanks for looking at it! [07:27] pedronis: 8532 might be useful, i need to think [07:28] pstolowski: ok, on a 3rd note: do you want to look at #8823 more ? [07:28] PR #8823: asserts/internal: limit Grouping size switching to a bitset representation [07:29] pedronis: yes, i'll conclude this review today [07:30] mvo: mborzecki: hi, we were having issues with centos on Fri, are we looking into it? [07:30] pedronis: what kind of issues? [07:31] let me check the most recent prs [07:31] mborzecki: https://github.com/snapcore/snapd/pull/8855/checks?check_run_id=766170841 selinux/package related [07:31] PR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil [07:32] pedronis: yeah, it's the same as https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310/28?u=mborzecki [07:33] mborzecki: do we need to mark them unstable? [07:34] 7 is also failing and marked required [07:34] pedronis: maybe, i need to poke around a bit more, had some trouble refreshing rhel vms in the morning [07:38] PR snapd#8858 opened: asserts,daemon: add support for "serials" field in system-user assertion === alazred_ is now known as alazred [07:49] heh, so centos is lagging behind again [07:50] and snapd 2.45 installs fine on rhel8 [08:01] hm a build of selinux-policy for centos in a sufficient version was done a couple of days ago https://koji.mbox.centos.org/koji/buildinfo?buildID=11412 but no clue where to find it [08:08] PR snapd#8859 opened: tests: enable snap-auto-mount test on core20 [08:19] pedronis: mvo: yeah, so with some info from folks in #centos it is lagging behind, 8.2 is in the oven so no updates are being pushed, and in general there is no clear solution for the latency of updates from rhel (which is used for epel builds) appearing in centos [08:20] mborzecki: mvo: so short term we shoul mark both centos unstable? [08:20] perhaps we should make that test smarter, rather than dumping whole centos to unstable [08:21] mborzecki: that sounds ok, but if is not trivial we should first unblock landings [08:22] mborzecki: also it's a bit unclear is a good use of time, I don't know. I agree that the fact that we have fully unsable systems, instead of unstable tests is a bit of a problem [08:23] otoh, how do we mark the system unstable right now? [08:26] mborzecki: I can mark it unstable (I uncheck "required test" in the settings box for this) [08:26] mvo: please do [08:30] mborzecki: done, centos-7 is no longer required [08:30] mvo: centos-8 :) [08:31] mborzecki: that is already not-required [08:31] mborzecki: should I make -7 required again? [08:31] mvo: yeah, sorry, centos-7 is good, only 8 needs to be non-mandatory [08:32] mborzecki: updated again, thank you :) [08:45] sil2100: hey, can you take a look at https://github.com/CanonicalLtd/ubuntu-image/pull/189 ? [08:45] PR CanonicalLtd/ubuntu-image#189: ubuntu_image: do not overwrite the files that snap prepare-image has created [08:48] PR snapd#8823 closed: asserts/internal: limit Grouping size switching to a bitset representation [08:53] PR snapd#8860 opened: overlord: refuse to install snaps whose activatable D-Bus services conflict with installed snaps [08:59] quick errand [08:59] starting work [09:01] pedronis: thank you for the changes to https://github.com/snapcore/snapd/pull/8829 - they look good [09:01] PR #8829: sandbox/cgroup: add tracking helpers [09:01] pedronis: I will prepare the next chunk in a moment [09:02] mborzecki: what is up with centos-8? [09:02] Problem: package snapd-2.45-1.el8.x86_64 requires snapd-selinux = 2.45-1.el8, but none of the providers can be installed [09:04] * zyga reads backlog [09:15] pstolowski: thanks, I expanded a bit my considerations: https://github.com/snapcore/snapd/pull/8812#discussion_r440038759 [09:15] PR #8812: o/snapstate: service-control task handler (4/N) [09:17] pedronis: thank you [09:21] mborzecki: do you think you could do a 2nd review for 8829? [09:21] it's the same code, just split out and polished a little [09:35] re [09:36] pstolowski: which snap did you try to debug with --gdbserver? [09:36] mborzecki: hello-world [09:37] ok, let me try that [09:38] meh, python 3.5 vs 3.8 [09:38] PR snapd#8861 opened: data,packaging,wrappers: extend D-Bus service activation search path [09:40] zyga: centos-8 should be marked as unstable, even if it fails it should be possible to merge a PR [09:40] I see [09:40] are we waiting for something to migrate? [09:40] zyga: and i'll be adding some details about centos-8 and epel to the standup docs [09:40] ok [09:44] mborzecki: hi, I updated https://github.com/snapcore/snapd/pull/8844 to keep only the benchmarks as we discussed previously [09:44] PR #8844: asserts/internal: add some iteration benchmarks [09:48] pedronis: thanks! [09:54] mvo: I reviewed #8858, missing some bits (format is a bit complicated) [09:54] PR #8858: asserts,daemon: add support for "serials" field in system-user assertion [09:55] pedronis: thank you, looking [10:00] mborzecki: are you checking my remark about seond 'continue'? [10:01] pstolowski: yeah, that was my intention, but got into a fight with py35 in ubuntu-image :/ [10:01] haha === pedronis_ is now known as pedronis [10:44] PR snapd#8784 closed: snap: add new `snap run --experimental-gdbserver` option [10:55] mborzecki: would you have any idea of what sort of changes I'd need to fix this error? https://github.com/snapcore/snapd/pull/8861#issuecomment-644048833 [10:55] PR #8861: data,packaging,wrappers: extend D-Bus service activation search path [10:55] jamesh: looking [10:56] mborzecki: in short, I need to make a couple of directories under /var/lib/snapd readable by dbus-daemon [10:56] while being writable by snapd [10:57] jamesh: should be fairly simple, i can push a patch there [10:58] mborzecki: thanks. That seemed like the only legitimate failure in the logs so far. [10:58] good thing you added that regression test :-) [10:59] jamesh: mhm, yeah we need to updae the policy, system_dbusd_t (used dbus-daemon) does not have read access to /var/lib/snapd [11:00] mborzecki: I suppose we can't just label /var/lib/snapd/dbus in a way to give it access if it can't read /var/lib/snapd :( [11:00] or traverse it at least [11:01] I have updated a snap (atom) which now complains that "- Mount snap "atom" (256) (cannot find required base "core")" - but i have core installed. https://paste.ubuntu.com/p/kMNzw3Jj8v/ any ideas? [11:01] you can "snap install atom --edge --classic" to try for yourself. [11:02] jamesh: we could use the same label as /usr/share/dbus/services.d but then quite likely we'd need to update the snapd policy to allow snapd write access there [11:02] jamesh: either way, a change is needed [11:02] i wonder why there was no error on fedora though [11:04] jamesh: hi [11:04] sorrym I'm not around during the calls much [11:04] not the best moment in my life [11:04] mborzecki: it should be similar label to /usr/share/dbus-1/{services,system-services} -- not sure if that differs to session.d/system.d [11:04] I left a pair of small comments on https://github.com/snapcore/snapd/pull/8861 [11:04] PR #8861: data,packaging,wrappers: extend D-Bus service activation search path [11:04] zyga: no problem [11:05] jamesh: sorry to nickpick about the name but I really wonder why we use "services" and not "session-services" [11:06] zyga: I followed the naming scheme that D-Bus uses, as mentioned in the comment. I'm not sure it is worth being different [11:07] I see, I missed that when jumping through the diff [11:11] zyga: and as always, thanks for the review feedback :-) [11:15] jamesh: do we need to reload dbus-daemon to have it pick up those extra conf files? [11:15] i would guess that system dbus got reloaded/restarted on centos 7 and that triggered the denial [11:17] Interesting, I recall a bug where it would only work if a directory was present to start with [11:17] as otherwise dbus would not establish some inotify watch [11:17] I don't recall the details [11:18] mborzecki: there is a restart method you can send, but I think it generally picks things up via inotify these days [11:19] mborzecki: we don't currently do it when adding/removing system bus policy, but probably should. [11:19] perhaps that should be a new PR [11:19] jamesh: isn't inotify only for service.d system.d directories? [11:22] mborzecki: once it reads the new config file from /usr/share/dbus-1/system.d or session.d, it should start monitoring the new directory for service activation files [11:34] core20 prepare fails, has anyone looked at that? [11:44] that's recent [11:56] jamesh: heh, the test is fine in isolation as suspected [12:09] hi everyone, quick question, were there any known changes to gadget structure for core20 builds? my ubuntu-image cli fails on the last step of building a core20 based image with "cant find boot config". [12:09] in the gadget's stage folder i can see all the grub related files [12:16] ooh one sec i realized something... snapcraft clean actually never removes gadget and parts folder somehow, i manually deleted them, did another build and the gadget snap is created but there is no stage or parts folder hmm [12:18] mborzecki: o/ [12:18] mborzecki: I opened a small tweak and another chunk carved out of the refresh tracking logic [12:19] mborzecki: the tweak is https://github.com/snapcore/snapd/pull/8862 and is really small apart from mv'ing some code around - I did this to allow the diff in cgroup.go (in subsequent branches) to be readable [12:19] zyga: trading PR for PR https://github.com/snapcore/snapd/pull/8864 :) [12:19] PR #8862: sandbox/cgroup: improve pid parsing code [12:19] PR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro [12:19] mborzecki: and to make sure I didn't break anything in conflict resolution [12:19] PR snapd#8862 opened: sandbox/cgroup: improve pid parsing code [12:19] PR snapd#8863 opened: sandbox/cgroup: allow discovering PIDs of given snap [12:19] mborzecki: gladly :) [12:19] PR snapd#8864 opened: cmd/snap: do not show $PATH warning when executing under sudo on a known distro [12:19] mborzecki: the only new change is that I simplified PidsInGroup [12:20] compare https://github.com/snapcore/snapd/pull/8862/files#diff-a44752c174bd4af51ccc892ed5bc15b4L212 and https://github.com/snapcore/snapd/pull/8862/files#diff-a5c0640204de19f988a6d5446e6108e6R32 [12:20] it was a simple code reuse as everything was exactly the same [12:20] the https://github.com/snapcore/snapd/pull/8863 is a bigger PR that involves one main new function in the form taken verbatim out of refresh app awareness v2 branch - again split to a new file for readability [12:20] PR #8863: sandbox/cgroup: allow discovering PIDs of given snap [12:21] mhm [12:21] comments there probably need tweaking but the logic is what I wanted it to be [12:21] the comment on the PR is more accurate than than the comments inside [12:21] ok, that's that [12:21] going to look at your PR :) [12:23] mborzecki: is there a spread test that shows this warning? [12:24] zyga: afaik there isn't one [12:25] ok [12:25] btw, I found one thing over weekend [12:25] grep -x [12:25] very useful for line matches [12:25] especially as grep -qFx [12:25] quiet, literal, whole line matches [12:25] it's essentially a line in open("fname").splitlines() in shell [12:26] mborzecki: could you add a test, I think it's going to be useful to let us know the list is stale [12:26] apart from that and the nitpick inline +1 [12:47] * zyga reviews services changes from pawel [12:50] PR snapcraft#3170 closed: repo: decouple fetch and unpack stage-packages [12:55] clmsy: yes, gadget look different/have different details in UC20 (and some details are still in flux), I recommend ATM looking at the 20 branches of https://github.com/snapcore/pi-gadget and https://github.com/snapcore/pc-amd64-gadget for an idea [13:28] * zyga lunch break (ha ha, in bed :() [13:35] zyga!!! hope you get better! I'm too far to help but let me know if I can in any way [13:39] thanks Daniel, being here and working keeps me sane [13:41] 👍 [13:41] just don't work too much :) [13:41] ijohnson: confirmed the classic → strict refresh issue https://bugs.launchpad.net/snapd/+bug/1883538 [13:41] Bug #1883538: Classic to strict refresh requires manual intervention [13:42] almost looks like staged refresh… [13:43] we only have about 10% of the people tracking stable on the most recent revision (that's out for a week now) [13:43] mvo: FYI ↑ [13:45] Saviq: oh, interessting. thank you, will look after my current meeting [14:00] thanks Saviq [14:00] we will look in a bit, I too have a meeting now :-) [14:02] pstolowski: https://github.com/snapcore/snapd/pull/8812#pullrequestreview-430673354 [14:02] PR #8812: o/snapstate: service-control task handler (4/N) [14:02] zyga: thank you [14:06] * zyga debugs the core 20 prepare failure [14:12] has anybody tried running UC20 on kvm + TPM (simulated or passthrough) for disk encryption? [14:12] abeato: yes not passthrough, but simulated [14:12] ijohnson, cool - any special issue with that or things just work? [14:13] abeato: yes it should just work, what issues are you running into? [14:13] ijohnson, none, just double checking before I enter a rabbit hole :) [14:13] abeato: for now, I use the swtpm-mvo snap + socket to provide to qemu [14:13] ijohnson, will try that, thanks [14:14] abeato: this is my qemu cmdline I use with a copy of the OVMF_VARS.ms.fd from the ovmf package: [14:14] https://www.irccloud.com/pastebin/I4HPR8u9/ [14:53] zyga: should probbaly land https://github.com/snapcore/snapd/pull/8863 first [14:53] PR #8863: sandbox/cgroup: allow discovering PIDs of given snap [14:54] zyga: w8, not this one, this one: #8862 [14:54] PR #8862: sandbox/cgroup: improve pid parsing code [14:55] looking [14:55] yeah [14:55] with one review? [14:55] maybe pawel can do a quick one [14:55] it's just moving a few lines around [14:55] mborzecki: thanks for this! [14:56] zyga: or ijohnson/cmatsuoka maybe? [14:56] yeah [14:56] anyone who's around [14:56] sorry, I'm kind of out of touch [14:56] ah I see ijohnson is around [14:56] whats up [14:56] which PR? [14:56] https://github.com/snapcore/snapd/pull/8862 [14:56] PR #8862: sandbox/cgroup: improve pid parsing code [14:57] 2nd review, just moving code around _and_ simplifying the main function since it had a common implementation with a private function already present [14:57] it's good to chat to you guys btw [14:57] I'm sorry for not joining the standups now [14:57] I really want to get over this part of my life [14:57] ijohnson: zyga: if https://github.com/snapcore/snapd/pull/8864 is green, i'll merge it and add a test in a follow up [14:57] PR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro [14:58] k, sounds good to me [14:58] mborzecki: that's okay [14:58] mborzecki: the test is mainly to see it break over time [14:58] :) [14:58] kind of distro-sensors [15:00] is spread on core 20 working now? [15:00] pedronis: it seems that preparing it intermittently fails because there are snaps in the classic 20.04 image we use to prepare it [15:00] yeah [15:00] I saw some reds preparing on Friday, some greens preapring on Friday [15:00] I'm running a loop to get a shell and look around [15:01] is this the issue that we seem not to get the same image all the time? [15:01] I think it's really the problem that mvo described is that we don't get the same image all the time [15:01] pedronis: yes [15:01] at least afaict [15:01] :/ [15:01] maybe it's something else too [15:02] woah [15:02] interesting [15:03] do we have hard proof that this happens? [15:03] (!same image) [15:03] zyga: the hard proof is that we sometimes get an image with snaps installed in it, and sometimes we get an image without snaps installed in it [15:04] hmm [15:04] maybe we always get an image with a seed inside [15:04] iirc mvo added a check to make preparing fail if it detects snaps installed in the image [15:04] and we sometimes manage to seed [15:04] and sometimes dont [15:05] zyga: you approved the PR :-) [15:05] https://github.com/snapcore/snapd/pull/8849 [15:05] PR #8849: tests: fail in setup_reflash_magic() if there is snapd state left [15:05] yeah but I didn't know it turned something up [15:07] zyga: so from what I see 8862 is just reorganization, without any feature changes? [15:07] cmatsuoka: yes [15:07] cmatsuoka: one tiny code change, if you look at the public function [15:07] but it's 100% identical after, just calls a helper that happens to do the common tail [15:08] zyga: yes, I noticed that, and it looks better this way [15:08] yeah, it's easy to follow top to bottom [15:10] thanks guys! [15:12] zyga: how are you feeling? getting better? [15:12] cmatsuoka: not actually [15:12] cmatsuoka: more news on Wednesday after doc visit [15:16] zyga: I hope you get well soon [15:16] thanks, I really want to [15:50] PR snapd#8865 opened: workflow test PR title as part of the static checks again [16:10] https://github.com/snapcore/snapd/pull/8863 is now ready for review [16:10] PR #8863: sandbox/cgroup: allow discovering PIDs of given snap [16:10] broken out of the refresh-app-awareness-v2 branch [16:10] PR snapd#8862 closed: sandbox/cgroup: improve pid parsing code [16:59] hey folks, could I get reviews on https://github.com/snapcore/snapd/pull/8519, it is green now after I debugged it more and fixed the test [16:59] PR #8519: tests/special-home-can-run-classic-snaps: re-enable <⚠ Critical> === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [18:31] PR snapd#8844 closed: asserts/internal: add some iteration benchmarks [19:01] PR snapd#8864 closed: cmd/snap: do not show $PATH warning when executing under sudo on a known distro [19:06] PR snapd#8866 opened: tests/main: add spread test for running svc from install hook [19:41] PR snapd#8867 opened: interfaces: add uinput interface