[00:59] PR snapcraft#2984 opened: plugins: move the existing plugin to a new package [06:48] morning [06:52] Uh [06:52] Morning [06:52] I’m so tired today [06:53] Too much work yesterday [06:53] Is mvo around? [06:54] zyga: hey [06:54] zyga: he doesn't seem to be online yet [07:49] mvo: hi, #8278 can be merged if you are ok with my last bit of changes [07:49] PR #8278: devicestate: disable cloud-init by default on uc20 [07:57] pedronis: let me check, I just summarzied the core refresh issue but that's summarized now, still in the dark about it [07:58] pedronis: how are tests looking? lots of red yesterday I noticed [07:58] mvo: snapd-failover still fails sometimes, Ian knows [07:58] mvo: other tests are flaky as well, the cgroup named one fails sometimes [07:58] pedronis: meh, that one is really a tough one [07:58] * mvo nods [07:59] pedronis: I go over the prs and see if there is anything I can do [08:00] mvo: there are some uc20 that need 2nd reviews, I need to re-review some as well [08:02] mvo: zyga left a comment in #8295 about 14.04 [08:02] PR #8295: osutil: do not leave processes behind after the test run [08:03] mvo: there might be 2.44 things to backport for .1 ? [08:04] I mean things landed on master [08:04] morning [08:05] pedronis: yeah, checking that too, thank you [08:05] pstolowski: good morning [08:26] hm,snap-confine-undesired-mode-group seems to fail fairly often, should we disable it until we have a fix? [08:28] PR snapd#8292 closed: travis.yml: run unit tests on master as well [08:30] PR snapd#8291 closed: packaging,tests: ensure debian-sid builds without vendor/ [08:30] mvo: it does [08:31] PR snapd#8290 closed: run-checks: tweak formatting checks [08:31] pedronis: hi, re search v2 pr & 400s, i think they were temporary (proxies catching up with latest fix?), i think i saw them before when working on this after Tony deployed new fix. i've re-run two of the failing tests a moment ago and they passed. just kicked travis on that PR again, let's see how it goes today [08:32] PR snapd#8278 closed: devicestate: disable cloud-init by default on uc20 [08:34] pstolowski: ok, please also sync with him because I think they are discusing s/search/find/ in the endpoint [08:35] as well [08:35] yes i saw the email [08:40] mborzecki: hi, can you look at #8159 again, I don't think it's doing what we discussed, but maybe I'm confused [08:40] PR #8159: snap-bootstrap: remove created partitions on reinstall [08:53] zyga, hi, do you need any other info WRT #1841137 ? [08:53] Bug #1841137: /dev/loopX devices left around for removed snap revisions [08:59] pedronis: yeah, tweaking it a bit already, idk but sfdisk manpage is super confusing abut the attrs format [09:00] at least the way it's printed seems stable, even if not 'well defined' [09:00] mborzecki: ok, if you are working on it, let's drop forcing the luks type (I think overriding the gadget content without thinking it through is risky/unexpected) [09:00] this was discussed already anyway yesterday [09:01] ackk: hey [09:01] * zyga is so tired today [09:01] mvo: about that issue affecting that customer device [09:01] mvo: I was wondering [09:02] is it the only one that crashes? [09:02] or is it affecting other identical devices [09:02] mvo: please don't disable it, I'll filter out files that are not made by this test from it [09:03] mvo: it really shows we leak cgroups/sessions across tests [09:03] mvo: not that the test is broken per se [09:03] zyga: in a meeting, will get back to you [09:04] zyga: multiple identically devices are not refreshig (3/3) [09:04] mvo: in that case it's a real bug :| [09:31] PR snapd#8298 opened: many: enumerate system seeds, return them on the /v2/systems API endpoint [09:31] pedronis: mvo: ^^ [09:32] mborzecki: thanks, in a meeting right now [09:32] zyga, fwiw it seems the snap-discard-ns trick doesn't always work before removing the snap. I had to run it multiple times [09:37] zyga, also: https://paste.ubuntu.com/p/dcwFrV6yxp/ (the script does a bunch of snap connect) [09:46] ackk: oh? [09:46] ackk: I'm in a call [09:47] sorry [09:54] uh [09:54] 360 reviews are due today [10:03] zyga: they were due, the window is closed [10:03] yeah, I noticed now :/ [10:03] oh bummer [10:07] mvo: I'm connected to Tw VPN [10:30] PR snapd#8286 closed: tests: cleanup various uc20 boot tests from previous PR [10:43] PR snapd#8293 closed: packaging: add README.source for debian [10:47] brb [10:56] mvo: an idea to play with in https://github.com/snapcore/snapd/pull/8295#discussion_r394941827 [10:56] PR #8295: osutil: do not leave processes behind after the test run [10:56] mvo: seems to work locally here [10:58] mborzecki: nice one, do you think that's easier/more reliable? I have no strong opinion either way [10:58] mvo: we could turn it into a cleanup helper and reuse ;) [11:02] mborzecki: sure, works for me [11:03] mvo: hmm still, it's not enough for mocks, we should probably track the main pid in the template [11:05] mborzecki: yeah, let's not spend too much time on this until we have more time (unless it's quick :) we have some bigger fish to fry right now [11:05] mvo: otoh, when we exec.Command(), we ought to take care of the child process too and kill the whole group [11:05] mborzecki: (if you have something relatively quick and clean, by all means, that's fine of course, use your judgement) [11:05] zyga, fwiw I'm getting that "read only" error even in a VM (so no snapfuse) [11:05] mborzecki: indeed [11:07] PR snapd#8299 opened: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous [11:09] mvo: oh, and we even have a osutil.KillProcessGroup helper ;) [11:14] zyga, n/m, I didn't have robust namespace on [11:14] :) [11:19] mvo: wdyt about this: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/process-fun-fun ? [11:27] mborzecki: +1 [11:27] mborzecki: that looks pretty neat [11:30] mborzecki: looks like the exit 1 on gofmt makes a bunch of stuff red [11:30] mvo: which PR? [11:31] mborzecki: the most recent two ones, mine and yours [11:31] hmm wth is the diff output trimmed? [11:34] mvo: ehh https://github.com/snapcore/snapd/pull/8300 [11:34] PR #8300: boot: apply Go 1.10 formatting [11:34] PR snapd#8300 opened: boot: apply Go 1.10 formatting [11:35] at least we can skip spread now ;) [11:39] mborzecki: indeed, thanks for that! [11:44] uhh [12:00] #8300 is green [12:00] PR #8300: boot: apply Go 1.10 formatting [12:02] PR snapd#8269 closed: apparmor: use rw for uuidd request to default and remove from elsewhere [12:04] mvo: restarted #8251, would be nice to land it after it gets 2nd review [12:04] PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks [12:10] pstolowski: yeah, thank you! [12:16] PR snapd#8300 closed: boot: apply Go 1.10 formatting [12:17] zyga: do we have any plan to move https://github.com/snapcore/snapd/pull/7205 forward? should we close it and re-open when needed? [12:17] PR #7205: rfc: introduce confinement options failsafe flag [12:18] I think the plan is to emit warnings indeed [12:29] pstolowski: thanks for the review of 8277 , I haven't yet looked at why/which of the spread tests fail [12:30] sure [12:30] pedronis: btw #8283 has a conflict [12:30] PR #8283: overlord,timings,daemon: separate timings from overlord/state [12:31] fun, not [12:31] anyway I'll look when it gets a 2nd review [12:31] thanks for noticing it though [12:33] PR snapd#8191 closed: [RFC] cmd/snap-recovery-chooser: add a recovery chooser <⛔ Blocked> [12:42] morning folks [12:44] good morning ijohnson [12:44] hey cmatsuoka [12:46] hi ijohnson [12:47] o/ pstolowski [12:47] and hi cmatsuoka ! [12:47] #8251 needs 2nd review (and is super simple) [12:47] PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks [13:13] PR snapcraft#2985 opened: static: ignore direnv created artifacts [13:16] pstolowski: I did another pass on search v2, looking good, still some comments/questions though [13:17] pedronis: thanks [13:17] pstolowski: also seems they are going ahead with /find, sync with Tony about timeline for that [13:17] we'll have to bump the version check as well [13:19] mvo: hey, are you still collecting PRs for 2.44 or is it baked? [13:27] jdstrand: 2.44 itself is kind of baked, but we'll do a .1 very likely [13:28] jdstrand: OTOH we are looking only for really neccesary or low risk even for .1 [13:28] mborzecki: I reviewed #8298, thank you [13:28] PR #8298: many: enumerate system seeds, return them on the /v2/systems API endpoint [13:28] pedronis: thanks! [13:31] pedronis: I may have something that meets that criteria to address an issue in the firefox snap that kenvandine and jamesh highlighted elsewhere [13:41] cmatsuoka: I re-reviewed #8159 [13:41] PR #8159: snap-bootstrap: remove created partitions on reinstall [13:41] pedronis: thanks, re-checking it... [13:56] jdstrand: still collecting for a 2.44.1 that will happen [13:56] mvo: ok, don't wait on me. if I get you something fine, if not, also fine :) [13:56] mvo: thanks! [13:57] jdstrand: yeah, 2.44 is out but we already know we will do a point release with some tweaks we want to have in 20.04-final [14:14] kenvandine: hey, can you read and comment on my assessment in https://bugs.launchpad.net/snapd/+bug/1868051 ? [14:14] Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications [14:34] PR snapcraft#2986 opened: packaging: use find_namespace_packages in setup.py [14:34] kenvandine: to be clear, I'd like your (or jamesh) feedback in a bug comment in bug #1868051 before I do anything [14:34] Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications [14:39] jdstrand: thanks! [14:40] jamesh: can you please comment on that? [15:02] jdstrand: another issue is what to do when firefox wants to open a file rather than download it [15:02] right now that goes in TMPDIR [15:02] which of course apps do not have access too [15:05] kenvandine: I think you mean that the file goes in firefox's /tmp but the other app isn't able to open it because either a) firefox says it is in /tmp when it is actually in /tmp/snap.firefox and b) the permissions on /tmp/snap.firefox are such that non-root can't access it [15:05] kenvandine: IME, firefox plugs 'home'. patch it to default to ~/Downloads instead [15:06] kenvandine: there is another option using the content interface to export 1777 $SNAP_COMMON/tmp or similar, but then other snaps need to know to plugs it so not really scalable [15:07] yeah [15:07] jdstrand: i've played with setting TMPDIR and have proven it works [15:07] but, $HOME/Downloads has a couple issues [15:08] $HOME isn't $REALHOME in the snap [15:08] and [15:08] ~/Downloads could be translated [15:08] kenvandine: other options are what were discussed before, a special way to opt out of per-snap tmp. this needs design and snapd changes. that also doesn't work for other snaps since we actually want per-snap /tmp and they wouldn't be able to access host /tmp [15:09] I guess I could add a script to the command-chain to get $REALHOME and the translated Downloads dir [15:09] just worry about that being fragile [15:09] kenvandine: well, yes, of course you would have to do reall hame (getent passwd $(id -u) | cut -f 6 -d ':') [15:09] real home* [15:10] kenvandine: and the snap would be free to use a translated Downloads [15:10] yeah, that's well known. just need a script to set that. can't do it in the yaml [15:10] i'd need to shell out to xdg to get the translated Downloads [15:10] should work fine... but i worry about corner cases :) [15:11] kenvandine: iirc, you only need to do this once since firefox remembers the last one [15:11] kenvandine: I know that is true for when downloading a file [15:11] kenvandine: it might not be for /tmp itself [15:11] kenvandine: but, it could be adjusted to follow the download location [15:12] kenvandine: perhaps it honors TMPDIR? [15:12] it does [15:12] so i just need to set TMPDIR in the snap [15:13] kenvandine: in which case, on snap startup you could in a wrapper, calculate realhome, calculate the translated dir name and then set TMPDIR before firefox starts [15:13] i'm just thinking through what i want to set that too before submitting a patch to mozilla [15:14] kenvandine: maybe you want to set it to realhome/Downloads/firefox.tmp. [15:15] kenvandine: in this manner, actually temp files don't clutter Downloads and if things don't get cleaned up like they should, someone can clean it out [15:15] actual* [15:15] i like that idea [15:15] kenvandine: or even .firefox.tmp [15:16] kenvandine: firefox itself (or the wrapper), could clean up things, deleting stuff older than say, a week [15:16] (be careful doing that, don't follow symlinks!!) [15:18] kenvandine: basically, there is no clear way to make /tmp work that works will with other snaps too (not without some rather deep and/or super magical integration with snapd), but home is shared by most everything that would open a file in this manner [15:18] man typos [15:18] works well* [15:18] :) [15:19] jdstrand: ok, thanks for the feedback. i'll continue with my original plan [15:19] but add firefox.tmp to it [15:19] np [15:23] kenvandine: fyi, from with snap run --shell firefox: [15:23] $ xdg-user-dir DOWNLOAD [15:23] /home/jamie/Downloads [15:23] yeah [15:23] so you don't need the getent at all [15:24] # Set TMPDIR to be under the user's default Downloads dir [15:24] export TMPDIR=$(xdg-user-dir DOWNLOAD)/firefox.tmp [15:24] handy [15:24] and i'll add that to command-chain after desktop-launch to ensure xdg user dirs are all setup [15:26] kenvandine: you probably know this, but xdg-user-dir just looks at ~/.config/user-dirs.dirs whish in the case of firefox is $SNAP_USER_DATA/.config/user-dirs.dirs [15:27] jdstrand: yeah, desktop-launch does some stuff to ensure those are set properly [15:27] kenvandine: I guess so long as that user-dirs.dirs is setup right, you're good [15:27] cool [15:28] kenvandine: this should really help. the wrapper may want to mkdir that directory. it is too bad that the snap probably needs to keep it clean, but hey, not a terrible solution to the problem overall [15:29] pedronis: hey, do you have a moment for HO? [15:29] firefox does create it if it doesn't exist [15:32] pstolowski: yes [15:33] pedronis: joining standup HO [15:41] jdstrand, hi [15:42] jdstrand, what about a meeting about the interface for the new CUPS Snap? [15:54] ijohnson, any insight into how to make https://forum.snapcraft.io/t/no-interfaces-without-core-snap a better experience? [15:54] It's an unfortunate situation [15:58] kyrofa: upgrade snapd everywhere ? [15:59] kyrofa: the issue is that its a bug we have solved everywhere in new snapd, and devices keep hitting the bug because there seems to be old snaps in many places [15:59] ijohnson, that's not a solution I'm afraid [15:59] ijohnson, not one that scales [16:00] ijohnson, the problem is that it's standard practice to only install security updates in prod [16:00] I mean whatever solution I can come up with involves changes to snapd, which only happens if you get an upgraded snapd ... hence the problem [16:00] perhaps others have thoughts, but I don't know how we can make old snapd's change behavior without updating old snapd [16:01] ijohnson, we have abused the security component in the past, is that an option? [16:01] kyrofa: you mean push an update to -security ? [16:01] Indeed [16:01] yeah that doesn't sound like a bad idea to me, I think there is some precedent for that, we have done that to solve this exact problem on trusty for example [16:02] that would be a mvo request though [16:02] Exactly my thinking. Not pretty, not ideal, but not unprecedented [16:02] yep [16:02] mvo, you should consider that as core18 becomes the standard [16:03] ijohnson, mvo, I'll add a comment about this to the forum post [16:04] kyrofa: thanks [16:06] kyrofa: we do need the agreement of the security team to do that [16:08] pedronis: --mask/unmask work with --root 👍 [16:08] pstolowski: good [16:16] tkamppeter: hey, I saw the discussions. can you put something in the calendar for sometime next week? Tue, Wed or Thu is best for me [16:17] tkamppeter: I've been wanting to review all the discussions again (I've read them) and think through everything in preparation for the meeting [16:19] ijohnson, around? [16:20] tkamppeter: yes [16:20] Next week is fine for me [16:20] tkamppeter Please include pedronis in the meeting though [16:20] I will not be available Thu or Fri [16:22] OK, should we do wed, 25, at 3pm UTC? [16:22] jdstrand, ijohnson, pedronis, me, someone else? [16:23] Or better mon, 23, at 3pm UTC? [16:23] tkamppeter: I don't think we need anyone else in the meeting, and 3 pm UTC works for me, but I prefer Wed instead of Mon [16:24] So let us do Wed then. [16:30] jdstrand, ijohnson, pedronis: Done. You should have gotten an invitation. [16:31] got it, thanks tkamppeter [16:31] kyrofa: sorry, lacking context [16:31] kyrofa: can you give me a tl;dr [16:33] * cachio lunch [16:33] mvo, quick read: https://forum.snapcraft.io/t/no-interfaces-without-core-snap . tl;dr if you have a bionic install with a snapd that hasn't been updated, you can't install a core18 snap [16:33] tkamppeter: you didn't check for meeting conflicts :( [16:34] At least, not without also manually installing the core snap or manually updating snapd first so it installs the snapd snap [16:34] jdstrand, so I hit another meeting of yours? I will go through all three where I find a slot. [16:34] tkamppeter: that is in conflict for me. all day tuesday is open for me, and most of thursday. wednesday my morning has a conflict [16:34] tk thanks [16:34] tkamppeter: thanks :) [16:35] * jdstrand lunch [16:36] jdstrand, pedronis, ijohnson: How do I check the participant's meeting schedules? [16:36] ijohnson, pedronis, what do you prefer? Tue, or Thu? [16:37] Thu I'm off [16:37] So Tue is left, ijohnson, does it work for you? [16:39] tuesday, again, is good for me at around the same time up to two hours earlier or 6 hours later [16:40] tkamppeter: (to answer your question, I temporarily add people to Other calendars to see if there is a conflict. there might be a better way) [16:40] kyrofa: yes, that's correct, we fixed this a while ago but not everybody got the fix :( [16:40] ok, really going to lunch now [16:40] mvo, right, exactly [16:41] kyrofa: it's a good question what we can do, we could (ab)use the security pocket so that people get the update via unattended-upgrades but it's a bit borderline [16:41] So let me do a time guess which should hit a slot on all of you: Tue, 24, 1pm UTC [16:41] tkamppeter: sorry I was away [16:42] ijohnson, jdstrand, pedronis: Is Tue, 24, 1pm UTC OK for all of you? [16:42] tkamppeter: yes that's fine for me [16:42] mvo, indeed. Is there any other option? [16:43] tkamppeter: yes [16:43] pedronis? [16:44] tkamppeter: doesn't work for me, but maybe you should have a first meeting just with ijohnson and jdstrand and see how far you get [16:44] kyrofa: we could grow something in the wrapper/command-chain that detect snap versions older than the fixed one (2.41? need to check changelog) and warn but that won't work so well for gui apps and is also not a amazing UX [16:45] pedronis, do you have another slot, which could hit a free slot of jdstrand? [16:46] mvo, wouldn't that also be a snapd update, though? [16:46] Tue 3p pm UTC [16:46] PR snapcraft#2985 closed: static: ignore direnv created artifacts [16:46] tkamppeter: I looked at everybody's calendars and propsoed a time which should work for everybody [16:47] mvo, or is that something you can put in core18? [16:47] tkamppeter: pedronis ah I think I proposed the same time that pedronis said [16:47] ijohnson, which one is that time? [16:47] it's 10 am cst, I don't know what UTC time it is [16:48] ijohnson, could you create a meeting at that hour, and invite me, so I will see where it falls. [16:48] tkamppeter: if you check your email you should get an email with the proposed time [16:48] kyrofa: a warning from the installed snap would be on the snap side, i.e. when you install snap foo and run "foo.bar" it would detect in the wrapper/command-chain. but it's not a great experience, I'm not really advocating it, just trying to come up with ideas [16:49] kyrofa: oh, maybe we could put "assumes: [snapd2.41]" into core18 [16:49] kyrofa: I wonder if that would work [16:49] ijohnson, nothing appeared yet. [16:49] mvo, ah, which implies a snapcraft change, and an assumption that the snap being installed was built recently [16:50] mvo, the assumes would just prevent install, right? [16:50] kyrofa: correct, not a great option [16:50] But at least it TELLS them something [16:50] kyrofa: it would but with a somewhat useful message [16:50] Indeed [16:50] kyrofa: it might be worth a shot [16:50] Right now it's just broken, and the user is left holding the pieces wondering what to do [16:50] sergiusens, you around? [16:51] kyrofa: exactly, we would have to test it, not sure how exactly the UX looks like but I think it's probably better than what we do right now [16:51]