o something with it when you have time
<pedronis> mborzecki: Chipaca: another approach would be to find something a bit more encompassing than "name" and also put Channel and some helpers for the various kind of IDs we have there
<mborzecki> Chipaca: do you have /usr/bin/tar?
<mup> PR snapd#6020 opened: overlord/snapshotstate/backend: detect path to tar in unit tests <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6020>
<mborzecki> Chipaca: ^^
<niemeyer> zyga: I've responded on the adb interface.. sorry that it's not just a LGTM, but the current proposal there looks quite cumbersome, and a bad precedent.. we should probably talk about it in a call if you have a moment
<zyga> niemeyer: thank you, I'll check that out
<zyga> niemeyer: perhaps next week, it's not urgent IMO
<niemeyer> zyga: Today is better if you have a moment.. next week I'm in SLC
<niemeyer> zyga: It's not urgent.. it's just been sitting there for very long
<zyga> niemeyer: I'm not at home today but I'll try to find a moment
 * pstolowski lunch
<zyga> niemeyer: I read the response, I think you are right and this feels like a new thing - with foo-support like approach we could have the adb  server part solved, I think we should still have the adb client part
<niemeyer> zyga: We can have that to actually make the inter-snap logic work, but I wouldn't try to bake that in together
<niemeyer> zyga: As that's not required for the person that submitted that request, as I understand it, and it would take longer to agree on the details
<zyga> yes, that's true
<zyga> the user would just run adb internally
<niemeyer> zyga: Yeah, that sounds a lot like browser-support
<niemeyer> zyga: And it becomes pretty sensible from the outside
<zyga> I can make those changes if that's what we agree on
<niemeyer> zyga: once we need a snap using adb from another snap, we can then have an "adb" plug+slot interface, that do just that
<zyga> +1
<niemeyer> zyga: If we can make that work, we can even get that merged today
<zyga> sure, that would b