=== chihchun is now known as chihchun_afk === MeiQianChiFan is now known as glibc === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:06] morning [06:34] zyga: mvo: https://paste.ubuntu.com/p/JtBVwYzqqH/ seems like the guess from yesterday was correct [06:35] snapd snap in mounted at some tmp location, but the code locating snap-seccomp in seccomp backend only picks snapMountDir + .. or distro libexecdir [07:07] mborzecki: nice find [07:07] mborzecki: so we just need to make snapd look at its own exe location first? [07:07] mborzecki: I think that makes sense anyway [07:07] mvo: yes, we do it already for system-key [07:08] mborzecki: \o/ [07:08] mvo: anyways, added a unit test and pushing a patch in a minute [07:10] mborzecki: thank you [07:15] Good morning [07:16] mborzecki: curious why this is failing now - or is the PR doing more than "just" the on-changed compiling of the bpf? [07:17] mvo: the PR tries to run snap-seccomp to get the version information when the seccomp backend is getting initialized [07:17] mborzecki: aha, I see [07:17] mborzecki: that makes sense [07:17] mvo: afaik we haven't run any of the internal tools until now [07:17] Aha! [07:17] mborzecki: interesting [07:19] mborzecki: yeah, bootstrap is very limited [07:19] mborzecki: otoh, you could simply ignore seccomp missing, the first snap installed during bootstrap will be snapd and then snapd restarts [07:21] Complexity :/ [07:26] pushed a patch [07:30] can I interest someone in a second review for 6381? should be straightforward [07:38] mvo: looking [07:56] mvo: does it make sense to have a remodel when there are no changes to the kernel and required snaps, so that only set-model task runs? [07:57] nvm, answered that myself :) [07:58] mborzecki: hi, we are still missing bits of snap connections ? content[foo] is not there yet, right? [07:59] pedronis: yes, it's not there yet [08:00] mborzecki: the idea was to have a followup right after [08:00] right now seems we will ship 2.38 without and 2.39 with? [08:00] mvo: ^ [08:00] pedronis: if its easy we can pull it into 2.38 still [08:00] pedronis: ah, ok, wanted to address soem feedback in selinux branches, but i can to that bit of connections first [08:00] pedronis: we are only at ~pre1 yet [08:01] mvo: it should be contained [08:01] yeah, having the full thing in 2.38 seems desirable [08:01] ok, will look into that then [08:01] ta [08:02] mborzecki: mvo: from my POV prioties are "snap connections" because 2.38, we are so close. SELinux because its going on since log. seccomp opts because it's 2.39 stuff anyway and it's an opt [08:02] s/log/long/ [08:03] mvo: ^, reasonable? [08:03] pedronis: +1 [08:06] mborzecki: thanks [08:06] morning [08:07] the seccomp PR has grown quite a bit :/ , the direction is good though [08:11] Back from walk, I’ll be in the office soon [08:24] aand #6485 is green! [08:24] PR #6485: interfaces/seccomp: regenerate changed profiles only [08:25] need to gram some coffee [09:02] hey team - I updated the https://forum.snapcraft.io/t/the-snapd-roadmap/1973 roadmap page for 2.38 - if your favorite thing is missing please do let me know and I add it [09:04] Thank you! [09:05] ogra@nanopc-t4:~$ lxc launch ubuntu:16.04/armhf snapcraft-armhf [09:05] To start your first container, try: lxc launch ubuntu:18.04 [09:05] * ogra scratches head ... why is it telling me the command i just used :P [09:06] 6565 is an easy win… [09:07] PR snapd#6567 closed: overlord/snapstate/backend: make LinkSnap clean up more [09:18] PR snapd#6498 closed: cmd/libsnap: add cgroup-pids-support module [09:23] mvo: https://github.com/snapcore/snapd/pull/6565#pullrequestreview-211672889 is ready [09:23] PR #6565: snap: remove obsolete license-* fields in the yaml [09:23] zyga: \o/ [09:24] PR snapd#6565 closed: snap: remove obsolete license-* fields in the yaml [09:45] interesting feature: https://help.github.com/en/articles/about-pull-requests#draft-pull-requests === tobias is now known as Guest35082 [09:51] PR snapd#6574 opened: cmd/snap-confine: track per-app and per-hook processes [09:55] another interesting github feature https://help.github.com/en/articles/about-code-owners [09:58] PR snapd#6381 closed: devicestate: add initial Remodel support === tobias is now known as Guest88232 === ricab is now known as ricab|bbl [10:32] sil2100, seems zyga just merged https://github.com/snapcore/pi3-gadget/pull/20 can you make sure we get a release of it into stable ? [10:33] PR pi3-gadget#20: dots in interface names are not allowed, fix spi [10:33] (this is actualyl one of the files that actually upgrade on gadget upgrades, so it is valuable even without new images) === alan_g_ is now known as alan_g [10:39] pedronis: updated https://github.com/snapcore/snapd/pull/6562 [10:39] PR #6562: timings: base API for recording timings in state [10:41] pedronis: thanks for another pass on nestedvm PR [10:41] I need to finally sort out the branch ownership, was too busy with the point releases in the last weeks [10:41] eh [10:41] ogra: will add that to my TODO list, will push it through as soon as possible but there's a lot going on right now [10:56] * dot-tobias says hi [11:07] zyga: 6574 is a prereq for 6502 to actually work? [11:08] I can't seem to find an update which snapcraft version is currently used for launchpad builders (latest was https://forum.snapcraft.io/t/launchpad-now-builds-snaps-in-lxd-containers-in-support-of-build-snaps/2002/23 , question asked ~20 days ago in https://forum.snapcraft.io/t/snapcraft-version-used-by-launchpad-and-docker-images/9994) [11:10] pedronis: correct [11:11] zyga: does it fail, or simply the checks always pass? [11:12] ah, the checks are not called yet [11:13] zyga: you should probably concetrate on landing a good chunk of your open PRs, I'm starting to get lost in them :) [11:13] pedronis: it would say that there are some apps running but it is unable to say which so the check would fail [11:13] fail as in prevent refresh [11:14] ack [11:22] pedronis: I updated https://github.com/snapcore/snapd/pull/6571 jus tnow [11:22] PR #6571: cmd/snap-confine: introduce sc_invocation [11:23] apart from hideous formatting I think it looks okay now [11:32] pedronis: I also updated the remaining two branches from the invocation work [11:36] pedronis: for the connection [11:36] ah, damn, noticed that i switched to -internal with the paste [11:38] cjwatson: Can you please tell me the correct syntax for LP builds “Source snap channels for automatic builds” in snap package configuration? I want to use snapcraft from latest/stable and core16 from latest/beta, do I just use the channel name or full track/channel? [11:39] mborzecki: we might let you do with --dangerous but is a bit of special case [11:39] if they come from the store content needs to mathc [11:39] even just for connecting [11:40] dot-tobias: either "latest/stable" and "latest/beta" or just "stable" and "beta" is fine [11:40] dot-tobias: but do you really mean core16? I think you probably mean core [11:40] dot-tobias: AIUI core16 isn't really a thing yet [11:44] cjwatson: Thanks for the clarification! Seems the build errors are in fact because I specified core16 (currently only available on the beta channel), but want "core". Related question: I'm a bit confused by the “Series” radio buttons up top in the same form – stating “Bionic, for Ubuntu Core 16”. Does that mean it'll run a Bionic LXD container which then utilises the “core” snap …? [11:47] dot-tobias: We'll be cleaning up the confusing "Ubuntu Core 16" bit there in the near future since it doesn't make as much sense as it used to [11:47] dot-tobias: In most cases now you should just select "Ubuntu Core 16" (without any explicit Ubuntu series) and let LP work out what to do for itself [11:48] cjwatson: Will do that, thank you very much! [11:48] That causes it to dispatch to a container based on what "base" in snapcraft.yaml says [11:48] So base: core18 dispatches to a bionic container, otherwise we dispatch to a xenial container [11:49] dot-tobias: I've committed a patch to allow explicitly setting the channel for core16 (and for that matter core18), but it's not on production yet [11:49] At the moment you can only select channels for core and snapcraft [11:53] hey! how can I make a confined snap "properly" access a unix abstract socket exposed by a process in the system? [11:53] cjwatson: Good to know. My use of “core16” was more due to confusion between core and core16, so I think my snap will be fine with just “core” for now. Only thing keeping me from upgrading to core18 is its reliance on a specific network-manager version [11:53] abeato: ^? (this is so that fwupd snapd can talk to a modem through the qmi-proxy socket) [11:54] mvo: I added a small spread test to https://github.com/snapcore/snapd/pull/6574 [11:54] PR #6574: cmd/snap-confine: track per-app and per-hook processes [11:55] aleksander: what provides the socket? [11:56] Chipaca: the socket is exposed by the "qmi-proxy" process, and the proxy process forwards QMI messages to a USB modem [11:56] zyga: ta [11:56] aleksander: but, how do you know that process is there when you install the snap? [11:57] Chipaca: well, that process is there when ModemManager is running [11:57] aleksander: is modem manager in a different snap? [11:57] fwupd won't try to use the socket unless MM is running already [11:58] Chipaca: yes, ModemManager may be system-installed or in its own snap I guess [11:58] aleksander: how does fwupd know mm is running? [11:58] actually, I'm not sure how libqmi/qmi-proxy are packaged, I guess they may be provided in the same snap as ModemManager? abeato should know [11:58] Chipaca: fwupd talks to MM via DBus [11:59] it sounds like the modem manager interface should allow access to the qmi proxy [12:00] at the time fwupd talks to the modem through qmi-proxy, ModemManager knows nothing about the modem as fwupd "inhibits" the device [12:01] and I definitely wouldn't want to make ModemManager allow raw QMI commands anyway... [12:01] small break for 3rd coffee [12:01] are you guys also this sleepy lately [12:01] or is it just me? :( [12:02] is is the weather or is that the baby [12:02] zyga: haha, the newborn syndrome I guess? I feel that [12:02] aleksander: I guess I got my answer :) [12:02] be prepared for years of sleep deprivation [12:02] aleksander: yeah, constant wake-ups at night [12:02] it's not that bad [12:02] it gets better [12:02] i'm told [12:02] hahaha [12:02] yeah, I think it is only about three months [12:02] so I'm told as well, and I haven't had a full night of sleep in 3 years by now [12:03] we're already 1/3rd of the way [12:03] * Chipaca does some fast maths and reckons 14 years and counting [12:03] :D [12:03] aleksander: oh really? [12:03] zyga: it changes in nature [12:03] in either way, COFFEE [12:03] EAGAINCOFEEE [12:03] at 2.5 years old, the firl started to sleep better, which is when we had the baby boy, and back to square 1 [12:04] the *girl started to sleep better [12:04] aleksander: you should've paralellised [12:04] Chipaca: lol [12:12] Chipaca: so back to the issue, is there any way to run this fwupd snap in a way that has access to the system-exposed unix abstract socket? [12:13] cjwatson: Just FYI, “core” works fine but for whatever reason the ruby plugin only likes core16/core18 [12:13] (https://github.com/snapcore/snapcraft/blob/ade7d65f0ba7870add2ed5ba5c016a93db2f88b8/snapcraft/plugins/ruby.py#L77) [12:14] aleksander: not a priori, no [12:14] :( [12:16] aleksander: is there already code in the snap that tries to do this? [12:16] in the fwupd edge snap channel, yes [12:18] wait [12:18] pedronis: https://github.com/snapcore/snapd/pull/6571 is green [12:18] aleksander: fwupd is classic [12:18] PR #6571: cmd/snap-confine: introduce sc_invocation [12:19] aleksander: i thought you said it was strict? [12:21] Chipaca: does this mean that fwupd as being a classic snap should be able to see abstract unix sockets without issues? [12:21] aleksander: yes [12:21] aleksander: 'classic' means 'as in a deb' [12:21] Chipaca: I may have assumed fwupd was confined, I'm still a bit lost on snap world :D (my first day actually, I'm learning...) [12:22] aleksander: :-) [12:22] oh, that's fine then I guess? humm.. I wonder why I couldn't make that work [12:22] aleksander: classic also means it won't work in the pure-snap world, as well as having security implications [12:22] kyrofa: Is there a reason that the ruby plugin only supports core16/core18, but not core as a base? (cf. https://bugs.launchpad.net/snapcraft/+bug/1794800) [12:22] Bug #1794800: Update the ruby plugin to be base aware <18.10-build-vm> [12:23] aleksander: hey, I think we've met before, no? [12:24] Chipaca: I believe that's something that is taken for granted for the fwupd package [12:24] a shame [12:25] zyga: hummmm not in the real world I think, but we discussed a long ago about a way to avoid MM poke TTYs [12:25] IIRC theer was work started to eventually have a fwupd interface, no ? [12:25] (IIRC) [12:25] aleksander: ahh, that's correct! [12:25] aleksander: nice to see you here, welcome! :) [12:25] :D [12:26] aleksander: if you have snap questions please ask us anything [12:26] zyga: we "fixed" the wrong poking of TTYs btw... :P [12:26] oh? how does that work now? [12:27] zyga: only if we're very certain that a TTY belongs to a modem we do poke it, we have some heuristics in place to do that automatically [12:27] is there a way to see which snaps use core18? [12:27] we've lost automatic detection of some old modems, but that's fine I guess [12:27] zyga: that series need at least a step 4, right? to pass sc_invocation at least to the functions changed in -3 to take is_normal_mode [12:27] pedronis: yes, there will be more patches, depending on how big the PRs get [12:28] pedronis: I'm making sc_invocation public now, so that we can easily pass it around [12:28] zyga: I'm happy to stop there to be clear, I don't think we need to do everything now [12:28] I mean at this step 4 [12:28] pedronis: OK [12:28] pedronis: yeah, this should allow us to return to mvo's branch [12:28] yes [12:29] pedronis: I'm happy to explore more refactoring and design once you have some interactive time [12:41] Chipaca: ok, I got more details about my issue with the proxy process... so, by the time fwupd wants to talk to the proxy, the proxy doesn't exist any more. fwupd is using libqmi/libmbim and this library is in charge of starting the process if it's not already running, so in this case, it's the fwupd snap the one trying to launch the proxy process, and failing [12:46] I think I'm going to just prepare a dirty hack to avoid this... :D [12:49] aleksander, hey, just back from lunch [12:50] aleksander, libqmi and libmbim are part of the MM snap [12:50] abeato: aha, I guessed that, and so the proxies as well? [12:50] aleksander, if you need access to something from HW probably best to do is to modify the MM snapd interface [12:50] aleksander, yes [12:51] abeato: so if there is any other app that wants to use QMI, it needs to rely on the MM snap somehow? [12:51] aleksander, nope, you could bundle the library in that new snap [12:51] I have a feeling that the fwupd snap also has libqmi inside actually [12:52] aleksander, in snaps in general we prefer to bundle most dependencies in [12:52] but the proxy is not there [12:52] pedronis: is https://github.com/snapcore/snapd/pull/6571 something you want to review in detail again or are you waiting for the full series to review? [12:52] PR #6571: cmd/snap-confine: introduce sc_invocation [12:52] aleksander, hm, talking to the proxy from the MM snap could be tricky [12:52] abeato: and imagine this case: snap fwupd runs, uses libqmi and libqmi starts the proxy, then fwupd exits; what happens with the proxy? [12:53] zyga: I can review it, it would be good to have also step 4 before starting landing things though [12:53] aleksander, it should be stopped I guess [12:53] is it kept alive in the system, or no because it was run as part of the snap fwupd? [12:53] should or will? I mean, what will the snap setup do right now? [12:54] aleksander, it will not do anything special unless instructed [12:54] oh ok ok [12:54] pedronis: ok, I'll get that up [12:54] aleksander, what I see is that there is a dependency here, I assume that ideally you will want to use the proxy from the MM snap to do the update [12:55] aleksander, but the fw updater would run from a different snap [12:55] so I have several ways to fix this issue, I can make the proxy not exit after 30s (if no clients connected) and let it exit e.g. after 300s, and that would allow snap fwupd to do the upgrade properly using the proxy that was already running in the system; or otherwise I could package inside the fwupd snap the proxies as well, and let libqmi/libmbim start the proxies from within the snap if needed [12:56] at this point, I'm not even looking at the MM snap, I'm assuming there's a system-installed MM, truth be told [12:57] abeato: is the MM snap confined? [12:57] aleksander, I think it is fine to assume MM is installed. Yes, was about to tell you that - the main issue is to be able to access the proxy from the fwupd [12:58] if both are in different snaps [12:58] oh, so MM snap is indeed confined and the proxy within the MM snap runtime isn't accessible from other processes? [12:58] correct [12:58] ouch :) [12:58] ok, won't tell anyone [12:58] we do allow access to MM dBus interface === ricab is now known as ricab|lunch [12:59] which is the interface for the proxy? a socket? [12:59] yes, abstract unix socket [12:59] abeato: two things [12:59] abeato: one is that maybe access to that socket should be made part of the mm interface? [12:59] abeato: second is that, given fwupd is classic, maybe they can access it anyway [12:59] Chipaca, yeah, of a new interface [13:00] s/of/or/ [13:00] abeato: of/or? [13:00] heh [13:00] Chipaca: oh is that possible? can the socket be made part of the mm interface? [13:00] there's already some qmi stuff in there [13:00] so, maybe? [13:00] dunno [13:00] is it an interface to access mm, or is it an interface for mm to do its thing? [13:00] where's the mm snap interface defined? [13:00] that is, is it a mm-client, or a mm-support? [13:01] aleksander, https://github.com/snapcore/snapd/blob/master/interfaces/builtin/modem_manager.go [13:01] mm-support [13:01] provides shared access to the QMI port exposed by the kernel [13:01] aleksander, not sure how familiar are you with slots/plugs. See https://docs.snapcraft.io/interface-management/6154 for an intro [13:01] ah, so not that interface :-/ [13:01] abeato: is there a -client interface for mm? [13:02] Chipaca, maybe it would make more sense to add a new interface instead of modifying mm's, as usually MM clients don't need direct access to the qmi proxy [13:02] off to pick up the kids [13:02] Chipaca, yes, used by mmcli and NetworkManager [13:02] abeato: what interface do mm clients use to talk to mm? [13:03] modem-manager interface [13:03] hmmm [13:04] abeato: but that's the interface that allows a snap to _be_ modem manager [13:04] Chipaca, well, it defines a slot and a plug [13:04] slot for MM, plug for users [13:04] ah, i missed that bit :-) [13:06] and maybe it would make sense to have a new interface, with the slot implemented by MM and the plug used by fwupd [13:08] abeato: fwupd would need a whole new interface just for all the stuff it needs to do :-) [13:10] Chipaca, agreed in deed :) [13:10] mvo, hey [13:10] https://paste.ubuntu.com/p/KXrkfp26WC/ [13:11] * pstolowski lunch [13:11] this is an error I see in all the core systems [13:11] is it intentional or it should exit 1 as it used to? [13:15] cachio: this was requested by the mir team that apt should error - and it does make sense I think, its not usable afterall. is it causing problems for you? [13:17] mvo, no, just a test failing [13:17] cachio: which one? I though I fixed them [13:17] mvo, ubuntu-core-apt [13:18] it failed in all the executions yesterday [13:19] * mvo looks [13:39] pedronis: -4 is open https://github.com/snapcore/snapd/pull/6575 [13:39] PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around [13:39] zyga: thank you [13:39] pedronis: I tweaked sc_invocation a little, there are many more cleanups that can be done on top but I think those are no longer on the critical path [13:39] PR snapd#6575 opened: cmd/snap-confine: pass sc_invocation instead of numerous args around [13:40] pedronis: the new patches in that PR start with "cmd/snap-confine: make sc_invocation public" [13:40] pedronis: please pay special attention to https://github.com/snapcore/snapd/pull/6575/commits/daa62250d09b01e59b66db203c31227202f22bbf [13:40] PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around [13:48] zyga: that looks good, the param in the function could be const though no? [13:48] we just need to modify in enter ? [13:49] *functions [13:54] pedronis: yes [13:54] pedronis: though I would prefer to first solve the issue of ubuntu-core [13:55] pedronis: where we modify the base snap name locally, see if we can make that properly earlier across the whole snap-confine invocation [13:55] pedronis: or if we can move it away to snap-run [13:55] pedronis: then we can make it constant with clarity [13:55] I'm doubtful about snap run [13:55] unless we want to do more than a refactoring [13:56] anyway it's clear that ubuntu-core fallback was broken [13:56] in more than one way [13:56] but is probably a good step to fix it as prep [13:56] anyway [13:57] pedronis: after I'm done with current branches I can move that fallback earlier, and have it modify the invocation object before we pass the read only to other functions [13:59] is google:ubuntu-14.04-64:tests/main/interfaces-daemon-notify failing a known issue / flaky test? i've been seeing it recently from time to time [14:00] zyga: yea [14:02] pstolowski: the test is a little tricky, maybe some race between systemd/service and logs? === chihchun is now known as chihchun_afk === ricab|lunch is now known as ricab [15:26] PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479, [15:26] snapcraft#2482, snapcraft#2491, snapcraft#2492, snapcraft#2493, snapcraft#2494 [15:28] PR snapd#6576 opened: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection [15:29] PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479, [15:29] snapcraft#2482, snapcraft#2491, snapcraft#2492, snapcraft#2493, snapcraft#2494 [15:32] roadmr: hey, do we need one more vote on https://forum.snapcraft.io/t/track-request-multipass-core16/10192 ? [15:40] Saviq: yes, we do :/ [15:41] PR snapcraft#2495 opened: Hide progress bar for dumb terminals - legacy branch [15:42] Saviq, roadmr: and now you have [15:44] zyga: thanks :) [15:45] mvo: can you have another look at https://github.com/snapcore/snapd/pull/6574 please - I fixed a typo in the test and confirmed that it passes in qemu [15:45] PR #6574: cmd/snap-confine: track per-app and per-hook processes [15:45] (the typo was test-snapd.sh instead of test-snapd-sh) [15:48] * zyga needs to run an errand [15:57] dot-tobias, have you ever tried that? https://paste.ubuntu.com/p/kBmSrpQ89k/ [16:00] kyrofa: No I did not, that's a very valid reason of course. Didn't want to imply an oversight or else, just wondering why a plugin might exclude a certain base (and because I hoped I could streamline my test/build workflow a bit :-) ) [16:02] dot-tobias, yeah there's sadly a bit of gap between using bases for core/core16 and using bases for core18. Core isn't seemingly a valid base, core16 isn't stable, so core18 is the only option if you're using a base. If you want to build for core, don't specify a base and you get the old snapcraft behavior [16:03] kyrofa: Will do, thanks for the clarification. [16:04] dot-tobias, sure thing. Regarding your actual question though, we tend to only support bases we've explicitly tested. If Fedora were to make their own, the plugin would need to grow support for it and potentially work a little differently [16:06] mvo, what kind of ETA are we looking at for the switch from core to snapd+core16? [16:10] #6571 needs a 2nd review [16:10] PR #6571: cmd/snap-confine: introduce sc_invocation [16:22] kyrofa: is the context bases for snapcraft? we had a discussion about "base: none" during the malta sprint to unblock people [16:22] mvo, indeed, good to know, thank you :) [16:24] kyrofa: I need to step out for some minutes but maybe someone else from the team can summarize the idea, I can also when I'm back, we have notes and all that :) [17:13] degville: https://forum.snapcraft.io/t/snap-epochs/10316 [17:13] thank you Chipaca! I'll take a look. [17:14] not super happy with it, feels like I should make a little graphic to make it clearer [17:16] Chipaca: ping wgrant about it as well [17:18] wgrant: https://forum.snapcraft.io/t/snap-epochs/10316 === pstolowski is now known as pstolowski|afk [20:58] PR snapd#6571 closed: cmd/snap-confine: introduce sc_invocation [22:10] jdstrand: FYI, replied on https://github.com/snapcore/snapd/pull/6574 [22:10] PR #6574: cmd/snap-confine: track per-app and per-hook processes [22:23] niemeyer, zyga: https://flocktofedora.org/ [22:23] Flock 2019 site is up :) [22:35] zyga: when you have time could you push master into -2 etc ? [22:47] PR snapd#6532 closed: daemon: allow downloading snaps blobs via .../file [22:51] pedronis: sure [23:19] hm