| mup | PR snapcraft#2984 opened: plugins: move the existing plugin to a new package <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2984> | 00:59 |
|---|---|---|
| mborzecki | morning | 06:48 |
| zyga | Uh | 06:52 |
| zyga | Morning | 06:52 |
| zyga | Iām so tired today | 06:52 |
| zyga | Too much work yesterday | 06:53 |
| zyga | Is mvo around? | 06:53 |
| mborzecki | zyga: hey | 06:54 |
| mborzecki | zyga: he doesn't seem to be online yet | 06:54 |
| pedronis | mvo: hi, #8278 can be merged if you are ok with my last bit of changes | 07:49 |
| mup | PR #8278: devicestate: disable cloud-init by default on uc20 <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8278> | 07:49 |
| mvo | pedronis: let me check, I just summarzied the core refresh issue but that's summarized now, still in the dark about it | 07:57 |
| mvo | pedronis: how are tests looking? lots of red yesterday I noticed | 07:58 |
| pedronis | mvo: snapd-failover still fails sometimes, Ian knows | 07:58 |
| pedronis | mvo: other tests are flaky as well, the cgroup named one fails sometimes | 07:58 |
| mvo | pedronis: meh, that one is really a tough one | 07:58 |
| * mvo nods | 07:58 | |
| mvo | pedronis: I go over the prs and see if there is anything I can do | 07:59 |
| pedronis | mvo: there are some uc20 that need 2nd reviews, I need to re-review some as well | 08:00 |
| pedronis | mvo: zyga left a comment in #8295 about 14.04 | 08:02 |
| mup | PR #8295: osutil: do not leave processes behind after the test run <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295> | 08:02 |
| pedronis | mvo: there might be 2.44 things to backport for .1 ? | 08:03 |
| pedronis | I mean things landed on master | 08:04 |
| pstolowski | morning | 08:04 |
| mvo | pedronis: yeah, checking that too, thank you | 08:05 |
| mvo | pstolowski: good morning | 08:05 |
| mvo | hm,snap-confine-undesired-mode-group seems to fail fairly often, should we disable it until we have a fix? | 08:26 |
| mup | PR snapd#8292 closed: travis.yml: run unit tests on master as well <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8292> | 08:28 |
| mup | PR snapd#8291 closed: packaging,tests: ensure debian-sid builds without vendor/ <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8291> | 08:30 |
| pedronis | mvo: it does | 08:30 |
| mup | PR snapd#8290 closed: run-checks: tweak formatting checks <Simple š> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8290> | 08:31 |
| pstolowski | 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:31 |
| mup | PR snapd#8278 closed: devicestate: disable cloud-init by default on uc20 <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8278> | 08:32 |
| pedronis | pstolowski: ok, please also sync with him because I think they are discusing s/search/find/ in the endpoint | 08:34 |
| pedronis | as well | 08:35 |
| pstolowski | yes i saw the email | 08:35 |
| pedronis | 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 |
| mup | PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159> | 08:40 |
| ackk | zyga, hi, do you need any other info WRT #1841137 ? | 08:53 |
| mup | Bug #1841137: /dev/loopX devices left around for removed snap revisions <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1841137> | 08:53 |
| mborzecki | pedronis: yeah, tweaking it a bit already, idk but sfdisk manpage is super confusing abut the attrs format | 08:59 |
| mborzecki | at least the way it's printed seems stable, even if not 'well defined' | 09:00 |
| pedronis | 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 |
| pedronis | this was discussed already anyway yesterday | 09:00 |
| zyga | ackk: hey | 09:01 |
| * zyga is so tired today | 09:01 | |
| zyga | mvo: about that issue affecting that customer device | 09:01 |
| zyga | mvo: I was wondering | 09:01 |
| zyga | is it the only one that crashes? | 09:02 |
| zyga | or is it affecting other identical devices | 09:02 |
| zyga | mvo: please don't disable it, I'll filter out files that are not made by this test from it | 09:02 |
| zyga | mvo: it really shows we leak cgroups/sessions across tests | 09:03 |
| zyga | mvo: not that the test is broken per se | 09:03 |
| mvo | zyga: in a meeting, will get back to you | 09:03 |
| mvo | zyga: multiple identically devices are not refreshig (3/3) | 09:04 |
| zyga | mvo: in that case it's a real bug :| | 09:04 |
| mup | PR snapd#8298 opened: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8298> | 09:31 |
| mborzecki | pedronis: mvo: ^^ | 09:31 |
| mvo | mborzecki: thanks, in a meeting right now | 09:32 |
| ackk | 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:32 |
| ackk | zyga, also: https://paste.ubuntu.com/p/dcwFrV6yxp/ (the script does a bunch of snap connect) | 09:37 |
| zyga | ackk: oh? | 09:46 |
| zyga | ackk: I'm in a call | 09:46 |
| ackk | sorry | 09:47 |
| zyga | uh | 09:54 |
| zyga | 360 reviews are due today | 09:54 |
| pedronis | zyga: they were due, the window is closed | 10:03 |
| zyga | yeah, I noticed now :/ | 10:03 |
| zyga | oh bummer | 10:03 |
| zyga | mvo: I'm connected to Tw VPN | 10:07 |
| mup | PR snapd#8286 closed: tests: cleanup various uc20 boot tests from previous PR <Test Robustness> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8286> | 10:30 |
| mup | PR snapd#8293 closed: packaging: add README.source for debian <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8293> | 10:43 |
| zyga | brb | 10:47 |
| mborzecki | mvo: an idea to play with in https://github.com/snapcore/snapd/pull/8295#discussion_r394941827 | 10:56 |
| mup | PR #8295: osutil: do not leave processes behind after the test run <Created by mvo5> <https://github.com/snapcore/snapd/pull/8295> | 10:56 |
| mborzecki | mvo: seems to work locally here | 10:56 |
| mvo | mborzecki: nice one, do you think that's easier/more reliable? I have no strong opinion either way | 10:58 |
| mborzecki | mvo: we could turn it into a cleanup helper and reuse ;) | 10:58 |
| mvo | mborzecki: sure, works for me | 11:02 |
| mborzecki | mvo: hmm still, it's not enough for mocks, we should probably track the main pid in the template | 11:03 |
| mvo | 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 |
| mborzecki | mvo: otoh, when we exec.Command(), we ought to take care of the child process too and kill the whole group | 11:05 |
| mvo | mborzecki: (if you have something relatively quick and clean, by all means, that's fine of course, use your judgement) | 11:05 |
| ackk | zyga, fwiw I'm getting that "read only" error even in a VM (so no snapfuse) | 11:05 |
| mvo | mborzecki: indeed | 11:05 |
| mup | PR snapd#8299 opened: devicestate,sysconfig: support "cloud.cfg.d" in uc20 for grade: dangerous <Created by mvo5> <https://github.com/snapcore/snapd/pull/8299> | 11:07 |
| mborzecki | mvo: oh, and we even have a osutil.KillProcessGroup helper ;) | 11:09 |
| ackk | zyga, n/m, I didn't have robust namespace on | 11:14 |
| zyga | :) | 11:14 |
| mborzecki | mvo: wdyt about this: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/process-fun-fun ? | 11:19 |
| mvo | mborzecki: +1 | 11:27 |
| mvo | mborzecki: that looks pretty neat | 11:27 |
| mvo | mborzecki: looks like the exit 1 on gofmt makes a bunch of stuff red | 11:30 |
| mborzecki | mvo: which PR? | 11:30 |
| mvo | mborzecki: the most recent two ones, mine and yours | 11:31 |
| mborzecki | hmm wth is the diff output trimmed? | 11:31 |
| mborzecki | mvo: ehh https://github.com/snapcore/snapd/pull/8300 | 11:34 |
| mup | PR #8300: boot: apply Go 1.10 formatting <Simple š> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8300> | 11:34 |
| mup | PR snapd#8300 opened: boot: apply Go 1.10 formatting <Simple š> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8300> | 11:34 |
| mborzecki | at least we can skip spread now ;) | 11:35 |
| mvo | mborzecki: indeed, thanks for that! | 11:39 |
| mborzecki | uhh | 11:44 |
| mborzecki | #8300 is green | 12:00 |
| mup | PR #8300: boot: apply Go 1.10 formatting <Simple š> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8300> | 12:00 |
| mup | PR snapd#8269 closed: apparmor: use rw for uuidd request to default and remove from elsewhere <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8269> | 12:02 |
| pstolowski | mvo: restarted #8251, would be nice to land it after it gets 2nd review | 12:04 |
| mup | PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251> | 12:04 |
| mvo | pstolowski: yeah, thank you! | 12:10 |
| mup | PR snapd#8300 closed: boot: apply Go 1.10 formatting <Simple š> <Skip spread> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8300> | 12:16 |
| pstolowski | 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 |
| mup | PR #7205: rfc: introduce confinement options failsafe flag <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/7205> | 12:17 |
| zyga | I think the plan is to emit warnings indeed | 12:18 |
| pedronis | pstolowski: thanks for the review of 8277 , I haven't yet looked at why/which of the spread tests fail | 12:29 |
| pstolowski | sure | 12:30 |
| pstolowski | pedronis: btw #8283 has a conflict | 12:30 |
| mup | PR #8283: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <https://github.com/snapcore/snapd/pull/8283> | 12:30 |
| pedronis | fun, not | 12:31 |
| pedronis | anyway I'll look when it gets a 2nd review | 12:31 |
| pedronis | thanks for noticing it though | 12:31 |
| mup | PR snapd#8191 closed: [RFC] cmd/snap-recovery-chooser: add a recovery chooser <Needs Samuele review> <UC20> <ā Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8191> | 12:33 |
| ijohnson | morning folks | 12:42 |
| cmatsuoka | good morning ijohnson | 12:44 |
| ijohnson | hey cmatsuoka | 12:44 |
| pstolowski | hi ijohnson | 12:46 |
| ijohnson | o/ pstolowski | 12:47 |
| pstolowski | and hi cmatsuoka ! | 12:47 |
| pstolowski | #8251 needs 2nd review (and is super simple) | 12:47 |
| mup | PR #8251: overlord: remove unneeded overlord.MockPruneInterval() mocks <Created by mvo5> <https://github.com/snapcore/snapd/pull/8251> | 12:47 |
| mup | PR snapcraft#2985 opened: static: ignore direnv created artifacts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2985> | 13:13 |
| pedronis | pstolowski: I did another pass on search v2, looking good, still some comments/questions though | 13:16 |
| pstolowski | pedronis: thanks | 13:17 |
| pedronis | pstolowski: also seems they are going ahead with /find, sync with Tony about timeline for that | 13:17 |
| pedronis | we'll have to bump the version check as well | 13:17 |
| jdstrand | mvo: hey, are you still collecting PRs for 2.44 or is it baked? | 13:19 |
| pedronis | jdstrand: 2.44 itself is kind of baked, but we'll do a .1 very likely | 13:27 |
| pedronis | jdstrand: OTOH we are looking only for really neccesary or low risk even for .1 | 13:28 |
| pedronis | mborzecki: I reviewed #8298, thank you | 13:28 |
| mup | PR #8298: many: enumerate system seeds, return them on the /v2/systems API endpoint <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8298> | 13:28 |
| mborzecki | pedronis: thanks! | 13:28 |
| jdstrand | pedronis: I may have something that meets that criteria to address an issue in the firefox snap that kenvandine and jamesh highlighted elsewhere | 13:31 |
| pedronis | cmatsuoka: I re-reviewed #8159 | 13:41 |
| mup | PR #8159: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159> | 13:41 |
| cmatsuoka | pedronis: thanks, re-checking it... | 13:41 |
| mvo | jdstrand: still collecting for a 2.44.1 that will happen | 13:56 |
| jdstrand | mvo: ok, don't wait on me. if I get you something fine, if not, also fine :) | 13:56 |
| jdstrand | mvo: thanks! | 13:56 |
| mvo | 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 | 13:57 |
| jdstrand | kenvandine: hey, can you read and comment on my assessment in https://bugs.launchpad.net/snapd/+bug/1868051 ? | 14:14 |
| mup | Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:Triaged> <https://launchpad.net/bugs/1868051> | 14:14 |
| mup | PR snapcraft#2986 opened: packaging: use find_namespace_packages in setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2986> | 14:34 |
| jdstrand | kenvandine: to be clear, I'd like your (or jamesh) feedback in a bug comment in bug #1868051 before I do anything | 14:34 |
| mup | Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:Triaged> <https://launchpad.net/bugs/1868051> | 14:34 |
| kenvandine | jdstrand: thanks! | 14:39 |
| kenvandine | jamesh: can you please comment on that? | 14:40 |
| kenvandine | jdstrand: another issue is what to do when firefox wants to open a file rather than download it | 15:02 |
| kenvandine | right now that goes in TMPDIR | 15:02 |
| kenvandine | which of course apps do not have access too | 15:02 |
| jdstrand | 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 |
| jdstrand | kenvandine: IME, firefox plugs 'home'. patch it to default to ~/Downloads instead | 15:05 |
| jdstrand | 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:06 |
| kenvandine | yeah | 15:07 |
| kenvandine | jdstrand: i've played with setting TMPDIR and have proven it works | 15:07 |
| kenvandine | but, $HOME/Downloads has a couple issues | 15:07 |
| kenvandine | $HOME isn't $REALHOME in the snap | 15:08 |
| kenvandine | and | 15:08 |
| kenvandine | ~/Downloads could be translated | 15:08 |
| jdstrand | 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:08 |
| kenvandine | I guess I could add a script to the command-chain to get $REALHOME and the translated Downloads dir | 15:09 |
| kenvandine | just worry about that being fragile | 15:09 |
| jdstrand | kenvandine: well, yes, of course you would have to do reall hame (getent passwd $(id -u) | cut -f 6 -d ':') | 15:09 |
| jdstrand | real home* | 15:09 |
| jdstrand | kenvandine: and the snap would be free to use a translated Downloads | 15:10 |
| kenvandine | yeah, that's well known. just need a script to set that. can't do it in the yaml | 15:10 |
| kenvandine | i'd need to shell out to xdg to get the translated Downloads | 15:10 |
| kenvandine | should work fine... but i worry about corner cases :) | 15:10 |
| jdstrand | kenvandine: iirc, you only need to do this once since firefox remembers the last one | 15:11 |
| jdstrand | kenvandine: I know that is true for when downloading a file | 15:11 |
| jdstrand | kenvandine: it might not be for /tmp itself | 15:11 |
| jdstrand | kenvandine: but, it could be adjusted to follow the download location | 15:11 |
| jdstrand | kenvandine: perhaps it honors TMPDIR? | 15:12 |
| kenvandine | it does | 15:12 |
| kenvandine | so i just need to set TMPDIR in the snap | 15:12 |
| jdstrand | 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 |
| kenvandine | i'm just thinking through what i want to set that too before submitting a patch to mozilla | 15:13 |
| jdstrand | kenvandine: maybe you want to set it to realhome/Downloads/firefox.tmp. | 15:14 |
| jdstrand | 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 |
| jdstrand | actual* | 15:15 |
| kenvandine | i like that idea | 15:15 |
| jdstrand | kenvandine: or even .firefox.tmp | 15:15 |
| jdstrand | kenvandine: firefox itself (or the wrapper), could clean up things, deleting stuff older than say, a week | 15:16 |
| jdstrand | (be careful doing that, don't follow symlinks!!) | 15:16 |
| jdstrand | 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 |
| jdstrand | man typos | 15:18 |
| jdstrand | works well* | 15:18 |
| kenvandine | :) | 15:18 |
| kenvandine | jdstrand: ok, thanks for the feedback. i'll continue with my original plan | 15:19 |
| kenvandine | but add firefox.tmp to it | 15:19 |
| jdstrand | np | 15:19 |
| jdstrand | kenvandine: fyi, from with snap run --shell firefox: | 15:23 |
| jdstrand | $ xdg-user-dir DOWNLOAD | 15:23 |
| jdstrand | /home/jamie/Downloads | 15:23 |
| kenvandine | yeah | 15:23 |
| jdstrand | so you don't need the getent at all | 15:23 |
| kenvandine | # Set TMPDIR to be under the user's default Downloads dir | 15:24 |
| kenvandine | export TMPDIR=$(xdg-user-dir DOWNLOAD)/firefox.tmp | 15:24 |
| kenvandine | handy | 15:24 |
| kenvandine | and i'll add that to command-chain after desktop-launch to ensure xdg user dirs are all setup | 15:24 |
| jdstrand | 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:26 |
| kenvandine | jdstrand: yeah, desktop-launch does some stuff to ensure those are set properly | 15:27 |
| jdstrand | kenvandine: I guess so long as that user-dirs.dirs is setup right, you're good | 15:27 |
| jdstrand | cool | 15:27 |
| jdstrand | 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:28 |
| pstolowski | pedronis: hey, do you have a moment for HO? | 15:29 |
| kenvandine | firefox does create it if it doesn't exist | 15:29 |
| pedronis | pstolowski: yes | 15:32 |
| pstolowski | pedronis: joining standup HO | 15:33 |
| tkamppeter | jdstrand, hi | 15:41 |
| tkamppeter | jdstrand, what about a meeting about the interface for the new CUPS Snap? | 15:42 |
| kyrofa | ijohnson, any insight into how to make https://forum.snapcraft.io/t/no-interfaces-without-core-snap a better experience? | 15:54 |
| kyrofa | It's an unfortunate situation | 15:54 |
| ijohnson | kyrofa: upgrade snapd everywhere ? | 15:58 |
| ijohnson | 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 |
| kyrofa | ijohnson, that's not a solution I'm afraid | 15:59 |
| kyrofa | ijohnson, not one that scales | 15:59 |
| kyrofa | ijohnson, the problem is that it's standard practice to only install security updates in prod | 16:00 |
| ijohnson | 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 |
| ijohnson | perhaps others have thoughts, but I don't know how we can make old snapd's change behavior without updating old snapd | 16:00 |
| kyrofa | ijohnson, we have abused the security component in the past, is that an option? | 16:01 |
| ijohnson | kyrofa: you mean push an update to -security ? | 16:01 |
| kyrofa | Indeed | 16:01 |
| ijohnson | 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:01 |
| ijohnson | that would be a mvo request though | 16:02 |
| kyrofa | Exactly my thinking. Not pretty, not ideal, but not unprecedented | 16:02 |
| ijohnson | yep | 16:02 |
| kyrofa | mvo, you should consider that as core18 becomes the standard | 16:02 |
| kyrofa | ijohnson, mvo, I'll add a comment about this to the forum post | 16:03 |
| ijohnson | kyrofa: thanks | 16:04 |
| pedronis | kyrofa: we do need the agreement of the security team to do that | 16:06 |
| pstolowski | pedronis: --mask/unmask work with --root š | 16:08 |
| pedronis | pstolowski: good | 16:08 |
| jdstrand | 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:16 |
| jdstrand | 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:17 |
| tkamppeter | ijohnson, around? | 16:19 |
| ijohnson | tkamppeter: yes | 16:20 |
| ijohnson | Next week is fine for me | 16:20 |
| ijohnson | tkamppeter Please include pedronis in the meeting though | 16:20 |
| pedronis | I will not be available Thu or Fri | 16:20 |
| tkamppeter | OK, should we do wed, 25, at 3pm UTC? | 16:22 |
| tkamppeter | jdstrand, ijohnson, pedronis, me, someone else? | 16:22 |
| tkamppeter | Or better mon, 23, at 3pm UTC? | 16:23 |
| ijohnson | 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:23 |
| tkamppeter | So let us do Wed then. | 16:24 |
| tkamppeter | jdstrand, ijohnson, pedronis: Done. You should have gotten an invitation. | 16:30 |
| ijohnson | got it, thanks tkamppeter | 16:31 |
| mvo | kyrofa: sorry, lacking context | 16:31 |
| mvo | kyrofa: can you give me a tl;dr | 16:31 |
| * cachio lunch | 16:33 | |
| kyrofa | 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 |
| jdstrand | tkamppeter: you didn't check for meeting conflicts :( | 16:33 |
| kyrofa | At least, not without also manually installing the core snap or manually updating snapd first so it installs the snapd snap | 16:34 |
| tkamppeter | jdstrand, so I hit another meeting of yours? I will go through all three where I find a slot. | 16:34 |
| jdstrand | 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 |
| jdstrand | tk thanks | 16:34 |
| jdstrand | tkamppeter: thanks :) | 16:34 |
| * jdstrand lunch | 16:35 | |
| tkamppeter | jdstrand, pedronis, ijohnson: How do I check the participant's meeting schedules? | 16:36 |
| tkamppeter | ijohnson, pedronis, what do you prefer? Tue, or Thu? | 16:36 |
| pedronis | Thu I'm off | 16:37 |
| tkamppeter | So Tue is left, ijohnson, does it work for you? | 16:37 |
| jdstrand | tuesday, again, is good for me at around the same time up to two hours earlier or 6 hours later | 16:39 |
| jdstrand | 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 |
| mvo | kyrofa: yes, that's correct, we fixed this a while ago but not everybody got the fix :( | 16:40 |
| jdstrand | ok, really going to lunch now | 16:40 |
| kyrofa | mvo, right, exactly | 16:40 |
| mvo | 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 |
| tkamppeter | So let me do a time guess which should hit a slot on all of you: Tue, 24, 1pm UTC | 16:41 |
| ijohnson | tkamppeter: sorry I was away | 16:41 |
| tkamppeter | ijohnson, jdstrand, pedronis: Is Tue, 24, 1pm UTC OK for all of you? | 16:42 |
| ijohnson | tkamppeter: yes that's fine for me | 16:42 |
| kyrofa | mvo, indeed. Is there any other option? | 16:42 |
| jdstrand | tkamppeter: yes | 16:43 |
| tkamppeter | pedronis? | 16:43 |
| pedronis | 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 |
| mvo | 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:44 |
| tkamppeter | pedronis, do you have another slot, which could hit a free slot of jdstrand? | 16:45 |
| kyrofa | mvo, wouldn't that also be a snapd update, though? | 16:46 |
| pedronis | Tue 3p pm UTC | 16:46 |
| mup | PR snapcraft#2985 closed: static: ignore direnv created artifacts <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2985> | 16:46 |
| ijohnson | tkamppeter: I looked at everybody's calendars and propsoed a time which should work for everybody | 16:46 |
| kyrofa | mvo, or is that something you can put in core18? | 16:47 |
| ijohnson | tkamppeter: pedronis ah I think I proposed the same time that pedronis said | 16:47 |
| tkamppeter | ijohnson, which one is that time? | 16:47 |
| ijohnson | it's 10 am cst, I don't know what UTC time it is | 16:47 |
| tkamppeter | ijohnson, could you create a meeting at that hour, and invite me, so I will see where it falls. | 16:48 |
| ijohnson | tkamppeter: if you check your email you should get an email with the proposed time | 16:48 |
| mvo | 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:48 |
| mvo | kyrofa: oh, maybe we could put "assumes: [snapd2.41]" into core18 | 16:49 |
| mvo | kyrofa: I wonder if that would work | 16:49 |
| tkamppeter | ijohnson, nothing appeared yet. | 16:49 |
| kyrofa | mvo, ah, which implies a snapcraft change, and an assumption that the snap being installed was built recently | 16:49 |
| kyrofa | mvo, the assumes would just prevent install, right? | 16:50 |
| mvo | kyrofa: correct, not a great option | 16:50 |
| kyrofa | But at least it TELLS them something | 16:50 |
| mvo | kyrofa: it would but with a somewhat useful message | 16:50 |
| kyrofa | Indeed | 16:50 |
| mvo | kyrofa: it might be worth a shot | 16:50 |
| kyrofa | Right now it's just broken, and the user is left holding the pieces wondering what to do | 16:50 |
| kyrofa | sergiusens, you around? | 16:50 |
| mvo | 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 |
| mvo | kyrofa: thank you for raising this btw | 16:51 |
| ijohnson | tkamppeter: I sent an invite, I guess you have a meeting that goes til 10:30, I think a 30 minute meeting is enough for now | 16:51 |
| kyrofa | mvo, my pleasure. I think it would be trivial to add this to snapcraft, which will move things in the right direction. Mull over the -security abuse, though | 16:53 |
| kyrofa | mvo, I'll update the forum thread with this | 16:53 |
| sergiusens | kyrofa: yes | 16:53 |
| tkamppeter | ijohnson, could we move it to half an hour later? | 16:53 |
| sergiusens | kyrofa: a bit hectic today though... the country is closing down and I am dealing with accomodations for a period where we do not know what will stay open | 16:54 |
| tkamppeter | Or is it really the only 1-hour hole in the week for all the 3 of you? | 16:54 |
| kyrofa | sergiusens, then ignore me. I'll ping you in the forum, look when you can | 16:54 |
| sergiusens | kyrofa: it is fine now :-) Might not be later :-) | 16:54 |
| tkamppeter | If so, our Desktop team meeting is only IRC and usually ends after 30 minutes. | 16:54 |
| mvo | kyrofa: thank you! | 16:55 |
| ijohnson | tkamppeter: I moved it | 16:55 |
| tkamppeter | ijohnson, I have moved it again, WDYT about this time? | 16:56 |
| ijohnson | tkamppeter: which meeting, the tuesday one I set up or the monday one you set up ? | 16:57 |
| kyrofa | sergiusens, to save you the scrollback then, I pinged you anyway: https://forum.snapcraft.io/t/no-interfaces-without-core-snap | 16:57 |
| tkamppeter | ijohnson, the tuesday one, I did not realize that I have put mine on monday, because the Calendar is starting weeks with Sun. | 16:58 |
| ijohnson | okay so the tuesday meeting is the one we will do | 16:58 |
| tkamppeter | ijohnson, so I will remove my meeting and let the rest up to you. OK? | 16:59 |
| ijohnson | sure sounds good | 16:59 |
| mup | PR snapd#8159 closed: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159> | 17:00 |
| sergiusens | kyrofa: replied on forum, short answer: we can | 17:00 |
| tkamppeter | ijohnson, done. | 17:01 |
| tkamppeter | Could you add the link https://forum.snapcraft.io/t/interface-request-cups-control-on-cups-snap-and-including-d-bus/ to the description? Thanks. | 17:02 |
| ijohnson | done | 17:03 |
| cmatsuoka | cachio: #8260 is still failing, shellcheck didn't like some stuff there | 17:04 |
| mup | PR #8260: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260> | 17:04 |
| abeato | ijohnson, hey, is it possible lready to run UC20 on kvm? | 17:33 |
| tkamppeter | ijohnson, jdstrand, pedronis, I have sent you all an e-mail with the final settlement for the meeting. Please check. | 17:37 |
| jdstrand | tkamppeter: ack, thanks! (accepted) | 17:58 |
| cachio | cmatsuoka, fixed | 17:58 |
| ijohnson | abeato: yes, do you have a dire need to boot uc20 on kvm soon? it's easy enough to seup but building images and such may change a bit from now until the release, so rather than have you get caught up in those changes if you can wait until the release that would be best | 17:58 |
| abeato | ijohnson, I'm starting to develop snaps with base: core20, and I'd like to do some testing. But it looks like I can run them on UC18, it downloads core20. Is that a good enough environment for some initial testing? | 18:00 |
| ijohnson | abeato yes for now that's probably good enough, as we can get closer we can help you run on actual uc20 | 18:23 |
| tkamppeter | jdstrand, thanks for the feedback. | 18:29 |
| abeato | ijohnson, ok, then I have all I need, thanks | 18:34 |
| mup | PR snapd#8260 closed: tests: enable nested on core20 and test current branch <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8260> | 20:01 |
| mup | PR snapd#8301 opened: interfaces/many: deny arbitrary desktop files and misc from /usr/share <ā Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301> | 20:18 |
| jdstrand | mvo: fyi, ^ was the PR I was thinking of for 2.44.1. after implementing it, I think it is too much for 2.44.1 and have milestoned if for 2.45 instead | 20:23 |
| jdstrand | jamesh (cc kenvandine): I referenced https://github.com/snapcore/snapd/pull/8301 in https://github.com/snapcore/snapd/pull/8301 | 20:23 |
| mup | PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <ā Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301> | 20:24 |
| mvo | jdstrand: thanks | 20:25 |
| jdstrand | erf | 20:25 |
| jdstrand | jamesh (cc kenvandine): sorry, mispaste. I referenced https://github.com/snapcore/snapd/pull/8301 in https://bugs.launchpad.net/snapd/+bug/1868051 | 20:25 |
| mup | PR #8301: interfaces/many: deny arbitrary desktop files and misc from /usr/share <ā Blocked> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8301> | 20:26 |
| mup | Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:In Progress by jdstrand> <https://launchpad.net/bugs/1868051> | 20:26 |
| kenvandine | jdstrand: thanks! I dropped jamesh and email earlier asking him to comment when he's back online | 20:27 |
| mup | PR snapd#8302 opened: interfaces/greengrass-support: fix typo <Simple š> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8302> | 20:52 |
| mup | PR snapd#8303 opened: interfaces/greengrass-support: fix typo <Simple š> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8303> | 20:53 |
| mup | PR snapd#8283 closed: overlord,timings,daemon: separate timings from overlord/state <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8283> | 20:54 |
| jdstrand | zyga: for tomorrow's standup. I wonder if bug #1866932 and bug #1867952 are dupes of bug #1865063 | 21:40 |
| mup | Bug #1866932: package snapd 2.44~pre1+20.04 failed to install/upgrade: installed snapd package post-removal script subprocess returned error exit status 1 <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1866932> | 21:40 |
| mup | Bug #1867952: package snapd 2.44+20.04 failed to install/upgrade: installed snapd package post-installation script subprocess was killed by signal (Terminated) <amd64> <apport-package> <focal> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1867952> | 21:40 |
| mup | Bug #1865063: snapd package hangs on deb postinst <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1865063> | 21:40 |
| jdstrand | zy | 21:40 |
| jdstrand | oh, ijohnson is here. zyga, nm | 21:40 |
| jdstrand | ijohnson: fyi ^ | 21:40 |
| jdstrand | ijohnson: that might be something for 2.44.1. I don't have any more info to add; just fyi | 21:41 |
| ijohnson | jdstrand: sorry what's this | 21:44 |
| jdstrand | ijohnson: it is just so mvo is aware that there might be an issue with 2.44 and (at least) deb upgrades | 21:44 |
| ijohnson | jdstrand: ack I'll make sure it's in the SU notes, but I don't have bandwidth to investigate right now unfortunately | 21:45 |
| jdstrand | ijohnson: postinst isn't finishing | 21:45 |
| jdstrand | ijohnson: oh, I wasn't asking you to look :) just bubbling it up so you can maybe mention it in standup | 21:45 |
| mwhudson | what is the expected lag between pushing to an automatically built branch in launchpad and the build starting? | 21:45 |
| mwhudson | i never quite know what to expect | 21:46 |
| ijohnson | jdstrand: also did you see I needed to open another greengrass-support PR ? apparently what I had was insufficient | 21:46 |
| ijohnson | they needed a slightly different access | 21:46 |
| jdstrand | mwhudson: that is a good question. sometimes it seems fast and other times less so | 21:46 |
| jdstrand | ijohnson: oh, not yet | 21:46 |
| * jdstrand looks | 21:46 | |
| ijohnson | 8302 and 8303 IIRC | 21:47 |
| jdstrand | ijohnson: approved | 21:49 |
| ijohnson | thanks jdstrand ! | 21:49 |
| jdstrand | np | 21:50 |
| mwhudson | jdstrand: i wonder if it's a */15 cron or something | 21:51 |
| mwhudson | anyway my snap is now building | 21:51 |
| jdstrand | mwhudson: it probably is cron. I had a fanciful idea that it would do it quickly if you hadn't committed in a while and then back off if you had :) | 21:58 |
| jdstrand | mwhudson: sometimes I'm impatient and trigger it manually | 21:59 |
| mwhudson | yeah i thought there was a threshold like that too but idk | 21:59 |
| mwhudson | yeah and then you end up with two builds going at once :) | 21:59 |
| jdstrand | it makes it twice as fun that way :) | 21:59 |
| cjwatson | mwhudson,jdstrand: There is indeed a */15 cron job; it runs for any snap that's configured to build automatically, whose source branch has been modified since the last automatic build was dispatched, and which hasn't had an automatic build dispatched in the last hour. | 23:00 |
| cjwatson | When the build actually *starts* after that will of course depend on build farm load etc. | 23:00 |
| mwhudson | cjwatson: does pushing a new tag count as modification? | 23:01 |
| mwhudson | cjwatson: and, hah for me guessing the frequency | 23:01 |
| cjwatson | mwhudson: No. | 23:01 |
| cjwatson | mwhudson: Modification is detected per-ref, so you'd need to actually change the specific branch that the snap builds from. | 23:02 |
| mwhudson | cjwatson: makes sense | 23:03 |
| cjwatson | (More specifically, when you push changes to a git repository in LP, any snaps based on refs that have changed are marked as stale.) | 23:04 |
| cjwatson | It's fairly similar to the recipe staleness logic, which you may distantly remember from bzr. | 23:04 |
| mwhudson | very distantly :) | 23:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!