| zyga | Good morning | 06:33 |
|---|---|---|
| zyga | It rains, finally | 06:33 |
| amurray | zyga: how's your mouth? | 06:36 |
| mvo | hey zyga and amurray | 06:46 |
| mvo | zyga: yeah, how are you today? | 06:46 |
| mvo | good morning sil2100 | 06:47 |
| sil2100 | Morning o/ | 06:58 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | mornings! | 07:05 |
| zyga | Hey. It hurts and bleeds but I think it is better than yesterday evening | 07:37 |
| zyga | Had a rough night but I am trying to get back to my feet | 07:37 |
| pstolowski | zyga: sounds scary, hope it's not too terrible.. get some rest | 07:43 |
| pstolowski | mvo: hey, ok to close #7000? i'll propose a new one | 08:07 |
| mvo | pstolowski: yes, thats fine | 08:10 |
| jamesh | pedronis: hi. Re: the user session agent PR, I was able to put something together to have xenial's dbus-daemon launch a systemd version of "snap userd" with the right environment. | 08:10 |
| jamesh | pedronis: the problem comes when adding unix socket activation, since that provides a new method of starting the service that bypasses the environment load | 08:10 |
| pedronis | jamesh: I see, we should be able to do something about that, no? | 08:11 |
| jamesh | pedronis: the normal way the environment gets populated is through /etc/X11/Xsession.d/95dbus_update-activation-env | 08:17 |
| jamesh | pedronis: and the dbus-update-activation-environment helper program doesn't seem to handle the case when the systemd user instance is not present on the bus | 08:18 |
| mvo | pstolowski: looking forward to see the new one, but fwiw, I think we should not make the perfect the enemy of the good, just dealing with missing "core/current" will already help even though we don't deal with "snapd" yet | 08:18 |
| pedronis | jamesh: my point, can't setup something that runs on sessions that can talk to the systemd userd ? | 08:19 |
| pedronis | sorry | 08:19 |
| jamesh | it's not clear where we should get the environment from in this case | 08:19 |
| pedronis | jamesh: ? | 08:20 |
| jamesh | hmm. maybe within the "snap userd --autostart" call? | 08:20 |
| pedronis | for example | 08:20 |
| jamesh | pedronis: systemctl can talk to the user instance because it has some private back channel for this case | 08:20 |
| pedronis | jamesh: my main point is that exept userd instances to be able to somehow setup talking to each other | 08:21 |
| pedronis | they could talk over sume /run files | 08:21 |
| pedronis | or something else | 08:21 |
| pedronis | *some | 08:21 |
| jamesh | pedronis: I'm still not entirely sure what the benefit of having these two separate tasks colocated in the same process is though. | 08:23 |
| pedronis | jamesh: how do we do user notifications if they are not? | 08:23 |
| pedronis | it one of the things you said we cannot do we they aren't | 08:23 |
| pedronis | maybe I misunerstood you | 08:23 |
| jamesh | pedronis: we can do that with just the session bus address, which I think I can work out a way to get | 08:24 |
| pstolowski | mvo: in the new version of 7000 i'm simply comparing snapd version string and got rid of the entire current symlink & refresh time logic | 08:24 |
| jamesh | being able to do xdg-open relies on a lot more | 08:24 |
| pedronis | jamesh: but in bionic we could have signle process though? | 08:25 |
| pedronis | *single | 08:25 |
| jamesh | pedronis: yes. | 08:25 |
| pedronis | jamesh: as I said I'm a bit worried to have a design that is more meant to accomodate xenial, than bionic | 08:26 |
| pedronis | but I understand there a trade offs | 08:26 |
| jamesh | pedronis: I'd see it more as allowing existing functionality to continue as is. | 08:27 |
| mvo | pstolowski: sweet | 08:28 |
| mvo | pstolowski: that sounds like the right approach, thank you! | 08:28 |
| jamesh | pedronis: also, having some separation between a service performing actions on behalf of untrusted apps and a service performing actions on behalf of snapd doesn't sound like a bad thing | 08:28 |
| pedronis | jamesh: you wrote this: "This also means that we will likely won’t be able to have the REST service post desktop notifications on Xenial. " | 08:29 |
| pedronis | you are saying this doesn't need to be true? | 08:29 |
| jamesh | pedronis: yes. I noticed afterwards that the Upstart job is writing the bus address to $XDG_RUNTIME_DIR/dbus-session | 08:31 |
| jamesh | pedronis: so a hack sufficient to get notifications working on Xenial would be to check for that file when $DBUS_SESSION_BUS_ADDRESS is not set | 08:32 |
| pedronis | jamesh: if it's to fiddly to get one process on xenial, I'm ok with two processes, as long as we keep it can keep their functionality clearly separate, we don't have things we want to do that we can't | 08:32 |
| jamesh | that doesn't generalise to the xdg-open case though (I don't think) | 08:33 |
| pedronis | notifications and getting user input on them is one of them | 08:33 |
| pedronis | pstolowski: thanks for #7014 | 08:34 |
| pedronis | I'l try to look at it soon | 08:34 |
| pstolowski | yw, ty | 08:34 |
| jamesh | that's another issue: Unity 7's notifications design explicitly doesn't support actions | 08:34 |
| pedronis | I imagine it's fairly mechanic | 08:34 |
| pedronis | ^ this was about #7014 (to be clear) | 08:35 |
| jamesh | that said, I don't think popping up dialogs will be particularly popular as an alternative | 08:36 |
| jamesh | anyway. That's something to test down the road | 08:36 |
| pedronis | yes, in theory it would be better if it was up to the snaps | 08:38 |
| pedronis | to display things | 08:38 |
| pedronis | not snapd itself | 08:38 |
| pedronis | but we'll have to see | 08:38 |
| pedronis | jamesh: can you write something about notifications and how to get hold of the session dbus on xenial and bionic in the forum topic | 08:41 |
| jamesh | sure. | 08:42 |
| jamesh | I need to check what notify-osd actually does if I post a notification with actions. At one point it converted it to a dialog itself. Not sure about now. | 08:43 |
| pedronis | jamesh: thank you | 08:43 |
| seb128 | jamesh, it still does that, notify-osd didn't change for like 7 years :) | 08:45 |
| jamesh | seb128: that's probably a good thing in this case. Thanks | 08:45 |
| seb128 | yw! | 08:46 |
| jamesh | pedronis: fwiw, it looks like CentOS 7 doesn't have a user instance of systemd at all, so it is like Ubuntu 14.04 in that respect | 08:55 |
| pedronis | jamesh: ok, we'll need to think about degradation of these features | 08:57 |
| * zyga just spilled coffee over *everything* on his desk | 08:58 | |
| zyga | this is not my day | 08:58 |
| jamesh | pedronis: if you only care about CentOS 7 on servers it is probably fine. CentOS 8 is just around the corner too | 08:59 |
| * pstolowski school end & early lunch, bbl | 10:05 | |
| Chipaca | pedronis: should 'snapctl set-health' be usable as non-root? | 10:13 |
| pedronis | Chipaca: do we even have that concept for snapctl commands ? | 10:14 |
| pedronis | Chipaca: anyway if the cookie is right I don't see why not | 10:14 |
| pedronis | Chipaca: am I missing something? | 10:16 |
| Chipaca | pedronis: I'm not sure what you're wanting to ask wrt your 1st question | 10:16 |
| Chipaca | pedronis: currently 'snapctl set-health' fails with 'error: cannot use "set-health" with uid 1001, try with sudo' | 10:17 |
| pedronis | Chipaca: mmh ? | 10:17 |
| pedronis | did we change something | 10:17 |
| pedronis | was it always like that? | 10:17 |
| pedronis | I thought for snapctl we used a different socket | 10:17 |
| pedronis | and only the cookie counted | 10:17 |
| Chipaca | overlord/hookstate/ctlcmd/ctlcmd.go:return &ForbiddenCommandError{Message: fmt.Sprintf("cannot use %q with uid %d, try with sudo", f.Name, f.Uid)} | 10:17 |
| Chipaca | (which is funny because how is sudo going to work 'inside') | 10:18 |
| Chipaca | (from a hook i mean) | 10:18 |
| Chipaca | bah, hooks are run as root i guess? | 10:18 |
| pedronis | yes | 10:18 |
| pedronis | hooks are run as root | 10:18 |
| Chipaca | pedronis: there's a whitelist of not-root things | 10:19 |
| Chipaca | right now it's "get" and "services" that are whitelisted | 10:19 |
| pedronis | where is it? | 10:19 |
| pedronis | apparently I didn't know about this | 10:19 |
| Chipaca | pedronis: overlord/hookstate/ctlcmd/ctlcmd.go line 124 | 10:19 |
| pedronis | interesting | 10:20 |
| pedronis | but ok | 10:20 |
| pedronis | Chipaca: I sort feel like setting healt should be ok not from root | 10:20 |
| pedronis | though | 10:20 |
| pedronis | *health | 10:21 |
| Chipaca | ok done | 10:25 |
| Chipaca | hmm, revision is _not_ getting set :-( | 10:25 |
| * Chipaca hmms | 10:25 | |
| pedronis | Chipaca: ephemeralContext sets snap name but not revision | 10:29 |
| pedronis | see hookmgr.go | 10:29 |
| Chipaca | pedronis: but I'm also getting unset when it's not ephemeral (ie when it's a hook) | 10:31 |
| pedronis | ah | 10:31 |
| pedronis | I feared that, I thought we discussed that | 10:31 |
| Chipaca | yeah | 10:31 |
| Chipaca | I got a revision in there at some point | 10:31 |
| Chipaca | oh wait | 10:31 |
| Chipaca | pedronis: i'm using 'try', which don't do revisions there | 10:31 |
| alan_g | sergiusens, we thought (apparently wrongly) that the LP builders could handle "layouts", so we dropped "passthrough" for the Mir related snaps and started seeing "Issues while validating snapcraft.yaml: Additional properties are not allowed ('layout' was unexpected)". Any thoughts? | 10:32 |
| alan_g | Here's an example: https://launchpadlibrarian.net/429275346/buildlog_snap_ubuntu_bionic_i386_mir-test-tools-edge_BUILDING.txt.gz | 10:32 |
| cjwatson | alan_g: This doesn't sound like something where Launchpad has much of an opinion either way ... | 10:41 |
| cjwatson | alan_g: Looks like you're not using a base? In that case you'll be using the snapcraft .deb package rather than the snap | 10:41 |
| cjwatson | alan_g: That probably accounts for whatever difference you're seeing | 10:42 |
| cjwatson | alan_g: Oh, huh, you are using a base. How are you requesting these builds exactly? | 10:43 |
| cjwatson | I think you're probably using an old API method | 10:43 |
| alan_g | Saviq, ^ you probably know how we're starting these | 10:47 |
| Saviq | that's very likely | 10:47 |
| * Saviq waits for github | 10:48 | |
| Saviq | cjwatson: https://github.com/MirServer/mir/blob/master/tools/process_snaps.py#L247 | 10:49 |
| * Saviq missed the memo that there's new API | 10:50 | |
| cjwatson | OK, so the problem with the API you're using is that it's synchronous so we can't fetch snapcraft.yaml from the source repository and inspect it to decide what to do without a serious risk of timeouts | 10:52 |
| cjwatson | (This was a mistake but we didn't realise it when we designed that API the first time round) | 10:53 |
| cjwatson | Saviq: You want https://launchpad.net/+apidoc/devel.html#snap-requestBuilds - so instead of "builds = snap_recipe.requestAutoBuilds()", use "snap_recipe.requestBuilds(archive=snap_recipe.auto_build_archive, pocket=snap_recipe.auto_build_pocket, channels=snap_recipe.auto_build_channels)" | 10:54 |
| cjwatson | (Or different values of archive/pocket/channels if you like, but that will preserve existing behaviour) | 10:55 |
| Saviq | cjwatson: ack, thank you | 10:55 |
| cjwatson | Note that this doesn't and can't return the list of created builds (because it's asynchronous), but you weren't using them anyway | 10:55 |
| Saviq | indeed | 10:55 |
| zyga | I collected my notes from the sprint and published them to the forum: https://forum.snapcraft.io/t/snapcraft-summit-2019-montreal-a-snapd-perspective/11905 | 11:30 |
| zyga | Wimpress: ^ feedback welcome, I specifically made this separate from the main thread because those are things that are mainly of interest to the snapd development and design team | 11:32 |
| zyga | break for some water | 11:32 |
| zyga | mvo: ^ more less complete | 11:34 |
| popey | zyga: tweet out a link with a nice description and a photo of your montreal summary and I'll get it shared from snapcraftio | 11:52 |
| zyga | popey: sure, will do :-) | 11:56 |
| Wimpress | Nice write up zyga :-) | 11:57 |
| popey | ok, just ping us a link when done | 12:00 |
| pstolowski | re | 12:02 |
| sergiusens | zyga: nice, typo alert (Gotod) | 12:07 |
| zyga | sergiusens: thanks! I will fix that shortly | 12:08 |
| zyga | popey: https://twitter.com/zygoon/status/1141316717899071489?s=21 | 12:08 |
| popey | haha.. that's an interesting photo! | 12:09 |
| Wimpress | Eye catching you might say :-) | 12:09 |
| zyga | Eye popping | 12:09 |
| Wimpress | I've replied to my post on the internal mailing list with a link to your forum post zyga | 12:09 |
| popey | thanks! | 12:10 |
| cwayne | it feels like zyga is staring into my soul | 12:10 |
| cwayne | and im worried he doesn't like what he sees | 12:10 |
| Wimpress | Well, it me stood behind him; so a fair assessment. | 12:10 |
| cmatsuoka | mvo: did you just resolve a comment in the slides? | 12:11 |
| cmatsuoka | (it disappeared in front of my eyes) | 12:13 |
| Pharaoh_Atem | zyga: you look like you've drank too much coffee | 12:41 |
| mvo | cmatsuoka: I didn't, at least not just now, just returned from lunch :) | 12:41 |
| cmatsuoka | mvo: hm, strange, perhaps I deleted it by mistake but undo can't bring it back so -- it was the one about the separate recovery kernel | 12:42 |
| cmatsuoka | mvo: I added that because we would need a separate extracted kernel for u-boot, otherwise selecting a new kernel for recovery would affect the next normal boot | 12:43 |
| cmatsuoka | (if it overwrites the existing extracted kernel) | 12:43 |
| cmatsuoka | does it make sense? otherwise I can just remove that entry from the slides | 12:44 |
| mvo | cmatsuoka: aha, I think I know what you mean - but please update and mention it only affects uboot at this point | 12:46 |
| cmatsuoka | mvo: done that already | 12:46 |
| mvo | ta | 12:47 |
| === ricab is now known as ricab|lunch | ||
| * cachio lunch | 14:40 | |
| === ricab|lunch is now known as ricab | ||
| abeato | jdstrand, hey, I have a couple of minor MPs related to interfaces: https://github.com/snapcore/snapd/pull/6962 and https://github.com/snapcore/snapd/pull/6975 | 15:01 |
| jdstrand | abeato: done, thanks! :) | 15:07 |
| abeato | jdstrand, thank you! | 15:09 |
| mvo | pedronis: just fyi, I'm triggering a new edge core build now (will take a little bit until all the bits are ready) | 15:28 |
| === pstolowski is now known as pstolowski|afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!