=== wgrant_ is now known as wgrant [00:33] Anyone here running the krita snap? === chihchun_afk is now known as chihchun === e is now known as deadk === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:39] good morning [06:41] hey zyga-ubuntu , good morning [06:46] mvo: hey, what a autumn-ish monday :) [06:46] mvo: how are you doing? [06:46] mvo: I'll get to reviews in a moment, just making tea [06:51] zyga-ubuntu: things are going well, I start 2.29~rc1 today [06:51] PR snapcraft#1638 opened: tests: reorganize unit and integration suites to make them easier to split for travis [06:52] mvo: do you think we will make it with all the PRs marked as a part of 2.29? [06:53] zyga-ubuntu: not for ~rc1, but we can cherry-pick them all for ~rc2 [06:54] mvo: all right then === JanC is now known as Guest95859 === JanC_ is now known as JanC === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [07:30] o/ [07:32] jamesh: hello [08:09] Chipaca: hey, quick question - the structured epochs branch has landed for 2.29 - does that mean our side is complete or will we have to do client side work still? [08:13] mvo: there's no business logic [08:14] Chipaca: aha, and we need that client side? [08:14] zyga-ubuntu: hi [08:14] mvo: as i understand it the client needs to sanity-check epochs as part of validation, yes [08:15] Chipaca: ok, thats fine then. was wondering if it should go into the 2.29 release notes draft or not :) [08:15] jamesh: hey! :) [08:16] mvo: i'd keep mum about it until both sides are done, in any case [08:17] elopio: still awake? mind reviewing snapcraft#1627 ? [08:17] PR snapcraft#1627: lxd: split container classes into different files [08:17] jamesh: how are you doing [08:17] jamesh: I'd like to sync on our work around mount features [08:18] zyga-ubuntu: do you happen to know if there is a workaround for classic snaps not working on artful? the __libc_dl_error_tsd issue? [08:20] mvo: I don't know of any workaround [08:20] zyga-ubuntu: I still need to get my user-mounts branch properly working for fuse mounts. I got side tracked on some other bugs (there have been a few gnome-software/snap related issues that came up in the last week or so) [08:20] jamesh: I'm working on overlay support and I think it could now be used for improved content interface [08:21] jamesh: I'll probably look at a quick attempt to implement the new content interface ideas [08:22] jamesh: (the one with saner one-to-many connections) [08:22] jamesh: I could also try the idea where snap-update-ns is called for user mounts, if any exist, and see if that can be made to work [08:23] hi [08:24] zyga-ubuntu: so, the main issue I can see with using snap-update-ns for the user mounts is that we either (a) need to have snap-confine set up inheritable capabilities so snap-update-ns can do its job as a normal user, or (b) have snap-update-ns do the capability manipulation and setuid itself [08:25] zyga-ubuntu: with (a), we'd need to make absolutely sure those capabilities didn't leak out to the confined process. With (b), we'd need to have Go bindings for the capability APIs [08:30] jamesh: why does snap-confine need to run as a user the 2nd time? can it run as root and pass some arguments to the mount operation? [08:31] zyga-ubuntu: let's say that /foo is a fuse file system, and I want to do "mount --bind /foo/bar /mountpoint" [08:31] zyga-ubuntu: if "/foo" was mounted as an ordinary user, running the mount command as root will fail because root can't see "/foo/bar" [08:32] c-lobrano: Did you see snapcraft#1636 ? [08:32] PR snapcraft#1636: internal: more gracefully determine host OS [08:32] the kernel will only let the user that mounted the fuse file system see files and directories within [08:32] jamesh: I see, how are they mounted by bubblewrap then? through capabilities? [08:33] zyga-ubuntu: yeah. add CAP_SYS_ADMIN to permitted set, setuid(real_uid), reacquire CAP_SYS_ADMIN, mount [08:33] Hey kalikiana, yes I saw it. Unfortunately I was to slow :D [08:33] jamesh: could we do that with the C preamble? [08:34] zyga-ubuntu: using cgo might be the best option, yeah. [08:34] jamesh: snap-update-ns has a non-trivial C preamble to do various pre-go manipulations [09:55] niemeyer, hi, could you have another look at https://github.com/snapcore/snapd/pull/3916 ? [09:55] PR #3916: snap,wrappers: add support for socket activation [09:56] pedronis: you're alive! \o/ [09:56] * Chipaca was starting to worry [09:56] pedronis: how're you doing? [09:58] Chipaca: better [09:59] pedronis: does that mean 'not 100% yet'? [10:00] not 100%, but back to work, still haven't finished my treatments (some more days of pills) [10:01] pedronis: blagh :-/ [10:03] pedronis: during the NYC sprint I advanced on having tab completion for aliases done. I've got it working, but there are a lot of tests for aliases from foo to foo that, because of the simplistic way i implemented it, don't pass for completion. i wanted to check with you about the rationale for those tests to see if it made sense to skip them for this, or if i needed to fix the implementation to treat it specially === chihchun is now known as chihchun_afk [10:05] Chipaca: I'm probably missing context, why doing tab completetion would break tests? [10:05] and what are aliases from foo to foo [10:05] pedronis: aliases := []*backend.Alias{{"x", "x"}} [10:07] that's an alias for something that already exists, right? [10:07] I suppose [10:08] I still don't understand why that then breaks when you add completion [10:09] pedronis: i mis-spoke, the aliases don't break; matchingAliases et al don't return that as an alias, which means it's not returned [10:09] i mean [10:10] pedronis: should i push the branch and you read code, or should i continue trying to explain? [10:10] pedronis: i tweaked the helpers to return the matching aliased commands and completions [10:10] pedronis: commands is what was there before, those still work fine [10:11] which helpers? [10:11] pedronis: completions will all be missing these auto-entries (the {"x", "x"} ones) [10:11] pedronis: matchingAliases, missingAliases [10:11] matchingAliases is a test only helper [10:11] yes [10:11] as i say, it works, my doubt was with tests [10:11] so i wanted to check with you about the intent of those {"x", "x"} ones before just removing them from the completion checks [10:12] can you give a test file name ? (there's a lot of tests) [10:13] pedronis: https://github.com/snapcore/snapd/compare/master...chipaca:complete-aliased#diff-66a739a11ce504d9bc94df4adb1e8bcdR377 [10:13] pedronis: the last two lines on that test [10:13] one is for the command aliases, which is as it was before [10:14] ie c.Check(matchingAs, DeepEquals, []*backend.Alias{{"baz", "y.baz"}, {"y", "y"}}) [10:14] why completers need tests in backend? [10:15] pedronis: because they're created there? [10:15] ah, this is not about completeing aliases [10:15] this as about completing aliases args ? [10:15] we were on completely different thoughts [10:15] this is about creating the completion snippet symlinks for aliased commands [10:16] that is, when you alias foo.bar to bar, you want bar to run the completer for foo.bar [10:17] will not Alias{x,x} create a circular symlink ? [10:18] you are probably reading too much in those tests [10:18] PR snapcraft#1412 closed: lxd: snapcraft refresh in containers [10:18] pedronis: Alias{x,x} wouldn't work because it either doesn't exist, or already exists, so in either case it won't get touched [10:19] pedronis: I thought they were probably the trivial case, but I don't know enough to be sure so rather than investigate i paused the work to ask you when you got back [10:19] I have as much clue as you on this [10:20] hah [10:20] pedronis: i thought you were mr aliases :-) but ok [10:20] (it's not worrying that i was wrong -- but everybody else thought so too, and that might be a little worrying) [10:21] Chipaca: wrong abotu what? [10:21] pedronis: about you being the person who knew about this bit [10:21] I wrote that code [10:21] it doesn't mean I remember why a unit tests is some way or another [10:21] after months [10:22] afaict Alias{x,x} will create a circular symlink [10:23] PR snapd#4065 opened: servicestate: use taskset [10:24] pedronis: fair enough. I'll go ahead and fix the tests to pass then, as the errors make sense [10:24] pedronis: thank you [10:25] pedronis: (my doubt was because maybe there were situations where that alias was attempted and something special needed to be done with it, but if it's just an easy test it's fine) [10:25] Chipaca: well it might be that we don't defend about somebody trying to set up such an alias, I don't remember [10:26] * kalikiana break [10:26] Chipaca: so it might be worth checking what happens [10:26] in that case [10:29] ok [10:30] ah, you get - Setup manual alias "spread" => "spread" for snap "spread" (cannot enable alias "spread" for "spread", it conflicts with the command namespace of installed snap "spread") [10:31] so we don't get there because of that [10:32] fwiw [10:49] Chipaca: ^ [10:49] pedronis: ack [10:56] zyga-ubuntu: by the way, I noticed that your devtools scripts don't work with the latest snapd. Is there a newer way to test out changes on my dev system? [10:59] no, not really [10:59] I mostly use make hack [11:00] that doesn't really help for snapd changes though [11:00] snapd is fine to run just from shell [11:00] go build && sudo ./snapd [11:01] zyga-ubuntu: no, because it panics if it's not running from /usr/lib/snapd/ [11:01] I was getting this error: https://github.com/zyga/devtools/issues/25 [11:01] Chipaca: what? I never got that [11:01] Chipaca: maybe I had no-reexec key set [11:01] zyga-ubuntu: then you're not running it like that enough [11:01] zyga-ubuntu: i get this with no-reexec set [11:02] hmmm [11:02] zyga-ubuntu: when trying to install something [11:02] is that new? [11:02] zyga-ubuntu: a month? two? [11:02] super old [11:02] I really think it's a bit shooting ourselves in the foot [11:02] Chipaca: weird [11:02] maybe my braches are just equally old [11:02] maybe make hack should do more? [11:02] (make hack == ~~ make install) [11:19] PR snapd#4066 opened: overlord/snapstate: support completion for command aliases [11:20] ok, i think i should go for a run === facundo__ is now known as Facu [11:39] * Chipaca goes [11:50] ackk: Will do, thanks for the ping [11:51] thanks niemeyer [12:15] mwhudson: hey, if you happen to be around, I wonder if you have any idea about a symbol ' out of range error on zesty/ppc64el (go1.7) [12:17] mwhudson: aha, nevermind, found the forum topic about it [12:35] PR snapd#4067 opened: packaging,spread: fix and re-enable opensuse builds [12:40] Hello. I need to make some changes in the mac80211 and ath9k modules. Does anyone know how can I compile a new kernel snap with my changes, to replace the legacy kernel snap available in the Ubuntu Core distro? [12:40] jdstrand, hey I am doing a test for the gsttings interface [12:41] Is this possible? [12:41] jdstrand, I see that the gsettings command is not able to access the schemas [12:42] jdstrand, any idea about the configuration needed for that? is it ok to use the gsettings too to test that interface? [12:42] jdstrand, I already tried with a python script but had a lot of issues with dependencies and showed similar problems with the schemas [12:48] booo, something changed in travis and the "all good" thing is now even more garbled [12:48] * Chipaca will fix, sometime [12:48] mvo: how are we for adding things to 2.29? [12:49] mvo, Chipaca are we still adding things to 2.29? [12:49] cachio: that's what i asked, more or less :-) [12:49] I already started beta testing on this [12:50] Chipaca, cachio first rc1 is out but there will most certainly a rc2 so things are still open [12:50] although my question would be "are we still doing that thing where we can sneak branches into the next point release if it happens" [12:50] but we already catching the first issues (ftbfs on ppc64el/zesty for example) [12:51] ok, if #4066 is as low drama as i think it is, i'll suggest it for point inclusion [12:51] PR #4066: overlord/snapstate: support completion for command aliases [12:51] otherwise .30 is fine [13:33] mvo: cachio: seeems we have a couple of assertions signed by an account/key from federico, not sure how they are used execatly, auto-import.assert is one of them, there's a bunch of model assertions too [13:34] if we redo the auto-import.assert one we probably need to redo some of the models too [13:35] mvo: is this related to the fact that there's a limit on how long a system-user can last ? [13:38] pedronis: I think its unrelated but I have not looked in detail [13:43] mmh, no, the limit is only if no models [13:43] not sure why federico set it so [13:43] but maybe we changed that in between [13:44] I suspect its and old test, that was one of the early ones [13:46] PR snapd#4068 opened: interfaces/builtin: add support for content "source" section [13:47] cachio: you need to use the desktop part and its desktop-launch wrapper to generate the schema files aiui. you might talk to the desktop team for more specifics (eg, kenvandine) [13:47] jdstrand, good, thanks [13:50] mvo, 2.28.5 in stable [13:51] \o/ [13:52] I need to pick up my daughter [13:52] cachio: woot, thank you [13:52] heh, looking at snap info core looks cnfising with beta and edge now [13:53] jdstrand: o/ [13:54] zyga-ubuntu: hi! fyi, 4008 and other PRs are at top of list today (after one thing I'll finish this morning) [13:54] mvo, should that beta build not also have gone to edge at the same time ? seems weird that beta has a higher versioon (and revision) than edge [13:54] jdstrand: thank you! :-) [13:54] jdstrand: I'm still working on some tweaks to the content one but I will post it as soon as 4008 is merged; I'll probably iterate with you today/tomorrow to land 4008 [13:57] ogra_: yeah, I think its confusing, edge is actually also new but the version does not reflect it. I will fix in a wee bit [13:57] cachio: yay, thank you so much! [14:00] mvo, np [14:04] niemeyer, this week could you take a look to the PRs in spread-cron? [14:04] niemeyer, taht would be grat if we can merge it soon [14:19] * kalikiana need.. more.. coffee.. [14:46] kyrofa: elopio Are we having our weekly between the three of us then? [14:46] in 15min [14:46] kalikiana, I was assuming so after our discussion on Friday, but we honestly didn't make much more progress after you had to jet [14:48] kyrofa: Ah. Should we maybe schedule another one for that? I can work late tomorrow so we have more time. [14:48] PR snapd#4069 opened: debian: do not build static snap-exec on powerpc [14:49] re [14:49] kyrofa: The other thing I was thinking, maybe if you want we could chat about the OsRelease class a bit - I made some suggestions in my comments, but maybe we want to check if we're on the same page there? [14:52] kalikiana, fine by me-- I'm always happy to meet regardless [14:52] let's do it [14:52] Okay [14:52] I mean the one today. As for tomorrow, let's ask sergio when he's back [14:53] I do think we need to continue breaking it down, but not sure when [14:54] kyrofa what's up? [14:54] kyrofa I added comments to the OsRelease stuff too [14:55] kyrofa is snapcraft#1632 ready to go? this would be my final gripe to go to the stable channel :-) [14:55] PR snapcraft#1632: libraries: exclude the full set of libc6 [14:55] sergiusens, indeed it is [14:56] sergiusens, I think we can improve that lib method, but it causes no harm in that PR [14:56] And I've tested it pretty extensively at this point [14:56] sergiusens, I'll go +1 it [14:57] sergiusens, you realize though that those other two PRs are required for trusty support, right? [14:57] kyrofa I have a PR refactor to change that module from `libraries` to `elf` and do some neat things in there [14:57] sergiusens, excellent [14:57] but I'd rather do minimal changes here so the test surface is not so broad to get a stable release out first [14:58] sergiusens, fair enough. +1d [14:59] niemeyer: I realized that due to a way apparmor is behaving we may need to have apparmor and mount kernels coordinate on the rename [14:59] niemeyer: I'll make a test case to examine this [15:01] PR snapcraft#1632 closed: libraries: exclude the full set of libc6 [15:01] niemeyer: I also think that we must be careful in mixing slots that use source and those that don't [15:01] sergiusens, I of course have some vested interest in trusty support. While I've got you: do you think it's possible to support using the snap (once it works) in the trusty builder? I've been getting some questions about this [15:02] niemeyer: as this will cripple plug side [15:02] niemeyer: I was thinking about an attribute that would let the plug side define and control one-to-many expectations: only-one, allow-many [15:02] zyga-ubuntu: Which renames? [15:02] kyrofa I think it should be possible with these changes; non classic confinement at least [15:02] sergiusens, yeah that's a whole different ballgame [15:03] zyga-ubuntu: Yeah, we'll need that at some point, but I suggest not doing that now so we don't get lost from the key priorities [15:03] niemeyer: https://forum.snapcraft.io/t/improvements-in-the-content-interface/2387 [15:03] cjwatson, if the snapcraft snap worked on trusty, is that a capability you'd be able to expose in the LP builders, or build.snapcraft.io? [15:03] niemeyer: ack [15:03] niemeyer: on that page look for "renamed" [15:03] cjwatson, the snapcraft in the archive is v1, targeting 15.04 [15:04] But there are people who actually need to build series 16 snaps on trusty [15:05] Oh sorry kalikiana got caught up in coffee [15:05] On my way [15:05] haha [15:05] no worries [15:08] zyga-ubuntu: By "kernels" you mean "backend" I suppose? [15:10] kyrofa: s/, or build.snapcraft.io// (they're the same thing). maybe? it'd need some thought; it would be complicated if it had to be selectable [15:10] cjwatson, well, the builders expose a lot more capability-- different archs, etc [15:10] cjwatson, curious to see if anyone is using it for v1 [15:11] (anyone using them today is either using v1 or expecting it to be v2 and giving up) [15:11] kyrofa: right, but BSI is strictly more limited, it doesn't have its own special build code or anything over and above what's on LP [15:11] cjwatson, right, which is why I specified them both [15:11] kyrofa: actually BSI would be out of scope here anyway since it's xenial-only [15:11] Ah [15:11] niemeyer: yes, not sure why I said "kernels" :) [15:12] kyrofa: we do have the notion of permitted combinations of Ubuntu series and snappy series in LP [15:12] zyga-ubuntu: We should be able to do without actual coordination between the backends.. the interface itself is the one that has needs across both, and should be able to inform both of what it needs [15:12] kyrofa: right now, the snappy series (e.g. 16) isn't passed through to the builder, but it could be [15:13] kyrofa: that's probably how we'd do that kind of thing if we needed to [15:13] niemeyer: yes, I was thinking we just need to supply the backends with the same information so that they can come up with the same decision in the end [15:14] kyrofa: (I don't suppose I could persuade somebody from the snapcraft side to have a go at contributing the necessary changes? more than happy to help with mentoring, but it seems that it'd be good for more people on the snapcraft side to know how the moving parts work) [15:15] cjwatson, actually yeah, that doesn't sound like a bad idea [15:15] it would involve carefully-sequenced changes to both launchpad-buildd and LP itself, but apart from that it's pretty isolated [15:16] actually maybe not much sequencing [15:19] basically just a matter of adding the snap's store_series name to the build args in SnapBuildBehaviour, passing that through to the backend script in launchpad-buildd's SnapBuildManager, and adding the necessary conditional behaviour to launchpad-buildd's BuildSnap.install. As long as launchpad-buildd tolerates the key being missing from the build args, there's no sequencing involved [15:20] and then we could add the trusty/16 combination to SnappyDistroSeries via an API POST request once we've verified that it works [15:20] cjwatson, good deal, once a few of our PRs make it into a release, I'll look into that [15:21] (right now the snap doesn't run) [15:21] cool - let me know [15:21] I expect we'll want the builders to know the snappy series eventually for other reasons too [15:22] man [15:23] I wish to thank everyone for introducing the automatic and smart "night mode" [15:23] with almost no direct sun nowadays, it's always "dark and gloomy" [15:23] but at least my eyes hurt less [15:23] zyga-ubuntu: the redshift developers disagree :-) [15:24] Chipaca: the coverflow developers you say? ;-) [15:24] zyga-ubuntu: (because gnome wrote their own and made them redundant) [15:24] mvo, I am taking a look to the snap-confine issue that seems to be failing on autopkgtest:ubuntu-* [15:24] Chipaca: all software falls into the back hole of "built-in feature" [15:24] cachio: hmm, which issue is that? [15:24] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-image/zesty/amd64/s/snapd/20171023_140008_52dda@/log.gz [15:25] aha that one [15:25] I suspect it's a very very slow VM [15:25] unless you can reproduce it [15:25] something related to module:nvidia_modeset [15:26] cachio: does it only fail in that place? [15:26] cachio: that error is a very indirect way of saying "3 seconds elapsed but we took longer to finish stuff" [15:28] cachio: did you see it in any interactive work? [15:33] PR snapd#4067 closed: packaging,spread: fix and re-enable opensuse builds [15:33] hmm [15:33] but something is indeed fishy [15:33] cjwatson, agreed, that seems generally useful [15:33] lots of tests are failing on this [15:34] mvo: maybe we should increase that timeout to 6 seconds === JoshStrobl|AFK is now known as JoshStrobl [15:46] zyga-ubuntu, sorry, I was having lunch [15:46] zyga-ubuntu, well, that could be a reason, I'll try to reproduce it on a vm here [16:15] cachio: Reviewed both PRs there [16:15] niemeyer, tx [16:35] niemeyer, hrm ... when we switched to the forum were all the old mailing lists archives simply wiped ? [16:36] ogra_: I don't think anything happened to the ML other than blocking subscriptions and postings. [16:36] well, it seems gone from lists.ubuntu.com [16:37] anyway, no biggie (the stuff i searched for is in my local archives) [16:37] https://lists.ubuntu.com/mailman/listinfo/snappy-devel ... should (theoretically) get me to the archives ... though [16:45] niemeyer, please tell me if the doc that I added in the PR help to understand the change [16:46] cachio: Thanks, looking [16:53] cachio, sorry that you have to suffer from my shell-like pyton stuff :) [16:56] ogra_, np :) [16:57] (even though sergiusens claims that my python looks like perl ... :P ) [16:59] ogra_, hahaha [17:01] cachio: Replied [17:02] ogra_: Are you looking for this: https://lists.ubuntu.com/mailman/listinfo/snapcraft [17:02] ogra_ perl 6 even [17:02] niemeyer, oooh, it was originally snappy-devel and got renamed ... (i simply clicked the link at the bottom of an old list mail in my mail app) ... yeah, thats it [17:03] thanks ! [17:03] ogra_: That's the actual mailing list we used before the move to the forum [17:04] yeah [17:04] ogra_: It got renamed 20 years ago.. shortly after Linus came up with the Linux kernel [17:04] hahaha [17:06] ogra_, I need to see an example then. I can't imagine python that looks like an AES-encrypted message [17:06] cjwatson kyrofa we would want to take advantage of base declarations in snapcraft.yaml when they come, those would be mapped to builder instances and if we really really want to support building on trusty, I would try to get a trusty base going too [17:07] kyrofa, well, i hate curly brackets ... so it wont be perl ever again :) [17:07] sergiusens, that's a great point, I wonder how hard it would be [17:08] kyrofa we wrote it down on a forum post already, somewhere at some point in time ;-) [17:08] sergiusens, haha, good luck finding it [17:10] sudo snap install forum-crawler ... [17:10] :P [17:11] $ snap find forum-crawler [17:11] The search "forum-crawler" returned 0 snaps [17:11] ogra_, you got my hopes up [17:11] haha [17:11] sorry [17:11] kyrofa: I find the forum search surprisingly effective actually [17:12] niemeyer, I've had pretty poor experiences with it, but I could also blame that on human error [17:13] which human exactly though ? [17:15] Yes I will leave that nebulous [17:16] :) [17:16] only 4 billion choices... [17:47] niemeyer, answers in the forum, now I have a kinesiology appointment but when I am back I'll finish the refactor for the python code. [17:47] * Pharaoh_Atem groans in tiredness === JanC_ is now known as JanC [17:50] snappy-m-o, autopkgtest 1583 xenial:amd64 xenial:armhf artful:amd64 [17:50] kyrofa: I've just triggered your test. [18:39] zyga-ubuntu: ping [18:46] jdstrand: ping.. maybe you might know the answer [18:46] niemeyer: yes? [18:46] (not here full time anymore) [18:46] zyga-ubuntu: Oh, hay [18:46] how can I help? :) [18:46] zyga-ubuntu: Sorry, I realize it's a bit late [18:47] that's ok, I'm trying to solve a problem and I came to give it another try [18:47] zyga-ubuntu: I'm about to merge #3958, and was wondering about the fact we have something about encryption file systems related to that apparmor/snap-confine, according to docs in the template of snap-confine [18:47] PR #3958: many: add support for /home on NFS [18:47] zyga-ubuntu: But I cannot see any code related to this [18:48] zyga-ubuntu: My only concern right now is not breaking something else because e.g. we remove some other file (think * glob + EnsureDir) [18:48] niemeyer: right, thank you for checking [18:49] niemeyer: right now we don't have any generated include files for encrypted files systems but indeed this feature was planned so that we could add one next to NFS [18:49] zyga-ubuntu: Aha, ok.. that makes sense [18:49] niemeyer: some of those, similar to NFS, leak through the abstractions apparmor gives us [18:49] zyga-ubuntu: Merging then, thanks [18:49] niemeyer: we have some workarounds but AFAIK what doesn't work very well is "snap try" on top of one [18:49] thank you! [18:50] zyga-ubuntu: Do you have anything on top of this, or can I squash? [18:50] niemeyer: no, nothing on top [18:50] feel free to squash/not squash :) [18:50] Ok, here we go [18:50] woot, thank you [18:51] I'm sure CE will like that aspect of 2.29 :) [18:51] PR snapd#3958 closed: many: add support for /home on NFS [18:56] niemeyer, hey, can you take a look at my 2 interfaces-related PRs before your vacation? [18:56] pstolowski: Yeah, will do, thanks for the ping [18:57] cool [19:14] woot [19:15] PR snapd#4070 opened: hooks/configure: queue service restarts [19:17] niemeyer, ^ I decided to simplify the approach with the above (compared to what I was trying to explain in the standup) [19:18]