| mup | PR snapd#3622 opened: tests: enable regression, upgrade and completion test suites for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3622> | 01:48 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| === AdmWiggin is now known as tianon | ||
| zyga-ubuntu | good morning | 06:48 |
| * zyga-ubuntu actually had brakfast today and starts hacking | 07:29 | |
| zyga-ubuntu | mvo: do you want to sync about the debian situation? | 07:29 |
| mvo | zyga-ubuntu: in some minutes, hacking on base snaps | 07:32 |
| zyga-ubuntu | okay | 07:35 |
| mup | PR snapd#3620 closed: interfaces/builtin: discard empty Validate{Plug,Slot} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3620> | 08:36 |
| === chihchun is now known as chihchun_afk | ||
| === daker_ is now known as daker | ||
| * zyga-ubuntu is puzzled | 09:30 | |
| zyga-ubuntu | single test doesn't fail, lets run the suite | 09:30 |
| mup | PR snapcraft#1419 opened: add "base" to the snapcraft.yaml schema <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1419> | 09:49 |
| ogra_ | fgimenez, do our spread tests accept TMPDIR ? (see https://forum.snapcraft.io/t/how-to-use-spread-to-test-ubuntucore-image/1323 ) | 09:51 |
| fgimenez | ogra_: looking | 09:52 |
| morphis | zyga-ubuntu: ping | 09:55 |
| zyga-ubuntu | morphis: hey | 09:58 |
| morphis | zyga-ubuntu: the changed way of describing interfaces in the snapd code, is that documented somewhere? | 09:58 |
| zyga-ubuntu | morphis: changed as in how? | 09:59 |
| morphis | bringing https://github.com/snapcore/snapd/pull/3615 into shape for kyle right now | 09:59 |
| mup | PR snapd#3615: add broadcom-asic-control interface <Created by knitzsche> <https://github.com/snapcore/snapd/pull/3615> | 09:59 |
| zyga-ubuntu | morphis: but I think it's not described in many places | 09:59 |
| morphis | zyga-ubuntu: "Description is now out. Please open a thread on the forum, document the interface there and add a documentation link (I will try to land the related branch today so that you can do this)." is what you said | 09:59 |
| * zyga-ubuntu looks | 09:59 | |
| morphis | I didn't saw this changed for any of the other interfaces yet | 09:59 |
| zyga-ubuntu | morphis: ah, I see | 09:59 |
| zyga-ubuntu | morphis: this is 3399 | 09:59 |
| zyga-ubuntu | morphis: which will hopefully land later today | 09:59 |
| zyga-ubuntu | morphis: not much changes, just DocumentationURL -> DocURL and Description -> out | 10:00 |
| ogra_ | WOHOO !!! | 10:06 |
| ogra_ | the latest nplan fixed the wlan issues on pi3 | 10:07 |
| ogra_ | \o/ | 10:07 |
| morphis | ogra_: nice :-) | 10:10 |
| * ogra_ just set up a pi3 without any wired network | 10:10 | |
| mup | Bug #1632387 changed: console-conf wifi only setup on pi3 beta3 image not possible <Snappy:Confirmed> <subiquity (Ubuntu):Confirmed> <https://launchpad.net/bugs/1632387> | 10:13 |
| zyga-ubuntu | ogra_: did wifi work on first boot? | 10:15 |
| zyga-ubuntu | ogra_: wow :) | 10:15 |
| zyga-ubuntu | ogra_: what was the issue? | 10:15 |
| mup | PR snapd#3623 opened: interfaces/builtin: implement broadcom-asic-control interface <Created by morphis> <https://github.com/snapcore/snapd/pull/3623> | 10:15 |
| ogra_ | zyga-ubuntu, netplan had a unbind/bind cycle hardcoded for all drivers | 10:16 |
| ogra_ | zyga-ubuntu, which the broadcom driver of the Pi doesnt suopport | 10:16 |
| zyga-ubuntu | ah, I see | 10:16 |
| zyga-ubuntu | interesting, I never worked with driver binding/unbinding before | 10:17 |
| ogra_ | https://forum.snapcraft.io/t/failing-raspberry-pi-3-config-wlan-disappears/1023/6 has all info | 10:18 |
| mvo | does anyone know if there is a way to force snapcraft to *not* create a wrapper script? | 10:21 |
| mvo | for the things in my apps: section | 10:21 |
| * ogra_ doesnt think there is | 10:21 | |
| zyga-ubuntu | mvo: AFAIK, no | 10:22 |
| mup | PR snapd#3545 closed: many: support querying and completing assertion type names <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3545> | 10:22 |
| mup | PR snapd#3611 closed: overlord/snapstate/backend: some copydata improvements <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3611> | 10:22 |
| Chipaca | pedronis: niemeyer: snapd#3614 is ready for another look i think (spread failed so i'm re-running it, but errors were not related to the pr) | 10:40 |
| mup | PR snapd#3614: daemon, client, cmd/snap: implement "snap services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614> | 10:40 |
| pedronis | Chipaca: thanks, I'm having lunch break and then I have an errands, but will look later in the afternoon | 10:41 |
| Chipaca | np | 10:41 |
| Chipaca | i'm about to break to see if i can't have my lunch run during a break in the rain | 10:42 |
| mup | PR snapcraft#1420 opened: add new "no-wrapper" property to apps <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1420> | 11:01 |
| zyga-ubuntu | mvo: wow, nice | 11:02 |
| zyga-ubuntu | mvo: suggestion added as comment | 11:03 |
| zyga-ubuntu | mvo: woot, 3621 is green :) | 11:03 |
| zyga-ubuntu | mvo: I forgot to commit :'D | 11:04 |
| zyga-ubuntu | mvo: this means I can pursue this idea further and do what we discussed on the call earlier today | 11:06 |
| mup | PR snapd#3624 opened: rework for avahi interface <Created by kubiko> <https://github.com/snapcore/snapd/pull/3624> | 11:40 |
| zyga-ubuntu | mvo, Chipaca: can I land https://github.com/snapcore/snapd/pull/3619 please? | 11:49 |
| mup | PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619> | 11:49 |
| zyga-ubuntu | there are new interfaces coming up and I wanted to make sure they can benefit | 11:49 |
| zyga-ubuntu | Chipaca: I need some advice | 12:06 |
| Chipaca | zyga-ubuntu: delete facebook, hit the gym, lawyer up? | 12:06 |
| zyga-ubuntu | Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3399#discussion_r129296043 | 12:06 |
| mup | PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399> | 12:06 |
| zyga-ubuntu | haha, nice :) | 12:06 |
| zyga-ubuntu | lawyer up? | 12:06 |
| zyga-ubuntu | what does that mean? | 12:06 |
| Chipaca | zyga-ubuntu: contact, and possibly retain, a lawyer | 12:06 |
| mvo | zyga-ubuntu: 3619 has my review already, just needs a second one | 12:07 |
| zyga-ubuntu | Chipaca: aha | 12:08 |
| Chipaca | zyga-ubuntu: what's your question? | 12:08 |
| zyga-ubuntu | mvo: thanks, I'll rally some help then ... (looks at Chipaca) | 12:08 |
| zyga-ubuntu | Chipaca: so say I "snap list barf", that doesn't return 404 or anything similar but instead does client side translation from len(results) == 0 to a dedicated error | 12:09 |
| zyga-ubuntu | Chipaca: I used the same approach for snap interface | 12:09 |
| zyga-ubuntu | Chipaca: now the question is, should both change to server side error? | 12:09 |
| Chipaca | zyga-ubuntu: the behaviour of 'snap list' probably needs revisiting; the logic has grown organically for a while with no active pruning | 12:10 |
| Chipaca | zyga-ubuntu: it used to be that all filtering of snap list was client-side | 12:10 |
| Chipaca | zyga-ubuntu: then a minimal change was added to move the filtering to the server | 12:10 |
| Chipaca | zyga-ubuntu: but the error logic was probably left alone | 12:10 |
| zyga-ubuntu | right | 12:10 |
| zyga-ubuntu | I'm after a common front, we can change the code once we agree on how | 12:10 |
| Chipaca | ok | 12:11 |
| niemeyer | Mornings o/ | 12:11 |
| Chipaca | zyga-ubuntu: sounds good | 12:12 |
| Chipaca | zyga-ubuntu: for snap list, it is not an error to say "snap list" and have it return nothing (it prints a message, but isn't an error) | 12:12 |
| Chipaca | zyga-ubuntu: for snap list, it is an error to say "snap list foo" if foo is not installed | 12:12 |
| Chipaca | zyga-ubuntu: for snap list, it is _not_ an error to say "snap list foo bar" if foo is not installed but bar is | 12:13 |
| zyga-ubuntu | Chipaca: how would the results be conveyed? | 12:13 |
| zyga-ubuntu | Chipaca: and why is the last thing different from the 2nd thing? | 12:14 |
| zyga-ubuntu | Chipaca: I was thinking about an xml-rpc like multi-call request, (one request packing many requests and returning many responses) | 12:14 |
| zyga-ubuntu | Chipaca: so that individual query elements can fail | 12:14 |
| Chipaca | zyga-ubuntu: how do you tell bash that | 12:15 |
| Chipaca | "snap list" takes the approach that if at least one succeeds, the op succeeded | 12:15 |
| Chipaca | my question is whether that is appropriate for the other thing you're wanting to generalise it to | 12:15 |
| zyga-ubuntu | Chipaca: well, bash can just fail with "error code 1" | 12:15 |
| zyga-ubuntu | Chipaca: bash isn't a problem here, I think | 12:15 |
| zyga-ubuntu | Chipaca: and we can either fail or succeed | 12:16 |
| zyga-ubuntu | Chipaca: depending on the context | 12:16 |
| zyga-ubuntu | Chipaca: but we need to know we did fail in the first place | 12:16 |
| zyga-ubuntu | Chipaca: I think we need to get the wire format right first | 12:16 |
| Chipaca | zyga-ubuntu: what's the advantage for the user? | 12:17 |
| zyga-ubuntu | Chipaca: user advantage is can be defined later, right now I think we are still stuck at the request/response layer | 12:18 |
| Chipaca | zyga-ubuntu: you're starting from the wrong place then :-) | 12:18 |
| zyga-ubuntu | Chipaca: well, not sure, at the moment we cannot even convey this to the user because we have no data to say so | 12:19 |
| niemeyer | Chipaca: I think it's awkward that "snap list foo bar" doesn't error if one of these is missing.. feels like a bug | 12:20 |
| niemeyer | Chipaca: I don't think the wire format is involved in any of this | 12:21 |
| niemeyer | Sorry, that was actually for zyga | 12:21 |
| niemeyer | The user interface is what creates expectation.. depending on what is being done, the expectation is broken and becomes a bug | 12:22 |
| zyga-ubuntu | niemeyer: by wire format I was referring to being able to encode this, right now I'm not sure if we should use status codes or what | 12:22 |
| niemeyer | The API under it can work in many different ways | 12:22 |
| niemeyer | zyga-ubuntu: We don't want to send bash status codes in the API.. makes no sense | 12:22 |
| zyga-ubuntu | niemeyer: I wasn't talking about bash status codes | 12:23 |
| zyga-ubuntu | niemeyer: just the fact that "snap list foo bar" didn't know about "bar" but found "foo" | 12:23 |
| niemeyer | zyga-ubuntu: Well, which status codes are you talking about then? :) | 12:23 |
| zyga-ubuntu | niemeyer: I was thinking about http status codes | 12:23 |
| niemeyer | zyga-ubuntu: We use those fine I think | 12:23 |
| Chipaca | niemeyer: it may well be, and if it is we can change it, but right now this is how it behaves -- changing it because it's a bug is fine, changing it because we want to change the wire format so we can change it is not | 12:23 |
| zyga-ubuntu | niemeyer: should that give a 404, a 200 with some extra data or something entirely different/ | 12:23 |
| zyga-ubuntu | niemeyer: so far snap list doesn't 404 AFAIK | 12:23 |
| niemeyer | Thankfully!!! | 12:24 |
| niemeyer | One more for emphasis: ! | 12:24 |
| niemeyer | :P | 12:24 |
| * Chipaca lends niemeyer a double ‼ | 12:24 | |
| niemeyer | Thanks! :) | 12:24 |
| Chipaca | maybe some bold ones as well ❗❕ | 12:25 |
| * Chipaca stops | 12:25 | |
| zyga-ubuntu | niemeyer: in any case, please have a look at 3399 | 12:25 |
| zyga-ubuntu | niemeyer: there is one outstanding point | 12:25 |
| zyga-ubuntu | niemeyer: that is related to the discussion above | 12:25 |
| zyga-ubuntu | niemeyer: and if you can, please +1 3619 as I want to fix some incoming interfaces | 12:26 |
| pedronis | Chipaca: did another pass on your branch | 12:26 |
| niemeyer | zyga-ubuntu: Some background: 404 generally means "nothing to see here" in HTTP protocols.. quite error prone to return it on a request that was processed and which has a richer response than simply "nothing to see here" | 12:26 |
| niemeyer | zyga-ubuntu: In this specific case, the API returning one element out of two seems reasonable.. it's the user action of saying "list me those two" in a CLI that makes this an error | 12:27 |
| Chipaca | pedronis: by "just check and transform the result" you mean "if it has ‘.’, call snap.SplitSnapApp, otherwise don't"? | 12:27 |
| pedronis | Chipaca: no check if the two parts are equal, if they are return one and "" | 12:28 |
| Chipaca | pedronis: so if the user says "foo.foo" they still get all the apps from foo? | 12:28 |
| Chipaca | :-/ | 12:28 |
| niemeyer | zyga-ubuntu: I think I just responded to that point? | 12:28 |
| pedronis | Chipaca: well as I said I'm not happy with tha ambiguity | 12:29 |
| Chipaca | pedronis: these are services, not … not-services, so the "foo means foo.foo" doesn't apply | 12:29 |
| pedronis | let me think | 12:30 |
| * Chipaca steps back from the thinking pedronis | 12:30 | |
| zyga-ubuntu | niemeyer: so if we ask about one interface and it is not there the server should then give us some kind of 404-ish error? | 12:30 |
| pedronis | Chipaca: ok, yes, I think you need to check if '.' is the thing then | 12:31 |
| niemeyer | zyga-ubuntu: How does "snap list" report that today? | 12:31 |
| pedronis | anyway it's a nitpick | 12:31 |
| zyga-ubuntu | niemeyer: it translates that in the client | 12:31 |
| niemeyer | zyga-ubuntu: How does it report? | 12:31 |
| zyga-ubuntu | niemeyer: with identical if len==0 check | 12:31 |
| zyga-ubuntu | niemeyer: zyga@fyke:~/go/src/github.com/snapcore/snapd$ snap list nothingtoseehere | 12:32 |
| zyga-ubuntu | error: no matching snaps installed | 12:32 |
| niemeyer | zyga-ubuntu: Sorry, for extra clarity: your question is about what the server does.. I'm driving an analogy with snap list, and asking how the server reacts to those requests | 12:32 |
| niemeyer | zyga-ubuntu: We don't want these APIs side-by-side with diverging behaviors | 12:33 |
| zyga-ubuntu | niemeyer: to the best of my knowledge snap inteface and snap list behave the same way server side, unknown things are skipped silently | 12:33 |
| Chipaca | niemeyer: "list" does not error on returning empty | 12:33 |
| Chipaca | niemeyer: /v2/snaps i mean | 12:33 |
| Chipaca | niemeyer: does not consider returning an empty list to be a 404 | 12:33 |
| zyga-ubuntu | you just get an empty result container | 12:33 |
| niemeyer | Chipaca: Great, thanks | 12:33 |
| niemeyer | zyga-ubuntu: So that's what we want for interfaces too, on the server side | 12:34 |
| zyga-ubuntu | niemeyer: that's exactly what happens now | 12:34 |
| niemeyer | zyga-ubuntu: On the client side, a person asking to list something non-existing is generally an error | 12:34 |
| Chipaca | we could change it so that, if "snaps" is specified to /v2/snaps, then it 404s if empty | 12:34 |
| zyga-ubuntu | niemeyer: we just return an empty list and the client checks that | 12:34 |
| Chipaca | but, for snaps, it's never a 404 for the result to be empty if "snaps" is not given | 12:34 |
| niemeyer | Chipaca: It seems fine as it is.. as long as the behavior is consistent.. it's generally also easier to handle and less error prone per reasons above | 12:35 |
| Chipaca | that is, an empty collection is not a not-found | 12:35 |
| zyga-ubuntu | niemeyer: so from my POV, it's consistent and no further change is needed there | 12:35 |
| * zyga-ubuntu would love to land that PR :-) | 12:35 | |
| Chipaca | but also note that /v2/snaps/foo will happily 404 | 12:35 |
| niemeyer | zyga-ubuntu: Ok.. so about the client: the CLI needs to error when an interface requested by the user is not found | 12:35 |
| niemeyer | zyga-ubuntu: It can even list the first one, but it should error at the end pointing out the missing interface | 12:36 |
| zyga-ubuntu | niemeyer: I think it does as well, the client checks if we got an empty response and returns an error | 12:36 |
| zyga-ubuntu | aha | 12:37 |
| zyga-ubuntu | niemeyer: note that we can only ask about one interface toaday | 12:37 |
| zyga-ubuntu | niemeyer: so we do that | 12:37 |
| zyga-ubuntu | niemeyer: you either see what you asked for or you get an error | 12:37 |
| niemeyer | zyga-ubuntu: Okay, LGTM then | 12:37 |
| zyga-ubuntu | \o/ woot :) | 12:38 |
| niemeyer | and we need to fix snap list later to correct that behavior | 12:38 |
| zyga-ubuntu | niemeyer: I'll just point out that you cannot ask about many interfaces and if you want that, I can happily change that | 12:38 |
| niemeyer | zyga-ubuntu: On this specific point.. the rest of the review still applies obviously :) | 12:38 |
| zyga-ubuntu | niemeyer: so there's more parity on list and interface | 12:38 |
| niemeyer | zyga-ubuntu: Hmm | 12:38 |
| zyga-ubuntu | niemeyer: I think the rest of the review is fully addressed | 12:38 |
| zyga-ubuntu | niemeyer: if you don't ask about a specific interfaces you get the listing | 12:38 |
| Chipaca | is it OK that the client is now calling them connections, even though the endpoint is interfaces? | 12:38 |
| zyga-ubuntu | niemeyer: if you ask about a specific, you get it or you get an error saying it's not there | 12:38 |
| Chipaca | or should it be /v2/connections? | 12:39 |
| niemeyer | zyga-ubuntu: Yeah, I'd expect an API close to what we have with snaps | 12:39 |
| zyga-ubuntu | Chipaca: that's a thing we want to untangle but we didn't want to break compatibility | 12:39 |
| zyga-ubuntu | niemeyer: note that on the API layer you can ask for many | 12:39 |
| * Chipaca shuts up and puts the bikeshed inside the shed and puts a padlock on the shed and burns down the whole house with the shed inside it | 12:39 | |
| zyga-ubuntu | niemeyer: it's just the command line tool asks for one | 12:39 |
| niemeyer | Chipaca: It's the opposite unfortunately | 12:39 |
| niemeyer | zyga-ubuntu: Ah, that's fine | 12:39 |
| niemeyer | zyga-ubuntu: Easy to improve the CLI later | 12:39 |
| niemeyer | zyga-ubuntu: Was mainly worried about the API | 12:40 |
| niemeyer | Chipaca: The /v2/interfaces we have *today* is more like a "/v2/connections" thing | 12:40 |
| niemeyer | Chipaca: So instead of creating a /v2/more-interfaces :), we introduced new behavior on /v2/interfaces in a compatible way, that makes it return something that looks more like an actual interface | 12:41 |
| niemeyer | and we should really go back to the forum on those conversations.. all of that background will be trashed in a couple of hours | 12:42 |
| pedronis | Chipaca: did you see my other comments, a table of bools doesn't seem very readable but maybe you discussed that already to death | 12:44 |
| * zyga-ubuntu eats lunch quickly, see you at the call | 12:50 | |
| Chipaca | pedronis: no, we didn't discuss that aspect of it | 12:52 |
| pedronis | Chipaca: also to be active it needs to be enable, right? and vice versa if it's not enabled it cannot be active | 12:53 |
| Chipaca | pedronis: it can be active and not enabled, and enabled but not active | 12:54 |
| pedronis | Chipaca: ah, if you do systemd stuff | 12:54 |
| pedronis | directly | 12:54 |
| pedronis | anyway I still don't know if a wall of true/false is great | 12:55 |
| Chipaca | pedronis: "snap stop" does not disable | 12:56 |
| Chipaca | pedronis: "snap start" does not enable | 12:56 |
| niemeyer | pedronis: Indeed | 12:56 |
| Chipaca | pedronis: so "snap stop --disable" -> service is inactive,disabled; "snap start" -> service is active,disabled | 12:57 |
| Chipaca | pedronis: me neither | 12:57 |
| Son_Goku | why are you doing that? | 12:57 |
| Chipaca | but it does need to be lined up | 12:57 |
| niemeyer | Maybe active vs. -, and enabled vs. -, would be more visually appealing | 12:57 |
| Chipaca | Son_Goku: what "that"'s that? | 12:57 |
| Son_Goku | [08:57:00 AM] <Chipaca>pedronis: so "snap stop --disable" -> service is inactive,disabled; "snap start" -> service is active,disabled | 12:57 |
| Chipaca | Son_Goku: as opposed to what? | 12:57 |
| * Son_Goku shrugs | 12:57 | |
| pedronis | all our services are created enabled though? | 12:58 |
| pedronis | right? | 12:58 |
| pedronis | that's the initial state | 12:58 |
| Son_Goku | I mean specifically service management through snap command | 12:58 |
| Chipaca | pedronis: yes | 12:58 |
| niemeyer | Son_Goku: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262 | 12:58 |
| Chipaca | Son_Goku: it's been requested multiple times, for convenience | 12:58 |
| niemeyer | And this is where we should be having this conversation too.. :) | 12:58 |
| niemeyer | (so we can link next time) | 12:58 |
| Son_Goku | I'll have to trawl through that and give my feedback on the whole thing | 12:59 |
| Son_Goku | so far, I don't know if this is a good idea | 12:59 |
| * Son_Goku sighs | 13:00 | |
| Son_Goku | the forum is too hard to follow | 13:00 |
| niemeyer | Son_Goku: IRC is even harder to follow.. all of the conversation above will be gone in 2h tops | 13:00 |
| Son_Goku | yes, but because it's real-time-ish, I can just ask people :) | 13:01 |
| niemeyer | Son_Goku: Yes, and people can repeat the same thing they tell you 20 times more, to every next person asking.. /o\ | 13:01 |
| Son_Goku | haha | 13:01 |
| Son_Goku | I'm still waiting for desktop snaps to be unbroken: https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100 | 13:02 |
| Son_Goku | niemeyer: the issue with the forum is that I don't get emails of threads that I can jump into arbitrarily | 13:03 |
| Son_Goku | only things that I've already commented on | 13:03 |
| Son_Goku | so I barely know what the heck is going on | 13:03 |
| zyga-ubuntu | Chipaca: standup please | 13:03 |
| niemeyer | Son_Goku: You can subscribe to categories, topics, or even the whole forum | 13:03 |
| Son_Goku | I can? | 13:03 |
| Son_Goku | how? | 13:03 |
| niemeyer | Son_Goku: "Mailing list mode" in your preferences | 13:03 |
| Chipaca | zyga-ubuntu: omw! | 13:03 |
| niemeyer | Son_Goku: Per category, going to the category and selecting your subscription option | 13:04 |
| Son_Goku | so if I just set mailing list mode without doing anything else, it'll send me everything, right? | 13:05 |
| niemeyer | Son_Goku: Yep! | 13:09 |
| Son_Goku | niemeyer: done, thanks | 13:23 |
| Son_Goku | hopefully now I'll be able to be kept in the loop more | 13:23 |
| fgimenez | niemeyer: mvo i've just promoted 2.26.14 to stable | 13:39 |
| zyga-ubuntu | woot | 13:40 |
| mvo | fgimenez: excellent, thanks a lot | 13:43 |
| * zyga-ubuntu small break before doing more stuff | 13:47 | |
| zyga-ubuntu | I need to put my fedora box on my desk | 13:47 |
| zyga-ubuntu | I miss it :( | 13:47 |
| mvo | zyga-ubuntu: if you have a rpm based system at hand, could you please touch a file like /usr/bin/vi and then rpm install vi and see if rpm just overwrite the file if it is already there? that is what dpkg is doing and if rpm is doing the same we are good for the bash-completion idea we had the other day | 13:50 |
| mup | PR snapd#3625 opened: many: end-to-end support for the bare base snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3625> | 13:57 |
| zyga-ubuntu | mvo: checking | 14:00 |
| Son_Goku | mvo: if it's not a config file, then that behavior is valid | 14:00 |
| Son_Goku | if it's a ghost or a real file tracked by rpm and already exists, you're toast | 14:00 |
| mvo | Son_Goku: great, thats my undersanding as well | 14:00 |
| mvo | understanding | 14:01 |
| Son_Goku | note that a ghost file is one that is known to be tracked by rpm once something creates it | 14:01 |
| Son_Goku | they don't necessarily care about *everything* about them | 14:01 |
| zyga-suse_ | mvo: although I will use emacs :) | 14:01 |
| Son_Goku | but rpm does track them for the purposes of being able to remove them | 14:01 |
| === zyga-suse_ is now known as zyga-suse | ||
| * zyga-suse curses at packagekit for being ugly and stupid | 14:01 | |
| zyga-suse | and not wanting to shut down | 14:02 |
| Son_Goku | if you're on suse, you can force pk to give up | 14:02 |
| zyga-suse | I just tired because it gave me that option | 14:02 |
| zyga-suse | it doesn't work | 14:02 |
| Son_Goku | lovely :( | 14:02 |
| zyga-suse | "must be busy" | 14:02 |
| zyga-suse | no shit sherlock? | 14:02 |
| ogra_ | stop giving it so much to do then | 14:02 |
| ogra_ | poor thing ... | 14:02 |
| Son_Goku | haha | 14:03 |
| zyga-suse | it would have been nicer if it didn't just run on resume | 14:03 |
| Son_Goku | mvo: the only semantic that differs between dpkg and rpm on file handling is the concept of ghost files | 14:03 |
| zyga-suse | ok, installing emacs | 14:03 |
| Son_Goku | they don't exist in dpkg | 14:03 |
| Son_Goku | I believe it treats those as a conflict as well | 14:04 |
| zyga-suse | zypper says "checking for conflicts amongs files" | 14:04 |
| zyga-suse | must be doing something | 14:04 |
| Son_Goku | it's resolving @System.solv against your proposed transaction | 14:04 |
| Son_Goku | mvo: since unless you do %config %ghost (which is dumb for a variety of reasons), a %ghost file is a real file to the rpmdb like anything else | 14:05 |
| zyga-suse | Chipaca: offtopic,if I have a huge snap, will it resume a partiall download? | 14:05 |
| zyga-suse | mvo: it works as in dpkg | 14:05 |
| zyga-suse | I just installed emacs | 14:05 |
| zyga-suse | now how do I quit ;-)( | 14:06 |
| Son_Goku | zyga-suse: really? | 14:06 |
| zyga-suse | (just kidding, I know how to quit, emacs was my first editor) | 14:06 |
| Son_Goku | mvo: this is why I declared certain files in the fedora snapd spec as %ghost, so that they're owned by snapd and other things can't collide with it | 14:06 |
| zyga-suse | Son_Goku: I touched /usr/bin/emacs | 14:06 |
| zyga-suse | Son_Goku: then zypper installed emacs | 14:06 |
| zyga-suse | Son_Goku: then confirmed the file was overwritten | 14:06 |
| Son_Goku | yep | 14:06 |
| Son_Goku | mvo: even though they're not created by the rpm, rpm "knows" something "owns" it, and won't let something else "different" take it over | 14:07 |
| Chipaca | zyga-suse: if you have a huge snap, and as part of an install the connection gets interrupted and needs to be redone, yes it continues | 14:09 |
| zyga-suse | Chipaca: awesome | 14:10 |
| zyga-suse | Chipaca: at some point it would be cool to be able to pause downloads | 14:10 |
| zyga-suse | Chipaca: so you could snap install that-huge-thing and pause it while needing the bandwidth | 14:10 |
| Chipaca | zyga-suse: if you get 50% through a download and the network goes away so badly that the install actually aborts after retrying a few times, then no, the tempfile gets nuked | 14:10 |
| zyga-suse | Chipaca: ah, I see; I think we will want to re-visit that over time | 14:10 |
| zyga-suse | Chipaca: unless the user aborts I'd keep the file around and try until it works | 14:10 |
| zyga-suse | (knowing that the snap exists and can be pulled) | 14:11 |
| Chipaca | zyga-suse: you're proposing that we have a cache | 14:11 |
| zyga-suse | not even a cache | 14:11 |
| zyga-suse | if I download a 5GB snap | 14:11 |
| Chipaca | zyga-suse: I'm just saying, that thing behaves like a cache | 14:11 |
| zyga-suse | and it aborts because I'm offline for 5 minutes | 14:11 |
| zyga-suse | and it downloads it again | 14:11 |
| Chipaca | zyga-suse: meaning it's Hard | 14:11 |
| zyga-suse | it's the (insert emoji that flips the table now) | 14:11 |
| Chipaca | zyga-suse: https://github.com/dysfunc/ascii-emoji | 14:12 |
| zyga-suse | Chipaca: again, not hard, not cache, just keep the file around for as long as the user doesn't abort | 14:12 |
| Chipaca | zyga-suse: right | 14:12 |
| zyga-suse | Chipaca: and also perhaps not /tmp but /var/tmp that's on /writable | 14:12 |
| Chipaca | zyga-suse: the user didn't abort but the install failed | 14:12 |
| zyga-suse | Chipaca: as 5GB snap is valid, even on devices with 512M memory | 14:12 |
| Chipaca | zyga-suse: so it's a year later and you now have 87G of half-downloaded snaps | 14:13 |
| Chipaca | zyga-suse: and you ran out of space | 14:13 |
| zyga-suse | Chipaca: no other consumer system does that (steam, gog, appstore.{ios,android}) | 14:13 |
| zyga-suse | Chipaca: if I don't abort the download that's what I wanted | 14:13 |
| zyga-suse | Chipaca: and I hope it will install them actually | 14:13 |
| zyga-suse | Chipaca: *and* we might be able go just mv the file rather than use 2x space for a copy out of /tmp | 14:13 |
| Chipaca | zyga-suse: do you understand how what you are describing is a cache, meaning it has all the problems of a cache that need addressing? | 14:13 |
| Chipaca | zyga-suse: we don't download to tmp | 14:14 |
| zyga-suse | Chipaca: I don't think it is a cache or that it has any problems. We should just not abort at all if network is bad but we got at least one byte and can keep re-trying. | 14:14 |
| zyga-suse | Chipaca: but I assume to be ignorant about things you know better | 14:14 |
| zyga-suse | Chipaca: ah, that's good. I was afraid we did (must be confusing with sideload) | 14:14 |
| zyga-suse | Chipaca: cache is another thing (e.g. remove and reinstall) | 14:15 |
| zyga-suse | Chipaca: but I'd argue that what I described is not a cache and is easier | 14:16 |
| Chipaca | zyga-suse: maybe i misunderstood; you're saying we should keep retrying forever? | 14:16 |
| zyga-suse | Chipaca: yes, and never unlink the file unless the user "snap aborts" | 14:17 |
| zyga-suse | Chipaca: again, think of the behavior on huge snaps and non-ideal network conditions, or metered connections | 14:17 |
| ogra_ | cyphermox, hey, thanks for the bind/unbind fix in netplan (it fixed the pi3 core image) ... one thing that struck me is that vendors that will build core images from their own BSP might hit that same issue (i guess it is pretty common that platform devices in SoCs do not support unbind) ... do you think we could make the code read a config file with a list of drivers that vendors could simply extend ? | 14:29 |
| ogra_ | it would avoid that they have to wait for another netplan fix to land | 14:29 |
| cyphermox | ogra_: that's a good idea, can you please file a bug for it? | 14:30 |
| ogra_ | will do | 14:30 |
| ogra_ | cyphermox, bug 1706680 for you | 14:34 |
| mup | Bug #1706680: add config file to list drivers that do not support unbind <nplan (Ubuntu):New> <https://launchpad.net/bugs/1706680> | 14:34 |
| sergiusens | tyhicks , jdstrand hey there, is there an interface which would allow lttng /dev nodes to be used? | 14:37 |
| Chipaca | niemeyer: hah! | 14:38 |
| Chipaca | niemeyer: I had most of a post to the services forum post written :-) | 14:38 |
| niemeyer | Chipaca: Hopefully we even agreed unkowingly? :) | 14:39 |
| niemeyer | Chipaca: Sorry, I've spent the last 25 minutes writing and deleting my own proposals.. :P | 14:39 |
| Chipaca | niemeyer: maybe i should post it anyway and then we can play "spot the differences" | 14:40 |
| jdstrand | sergiusens: not currently | 14:41 |
| niemeyer | Sure, having more data won't hurt.. | 14:41 |
| Chipaca | niemeyer: there ya go | 14:41 |
| * ogra_ definitely likes niemeyer's proosal better because there are bars in it (it carries the subconcious promise of beer in it) | 14:42 | |
| ogra_ | *proposal | 14:42 |
| sergiusens | jdstrand: thanks, given that lttng is specifc to lttng can we update snappy-debug ? | 14:43 |
| Chipaca | ogra_ walks into a bar | 14:43 |
| Chipaca | >clonk< | 14:43 |
| * ogra_ grins | 14:43 | |
| Vamsi | Hi, I don't seem to find info on error reporting and handling for snaps. Does anyone know where I could read about it? | 14:43 |
| Chipaca | Vamsi: could you expand on what you mean? | 14:44 |
| Chipaca | Vamsi: hi :-) | 14:44 |
| Vamsi | Chipaca: Hi | 14:44 |
| Vamsi | Chipaca: In case a snap fails to start or is behaving incorrectly, how is this conveyed to the user? | 14:45 |
| Chipaca | Vamsi: currently it is not | 14:46 |
| Chipaca | Vamsi: assuming that by "a snap" you mean a service inside a snap | 14:46 |
| ogra_ | well, if you are lucky the developer added some info to the description ... which you can obtin with snap info | 14:47 |
| Chipaca | if the service fails to start entirely then the snap _should_ fail to install (but it's harder to detect than it should be, so we don't always catch that) | 14:47 |
| Chipaca | and the user can inspect the service status and its logs if things aren't working | 14:48 |
| Chipaca | but snapd itself doesn't tell the user | 14:48 |
| * ogra_ read the above as "where to report bugs about specific snaps" ... (perhaps i misunderstood) | 14:48 | |
| Chipaca | ah, if it is indeed where to report bugs, snap info tells you | 14:48 |
| Chipaca | that's what the "contact" field is for | 14:49 |
| Chipaca | but the question was 'how was this conveyed to the user', not 'how does the user convey this to the snap author' | 14:49 |
| ogra_ | yeah | 14:49 |
| ogra_ | thus my comment | 14:49 |
| ogra_ | (that i might have misunderstood) | 14:50 |
| Chipaca | ogra_: too much walking into bars :-p | 14:50 |
| ogra_ | :P | 14:50 |
| Chipaca | Vamsi: why do you ask? | 14:52 |
| zyga-suse | Chipaca: snappy, flatpak and appimage walk into a bar | 14:53 |
| ogra_ | and snappy is the only one who has an interface to the barkeeper to order beers ;) | 14:53 |
| Chipaca | zyga-suse: rox wonders what they did to not be invited | 14:54 |
| zyga-suse | ogra_: flatpak needs a beer portal, one is coming in F28, appimage just grabs the beer and snappy needs an assertion for the beer to be connected | 14:55 |
| ogra_ | dang | 14:56 |
| Vamsi | Chipaca: I was read on in the documentation that it was possible to revert back to the older version of a snap in case the update causes a problem. Additionally, the documentation says that the revert for a snap app happens when the user manually refreshs the snap. So if it is manual, how does the user or say a developer know what went wrong and where. The was the idea behind the question. | 14:57 |
| Vamsi | Chipaca: Okay I didn't realise that I typed so much :| | 14:58 |
| Chipaca | Vamsi: "the revert for a snap happens when the user manually refreshes the snap" that's not quite right, not sure exactly what you understood | 14:59 |
| Chipaca | but | 14:59 |
| Chipaca | Vamsi: if "snap install foo" fails, you do not end up with half-installed things (compare with "apt install") | 14:59 |
| Chipaca | Vamsi: if snap install succeeded, and then a later refresh (whether automatic or manual) fails, that refresh is undone | 15:00 |
| ogra_ | well | 15:00 |
| ogra_ | and you *can* snap revert manually indeed :) | 15:00 |
| Chipaca | Vamsi: "snap revert" is a different operation, where the user manually reverts to a previous version | 15:00 |
| Chipaca | Vamsi: the user would initiate the revert because something broke, even though snapd didn't realise | 15:01 |
| Chipaca | Vamsi: we want to additionally introduce health checks, where if a snap has a health check, and that helth check fails, the snap is automatically reverted | 15:02 |
| Chipaca | Vamsi: but this last bit of work is not started | 15:02 |
| ogra_ | we're such slackers! | 15:02 |
| * Chipaca writes down "trick ogra_ into creating a slackware base snap" | 15:02 | |
| ogra_ | lol | 15:03 |
| ogra_ | tarballs everywhere ! | 15:03 |
| Chipaca | ogra_: I'll take that as a "yes" | 15:06 |
| ogra_ | heh | 15:07 |
| Vamsi | Chipaca: Thanks :-) The document said this: 'For application snaps the user does this with snap revert <snap>'. So I understood that the revert process for application snaps was manual. | 15:11 |
| Chipaca | Vamsi: correct, revert is manual | 15:11 |
| Vamsi | Chipaca: Okay. In case of a failure of a snap. I.e., the snap stopped working or etc., are these logged automatically somewhere? If not, Is there a standardized way that a developer can implement such logging? | 15:14 |
| Vamsi | Chipaca: Lets say, I have a snap. A user reported an error in it's behavior or something like that. As the application's developer, is it possible for me to get logs from the user's device to understand what caused the problem? | 15:17 |
| Vamsi | Chipaca: I am trying to understand the diagnostic capabilities of snappy core. | 15:18 |
| Chipaca | Vamsi: that's not currently a feature we offer, no | 15:20 |
| Vamsi | Chipaca: So it's safe to say that snappy core offers no diagnostic tools to remotely check the device for errors errors etc? | 15:24 |
| Chipaca | Vamsi: It is safe to say that, today, that is correct. | 15:24 |
| Chipaca | Vamsi: why do I get the impression that you should be talking with our commercial team and not with us | 15:25 |
| Vamsi | Chipaca: Thanks :-) Additionally, in one of your previous messages you said it is possible for the user to see a service's status and its logs. Where could I see this. | 15:26 |
| Vamsi | Chipaca: Oh I am in touch with them. They directed me to the some documentation. Questions I asked here were something that was not clear/available in the documentation :| | 15:27 |
| Chipaca | Vamsi: today, the way to look at a service's status and logs is via systemctl and journalctl | 15:30 |
| Chipaca | Vamsi: i'm working on giving a slightly nicer way to get that, because of user demand :-) | 15:30 |
| Chipaca | Vamsi: wrt commercial, ok. I only mention it because it's one of the things that drive feature prioritization. | 15:32 |
| Chipaca | eg if there's a clear "we need <feature> so we can <zomg>", it's a lot easier to get to it sooner on the roadmap | 15:32 |
| zyga-suse | mvo: any idea what just happened here: | 15:33 |
| zyga-suse | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170726_141551_02f64@/log.gz | 15:33 |
| zyga-suse | - Run install hook of "core" snap if present (internal error: no registered handlers for hook "install") | 15:34 |
| zyga-suse | via https://github.com/snapcore/snapd/pull/3399 | 15:34 |
| mup | PR snapd#3399: many: add the interface command <Created by zyga> <https://github.com/snapcore/snapd/pull/3399> | 15:34 |
| zyga-suse | mvo: I assume this is the new stable core | 15:34 |
| Vamsi | Chipaca: Got it. Right now I am only evalutaing Snappy core. Perhaps once I figure out what are the features that we need that are missing in snappy core, perhaps then would be good to raise requests for features. | 15:35 |
| mvo | zyga-suse: autsch | 15:37 |
| Chipaca | Vamsi: ok. Good luck! | 15:37 |
| mvo | zyga-suse: a new core was released today | 15:37 |
| zyga-suse | right, I recall that | 15:37 |
| zyga-suse | and this didn't fail earlier | 15:37 |
| mvo | zyga-suse: looks like the new hook stuff is not quite working | 15:37 |
| zyga-suse | and the branch is definitely unrelated to hooks | 15:37 |
| mup | PR snapcraft#1421 opened: Travis: Wait for apt/ dpkg lock <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1421> | 15:37 |
| zyga-suse | looks like we broke something again | 15:38 |
| zyga-suse | maybe the old snapd setup hooks in one way | 15:38 |
| zyga-suse | and new snapd does it in a different way | 15:38 |
| zyga-suse | (just task names) | 15:38 |
| zyga-suse | so now we get this | 15:38 |
| zyga-suse | so maybe we need a .15 that adds re-adds the legacy hook task handlers | 15:38 |
| zyga-suse | (just a shoot in the dark) | 15:39 |
| * zyga-suse is super sleepy and feels like actually sleeping now | 15:39 | |
| ogra_ | Vamsi, if you talk about core itself, the core and kernel snaps definitely have some self tests and auto-rollback features ... managed by the bootloader setup together with snapd ... | 15:40 |
| ogra_ | this is different from application snaps though | 15:40 |
| ogra_ | (it checks if after an upgrade a certain safe point inn thhe system boot was reached, if not, it will automatically go back to last kernel or core) | 15:41 |
| fgimenez | mvo: zyga-suse fwiw refresh from latest stable to the new core when it was in beta has been successfully tested, incuding revert, not sure what can be causing that test/upgrade/basic error | 15:46 |
| mup | PR snapcraft#1422 opened: tests: remove the old script to launch lxc <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1422> | 15:49 |
| Chipaca | niemeyer: for your lunch break: https://thedailywtf.com/articles/the-nuclear-option | 15:51 |
| niemeyer | Chipaca: Thanks! :) | 15:51 |
| * Chipaca was closing tabs :-) | 15:52 | |
| mvo | zyga-suse, fgimenez: also funny that it only happens on i386 | 15:52 |
| fgimenez | mvo: yep, and refresh from latest stable was also successfully tested on i386 (on all the archs for that matter :) | 15:56 |
| mvo | fgimenez: yeah, never doubted this :) I'm just puzzled, one would assume it would fail everywhere at least | 15:57 |
| fgimenez | mvo: does it fail in more than one PR? | 15:57 |
| mvo | fgimenez: I have not instigated that yet, sorry | 16:02 |
| fgimenez | mvo: np thanks, looking | 16:02 |
| pedronis | Chipaca: +1 | 16:24 |
| Chipaca | pedronis: grazie mille | 16:24 |
| mup | PR snapd#3399 closed: many: add the interface command <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3399> | 16:53 |
| * zyga-suse needs a second review for 3619 | 17:02 | |
| zyga-suse | mvo: I had a look at the branch for bases and I need to think about it; in theory all the snaps have a base and I'd rather have something uniform (I'm thinking about the extra bool flag) | 17:03 |
| zyga-suse | Chipaca, pedronis ^ (maybe)? I could help some folks with their interface PRs if this lands | 17:07 |
| jdstrand | sergiusens_: what change are you thinking for snappy-debug? | 17:09 |
| niemeyer | Chipaca: OMG.. that code | 17:18 |
| zyga-suse | go generate xls plugin | 17:21 |
| niemeyer | Okay, I'm being pinged by Linode again.. will need to work on Spread to reduce the API calls so we don't get our tests blocked again | 17:31 |
| niemeyer | Moving to that now | 17:32 |
| Pharaoh_Atem | zyga-suse: yo | 17:33 |
| zyga-suse | o/ | 17:34 |
| Pharaoh_Atem | zyga-suse: did you ever send an email to the selinux@ mailing list asking about how to do the stuff we need for snap confinement to work? | 17:34 |
| zyga-suse | no, I didn't :-( | 17:35 |
| Pharaoh_Atem | it was pointed out to me in #fedora-devel that no one has ever actually asked there | 17:35 |
| Pharaoh_Atem | so no one knows why snapd can't be plugged into selinux the same way it can be on apparmor | 17:35 |
| zyga-suse | shall we start that thread today? | 17:35 |
| Pharaoh_Atem | yes, hold on | 17:36 |
| Pharaoh_Atem | need to sub to SELinux ML | 17:36 |
| zyga-suse | yeah, me too | 17:36 |
| zyga-suse | Pharaoh_Atem: this one? | 17:37 |
| zyga-suse | https://www.redhat.com/mailman/listinfo/fedora-selinux-list | 17:37 |
| tyhicks | mjg's post in the snapcraft forum summarizes the problems quite well | 17:37 |
| Pharaoh_Atem | zyga-suse: no, the upstream one: https://www.nsa.gov/what-we-do/research/selinux/mailing-list.shtml | 17:38 |
| * Chipaca EODs | 17:38 | |
| Pharaoh_Atem | zyga-suse: though sending to fedora-selinux is also a good idea | 17:38 |
| zyga-suse | Chipaca: noooo | 17:38 |
| tyhicks | (https://forum.snapcraft.io/t/selinux-interface-support/255) | 17:38 |
| Pharaoh_Atem | zyga-suse: I would send to both | 17:38 |
| Pharaoh_Atem | zyga-suse: hold on, the fedora one is this: http://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/ | 17:40 |
| tyhicks | zyga-suse, Pharaoh_Atem: I think the better solution is to work towards getting the LSM stacking patches fully functional and upstream | 17:41 |
| Pharaoh_Atem | tyhicks: it won't matter | 17:41 |
| Pharaoh_Atem | downstream, hardly anyone will do it | 17:41 |
| Pharaoh_Atem | it's just too much extra work | 17:41 |
| Pharaoh_Atem | maintaining *one* security system is a lot of work as it is | 17:41 |
| Pharaoh_Atem | if you expect people to maintain two for just *one* application, it's not going to fly | 17:41 |
| tyhicks | it is far less work than attempting to write equivalent SELinux policy for interfaces | 17:41 |
| tyhicks | many distros already have kernel and userspace support for multiple LSMs | 17:42 |
| zyga-suse | tyhicks: I somewhat agree with Pharaoh_Atem here, I think that in Fedora/RHEL land specifically it would fly much better with native selinux support even if that is harder | 17:42 |
| zyga-suse | (because they support selinux and not apparmor even if it technically gets stacked) | 17:42 |
| Pharaoh_Atem | we don't even have the apparmor userspace stuff packaged in Fedora | 17:43 |
| pedronis | zyga-suse: sorry, what was the "this" in your review request? the PR before was merged | 17:43 |
| tyhicks | zyga-suse: they don't need to support apparmor policy - they only need the tools available | 17:43 |
| pedronis | zyga-suse: before as in the logs here | 17:43 |
| zyga-suse | pedronis: https://github.com/snapcore/snapd/pull/3619 | 17:44 |
| mup | PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619> | 17:44 |
| Pharaoh_Atem | and unless zyga wants to add *that* to his plate of packages, it's unlikely to get in | 17:44 |
| zyga-suse | pedronis: nothing fancy, just a small cleanup | 17:44 |
| Pharaoh_Atem | nothing says that apparmor userspace can't be packaged, but you need to convince the kernel team to enable it | 17:44 |
| Pharaoh_Atem | they currently do not | 17:44 |
| jdstrand | tyhicks: technically, snapd could ship its own abstractions and parser there too | 17:44 |
| * zyga-suse has stuff falling off his plate already | 17:44 | |
| tyhicks | jdstrand: that's a very good point | 17:44 |
| Pharaoh_Atem | and all the things need to be compiled with apparmor support | 17:44 |
| zyga-suse | jdstrand: technically, don't we already do that in core? | 17:44 |
| zyga-suse | Pharaoh_Atem: I subscribed to both though I didn't get a confirmation from the NSA one | 17:45 |
| zyga-suse | (maybe they need to login to all my machines to check first ;-) | 17:45 |
| jdstrand | zyga-suse: yes. things would need to be shuffled around to use the internal parser, but yes | 17:45 |
| Pharaoh_Atem | tyhicks: it's a humongous amount of work and coordination to get things through and enabled, even with no policy | 17:46 |
| Pharaoh_Atem | zyga-suse: I've not seen an confirmation email either | 17:46 |
| Pharaoh_Atem | I'm not sure it sends one... | 17:46 |
| zyga-suse | Pharaoh_Atem: while it may not be supported by fedora I think tyhicks' point is that it can all be done in snapd as long as the kernel cooperates | 17:47 |
| zyga-suse | which is another question | 17:47 |
| Pharaoh_Atem | again, convincing the fedora kernel team is another obstacle toward that | 17:47 |
| Pharaoh_Atem | unless you want to be "point man" for Fedora AppArmor, it's not something worth suggesting | 17:48 |
| tyhicks | Pharaoh_Atem: what about all the technical limitations of attempting to write equivalent SELinux policy to match existing AppArmor policy? I feel like you're vastly ignoring the problems there | 17:48 |
| zyga-suse | well, I think we want to attempt both ways | 17:48 |
| zyga-suse | technically LSM stacking is easier and feels better | 17:49 |
| zyga-suse | but socially it may be received less well | 17:49 |
| zyga-suse | "easier" as in just easier, not easy though | 17:49 |
| Pharaoh_Atem | tyhicks: I'm not | 17:49 |
| Pharaoh_Atem | both are hard, but one involves working with a hell of a lot of other people | 17:49 |
| jdstrand | I don't doubt that some may push back, but lots of people want stacking-- this isn't just a snapd thing. lots of distros enable both selinux and apparmor (and other LSMs) in their kernels, but either do nothing with policy or pick one | 17:50 |
| Pharaoh_Atem | I think you underestimate how much coordination effort is actually required for getting even apparmor userspace up and going, even without policy | 17:50 |
| tyhicks | they both do | 17:50 |
| tyhicks | it is just different groups of people :) | 17:50 |
| jdstrand | there is a spectrum | 17:50 |
| jdstrand | Pharaoh_Atem: as mentioned, that could ll be packaged within snapd if the distro doesn't care about it | 17:51 |
| * zyga-suse things one thing is horribly missing; a good barrel of beer and all the key people in one room | 17:51 | |
| zyga-suse | so that all the hard edges can be discussed | 17:51 |
| Pharaoh_Atem | jdstrand: you're still missing that systemd can't filter profile things | 17:51 |
| Pharaoh_Atem | that needs linking into libapparmor | 17:51 |
| Pharaoh_Atem | look, adding apparmor as a userspace package is *easy* | 17:51 |
| jdstrand | we don't use systemd's apparmor support in snappy | 17:51 |
| Pharaoh_Atem | zyga-suse could propose it today, and I can have it added in right away | 17:52 |
| jdstrand | snapd manages it all itself | 17:52 |
| Pharaoh_Atem | that's not a big deal | 17:52 |
| Pharaoh_Atem | if zyga-suse put on his nicest outfit and the best words, he probably could sweet-talk Fedora kernel team into enabling apparmor in the kernel | 17:52 |
| Pharaoh_Atem | honestly, I'm not worried about those things | 17:52 |
| Pharaoh_Atem | what I'm worried about is making sure that the apparmor stuff is usable | 17:53 |
| Pharaoh_Atem | according to the folks I've talked to, there are currently no efforts in stacking selinux and apparmor | 17:53 |
| zyga-suse | "I have the best words" doesn't sound like someone I want to be affiliated with, just look at my hair anyway | 17:53 |
| tyhicks | that's not true | 17:53 |
| jdstrand | if people want full apparmor userspace, that's great and yes that would include the tools and systemd and policy and .... my point is that all that isnt strictly needed with snapd. only the kernel to have it compiled in. I suspect booting without it enabled wouldn't be terrible too-- snapd could mention changing the command line to make it work (at least until it proves itself) | 17:53 |
| tyhicks | we're (AppArmor upstream) working the author of the LSM stacking patch set | 17:54 |
| zyga-suse | Pharaoh_Atem: offtopic, boltron feels ... bolted ... on ... who names those things? | 17:54 |
| Pharaoh_Atem | zyga-suse: the Czech guys did | 17:54 |
| tyhicks | in fact, he is working on testing his patch set with the apparmor regression test suite: https://lists.ubuntu.com/archives/apparmor/2017-July/010909.html | 17:54 |
| Pharaoh_Atem | clearly, no sense for names | 17:54 |
| Pharaoh_Atem | jdstrand: look, if the kernel feature is enabled, there's literally no reason not to have apparmor in Fedora as userspace package | 17:55 |
| Pharaoh_Atem | it's probably easy for zyga to maintain as he works with you guys | 17:55 |
| tyhicks | this is something that we're going to be discussing and working on between now and the Linux Security Summit, where there's a BOF discussion | 17:55 |
| jdstrand | Pharaoh_Atem: I totally agree with that. In terms of steps and push back, etc, I'm just saying there are different options and paths | 17:55 |
| zyga-suse | it's hard as we have a hard time to keep focus on packaging _and_ upstream work | 17:55 |
| Pharaoh_Atem | and zyga-suse is friends with zbyszek, who is the fedora systemd maintainer :) | 17:56 |
| Pharaoh_Atem | so getting apparmor switched on in Fedora systemd is probably not going to be hard | 17:56 |
| Pharaoh_Atem | heck, for some reason, smack support is enabled | 17:56 |
| jdstrand | I'd love to see full blown apparmor support in fedora. I suspect some people might like it too. maybe that happens right away. maybe it doesn't. maybe having only snapd use it makes it more interseting to make it available in the distro | 17:56 |
| zyga-suse | s/friends/I was friendly towards him and vice versa but we never met IRL/g | 17:56 |
| zyga-suse | but yeah ;) | 17:56 |
| Pharaoh_Atem | I wish AppArmor had better diagnostics | 17:57 |
| tyhicks | Pharaoh_Atem: am I looking in the wrong place? http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/baseconfig/CONFIG_SECURITY_SMACK | 17:57 |
| jdstrand | anyway, I'm not advocating a particular path. I'm just mentioned some options | 17:57 |
| jdstrand | mentioning* | 17:57 |
| Pharaoh_Atem | tyhicks: I've never seen this before O.o | 17:57 |
| * Pharaoh_Atem should read these things more often | 17:57 | |
| Pharaoh_Atem | tyhicks: yeah, it's not enabled in the kernel | 17:57 |
| tyhicks | Pharaoh_Atem: how are you seeing that smack is enabled? | 17:57 |
| tyhicks | ok | 17:58 |
| Pharaoh_Atem | tyhicks: I mean it's enabled in systemd | 17:58 |
| tyhicks | ah, I see | 17:58 |
| Pharaoh_Atem | [neal@yu-ohki ~]$ systemctl --version | 17:58 |
| Pharaoh_Atem | systemd 233 | 17:58 |
| Pharaoh_Atem | +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN default-hierarchy=hybrid | 17:58 |
| zyga-suse | -apparmor :'-( | 17:58 |
| Pharaoh_Atem | zyga-suse: I suspect if you packaged apparmor for fedora and got it in, zbyszek would be happy to enable it | 17:59 |
| tyhicks | I don't want to discourage you from engaging with SELinux upstream but I did want to point out that AppArmor upstream is going to be working with the greater LSM community to get LSM stacking into shape and widely available | 17:59 |
| zyga-suse | to be able to commit to that I'd have to become a full blown package maintainer and I have a lot of upstream work to be able to do that, I don't think it's realistic today | 17:59 |
| Pharaoh_Atem | zyga-suse: tyhicks and jdstrand will gleefully support your endeavor to spread the AppArmors :P | 18:00 |
| tyhicks | we're getting pretty off-topic here but I'll mention that opensuse's packaging for apparmor would probably be reusable | 18:02 |
| Pharaoh_Atem | tyhicks: nothing is offtopic in a channel with no topic :) | 18:03 |
| tyhicks | :) | 18:03 |
| Pharaoh_Atem | but yes, it most likely would be | 18:03 |
| Pharaoh_Atem | it does some dumb suse-y things, but it's generally okay | 18:03 |
| * zyga-suse summons sysrich and gets popcorn | 18:03 | |
| Pharaoh_Atem | AppArmor has also been on the wishlist for literally years: https://fedoraproject.org/wiki/Package_maintainers_wishlist?rd=PackageMaintainers/WishList#A-D | 18:04 |
| Pharaoh_Atem | tyhicks: I have my hands full working on the features I'm working on in Fedora now | 18:06 |
| tyhicks | Pharaoh_Atem: I wasn't implying that you should do any work | 18:06 |
| Pharaoh_Atem | between the pkgconf transition in f26 and the new debuginfo stuff in f27 and the core development work in mga7, I'm stretched quite thinly | 18:06 |
| Pharaoh_Atem | nevermind keeping up with snappy stuff :) | 18:07 |
| tyhicks | yeah, sounds like a lot | 18:07 |
| Pharaoh_Atem | I need to find someone interested in snappy stuff in mga to pull into this | 18:08 |
| Pharaoh_Atem | I can't juggle so many things :) | 18:08 |
| zyga-suse | more hands is always good | 18:09 |
| zyga-suse | if you know someone that would be a good fit please introduce such a person | 18:10 |
| Pharaoh_Atem | I actually do | 18:10 |
| Pharaoh_Atem | Remi Verschelde | 18:10 |
| Pharaoh_Atem | Akien | 18:10 |
| Pharaoh_Atem | https://twitter.com/akien | 18:10 |
| Pharaoh_Atem | he's also one of the core developers of the Godot game engine | 18:10 |
| Pharaoh_Atem | zyga-suse: you should reach out to him with your best words :) | 18:13 |
| * zyga-suse thinks about another trump joke | 18:14 | |
| * zyga-suse has super slow network | 18:15 | |
| zyga-suse | I'm trying to follow him and I'll reach out as soon as my network recovers | 18:15 |
| zyga-suse | for now I'll resort to reading a book and trying to fall asleep again | 18:15 |
| niemeyer | I just deployed a new spread change that performs more caching to avoid hitting Linode so badly | 18:16 |
| Pharaoh_Atem | zyga-suse: you could email him instead if you want | 18:16 |
| niemeyer | Please let me know if you see any issue | 18:16 |
| niemeyer | s | 18:17 |
| zyga-suse | niemeyer: thanks! I assume locally installed spread should be updated as well | 18:17 |
| zyga-suse | niemeyer: how many requests were we making? | 18:17 |
| zyga-suse | Pharaoh_Atem: can you share his email address please? | 18:18 |
| niemeyer | niemeyer: Too many.. we've never tried to optimize away that because it was created with 2 or 5 instances in mind, rather than 20 or 30 | 18:18 |
| niemeyer | zyga-suse: ^ | 18:18 |
| Pharaoh_Atem | zyga-suse: done, sent via PM | 18:18 |
| niemeyer | zyga-suse: The Linode listing calls being the main offender, as they were done recurringly and per instance to check the power status | 18:18 |
| niemeyer | Now it performs a single list call for all instances, and caches the result.. so not linear anymore | 18:19 |
| Pharaoh_Atem | zyga-suse: feel free to cc me if you want | 18:22 |
| niemeyer | Folks, please update spread on your systems as well | 18:28 |
| niemeyer | cachio_ ^ | 18:28 |
| cachio_ | niemeyer, ok | 18:28 |
| === sergiusens_ is now known as sergiusens | ||
| sergiusens | jdstrand: today it tells you to adapts /dev/shm so that it is namespaced, but it is a common interface point for lttng so maybe suggest devmode until an interface exists | 18:45 |
| mup | PR snapcraft#1421 closed: ci: wait for apt/dpkg lock when setting lxd up <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1421> | 18:53 |
| niemeyer | pedronis: Did the final review on Chipaca's point, which is actually just a +1 on your point regarding the app name splitting | 18:53 |
| niemeyer | pedronis: Since Chipaca is not around, LGTM on the PR assuming we fix that | 18:53 |
| niemeyer | pedronis: The reason the PR had to introduce an independent split function is precisely that it's introducing an independent understanding of how to split, which seems unnecessary | 18:54 |
| niemeyer | (and wrongish) | 18:54 |
| niemeyer | This is about snapd#3614 | 18:55 |
| mup | PR snapd#3614: daemon, client, cmd/snap: implement "snap services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/3614> | 18:55 |
| mup | PR snapcraft#1410 closed: tests: remove download timeout workaround <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1410> | 18:59 |
| mup | PR snapcraft#1423 opened: Revert "tests: workaround issue that causes failures to download core… <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1423> | 18:59 |
| mup | PR snapd#3626 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3626> | 19:03 |
| jdstrand | sergiusens: ack | 19:04 |
| mup | PR snapd#3626 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3626> | 19:09 |
| mup | PR snapd#3627 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627> | 19:11 |
| cachio_ | niemeyer, if you have a time for review this PR 3627 | 19:13 |
| cachio_ | niemeyer, not sure why it shows 28 commits when I just did 2 | 19:14 |
| niemeyer | Looking | 19:16 |
| niemeyer | cachio_: That's because you have a fork of master on your end with dozens of changes, some of which have been integrated | 19:19 |
| niemeyer | cachio_: Create a new branch from master on your end, and then merge the patch from that branch on it, and it'll clean the PR up | 19:20 |
| cachio_ | niemeyer, ok, thanks | 19:21 |
| pedronis | niemeyer: well afaiu the code there wants use "foo" to always mean the snap, and "foo.foo" to mean the app, not quite sure how to accomodate that and the idea that foo means "foo.foo" | 19:25 |
| mup | PR snapd#3627 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627> | 19:25 |
| mup | PR snapd#3628 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3628> | 19:25 |
| pedronis | niemeyer: Chipaca: I fear it means probably the API is too dwimish for being an API | 19:27 |
| pedronis | niemeyer: is this bit of API convention/doc that is problematic: +// Apps returns information about all matching apps. Each name can be | 19:28 |
| pedronis | +// either a snap or a snap.app. | 19:28 |
| niemeyer | Oh no.. there we go again.. Chipaca will have a heart attack :) | 19:29 |
| niemeyer | pedronis: Hmm.. I think it may be okay, though | 19:30 |
| niemeyer | pedronis: We can use the foo.foo syntax to disambiguate, perhaps | 19:30 |
| pedronis | niemeyer: yes, exactly | 19:30 |
| pedronis | that's why he need the different split though | 19:30 |
| pedronis | niemeyer: my point is more whether this bit should be part of the REST API (or there app vs snap should be more explicit) or just part of cmd/snap code | 19:31 |
| niemeyer | pedronis: Yeah, indeed | 19:31 |
| mup | PR snapd#3628 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3628> | 19:32 |
| niemeyer | Let me check it again | 19:32 |
| Chipaca | niemeyer: ping | 19:32 |
| mup | PR snapd#3627 opened: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627> | 19:33 |
| niemeyer | Chipaca: I know! | 19:33 |
| niemeyer | :P | 19:33 |
| Chipaca | ? | 19:33 |
| niemeyer | Chipaca: Joking.. We were just discussing the PR and the comment above, seconds ago :) | 19:33 |
| Chipaca | ah. missed it. | 19:33 |
| niemeyer | Chipaca: Yeah, sorry, and no worries | 19:33 |
| niemeyer | Chipaca: I know the issue with my suggestion.. trying to think through it | 19:34 |
| Chipaca | niemeyer: but i'm hear about the pr and the review and the comment | 19:34 |
| niemeyer | (pedronis pointed out) | 19:34 |
| Chipaca | "the issue" being that AFAIK the only place where foo.foo == foo is in /snap/bin? | 19:34 |
| niemeyer | Chipaca: Well, every place we use the main split function that logic plays again | 19:35 |
| pedronis | Chipaca: also snap run I think | 19:35 |
| pedronis | and lots of places internally | 19:35 |
| niemeyer | Chipaca: So this is sort of a fundamental rule we've been trying to respect | 19:35 |
| niemeyer | Chipaca: Given the term Apps(foo) I think the most natural would be for foo to be names of apps | 19:36 |
| Chipaca | FTR, the service units do not follow this | 19:36 |
| niemeyer | Chipaca: So the app "foo" would IMO take precedence of the snap "foo" | 19:36 |
| niemeyer | Chipaca: Yeah, but that's sort of an edge that we'll soon see fixed | 19:37 |
| niemeyer | Chipaca: (that entry in the roadmap that we've been overlooking) | 19:37 |
| Chipaca | in fact I don't see a place that usees snap.SplitSnapApp that isn't about /snap/bin, or aliases | 19:37 |
| niemeyer | Chipaca: Where else do we talk about apps in the user interface? | 19:39 |
| niemeyer | Chipaca: Ah, and look at JoinSnapApp as well | 19:40 |
| niemeyer | Chipaca: This is the complement of Split | 19:41 |
| Chipaca | sigh | 19:42 |
| Chipaca | i don't see it being relevant for services :-( | 19:42 |
| Chipaca | i don't get why it's so fundamental all of a sudden | 19:42 |
| Chipaca | but, it's past my eod. i'll leave you to it. | 19:42 |
| Chipaca | ttfn! | 19:42 |
| niemeyer | Chipaca: The point is that it's not all of a sudden.. | 19:42 |
| Chipaca | … | 19:42 |
| niemeyer | Chipaca: Wait.. | 19:42 |
| Chipaca | niemeyer: but it is? | 19:42 |
| pedronis | DWIMish apis are strange | 19:42 |
| pedronis | I think we had related problems with aliases | 19:43 |
| zyga-suse | DWIM? | 19:43 |
| pedronis | and had to think a bit | 19:43 |
| pedronis | zyga-suse: do-what-I-mean | 19:43 |
| niemeyer | Chipaca: No, we do that for apps for quite a while, and services are apps, as we've been going through a few times | 19:43 |
| zyga-suse | aha | 19:43 |
| zyga-suse | gcc --dwim would be a nice feature | 19:44 |
| niemeyer | Chipaca: But, let's just try to fix this somehow.. hmm | 19:44 |
| Chipaca | if the veredict is "it's always app names, never snap names", that's easy to do | 19:46 |
| Chipaca | completion will be there, so users can always use alt-* | 19:46 |
| niemeyer | Chipaca: Problem with that is that the most useful outcome for that specific command is that it's always snap names | 19:46 |
| Chipaca | of course most users don't know about alt-* ¯\_(ツ)_/¯ | 19:46 |
| niemeyer | Chipaca: Maybe we should just split those apart | 19:46 |
| mup | PR snapd#3629 opened: tests: fix refresh tests not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3629> | 19:47 |
| niemeyer | Chipaca: That removes the ambiguity | 19:47 |
| niemeyer | Yeah, I think that's the most sane | 19:47 |
| Chipaca | niemeyer: io | 19:47 |
| niemeyer | Chipaca: Two different parameters.. instead of names, "apps" and "snaps", on the API | 19:47 |
| Chipaca | niemeyer: i'm not sure if you're agreeing with yourself or with me, there | 19:47 |
| Chipaca | niemeyer: i don't understand how that helps | 19:47 |
| mup | PR snapd#3627 closed: tests: fix refresh task not stopping fake store for fedora <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3627> | 19:48 |
| cachio_ | niemeyer, finally the PR to review is 3629 | 19:48 |
| niemeyer | Chipaca: apps resolves _only_ to apps, and snaps resolves _only_ to snaps (returning the set of all apps in that snap) | 19:48 |
| cachio_ | niemeyer, it is fixed now | 19:48 |
| Chipaca | yes but the user doesn't talk to the api | 19:48 |
| niemeyer | Chipaca: Then, on the CLI, let's accept snap names only | 19:48 |
| niemeyer | Chipaca: Or, actually.. we can still accept both.. one sec | 19:49 |
| mup | PR snapcraft#1408 closed: lxd: Stop setting $HOME in containers <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1408> | 19:50 |
| niemeyer | Chipaca: Yeah, okay: if we receive "foo" we handle it as a snap name.. if we receive "foo.bar" we handle it as an app name | 19:50 |
| niemeyer | Chipaca: Calling the respective APIs | 19:50 |
| Chipaca | when you say "calling the respective APIs" | 19:51 |
| niemeyer | Chipaca: The effect is pretty much the same as your current PR.. only difference is that the API becomes unambiguous | 19:51 |
| niemeyer | I guess it doesn't matter much.. | 19:53 |
| niemeyer | We can always introduce the new parameters with the new meanings.. | 19:54 |
| niemeyer | Chipaca: Go rest | 19:54 |
| niemeyer | Chipaca: PR LGTM once tests pass | 19:54 |
| Chipaca | PR has conflicts, and tests fail I assume because of the core release | 19:55 |
| Chipaca | will fix in the morning | 19:55 |
| Chipaca | g'night | 19:55 |
| * zyga-suse hugs Chipaca | 19:55 | |
| * Chipaca hugs zyga-suse back | 19:55 | |
| zyga-suse | have a good rest man | 19:55 |
| Chipaca | mmm | 19:55 |
| Chipaca | need a walk first i think | 19:55 |
| Chipaca | \o | 19:55 |
| pedronis | niemeyer: yes, having separate snaps vs apps seems similar to what we did with aliases I think | 19:56 |
| niemeyer | pedronis: Yeah, I think that's what we need | 19:56 |
| niemeyer | pedronis: Let's please make sure that the current parameters is "names" instead of "apps" | 19:57 |
| niemeyer | pedronis: So we clear the path for the unambiguous version of those | 19:58 |
| niemeyer | apps should be apps, not snaps | 19:58 |
| pedronis | ah, yes, it's apps | 19:58 |
| pedronis | atm | 19:58 |
| pedronis | so it need some change anyway :/, we'll see what Chipaca thinks | 19:58 |
| niemeyer | pedronis: Let's just call it "names".. makes no difference for this PR | 20:00 |
| niemeyer | pedronis: We can keep support for "names" later as the magic matching, as is now, and have "snaps" and "apps" with the unambiguous versions of those | 20:01 |
| pedronis | just pointing out that the PR needs a change | 20:01 |
| niemeyer | Yeah, it needs a change anyway | 20:01 |
| pedronis | a small one | 20:01 |
| niemeyer | (to solve conflicts) | 20:01 |
| pedronis | ah, that too | 20:01 |
| pedronis | ok | 20:01 |
| * zyga-suse read https://lwn.net/Articles/728699/ | 20:03 | |
| niemeyer | cachio_: Do you have the new PR? | 20:03 |
| niemeyer | zyga-suse: Paywal | 20:03 |
| niemeyer | l | 20:03 |
| zyga-suse | niemeyer: I think you have a subscription | 20:04 |
| zyga-suse | niemeyer: but I can give you a "free" link in a PM if you want one | 20:04 |
| niemeyer | zyga-suse: Do I? Either way, most people here don't I'd assume | 20:05 |
| zyga-suse | niemeyer: everyone at Canonical does | 20:05 |
| zyga-suse | I PMd you with a "freel" link | 20:05 |
| cachio_ | niemeyer, yes | 20:18 |
| cachio_ | niemeyer, I had to recreate the local master | 20:19 |
| cachio_ | niemeyer, and make cherry-pick to fix it | 20:19 |
| niemeyer | cachio_: link? | 20:19 |
| cachio_ | niemeyer, https://github.com/snapcore/snapd/pull/3629 | 20:21 |
| mup | PR snapd#3629: tests: fix refresh tests not stopping fake store for fedora <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3629> | 20:21 |
| dpb1 | hey all --- $ simplenote | 20:21 |
| dpb1 | cannot stat /var/lib/snapd/seccomp/bpf: No such file or directory | 20:21 |
| dpb1 | something missing with apparmor? | 20:22 |
| zyga-suse | dpb1: hey, what is your "snap version"? | 20:24 |
| zyga-suse | that looks like a bug in snapd | 20:24 |
| zyga-suse | dpb1: (it's actually seccomp, not apparmor this time) | 20:24 |
| dpb1 | sec | 20:25 |
| dpb1 | snap 2.26.14 | 20:25 |
| dpb1 | (xenial) | 20:25 |
| dpb1 | ah, snapd update is waiting | 20:25 |
| zyga-suse | is this in a container? | 20:26 |
| niemeyer | cachio_: I'm finding these prepare and restore in the refresh test pretty hard to follow | 20:26 |
| niemeyer | cachio_: There are so many exit points.. pretty hard to track what is actually happening there | 20:26 |
| dpb1 | zyga-suse: no, it's a desktop workstation | 20:26 |
| dpb1 | I'm upgrading snapd and will try again | 20:26 |
| zyga-suse | dpb1: can you open a topic on forum.snapcraft.io please? | 20:26 |
| dpb1 | zyga-suse: sure | 20:27 |
| zyga-suse | dpb1: add things like "snap version" (the full output), "snap changes" and the name of the snap that you saw this with | 20:27 |
| niemeyer | cachio_: Your changes are minor, so if they fix the problem, LGTM | 20:27 |
| niemeyer | cachio_: But it would be good to clean that up at some point | 20:27 |
| zyga-suse | dpb1: not sure what's wrong yet, I mean, I know but not sure why :) | 20:27 |
| dpb1 | zyga-suse: looks like it's still happening after the upgrade, so I will open that post | 20:27 |
| cachio_ | niemeyer, but I already did it | 20:27 |
| zyga-suse | dpb1: ack | 20:28 |
| niemeyer | cachio_: ? | 20:28 |
| zyga-suse | when did it break on you? | 20:28 |
| cachio_ | niemeyer, the clean up for the commits | 20:28 |
| zyga-suse | just now? | 20:28 |
| zyga-suse | (we released a new stable core snap so you likely updated to it) | 20:28 |
| zyga-suse | dpb1: paste the link to the forum once you have that topic up | 20:29 |
| niemeyer | cachio_: Did you read the messages above? :) | 20:29 |
| cachio_ | niemeyer, no, now reading | 20:29 |
| zyga-suse | niemeyer: can you squeeze a quick review of https://github.com/snapcore/snapd/pull/3619 ? | 20:29 |
| mup | PR snapd#3619: interfaces/builtin: reduce duplication and remove cruft in Sanitize{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/3619> | 20:29 |
| * zyga-suse is 3/4 through "ponyo" but then needs to put kids to bed (including any extra food and cleaning they may need) | 20:30 | |
| cachio_ | niemeyer, yes, agree with you, there are so many if | 20:30 |
| cachio_ | niemeyer, as part of this branch I just fixed the issue | 20:30 |
| dpb1 | zyga-suse: https://forum.snapcraft.io/t/simplenote-snap-cannot-stat-var-lib-snapd-seccomp-bpf-no-such-file-or-directory/1446 | 20:30 |
| zyga-suse | thanks! | 20:30 |
| niemeyer | cachio_: Not just that, but the break outs via exit makes it all hard to follow | 20:30 |
| zyga-suse | ha | 20:31 |
| cachio_ | niemeyer, ok, I can work in another branch to simplify that | 20:31 |
| zyga-suse | snap 2.26.14 | 20:31 |
| zyga-suse | snapd 2.25 | 20:31 |
| zyga-suse | this is very very wrong! | 20:31 |
| zyga-suse | can you add your journal logs? (like journalctl -u snapd) | 20:31 |
| niemeyer | cachio_: Not super urgent, but worth an item in the backlog | 20:31 |
| cachio_ | niemeyer, in fact, the prepare/restore is repeated in 7 tests | 20:31 |
| cachio_ | niemeyer, prepare-image-grub, refresh-all-undo, refresh-all, refresh-devmode, refresh, revert-devmode and revert | 20:32 |
| zyga-suse | dpb1: let's move the discussion to the forum | 20:32 |
| cachio_ | so, 1 fix would work for all of them | 20:33 |
| dpb1 | zyga-suse: adding | 20:33 |
| dpb1 | zyga-suse: and ok | 20:33 |
| dpb1 | :) | 20:33 |
| cachio_ | niemeyer, it goes to my queue | 20:35 |
| zyga-suse | dpb1: more questions posted | 20:36 |
| dpb1 | zyga-suse: ok, I'm doing an apt-get dist-upgrade right now as I'm pretty out of date | 20:37 |
| zyga-suse | dpb1: which version were you on? | 20:37 |
| dpb1 | zyga-suse: I'll post back results to the forum in a sec | 20:37 |
| zyga-suse | thanks! | 20:37 |
| mup | Bug #1681833 changed: Devmode Edge Snap not automatically updating <Snappy:Invalid> <https://launchpad.net/bugs/1681833> | 20:40 |
| mup | PR snapcraft#1422 closed: ci: remove the old script to run with lxc <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1422> | 20:41 |
| niemeyer | cachio_: Thanks! | 20:41 |
| * zyga-suse afk for some time | 20:41 | |
| jdstrand | roadmr: hey, I added another check to the review tools. can you sync r892? this isn't urgent | 20:46 |
| roadmr | jdstrand: sure thing! | 20:46 |
| jdstrand | roadmr: thanks! | 20:46 |
| === cachio_ is now known as cachio_afk | ||
| mup | PR snapcraft#1373 closed: snapcraft.yaml: add support for reload-command and completer directives <Created by bloodearnest> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1373> | 20:56 |
| === zarcade_droid is now known as ^arcade_droid | ||
| * zyga-suse EODs | 21:35 | |
| mup | PR snapcraft#1416 closed: core: a clean command should clean <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1416> | 22:08 |
| mup | PR snapcraft#1423 closed: Revert "tests: workaround issue that causes failures to download core… <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1423> | 22:11 |
| === cachio_afk is now known as cachio | ||
| mup | PR snapcraft#1418 closed: nodejs plugin: copy the content of out of tree symlinks <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1418> | 22:38 |
| mup | PR snapd#3629 closed: tests: fix refresh tests not stopping fake store for fedora <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3629> | 23:05 |
| cachio | niemeyer, 2017-07-26 23:17:27 Cannot allocate linode:ubuntu-14.04-64: backend "linode" missing Linode API key | 23:19 |
| cachio | niemeyer, all the builds failing because of that | 23:19 |
| cachio | niemeyer, example: https://travis-ci.org/snapcore/snapd/builds/257940281?utm_source=email&utm_medium=notification | 23:20 |
| niemeyer | cachio: Thanks, will have a look later today | 23:20 |
| cachio | niemeyer, quick question, any idea is snapd will be uploaded to the zypper repository? | 23:23 |
| niemeyer | cachio: I don't really know | 23:27 |
| cachio | niemeyer, ok, np | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!