[01:51] Bug #1671266 opened: rfkill should be included in the core snap === JanC_ is now known as JanC [07:19] PR snapd#7690 closed: cmd/snap: make completion skip hidden commands (unless overridden) [08:21] PR snapd#7714 opened: overlord: refactor mgrsSuite and extract kernelSuite [08:30] pedronis_: a review for 7682 would be great. then I could use the helpers there for the base->bsae undo tests [08:31] pedronis_: actually - 7701 (smaller) is enough :) === pedronis_ is now known as pedronis [08:32] mvo: hi, yes, I wanted to ask which one of those I should review first? because the newer was merged into the older? [08:38] pedronis: yeah, the newer one is probably the best starting point [08:38] pedronis: so 7701 is probably the best start, its relatively small [08:42] mvo: I'll look now, I was trying to give input on some older PRs that were stuck === alan_g is now known as alan_g_ [08:54] good morning [08:54] hey mvo, pedronis [08:54] how are you doing this frosty morning? [08:54] hey zyga ! doing well [08:55] mvo: I reviewed 7701 [08:56] pedronis: thank you! [08:56] zyga: hi, did you see my question in #7700 ? [08:56] not yet [08:56] PR snapd#7715 opened: overlord: add base->base remodel undo tests and fixe [08:56] PR #7700: many: wait while inhibition file is present [08:56] 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] pedronis: thanks a bunch for the review! [08:57] @pedronis I yeah, I thought about this and I think it may need to be in /var after all [08:57] @pedronis I got into a longer exploration of the problem of locking [08:57] ok [08:57] @pedronis I tried to document that in the doc but I need to remove redundant parts and make the whole thing comprehensible [08:59] mvo: this test seems also to have that kind of name: TestInstallCoreSnapUpdatesBootloaderAndSplitsAcrossRestart [09:02] wow that's a long name :) [09:03] pedronis: yeah, fixing all of the UpdatesBootloader ones now [09:03] zyga: its a long test! needs a long name :) [09:03] mvo: ChapterOne [09:03] ;-) [09:09] zyga: *if* you work today a review for 7651 would be great [09:09] sure, let me start with that [09:15] * zyga reads the spec first [09:25] morning [09:26] hey pawel [09:35] pedronis: i'm changing PreseedMode to func, no strong opinion either way [09:40] 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] PR #7675: release: preseed mode flag [09:40] pstolowski: gladly, just after the current one [09:43] mvo: there's a problem with the download via snapd stuff [09:43] pedronis: oh? [09:43] mvo: you get polkit prompts [09:43] which I'm not sure we want [09:43] for this [09:44] oh? [09:44] pedronis: oh, meh, yes. downlaod is an auth endpoint :/ [09:44] because of snapd asking polkit? [09:44] pedronis: that sounds like we need some flag to prevent interaction [09:44] zyga: yeah [09:44] pedronis: yesterday I suggested landing the current download but with the defaults flipped [09:45] mvo: well, we might need to change the auth rules for the /download endpoint [09:45] ie having direct being the default, with a hidden --indirect flag [09:45] Issue core18#142 opened: Stuck with blank screen on snap-core 18 Raspi 3 B+ install [09:46] Chipaca: just to progress? because that's not the final goal [09:47] pedronis: just to progress, yes [09:48] pedronis: otherwise i see this being an open pr for quite some time, across vancouver [09:48] 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] PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> [09:48] Chipaca: isn't just a matter to remove this from download ? PolkitOK: "io.snapcraft.snapd.manage", [09:49] jamesh: heh, i'm terrible with names, but let me respond over there [09:49] I don't think it's actually a mgmt action (in those terms) anyway [09:49] mvo: ^ [09:50] pedronis: hm, good point, that is probably fine [09:50] Chipaca: beside better tests (I pushed two prs recently) and resume-partial is there anything missing from the snap download via snapd? [09:52] mvo: also ./snap0 known --remote account account-id=dell gives me nothing (no error either), but --direct works [09:52] mvo: something is off [09:52] with known too [09:53] pedronis: uh, let me debug this [09:53] mvo: you pushed a 2.42.1 to edge? [09:53] that will roolback people [09:54] pedronis: I did not, that was our stupid machinery not being updated :( [09:54] pedronis: let me fix this, but it sounds like one of the auto-merge/auto-build bits failed [09:54] so my snapd doesn't have remote on /assertions [09:54] I suppose [09:55] mvo: more real-life testing? [09:55] Chipaca: good point :) [09:56] mvo: i'd like to have a whole .N of us using it to help us find the bugs [09:57] but I'd also like people to stop being horrible to each other, and here we are [09:57] Chipaca: we will have the entire 2.43 for people to test :) [09:58] pedronis: I can reproduce the dell issue, debugging now [09:58] Chipaca: wdyt about removing pollkitOk from /v2/download ? [09:58] mvo: nah [09:58] mvo: just tell it to not do interactive [09:59] * Chipaca looks for how to do that [09:59] mvo: client.Config{Interactive: false} [09:59] mvo: turns off polkit for that request [10:00] bah, for any request that client emits [10:00] Chipaca: \o/ [10:00] mvo: you owe jamesh a beverage [10:01] 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] mvo: ok [10:02] mvo: the Client instance set up by the snap command sets Interactive based on whether stdin is a tty [10:04] in general it is going to do the right thing for non-interactive scripts [10:04] mvo: jamesh: cmd/snap/main's mkClient could take a ClientConfig to override that though [10:04] yea, for download I think the regression is still annoying even interactively [10:05] we are not starting from scratch here [10:05] Chipaca: presumably you could just do client.Interactive = false within the command [10:05] I don't think anything would be using the client after the command takes control of execution [10:06] degville: could / should we add a list of supported architectures to https://snapcraft.io/docs/architectures ? [10:06] Chipaca: yes, I think so - I've actually got a list in my edit, taken from build.snapcrraft.io. [10:07] degville: i was just looking for that list :-) [10:07] there's somebody trying to build a MIPS core image [10:07] seems like they've spent some time on it already [10:07] (not very effectively) [10:09] Chipaca: these are the ones I've got - s390x, ppc64el, arm64, armhf, amd64, i386. [10:09] 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:10] mvo: can we nuke the vendor sync repo and use github actions? [10:10] 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] zyga: maybe, that would certainly be nice [10:11] mvo: yeah, worth trying at least [10:14] zyga: yes! unfortunately not today [10:14] nope [10:14] I don't even know if actions are out of beta yet [10:14] I have access on my repos but I was given access ahead of general release a while ago [10:15] mvo: ok, at least this bit is understood, yes I got edge with 2.42.1 here too [10:15] github actions are so much nicer to deal with than travis [10:16] I've been using them on some of my personal repos too [10:16] jamesh: that's good indicator to use them [10:16] thanks! [10:17] zyga: here were my initial thoughts on the system: https://blogs.gnome.org/jamesh/2019/09/06/exploring-github-actions/ [10:21] jamesh: I answered to John comment in #7589 [10:21] PR #7589: cmd/snap: add ability to register "snap internal" commands <⛔ Blocked> [10:21] I think we do have a path forward [10:23] 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] PR #7238: usersession: add systemd user instance service control to user session agent [10:23] jamesh: yea, I'll do a pass again on it today, then either way it will need a re-review by jdstrand [10:23] jamesh: btw I'm off next week [10:24] okay. Thanks [10:24] jamesh: the fwupd one is also unblocked, it just needs a 2nd review and to get green [10:28] pedronis, Chipaca I updated the code in 7624 to not have a polkit prompt anymore (set interactive to false) [11:11] 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] do about them [11:12] pstolowski: sorry, what is the problem? that they are *16 specific? [11:13] pstolowski: did you forget to add a file? [11:14] this diff is strange https://github.com/snapcore/snapd/pull/7705/commits/fdd697d3b89cab1101b8adbd04f082d32b3aa27e [11:14] PR #7705: [WIP] o/devicestate: handle preseed in firstboot [11:15] pedronis: yes i forgot the file in that one commit. look at the next commit or complete diff [11:19] pstolowski: so makeSeedChanges has actual differences [11:19] pedronis: yes, but minor, different checkTasks* used [11:20] you can make a firstBoot16BaseTest with seedtest and those two? no? [11:20] I mean with seedtest.TestingSeed16 [11:21] if you want [11:22] makeCoreSnap could be a global helper that takes a *seedtest.TestingSeed16 [11:22] makeCoreSnaps [11:23] pedronis: yes, i can do something like this [11:25] pstolowski: I don't strong opinions on this, need to try a bit what is readable in the end [11:25] I wouldn't do is chain them though firstBoot16BaseTest shouldn't contain firstBootBaseTest [11:27] and maybe firstBoot16BaseTest is not the best name for that one [11:31] pstolowski: otoh all the new tests have a slightly different style that makes something like makeCoreSnaps a bit less necessary [11:31] so maybe we should change to that at some point [11:31] pedronis: i can also postpone these changes for a followup maybe (when you're back)? [11:33] Chipaca: if you feel like reviewing, 7701 would be a nice one [11:40] pedronis: will you find a moment today to take a look at #7706? [11:40] PR #7706: overlord/snapstate: install task edges [11:41] mvo: reviewing is all there is [11:41] mvo: but first more coffee [11:41] maybe a bite to eat as well [11:42] jamesh, pedronis: re 7238, it's on my list [11:42] hey jdstrand :) [11:42] hey zyga :) [11:42] i'm going afk for now. i'll check later if my #7675 can land and rebase the rest if needed [11:42] PR #7675: release: preseed mode flag [11:42] o/ === pstolowski is now known as pstolowski|afk [11:47] Chipaca: sounds like a great plan! [11:47] * mvo contemplates food as well [11:51] PR snapd#7708 closed: parts/plugins: don't xz-compress a deb we're going to discard [12:02] pstolowski|afk: sorry, needed to run to have lunch [12:21] pedronis: https://github.com/snapcore/snapd/pull/7651#pullrequestreview-310392093 [12:21] PR #7651: asserts: support and parsing for slots-per-plug/plugs-per-slot [12:26] pstolowski|afk: looking at your PR now [12:35] pstolowski|afk: https://github.com/snapcore/snapd/pull/7675#pullrequestreview-310427961 (though not what you may have expected) [12:35] PR #7675: release: preseed mode flag [12:36] * zyga breaks for quick tea [12:36] it's soooo cold at home today [13:17] jdstrand: https://github.com/snapcore/snapd/pull/7659 should be ready now [13:18] jdstrand: it's just the extra feature flag you asked for [13:18] PR #7659: snap/snapenv: preserve XDG_RUNTIME_DIR for classic confinement [13:18] jdstrand: I'm looking at expanding spread test to cover that, just looking where to put it [13:18] zyga: ok, thanks [13:19] jdstrand, zyga: any thoughts on marcustomlinson's findings on bug 1661626 ? [13:19] Bug #1661626: GSettings/dconf reports incorrect values on setting change under confinement [13:20] kenvandine: no, it seems like a mess now :/ [13:20] kenvandine: feels like gsettings really needs a portal / proxy [13:20] kenvandine: do you think there's a simple solution for all of this? [13:21] there is a settings proxy, not sure the state of it though [13:21] s/proxy/portal [13:22] https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Settings.xml [13:22] kenvandine: how can we use this? [13:22] I mean [13:22] 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:23] but that seems to be read access to the host settings [13:23] does it need gtk change to software to use that vs doing what they needed before [13:23] or is this some transparent proxy where we hack around and inject it and software is unmodified [13:23] i don't think it helps for an app with it's own schema [13:23] but that was for per app settings, not global settings now that I type that [13:23] the per app is the issue here, at least this bug [13:24] if i'm reading it right [13:24] bare in mind that set and get work just fine, it's just the monitor that is broke [13:24] marcustomlinson: right? this is an app not getting change notificiations for it's own settings? [13:25] marcustomlinson: who sends the signal? [13:25] yeah, it seems to be all related to the XDG_RUNTIME_DIR [13:25] zyga: shrug [13:25] I'm not experienced in the desktop stack [13:25] I cannot help without someone who knows how this works [13:25] i think the app's process [13:25] would it help if we had not modified xdg runtime dir? [13:25] zyga: i think so [13:26] maybe this is a bug in the helpers? [13:26] sounds like someone needs to deep dive into this [13:26] but, we can probably just add another symlink for now from $XDG_RUNTIME_DIR/dconf -> ../dconf [13:26] I really don't know [13:26] jdstrand: I did try that, didn't work [13:26] my meta observation is as follows: [13:27] jamesh: are you by chance still around? [13:27] marcustomlinson: oh? did dconf remove it? [13:27] 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] jdstrand: no didn't remove it, perhaps permission issue not sure [13:27] it would teach the snapd team more a [13:27] and it would help in fixing "what happens" part of the problem, because we have many layers [13:28] marcustomlinson: a snap that plugs gsettings can acces /run/user/*/dconf, so a symlink to it should be fine [13:28] jdstrand: well it wasn't :D [13:28] marcustomlinson: ok... that isn't a lot of detail ;) [13:29] jdstrand: I asked for assistance [13:29] not for ears to hear the solution [13:29] 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:30] 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] 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] I don't have a lot of detail [13:30] PR snapd#7651 closed: asserts: support and parsing for slots-per-plug/plugs-per-slot [13:31] i think we probably need jamesh [13:31] zyga: yes which is what I said in my comment [13:31] 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] jdstrand: nah, i think we need jamesh to look at it [13:31] PR snapd#7695 closed: o/devicestate: the basics of Core 20 firstboot support with test [13:32] kenvandine: I'm happy to press on with it if you like [13:32] pstolowski|afk: #7695 has landed which should help with your PR [13:32] I just saw a rabbit hole approaching and thought I'd reach out first [13:32] PR #7695: o/devicestate: the basics of Core 20 firstboot support with test [13:33] marcustomlinson: i'm betting james could point to the problem pretty quickly [13:33] it's in his wheelhouse [13:33] agreed [13:34] 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:35] jdstrand: i do not think they do [13:35] 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] and to me that is interesting [13:36] jdstrand: yeah, that is interesting [13:36] jdstrand: no installing with --devmode doesn't fix it [13:36] it doesn't feel like confinement [13:36] 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:37] i think it has to do with monkeying with paths [13:37] * jdstrand does know otoh [13:37] marcustomlinson: no, I wasn't talking about --devmode. I was talking about a non-snap [13:37] vs a snap that has XDG_RUNTIME_DIR, $HOME, etc set [13:37] jdstrand: a non-snap doesn't fall out of sync as said in the bug description [13:38] 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:40] i'm going to get jamesh to take a look [13:40] jamesh: please see backscroll to see if that sparks any ideas [13:40] pedronis: great, ty [13:40] kenvandine: thanks :) [13:41] * zyga breaks for lunch [13:41] see you at the standup [13:41] s/does know/doesn't know/ [14:00] kenvandine, marcustomlinson, jamesh: I gave my thoughts in the bug [14:00] jdstrand: thanks! [14:01] jdstrand: can you assign it to jamesh? I can't seem to choose people to assign the snapd bugs to [14:02] kenvandine: sure, done [14:20] spread running [14:20] jdstrand: I'm trying your suggestion on lxd [14:20] jdstrand: thanks [14:21] jdstrand: if it works I'll file a bug with the LXD team to update their templates [14:22] claudio is not on irc? [14:22] I wanted to correct my statement, the destkop has four microphones, not seven [14:26] pedronis: oh, 7651 got committed while I was reviewing. there are no blocking comments from me, but please consider the feedback given [14:27] jdstrand: thanks, well said [14:27] marcustomlinson: yw :) [14:29] jdstrand: thanks, probably after I'm back at this point. I addressed some that were shared with zyga's here: [14:30] https://github.com/snapcore/snapd/pull/7652/commits/3e9a7ebe67bc054e7613489b0bcbd0e1eb9713a6 [14:30] PR #7652: o/ifacestate,interfaces,interfaces/policy: slots-for-plug: * [14:30] zyga: the follow ups ^ [14:30] looking [14:31] 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:32] PR snapd#7716 opened: interfaces/lxd-support: Fix on core18 [14:33] ^ simple quick review [14:34] pedronis: do you want it reviewed today? [14:34] pedronis: or is Monday ok? [14:35] zyga: the entire PR ? that's a question for mvo [14:35] yes [14:35] the comments are good, thank you for them! [14:36] 7716: approved [14:36] stgraber: is that needed urgently? [14:37] I kind of wish that one liner could be a .2 in a day or two [14:37] zyga: the pr 7716? monday is ok [14:38] PR #7716: interfaces/lxd-support: Fix on core18 [14:38] mvo: no, the bigger one - 7652 [14:38] mvo: I reviewed 7716 arlready [14:38] zyga: monday is still ok, I will try to do a first pass myself today [14:38] jdstrand: I don't completely understand the warn/log comments [14:42] 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:43] 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] zyga: we'll want that in all distros ASAP, but I'm expecting it to take months to fully roll out again :( [14:43] mvo: ^ [14:43] too bad we just did a .2 [14:43] stgraber: if you want we can push that to fedora and opensuse quickly [14:44] jdstrand: I see, but it's the machine, and the one setting is in the store [14:44] jdstrand: it feels more confusing than helpful tbh [14:44] zyga: those two would be nice, our main blocker last time around was centos7 [14:44] 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] stgraber: it would be good to run the lxd test on more places [14:44] stgraber: if its really important we can do a 2.42.2 just with this [14:44] stgraber: centos7 should be fast too nowadays [14:44] zyga: looks like thye only got >= 2.40 earlier this week [14:44] stgraber: I'll raise this with mborzecki and mvo on Monday [14:45] pedronis: that's fine [14:45] (mborzecki is off today) [14:45] jamesh: that's what i thought. can you look for a solution to the current issue in that bug report? [14:45] jamesh: I was thinking about one thing [14:45] stgraber: we don't always get quick turnaround on SRUs unfortunately, thats true [14:46] 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] 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] 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] zyga: what would that offer over the keyfile solution? [14:47] * cachio lunch [14:47] 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] *sanely [14:48] confinement isn't the issue though [14:48] kenvandine: it kind of is, if we had no xdg runtime dir changes we'd be okay [14:48] but we do for confinement [14:48] and get/set api is not scoped to what a given snap can and cannot do [14:49] if we had a way to run code on each of those [14:49] 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] we could do something smart [14:49] jamesh: I think that is fine as long as mmap is gone [14:49] jamesh: and as long as we can limit get/set [14:49] jamesh: (which we cannot today) [14:49] jamesh: anyway, it's just an idea, I wanted to know what you think [14:50] 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] jamesh: that's true and that's fine [14:50] jamesh: it means it should be easy to express [14:50] 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:51] 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]