[09:14] hey guys, can snapd tell me if a particular snap has been installed and removed before? [09:42] PR snapcraft#2954 opened: cli: enable config file for base snapcraft command [10:19] sil2100, is vorlon not coming to the sprint ? i was hoping we could discuss some changes to ubuntu-image this week (i also wanted to talk to waveform about some pi-gadget breakage too, but i see he wont be here either) [10:56] ogra: he's not [11:01] cjwatson, yeah, just learned that in person from sil ... [11:18] PR snapcraft#2955 opened: repo: respect http proxy for apt update [11:30] PR snapcraft#2794 closed: Add gnome 3 34 extension [11:30] PR snapcraft#2945 closed: ci: only run docker builds for cron [11:33] PR snapcraft#2956 opened: Add gnome 3 34 extension [12:45] jdstrand: hello [12:45] zyga: hey [12:45] jdstrand: how are you doing? :) [12:46] jdstrand: I'll try to progress on the session problem you highlighted this week, if I can [12:46] zyga: I'm ok. it feels real weird not being there [12:46] jdstrand: there are some empty-ish rooms around [12:46] I heard [12:48] jdstrand: not as a security review, but I was curious if https://github.com/snapcore/snapd/pull/8216 works on your system [12:48] PR #8216: tests: add session-tool, a su / sudo replacement [12:48] can. you use it to spawn a shell as yourself [12:48] and run snaps (with current snapd) [12:49] I would like to eliminate the chance that there's something extra special about your system [12:49] perhaps pam_apparmor [12:49] or something like that [12:50] zyga: is this for the transient scope issue I had? [12:50] yes [12:50] and a lot of other tests that effectively incorrectly run code as the "test" user [12:50] zyga: so, the system in question was a default bionic desktop install in a vm [12:50] (so no pam-apparmor [12:50] ) [12:50] aha [12:51] so it should work, I tested that case [12:51] if you want to fire it up anyway feel free but not really needed [12:51] I also don't have pam apparmor on my laptop [12:52] zyga: I'm going to finish up some reviews today. when I am about to do those, I will try out 8216 and report problems, if any. if you don't herre from me, consider it fine. is that ok? [12:52] jdstrand: that's great [12:52] I'll push forward on getting to the bottom of the problem you uncovered [13:07] PR snapcraft#2955 closed: repo: respect http proxy for apt update [13:34] zyga: the next time you see mvo, can you let him know that I added comments to the Frankfurt sprint doc and various meeting invites? [13:34] jdstrand: I will [13:34] thanks [13:34] jdstrand: he's here but we're in a meeting now [13:36] zyga: it isn't urgent, just want him to be aware [14:31] jdstrand: mvo now knows [14:54] zyga: thanks! :) === hggdh is now known as hggdh-msft [15:16] stgraber: do you think this bug is what you showed me a number of times [15:16] https://bugs.launchpad.net/snapd/+bug/1865503 [15:16] Bug #1865503: snapd (deb) fails to install snapd (snap) inside LXD on a buildd based image [15:16] stgraber: first snap installation fails in lxd [15:20] Yeah, run it again and it will succeed [15:25] stgraber: right, it seems to be a bug at the intersection of udev and lxd [15:25] stgraber: can you think of a reason why this fails, is it the sandbox lxd provides? [15:26] stgraber: is there a way to detect LXD that's reliable [15:26] stgraber: so that we could perhaps fix the base udev rules to not fail [15:26] /dev/lxd is usually a good bet, that or systemd-detect-virt [15:26] stgraber: excellent [15:27] stgraber: I'll run by foundations and check if this can be fixed [15:30] rharper: can you please join a hangout, it should be in the invite [15:30] y [16:06] PR snapd#8217 opened: o/devicestate: delay the creation of mark-seeded task until asserts are loaded