[05:24] morning [06:19] quick errand, brb [06:29] Good morning [06:29] Let’s catch up on email [06:29] And administrative tasks [06:51] https://github.com/snapcore/snapd/pull/8881 needs a 2nd review [06:51] PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs [07:00] re [07:02] hey :) [07:06] morning [07:06] zyga: hey, how are you feeling? [07:06] pstolowski: hey [07:07] hey pawel! [07:07] mborzecki: without pain killers, pretty bad [07:07] with them, passable [07:07] two weeks of bed now [07:07] but hey, special bed desk arrives today [07:10] so no more cramped legs :) [07:41] PR snapd#8895 closed: tests: mock servicestate in api tests to avoid systemctl checks (6/8) [07:44] hello [08:02] pedronis: hey [08:31] do we have a helper that checks wheher snapd reexec'ed? [08:34] zyga: ^^ [08:35] mborzecki: I think we have some logic like that in cmd/* somewhere [08:35] i see there's some code in snapdtool, but it derives the location of the internal tooling [08:35] but there was some change recently [08:35] zyga: i was hoping for something like `IsReexeced() (boot, error)` ;) [08:36] right :) [08:36] don't we have a env variable for thaT? [08:37] zyga: is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652 fixed released now? [08:37] Bug #1871652: snap run hangs on system-key mismatch due to reexec and shutdown [08:37] pedronis: I think so [08:37] 2.44.3 was released as .5 IIRC [08:39] Bug #1870201 changed: lxd-support interface doesn't appear to get properly connected/ready [08:39] Bug #1871827 changed: git ubuntu submit fails on focal

[08:39] Bug #1882957 changed: Snapd `internal error: connection "[slot] [plug]" not found in state` [09:09] zyga: hmm, we don't? [09:10] zyga: looks like we're jut passing os.Environ() to exec [09:15] mborzecki: snapdtool is just what was in cmd and cmdutil move to one place, didn't change or add much [09:15] *moved [09:15] pedronis: zyga: in the context of #8861, i'm not sure we should be writing out the conf fies to /usr/share/dbus-1 unless snapd is reexeced [09:15] PR #8861: data,packaging,wrappers: extend D-Bus service activation search path [09:16] I agree [09:16] hence the question whether there's any helpers that can tell us that [09:16] it's not our place to write probably [09:16] mhm, leaving a comment there for jamesh [09:31] mborzecki: if there are better places to do this stuff, I'm open to changing it. But at the moment, that's where similar work is being done. [09:32] pstolowski: you are still working on #8891, right? [09:32] PR #8891: o/servicestate: add updateSnapstateServices helper (5/8) [09:32] pedronis: yes, i'd like to play a bit and refactor this helper [09:33] ok [09:33] jamesh: hi, Jamie asked a question for you here: https://bugs.launchpad.net/snapd/+bug/1881232 [09:33] Bug #1881232: AppArmor blocks ibus input when IBUS_USE_PORTAL=1 [09:34] jamesh: do you recall those other bits that write out system locations were? iirc there's some code for snapd on core and core->snapd remodels doing that [09:35] maybe we should wrap those locations with an if{} too [09:35] mborzecki: it's writing out D-Bus activation files for "snap userd" [09:35] pedronis: looking [09:35] thx [09:35] jamesh: thanks i will take a look, but it soulds like we could address this in a follow up [09:41] brb [09:50] re [09:55] pedronis: responded to the bug report. Looks reasonable to add to the desktop interface (no need for desktop-legacy) [10:01] PR snapd#8898 opened: snapdtool: helper to check whether the current binary is reexeced from a snap [10:02] jamesh: pedronis: ^^ [10:03] pedronis: i've tentatively put the helper in snapdtool [10:03] it's the right place [10:31] PR snapd#8899 opened: tests: add servicestate.Control tests (7/9) [11:35] thunderstorms! [11:35] zyga: yay, like there weren't enough for the last few days [11:35] haha, right? :D [11:36] tropical banana republic of polandia [11:36] hahah [11:48] I need to reboot to fix my system [11:54] really heavy rain now [12:13] * zyga small break for tea [12:30] and larger break for lunch too [12:32] PR snapd#8900 opened: tests: extra worker for google-nested backend to avoid timeout error on uc20 [12:34] cmatsuoka: hi, i looked a bit why the cla check came up with your @gmail.com email address [12:34] mborzecki: yeah, I found the merge node there [12:34] cmatsuoka: it's probably the merge that happens automatically when the branch is not on top of current master [12:35] mborzecki: but this is something that started happening on friday, I wonder if github changed something there [12:35] mborzecki: I worked around it by changing my primary email address in github [12:35] cmatsuoka: hm i could tweak the call to git shortlog -s -e --no-merges, though i'm thinking that there could be a merge that ahs some actual code changes due to conflicts [12:37] mborzecki: the primary address change shouldn't be a problem (and now it will allow me to accept modiciation suggestions in reviews) [12:38] it's interesting however that it never happened before, even in the same PR, and now it happens in all of them [12:38] cmatsuoka: it's becase we landed some tweaks to cla_check [12:38] cmatsuoka: https://github.com/snapcore/snapd/pull/8455 landed on friday [12:38] PR #8455: tests/lib/cla_check: expect explicit commit range [12:40] mborzecki: mm ok, well, it's not causing problems for me anymore but if someone else complains we already know what's causing it and a potential workaround [12:43] cmatsuoka: btw. thhere's a way to select differnt email address on per organization basis, but afaict it only affects notifiactions :/ [12:47] re [12:47] mborzecki: ah interesting, I didn't find that settings on gh [12:48] cmatsuoka: it's in notifications -> custom routing, but apparently does not affect commits [12:48] ah, under notifications, ok, I didn't look there [12:49] cmatsuoka: perhaps you can add your other email address to lp too [12:49] (it's probably more convenient) [12:49] yep, it's already on LP but it seems that I didn't sign the CLA using it [13:35] cachio: when did that problem on centos start appearing? [13:43] last week [13:44] mborzecki, I thought that was going to be fixed with the last update but didn't happen [13:46] mborzecki, we use a base image which is provided by centos cloud project [13:46] last week I updated the image manually [13:46] I can do it again [13:47] and it will start failing on snapd tests so then we can fix snapd tests [13:47] mborzecki, what do you suggest? [13:50] cachio: you can try updating, maybe ausearch will be consistent, but it may as well be a bug in the tool itself [13:50] mborzecki, ok [13:50] I'll manually update again [13:50] mborzecki, thanks [13:51] cachio: it used to show 'no matches' but i don't understand why it's not doing tghat anymore, do you have more of the log, or just the tiny snippet? [13:52] mborzecki, just that [14:07] pedronis: I'm happy to take bug #1881232 off your hands [14:07] Bug #1881232: AppArmor blocks ibus input when IBUS_USE_PORTAL=1 [14:08] jdstrand: thanks [14:08] * jdstrand assigns himself [14:14] zyga: do you recall whether https://github.com/systemd/systemd/issues/12401 was introduced in 242? [14:14] looking [14:15] zyga: the linger workaround [14:15] ah [14:15] hmm hmm hmm [14:15] numbers [14:15] I don't recall for sure, let me look if I left a comment [14:15] zyga: there's a comment indicating when the fix was done [14:16] so you are asking about when the bug was introduced? [14:16] IIRC it was always broken before that :) [14:18] zyga: well, it must have worked before, otherwise they would not keep recommenting loginctl enable-linger in rhbz for rhel8 [14:18] hm must/should [14:18] it may have been fixed in distros [14:18] mborzecki, centos 8 updated [14:18] but if you look, the required line to logind conf was only added in 243 [14:19] it probably worked with some distro config before that but master was broken [14:20] zyga: do you recall which distros were broken? [14:20] all that we tested [14:20] I don't recall this being okay before 243 on any distro [14:20] but I may be wrong [14:21] PR core18#152 closed: Make .disk/info visible on the root partition [14:28] zyga: hmm so the effect was that the director would not be created? [14:28] zyga: i mean /var/lib/systemd/linger ? [14:28] linger wouldn't do anything because logind could not create it [14:29] logind itself worked okay [14:29] just this part was impacted [14:30] zyga: tried centos-8 and fedora-31/32, loginctl enable-linger seems to work fine, /var/lib/systemd/linger is already there even before i run the command, and then it creates the right file underneath [14:30] how about centos-7? [14:31] zyga: we don't do user sessions there anyway [14:31] ah [14:31] right [14:31] zyga: i'll try wrapping that workaround with if ! test -d /var/lib/systemd/linger and see what happens [14:31] sure [15:08] * zyga will resume work later, need a break for painkillers to work again [15:25] zyga: cachio: i've tried a couple of workaroudns for linger, but i need to run some errands now, opened #8901 to see if this one is sufficient [15:25] PR #8901: tests/lib/tools: apply linger workaround when needed [15:26] mborzecki, thanks [15:26] ok [15:26] I'll take a look [15:26] and wth tests.session is formatted with tabs [15:27] i don't think any other scripts use tabs [15:27] PR snapd#8901 opened: tests/lib/tools: apply linger workaround when needed [15:27] anyways, bbl [15:50] Issue pc-amd64-gadget#49 opened: Please provide dual-signed shim for UC20 1.0 [16:25] * cachio lunch [16:52] pedronis: hey, you assigned bug #1884444 to me, but it is working as expected. what did you want me to do with it? [16:52] Bug #1884444: SECURITY ISSUE: Snaps unconfined on CentOS and Fedora === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [18:04] jdstrand: answer with the official stance on that [19:41] tianon: do you know if this is the right docker repo to file an issue for the registry against ? [19:41] https://github.com/docker/distribution/issues/3185 [19:44] ijohnson: for the registry in general, yes, but the specific issue you've filed is an issue with the registry image, which would be https://github.com/docker/distribution-library-image -- see also https://github.com/docker/distribution-library-image/issues/106 and https://github.com/docker/distribution-library-image/issues/107 (https://github.com/docker/distribution-library-image/pull/92) [19:44] PR docker/distribution-library-image#92: Fix security issues: bump alpine to 3.11, remove apache2-utils [19:47] thanks tianon, I think I will close my issue and comment on the existing issues that if htpasswd is meant to not be in the image anymore, they need to adjust the docs too [20:22] roadmr: hey, can you sync 20200622-2009UTC ? [20:23] jdstrand: certainly! [20:23] msalvatore: ^ that has the cvescan override [20:23] roadmr: thanks! [20:26] jdstrand: thanks :) [21:25] cachio: in order to run nested tests via qemu, I need to increase the amount of memory allocated to spread systems otherwise the nested QEMU allocation fails due to not being able to allocate all the memory for the nextedVM [21:26] cachio: , is `memory: 4G` ok, or should I use `memory: 3G`? [21:26] cachio: the other thing I could do is define a qemu-nested which uses `memory: 4G` and leave qemu at `memory: 2G` [21:30] ijohnson, hi [21:30] you are talking about memory of the host vm right? [21:30] cachio: yes [21:30] not the nested vm [21:31] cachio: yes I want to increase the memory of the host VM in the qemu backend [21:31] well, I think 4gb [21:31] and then 2 for the host [21:31] for the nested [21:32] if you run nested suite of snapd then the default size for the nested is PARAM_MEM="-m 4096" [21:32] and the host has 8gb [21:33] so, you will need to update nested.sh to upate that [21:34] cachio: ah I forgot actually that I had already decreased the nested VM memory in my local git tree to 2G, you're right it's 4G, so it would need to be at least 5G in the host [21:35] ijohnson, yes [21:35] 5GB should work [21:35] or more [21:36] cachio: since the current default is 2G, I think increasing to 5G is a bit much and may be unexpected to folks trying to run qemu spread tests locally as they will run out of memory very easily with even 3 spread workers, so I think I will just define a new qemu-nested backend which uses 8G [21:36] ijohnson, yes [21:37] it is easier [21:38] ijohnson, if you need any help I am going to buy some stuff, please leave a note I'll read it once I am back [21:39] cachio: I will open the PR for you to look at, but I will be EOD within the hour, but please take a look tomorrow [21:39] cachio: it's not urgent so it can wait til tomorrow [21:40] ijohnson, sure, I'll take a look once I'm back [21:40] thanks [21:40] np [21:40] * cachio afk [21:51] PR snapcraft#3184 opened: build providers: check revision before switching [22:59] PR snapd#8902 opened: tests: fix assertion disk handling for nested UC systems