[02:23] secretfader: a combination of private snaps on the public store + https://docs.ubuntu.com/snap-store-proxy/en/ for onsite delivery may be able to do what you want [02:25] oh nice [05:16] morning [05:22] PR snapd#8915 closed: gadget: do only one mount point lookup in mounted fs updater [05:22] PR snapd#8921 opened: gadget: fix typo in mounted filesystem updater [05:52] PR snapd#8921 closed: gadget: fix typo in mounted filesystem updater [05:52] yay [05:52] mvo: hey [05:56] mborzecki: good morning [06:02] PR snapd#8911 closed: asserts,seed: split handling of essential/not essential model snaps [06:20] zyga: can I help with 8881 ? looks super close, just reading the reamaining comments [06:27] Good morning. Let me try finishing it. I think today will be smoother than yesterday [06:28] zyga: heya [06:28] Hey :-) [06:32] ok [06:58] morning [07:13] pstolowski: hey [07:14] anyone investigated the random failure in unit tests related to GPG? [07:19] not yet [07:19] settling in for work === pedronis_ is now known as pedronis [07:19] mborzecki: not yet [07:20] mborzecki: can you explain why you think chasing the dm hiearchy is simpler? it sounds like more code, am I wrong? [07:26] pedronis: yes, it may be a bit more code, but upside is the information is coming directly from device hierarchy rather than from a specially formatted name [07:27] pedronis: otoh the name format will remain stable throughout the release as udev/systemd versions are frozen effectively [07:28] mborzecki: less code is more compelling at this point to me, also because is not clear that slaves couldn't have many entries? [07:30] pedronis: it should be one for simple lvm/luks, i can find out about other scenarios [07:31] mborzecki: it's ok, just pointing out that the error cases will also grow [07:31] pedronis: anyways, not a strong opinion, thought it may be worth considering given how easy it is to chase down the device with shell [07:37] PR snapd#8922 opened: tests: fix incorrect check in smoke/remove test [08:24] it's supper annyoing how google meet is hiding the bootom bar with the (un)mute/hangup buttons each time the window goes out of focus [08:25] obviously accompanied by an animation of the bar rolling up and down [08:33] heh, yes [08:47] PR snapd#8922 closed: tests: fix incorrect check in smoke/remove test [08:50] pedronis: left a small question on the assertion sequence PR: https://github.com/snapcore/snapd/pull/8906/files#r445405988 [08:50] PR #8906: asserts: introduce SequenceMemberAfter in the asserts backstores [08:56] zyga: I tried to answer [08:58] thanks, that makes sense [09:15] meh another random test failure https://paste.ubuntu.com/p/Y5G6hx4QG7/ [09:17] zyga: https://github.com/snapcore/snapd/pull/8881/files#r445419656 it's missing a } in the template list [09:17] PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs [09:17] oh, [09:18] looking [09:18] zyga: `AddParametricSnippet([]{"/dev/", "rw," <<>>, "sda1")` [09:18] zyga: and probably []string too [09:19] ah [09:19] I se [09:20] fixed [09:21] zyga: thx :) [09:22] I fixed string as well, just didn't push again [09:31] zyga: what's the state of 7700 ? [09:31] zyga: should this be reviewed by pedronis ? [09:31] looking [09:31] yes, it needs review to establish direction [09:31] zyga: preping for vMontreal I was wondering if we can try a push for refresh awareness again :) [09:31] zyga: cool, I add the tag [09:31] thanks [09:32] zyga: do you have an order in which these should be reviewed? [09:32] zyga: is 7700 the first one we should look at? [09:32] mvo: no, there are two PRs now, that are critical [09:32] this and ... [09:33] https://github.com/snapcore/snapd/pull/8573 [09:33] PR #8573: overlord/snapstate: inhibit startup while unlinked [09:33] though that one was already reviewed and I need to expand it a littie [09:33] *little [09:33] mvo: it was reviewed already :) [09:33] zyga: ok, let's try to move this a bit forward before vMontreal [09:33] apart from that there is https://github.com/snapcore/snapd/pull/8829 [09:33] PR #8829: sandbox/cgroup: add tracking helpers [09:33] that needs a 2nd review and I think is ready to land [09:34] zyga: I do the second review [09:34] zyga: after my current meeting [09:34] and after 8829 lands I can shring https://github.com/snapcore/snapd/pull/7825 once again, it will be closer to something that is reviewable then [09:34] PR #7825: many: use transient scope for tracking apps and hooks

[09:35] thank you! [09:35] mvo: then there is https://github.com/snapcore/snapd/pull/8863 [09:35] PR #8863: sandbox/cgroup: allow discovering PIDs of given snap [09:35] which is the lsat of the group I have now [09:35] it needs two reviews and I also think it is ready [09:36] those two should shrink the main backend PR by quite a bit, perhaps enough for it to be mostly just tests [09:36] there's one more PR that can be broken out but I'm blocked by those two helpers landing first [09:37] man github is slow on large pages :/ [09:37] I mean, my laptop is slow [09:37] I want to be healthy again and use my normal work stuff [09:39] hrm [09:40] go language server is swapping on my system [09:45] disabled go support in code, it's useless at this stage [09:48] mvo: I think https://github.com/snapcore/snapd/pull/8881 is ready now [09:48] PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs [09:49] mvo: I'm open to changing the API again to make it even harder to use incorrectly but I don't consider it blocked anymore [09:51] * zyga small break to change the workspace [09:53] PR snapd#8905 closed: bootloader: introduce managed bootloader, implement for grub [09:53] finally landed, took a bunch of restarts [09:54] now which part should i open next [09:59] mvo: for what it is worth, I think some of the font cache differences come from all the static versions of fc-cache versions being linked against xenial's freetype [10:02] jamesh: thanks, that is good to know, so if we fix that and build with the right freetype it should be better? [10:02] hopefully. I think this is the cause of color emoji compatibility at least [10:02] mvo: I think the private fontconfig cache is probably the best bet going forward though [10:03] jamesh: yeah, I would *love* to remove this from snapd and move it into the snaps [10:11] ls [10:11] ps [10:11] id [10:11] o/ [10:13] bash: o/: No such file or directory [10:14] trying to work from the office [10:14] will see how it goes [10:14] maybe an hour or two a day [10:17] jamesh, mvo, should bug #1858636 be assigned to someone from the snapd team again in regard of the recent findings? ijohnson was assigned but unassigned himself [10:17] Bug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium

[10:23] PR snapd#8923 opened: wrappers: helper for enabling services (8/9) [10:48] PR snapd#8924 opened: gadget, bootloader: preserve managed boot assets during gadget updates [11:02] mborzecki: hi [11:02] question about managed boot assets PR [11:02] zyga: hm? [11:02] should BootAssets return nil if IsCurrentlyManaged returns false? [11:03] I know the usage below is correct [11:03] just asking conceptually [11:04] zyga: no, i'm not sure it's needed, i actually thought about making it part of the Bootloader interface even [11:07] zyga: iow, it answers the question as to where inside the tree can the bootloader assets be located, IsCurrentlyManaged() indicates whether those are really managed [11:08] zyga: updated #8914 per your suggestions, thanks [11:08] PR #8914: o/ifacestate: fix connect undo handler [11:11] pstolowski: looking [11:11] * pstolowski lunch [11:11] pstolowski: one more question there [11:12] in the beginning of the diff [11:12] is there any risk that "old" stores more than the undesired flag? [11:13] perhaps we should do something like task.Set("old-conn", ConnectionState{Undesired: old.Undesired}) [11:13] (I forgot the type names so forgive me for making the name up [11:15] pstolowski: not sure if you see what I'm worried about [11:42] * zyga breaks to wait for meds to help [11:42] please review https://github.com/snapcore/snapd/pull/8881 [11:42] PR #8881: interfaces: optimize rules of multiple connected iio/i2c/spi plugs [11:48] it'd be nic to have auto cancel of runs when a PR gets updated [11:48] s/nic/nice/ [11:48] PR snapd#8925 opened: bootloader: allow managed bootloader to update its boot config [12:06] re [12:24] * zyga feels better [12:31] zyga: great to hear that! [12:31] temporary but yeah [12:31] ijohnson: hey, can you take a look at #8899 (i think you assigned it to yourself anyway)? [12:31] PR #8899: tests: add servicestate.Control tests (7/9) [12:41] Hey pstolowski yes it's in my queue, I started yesterday but got distracted; should finish this morning [12:41] ijohnson: sure, thanks [13:31] ijohnson: about ram, try the code snap and open snapd there [13:31] install the go extension it recommends [13:31] and observe ram usage [13:31] the official go language server immediately eats 4+GB [13:31] after indexing snapd [13:32] zyga: I did, I filed an issue about strict and classic snaps being confused about each other, so I don't use the code snap any more :-/ [13:32] I had to close the editor to join the hangout [13:32] cause the code snap can't use the go snap [13:32] I see [13:32] I think it's pretty nice overall (code itself) [13:32] but I do remember trying the language server and it has some weirdness I don't remember so I turned it off [13:33] but I'm quite happy with vs code, I would love to use the snap when we can fix that bug [13:33] yeah but the features are really great [13:33] have you used the remote sharing feature yet? [13:33] no? [13:33] pstolowski: I don't think I need to review that tests PR [13:33] it's quite nice actually, we used it a bit at the virtual snapcraft summit [13:33] ah live share is the name of it [13:33] https://code.visualstudio.com/blogs/2017/11/15/live-share [13:33] is it like something that atom had a while ago [13:33] pedronis: ok, i thought so, thanks [13:33] where >1 people can code in one workspace [13:34] really nice [13:34] we should try that [13:34] zyga: yeah sounds like it, I've never used atom though [13:34] maybe next week? [13:34] yeah we could try doing some kind of pair coding session I know we talked about trying that out all the way back in paris iirc haha [13:41] yeah [13:41] we'll always have paris 💛 [13:43] * zyga makes coffee [13:44] PR snapd#8881 closed: interfaces: optimize rules of multiple connected iio/i2c/spi plugs [13:49] when snap run runs a hook (as root ofc), should we really try to create /roon/snap// ? [13:49] we don't expect hooks to try to manipulate home [13:50] mborzecki: probably not. this happens in snap-run? [13:50] pstolowski: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1884929 [13:50] Bug #1884929: snap creates (or tries to create) a direcotry in /root/snap/

[13:50] it's running a configure hook [13:57] hmm, there's a bunch of things that happen but maybe shouldn't be when we run --hook, it's creating $HOME/snap, migrating Xauthority and activating a document portal [14:07] mborzecki: it probably makes sense to do only a subset of that for hooks [14:07] mborzecki: not sure about $HOME/snap (maybe it should be crated), it's also related to what is exposed via SNAP_* env vars [14:12] pstolowski: still the hook runs as root, not sure why there would bea need to store anything inside /root instead of /var/snap/ [14:18] mborzecki: they shouldn't, worried about silly hooks though [14:29] PR snapd#8926 opened: Add microstack-support interface [14:29] oh, i think undo of snap connect has yet another bug /o\, it doesn't restore security profiles. it's only a problem with undo of individual snap connect, and not when run as part of a install/refresh change [14:31] i wonder how/when did this sneak it. probably at the time undo handlers were re-arranged [14:59] PR snapd#8927 opened: tests: avoid exit 1 when nested type var is not defined [15:09] * cachio lunch [15:14] ijohnson: I think we should try to land #8683 with the current approach, https://github.com/snapcore/snapd/pull/8683#discussion_r445635143 [15:14] PR #8683: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices [15:15] pedronis: ok, I have not yet had a chance to explore mborzecki's recommendation but it seems that it would be more code [15:19] ijohnson: I mean, if we are really paranoid about udev then we shouldn't use udevadm at all, but I don't think we are there yet [15:19] sure, I mean the udev that's there right now seems to be good enough, so I'm fine to keep using it until we have reason to want to rip it out [15:19] yes [15:24] mvo: thank you for merging 8881 [15:24] mvo: I will open some follow-ups for it [15:30] zyga: sounds good [15:34] pstolowski: I reviewed #8914, lgtm [15:34] PR #8914: o/ifacestate: fix connect undo handler [15:35] pedronis: ty [15:35] pstolowski: you said there's more to fix though? [15:36] pedronis: yes, i'm afraid so, but it can be a followup. we're missing m.setupSecurityProfiles on undo [15:36] pstolowski: only if it's not an auto-connect one? [15:36] I mean only if we did setup profiles [15:36] right? [15:40] pedronis: doConnect sets up security profiles (unless delayed-setup-profiles is set). but undo doesn't do this at all. this affects manual 'snap connect ..' if you have a hook that fails after connect [15:41] pstolowski: I mean it matters only if !delayedSetupProfiles or what should happen in that case? [15:43] pedronis: we should do repo.Disconnect and then m.setupSnapSecurity like we do on connect, [15:44] only if !delayedSetupProfiles ? [15:46] pedronis: yes [15:46] ok, thx [15:46] pedronis: for delayedSP==true it's a different case (refresh, instal) where everything is undone and initial setup-profiles should do the right thing [15:49] pedronis: btw, with a disconnect hook that fails it is impossible (not really a surprise) to uninstall affected snap [15:50] a flag for such cases would be handy [15:59] it could set IgnoreError=true on all hooks [15:59] pstolowski: snap remove --force [15:59] ? [16:00] yep [16:00] mvo: any chance for a review of https://github.com/snapcore/snapd/pull/8829 [16:00] PR #8829: sandbox/cgroup: add tracking helpers [16:00] mborzecki: not sure if you have time today but a look at https://github.com/snapcore/snapd/pull/8863 would be great [16:00] PR #8863: sandbox/cgroup: allow discovering PIDs of given snap [16:00] with those two I can make progress on r-a-a [16:00] zyga: having fun with freetype now, but let me try [16:00] mvo: it's not much code, just a pair of functions [16:04] zyga: I will try to review that in my PM if mvo does not finish [16:05] thank you so much! [16:05] zyga: I've been waiting for nested spread runs to finish, so it's easy for me to do reviews while waiting for results :-) [16:06] :) [16:06] cachio: so I finally got around to try and reproduce your uc20-recovery test and it finished fine for me, I ran it with `spread --debug -v google:ubuntu-core-20-64:tests/core/uc20-recovery`, is that the right test you said was failing ? [16:08] cmatsuoka: I looked at #8824 [16:08] PR #8824: many: move encryption and installer from snap-boostrap to gadget [16:09] pedronis: thanks, I'll check [16:09] PR snapd#8914 closed: o/ifacestate: fix connect undo handler [16:20] Is there a way for a user to alter the layout after installing a snap? For example, the app I'm snapping produces datafiles as output. Our classic install dumps this data /var/log/.. Could they redirect it there if they choose to? By default it happily logs to a confined space I've mapped with a layout. [16:20] ish: users cannot alter the layout [16:21] Ok. Thats what I thought. Was hoping for some command that I couldn't find to "connect" directories together. [16:26] zyga: fwiw, I pushed https://github.com/snapcore/fc-cache-static-builder/pull/2 - will have dinner now so let's hope ijohnson can review, otherwise I do it in my morning [16:26] PR fc-cache-static-builder#2: build freetype from the security pocket too [16:27] mvo: ack [16:28] uh, 5% battery left [16:30] brb [16:31] plugged in [16:42] hmm [16:42] Variable NESTED_TYPE not defined. Exiting... [16:43] on tests/main/lxd-no-fuse on 18.04 [16:58] ah [16:58] * zyga fixed the problem [17:02] zyga, there is a PR for that [17:02] yeah, I know, different problem [17:03] zyga, nice [17:03] it was just a message that confused me [17:03] cachio: updated https://github.com/snapcore/snapd/pull/8728 [17:03] PR #8728: tests: detect stray dbus-daemon [17:04] ijohnson, yes [17:04] ijohnson, but it is not failing in google [17:04] cachio: do you think I should just run that test in a loop ? [17:04] it fails with edge image [17:04] using external backedn [17:04] cachio: ah right now you said it was with external [17:04] cachio: ok, can you remind me which external image I need to use? [17:04] * zyga returns to bed [17:05] ijohnson, yes, 1 sec [17:05] (it was great to work from office again today) [17:05] zyga: glad to hear you are feeling better today :-) [17:05] zyga, happy to hear that [17:05] little by little :) [17:06] ijohnson, https://storage.googleapis.com/spread-snapd-tests/images/pc-amd64-20-edge-snapd_edge/pc.img.xz [17:07] ijohnson, I am testing now the beta image [17:07] cachio: thanks, so I just run that via qemu on my local machine, then how do I point spread to use that as the external image ? [17:07] err external backend [17:07] do I need to change some IP address or set some env var ? [17:07] ijohnson, then you do [17:07] export SPREAD_EXTERNAL_ADDRESS=localhost:8022 [17:08] ./tests/lib/external/prepare-ssh.sh localhost 8022 sergio-j-cazzolato [17:08] with you lp id [17:08] ijohnson, and spread -debug external:ubuntu-core-20-64:tests/core/uc20-recovery [17:08] that should be enough [17:12] cachio: ack will give it a try === ijohnson is now known as ijohnson|lunch [17:12] ijohnson|lunch, tx === benfrancis2 is now known as benfrancis [17:19] PR snapd#8824 closed: many: move encryption and installer from snap-boostrap to gadget === ijohnson|lunch is now known as ijohnson === benfrancis2 is now known as benfrancis [17:32] hey, zyga, not sure you are there... but is the merge of master ok. (just for speed...) Or should i look for an error? I'm just past the age of 40' ;-) ... maybe i'm different, ... [17:33]