| mwhudson | will you guys be trying to get snapcraft 2.39 into bionic RELEASE? | 01:29 |
|---|---|---|
| zyga | maaan | 06:00 |
| zyga | its Friday and we are deep in golang build issues | 06:00 |
| === Guest23352 is now known as ogasawara | ||
| zyga_ | hello | 07:31 |
| === zyga_ is now known as zyga | ||
| * zyga rebuilds systemd due to CVEs, meh | 07:31 | |
| zyga | I made that branch we talked about | 07:31 |
| zyga | https://github.com/snapcore/snapd/pull/4641 | 07:31 |
| mup | PR #4641: many: move mount code to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/4641> | 07:31 |
| zyga | and on top of that: https://github.com/snapcore/snapd/pull/4642 | 07:31 |
| mup | PR #4642: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642> | 07:31 |
| mvo | zyga: nice, thanks | 07:31 |
| zyga | both of those are red because of golang | 07:31 |
| * mvo looks | 07:32 | |
| zyga | after 4641 we could remove some duplicate code that parsed mountinfo in osutil | 07:32 |
| mvo | zyga: that sounds good, let me check | 07:38 |
| mvo | zyga: fwiw, it fails because of undefine FindUID | 07:42 |
| zyga | it fails in cgo | 07:42 |
| mvo | zyga: and undefined FindGID | 07:42 |
| zyga | this is a cgo issue | 07:42 |
| mvo | zyga: it is? | 07:42 |
| zyga | it passes in normal go | 07:43 |
| zyga | (I didn't push this without testing0 | 07:43 |
| mvo | zyga: did this also break with the latest go update? | 07:43 |
| zyga | hmm, not sure, I didn't push anything else | 07:43 |
| zyga | hmm | 07:43 |
| zyga | but FindUID was always in that spot | 07:43 |
| zyga | mmm | 07:44 |
| zyga | ah | 07:44 |
| zyga | snap-update-ns had some exception to build with cgo, right? | 07:44 |
| zyga | so | 07:45 |
| zyga | quick fix | 07:45 |
| zyga | we don't need username lookup in mountentry.go | 07:45 |
| zyga | we just need the number | 07:46 |
| zyga | let me remove that code | 07:46 |
| mvo | zyga: \o/ | 07:46 |
| mvo | zyga: thanks | 07:46 |
| mvo | zyga: this is for the static build of snap-exec | 07:46 |
| mvo | zyga: so that things work even without a glibc in the core | 07:46 |
| zyga | ok, almost done | 07:49 |
| zyga | mvo, while I'm testing | 07:50 |
| zyga | quick experiment | 07:50 |
| zyga | run htop or similar in one terminal | 07:50 |
| zyga | go to root of snapd and run: time go test ./... | 07:50 |
| zyga | it seems that we have a part that scales well and a part when CPU is not really busy | 07:50 |
| zyga | for me it totals at around 1 minute 30 seconds | 07:51 |
| mvo | zyga: let me try with "time ./run-checks --unit" | 07:52 |
| zyga | no | 07:52 |
| zyga | that's idfferent | 07:52 |
| zyga | and faaaaar slower | 07:52 |
| zyga | it does sequential test for each package | 07:52 |
| zyga | the command I used does it in parallel | 07:52 |
| mvo | zyga: aha, go test in the new go skips vendor/ right? iirc 1.6 does not | 07:52 |
| zyga | (PR updated) | 07:52 |
| mvo | zyga: thanks for the update | 07:53 |
| zyga | correct | 07:53 |
| zyga | if 4641 passes I will push the same patch ot 4642 | 07:53 |
| mvo | zyga: go test starts with low cpu for me and then speeds up | 07:55 |
| mvo | zyga: for me real is about 0m58, user 2m9 and sys 0m14 | 07:56 |
| zyga | hmmm, interesting | 07:57 |
| zyga | on artful? | 07:58 |
| mvo | bionic, go1.9 | 07:58 |
| pstolowski | morning! | 07:58 |
| zyga | ah, I'm on 1.8 | 07:58 |
| zyga | hey pawel | 07:58 |
| mvo | hey pstolowski | 07:58 |
| mvo | zyga: that might be it, I can try on an artful machine in a bit | 07:58 |
| zyga | looking at the output it did run vendor tests here | 07:58 |
| zyga | but in any case, did you see a drop in CPU usage during that period? | 07:59 |
| zyga | for me it starts high, then drops to sequential | 07:59 |
| zyga | for instance cmd is super slow | 07:59 |
| zyga | (nothing happens there) | 07:59 |
| zyga | er, sorry, the one *after* cmd | 07:59 |
| zyga | cmd/snap | 07:59 |
| zyga | 25 seconds | 07:59 |
| zyga | client takes 10 seconds | 07:59 |
| mvo | zyga: yeah, cmd/snap, daemon, overlord are all slow for me, client too | 08:00 |
| mvo | devicestate and snapstaet too, might be worthwhile to look at the reasons at some point | 08:00 |
| zyga | http://paste.ubuntu.com/26545336/ | 08:03 |
| zyga | snap-seccomp | 08:03 |
| zyga | 85 seconds | 08:03 |
| zyga | I think those are those tests that run gcc, right? | 08:03 |
| zyga | I wonder if there's some golang testing trick that would let us spawn those as parallel, indepentend tests | 08:04 |
| zyga | maybe even using go() itself | 08:04 |
| niemeyer | Hello all | 08:11 |
| zyga | hey | 08:14 |
| zyga | you're up early :) | 08:14 |
| pstolowski | morning! | 08:15 |
| niemeyer | Moin! Yeah.. will try to do an early Friday today | 08:16 |
| mvo | zyga: yeah, snap-seccomp runs a lot of gcc, might be worth looking at too | 08:18 |
| mvo | hey niemeyer, good moooorining | 08:18 |
| mvo | and we have the new logo in the forum, looks really nice | 08:19 |
| mup | PR snapd#4641 closed: many: move mount code to osutil <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4641> | 08:20 |
| kalikiana | good morning, snappy | 08:20 |
| mvo | zyga: please update the other PR as well (the system-key one) | 08:21 |
| mvo | zyga: nevermind, I pushed it | 08:22 |
| niemeyer | mvo: Nice, isn't it? Really enjoyed it too | 08:23 |
| niemeyer | mvo: The whole design for the new site (not deployed yet) looks really sweet | 08:23 |
| zyga | mvo, re | 08:24 |
| zyga | thanks ! | 08:24 |
| mvo | looking forward to see it :) | 08:24 |
| mvo | zyga: thank *you* | 08:24 |
| mvo | zyga: lets hope tests are happy | 08:24 |
| mvo | zyga: also: great that we have this test, it saved our bacon | 08:24 |
| mvo | (or tofu) | 08:24 |
| zyga | indeed :-) | 08:24 |
| zyga | oh, the new logo! | 08:24 |
| zyga | I like the subtle separation of snap from craft | 08:25 |
| zyga | mvo thank you for initializing nfs home :) | 08:37 |
| zyga | I didn't think about that last night | 08:38 |
| zyga | mvo can we land 4049? | 08:38 |
| mvo | zyga: yes, I thnk so | 08:45 |
| pedronis | pstolowski: there is still a comment I made that seem unadressed in #4401 | 08:46 |
| mup | PR #4401: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4401> | 08:46 |
| pedronis | pstolowski: I recommented on it | 08:46 |
| pstolowski | pedronis, oh,i'm sorry about that, missed that somehow. thanks, will look at this | 08:47 |
| pedronis | np, thanks for working through this | 08:48 |
| mvo | zyga: hm, a peculiar error in the system-key nfs PR, snap-cofine didn't refuse to run | 08:57 |
| zyga | oh | 08:58 |
| zyga | looking | 08:58 |
| zyga | weird | 08:58 |
| zyga | just on the three systems? | 08:58 |
| mvo | zyga: yeah, really strange, I have not tried to reproduce yet | 08:59 |
| zyga | mvo actually, other systems are disabled there | 08:59 |
| zyga | hmm | 09:00 |
| zyga | hmm hmm | 09:00 |
| zyga | my only idea is that something loads that profile | 09:01 |
| zyga | and that's probably one of the changes in the PR | 09:01 |
| * zyga reviews diff | 09:01 | |
| zyga | mvo maybe we are killing the profile in the helper test scripts | 09:05 |
| zyga | I mean, system key, not the profile | 09:05 |
| zyga | mvo actually | 09:06 |
| zyga | so | 09:06 |
| zyga | I think I see what's going on | 09:07 |
| zyga | apparmor initialize starts up | 09:07 |
| zyga | then we get into regenerate all security profiles | 09:07 |
| zyga | that doesn't do anything | 09:07 |
| zyga | hmm, no wait wrong file | 09:08 |
| * zyga gets back to square one :/ | 09:08 | |
| mvo | zyga: oh, so we need to keep the current core snap revision in the system-key? | 09:08 |
| mvo | zyga: to ensure we always re-generate for the snap-confine on the core snap | 09:08 |
| mvo | zyga: woah, our system key needs a lot of input :/ | 09:08 |
| zyga | well, that's another perhaps | 09:09 |
| zyga | I don't know yet | 09:09 |
| zyga | I wonder why it clearly regenerated the profile | 09:09 |
| zyga | not why it wouldn't generate a profile | 09:09 |
| zyga | let me get a coffee and have a deeper look | 09:09 |
| zyga | I think system key is long overdue and I cannot wait to see it in production :) | 09:09 |
| mvo | zyga: heh, more thorny than anticipated | 09:10 |
| mvo | zyga: I will add the core revision and see if that helps | 09:10 |
| mvo | zyga: its needed anyway | 09:10 |
| zyga | yeah, ok | 09:10 |
| zyga | that's actually true anyway because core revision determines apparmor templates | 09:10 |
| zyga | so +1 on that | 09:10 |
| * zyga got some coffee | 09:16 | |
| Chipaca | niemeyer: go to be-e-e-ed | 09:16 |
| Chipaca | niemeyer: (thank you for the review though) | 09:16 |
| Chipaca | good morning all | 09:16 |
| niemeyer | Chipaca: Moin :) | 09:16 |
| niemeyer | Chipaca: Should have another section of it soon | 09:17 |
| * kalikiana will copy zyga and also get coffee | 09:17 | |
| * Chipaca loves the new branding | 09:17 | |
| Chipaca | niemeyer: about homes vs users, thinking about it some more | 09:18 |
| Chipaca | niemeyer: the tars are already encoding the uids/gids | 09:18 |
| Chipaca | niemeyer: should i just go with the uids, internally, and the username->uid translation on the fly? | 09:18 |
| niemeyer | Chipaca: On which side? I think the API should take the username.. internally we probably need to translate into a home at some point | 09:19 |
| niemeyer | Chipaca: It wouldn't hurt to keep the uid as well, though, at least in the metadata | 09:20 |
| Chipaca | niemeyer: to be able to alert when things change and restore would mess things up? | 09:20 |
| Chipaca | sgtm | 09:20 |
| Chipaca | api being username sounds a'ight (although it will mean having to do user lookups, which seems to kill spread on 14.04) | 09:22 |
| niemeyer | Chipaca: One more round on your way.. cmd/snap this time | 09:50 |
| Chipaca | niemeyer: just seen it | 09:50 |
| Chipaca | niemeyer: is the 'internal spacing' about the space in '2m ago', and in 'yyy-mm-dd hh:mm:ss'? | 09:50 |
| Chipaca | niemeyer: yes i can make the latter use T instead of space | 09:51 |
| Chipaca | niemeyer: for the former, i don't know how to drop the space without it losing meaning | 09:51 |
| niemeyer | Chipaca: Yeah, exactly | 09:51 |
| mvo | zyga: I added the core rev now but the security-setuid-root will not be fixed with this :/ | 09:51 |
| niemeyer | Chipaca: 2mins | 09:51 |
| Chipaca | (i could cheat and use something that looks like a space but isn't! that'd help machine parsing) | 09:51 |
| zyga | yeah, I suspect it's something else | 09:51 |
| Chipaca | niemeyer: i mean, i can drop the 'ago' if you think it's obvious | 09:52 |
| zyga | I'm really puzzled, it must be something obvious but I cannot see what would cause this from the diff | 09:52 |
| Chipaca | i added it because it seemed wrong without | 09:52 |
| niemeyer | Chipaca: Right, I think it's fine.. it's implicit from context | 09:52 |
| Chipaca | ok | 09:52 |
| niemeyer | Chipaca: Thinking about it now, it's probably nicer either way, even if we didn't care about the spacing | 09:53 |
| niemeyer | Chipaca: The "ago" will get boring quickly on a long listing | 09:53 |
| Chipaca | true | 09:53 |
| Chipaca | oops i forgot to change 'lost to the ages' back :-) | 09:57 |
| Chipaca | … and the "is probably *fine*" one! | 09:57 |
| Chipaca | heh | 09:57 |
| mvo | zyga: I have a debug shell now, I see that the apparmor profile for the snap-confine for the core rev is loaded (but not on disk) | 10:03 |
| zyga | is it possible that | 10:03 |
| zyga | 1) the profile is gone because of the test scripts and how they restore state | 10:03 |
| zyga | 2) the profile is in memory because prior test loaded it and we don't unload them in test restore scripts | 10:04 |
| * Chipaca waiting for spread to finish so he can fire off another spread, but really should leave for physio | 10:05 | |
| mvo | zyga: yeah, I think its something like this, the details are still a bit blurry to me, I ran the the test standalone and got no error | 10:06 |
| mvo | zyga: eh, got *an* error | 10:06 |
| zyga | oh | 10:06 |
| zyga | well, that's possible too | 10:06 |
| zyga | the prepare for suite would load snapd | 10:06 |
| zyga | and that would keep the profile loaded | 10:06 |
| zyga | I don't think we actually unload anything in tests, right? | 10:06 |
| zyga | oh drat | 10:24 |
| zyga | I made the coffee and never picked it up | 10:24 |
| mvo | zyga: I think I have an idea, testing it now | 10:28 |
| zyga | mvo yeah? let me know once you have the result, I'm curious :) | 10:29 |
| alexlarsson | jamesh: Are you around? Or anyone else involved in snappy on the desktop? I would like someone to take a spin with https://github.com/flatpak/xdg-desktop-portal/pull/155 | 10:30 |
| mup | PR flatpak/xdg-desktop-portal#155: Support snap <Created by alexlarsson> <https://github.com/flatpak/xdg-desktop-portal/pull/155> | 10:30 |
| zyga | hey | 10:30 |
| zyga | hey alexlarsson :) | 10:30 |
| alexlarsson | hey | 10:31 |
| jamesh | alexlarsson: hi. I'll give it a spin | 10:31 |
| zyga | oh excellent, jamesh is still up :) | 10:31 |
| alexlarsson | It depends on https://github.com/flatpak/xdg-desktop-portal/pull/154 | 10:31 |
| mup | PR flatpak/xdg-desktop-portal#154: Add application info abstraction <Created by alexlarsson> <https://github.com/flatpak/xdg-desktop-portal/pull/154> | 10:31 |
| alexlarsson | Which would be good if it could get separate reviews, but all the commits from that is in the other pr too | 10:31 |
| alexlarsson | jamesh: i don't really have a snappy setup so i kinda coded the apparmor stuff blindly | 10:32 |
| alexlarsson | jamesh: also, there are some todos that you might want to look at | 10:32 |
| ikey | oh shiny | 10:32 |
| alexlarsson | I'm hoping we can release a xdg-desktop-portal with the document portal and snappy support next week | 10:33 |
| alexlarsson | Then i can do complementary flatpak releases with it removed | 10:33 |
| * Chipaca -> physio, finally | 10:33 | |
| jamesh | alexlarsson: we don't yet have the portal support ready in master yet, so it isn't exactly trivial to test out at the moment | 10:33 |
| alexlarsson | jamesh: you can test with gdbus from a snap | 10:34 |
| alexlarsson | jamesh: In fact, maybe you can just put https://github.com/matthiasclasen/portal-test in a snap? | 10:34 |
| alexlarsson | jamesh: I guess you need dbus aa rules to grant access to org.freedesktop.portal.* | 10:35 |
| jamesh | alexlarsson: that's what I used when I was working on a prototype for this last year: https://github.com/jhenstridge/portal-test/blob/snap-pkg/snap/snapcraft.yaml | 10:36 |
| alexlarsson | jamesh: But, at the very least you could add some debug printfs in the portal and see if it gets the right app id | 10:36 |
| jamesh | I probably need to change that packaging a bit though | 10:36 |
| alexlarsson | jamesh: also, i *think* i got the app id validation right by looking at the glob for snap package names, but please verify that | 10:37 |
| alexlarsson | gdbus call --session --dest org.freedesktop.portal.Desktop --object-path /org/freedesktop/portal/desktop --method org.freedesktop.portal.OpenURI.OpenURI "" "https://gnome.org" {} | 10:37 |
| alexlarsson | is a simple thing to test | 10:37 |
| alexlarsson | Well, that actually doesn't really check the app id, so maybe not the best test... | 10:38 |
| alexlarsson | But if you combine it with some added printfs to your xdg-desktop-portal you should get some basic validation | 10:38 |
| zyga | alexlarsson thank you :-) | 10:39 |
| alexlarsson | np | 10:39 |
| alexlarsson | I really don't want app developers to have to target multiple apis | 10:39 |
| alexlarsson | we need to share this shit | 10:39 |
| ikey | not sure anyone was planning anything different, no..? | 10:40 |
| zyga | yeah, that's very much true | 10:40 |
| jamesh | alexlarsson: agreed. I don't want to repeat all the work that's been done for GTK and Qt integration. | 10:40 |
| alexlarsson | ikey: no, that was always the idea, but it need to also get done | 10:40 |
| ikey | ah gotcha | 10:40 |
| ikey | set a stable baseline now.. | 10:40 |
| mvo | zyga: quick question> kernel version as part of system-key: yes/no? | 10:57 |
| zyga | ok, I think I got the validation right now | 10:57 |
| zyga | oh | 10:57 |
| zyga | actually | 10:57 |
| zyga | version is not of much use | 10:57 |
| zyga | I'd say no unless you have a clear need | 10:57 |
| zyga | mvo we could keep bugs: [] | 10:58 |
| zyga | ;-) | 10:58 |
| zyga | if kernel bugs are bugging us | 10:58 |
| mvo | zyga: aha, thats good, yeah, we can create: bugs: [foo] when we need it | 10:59 |
| mvo | zyga: cool, thank you | 10:59 |
| * ogra_ wonder what the new bird logo on the forum is meant to represent | 11:05 | |
| sparkiegeek | ogra_: it's the snapcraft logo... it represents snappy :) | 11:23 |
| ogra_ | haha | 11:23 |
| ikey | pretty banging logo though | 11:26 |
| zyga | it could animate | 11:26 |
| ikey | also it hidpis on the site favicon | 11:26 |
| * ikey is happy | 11:26 | |
| zyga | it's nicely hidpi | 11:27 |
| zyga | yeah | 11:27 |
| ikey | lol | 11:27 |
| zyga | it scales all the way | 11:27 |
| ikey | "snappy takes flight" ™ | 11:27 |
| * ikey also cringes | 11:27 | |
| ikey | wait does this make solus (budgie) and snappy birds of a feather? :P | 11:27 |
| zyga | twin engine bird | 11:27 |
| ikey | lol | 11:27 |
| ogra_ | hey ... https://docs.ubuntu.com/core/en/reference/interfaces/shows a "network-status" interface but snap interfaces in 2.30 does not ... did we lose something since 2.25 ? | 11:28 |
| ogra_ | mvo, ^^^ | 11:28 |
| ogra_ | (or zyga ) | 11:28 |
| zyga | I think I know | 11:28 |
| zyga | just checking | 11:28 |
| zyga | yeah | 11:29 |
| zyga | it's not implicit | 11:29 |
| zyga | it's just there but you need an snap to carry it | 11:29 |
| * ikey unsubs from mir notifications on github | 11:29 | |
| ogra_ | Trevinho, ^^^ | 11:29 |
| ikey | just reminds me how little im doing myself.. | 11:29 |
| * zyga rethinks that validation | 11:44 | |
| zyga | can be done faster and much more easily than now | 11:44 |
| zyga | by tracking source and target constraints separately | 11:45 |
| niemeyer | pedronis: Reviewed most of #4497 | 11:56 |
| mup | PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497> | 11:57 |
| niemeyer | pedronis: Please have a look and let me know if you like the proposal | 11:57 |
| niemeyer | pedronis: Will take a coffee break and will review the server end | 11:57 |
| pstolowski | pedronis, do you have a moment? | 12:19 |
| Chipaca | so many non-powered-off-servers | 12:27 |
| pedronis | pstolowski: now, I was having lunch | 12:32 |
| pstolowski | pedronis, ok, i need to run to school now, will be back in ~10 min | 12:33 |
| pstolowski | pedronis, will ping you for a quick HO before the standup if thats ok | 12:34 |
| pedronis | ok | 12:34 |
| pedronis | niemeyer: from quick look proposal seems reasonable, it means the client becomes stateful though, will take me a bit to get back to that PR though | 12:36 |
| zyga | woot | 12:44 |
| zyga | it works :) | 12:44 |
| pstolowski | pedronis, can you join standup HO? | 12:53 |
| === ikey is now known as ikey|afk | ||
| mvo | zyga: fwiw, 4642 is green now | 12:59 |
| zyga | oh | 13:00 |
| zyga | oh standup | 13:00 |
| zyga | mvo so it was the test setup! | 13:00 |
| zyga | cool | 13:00 |
| zyga | mvo shall we merge it? | 13:01 |
| zyga | jdstrand hey | 13:01 |
| mvo | zyga: maybe we can look over it again just in case | 13:01 |
| zyga | I think pawel or chipaca could look | 13:02 |
| mvo | zyga: one independent review would be cool, maybe Chipaca or pstolowski | 13:02 |
| mvo | zyga: heh | 13:02 |
| zyga | :D | 13:02 |
| Chipaca | sure | 13:02 |
| zyga | it's funny, no? | 13:02 |
| Trevinho | ogra_: oh ok... It was my guess too after re-reading | 13:28 |
| Trevinho | Network observer should be enough though | 13:29 |
| ogra_ | Trevinho, yeah | 13:29 |
| Trevinho | But what we'd need is a connection status one | 13:29 |
| Trevinho | With auto connection | 13:29 |
| Trevinho | Although qt also needs to be fixed not to require too many infos | 13:29 |
| * kalikiana going out for lunch, back later | 13:31 | |
| jdstrand | zyga: hey | 13:49 |
| zyga | jdstrand hey, I added the validation we spoke about last night and I will add some more (about things we didn't talk about) | 13:49 |
| zyga | well, at least not yesterday | 13:49 |
| zyga | I think we mentioned this long ago but we didn't black-list /proc and other similar places | 13:50 |
| zyga | I will do that | 13:50 |
| jdstrand | zyga: more in that pr or more in a future pr? | 13:50 |
| zyga | I also merged master into jamesh branch | 13:50 |
| zyga | jdstrand it can be separate, it's not related to that PR directly | 13:50 |
| zyga | I will look at one function that was meant to validate if a mount operation worked | 13:51 |
| jdstrand | zyga: so, technically /proc isn't a security issue (since they are just putting something they already have read/write access to in there. it isn't going to fakeout the actual kernel), but it is going to be an error | 13:52 |
| jdstrand | in the snap if it is doing that | 13:52 |
| === ikey|afk is now known as ikey | ||
| jdstrand | zyga: so +1 on filtering /proc, /sys, /lost+found, and /dev | 13:53 |
| zyga | I agree but I think it's sensible to be conservative | 13:53 |
| zyga | oh | 13:53 |
| zyga | lost and found | 13:53 |
| zyga | good one | 13:53 |
| zyga | noted | 13:53 |
| jdstrand | /boot and /run probably also make sense | 13:53 |
| zyga | jdstrand as for 3963, I might look at splitting it to help | 13:53 |
| jdstrand | but, eh | 13:53 |
| jdstrand | we can always open it up more later, so seems safe to block these weird ones | 13:54 |
| zyga | yes, that's the principle I think | 13:54 |
| zyga | phase 1, conservative approach | 13:54 |
| * jdstrand nods | 13:54 | |
| jdstrand | as for 3963, thank you | 13:54 |
| jdstrand | it is *so* close | 13:55 |
| * zyga looks at `snap/validate.go:276:20: "compatiblity" is a misspelling of "compatibility"` and sighs | 13:55 | |
| niemeyer | pedronis: Yeah, we'd update it on every request, whether "maintenance" was set or not | 13:55 |
| niemeyer | pedronis: I think that reflects well the semantics on the server end | 13:56 |
| zyga | jdstrand the new validation logic resulting from last night's discussion is: https://github.com/snapcore/snapd/pull/4640/files#diff-b76be54ad28535ed9b0ac36a2851516eR240 | 13:57 |
| mup | PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640> | 13:57 |
| jdstrand | zyga: so, I'm seeing things like this: | 13:57 |
| jdstrand | if layout.Bind != "" { | 13:57 |
| jdstrand | if layout.BineFile != "" { | 13:58 |
| jdstrand | and I wonder why that isn't if/else if | 13:58 |
| zyga | no reason, but it doesn't change anything | 13:58 |
| jdstrand | which makes my wonder if this is not caught: | 13:58 |
| pstolowski | zyga, reviewed 4642 | 13:58 |
| jdstrand | /foo: | 13:58 |
| jdstrand | bind: ... | 13:58 |
| jdstrand | bind-file: ... | 13:59 |
| zyga | this is caught by existing validation that's older than this pr | 13:59 |
| zyga | you can barely see it ... | 13:59 |
| jdstrand | zyga: are there tests for it? | 13:59 |
| zyga | https://github.com/snapcore/snapd/pull/4640/files#diff-b76be54ad28535ed9b0ac36a2851516eR560 | 13:59 |
| mup | PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640> | 13:59 |
| cachio_ | pedronis, results on staing https://paste.ubuntu.com/26546594/ | 13:59 |
| cachio_ | still 6 tests failing | 13:59 |
| zyga | yes, though not for every possible combination | 14:00 |
| zyga | I can add more :) | 14:00 |
| zyga | it's been a learning exercise so far | 14:00 |
| zyga | https://github.com/snapcore/snapd/pull/4640/files#diff-0c50c794f66e17a6bf61861029a83e21R533 | 14:00 |
| zyga | actually I did, sorry, | 14:00 |
| zyga | I just see it in the diff now | 14:00 |
| jdstrand | zyga: right, so that isn't going to catch this: | 14:00 |
| jdstrand | /foo: | 14:00 |
| jdstrand | bind: ... | 14:00 |
| jdstrand | symlink: ... | 14:00 |
| zyga | no, it does | 14:00 |
| zyga | it catches it | 14:00 |
| zyga | you must use exactly one of the kind definers | 14:01 |
| jdstrand | oh nused | 14:01 |
| jdstrand | I was looking at something different | 14:01 |
| zyga | yeah, number of things used | 14:01 |
| jdstrand | if you can add a test for that, it would be great | 14:01 |
| zyga | yeah, I did for that exact case | 14:01 |
| jdstrand | I <3 negative tests | 14:01 |
| jdstrand | ok | 14:02 |
| zyga | https://github.com/snapcore/snapd/pull/4640/files#diff-0c50c794f66e17a6bf61861029a83e21R533 | 14:02 |
| mup | PR #4640: snap,interfaces: allow using bind-file layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4640> | 14:02 |
| zyga | I'm sure there are some things I didn't cover, I will go over it again | 14:02 |
| jdstrand | I'm looking only at a particular commit. I'll look at the whole thing again | 14:02 |
| zyga | I was thinking how to do the source validation and I was thinking about various options | 14:02 |
| zyga | I like one test | 14:02 |
| zyga | I'm sure you will love it | 14:02 |
| zyga | https://github.com/snapcore/snapd/pull/4640/files#diff-0c50c794f66e17a6bf61861029a83e21R744 | 14:02 |
| zyga | btw, what _is_ norf and corge? | 14:03 |
| jdstrand | I think it is too early for me to review the mind-bending '// Validate mutual compatiblity between otherwise valid layout elements.' | 14:03 |
| zyga | hehe | 14:03 |
| zyga | that means I can do something about lunch :) | 14:04 |
| jdstrand | zyga: extra meta vars beyond foo, bar, baz, qux, quux | 14:04 |
| zyga | jdstrand but are those dog naems? | 14:04 |
| zyga | *names | 14:04 |
| pedronis | cachio_: snap info seems to need some upload, searching might need uploads and store admin to set featured/sections in staging | 14:04 |
| jdstrand | norf certainly isn't | 14:04 |
| jdstrand | corge I've wondered on the pronunciation | 14:04 |
| jdstrand | looks like corg-y | 14:04 |
| jdstrand | I always pronounced it corj | 14:05 |
| pedronis | cachio_: create user is not finding mvo on staging, might have other issues as well, not sure | 14:05 |
| zyga | oh | 14:05 |
| zyga | wait, you found some dead code | 14:05 |
| pedronis | cachio_: I don't understand the refresh-amend error, it seems a test vs code mismatch | 14:05 |
| zyga | that mutual compatibility thing is supposed to be gone | 14:05 |
| * zyga yanks it | 14:05 | |
| jdstrand | thank goodness | 14:05 |
| pedronis | cachio_: I mean, it seems like an error message has changed | 14:05 |
| jdstrand | :) | 14:05 |
| cachio_ | pedronis, yes, it changed recently | 14:06 |
| cachio_ | I saw the same error on bionic | 14:06 |
| mvo | pedronis: uhh, why are we not seeing the error in other spread runs if its a real error due to code change? | 14:07 |
| pedronis | cachio_: probably we need to upload a newer core? | 14:07 |
| pedronis | other issues look like core is old | 14:08 |
| pedronis | I mean tests take core and change snapd etc in it | 14:08 |
| mvo | aha, ok | 14:08 |
| mvo | old core makes sense | 14:08 |
| mvo | sorry for the noise | 14:08 |
| pedronis | mvo: well, the amend one is not clear | 14:09 |
| pedronis | that is not related to pieces in core | 14:09 |
| pedronis | is a bit strange | 14:09 |
| pedronis | but I didn't get it either | 14:09 |
| pedronis | heere | 14:09 |
| pedronis | but xdg-* stuff looks like old core | 14:09 |
| cachio_ | pedronis, I'll run with the latests changes | 14:12 |
| pedronis | cachio_: I mean, it seems like we need to copy over a recent edge core to staging core edge | 14:13 |
| pedronis | cachio_: and we need some uploads/reuploads for snap-info | 14:13 |
| pedronis | cachio_: searching needs vlc and to talk with store people about setting some section/featured stuff in staging | 14:13 |
| cachio_ | pedronis, ah, ok, I'll update the core in staging | 14:14 |
| cachio_ | pedronis, is it ok if I just update for amd64? | 14:14 |
| cachio_ | do we need it on other archs? | 14:14 |
| pedronis | no just amd64 | 14:14 |
| pedronis | is fine | 14:14 |
| Chipaca | zyga: mvo: you now have too many reviews of #4642 | 14:15 |
| mup | PR #4642: many: add nfs-home flag to system-key <Created by zyga> <https://github.com/snapcore/snapd/pull/4642> | 14:15 |
| mvo | Chipaca: thanks, looking | 14:18 |
| kalikiana | re | 14:27 |
| jdstrand | zyga: hey, in case you didn't see, I commented on 4640 | 15:06 |
| zyga | yes, I'm responding now, thanks! :) | 15:07 |
| zyga | done | 15:07 |
| jdstrand | roadmr: hi! thanks for syncing r1000. to be clear, you will also update the list of packages to install? | 15:07 |
| roadmr | jdstrand: yes, that means the merge is a bit more involved than usual. I need to first land the dependency change and ensure it doesn't break staging, then merge the tools bump and test thoroughly | 15:08 |
| zyga | jdstrand so I think 4640 is good now, I will work on a new branch that makes special filesystem mount points off limits | 15:09 |
| zyga | pstolowski, Chipaca - thank you for the feedback | 15:11 |
| pstolowski | zyga, yw | 15:11 |
| Saviq | Trevinho: hey, should clicking on links in telegram-desktop work? | 15:13 |
| Saviq | seems to be NOOP here | 15:13 |
| Saviq | that's GNOME@Wayland@bionic | 15:14 |
| jdstrand | roadmr: right. I thought I remembered you saying something to that effect in cape town. thanks! | 15:14 |
| roadmr | jdstrand: np! no worries, we'll make this happen | 15:14 |
| jdstrand | roadmr: which is also why I went the more formal bug route :) | 15:15 |
| jdstrand | zyga: yep, approved. thanks! | 15:15 |
| zyga | wooot | 15:15 |
| zyga | thank you! | 15:15 |
| jdstrand | zyga: it's so close! | 15:15 |
| jdstrand | that and user mounts are going to rock | 15:15 |
| zyga | yeah, I need to jump onto user mounts | 15:16 |
| zyga | but I want to ensure we don't leak the poorly confined snap-update-ns | 15:16 |
| zyga | I need to finish that too | 15:16 |
| zyga | though it's super close, I have code for most of that now | 15:16 |
| zyga | just chopping and reviews | 15:16 |
| seb128 | Saviq, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1742687 maybe | 15:30 |
| mup | Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <AppArmor:New> <D-Bus:New> <snapd (Ubuntu):In Progress> <https://launchpad.net/bugs/1742687> | 15:30 |
| seb128 | Saviq, what snapd version do you use? the fix is in proposed only | 15:31 |
| Trevinho | Saviq: mh,they work here.... let me check | 15:31 |
| Trevinho | Saviq: what channel? | 15:31 |
| Trevinho | or revision, better | 15:31 |
| Saviq | Trevinho, seb128: http://paste.ubuntu.com/26546844/ | 15:32 |
| seb128 | Saviq, and snapd? | 15:32 |
| Trevinho | Saviq: you get anything on terminal? Also have you snapd-xdg-open or how it was called or not (I don't) | 15:33 |
| Saviq | 2.29.4.2+18.04 | 15:33 |
| seb128 | right, that doesn't include the fix | 15:33 |
| seb128 | see what I copied before | 15:33 |
| seb128 | try the snapd from bionic-proposed | 15:33 |
| Saviq | ack, tx | 15:33 |
| * Saviq tries | 15:34 | |
| seb128 | yw | 15:34 |
| seb128 | let we know if it fixes it | 15:34 |
| Trevinho | seb128: about that... | 15:34 |
| Trevinho | seb128: is there any reason why we don't want file:// ... protocol to work when the target is a directroy? | 15:34 |
| Trevinho | directory* | 15:34 |
| Trevinho | and then opening it with the file-manager? | 15:35 |
| Trevinho | as telegram requires that sometimes, and so other apps | 15:35 |
| Saviq | Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.1572" (uid=1000 pid=29767 comm="dbus-send --print-reply --session --dest=io.snapcr" label="snap.telegram-desktop.telegram-desktop (enforce)") interface="io.snapcraft.Launcher" member="OpenURL" error name="(unset)" requested_reply="0" destination="io.snapcraft.Launcher" (bus) | 15:35 |
| Saviq | Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files | 15:35 |
| Saviq | sry | 15:35 |
| Saviq | Trevinho: I don't see snapd-xdg-open, only xdg-open, and when ran inside `snap run --shell...` it does print ↑, as does Telegram itself | 15:37 |
| seb128 | Saviq, dunno what you needs to reload for the snapd update to work, maybe try rebooting? | 15:37 |
| Saviq | prolly apparmor profiles or something, will reboot in a mo | 15:37 |
| seb128 | Trevinho, that would be to check with the security team, I didn't give much thinking of the implications | 15:38 |
| Trevinho | mdeslaur: something is popping up in your mind? ^ | 15:38 |
| mup | PR snapd#4640 closed: snap,interfaces: allow using bind-file layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4640> | 15:38 |
| Trevinho | might be the case to ask to jdstrand too when back | 15:38 |
| mup | PR snapd#4643 opened: snap: disallow layouts in various special directories <Created by zyga> <https://github.com/snapcore/snapd/pull/4643> | 15:39 |
| zyga | jdstrand https://github.com/snapcore/snapd/pull/4643/files | 15:40 |
| mup | PR #4643: snap: disallow layouts in various special directories <Created by zyga> <https://github.com/snapcore/snapd/pull/4643> | 15:40 |
| zyga | that's the quick list | 15:40 |
| zyga | now I realized that mountedTree and mountedFile are exactly the same, I'll simplify them | 15:40 |
| mdeslaur | Trevinho: sorry, jdstrand would be best to answer that question | 15:40 |
| kalikiana | Damn my greedy organism, need to fetch more water. Don't want to take a break... | 15:41 |
| jdstrand | Saviq: the apparmor denial is because the service isn't started yet and the service file doesn't have the magic directive to make it work | 15:44 |
| zyga | jdstrand and https://github.com/snapcore/snapd/pull/4644 | 15:44 |
| mup | PR #4644: tests: add a spread test for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4644> | 15:44 |
| zyga | :-) | 15:44 |
| jdstrand | Saviq: I didn't read all of backscroll, but you need the dbus service file coming from an updated snapd *deb*. an updated core is not enough | 15:44 |
| mup | PR snapd#4644 opened: tests: add a spread test for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4644> | 15:44 |
| zyga | jdstrand both are pretty obvious +1's :) | 15:44 |
| jdstrand | zyga: ack | 15:45 |
| zyga | and with that I'm done on the quick branches | 15:46 |
| Saviq | jdstrand: I got snapd from proposed, do I need non-stable core? | 15:47 |
| jdstrand | Saviq: this is the pr: https://github.com/snapcore/snapd/pull/4495/files | 15:48 |
| mup | PR #4495: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4495> | 15:48 |
| jdstrand | Saviq: no, you shouldn't | 15:48 |
| Saviq | ack | 15:48 |
| * zyga takes an extended break | 15:50 | |
| jdstrand | Saviq: you have AssumedAppArmorLabel=unconfined in the service files? grep AssumedAppArmorLabel=unconfined /usr/share/dbus-1/services/io.snapcraft.* | 15:50 |
| jdstrand | Saviq: did you restart your session? | 15:50 |
| Saviq | not yet, doing that now | 15:51 |
| jdstrand | Saviq: I think you'll need to restart the session for it to take effect | 15:52 |
| Saviq | jdstrand: I rebooted, same problem | 15:59 |
| Saviq | and yes I do have this ↑↑ in the service files | 15:59 |
| jdstrand | Saviq: that's weird. mvo, iirc, you tested this ^ | 16:04 |
| jdstrand | Saviq: are there any apparmor denials in the logs? | 16:04 |
| Saviq | jdstrand: not in dmesg, yes on the console | 16:04 |
| Saviq | exactly what's mentioned in the bug | 16:05 |
| jdstrand | Saviq: don't look at dmesg, look at journalctl (dbus denial for the session bus are logged through syslog, not the audit system) | 16:05 |
| * jdstrand fires up a vm | 16:06 | |
| Saviq | lut 09 17:07:23 michal-laptop dbus-daemon[6341]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/io/snapcraft/Launcher" interface="io.snapcraft.Launcher" member="OpenURL" mask="send" name="io.snapcraft.Launcher" pid=2 | 16:07 |
| Saviq | 1423 label="snap.telegram-desktop.telegram-desktop" | 16:07 |
| Saviq | jdstrand: ↑ | 16:07 |
| jdstrand | Trevinho: https://forum.snapcraft.io/t/allowing-xdg-open-to-open-files/3789/1 | 16:07 |
| Saviq | (among a guanoload of gnome shell stack traces...) | 16:08 |
| jdstrand | Saviq: can you paste /var/lib/snapd/profiles/snap.telegram-desktop.telegram-desktop ? | 16:08 |
| Saviq | jdstrand: https://paste.ubuntu.com/26546956/ | 16:09 |
| Trevinho | jdstrand: ok, fair... I just was wondering if there some explication on file + directory path though. As I can see that a single file might be different,but a trusted file-manager could be a different thing | 16:09 |
| Trevinho | or just always opening file:// with the file-manager so that it only selects the file, then it's up to the user to open it | 16:09 |
| Trevinho | as an interim solution to portals | 16:10 |
| jdstrand | Trevinho: feel free to add a comment about opening a directory. I suspect that is a bit trickier since userd is launching the file manager, not the snap, so the filemanager would somehow need to pass on open fd or the security policy would need to be adjusted to allow the open if only the filename is passed back | 16:12 |
| jdstrand | Trevinho: which is what portals aims to address | 16:13 |
| jdstrand | Trevinho: if you have details on how it could work with existing confinment, please share. note that portals is closer than you might think | 16:13 |
| Trevinho | jdstrand: wait, I'm not talking of opening a dir... but showing a file in a dir, does it need to send bak anything? | 16:13 |
| Trevinho | jdstrand: I just would like something like the xdg-open does for a browser, but doing it using the file-manager instead | 16:14 |
| jdstrand | Trevinho: a snap calls xdg-open on a dir. userd opens nautilus. how does the snap get access to the file the user chooses? | 16:14 |
| Trevinho | No, it has not to choose | 16:14 |
| Trevinho | like in telegram, when you download a file... It says: "show it on folder" and it would open the filemanager at that position | 16:15 |
| Trevinho | like firefox does when you do "open on dir".. or similra | 16:15 |
| Trevinho | containing dir I mean | 16:15 |
| jdstrand | isn't that when people normally call xdg-open with a dir? this came up in another forum post where a snap was doing precisely this (a poor man's file chooser) | 16:15 |
| jdstrand | Trevinho: that specific case would be fine imo | 16:15 |
| jdstrand | Trevinho: please comment in the topic. (we want to allow file:// for userd, there is just some work to be done to make sure it is sane. perhaps dir is the first use case) | 16:16 |
| Trevinho | we can just redirect all the file://path/foo to call org.freedesktop.filemanager to only show content | 16:16 |
| Trevinho | so it won't be any dangerous | 16:16 |
| Trevinho | there's a ShowItems call which does it.. | 16:17 |
| jdstrand | opening a dir so the user can choose the file to open with whatever mime handler is available is totaly fine imo | 16:17 |
| Trevinho | ok | 16:17 |
| Trevinho | cool | 16:17 |
| Trevinho | jdstrand: I could also contribute if you guide me, or... I can leave things to you guys happylier too :D | 16:18 |
| jdstrand | I mean, there are phishing attacks where a bad snap could present a directory it controls with malicious stuff and try to get the user to click stuff | 16:18 |
| jdstrand | Trevinho: present your ideas in the forum and once there is general agreement, I think pursuing a PR is fine. /me isn't tasked with implementing this, but would review the PR | 16:19 |
| Trevinho | jdstrand: mh, right... that's indeed a different thing. However, it's also true that this might happen with a browser too | 16:20 |
| jdstrand | very much so | 16:21 |
| jdstrand | we'll want to think about that case so that we make an active decision about it | 16:21 |
| jdstrand | as in, we ignore that or we try to do something about it | 16:21 |
| jdstrand | it is fun to think about pointing a url at a snap's httpd if the user goes to say, bank of america | 16:22 |
| jdstrand | the browser has protections on that though-- like, you clearly see the url, EV certs, https verification, etc | 16:24 |
| jdstrand | we might be able to rationalize doing nothing if the file browser is clear | 16:24 |
| Trevinho | it's beauty of it... Break the system, but your container is the system :D | 16:36 |
| cachio_ | mvo, is it ok if I register your suer in staging store? | 16:42 |
| mvo | cachio_: sure | 16:42 |
| cachio_ | tx | 16:42 |
| cachio_ | mvo, perhasps you need to do it | 16:43 |
| cachio_ | is it requesting ubuntu one authentication | 16:43 |
| mvo | cachio_: in a meeting right now, lets talk in 10min | 16:44 |
| cachio_ | mvo, we need the user with email: mvo@ubuntu.com | 16:44 |
| cachio_ | mvo, np | 16:44 |
| mvo | cachio_: whats the store url? where do I need to register | 16:44 |
| cachio_ | mvo, https://login.staging.ubuntu.com/BERkIKYcyn847YYR/+login | 16:45 |
| mvo | cachio_: or, the next silly question, what is the staging store url? | 16:53 |
| mvo | cachio_: https://dashboard.staging.snapcraft.io/snaps/ - I guess? | 16:53 |
| pstolowski | pedronis, i've just addressed the missing bit in autoconnect-tasks PR | 16:54 |
| mvo | cachio_: ok, I should be registered now | 16:54 |
| cachio_ | mvo, tx | 16:55 |
| * kalikiana wrapping up for EOD/ EOW | 17:05 | |
| cachio_ | mvo, https://paste.ubuntu.com/26547147/}Getting this error in staging | 17:17 |
| cachio_ | mvo, creating your user | 17:17 |
| cachio_ | mvo, any idea why it did not work after you registered it? | 17:17 |
| pstolowski | eow o/ | 17:20 |
| mvo | cachio_: hm, no idea, also error 500 sounds strange, probably worth talking to the store people about it | 17:25 |
| mup | PR snapd#4645 opened: snapctl: allow `snapctl get` from any uid <Created by mvo5> <https://github.com/snapcore/snapd/pull/4645> | 17:26 |
| jdstrand | Saviq (cc seb128): I was wrong. so, the snapd deb only adds the magic to the Settings service file. if you install the core snap from candidate, it has the updates for both Settings and Launcher, and snapd puts it into place in /usr/share/dbus-1/services | 17:30 |
| jdstrand | Saviq: put another way: snap refresh --candidate core, restart your session and it should work | 17:30 |
| jdstrand | Saviq: I just verified with the spotify snap | 17:30 |
| Saviq | Ack! | 17:40 |
| * diddledan makes his presence known by pretending to be a zombie | 17:47 | |
| * ikey sets fire to ctrl+z | 17:57 | |
| diddledan | ikey: that sounds like you made a booboo | 18:01 |
| diddledan | ? | 18:01 |
| ikey | no i was protecting against future zombies | 18:01 |
| diddledan | I refuse to use nano because it encourages me to remember ctrl+w as the "find" feature, and then I close random windows when I'm trying to find in other apps | 18:02 |
| ikey | lol | 18:02 |
| * ikey only uses nano for CLI editing | 18:02 | |
| ikey | well that and "echo blah >>" | 18:02 |
| === alan_g is now known as alan_g|EOW | ||
| jdstrand | mvo: you might be interested in what I mentioned to Sav iq ^. basically, what is in bionic-proposed doesn't have the full fix for the launcher not launching. core from candidate does fix things up though | 18:05 |
| mvo | jdstrand: oh, that is good to know, thank you | 18:20 |
| mvo | jdstrand: hm, i downloaded the bionic-proposed deb and checked io.snapcraft.{Launcher,Settings}.service in gdebi and they have the AssumedApparmorLabel=unconfined | 18:28 |
| Chipaca | ikey: CLI editing, as in "oh this command is getting too long, ^X^E"? | 18:31 |
| ikey | oh i dont vim | 18:33 |
| ikey | or emacs | 18:33 |
| ikey | also in my head emacs is a hair removal cream | 18:33 |
| ikey | so im totally avoiding it | 18:33 |
| jdstrand | mreed: that... is weird. I specifically uploaded to snapd in bionic-proposed and only saw it in settings (this was in a vm). I'm confused | 18:37 |
| jdstrand | updated* | 18:37 |
| jdstrand | mreed: nvm | 18:38 |
| Pharaoh_Atem | :P | 18:41 |
| mup | Bug #1748510 opened: shell's test gives false positive on readability of files <Snappy:New> <https://launchpad.net/bugs/1748510> | 18:46 |
| === ikey is now known as ikey|afk | ||
| Chipaca | ikey|afk: ^X^E on bash opens $EDITOR on current commandline | 19:13 |
| Chipaca | ikey|afk: completely unrelated question: is solus' encrypted home a LUKS thing, or is it something more weird? | 19:13 |
| ikey|afk | luks | 19:14 |
| ikey|afk | we dont do encrypted home, only FDE | 19:14 |
| ikey|afk | in future we'll support more specific schems | 19:14 |
| ikey|afk | *scherms | 19:14 |
| Chipaca | right, encrypted home partition | 19:14 |
| ikey|afk | .. | 19:14 |
| ikey|afk | *schemes | 19:14 |
| ikey|afk | no i mean the entire thing is encrypted | 19:14 |
| ikey|afk | its only supported in full disk mode on our installer right now | 19:14 |
| ikey|afk | cuz laziness | 19:14 |
| ikey|afk | but yeah its just normal LUKS | 19:15 |
| Chipaca | cool | 19:15 |
| ikey|afk | ok im gonna dash, gotta go make myself look hooman for tonight | 19:15 |
| ikey|afk | might take a while ... | 19:15 |
| cachio_ | pedronis, all the tests passing in staging now | 19:39 |
| === ryebot is now known as ^ | ||
| === ^ is now known as Guest51007 | ||
| === Guest51007 is now known as ryebot | ||
| mup | PR snapcraft#1904 closed: lxd: raw.idmap expects host and container id respectively <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1904> | 21:23 |
| mup | PR snapcraft#1913 closed: elf: pyelftools to parse ELF files rather than readelf <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1913> | 21:23 |
| pedronis | cachio_: thank you | 21:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!