| === dkessel_ is now known as dkessel | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === pstolowski|afk is now known as pstolowski| | ||
| pstolowski| | mornings | 07:03 |
|---|---|---|
| === pstolowski| is now known as pstolowski | ||
| zyga | good morning! | 07:10 |
| zyga | I'll start later as today is the market day so we need to go and buy groceries | 07:10 |
| zyga | and my wife should not carry and heavy things anymore so I need to help | 07:11 |
| zyga | hey Pawel :) | 07:11 |
| zyga | ok, I did most of the heavy lifting now | 08:02 |
| pstolowski | zyga: enumerating existing device as udev knows them is... problematic. now i understand why all the go udev implementations are cgo wrappers around libudev | 08:15 |
| pstolowski | zyga: and go-udev might be the only native go, except it doesn't really use udev stuff :/ | 08:16 |
| pstolowski | zyga: parsing the output of `udevadm info -e` (exports udev database in a simple key=value format) might be one of the better options | 08:18 |
| zyga | pstolowski: can you tell me more please? | 08:18 |
| zyga | pstolowski: specifically what is problematic? | 08:18 |
| zyga | pstolowski: what is the format natively used by udev? | 08:21 |
| pstolowski | zyga: /var/run/udev/* has simple flat text files - one for every device/node it seems, and it's very bare. it doesn't have all devices it seems, e.g. when i plug a serial adapter it doesn't appear there, it seems udev keeps it in-memory only. to enumerate existing devices via udevadm you either query specific ones by names/paths, or just dump everything with `udevadm -e` and there is tons of logic in libudev when it | 08:36 |
| pstolowski | enumerates | 08:36 |
| zyga | pstolowski: and when you subscribed to the other netlink group and started to parse events, what kind of data was broadcast there? | 08:40 |
| pstolowski | zyga: only the devices that get plugged since i subscribed | 08:42 |
| zyga | aha, I see | 08:42 |
| pstolowski | zyga: so it's two worlds to deal with | 08:42 |
| zyga | so the problem is how to enumerate existing data set, | 08:42 |
| pstolowski | zyga: yes | 08:42 |
| zyga | I see | 08:42 |
| pstolowski | zyga: the way i see it for the moment: | 08:42 |
| pstolowski | zyga: we either subscribe to netlink for hotplug events, and parse udevadm to enumerate existing devices; or we just parse udevadm output for both cases (bonus is it's the same output format to parse then, then we don't actually need go-udev anymore); or we switch to some other go-udev implementation based on cgo+libudev | 08:45 |
| zyga | I think cgo+libudev is strongly undesired | 08:45 |
| zyga | because libudev has unstable protocol | 08:45 |
| zyga | and this would complicate re-exec seriously | 08:45 |
| zyga | we need to think how to approach the problem | 08:46 |
| zyga | can you look into what libudev C code does? | 08:46 |
| zyga | so that we understand the on-disk data format | 08:46 |
| zyga | and the current on the wire format | 08:46 |
| zyga | it seems that we could indeed run udevadm --monitor and just feed of that pipe | 08:48 |
| zyga | but not sure | 08:48 |
| zyga | this is something to discuss with gustavo IMO | 08:48 |
| pstolowski | zyga: yep, i'll look into libudev more. also, the parsing of netlink data from udev is questionable and might have potential to break. they have a custom header (a bunch of ints, one of them tells you the offset where actual data starts). this header is *private* to the libudev/udevdaemon, it means it's a contract between libudev/udev basically and can change at any time (they don't even care about endianess there). so | 08:55 |
| pstolowski | even monitoring via netlink has a risk of breaking | 08:55 |
| zyga | pstolowski: I think we need to (realistically) support every wire format used by udev since Ubuntu 14.04-era onwards | 08:55 |
| zyga | pstolowski: it is either that or parsing of (potentially equally fragile) text representation from udevadm | 08:56 |
| zyga | pstolowski: or writing our own udev and shoving it into early boot | 08:56 |
| zyga | (initrd) | 08:56 |
| pstolowski | oh noes | 08:59 |
| Chipaca | pstolowski: ? | 09:00 |
| pstolowski | Chipaca: that's in response to what zyga suggested re own udev | 09:01 |
| Chipaca | pstolowski: we'll write our own udev, with blackjack and hooks | 09:04 |
| pstolowski | zyga: fwtw the text repr of udevadm looks quite stable due to its simplicity. but yes, it's all fragile | 09:10 |
| zyga | pstolowski: yeah, all --porcelain | 09:18 |
| zyga | Chipaca: lol | 09:18 |
| zyga | Chipaca: on the other hand I'm very much happy to write one if we choose to | 09:18 |
| zyga | Chipaca: if we choose to do this we must mask it as something entirely non-udev like so that phoronix won't notice ;-) | 09:24 |
| pstolowski | :) | 09:25 |
| Chipaca | call it µdev | 09:26 |
| zyga | Chipaca: ooooh, I love it! | 09:27 |
| zyga | Chipaca: can I can I can I? :D | 09:27 |
| Chipaca | it looks like I'll never have time to do µubuntu, so, sure | 09:27 |
| zyga | moobuntu for livestock | 09:29 |
| zyga | but it would have to use apt for packaging, it is so apt | 09:29 |
| niemeyer | Mornings | 09:33 |
| zyga | hey hey | 09:33 |
| pstolowski | morning niemeyer ! | 09:34 |
| niemeyer | pstolowski: Heya | 09:34 |
| pstolowski | niemeyer: some interesting findings re udev, go-udev etc., we will need to meet and take some decisions | 09:38 |
| niemeyer | pstolowski: Sounds good, let's try after the standup today | 09:39 |
| zyga | niemeyer: we have the core 18 meeting then | 09:39 |
| niemeyer | pstolowski: I'm hoping for a slightly shorter meeting as we have less people | 09:45 |
| zyga | ah, indeed | 09:45 |
| zyga | we should have plenty of time in between | 09:45 |
| pstolowski | sure | 09:45 |
| mup | PR snapd#5490 opened: store: make snap blobs be 0600 <Created by chipaca> <https://github.com/snapcore/snapd/pull/5490> | 10:27 |
| Chipaca | ^ should be an easy one to review | 10:30 |
| zyga | done | 10:33 |
| pstolowski | Chipaca: +1, with a suggestion | 10:41 |
| Chipaca | pstolowski: your suggeestion wouldn't catch seeds though | 10:41 |
| pstolowski | Chipaca: right, i didn't know it was supposed to; $(find /var/lib/snapd/{cache,snaps,seed/snaps} then; but, nvm | 10:44 |
| * zyga is happy now | 10:48 | |
| zyga | all the remapping is tested and can be proposed now | 10:48 |
| niemeyer | pstolowski: Have you seen the note on #5488? | 10:48 |
| mup | PR #5488: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <https://github.com/snapcore/snapd/pull/5488> | 10:48 |
| pstolowski | niemeyer: yes, thanks, will respond | 10:50 |
| pstolowski | replied and closed | 10:58 |
| mup | PR snapd#5488 closed: tests/interfaces-contacts-service: use random XDG dir via mktemp <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5488> | 10:58 |
| niemeyer | pstolowski: What's the status of #4940? | 11:03 |
| mup | PR #4940: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940> | 11:03 |
| === chihchun is now known as chihchun_afk | ||
| pstolowski | niemeyer: i'm hitting various issues with it on existing spread tests; no clear pattern, various failures inluding kill timeouts. no idea why, there is no clear indication in the logs pointing at my changes (but oviously they are the suspect), and just re-runiing a failing test locally doesn't reproduce the failure | 11:09 |
| pstolowski | niemeyer: in any case, in the light of what i'd like to discuss today i might need to make changes | 11:10 |
| niemeyer | pstolowski: Are we seeing the same errors on master? | 11:12 |
| pstolowski | niemeyer: no, except ocasionally with flaky tests | 11:14 |
| niemeyer | pstolowski: We've seen kill timeouts on master before, but my understanding is that those were related to core and were fixed | 11:14 |
| pstolowski | niemeyer: yes. but not at the rate i see on my PR | 11:15 |
| pstolowski | niemeyer: i basically didn't have a succesful run on this PR yet | 11:15 |
| niemeyer | pstolowski: If you're wondering about whether it's your PR's fault, I suggest breaking it down into smaller chunks, and pushing it so we can review and merge until we hit something suspicious | 11:15 |
| niemeyer | pstolowski: In fact, given how long that's been up for review and the long history of merges, that might be a good idea either way | 11:16 |
| niemeyer | pstolowski: It feels like that's been blocked for months now | 11:16 |
| Chipaca | cp: not writing through dangling symlink 'squashfs-root/usr/bin/snapctl' | 11:16 |
| Chipaca | ^ anybody seen those before now? | 11:17 |
| niemeyer | Chipaca: No, but that's pretty nice actually | 11:17 |
| niemeyer | Chipaca: In terms of cp not doing that, I mean | 11:18 |
| pstolowski | niemeyer: the biggest suspect is plugging go-udev in.. which is the meat of this PR. I can probably split it into two PRs - some scaffolding, and then actually plugging it in | 11:18 |
| niemeyer | Chipaca: We've recently merged a PR from mvo that changed the way this worked.. | 11:18 |
| niemeyer | Chipaca: It wasn't a symlink before | 11:18 |
| niemeyer | Chipaca: by recently I mean yesterday :) | 11:18 |
| niemeyer | pstolowski: I don't see go-udev in that RP | 11:18 |
| niemeyer | PR | 11:18 |
| niemeyer | pstolowski: Maybe that's why it's failing? :) | 11:19 |
| pstolowski | niemeyer: and it was blocked for long time by go-udev dependency.. which got resolved ~2 weeks ago by incorporating go-udev | 11:19 |
| pstolowski | niemeyer: no, go-udev package landed | 11:19 |
| niemeyer | pstolowski: Ah, ok | 11:19 |
| pstolowski | this PR actually makes use of it | 11:19 |
| niemeyer | pstolowski: Ok.. how about this.. can we close it and get smaller PRs in, oriented after whatever we discuss today? | 11:19 |
| niemeyer | pstolowski: We need to start flowing bits in | 11:20 |
| pstolowski | niemeyer: okay. fwtw a few small bits landed already | 11:20 |
| pstolowski | niemeyer: anyway.. the topic to discuss today might be a tough nut to crack for this entire story | 11:21 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | niemeyer: hmm. I wonder if master is broken because of this, then. Pretty consistent anything-but-ubuntu-16+ broke in the same way with my pr (but maybe it's my pr) | 11:22 |
| * Chipaca running spread from master now | 11:22 | |
| niemeyer | pstolowski: Cool | 11:24 |
| niemeyer | Chipaca: I received mixed broken/not-broken messages from Travis yesterday.. wouldn't be entirely surprising if something that got landed isn't entirely right given prior merges | 11:24 |
| niemeyer | Chipaca: This is the relevant PR: #5375 | 11:26 |
| mup | PR #5375: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375> | 11:26 |
| niemeyer | jdstrand: Gentle ping about #4951.. no rush, just want to make sure it's featured somewhere in your list still | 11:27 |
| mup | PR #4951: interfaces/screenshot: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951> | 11:27 |
| mup | PR snapd#5491 opened: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491> | 11:33 |
| Chipaca | niemeyer: yep, master broken | 11:35 |
| niemeyer | Chipaca: Well, at least it's a well known cause for once | 11:36 |
| mup | PR snapd#5492 opened: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492> | 11:36 |
| Chipaca | niemeyer: grmbl grmbl grmbl | 11:36 |
| niemeyer | Chipaca: Any ideas given what you've seen? | 11:36 |
| Chipaca | niemeyer: replace «cp -a /usr/bin/snap /usr/bin/snapctl squashfs-root/usr/bin/» with something that's mindful of the symlink | 11:37 |
| === chihchun is now known as chihchun_afk | ||
| niemeyer | Chipaca: Hmm | 11:38 |
| * zyga proposed the interface re-mapping integration PR and the first of the tree patches :) | 11:38 | |
| niemeyer | Chipaca: The error is likely that we're doing that twice | 11:38 |
| niemeyer | Chipaca: I mean, that command, if done twice, will fail on /usr/bin/snapctl | 11:38 |
| * niemeyer tests the theory | 11:39 | |
| zyga | niemeyer: didn't we change the base snap by now? | 11:39 |
| Chipaca | niemeyer: I don't think so, I think it's that core already has a symlink there | 11:39 |
| zyga | so maybe base and the test support is doing the same thing now | 11:39 |
| zyga | I can now start looking at existing PRs | 11:40 |
| niemeyer | Chipaca: Yeah, but there's something that doesn't smell right there | 11:40 |
| * zyga catches up with IRC | 11:40 | |
| * Chipaca takes a shower | 11:40 | |
| niemeyer | Chipaca: "cp -a" works on symlink over symlink | 11:41 |
| Chipaca | niemeyer: *dangling* symlink is key i think | 11:41 |
| niemeyer | Chipaca: This is copying a file over a symlink | 11:41 |
| zyga | pedronis: would you have time to review 5492, you did an earlier iteration of the idea | 11:42 |
| zyga | pedronis: I have it fully fleshed out now | 11:42 |
| pedronis | I'll look at it later today (it's a couple of nights that I'm not sleeping well and it makes me a bit slow) | 11:43 |
| Chipaca | niemeyer: ok, so new hypothesis: coreutils change the behaviour of cp over dangling symlink, which is why it fails in 14.04 but not 16+, and presuambly fedora and opensuse have the old one | 11:43 |
| Chipaca | hmm, that sounds wrong, fedora usuallly ship bleeding edge coreutils | 11:43 |
| * Chipaca runs the test on fedora to check | 11:43 | |
| pedronis | Chipaca: anyway , it's probably more complicated than that becausee if we have snapd and core18, we want to change snapd, not the symlink in core18 | 11:44 |
| pedronis | I'm not quite sure how far we are in that | 11:44 |
| Chipaca | niemeyer: actually, in 16.04, cp -a refuses to copy over a dangling symlink | 11:44 |
| zyga | pedronis: thank you and take care, sleep is like credit, you have to pay back eventually | 11:44 |
| niemeyer | Chipaca: I don't get what changes in the last few days for this logic to be broken now, but the logic does look broken indeed | 11:45 |
| === chihchun_afk is now known as chihchun | ||
| Chipaca | niemeyer: /usr/bin/snapctl became a symlink | 11:45 |
| Chipaca | niemeyer: you yourself told me :-D | 11:46 |
| niemeyer | Chipaca: I mean, the rm right above it removes snapctl from /usr/lib/snapd.. the follow up command then copies it into a different place | 11:46 |
| zyga | niemeyer: new core snap was built? | 11:46 |
| mup | PR snapd#4940 closed: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4940> | 11:46 |
| niemeyer | Chipaca: It's just inconsistent... I suggest fixing it by removing *both* /usr/bin/snapctl and /usr/lib/snapd/snapctl, and copying *both* back | 11:46 |
| niemeyer | Chipaca: The rm will likely have to be -f | 11:46 |
| Chipaca | niemeyer: I'll give you a clearer picture of the failure in a bit (test spinning up) | 11:47 |
| niemeyer | Chipaca: It's a bit uncertain because we're dealing with an external core | 11:47 |
| niemeyer | Chipaca: Actually, that's likely where the failure comes from | 11:48 |
| niemeyer | Chipaca: The passing code expected a previous core from edge.. once the PR was merged, the logic in the test became incompatible with the logic that was merged, somewhat ironically | 11:48 |
| Chipaca | niemeyer: so, snapctl needs to be in libexec, and the one in bin a symlink to it, right? | 11:53 |
| Chipaca | as per #5375 | 11:53 |
| mup | PR #5375: packaging: put snapctl into /usr/lib/snapd and symlink in usr/bin <Core18> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5375> | 11:54 |
| Chipaca | lynch! launch! lunch! | 12:01 |
| niemeyer | Chipaca: Not libexec, lib/snapd | 12:06 |
| Chipaca | niemeyer: http://paste.ubuntu.com/p/jq8nw6H8q2/ | 12:07 |
| niemeyer | Ah, nevermind.. we put that in libexec in some distros | 12:07 |
| niemeyer | Chipaca: Typo in usrs | 12:08 |
| Chipaca | dammit | 12:08 |
| Chipaca | niemeyer: ta | 12:08 |
| niemeyer | Chipaca: No need for the -f I think.. I missed the fact it was a * when reading the output | 12:08 |
| === pstolowski is now known as pstolowski|lunch | ||
| niemeyer | Chipaca: Looks good | 12:10 |
| mup | PR snapd#5493 opened: tests: prepare needs to handle bin/snapctl being a symlink <Created by chipaca> <https://github.com/snapcore/snapd/pull/5493> | 12:25 |
| jdstrand | niemeyer: thanks for the reminder. I had it as blocked in the list so I fixed that | 12:41 |
| * zyga focuses on core18-tests3 for now | 12:42 | |
| === pstolowski|lunch is now known as pstolowski | ||
| zyga | hey jdstrand | 12:55 |
| zyga | how are you doing? | 12:56 |
| zyga | jamesh: hey | 12:58 |
| zyga | I saw some tweets from the conference | 12:58 |
| zyga | how are you doing? | 12:58 |
| zyga | jamesh: anything interesting to share? | 12:58 |
| Chipaca | a curse on google:ubuntu-16.04-64:tests/main/interfaces-accounts-service | 12:58 |
| Chipaca | was anybody looking into that one? | 12:59 |
| jamesh | zyga: hi. I had a chat with the flatpak/xdg-desktop-portal guys this morning during a BoF about improving support for snaps | 12:59 |
| zyga | Chipaca: mmmm, perhaps pstolowski but I don't remember for sure | 12:59 |
| Chipaca | jamesh: zyga: so much paella | 13:00 |
| jamesh | zyga: we want to provide more info about a snap to xdg-desktop-portal, but don't want to add a new dependency, so the current plan is to add a new "snap" sub-command that returns the info in a machine readable format (probably keyfile or yaml), and have xdg-desktop-portal call that | 13:01 |
| jamesh | zyga: probably passing the AppArmor security label as an argument, and maybe also process ID | 13:01 |
| jamesh | zyga: the extra info I want is the desktop file ID for the confined app, and whether it has the network interface plugged | 13:02 |
| jamesh | there might be more in future | 13:02 |
| Chipaca | zyga: https://github.com/tremby/imgur.sh | 13:02 |
| zyga | thank you! | 13:03 |
| jamesh | Chipaca: we did have paella at the beach party, yeah. | 13:03 |
| Son_Goku | jamesh, why would the AppArmor sec label matter? | 13:03 |
| zyga | jamesh: neat | 13:03 |
| Son_Goku | and that wouldn't be particularly useful when that isn't available (e.g. Fedora, CentOS) | 13:04 |
| Son_Goku | I'd also suggest using either keyfile or json | 13:04 |
| Son_Goku | those are a lot less brittle | 13:04 |
| jamesh | Son_Goku: at the moment, xdg-desktop-portal won't detect a snap as confined without the security label | 13:05 |
| Son_Goku | jamesh, could you do it in a more generic fashion? | 13:05 |
| Son_Goku | I don't understand why the AppArmor label is required specifically for this | 13:06 |
| Son_Goku | that defeats the abstraction between AppArmor and the sandboxing control | 13:06 |
| jdstrand | hey zyga. pretty good, how are you? | 13:07 |
| zyga | jdstrand: I'm good, enjoying the time with my family in the woods, | 13:08 |
| zyga | I'll be in Montreal next week, are you going? | 13:08 |
| jdstrand | nice! yes, I'll be there | 13:08 |
| zyga | jamesh: I'd love to know what your plans are after the event, let me know if you think it would be useful to sync _during_ the event so that you can still discuss ideas with the flatpak team | 13:09 |
| jamesh | Son_Goku: the AppArmor label was the most obvious way to detect that the application really was a confined snap (rather than a flatpak, or an unconfined app). What would you suggest for systems without strict confinement? | 13:10 |
| Son_Goku | jamesh, snap-confine has "grades" of confinement, which could be passed to xdg-desktop-portal | 13:11 |
| zyga | jamesh: we could look at the root filesystem of the mount namespace | 13:11 |
| zyga | jamesh: and see if it is /var/lib/snapd/snap/* or /snap/* | 13:12 |
| zyga | jamesh: this could be used as a fallback in case the apparmor label is problematic in any way | 13:12 |
| jamesh | Son_Goku: for reference, this is the information dbus-daemon gives us to make the decision: https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-get-connection-credentials | 13:12 |
| jamesh | Son_Goku: I meant strict confinement as in what "snap debug confinement" prints | 13:13 |
| jamesh | Son_Goku: that will say "strict" on systems where we have MAC controlling file system access and mediated D-Bus communication | 13:14 |
| Son_Goku | that means it'll fail in partial confinement situations | 13:14 |
| Son_Goku | which is basically everyone except Ubuntu | 13:14 |
| Son_Goku | (and Solus) | 13:14 |
| jamesh | zyga: so I guess the solution to ever problem ends up being "parse the mountinfo file" :) | 13:15 |
| zyga | jamesh: no, you can really just read one symlink in proc | 13:15 |
| zyga | it's nicer than mountinfo :) | 13:15 |
| zyga | jamesh: AFAIR /proc/$PID/root | 13:16 |
| jamesh | oh | 13:16 |
| zyga | and then match against two patterns | 13:16 |
| zyga | thigh AFAIR the symlink value is dynamic depends on the POV of the beholder, so if you are "inside" it will always have a value of /snap/* (needs checking) | 13:17 |
| jdstrand | fyi, that's overstated-- there are quite a few distros that have it where snapd is supported. @popey provided me with a list recently | 13:17 |
| jamesh | zyga: hmm. readlink() on that returns "/" | 13:17 |
| zyga | jamesh: ah, that's not useful then :/ | 13:17 |
| * jdstrand is referring go "< Son_Goku> which is basically everyone except Ubuntu (and Solus)" | 13:18 | |
| zyga | from the outside it would be different but it makes sense to be / on the inside | 13:18 |
| jdstrand | to* | 13:18 |
| Son_Goku | jdstrand, dbus mediation isn't upstream | 13:18 |
| jamesh | zyga: it is a magic proc symlink, so doing open() on it would give a dir fd for the confined root. I'm not sure how to convert that to the root file system though | 13:18 |
| jdstrand | Son_Goku: dbus mediation *is* upstream in dbus. the kernel feature not yet, but is super close | 13:18 |
| zyga | jamesh: I see, well, I'm offering to help if you need to discuss something and think I could be useful | 13:19 |
| jdstrand | Son_Goku: I'm not arguing against your point of having to deal with partial confinement like Debian/OpenSUSE or devmode like Fedora, I was just clarifying your specific comment on 'only Ubuntu (and Solus)' | 13:20 |
| Son_Goku | for full confinement, that's it, though | 13:20 |
| jdstrand | Son_Goku: no, it isn't. that is my point. popey showed me a list recently | 13:21 |
| Son_Goku | and that list is?! | 13:21 |
| jdstrand | I'll let popey comment since I would have to dig around for it. if he doesn't have it at hand, I will do that | 13:22 |
| popey | It's just a list of distros I've booted in a vm and run hello-world.evil to see if confinement works | 13:22 |
| popey | i replied citing them in a thread on the forum | 13:23 |
| jamesh | zyga: if there's anything more you'd like me to bring up, there's still another day of the conf. Getting the in-principle support for the "call snap as a subprocess" solution was a good start | 13:24 |
| === robert_ancell_ is now known as robert_ancell | ||
| jamesh | (and is probably the first step towards something that will work better on Fedora, etc too) | 13:24 |
| jamesh | given what's currently in xdg-desktop-portal relies exclusively on AppArmor security labels | 13:25 |
| zyga | jamesh: one thing that we can do that's simple | 13:25 |
| zyga | jamesh: snapctl | 13:25 |
| popey | jdstrand / Son_Goku https://forum.snapcraft.io/t/joystick-connection-request-for-xonotic/6244/7 the post in question | 13:25 |
| zyga | jamesh: snapctl uses a cookie to talk to snapd as a given snap | 13:25 |
| Son_Goku | popey, you proved my point | 13:25 |
| zyga | jamesh: so it could be there, regardless of confinement we would be able to present meta-data about the snap being executed | 13:25 |
| popey | Son_Goku: I don't know what point I proved :) | 13:25 |
| jamesh | zyga: where is the cookie? | 13:25 |
| zyga | jamesh: I think it is in the environment | 13:25 |
| Son_Goku | jdstrand, popey's list boils down to Ubuntu and Solus | 13:26 |
| zyga | jamesh: so running snapctl from inside a snap "authorizes" it as the snap | 13:26 |
| Son_Goku | all the various Ubuntu flavors are a distinction without a difference | 13:26 |
| popey | elementary, KDE Neon and Linux Mint are not flavours. | 13:26 |
| Son_Goku | but they are derived from Ubuntu and do not change anything about Ubuntu in that manner | 13:27 |
| Son_Goku | (Mint and Neon's irresponsibility about sec updates aside) | 13:27 |
| ogra_ | mint also installs its own kernel by default | 13:27 |
| popey | (oh, and Zorin, which isn't in that list because that list if systems which do _not_ have GNOME Software by default). | 13:27 |
| popey | ogra_: uh, you may be on outdated info | 13:27 |
| ogra_ | (which might or might not cause issues with snaps) | 13:28 |
| Son_Goku | ogra_, you're wrong | 13:28 |
| ogra_ | oh, really ? | 13:28 |
| Son_Goku | Mint uses Ubuntu kernel | 13:28 |
| popey | yes, please check before claiming that again | 13:28 |
| Son_Goku | they've done that for at least a few years | 13:28 |
| ogra_ | i know you can install the ubuntu kernel manually but their main reason for existance was always their own kernel | 13:28 |
| Son_Goku | no | 13:28 |
| popey | No | 13:28 |
| Son_Goku | their existence is for Cinnamon Desktop | 13:28 |
| Son_Goku | just like elementary's is Pantheon Desktop | 13:28 |
| ogra_ | it used to be the kernel too | 13:29 |
| ogra_ | good that this changed then | 13:29 |
| popey | Lets talk about today rather than the past | 13:29 |
| Son_Goku | anyway, point is, anything using Ubuntu AppArmor (aka Ubuntu or Solus kernel) has it | 13:29 |
| Son_Goku | no one else does | 13:29 |
| Son_Goku | one day, that situation will change (and I can stop calling it Ubuntu AppArmor then), but that day is quite a ways out | 13:30 |
| jamesh | zyga: if we resort to parsing /proc/$pid/env, we may as well just look for SNAP_NAME | 13:32 |
| jamesh | (as an indicator that it might be a snap app: the snap command could do a more rigorous check) | 13:33 |
| zyga | jamesh: yes, though that's easier to spoof | 13:38 |
| roadmr | jdstrand: hey! sorry for not announcing it earlier, reviewer-tools r1093 is live in the store (as of Friday I believe) | 13:38 |
| jamesh | zyga: right, but false positives are okay here. It'd just mean we unnecessarily call the snap command, and get back an error saying it isn't really a snap confined app | 13:40 |
| zyga | jamesh: sure but if we are looking for anything and calling snap we could look at SNAP_COOKIE and run snapctl with some command, as a protocol it feels nice | 13:40 |
| jdstrand | roadmr: thanks! fyi, I may ask you to turn on resquash enforcement this week when the squashfs-tools make it through SRU | 13:41 |
| roadmr | jdstrand: great! sure, let me know. Remember we'll be in sprint mode next week, maybe to keep in mind. | 13:41 |
| roadmr | jdstrand: but of course I'm available that week if we need to flip it back quickly (and we'll mostly be in the same room so that might be a plus hehe) | 13:42 |
| jdstrand | roadmr: once they hit -updates, remind me, can we depend on -updates being applied immediately? | 13:42 |
| jdstrand | roadmr: yes, it would be nice to say at the sprint "we just turned on enforcement again and are keeping an eye on it" | 13:42 |
| roadmr | jdstrand: uhh great question. The safest bet would be to do an explicit upgrade, which I can do via an IS ticket request | 13:42 |
| roadmr | jdstrand: so when it hits -updates, it should be in the store units in the next 24 working hours | 13:47 |
| jdstrand | roadmr: ok, I'll keep that in mind | 13:47 |
| niemeyer | zyga: You coming? | 14:03 |
| zyga | yes | 14:03 |
| thresh | is it only me or the color picker in the snapped gimp select the one and only blue color? 007ffd? | 14:27 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | thresh: wayland? | 14:37 |
| zyga | re, sorry I had to feed my dog | 14:39 |
| Chipaca | zyga: in soviet russia, something something something | 14:45 |
| zyga | Chipaca: so we dogfood our stuff, right? | 14:46 |
| Chipaca | zyga: isso | 14:46 |
| popey | I prefer "Drink our own champagne" :) | 14:46 |
| Chipaca | we've got enough verified developers i think i should work on the snap cli bit of that | 14:47 |
| * Chipaca looks | 14:47 | |
| cwayne | popey: what you don't like dogfood?! | 14:47 |
| popey | only on wednesdays | 14:47 |
| cwayne | makes sense | 14:48 |
| zyga | popey: that is grose ;-) | 14:48 |
| zyga | my dog is grateful and returned for a hug | 14:49 |
| thresh | Chipaca, nope | 14:50 |
| thresh | i'm not that hip | 14:50 |
| zyga | Chipaca: tests are not happy today, are they? | 15:00 |
| zyga | Chipaca: that's a nice one | 15:10 |
| zyga | Chipaca: MATCH errors, opensuse download errors, mount errors | 15:10 |
| zyga | bonus combo | 15:10 |
| zyga | https://api.travis-ci.org/v3/job/402187098/log.txt | 15:12 |
| Chipaca | zyga: plz restart it | 15:12 |
| zyga | ack | 15:12 |
| zyga | done | 15:13 |
| Chipaca | taw | 15:13 |
| Chipaca | I'm going to have to reimplement tabwriter for this thing | 15:13 |
| Chipaca | fun :-) | 15:13 |
| zyga | which thing? | 15:13 |
| zyga | pedronis: replied on your comment | 15:23 |
| zyga | as for the incoming/outgoing terminology I'm open for changes but this is actually factually accurate representation of what happens | 15:23 |
| zyga | pedronis: to stop changeing snap.Info we need to patch the interfac API layer heavily (ish) | 15:24 |
| zyga | *changing | 15:24 |
| zyga | pedronis: on the up side those are not really full snap.Infos, those are just re-mapped on the outgoing path and are no longer linked to anything else in snapd | 15:24 |
| pstolowski | niemeyer: re talking to udev: no generic udev->dbus bridge (only udisks2 for storage devices). the most appealing to me is a proxy executable that both enumerates and monitors the devices, and links with libudev. for the prototype I could just wrap udevadm info & monitor in a script (or have a script that just outputs predefined events) and focus on business logic of snapd, once that works have a proper udev helper binary. | 15:27 |
| mup | PR snapcraft#2178 opened: lifecycle: pass commands to containerbuild, not steps <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2178> | 15:28 |
| zyga | pstolowski: I think the answer to your main comment is that those are not _really_ snap.Infos, we just use the type for that because certain things about it are the same | 15:30 |
| zyga | er | 15:30 |
| zyga | pedronis: ^ | 15:30 |
| zyga | pedronis: if you want I can look at separating those types out completely | 15:30 |
| pedronis | zyga: I need to look a bit at code, but I'm close to eod | 15:34 |
| zyga | pedronis: ok, I'll prepare a small PR that shows what this would look like | 15:34 |
| zyga | pedronis: essentially interfaces.Info type needs to grow some counterparts for snap.{Plug,Slot}Info | 15:35 |
| zyga | pedronis: and then we need to copy the data out of snap.{Plug,Slot}Info into the new interfaces.{Plug,Slot}PartialInfo | 15:35 |
| zyga | so that there is no need to ever modify snap.{Plug,Slot}Info | 15:35 |
| zyga | the new interfaces.{Plug,Slot}Info would only be used in the response to /v2/interfaces (and perhaps partially to connections later) | 15:36 |
| zyga | but this doens't change the essence of the re-mapping, I think that is still correct | 15:36 |
| Chipaca | zyga: I shal name thee 'hitter of restart job' | 15:42 |
| Chipaca | zyga: (it just became green i think) | 15:42 |
| zyga | Chipaca: oooh | 15:42 |
| zyga | merge it pretty please | 15:42 |
| Chipaca | it's only got one +1 :-) | 15:42 |
| zyga | Chipaca: I'm the serverless api server that makes things work ;0 | 15:43 |
| Chipaca | but, yeah, niemeyer reviewed it on irc :-) | 15:43 |
| zyga | pstolowski: we need a +1, can you spare a sec? | 15:43 |
| Chipaca | merged | 15:43 |
| Chipaca | done | 15:43 |
| mup | PR snapd#5493 closed: tests: prepare needs to handle bin/snapctl being a symlink <Critical> <Simple> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5493> | 15:44 |
| zyga | thanks! | 15:44 |
| pstolowski | #4767 needs a second review... (for the brave only) | 15:49 |
| mup | PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767> | 15:49 |
| Saviq | hi all I've been getting store release / upload failures (500) from Launchpad, is that known? anything I can help with? https://launchpad.net/~saviq/+snap/subsurface-edge/+build/274030 is the failed release | 15:51 |
| jdstrand | roadmr: hey, can you pull in r1095 of the review tools (adds 2.34 interfaces and an override) | 15:51 |
| roadmr | jdstrand: sure! | 15:51 |
| jdstrand | thanks! | 15:51 |
| Chipaca | cprov: ^ see Saviq's q | 15:53 |
| roadmr | mhh Saviq it looks like it was an error releasing only, for the arm64 upload | 15:58 |
| * roadmr dives into logs | 15:58 | |
| zyga | pedronis: still here? | 15:59 |
| mup | PR snapd#5494 opened: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/5494> | 15:59 |
| Saviq | roadmr: I've been getting those in ~20% of the builds since the weekend, some of them upload failures, some release | 16:00 |
| roadmr | Saviq: let's see what log diving says :) | 16:00 |
| zyga | pedronis: this is roughly the kind of change we'd have to apply to stop sending snap.PlugInfo in api responses: http://paste.ubuntu.com/p/5YqMTm3j9P/ | 16:00 |
| Saviq | roadmr: https://launchpad.net/~saviq/+snap/subsurface-edge/+build/273719 | 16:00 |
| zyga | this is _just_ the patch to the interface repository | 16:00 |
| zyga | a small change along this vein is needed in api.go and in the mapper (to stop changing PlugInfo)( | 16:01 |
| zyga | I can polish this all the way and propose | 16:01 |
| Saviq | roadmr: 0324, 0701, 1016, 1037, 1544 today (all UTC) | 16:02 |
| Saviq | and ok, it's only been today, not since the weekend | 16:02 |
| roadmr | Saviq: nice, thanks! | 16:02 |
| zyga | pedronis: let me know what you think | 16:03 |
| zyga | I need to break to take the dog out while it is not raining | 16:03 |
| roadmr | Saviq: I think it's because of a problem we identified yesterday and a rollout is in progress to fix it (hopefully) | 16:08 |
| roadmr | Saviq: I'll let you know when done and after that please let me know if it happens again | 16:08 |
| Saviq | roadmr: ack, will do | 16:10 |
| === pstolowski is now known as pstolowski|afk | ||
| niemeyer | pstolowski|afk: If udevadm is enough, why not just calling it? | 16:29 |
| niemeyer | pstolowski|afk: Send some notes on that forum message.. that should probably be an open thread, btw | 16:36 |
| niemeyer | (sounds generally interesting and worth archiving) | 16:36 |
| * zyga returns home wet | 16:52 | |
| zyga | so the week of rain starts now | 16:52 |
| zyga | I also saved the home camera by wrapping it in one of the bags for dog poo, I was glad to have a few extras | 16:53 |
| * zyga -> hot shower | 16:53 | |
| niemeyer | pstolowski|afk: Sorry, s/Send/Sent/ (but that was probably obvious) | 17:13 |
| * Chipaca eods | 17:16 | |
| niemeyer | Have fun Chipaca | 17:20 |
| niemeyer | I'll step out to run some errands as well.. back later | 17:20 |
| jdstrand | roadmr: hey, what does this mean: "Store upload failed: The request is missing an Authorization header field containing a valid macaroon" - https://launchpad.net/~jdstrand/+snap/snappy-debug/+build/274620 | 19:49 |
| jdstrand | roadmr: a better question is, how do I fix that? | 19:49 |
| roadmr | jdstrand: macaroons have a hard expiration date of (I think) a year, is it possible this project has been pushing builds for a year or so? | 19:50 |
| jdstrand | roadmr: yes | 19:50 |
| jdstrand | roadmr: how do I regenerate the macaroon? | 19:50 |
| roadmr | jdstrand: does this use build.snapcraft.io? or just launchpad? | 19:51 |
| jdstrand | roadmr: just launchpad | 19:51 |
| jdstrand | roadmr: I wonder if 'Update snap package' would do it, if I change nothing else | 19:52 |
| jdstrand | (under 'Edit snap package') | 19:52 |
| roadmr | hmm maybe but let me check | 19:52 |
| roadmr | jdstrand: ok, so that should work, yes | 20:03 |
| roadmr | jdstrand: ideally you'd get sent to SSO for authentication, that would strongly suggest it's getting a new macaroon | 20:04 |
| roadmr | jdstrand: if not try changing some bogus value (and then back, like the channel for publishing) | 20:04 |
| jdstrand | ok | 20:09 |
| jdstrand | roadmr: chaning nothing didn't work. trying changing something now | 20:10 |
| roadmr | \o/ | 20:11 |
| jdstrand | roadmr: chaning something, updating, changing back, updating didn't work for an existing build. will now try a new build | 20:12 |
| jdstrand | it'll be a few minutes | 20:12 |
| roadmr | O;/ sorry about that | 20:13 |
| jdstrand | roadmr: oh, I was sent an email to go to https://launchpad.net/~jdstrand/+snap/snappy-debug/+authorize | 20:16 |
| roadmr | interesting | 20:16 |
| roadmr | jdstrand: Colin would be the expert here, this explains my amazed face at most everything you're encountering | 20:17 |
| jdstrand | heh | 20:17 |
| jdstrand | I'm going to wait to see what happens with the build before clicking the url | 20:17 |
| roadmr | jdstrand: if you click on authorize you'll get a page "Authorize store uploads of fongo" | 20:20 |
| roadmr | jdstrand: after clicking the button and going through the flow, I see "Uploads of fongo to the store are now authorized." | 20:20 |
| roadmr | fongo is my snap :D | 20:20 |
| roadmr | jdstrand: if your build still doesn't upload, it seems very likely hitting /+authorize will work | 20:21 |
| jdstrand | roadmr: it didn't upload. hitting authorize | 20:21 |
| roadmr | fwiw I saw the same flow to authorize the uploads, because I was just creating the snap | 20:22 |
| roadmr | which is why I sent you on the wild goose chase :( sorry | 20:22 |
| jdstrand | roadmr: that took me through SSO | 20:22 |
| roadmr | \o/ | 20:22 |
| jdstrand | roadmr: and I can upload again. thanks! | 20:23 |
| roadmr | whee | 20:24 |
| roadmr | jdstrand: TIL about +authorize by the way :) | 20:24 |
| mup | PR snapd#5495 opened: interfaces/builtin: initial version of the anbox-support interface <Created by morphis> <https://github.com/snapcore/snapd/pull/5495> | 20:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!