| mup | Bug #1671266 opened: rfkill should be included in the core snap <hwe> <Snappy:Confirmed for ogra> <https://launchpad.net/bugs/1671266> | 01:51 |
|---|---|---|
| === JanC_ is now known as JanC | ||
| mup | PR snapd#7690 closed: cmd/snap: make completion skip hidden commands (unless overridden) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7690> | 07:19 |
| mup | PR snapd#7714 opened: overlord: refactor mgrsSuite and extract kernelSuite <Created by mvo5> <https://github.com/snapcore/snapd/pull/7714> | 08:21 |
| mvo | pedronis_: a review for 7682 would be great. then I could use the helpers there for the base->bsae undo tests | 08:30 |
| mvo | pedronis_: actually - 7701 (smaller) is enough :) | 08:31 |
| === pedronis_ is now known as pedronis | ||
| pedronis | mvo: hi, yes, I wanted to ask which one of those I should review first? because the newer was merged into the older? | 08:32 |
| mvo | pedronis: yeah, the newer one is probably the best starting point | 08:38 |
| mvo | pedronis: so 7701 is probably the best start, its relatively small | 08:38 |
| pedronis | mvo: I'll look now, I was trying to give input on some older PRs that were stuck | 08:42 |
| === alan_g is now known as alan_g_ | ||
| zyga | good morning | 08:54 |
| zyga | hey mvo, pedronis | 08:54 |
| zyga | how are you doing this frosty morning? | 08:54 |
| mvo | hey zyga ! doing well | 08:54 |
| pedronis | mvo: I reviewed 7701 | 08:55 |
| mvo | pedronis: thank you! | 08:56 |
| pedronis | zyga: hi, did you see my question in #7700 ? | 08:56 |
| zyga | not yet | 08:56 |
| mup | PR snapd#7715 opened: overlord: add base->base remodel undo tests and fixe <Created by mvo5> <https://github.com/snapcore/snapd/pull/7715> | 08:56 |
| mup | PR #7700: many: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700> | 08:56 |
| mvo | pedronis: I pushed base->base remodel undo but it needs all the other ones first but at least I think we are complete in the sense that we have code written :) | 08:56 |
| mvo | pedronis: thanks a bunch for the review! | 08:56 |
| zyga | @pedronis I yeah, I thought about this and I think it may need to be in /var after all | 08:57 |
| zyga | @pedronis I got into a longer exploration of the problem of locking | 08:57 |
| pedronis | ok | 08:57 |
| zyga | @pedronis I tried to document that in the doc but I need to remove redundant parts and make the whole thing comprehensible | 08:57 |
| pedronis | mvo: this test seems also to have that kind of name: TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart | 08:59 |
| zyga | wow that's a long name :) | 09:02 |
| mvo | pedronis: yeah, fixing all of the UpdatesBootloader ones now | 09:03 |
| mvo | zyga: its a long test! needs a long name :) | 09:03 |
| zyga | mvo: ChapterOne | 09:03 |
| zyga | ;-) | 09:03 |
| mvo | zyga: *if* you work today a review for 7651 would be great | 09:09 |
| zyga | sure, let me start with that | 09:09 |
| * zyga reads the spec first | 09:15 | |
| pstolowski | morning | 09:25 |
| zyga | hey pawel | 09:26 |
| pstolowski | pedronis: i'm changing PreseedMode to func, no strong opinion either way | 09:35 |
| pstolowski | zyga: would you find a moment for #7675? i'd like to get it out of the way as it's a base for other PRs | 09:40 |
| mup | PR #7675: release: preseed mode flag <Prebaking 🍞> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675> | 09:40 |
| zyga | pstolowski: gladly, just after the current one | 09:40 |
| pedronis | mvo: there's a problem with the download via snapd stuff | 09:43 |
| mvo | pedronis: oh? | 09:43 |
| pedronis | mvo: you get polkit prompts | 09:43 |
| pedronis | which I'm not sure we want | 09:43 |
| pedronis | for this | 09:43 |
| zyga | oh? | 09:44 |
| mvo | pedronis: oh, meh, yes. downlaod is an auth endpoint :/ | 09:44 |
| zyga | because of snapd asking polkit? | 09:44 |
| mvo | pedronis: that sounds like we need some flag to prevent interaction | 09:44 |
| mvo | zyga: yeah | 09:44 |
| Chipaca | pedronis: yesterday I suggested landing the current download but with the defaults flipped | 09:44 |
| pedronis | mvo: well, we might need to change the auth rules for the /download endpoint | 09:45 |
| Chipaca | ie having direct being the default, with a hidden --indirect flag | 09:45 |
| mup | Issue core18#142 opened: Stuck with blank screen on snap-core 18 Raspi 3 B+ install <Created by bernermic> <https://github.com/snapcore/core18/issue/142> | 09:45 |
| pedronis | Chipaca: just to progress? because that's not the final goal | 09:46 |
| Chipaca | pedronis: just to progress, yes | 09:47 |
| Chipaca | pedronis: otherwise i see this being an open pr for quite some time, across vancouver | 09:48 |
| jamesh | Chipaca: re. https://github.com/snapcore/snapd/pull/7589, are you happy with pedronis's suggestion for "snap routine"? I'm fine with it myself. | 09:48 |
| mup | PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589> | 09:48 |
| pedronis | Chipaca: isn't just a matter to remove this from download ? PolkitOK: "io.snapcraft.snapd.manage", | 09:48 |
| Chipaca | jamesh: heh, i'm terrible with names, but let me respond over there | 09:49 |
| pedronis | I don't think it's actually a mgmt action (in those terms) anyway | 09:49 |
| pedronis | mvo: ^ | 09:49 |
| mvo | pedronis: hm, good point, that is probably fine | 09:50 |
| mvo | Chipaca: beside better tests (I pushed two prs recently) and resume-partial is there anything missing from the snap download via snapd? | 09:50 |
| pedronis | mvo: also ./snap0 known --remote account account-id=dell gives me nothing (no error either), but --direct works | 09:52 |
| pedronis | mvo: something is off | 09:52 |
| pedronis | with known too | 09:52 |
| mvo | pedronis: uh, let me debug this | 09:53 |
| pedronis | mvo: you pushed a 2.42.1 to edge? | 09:53 |
| pedronis | that will roolback people | 09:53 |
| mvo | pedronis: I did not, that was our stupid machinery not being updated :( | 09:54 |
| mvo | pedronis: let me fix this, but it sounds like one of the auto-merge/auto-build bits failed | 09:54 |
| pedronis | so my snapd doesn't have remote on /assertions | 09:54 |
| pedronis | I suppose | 09:54 |
| Chipaca | mvo: more real-life testing? | 09:55 |
| mvo | Chipaca: good point :) | 09:55 |
| Chipaca | mvo: i'd like to have a whole .N of us using it to help us find the bugs | 09:56 |
| Chipaca | but I'd also like people to stop being horrible to each other, and here we are | 09:57 |
| mvo | Chipaca: we will have the entire 2.43 for people to test :) | 09:57 |
| mvo | pedronis: I can reproduce the dell issue, debugging now | 09:58 |
| mvo | Chipaca: wdyt about removing pollkitOk from /v2/download ? | 09:58 |
| Chipaca | mvo: nah | 09:58 |
| Chipaca | mvo: just tell it to not do interactive | 09:58 |
| * Chipaca looks for how to do that | 09:59 | |
| Chipaca | mvo: client.Config{Interactive: false} | 09:59 |
| Chipaca | mvo: turns off polkit for that request | 09:59 |
| Chipaca | bah, for any request that client emits | 10:00 |
| mvo | Chipaca: \o/ | 10:00 |
| Chipaca | mvo: you owe jamesh a beverage | 10:00 |
| mvo | pedronis: snap-vendor-sync repo is 40h behind, this is controlled via spread-cron, I need to check with sergio what is going on there :( | 10:01 |
| pedronis | mvo: ok | 10:01 |
| jamesh | mvo: the Client instance set up by the snap command sets Interactive based on whether stdin is a tty | 10:02 |
| jamesh | in general it is going to do the right thing for non-interactive scripts | 10:04 |
| Chipaca | mvo: jamesh: cmd/snap/main's mkClient could take a ClientConfig to override that though | 10:04 |
| pedronis | yea, for download I think the regression is still annoying even interactively | 10:04 |
| pedronis | we are not starting from scratch here | 10:05 |
| jamesh | Chipaca: presumably you could just do client.Interactive = false within the command | 10:05 |
| jamesh | I don't think anything would be using the client after the command takes control of execution | 10:05 |
| Chipaca | degville: could / should we add a list of supported architectures to https://snapcraft.io/docs/architectures ? | 10:06 |
| degville | Chipaca: yes, I think so - I've actually got a list in my edit, taken from build.snapcrraft.io. | 10:06 |
| Chipaca | degville: i was just looking for that list :-) | 10:07 |
| Chipaca | there's somebody trying to build a MIPS core image | 10:07 |
| Chipaca | seems like they've spent some time on it already | 10:07 |
| Chipaca | (not very effectively) | 10:07 |
| degville | Chipaca: these are the ones I've got - s390x, ppc64el, arm64, armhf, amd64, i386. | 10:09 |
| mvo | pedronis: I can reproduce this if I have 2.42.1 snapd and a snap client from master. snap client will sent "remote=true" to snapd but the old snapd does not know this header and returns nothing (but also no error). switching to the real edge snapd fixes this (I got reverted to 2.42.1 apparently) | 10:09 |
| zyga | mvo: can we nuke the vendor sync repo and use github actions? | 10:10 |
| zyga | mvo: and perhaps build the thing with github actions in a way that allows us to have the real git sha in the snap version? | 10:10 |
| mvo | zyga: maybe, that would certainly be nice | 10:10 |
| zyga | mvo: yeah, worth trying at least | 10:11 |
| mvo | zyga: yes! unfortunately not today | 10:14 |
| zyga | nope | 10:14 |
| zyga | I don't even know if actions are out of beta yet | 10:14 |
| zyga | I have access on my repos but I was given access ahead of general release a while ago | 10:14 |
| pedronis | mvo: ok, at least this bit is understood, yes I got edge with 2.42.1 here too | 10:15 |
| jamesh | github actions are so much nicer to deal with than travis | 10:15 |
| jamesh | I've been using them on some of my personal repos too | 10:16 |
| zyga | jamesh: that's good indicator to use them | 10:16 |
| zyga | thanks! | 10:16 |
| jamesh | zyga: here were my initial thoughts on the system: https://blogs.gnome.org/jamesh/2019/09/06/exploring-github-actions/ | 10:17 |
| pedronis | jamesh: I answered to John comment in #7589 | 10:21 |
| mup | PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589> | 10:21 |
| pedronis | I think we do have a path forward | 10:21 |
| jamesh | pedronis: thanks. For the user session systemd branch, I don't think timers and sockets need any special handling. I put my reasoning in a comment on #7238 | 10:23 |
| mup | PR #7238: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7238> | 10:23 |
| pedronis | jamesh: yea, I'll do a pass again on it today, then either way it will need a re-review by jdstrand | 10:23 |
| pedronis | jamesh: btw I'm off next week | 10:23 |
| jamesh | okay. Thanks | 10:24 |
| pedronis | jamesh: the fwupd one is also unblocked, it just needs a 2nd review and to get green | 10:24 |
| mvo | pedronis, Chipaca I updated the code in 7624 to not have a polkit prompt anymore (set interactive to false) | 10:28 |
| pstolowski | pedronis: hey, i've added a separate firstbootPreseed16 suite to yesterday's PR. one remaining "annoyance" is the copy of two helpers (makreCoreSnaps + makeSeededChange - the latter with only minor change), maybe they should be made more general to be reused by two *16 suites - although moving them to firstBoot16Suite would probably go too far since they set up specific test data. slightly on the fence about what to | 11:11 |
| pstolowski | do about them | 11:11 |
| pedronis | pstolowski: sorry, what is the problem? that they are *16 specific? | 11:12 |
| pedronis | pstolowski: did you forget to add a file? | 11:13 |
| pedronis | this diff is strange https://github.com/snapcore/snapd/pull/7705/commits/fdd697d3b89cab1101b8adbd04f082d32b3aa27e | 11:14 |
| mup | PR #7705: [WIP] o/devicestate: handle preseed in firstboot <Prebaking 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705> | 11:14 |
| pstolowski | pedronis: yes i forgot the file in that one commit. look at the next commit or complete diff | 11:15 |
| pedronis | pstolowski: so makeSeedChanges has actual differences | 11:19 |
| pstolowski | pedronis: yes, but minor, different checkTasks* used | 11:19 |
| pedronis | you can make a firstBoot16BaseTest with seedtest and those two? no? | 11:20 |
| pedronis | I mean with seedtest.TestingSeed16 | 11:20 |
| pedronis | if you want | 11:21 |
| pedronis | makeCoreSnap could be a global helper that takes a *seedtest.TestingSeed16 | 11:22 |
| pedronis | makeCoreSnaps | 11:22 |
| pstolowski | pedronis: yes, i can do something like this | 11:23 |
| pedronis | pstolowski: I don't strong opinions on this, need to try a bit what is readable in the end | 11:25 |
| pedronis | I wouldn't do is chain them though firstBoot16BaseTest shouldn't contain firstBootBaseTest | 11:25 |
| pedronis | and maybe firstBoot16BaseTest is not the best name for that one | 11:27 |
| pedronis | pstolowski: otoh all the new tests have a slightly different style that makes something like makeCoreSnaps a bit less necessary | 11:31 |
| pedronis | so maybe we should change to that at some point | 11:31 |
| pstolowski | pedronis: i can also postpone these changes for a followup maybe (when you're back)? | 11:31 |
| mvo | Chipaca: if you feel like reviewing, 7701 would be a nice one | 11:33 |
| pstolowski | pedronis: will you find a moment today to take a look at #7706? | 11:40 |
| mup | PR #7706: overlord/snapstate: install task edges <Prebaking 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7706> | 11:40 |
| Chipaca | mvo: reviewing is all there is | 11:41 |
| Chipaca | mvo: but first more coffee | 11:41 |
| Chipaca | maybe a bite to eat as well | 11:41 |
| jdstrand | jamesh, pedronis: re 7238, it's on my list | 11:42 |
| zyga | hey jdstrand :) | 11:42 |
| jdstrand | hey zyga :) | 11:42 |
| pstolowski | i'm going afk for now. i'll check later if my #7675 can land and rebase the rest if needed | 11:42 |
| mup | PR #7675: release: preseed mode flag <Prebaking 🍞> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675> | 11:42 |
| zyga | o/ | 11:42 |
| === pstolowski is now known as pstolowski|afk | ||
| mvo | Chipaca: sounds like a great plan! | 11:47 |
| * mvo contemplates food as well | 11:47 | |
| mup | PR snapd#7708 closed: parts/plugins: don't xz-compress a deb we're going to discard <Simple 😃> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7708> | 11:51 |
| pedronis | pstolowski|afk: sorry, needed to run to have lunch | 12:02 |
| zyga | pedronis: https://github.com/snapcore/snapd/pull/7651#pullrequestreview-310392093 | 12:21 |
| mup | PR #7651: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <https://github.com/snapcore/snapd/pull/7651> | 12:21 |
| zyga | pstolowski|afk: looking at your PR now | 12:26 |
| zyga | pstolowski|afk: https://github.com/snapcore/snapd/pull/7675#pullrequestreview-310427961 (though not what you may have expected) | 12:35 |
| mup | PR #7675: release: preseed mode flag <Prebaking 🍞> <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7675> | 12:35 |
| * zyga breaks for quick tea | 12:36 | |
| zyga | it's soooo cold at home today | 12:36 |
| zyga | jdstrand: https://github.com/snapcore/snapd/pull/7659 should be ready now | 13:17 |
| zyga | jdstrand: it's just the extra feature flag you asked for | 13:18 |
| mup | PR #7659: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement <Created by zyga> <https://github.com/snapcore/snapd/pull/7659> | 13:18 |
| zyga | jdstrand: I'm looking at expanding spread test to cover that, just looking where to put it | 13:18 |
| jdstrand | zyga: ok, thanks | 13:18 |
| kenvandine | jdstrand, zyga: any thoughts on marcustomlinson's findings on bug 1661626 ? | 13:19 |
| mup | Bug #1661626: GSettings/dconf reports incorrect values on setting change under confinement <desktop> <snapd:Triaged by marcustomlinson> <https://launchpad.net/bugs/1661626> | 13:19 |
| zyga | kenvandine: no, it seems like a mess now :/ | 13:20 |
| zyga | kenvandine: feels like gsettings really needs a portal / proxy | 13:20 |
| zyga | kenvandine: do you think there's a simple solution for all of this? | 13:20 |
| kenvandine | there is a settings proxy, not sure the state of it though | 13:21 |
| kenvandine | s/proxy/portal | 13:21 |
| kenvandine | https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml | 13:22 |
| zyga | kenvandine: how can we use this? | 13:22 |
| zyga | I mean | 13:22 |
| jdstrand | zyga: this is what jamesh and I briefly chatted about in the plenary room as a side discussion after a meeting. there is stuff we can probably do here, but not immediately. he summarized that discussion in the forum somewhere | 13:22 |
| kenvandine | but that seems to be read access to the host settings | 13:23 |
| zyga | does it need gtk change to software to use that vs doing what they needed before | 13:23 |
| zyga | or is this some transparent proxy where we hack around and inject it and software is unmodified | 13:23 |
| kenvandine | i don't think it helps for an app with it's own schema | 13:23 |
| jdstrand | but that was for per app settings, not global settings now that I type that | 13:23 |
| kenvandine | the per app is the issue here, at least this bug | 13:23 |
| kenvandine | if i'm reading it right | 13:24 |
| marcustomlinson | bare in mind that set and get work just fine, it's just the monitor that is broke | 13:24 |
| kenvandine | marcustomlinson: right? this is an app not getting change notificiations for it's own settings? | 13:24 |
| zyga | marcustomlinson: who sends the signal? | 13:25 |
| kenvandine | yeah, it seems to be all related to the XDG_RUNTIME_DIR | 13:25 |
| marcustomlinson | zyga: shrug | 13:25 |
| zyga | I'm not experienced in the desktop stack | 13:25 |
| zyga | I cannot help without someone who knows how this works | 13:25 |
| kenvandine | i think the app's process | 13:25 |
| zyga | would it help if we had not modified xdg runtime dir? | 13:25 |
| kenvandine | zyga: i think so | 13:25 |
| kenvandine | maybe this is a bug in the helpers? | 13:26 |
| zyga | sounds like someone needs to deep dive into this | 13:26 |
| jdstrand | but, we can probably just add another symlink for now from $XDG_RUNTIME_DIR/dconf -> ../dconf | 13:26 |
| zyga | I really don't know | 13:26 |
| marcustomlinson | jdstrand: I did try that, didn't work | 13:26 |
| zyga | my meta observation is as follows: | 13:26 |
| kenvandine | jamesh: are you by chance still around? | 13:27 |
| jdstrand | marcustomlinson: oh? did dconf remove it? | 13:27 |
| zyga | I think it would be healthier for the process if instead of in the helpers this was a part of snapd's preparation of /run, when some sort of interface is used | 13:27 |
| marcustomlinson | jdstrand: no didn't remove it, perhaps permission issue not sure | 13:27 |
| zyga | it would teach the snapd team more a | 13:27 |
| zyga | and it would help in fixing "what happens" part of the problem, because we have many layers | 13:27 |
| jdstrand | marcustomlinson: a snap that plugs gsettings can acces /run/user/*/dconf, so a symlink to it should be fine | 13:28 |
| marcustomlinson | jdstrand: well it wasn't :D | 13:28 |
| jdstrand | marcustomlinson: ok... that isn't a lot of detail ;) | 13:28 |
| marcustomlinson | jdstrand: I asked for assistance | 13:29 |
| marcustomlinson | not for ears to hear the solution | 13:29 |
| jdstrand | marcustomlinson: but, /run/user/*/dconf is different than ~/.config/dconf, so maybe it doesn't have to do with XDG_RUNTIME_DIR at all? | 13:29 |
| jdstrand | marcustomlinson: I'm not sure what you mean be that, but if you are implying I am not trying to assist, you are wrong | 13:30 |
| zyga | marcustomlinson: we can help with the confinement but we need someone to understand how the desktop side works well and design how it ought to work with isolation in place | 13:30 |
| marcustomlinson | I don't have a lot of detail | 13:30 |
| mup | PR snapd#7651 closed: asserts: support and parsing for slots-per-plug/plugs-per-slot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7651> | 13:30 |
| kenvandine | i think we probably need jamesh | 13:31 |
| marcustomlinson | zyga: yes which is what I said in my comment | 13:31 |
| jdstrand | but if I'm being asked to look at this to investigate the whole issue rather than provide pointers to someone who will, I'll but it in backlog | 13:31 |
| kenvandine | jdstrand: nah, i think we need jamesh to look at it | 13:31 |
| mup | PR snapd#7695 closed: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7695> | 13:31 |
| marcustomlinson | kenvandine: I'm happy to press on with it if you like | 13:32 |
| pedronis | pstolowski|afk: #7695 has landed which should help with your PR | 13:32 |
| marcustomlinson | I just saw a rabbit hole approaching and thought I'd reach out first | 13:32 |
| mup | PR #7695: o/devicestate: the basics of Core 20 firstboot support with test <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7695> | 13:32 |
| kenvandine | marcustomlinson: i'm betting james could point to the problem pretty quickly | 13:33 |
| kenvandine | it's in his wheelhouse | 13:33 |
| marcustomlinson | agreed | 13:33 |
| jdstrand | marcustomlinson (cc kenvandine, jamesh): do note that outside of snaps, there is a /run/user/1000/dconf dir and a ~/.config/dconf dir (I know you know that, but bear with me). does an unconfined non-snap get out of sync? | 13:34 |
| kenvandine | jdstrand: i do not think they do | 13:35 |
| jdstrand | marcustomlinson (cc kenvandine, jamesh): I ask cause while we do the symlink trick from SNAP_USER_DATA to ~/.config/dconf, we apparently aren't for XDG_RUNTIME_DIR/dconf to /run/user/1000/dconf | 13:35 |
| jdstrand | and to me that is interesting | 13:35 |
| kenvandine | jdstrand: yeah, that is interesting | 13:36 |
| marcustomlinson | jdstrand: no installing with --devmode doesn't fix it | 13:36 |
| kenvandine | it doesn't feel like confinement | 13:36 |
| jdstrand | iirc, and this is from *long* ago, the /run stuff was a perf optimization for fast reads. part of that optimization may be how it opens the file, or harrdoces a path, or something else | 13:36 |
| kenvandine | i think it has to do with monkeying with paths | 13:37 |
| * jdstrand does know otoh | 13:37 | |
| jdstrand | marcustomlinson: no, I wasn't talking about --devmode. I was talking about a non-snap | 13:37 |
| jdstrand | vs a snap that has XDG_RUNTIME_DIR, $HOME, etc set | 13:37 |
| marcustomlinson | jdstrand: a non-snap doesn't fall out of sync as said in the bug description | 13:37 |
| jdstrand | the security policy should allow access to everything, but that doesn't mean dconf is going to the right places. that is all I'm saying | 13:38 |
| kenvandine | i'm going to get jamesh to take a look | 13:40 |
| jdstrand | jamesh: please see backscroll to see if that sparks any ideas | 13:40 |
| pstolowski|afk | pedronis: great, ty | 13:40 |
| jdstrand | kenvandine: thanks :) | 13:40 |
| * zyga breaks for lunch | 13:41 | |
| zyga | see you at the standup | 13:41 |
| jdstrand | s/does know/doesn't know/ | 13:41 |
| jdstrand | kenvandine, marcustomlinson, jamesh: I gave my thoughts in the bug | 14:00 |
| kenvandine | jdstrand: thanks! | 14:00 |
| kenvandine | jdstrand: can you assign it to jamesh? I can't seem to choose people to assign the snapd bugs to | 14:01 |
| jdstrand | kenvandine: sure, done | 14:02 |
| zyga | spread running | 14:20 |
| zyga | jdstrand: I'm trying your suggestion on lxd | 14:20 |
| kenvandine | jdstrand: thanks | 14:20 |
| zyga | jdstrand: if it works I'll file a bug with the LXD team to update their templates | 14:21 |
| zyga | claudio is not on irc? | 14:22 |
| zyga | I wanted to correct my statement, the destkop has four microphones, not seven | 14:22 |
| jdstrand | pedronis: oh, 7651 got committed while I was reviewing. there are no blocking comments from me, but please consider the feedback given | 14:26 |
| marcustomlinson | jdstrand: thanks, well said | 14:27 |
| jdstrand | marcustomlinson: yw :) | 14:27 |
| pedronis | jdstrand: thanks, probably after I'm back at this point. I addressed some that were shared with zyga's here: | 14:29 |
| pedronis | https://github.com/snapcore/snapd/pull/7652/commits/3e9a7ebe67bc054e7613489b0bcbd0e1eb9713a6 | 14:30 |
| mup | PR #7652: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * <Created by pedronis> <https://github.com/snapcore/snapd/pull/7652> | 14:30 |
| pedronis | zyga: the follow ups ^ | 14:30 |
| zyga | looking | 14:30 |
| jdstrand | pedronis: sure, just wanting to make sure you saw it. not sure since it was merged by the time I finished my review if you would | 14:31 |
| mup | PR snapd#7716 opened: interfaces/lxd-support: Fix on core18 <Created by stgraber> <https://github.com/snapcore/snapd/pull/7716> | 14:32 |
| zyga | ^ simple quick review | 14:33 |
| zyga | pedronis: do you want it reviewed today? | 14:34 |
| zyga | pedronis: or is Monday ok? | 14:34 |
| pedronis | zyga: the entire PR ? that's a question for mvo | 14:35 |
| zyga | yes | 14:35 |
| zyga | the comments are good, thank you for them! | 14:35 |
| jdstrand | 7716: approved | 14:36 |
| zyga | stgraber: is that needed urgently? | 14:36 |
| zyga | I kind of wish that one liner could be a .2 in a day or two | 14:37 |
| mvo | zyga: the pr 7716? monday is ok | 14:37 |
| mup | PR #7716: interfaces/lxd-support: Fix on core18 <Simple 😃> <Created by stgraber> <https://github.com/snapcore/snapd/pull/7716> | 14:38 |
| zyga | mvo: no, the bigger one - 7652 | 14:38 |
| zyga | mvo: I reviewed 7716 arlready | 14:38 |
| mvo | zyga: monday is still ok, I will try to do a first pass myself today | 14:38 |
| pedronis | jdstrand: I don't completely understand the warn/log comments | 14:38 |
| jamesh | kenvandine, jdstrand, marcustomlinson: the settings portal is not intended for application settings: instead it is intended to share desktop settings (e.g. theme name, font choice, etc) with the sandbox | 14:42 |
| jdstrand | pedronis: I might've been a bit terse, but the idea is that if someone uses '2', should we bubble that up instead of being silent | 14:43 |
| stgraber | zyga: we'll want that in all distros ASAP, but I'm expecting it to take months to fully roll out again :( | 14:43 |
| zyga | mvo: ^ | 14:43 |
| zyga | too bad we just did a .2 | 14:43 |
| zyga | stgraber: if you want we can push that to fedora and opensuse quickly | 14:43 |
| pedronis | jdstrand: I see, but it's the machine, and the one setting is in the store | 14:44 |
| pedronis | jdstrand: it feels more confusing than helpful tbh | 14:44 |
| stgraber | zyga: those two would be nice, our main blocker last time around was centos7 | 14:44 |
| jamesh | kenvandine: The plan upstream is to not have sandboxed apps talk to dconf at all. If you have a new enough glib and set GTK_USE_PORTALS=1 it will store app settings to ~/.config/glib-2.0/settings/keyfile, which will be private to the snap | 14:44 |
| zyga | stgraber: it would be good to run the lxd test on more places | 14:44 |
| mvo | stgraber: if its really important we can do a 2.42.2 just with this | 14:44 |
| zyga | stgraber: centos7 should be fast too nowadays | 14:44 |
| stgraber | zyga: looks like thye only got >= 2.40 earlier this week | 14:44 |
| zyga | stgraber: I'll raise this with mborzecki and mvo on Monday | 14:44 |
| jdstrand | pedronis: that's fine | 14:45 |
| zyga | (mborzecki is off today) | 14:45 |
| kenvandine | jamesh: that's what i thought. can you look for a solution to the current issue in that bug report? | 14:45 |
| zyga | jamesh: I was thinking about one thing | 14:45 |
| mvo | stgraber: we don't always get quick turnaround on SRUs unfortunately, thats true | 14:45 |
| zyga | jamesh: could we have a service that steals part of the traffic so that gsettings is running through a new proxy which runs unconfined as the user | 14:46 |
| mvo | vorlon: you are mentioned in the stable-release-udpates page for today, do you think you could have a look at the snapd sru maybe? | 14:46 |
| stgraber | mvo: our own CI now records what the snapd version was on all the distros we test, so it's pretty easy for us to block work until the version we want is available on the distros we care the most about but yeah, it can be high latency and we completely missed the broken interface until right when we were about to push to edge... | 14:46 |
| jamesh | zyga: what would that offer over the keyfile solution? | 14:46 |
| * cachio lunch | 14:47 | |
| zyga | jamesh: not sure yet, I think if we had a more-less generic middleware that could do some logic and forward the call we could handle more dbus APIs sanyl | 14:47 |
| zyga | *sanely | 14:47 |
| kenvandine | confinement isn't the issue though | 14:48 |
| zyga | kenvandine: it kind of is, if we had no xdg runtime dir changes we'd be okay | 14:48 |
| zyga | but we do for confinement | 14:48 |
| zyga | and get/set api is not scoped to what a given snap can and cannot do | 14:48 |
| zyga | if we had a way to run code on each of those | 14:49 |
| jamesh | zyga: the design of dconf (and gconf before it) was to store every application's settings in a common data store. It's not obvious that we want to do that when sandboxing applications | 14:49 |
| zyga | we could do something smart | 14:49 |
| zyga | jamesh: I think that is fine as long as mmap is gone | 14:49 |
| zyga | jamesh: and as long as we can limit get/set | 14:49 |
| zyga | jamesh: (which we cannot today) | 14:49 |
| zyga | jamesh: anyway, it's just an idea, I wanted to know what you think | 14:49 |
| jamesh | zyga: there are only a small number of settings we want to share (themes, fonts, etc), but everything else can be private to the app | 14:50 |
| zyga | jamesh: that's true and that's fine | 14:50 |
| zyga | jamesh: it means it should be easy to express | 14:50 |
| jamesh | zyga: so we store application settings in a file that ends up in $SNAP_USER_DATA, and have the portal for the shared settings | 14:50 |
| jdstrand | jamesh: for what it is worth, I think the keyfile idea is very good. I also think that the concept of sometime soon(ish) bind mounting /run/user/uid/snap.... onto /run/user/uid and adding in what we want to expose, leaving XDG_RUNTIME_DIR as /run/user/uid, is going to solve a lot of things | 14:51 |
| jamesh | no need for a config access daemon with ACL support | 14:51 |
| zyga | jamesh: sure, but again, this is just an excuse to try out an idea in our heads: we could use this for gsettings, for network-manager and perhaps for more dbus things later on | 14:51 |
| jdstrand | zyga: we've discussed a dbus proxy in the past, I don't think we have a compelling use case that justifies the dev resources and risk at this point | 14:52 |
| kenvandine | jamesh: i think we should add GTK_USE_PORTALS=1 to the WIP gnome-3-34 snapcraft extension | 14:53 |
| jdstrand | we have a lot with just apparmor without having to look at member data | 14:53 |
| jdstrand | but, yes, it we really required member data mediation, we would have to come up with something | 14:54 |
| zyga | jdstrand: odd | 14:55 |
| zyga | I didn't have /var/snap/lxd/common/lxd/security/apparmor/profiles/lxd-my-ubuntu | 14:55 |
| zyga | 14:55 | |
| zyga | in the test | 14:55 |
| * zyga tries 16.04 | 14:55 | |
| zyga | I was running on 18.04 | 14:56 |
| zyga | no apparmor profile created by lxd? | 14:56 |
| jamesh | zyga: there is work upstream to add connection filtering to dbus-daemon itself. I'm not sure of the status, but I did participate in the bug reports to make sure it wouldn't be too impossible to use with snaps | 14:56 |
| zyga | mmm, I recall some of this | 14:57 |
| zyga | that's good | 14:57 |
| zyga | well, just a thought | 14:57 |
| jamesh | zyga: the basic idea was to ask dbus-daemon to create a new listening socket, and tag all connections made through that socket | 14:57 |
| jamesh | a policy would be applied that would limit the bus names those connections could see, and what messages they could send and receive | 14:58 |
| pedronis | mvo: is 7701 merged ? | 15:00 |
| zyga | pedronis: doesn't seem to be | 15:01 |
| jdstrand | jamesh: thanks for keeping an eye on that btw :) it would be a bit unfortunate to have both it and apparmor in place and deciding when/how to use what, etc, etc, but yes, what you described is something we can work with | 15:07 |
| zyga | hmm | 15:08 |
| zyga | stgraber: where does lxd store apparmor profiles? | 15:08 |
| stgraber | zyga: /var/snap/lxd/common/lxd/security/apparmor | 15:08 |
| zyga | oh, I'm silly | 15:08 |
| zyga | thanks, it's all there now | 15:08 |
| zyga | ETOOMANYNAMESPACES | 15:08 |
| zyga | thank you! | 15:12 |
| pedronis | pstolowski|afk: gave a couple of comments in 7706 | 15:14 |
| mvo | pedronis: 7701 needs a second review - I guess it could be merged with one given that its mostly test updates | 15:16 |
| zyga | mvo: go for it | 15:16 |
| mvo | zyga: go for the merge? | 15:16 |
| zyga | yes | 15:16 |
| pedronis | mvo: it would give me a chance for me to try to review the next one | 15:16 |
| mvo | pedronis: +1 | 15:16 |
| * zyga strongly believes in trust and asking for forgiveness more than permission | 15:17 | |
| mup | PR snapd#7701 closed: overlord: add kernel rollback accross reboots manager test and fixes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7701> | 15:17 |
| mvo | pedronis: 7682 is now ready for review as well | 15:18 |
| pedronis | mvo: taking a break and after I'll see where I'm at on the things to finish stuff | 15:20 |
| pedronis | s/stuff/list/ | 15:20 |
| mvo | pedronis: sure, thank you! | 15:20 |
| mvo | Chipaca: can 7669 be merged? has two +1 | 15:23 |
| zyga | jdstrand: FYI https://github.com/snapcore/snapd/pull/7547#issuecomment-548788685 | 15:24 |
| Chipaca | mvo: 'needs samuele review' :) | 15:24 |
| mup | PR #7547: many: use a dedicated named cgroup hierarchy for tracking <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/7547> | 15:24 |
| pedronis | mvo: actually it should be closed, I think Chipaca's prefers next one | 15:26 |
| pedronis | but there is a question answered | 15:26 |
| pedronis | that related whether we should pick one or the other | 15:26 |
| * zyga tries another approach | 15:26 | |
| Chipaca | yes, i slightly prefer 7670 | 15:26 |
| Chipaca | oh, answered? | 15:27 |
| * Chipaca looks | 15:27 | |
| pedronis | sorry, unanswered | 15:27 |
| pedronis | Chipaca: is this one: https://github.com/snapcore/snapd/pull/7680#discussion_r339552372 | 15:27 |
| mup | PR #7680: daemon: parse and reject invalid channels in snap ops <Channels 🏷️> <Simple 😃> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7680> | 15:27 |
| Chipaca | ah! | 15:28 |
| Chipaca | pedronis: answered! closing 7669 | 15:28 |
| Chipaca | and adding comments to 7670 to land it | 15:28 |
| Chipaca | thanks | 15:28 |
| Chipaca | missed these somehow | 15:29 |
| Chipaca | bah, i know how -- inbox 0 it isn't | 15:29 |
| pedronis | it's ok, I just thought your were pausing these and get back later | 15:29 |
| pedronis | they have some comments from me | 15:29 |
| jdstrand | zyga: :( | 15:30 |
| pedronis | Chipaca: yea, please close 7669 | 15:30 |
| mup | PR snapd#7302 closed: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7302> | 15:33 |
| jdstrand | zyga: but boy, glad we thought to test before rolling out :) | 15:34 |
| zyga | yes | 15:34 |
| zyga | thank you! | 15:34 |
| zyga | mvo: this remained unaddressed https://github.com/snapcore/snapd/pull/7302#discussion_r341178203 | 15:34 |
| mup | PR #7302: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7302> | 15:34 |
| zyga | mvo: but I'll work with maciek to make it better | 15:34 |
| mvo | zyga: ok | 15:36 |
| mvo | zyga: yeah, its fine to enable during 2.43 lifetime in edge at least | 15:36 |
| mvo | zyga: topic for monday and a detail in some way! thanks for the suggestion though | 15:36 |
| zyga | stgraber: question about mount in lxd | 15:38 |
| zyga | stgraber: lxd performs syscall interception for it now? | 15:38 |
| zyga | stgraber: is there some logic that allows systemd inside the container to mount cgroups? | 15:38 |
| stgraber | It will be able to in 3.19 | 15:39 |
| zyga | stgraber: or are cgroups mounted in some other way | 15:39 |
| zyga | stgraber: the context is this: | 15:39 |
| zyga | stgraber: snapd needs to mount a new cgroup hierarchy | 15:39 |
| zyga | stgraber: a name=snapd one, with no controllers | 15:39 |
| mvo | pedronis: 7438 is probably now also unblocked, but I leave this to you, your review list is very long so its fine if it gets dropped | 15:39 |
| stgraber | Right now we don't intercept anything | 15:39 |
| zyga | stgraber: I see | 15:39 |
| zyga | stgraber: I will explore more, I'm getting EPERM now but I'll check more why | 15:39 |
| stgraber | It's just normal userns+mntns and the kernel allowing you mounting safe virtual filesystems | 15:39 |
| pedronis | mvo: yea, don't think I will get to that one | 15:40 |
| zyga | stgraber: does that include cgroups? | 15:40 |
| stgraber | cgroupfs is definitely one of those | 15:40 |
| zyga | stgraber: I'm not experienced with userns | 15:40 |
| zyga | ok | 15:40 |
| zyga | I see, thanks, I'll explore more interactively | 15:40 |
| stgraber | systemd in the container handles mounting it so it has to be unprivileged | 15:40 |
| * zyga is making progress | 15:44 | |
| mup | PR snapd#7669 closed: snap, cmd/snap: support (but warn) deprecated multi-slash channel <Channels 🏷️> <Needs Samuele review> <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/7669> | 15:44 |
| pedronis | mvo: Chipaca: there is no progress bar in snap download ? | 15:45 |
| Chipaca | pedronis: there is | 15:45 |
| pedronis | I'm not seeing it | 15:45 |
| pedronis | or it's only when is not direct ? | 15:45 |
| Chipaca | pedronis: what are you running | 15:45 |
| pedronis | I'm running direct | 15:45 |
| pedronis | I'm running mvo 7624 | 15:46 |
| mvo | pedronis: try a bigger snap | 15:46 |
| mvo | pedronis: maybe core? | 15:46 |
| mvo | pedronis: I did not see it for small snaps like test-snapd-tools myself | 15:46 |
| mvo | pedronis: and then I did not implment one in the first iteration because I was blissfully unware of it :/ | 15:46 |
| Chipaca | ah you might not see it if there is no progress before it's done :) | 15:47 |
| ijohnson | hey folks o/ | 15:49 |
| zyga | ijohnson: hey | 15:49 |
| ijohnson | lots happening this morning it seems :-) anything in particular I can help with or review, etc. ? | 15:49 |
| zyga | ijohnson: I think reviews are in demand | 15:50 |
| zyga | ijohnson: mvo can point you the way | 15:50 |
| ijohnson | it would appear so :-) | 15:50 |
| mvo | ijohnson: 7652, 7696 would be good and 7665 | 15:52 |
| ijohnson | mvo ack | 15:52 |
| mvo | ijohnson: probably more, but this should keep you busy :) | 15:52 |
| mvo | ijohnson: and *thank you* | 15:52 |
| ijohnson | happy to help :-) (also good to take a break from staring at why the chromium snap is slow) | 15:53 |
| ogra | zyga, ubuntu-core-meta is the metapackage generated from the seed that is defining the package list ... should be owned by foundations nowadays (sorry, only just returned from IoT worldcongress and wasnt able to check IRC) | 15:54 |
| ogra | zyga, i think sil2100 or vorlon own it now | 15:54 |
| zyga | ogra: ah, so it's a real thing | 15:57 |
| zyga | thank you | 15:57 |
| pedronis | mvo: added a couple of comments to 7624, I removed the needs my review, I think is far along enough and shouldn't be blocked, but it will need a revisit at some point | 15:59 |
| mvo | pedronis: cool, thank you! | 15:59 |
| pedronis | mvo: the fallback to direct without sudo or auth works | 16:00 |
| pedronis | mvo: as John said a bit more manual testing is probably in order | 16:00 |
| mvo | pedronis: indeed, I also want to add some more unit tests | 16:00 |
| * zyga breaks | 16:09 | |
| mup | PR snapd#7717 opened: tests/docker-smoke: add minimal docker smoke test <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7717> | 16:23 |
| ogra | zyga, well, the seeds surely are since we are using the osfficial build system now, not sure if the metapackage is actually needed, the build of core18 might just use the task which wouldnt require a metapackage anymore | 16:26 |
| ogra | s/core18/core18 and onwards/ | 16:27 |
| === grumboo is now known as grumble | ||
| Chipaca | pedronis: #7696 LGTM | 16:52 |
| mup | PR #7696: cmd/snap,image: initial support for Core 20 in prepare-image with test <Created by pedronis> <https://github.com/snapcore/snapd/pull/7696> | 16:52 |
| pedronis | Chipaca: thanks, it has a bug though | 16:53 |
| Chipaca | pedronis: I saw, about classic? | 16:53 |
| pedronis | yes | 16:53 |
| Chipaca | pedronis: hm | 16:53 |
| pedronis | because of the moving of setting up the directory | 16:53 |
| pedronis | from the cmd_* to the image | 16:53 |
| pedronis | it got lost, and the unit test didn't notice | 16:53 |
| pedronis | I'll try to push a fix later tonight | 16:54 |
| pedronis | otherwise you or mvo should fix it next week | 16:54 |
| Chipaca | pedronis: no probs | 16:54 |
| Chipaca | pedronis: lots of spread tests caught it instead :) | 16:54 |
| pedronis | Chipaca: basically for core we create PrepareDir/image and use it as root | 16:54 |
| pedronis | that's correct | 16:54 |
| pedronis | Chipaca: for classic PrepareDir is really the root dir already | 16:55 |
| pedronis | so no /image should be added there | 16:55 |
| * Chipaca nods | 16:55 | |
| pedronis | and boot stuff is not relevant for classic anyway | 16:55 |
| pedronis | also to be clear we don't have uc20 model/classic support yet | 16:56 |
| pedronis | classic is uc 18/16 style seeds | 16:56 |
| pedronis | for now | 16:56 |
| diddledan | has snapd moved out of the core snap now? | 16:59 |
| diddledan | I installed a fresh ubuntu vm and then a snap that depends on core18 and I received snapd via the snapd snap instead of the core snap via autoinstall | 16:59 |
| pedronis | diddledan: yes for fresh installs | 17:01 |
| diddledan | aah, only fresh installs. gotcha | 17:01 |
| Chipaca | diddledan: and only if the first snap you install doesn't use core :) | 17:12 |
| pedronis | diddledan: we do plan to migrate old classic system (like at some point we migrated from ubuntu-core -> core), but it isn't enabled yet | 17:16 |
| Chipaca | ijohnson: the spread tests on that pr also failed because if the image/ thing samuele mentioned, fwiw | 17:19 |
| pedronis | ? | 17:19 |
| pedronis | only my PR should be affected | 17:20 |
| pedronis | now I'm confused | 17:20 |
| Chipaca | pedronis: yep, talking about that | 17:20 |
| pedronis | ah | 17:20 |
| Chipaca | pedronis: ijohnson said, on your pr, “looks like the spread tests failed from some store 403s :-/” | 17:20 |
| ijohnson | Oh sorry I just saw that like 4 tests failed on 403s and assume the rest of them were from similar problems | 17:21 |
| Chipaca | pedronis: so i thought before he restarts them maybe i should point out that at least some of them are genuine (enough that i didn't notice the 403 ones he mentions) | 17:21 |
| ijohnson | I didn't restart them | 17:21 |
| Chipaca | ijohnson: \o/ :) | 17:21 |
| ijohnson | I assumed y'all wanted to look | 17:21 |
| pedronis | yea, I will fix later tonight | 17:21 |
| ijohnson | Cool beans | 17:21 |
| pedronis | Chipaca: anything you need my input on? | 17:21 |
| Chipaca | pedronis: oh, just everything | 17:22 |
| Chipaca | pedronis: :-D | 17:22 |
| Chipaca | pedronis: seriously, no | 17:22 |
| pedronis | jdstrand: thanks you for reviewing 7652 | 17:31 |
| pedronis | Chipaca: ijohnson: I pushed a fix to 7696, spread should tell us if I got it right, but please double check it makes sense | 17:44 |
| Chipaca | will do | 17:44 |
| ijohnson | Ack | 17:44 |
| * ijohnson lunches | 17:45 | |
| jdstrand | pedronis: yw | 17:47 |
| pedronis | jdstrand: I might try to still apply the rest of your previous PR feedback and this one today | 17:49 |
| * pedronis dinner | 17:50 | |
| Chipaca | pedronis: // Core 16/20, writing for the writeable partion | 17:50 |
| Chipaca | 16/18* | 17:50 |
| Chipaca | :) | 17:51 |
| Chipaca | pedronis: buen provecho, and have a lovely holiday | 17:51 |
| pedronis | Chipaca: oops | 17:51 |
| Chipaca | pedronis: :) | 17:51 |
| mup | PR snapcraft#2787 closed: Safe grade <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2787> | 17:57 |
| mup | PR snapcraft#2788 opened: Release changelog for 3.9.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2788> | 18:00 |
| * zyga returns | 18:26 | |
| vorlon | ogra, zyga: https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-meta/+bug/1850538 - what is referencing ubuntu-core-meta? | 18:49 |
| mup | Bug #1850538: Please remove ubuntu-core-meta from the archive <ubuntu-core-meta (Ubuntu):Fix Released> <https://launchpad.net/bugs/1850538> | 18:49 |
| jdstrand | pedronis: hey, I need to update the review-tools to understand (but not do anything with) slots-per-plug and plugs-per-slot and wanted to make sure about something. | 18:55 |
| jdstrand | pedronis: say the base decl has: | 18:55 |
| jdstrand | slots: | 18:55 |
| jdstrand | foo: | 18:55 |
| jdstrand | allow-connection: false | 18:55 |
| jdstrand | pe | 18:55 |
| jdstrand | pedronis: and the snap decl has: | 18:55 |
| jdstrand | slots: | 18:56 |
| jdstrand | foo: | 18:56 |
| jdstrand | allow-connection: | 18:56 |
| jdstrand | slots-per-plug: 1 | 18:56 |
| pedronis | jdstrand: first of all you could warn or prohibit initially anything but | 18:57 |
| pedronis | allow-auto-connection: | 18:57 |
| pedronis | slots-per-plugs: * | 18:57 |
| pedronis | because anything else will just end up being like the default | 18:57 |
| pedronis | so it's confusing/distracting | 18:57 |
| pedronis | but your call | 18:57 |
| jdstrand | pedronis: sure | 18:57 |
| pedronis | what's the question here? | 18:57 |
| pedronis | that rule in the snap decl | 18:57 |
| pedronis | is like allow-connection: true | 18:58 |
| jdstrand | pedronis: yes, that is exactly what I thought and wanted to confirm | 18:58 |
| pedronis | and slot-per-plug will behind the scene be normalize away back to * | 18:58 |
| pedronis | in snapd | 18:59 |
| pedronis | for this specific case | 18:59 |
| jdstrand | right. in the review-tools, I want the same evaluation rules as before. I'm only checking arity for syntax/etc | 18:59 |
| jdstrand | but due to evaluation rules, in my scenario, I just wanted to double check the intent was allow-connection: true with the above | 19:00 |
| pedronis | yes | 19:00 |
| jdstrand | pedronis: ok, thanks. if you haven't started yet, enjoy your weekend :) | 19:00 |
| jdstrand | and week! :) | 19:00 |
| pedronis | thanks | 19:00 |
| pedronis | still shepharding some last bits of PRs that I can | 19:01 |
| * jdstrand nods | 19:01 | |
| pedronis | jdstrand: I applied your feedback (except some bits that were more open ended) | 19:01 |
| jdstrand | cool, thanks :) | 19:03 |
| * cachio afk | 19:05 | |
| ogra | vorlon, i think that was a core16 bug | 19:24 |
| vorlon | ok, core+core16 still referenced ubuntu-core-meta yes | 19:24 |
| ogra | https://launchpad.net/bugs/1646144 | 19:25 |
| mup | Bug #1646144: ACLs to devices need to be supported in core <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Fix Released by ogra> <ubuntu-core-meta (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1646144> | 19:25 |
| zyga | vorlon: I don't know what referenced it, I just noticed it being mentioned here | 19:25 |
| ogra | zyga, ah, i thought you were referring to the line above your ping | 19:25 |
| ogra | (which was that bug it seems) | 19:25 |
| cyphermox | ok, so false alarm? | 19:26 |
| ogra | alarm ? | 19:26 |
| ogra | there was no alarm, everything is good :) | 19:26 |
| cyphermox | ok; just making sure ;) | 19:27 |
| === heather is now known as hellsworth | ||
| mup | PR snapcraft#2789 opened: tests: update the push and release tests for staging <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2789> | 19:57 |
| mup | PR snapcraft#2790 opened: tests: skip spread tests for rust on s390x <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2790> | 20:24 |
| * zyga breaks | 20:39 | |
| zyga | no progress | 20:39 |
| ads20000 | jdstrand My journal log is completely flooded with GNOME System Monitor snap denials on Ubuntu 19.04, what interface do I need to enable? `Nov 01 22:29:43 adam-thinkpad-t430 audit[11527]: AVC apparmor="DENIED" operation="open" profile="snap.gnome-system-monitor.gnome-system-monitor" name="/run/systemd/sessions/2"` | 22:31 |
| ads20000 | I'm pretty sure this is System Monitor out-of-the-box (well, upgraded from previous Ubuntu versions) so perhaps a bit worrying that this has happened out-of-the-box? | 22:32 |
| jdstrand | ads20000: yeah, that is on the list for policy updates PR queued for next week | 22:32 |
| ads20000 | jdstrand: great, thanks! :) | 22:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!