=== wgrant_ is now known as wgrant [01:33] Bug #1760252 changed: starting slack crashes xwayland on 18.04

[03:05] PR snapd#5690 opened: Add an error code for Polkit auth cancels [05:09] morning [05:42] mvo: hey [05:42] mvo: easy win https://github.com/snapcore/snapd/pull/5687 [05:42] PR #5687: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME [05:50] mvo: hey, you probably missed that, https://github.com/snapcore/snapd/pull/5687 is an easy win, same as https://github.com/snapcore/snapd/pull/5684 [05:50] PR #5687: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME [05:50] PR #5684: cmd/snap: create snap user directory when running parallel installed snaps [05:53] mborzecki: yeah, missed that, looking. thank you [05:53] good morning! [05:54] * zyga tries to shift to 6AM wake-ups [05:54] not there yet [05:54] but slowly :) [05:54] zyga: good morning [05:54] I'll make coffee and join you guys shortly [05:54] zyga: hey [05:54] zyga: you're still 2h behind the schedule :P [05:57] PR snapd#5687 closed: cmd/snap-confine: switch to validation of SNAP_INSTANCE_NAME [05:57] mborzecki: 5684 waits for john, no? [05:57] mvo: yay, thanks [05:57] mvo: yes, i pinged him and pawel yday [05:58] feels good to be back at the proper screen === mborzeck1 is now known as mborzecki [06:24] :-) [06:25] Yeah but I’m shifting [06:26] When I woke up today I felt like it’s autumn ready [06:27] Is it OK to say I already miss the summer? [06:28] My plan for today is to talk with Paweł about the system snap [06:29] And to finish off the two remaining PR I have open [06:29] And then work and user mounts [06:29] mvo: When do you plan to release the next point release? [06:30] zyga: https://github.com/snapcore/snapd/compare/master...bboozzoo:bboozzoo/parallel-install-snap-namespace-mapping i'd love to hear your thoughts [06:31] zyga: also need to look info why /snap/foo is mounted rw [06:32] I’ll check it out very soon but just as an observation snap foo cannot be a mount point, because there’s nothing out there is just a directory [06:52] zyga: rbind & ro are a no go (you added that comment?), guess it's not much of a problem for /snao/foo_bar -> /snap/foo [06:53] re [06:54] mborzecki: looking === pstolowski|afk is now known as pstolowski [07:10] mornings [07:23] zyga: I have no plans yet for a point release. what do we need in it? [07:23] some things are tagged with 2.35 [07:23] zyga: we can do in a week after the real release [07:23] and 2.35.0 is in the release page [07:23] zyga: aha, let me check [07:23] so I assumed you would do another one [07:23] is 2.35 out? [07:23] or am I just mistaken about the assumption [07:23] zyga: I thought I had moved them to .36 [07:23] zyga: its in beta now [07:23] ah, that must be it then [07:24] zyga: https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.35 [07:24] zyga: but we can do a point release i fneeded [07:24] ah, ok [07:24] :) [07:42] zyga: mount profiles for test-snapd-layout{,_foo} https://paste.ubuntu.com/p/JvmWd88tKp/ unfortunately the _foo one explodes on startup https://paste.ubuntu.com/p/8ZYtzf7sgG/ [07:43] https://www.irccloud.com/pastebin/d39eugoc/ [07:44] mborzecki: that's "expected", aka known issue [07:44] mborzecki: rm the symlink on your host to fix it [07:44] mborzecki: that's the "trespassing" bug that I was trying to fix for many months now [07:45] mborzecki: it manifests itself as dangling symlinks and empty files in /etc [07:46] zyga: ok, removing files made it go away [08:04] PR snapcraft#2220 opened: schema: allow license field [08:12] zyga: hey, do you know if there is any work going on to backport the new xdg-desktop-portal releases (in particular, 1.0) to bionic? [08:13] zyga: I'm considering whether to add it to the bionic flatpak ppa [08:24] PR snapd#5691 opened: spdx: allow Other-Open-Source [08:24] jamesh, ^ you might know? [08:26] alexlarsson: we want to backport xdg-desktop-portal to xenial. I think it might make that backport 1.0, and push it to bionic, assuming there aren't compat issues [08:26] jamesh: Should be no compat issues [08:27] I have x-d-p 1.0 for xenial in the flatpak ppa, but historically i didn't add it to bionic, because it had 0.11 already [08:27] whee, thank you alexlarsson and jamesh :) [08:27] alexlarsson: I'll talk about it with Ken [08:34] zyga: parallel installs + layouts spread test running now [08:35] cool [08:35] jamesh: cool === chihchun_afk is now known as chihchun [08:44] mborzecki: any luck? [08:46] zyga: heh, stopped at the trespassing thing, fixed the test to cleanup /etc/demo* stuff and retrying now [08:47] kk [08:47] once it passes (if it does) look around, as I said it's more about just ensuring the outcome makes sense than looking at the boolean pass/fail value [08:47] Bug #1533899 changed: Add support for proxies

[08:48] zyga: yeah, modified it a bit to write different content to locations and added some steps to verify if the things look ok from the outside [08:48] zyga: once https://github.com/snapcore/snapd/pull/5670 i'll be able to open a PR with mapping changes along with a spread test [08:48] PR #5670: daemon, overlord/snapstate: set instance name when installing from snap file [08:49] hm actually most of the spread tests, there's one that depends on https://github.com/snapcore/snapd/pull/5614 [08:49] PR #5614: interfaces: parallel instances support, extend unit tests [08:58] zyga: next time you're feeling smug about your mac, have you looked at the uname implementation for darwin vs the one for linux [08:58] mmm, nope/ [08:59] what's the difference? [08:59] zyga: https://github.com/golang/sys/blob/master/unix/syscall_darwin.go#L368 vs https://github.com/golang/sys/blob/master/unix/zsyscall_linux_amd64.go#L1378 [08:59] zyga: the darwin one is five syscalls and a loop [09:02] interesting, I knew apple did some unusual things with their sys call layers [09:02] notably for compatibility at the extreme [09:02] and also flexibility [09:03] some system calls don't have numbers [09:03] only names [09:03] and to call them you literally have to pass the string to the kernel [09:03] then again apple sys calls are executed differently due to (last time I looked at 32bit systems) 4/4 split [09:03] where the whole address space flips (except for a tiny page that has the flip code and arg buffers) [09:04] Chipaca: but yeah, cool stuff :) [09:04] and apparently it doesn't matter (marketshare :) [09:04] zyga: :-) [09:11] what does userd use SIGUSR1 for? [09:11] morphis: do you remember? === chihchun is now known as chihchun_afk [09:15] PR core#93 opened: hooks: unwind /etc/alternatives [09:23] zyga: that's the test currently https://paste.ubuntu.com/p/KfNJC6tJV2/ [09:25] mborzecki: looking [09:26] mborzecki: what I would look for in this test is something that verifies that both instances don't step on each other's data [09:26] zyga: that's towards the end [09:27] mmm, I don't see that [09:27] zyga: lines 85+, unless you have something else in mind [09:28] mborzecki: I mean that one snap should say "snap-a" and the instance snap should say "snap-b" [09:28] they should both write [09:28] and only after that we should verify the data seen by both [09:28] so that it's not "snap-a" in all the places (or snap-b in all the places) [09:29] zyga: that's exactly what's there [09:29] hmm? [09:29] but you write foo-1, 2, 3 for _both_ [09:29] so how can you check that [09:29] zyga: $name foo-1 .. [09:29] either I don't see it or the pastebin is wrong :D [09:29] aaah [09:29] $name :D === chihchun_afk is now known as chihchun [09:29] I didn't notice that at a ll [09:29] ++ [09:29] it's good :) [09:29] heh :) [09:29] thank you [09:31] zyga: ok, i'll add it to the tests and integration branches, and deal with that change in mount spec that you suggested layer [09:31] have to deal with UpdateMany() now [09:33] zyga: do you know what (bind) mounts /var/lib/extrausers in snap-confine - git grep extrausers is very quiet for me [09:33] let me think [09:33] I don't think that's us [09:33] isn't that the test setup? [09:33] or core boot process? [09:34] (us as in the cli tools) [09:34] zyga: snap run --shell test-snapd-tools.echo gives me a valid /var/lib/extrausers inside the mount namespace [09:34] zyga: so I assume that is us doing it [09:34] ok, let me look deeper [09:34] probably my memory is just rusty [09:35] ah [09:35] I know [09:35] just let me check to be 100% sure [09:35] yep [09:35] it's the LXD quirk [09:35] we have a "quirk" system in snap-confine that we only used after a particular release of snap-confine broke lxd [09:36] we make /var/lib/lxd (which is not in the base snap) [09:36] and we bind mount the host's version there [09:36] to do that we construct an (older implementation of) a writable mimic over /var/lib [09:36] I would like to disable that code but perhaps hard to ensure it's not a backwards incompatible change now [09:36] zyga: and this runs only if core is the base? not core18 ? or how is that decided? [09:36] (and we could tie that code to the lxd interface perhaps) [09:36] it runs on all classic systems for sure [09:36] let me look [09:37] yes [09:37] zyga: aha, ok [09:37] sc_setup_quirks is called if distro is SC_DISTRO_CLASSIC [09:37] but I would like to drop that, really [09:37] it pollutes the mount table with stuff for one snap but runs for all the snaps [09:37] and it's very very very likely to be unused now [09:38] and it can move to an interface (for sure) [09:38] zyga: hm, something else is going on - I see this on !classic, on uc16 [09:38] though all such transitions are non-trivial because we have no mechanism to update in-place the [09:38] oh [09:38] maybe there's a bug in core / classic classification on uc16 [09:39] zyga: could be, not super important right now, I was mostly looking why core18 was not displaying a username on core18 devices inside the mount namespace [09:39] mvo: what's the /etc/os-release file you see? [09:40] zyga: https://paste.ubuntu.com/p/XkFW7hYYTX/ [09:40] ID=ubuntu-core [09:41] zyga: silly question - in sc_mount_config what does "normal mode" mean? [09:41] normal mode is the preferred mode of operation where pivot root happens [09:41] the exceptional mode is only on core16 when we don't do that [09:41] (for compatibility reasons) [09:42] the exceptional mode is called "legacy mode" [09:42] zyga: do we have two normal modes? on in the struct and one global? [09:42] nope [09:43] normal == used on classic, used on core 18 + [09:43] legacy == used only on core16 [09:43] brb, coffee [09:43] zyga: thank you [09:43] zyga: enjoy coffee, I will dig a bit around myself [09:44] PR snapd#5683 opened: overlord/patch: support for sublevel patches [10:04] mvo: back [10:04] I was getting coffee making lessons actually (unexpectedly) [10:04] mvo: I can spin up a core16 VM and check as well if you want [10:05] need to go to the car shop, will work from there, bbiab [10:05] kk [10:06] mvo: you can also get a trace with SNAP_CONFINE_DEBUG=yes [10:07] perhaps that will shed some light as to what is going on [10:08] zyga: ok [10:08] mvo: if you pastebin that I will gladly look [10:09] mvo: just remember that on 2nd run it will use the persisted namespace [10:09] so you may want to discard it before collecting the log [10:10] zyga: https://paste.ubuntu.com/p/mTqsSKSfTz/ [10:10] PR snapd#5692 opened: snap-confine: map /var/lib/extrausers into snaps mount-namespace [10:10] zyga: oh, what was the command again to discard it? [10:10] zyga: ^- the PR above is the actual problem I want to fix :) [10:10] zyga: this is a bit of a side-issue [10:10] mvo: /usr/lib/snapd/snap-discard-ns $SNAP_NAME [10:11] zyga: https://paste.ubuntu.com/p/26bb6N4mVQ/ [10:12] mvo: if you use SNAP_DEBUG=1 you will also get snap-update-ns feedback [10:12] mvo: hmm [10:12] mvo: so this says nothing happened really pretty much [10:15] zyga: https://paste.ubuntu.com/p/FtqGCYzTnT/ <- with SNAPD_DEBUG=1 [10:25] niemeyer: https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/corecfg.go#L119-L125 <- means that snap set core proxy.http doesn't do anything on non-core, right? [10:25] mwhudson: correct [10:26] mvo: context https://bugs.launchpad.net/snapcraft/+bug/1533899 [10:26] Bug #1533899: Add support for proxies

[10:27] mwhudson: aha, I see. this is about respecting it in snapd internally? [10:27] mvo: i don't know [10:27] mwhudson: yeah, I think thats missing but should be simple, let me have a poke [10:28] mwhudson: proxy on classic can be set via /etc/environment, can't it? [10:28] mvo: there is a tension core-aka-system-config vs core-aka-snapd-config [10:28] mvo: which i guess you are fixing in series 18 :) [10:28] Chipaca: that works about as well or badly as any other way of setting it, yes [10:29] mwhudson: also to keep things interesting, there's http proxying, and there's snap store proxy [10:29] mwhudson, Chipaca my gut feeling is that on core device we edit /etc/environment and thats fine. on classic we don't but we should still lookup if the config was set and respect it [10:29] brb [10:30] sparkieg`: the link to documentation from https://forum.snapcraft.io/t/announcing-snap-store-proxy-beta/4666 is broken [10:30] i think snapd.service still says EnvironmentFile=/etc/environment? [10:30] mwhudson: yup [10:30] anyway, i wouldn't want people to think that saying snap set core proxy.http=.. does anything at all on classic now, because it doesn't [10:31] maybe it should but i don't have an opinion on that :) [10:31] mvo: mwhudson: on classic, setting the proxy via unity-control-center edits /etc/environment [10:31] Chipaca: yeah, thats fine [10:31] I'm lost about what the bug is about tbh [10:31] description just talks about core [10:31] Chipaca: I was mostly thinking that we should do somehting on classic. either error if you try to set it on classic *or* respect it for snapd only [10:32] Chipaca: yeah, its not entirely clear to me either but there is confusion and it seems the above (either error or support it) should fix the confusion [10:32] mwhudson: ^- does this make sense? [10:32] mvo: hold on [10:33] Chipaca: should probably do something to do with environment.d(7) nowadays? don't really care though [10:33] mvo: "snap set system proxy.store=xyzzy" works on classic, doesn't it? [10:33] mwhudson: environment.d wasn't in <18 afaik [10:33] oh wait that's only user sessions? [10:33] yeah all this is fairly new [10:33] mvo: Don't we use the proxy internally? [10:33] mwhudson: this is not read by pam, right? so things like ssh will not use it(?) [10:33] mwhudson: so yeah nah [10:34] niemeyer: I think we did not add support for this, I can look into making this happen should be easy but iirc we did not do it yet [10:34] mvo: erroring on the ones we don't support would be good yes [10:34] mwhudson: I whish pam_env would support it, I looked at this briefly but iirc there were some complications (beside it being pam) [10:35] mvo: something extra fun iirc here is that go's ProxyFromEnvironment looks at the environment *once* [10:35] Chipaca: yeah, lets see if niemeyer prefers support or error [10:35] mwhudson: heh, fun indeed :) [10:35] i spent a while trying for subiquity to find a way of providing a proxy to snapd that didn't involve restarting it and failed [10:36] For some reason I assumed we were already using it for internal purposes at least.. just not changing the whole system configuration when !core [10:36] mvo: wait, that onClassic check means we don't support proxy.store on classic either [10:36] mwhudson: hm, you should talk to use more :) [10:36] Chipaca: Yeah, this is busted [10:36] mvo: probably [10:36] mwhudson: I mean, we can/should honor it internally [10:36] Chipaca: is it? this is just used internally, no? [10:36] mvo: which is 'this'? [10:37] i should also not rush to complete features before deadlines i guess [10:37] Chipaca: let me look at the code before I make more statements :) [10:37] mvo: ok :-) [10:37] Chipaca: what I mean is that iirc we allow setting proxy.store [10:37] Chipaca: and it is store in the internal configuration state [10:37] Chipaca: and we honor it inside our code [10:37] mwhudson: turns out deadlines are really only slightly-upset-lines [10:37] Chipaca: Ah, except we do it seems [10:37] Chipaca: *but* I have not looked at this [10:37] Chipaca: I mean, this is just memory [10:38] * Chipaca tries [10:39] hmm, proxy.store does do _something_ (it complains about a missing assertion at least) [10:39] proxy.http does not, though [10:39] Chipaca: yeah, thats my understanding [10:39] Chipaca: let me do a quick PR that errors and then I do a not-so-quick PR that honors it internally [10:40] looks like all snap set core proxy.store does is validate the args [10:40] niemeyer: ^- sounds reasonable? [10:40] on any system [10:40] bah [10:40] i dunno [10:40] validation happens, but handling does not ? [10:40] looks like it [10:40] Chipaca: we don't need to handle it at this level, do weß [10:40] s/ß/?/ [10:40] * Chipaca gives up [10:40] * mwhudson gets back to ordering groceries (why the laptop is open at 22:40) [10:40] * Chipaca goes shopping [10:40] mwhudson: a solid plan [10:40] ha [10:41] Chipaca: I mean - for http.proxy we need to modify the filesystem but proxy.store is only used internally and does not need any external actions iirc [10:41] func ProxyStore(st *state.State) (*asserts.Store, error) { [10:41] tr := config.NewTransaction(st) [10:41] var proxyStore string [10:41] err := tr.GetMaybe("core", "proxy.store", &proxyStore) [10:41] The fact we don't do anything at set time but validation doesn't mean it's unused [10:41] +1 [10:42] I assumed the same was being done for proxy, at least for internal purposes [10:42] We just shouldn't fiddle with the whole system when snapd is not on a core system [10:42] But respecting the variable seems reasonable [10:42] I mean, if people don't want snapd to have a proxy, just don't set it [10:43] niemeyer: yeah, I think we are in agreement, I have a look at this [10:43] mvo: The question is what's the easiest way to make sure all requests are proxied [10:43] mvo: It may well be to take the proxy configuration and set the environment variable [10:44] Both when we start, and when someone changes the conifg [10:44] Otherwise we'll need to tune every single *http.Client [10:44] niemeyer: yeah, this is straightforward, we need to double check that golang actually reads the env anew every time [10:44] mvo: +1.. I assume it does, but needs confirmation indeed [10:45] er no it doesn't [10:45] that's what i was saying above [10:46] mwhudson: hm, hm, thats unfortunate [10:46] just make people stop using that ancient classic thing ;) core for everyone ! [10:47] niemeyer: the good news is that we have httputils:NewHTTPClient so hopefully a single point where we need to inject this [10:47] mvo: hmmm maybe i am wrong, or maybe this has changed in golang now [10:48] mwhudson: I was just looking at 1.10 [10:48] mwhudson: but then we still build with 1.6 :( [10:49] ah no net/http's ProxyFromEnvironment still has a sync.once [10:49] mvo: Ah, sweet! I didn't realize we had already consolidated that, great [10:50] niemeyer: its a bit of a layering problem still because we use that in e.g. "snap download" so we need access to the state [10:50] niemeyer: we could of course cheat and set an (internal) env var snapd_http_proxy etc [10:50] mvo: I think we need to fix snap download to be more typical [10:51] mvo: Meanwhile, we might just ask for the config in the command maybe? [10:51] mvo: I mean, the configuration is readable from the API [10:51] niemeyer: great idea [10:54] aah ok you can call golang.org/x/net/httpproxy.FromEnvironment() to make a new thing from the current environment [10:56] (thanks to rog, it seems0 [10:56] ) [10:58] mwhudson: this will work in 1.6? [10:58] mvo: no idea [10:58] mvo: suspect not :/ [10:59] mvo: do you have a plan for getting off 1.6? [10:59] juju-core uploads in xenial build golang first... [10:59] mwhudson: I hard foundations will support 1.10 in xenial :P [11:00] mwhudson: yeah, we might need to do the same, I'm not looking forward to it [11:00] mvo: i just do what the security team tells me to do [11:00] mwhudson: heh, sure I understand the issue(s) [11:00] (which is why juju does what it does!) [11:00] mwhudson: it makes me wonder (again) if we should make the snapd in the deb just a small shim that downloads the snapd *snap* which we then can build in whatever way we want [11:01] * mwhudson reaches for his boostraps only to find he's already standing on them [11:03] mvo: something about the current setup certainly smells bad [11:03] mvo: something something prepare-image classic something [11:04] mwhudson: I'm missing something here, what about prepare-image classic ? [11:04] * mvo might be a bit slow due to lack of lunch [11:04] mvo: heh i'm skipping ahead in ways that probably don't make sense [11:05] mvo: we already support including snaps in all the images we make [11:05] or will [11:05] why shouldn't the snapd snap be one of them? [11:06] mwhudson: \o/ I like that thinking! [11:06] well because it's snapd that processes the seed.yaml [11:06] mwhudson: sillly bootstraps [11:06] so you need something to at least partly process it at image build time [11:06] --> prepare image for classic [11:07] mwhudson: yeah, we would just need to extract the snapd binary and when it starts and finds a valid seed env it will DTRT (i.e. seed itself, restart itself, seed the rest) [11:07] mwhudson: so that is actually pretty simple [11:08] and then you can use the go snap to build snapd :) [11:08] mwhudson: \\o// [11:09] mwhudson: I will think about this over lunch [11:10] mvo: i'm at least somewhat procastinating about ordering groceries, please don't let me disturb your day too much [11:10] um, sorry if i got distracted and worked on the same thing you've been working [11:11]