[01:22] PR snapcraft#2368 closed: {kbuild,kernel} plugin: add support for bases [02:28] anything obviously wrong with this snapcraft.yaml ? https://pastebin.com/GSWxvuAQ [02:33] maaaan.. cleanbuild takes ages [03:19] PR snapcraft#2369 opened: Hide progress bar for dumb terminals [05:11] morning [06:13] got to run an errand, back in ~30 [06:47] Hey [06:49] Hey mvo [06:49] hey zyga [06:49] Prepping for SLC? [06:49] I forgot to mention that I will be working with Zbyszek from red hat today [06:50] I plan to discuss some Fedora issues as well as some cgroup topics [06:50] I will be around as usual, sort from the extra commute [06:50] zyga: yeah, preparing [06:50] zyga: cool, good luck [06:53] mvo: can you think of any systemd topics to ask about? [06:58] mborzecki: ^ [06:59] zyga: heh - the mount race [06:59] zyga: but maybe not [06:59] Oh, for sure [06:59] No? [07:00] zyga: I mean, if its really util-linux then its none of his concern [07:00] zyga: but *maybe* it is not, might be nice to hear his opinion [07:00] I think it is worth trying at least [07:01] yeah [07:06] morning [07:14] zyga: yes, systemctl start as single transaction [07:15] need to go to kids school [07:16] zyga: https://bugs.launchpad.net/snapd/+bug/1796125 [07:16] Bug #1796125: services in a snap with dependencies aren't started in correct order on install [07:16] zyga: there are links to systemd github issues in the comments [07:16] zyga: would be great if he had a suggestion for a reasoanble workaround, or eta if they plan to do it [07:16] bbiab [07:23] PR snapd#6014 closed: ifstate: fix decoding of json numbers [07:32] mborzecki: the one with services? [07:32] mborzecki: he replied on it already [07:33] But I will ask just in case :-) [07:45] Hey Chipaca [07:46] hey yourself [07:46] Chipaca: do you have any questions or issues to raise about systemd? [07:47] zyga: ? [07:47] zyga: I don't, offhand, why? [07:47] I’ll work with Zbyszek today [07:47] He is a systemd upstream [07:48] ah [07:48] zyga: is there a way to cause all the starts/stops to be in a single transaction [07:49] zyga: or do we need to do the topological sort ourselves [07:49] (we already are, almost ¯\_(ツ)_/¯ ) [07:50] zyga: dunno if you remember from yesterday, this is that we have before/afters in units in a snap, and those are respected at system boot, but when we systemctl start them all at snap install time, they're started without ordering [07:50] Chipaca: oh, yes, that is a good one [07:50] I’ll ask [07:51] also try to convince them to absorb something else, people can only hate on one thing at a time [07:51] :-p [07:53] Is this the same issue that war reported by ian? [07:53] Or better yet: do you have a link [07:53] I’m on the tube now but I will collect them later [07:53] zyga: i think we talked about it in the standup [07:53] i don't have issues/links/etc to go with it [07:56] mborzecki: you around? let's chat about the snapname pr [07:56] mborzecki: ^ is this the same issue you mentioned? [07:56] relatedly, somebody is calling github.com/snapcore/snapd/client a "library" and i'm worried [07:57] yes, if we need to treat it as one we need to know [07:57] atm only asserts is officially used as a library, but from things we control tough [07:59] pedronis: https://github.com/snapcore/snapd/pull/6011#issuecomment-431214304 [07:59] PR #6011: Fix import as module by adding go.mod files [08:00] pedronis: and http://r.chipaca.com/client.png if you need to make a point about things [08:01] Chipaca: it's mostly auth from store provoking the mess I suppose [08:01] we would need store/auth [08:01] and to do reasosnable things with overlord/auth [08:01] which is also misnamed atm [08:01] and mixing a couple different concerns [08:02] pedronis: buy is the thing pulling in store [08:02] not auth stuff? [08:03] maybe that was long ago [08:03] no auth stuff [08:03] yea, I see [08:04] so it's Buy stuff [08:04] :( [08:04] and it looks like it's just for a struct [08:04] or two [08:04] we could easily turn that one around [08:04] or we could go on and kill buy :-) [08:05] after store, there's snap and overlord/auth [08:05] snap is http://r.chipaca.com/snap.png [08:08] Chipaca: mmh, it doesn't import overlord/auth directly, or does it? [08:08] anyway I seem confused [08:08] either way it's a bit of work to make it a "library" [08:09] pedronis: if I copy the structs for Buy in, all client depends on is snap and asserts [08:09] asserts is fine [08:09] I suppose [08:09] pedronis: http://r.chipaca.com/client_pruned.png [08:10] so maybe we should do that [08:10] Chipaca: the annoying bits of snap, are really that it pulls in squashfs, dirs, and maybe arch (I don't remember how naive or not that is these days) [08:11] also snapdir [08:11] pedronis: why is the squashfs import annoying? [08:12] dirs is fine, it's just config [08:12] arch is a funny one, mostly because i'm not sure it needs to be its own package [08:13] Chipaca: because is conceptually wrong, and because one day it might brings in a big library instead of shelling out [08:13] pedronis: can you explain the misconception to me? [08:13] Chipaca: dealing with snaps abstractly/remotely vs concrentely are very different things [08:13] ah [08:14] pedronis: well, it would be easy to split [08:14] it's just a taste thing [08:14] but the bring in a library bit is a bit more serious [08:14] pedronis: snap/container.go -> snap/container/container.go (or some better name) [08:14] potentially [08:15] Chipaca: osutil/sys is also interesting [08:15] then snap can be the abstract, and snap/container be the "open this thing" and the "build this thing" aspects of it [08:16] osutil and osutil/sys are in the middle of finding themselves [08:16] :-p [08:16] the idea is that osutil/sys is like syscall, and has friendly wrappers in osutil [08:16] but there's work to do to finish that division, and so things are a bit messy still [08:16] (including a bit of duplication) [08:17] i'm not sure if that makes it better or not :-) [08:18] Chipaca: just wondering why snap imports it [08:18] directly [08:19] PR classic-snap#21 closed: create: improve user information [08:19] pedronis: without looking, probably sys.UserID and sys.GroupID [08:19] now looking [08:19] UserXdgRuntimeDir(userID sys.UserID) string [08:20] I see [08:20] mmmh [08:20] lots of conceptual decisions to make [08:22] Chipaca: in theory the easiest is to invert and have anything in snap that client needs live in client, import client from snap [08:22] but I'm not 100% happy with that [08:22] either [08:24] pedronis: why not? [08:24] (sorry if this explain-your-thinking interrogation gets boring) [08:25] PR classic-snap#26 opened: Add simple spread tests [08:27] Chipaca: it reads strange to me [08:27] client.Revision [08:27] is odd [08:27] maybe is just me [08:27] ah, yes [08:28] no not just you [08:28] when i was saying we could do that i found the same thing === alan_g is now known as alan_g_ [08:28] OTOH we could have client/snap and internal/snap? [08:28] dunno [08:28] * pedronis errands [08:29] pedronis: ttfn [08:43] re [08:43] PR snapd#6015 closed: tests/unit/gccgo: drop gccgo unit tests [08:43] PR snapd#6018 opened: nuke tests/unit/go-darwin [08:44] I'd love to get reviews of #5955 [08:44] PR #5955: cmd/snap, tests: snapshots for all [08:44] it's green! and the only thing between us and snapshots [08:52] PR classic-snap#27 opened: add shellcheck and fix warnings (16) [09:02] re, finally [09:05] PR snapcraft#2362 closed: python plugin: add support for bases [09:05] PR snapcraft#2364 closed: maven plugin: add support for bases [09:20] Chipaca: thanks for the reviews [09:20] Chipaca: any suggestions about snap/name? [09:20] mborzecki: I didn't understand your response to my comment :-) [09:21] sorry, stray middle click [09:22] mborzecki: what do you mean by "you'd still need to have access to snap.Info"? [09:22] mborzecki: how is that different between snap/validate and snap/name? [09:22] Chipaca: hmm maybe i misunderstood yours [09:23] mborzecki: ah [09:23] Chipaca: i thought you'd want to have all the validation code (now in snap/validate.go) in a seaprate snap/validate package? [09:23] mborzecki: mine was just: everything in name is called ValidateX [09:23] mborzecki: so why not call it validate :) [09:24] mborzecki: then using snap/validate primarily in snap/validate.go is a nice pattern as well [09:24] we do that in a few places even [09:25] Chipaca: right, but then we'd end up with some validate*() in snap/validate.go and some in snap/validate, felt a bit uneasy about that [09:25] Chipaca: but you have a point, it's snap/name now but all of it actually validation :/ [09:26] mborzecki: looking at snap/validate.go in your pr, 1 sec [09:26] mborzecki: snap.ValidateVersion could move into the new package [09:26] dito snap.ValidateLicense [09:27] Chipaca: license calls out to spdx package? [09:27] yes [09:28] Chipaca: i think i'd rather keep it ValidateLicense in snap then [09:29] hm [09:29] mborzecki: so [09:29] mborzecki: how about keeping just snap.Validate as the public interface, and making everything else be either in snap/validate or private in snap? [09:29] Chipaca: the motivation was to not have another copy of ValidateName() in asserrts, but rather have a package slimmer than snap and have it importable in asserts [09:30] ha, now i understand the no-spdx thing more :-) [09:30] mborzecki: this strengthens my last suggestion above [09:30] i think [09:32] Chipaca: hm, let me check again, iirc snap.ValidateLayout may still need to be public, but the rest could be make private [09:32] grep says nothing uses it outside of snap.Validate [09:34] Chipaca: ValidateContainer is probably the only func other than Validate() that would need to be public [09:35] i see some calls to ValidateSlotName() but that would be validate.SlotName() (or validate.Slot()) now [09:40] Chipaca: yeah, snap/validate seems ok, a question about naming, since the validation code is mostly validating names right now, validate.SnapName() feels more fitting than validate.Snap(name string) [09:45] PR snapd#6019 opened: ifacestate: optimize disconnect hooks [09:45] Chipaca: the problem of making it validate that it will be very tempting to move Validate itself or other things into it at some point [09:46] Chipaca: also there are some name related regexpes that asserts could reuse [09:46] Chipaca: making it about names (which are strings in the end), makes it easier to keep under control imo [09:48] snap/validate/name :) [09:48] that is not funny [09:50] Chipaca: mborzecki: anyway my 2cts [09:51] pedronis: which regexp you'd like to see public? [09:52] mborzecki: asserts has at least a validAppName and validAlias atm [09:55] degville: hi, somebody liked this just now which I wrote long ago, https://forum.snapcraft.io/t/the-meaning-of-classic/861 is not under doc because niemeyer said he wanted to tweak it a bit but didn't get to it, maybe you can do something with it when you have time [09:58] 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 [10:15] Chipaca: do you have /usr/bin/tar? [10:27] PR snapd#6020 opened: overlord/snapshotstate/backend: detect path to tar in unit tests [10:28] Chipaca: ^^ [10:39] 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 [10:39] niemeyer: thank you, I'll check that out [10:39] niemeyer: perhaps next week, it's not urgent IMO [10:40] zyga: Today is better if you have a moment.. next week I'm in SLC [10:40] zyga: It's not urgent.. it's just been sitting there for very long [10:41] niemeyer: I'm not at home today but I'll try to find a moment [10:44] * pstolowski lunch [10:48] 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 [10:48] zyga: We can have that to actually make the inter-snap logic work, but I wouldn't try to bake that in together [10:49] 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 [10:49] yes, that's true [10:49] the user would just run adb internally [10:49] zyga: Yeah, that sounds a lot like browser-support [10:49] zyga: And it becomes pretty sensible from the outside [10:50] I can make those changes if that's what we agree on [10:50] zyga: once we need a snap using adb from another snap, we can then have an "adb" plug+slot interface, that do just that [10:50] +1 [10:50] zyga: If we can make that work, we can even get that merged today [10:51] sure, that would be nice :) [10:51] zyga: Since the details of what's allowed was already approved [10:51] zyga: (by jdstrnad) [10:51] zyga: Same as in the current incarnation, we shouldn't allow access to the devices unless adb-support is connected [10:51] zyga: There's another part which feels a bit awkward in that interface which is the network bits [10:52] zyga: Does it grant open access into the network? [10:52] ish [10:52] it needs localhost sockets [10:53] it's like network [10:53] this is how adb operates [10:53] (well network-bind and network() [10:54] zyga: Sure, but the comments there make it sound like we're granting open ended access into the network via that interface [10:54] zyga: That sounds undue [10:54] that's because we have no richer language [10:54] yes , that is true [10:55] zyga: If it's open ended and not localhost, and unless there's more missing that would prevent the access from being actually used for general network access, I think we can drop those permissions and mention that they'll need "network-bind" as well [10:56] zyga: Sure, and in some cases that's alright, but here it feels like we have a very purpose-specific interface that is then offering something unexpected, and unnecessarily so since we have another interface that grants exactly those permissions [10:56] zyga: Once we get the ability to define network context, we can include in the interface, and nobody breaks [10:56] The opposite isn't true [10:56] in a way but it is also internal part of the interface, it will always be broken without network-bind [10:57] zyga: That's not an internal part of the interface unless we define that it is [10:57] zyga: If it's open ended network access, I'd generally recommend letting people explicitly ask for it [10:57] jdstrand: ^ [10:58] I mean without network-bind, adb will crash [10:58] zyga: Doesn't hurt, comes for free with auto-connection, and is truthful to what the snap is being able to do [10:58] sure, I don't mind that [10:58] I can make the modifications today [10:58] zyga: I understand.. that's why they'll use the plug.. [10:58] zyga: Once we're able to further restrict so that it's not open ended access, we can be more precise in what we offer [10:59] zyga: and the interface might become self-sufficient [10:59] yeah, that's a good point [11:08] PR snapcraft#2367 closed: tests: add spread test exercising multipass build VMs [11:10] zyga: Pasted this conversation into the ticket for reference [11:10] zyga: Sorry for the terrible copy & paste... my client has c&p broken right now [11:10] pedronis: mborzecki: i'm ok with it not being validate if that'll keep it about simple strings as opposed to more complex stuff, if we don't want it to have more complex stuff (and i guess using it from asserts means we don't) [11:10] niemeyer: thank you :-) [11:10] I'm going to have lunch [11:10] enjoy :) [11:10] Thanks [11:11] pedronis: mborzecki: otoh i maintain that 'name' is a bad name :-) note how everywhere you use it you have to re-name (groan) it [11:12] pedronis: mborzecki: combine that with pedronis's observation about having other things we could move out if it weren't called 'name', and i really want it called something else :-) [11:12] pedronis: mborzecki: call it "english-racing-green" [11:13] Chipaca: moss? [11:13] a package full of surprises [11:13] i thought that was lichen [11:15] mborzecki: 'twas a bikeshed joke, just in case it was too unobvious [11:15] Chipaca: it was [11:16] sary [11:16] uh, it wans't :) [11:16] saryn't [11:18] things we want that package to do: validate instance names, validate snap names, validate channels, validate other ids [11:19] things we can't call it because conflicting things with too similar names; snapids, snapidents [11:20] name that probably only serves to make me giggle: snapvalids (groan) [11:20] you should feel bad about yourself Chipaca :) [11:21] every day, noise][. Every day. [11:52] Chipaca: handle (the name, not the verb), moniker, refer, designate, nominate [11:52] nomnomnom [11:52] hmm, lunch [12:00] Are the various SNAP_ environment variables documented anywhere? I'm looking at docs.snapcraft.io and don't see it anywhere obvious, and I'm a bit lost after the refactor. [12:00] The environment variables were previously the reference section IIRC, but that doesn't seem to be there any more. [12:00] google got me to https://snapdocs.labix.org/look-at-this/5368 [12:00] which is a mad url [12:02] popey: https://docs.snapcraft.io/moved-environmental-variables-that-snapcraft-exposes/5368 [12:02] popey: dunno where it was moved to, offhand [12:02] popey: but until they get hidden, you can use the ids to find stuff :-) [12:02] I want SNAP_* rather than SNAPCRAFT_* [12:02] And also what they mean rather than what they're set to [12:03] rbasak: try this https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 [12:03] rbasak: https://docs.snapcraft.io/environmental-variables/7983 [12:04] Thanks! [12:04] Though that doesn't explain SNAP_INSTANCE_DATA? [12:05] that'll be in https://docs.snapcraft.io/parallel-installs/7679 [12:05] but i agree it should get added to the other one [12:05] mborzecki: ^ :-) [12:05] augh, i need to go have lunch [12:05] * Chipaca goes [12:05] w8, why doesn't https://docs.snapcraft.io/environmental-variables/7983 have SNAP_INSTANCE_NAME? [12:06] Thanks! That page also doesn't explain SNAP_INSTANCE_DATA, but I think from the context it's clear I can ignore SNAP_INSTANCE_* [12:06] rbasak: which version of snapd do you have? SNAP_INSTANCE_DATA is no more [12:06] 2.34.2 on Xenial on this particular system [12:07] rbasak: ah ok, makes sense now [12:13] degville: added a note about SNAP_INSTANCE_NAME and SNAP_INSTANCE_KEY to https://forum.snapcraft.io/t/environmental-variables/7983 [12:14] mborzecki: thank you! [12:19] * Chipaca sneaks SNAP_TROLL_NAME in to keep people on their toes [12:19] * Chipaca is making lunch, so technically on lunch break [12:20] can we s/environmental/environment/ too :) [12:20] always makes my teeth clench when i see 'environmental' [12:21] degville: ^^ [12:22] hm discourse should be smart enough to figure it out when the topic is changed [12:26] popey: to be fair, the environ is mental [12:27] wakka wakka wakka [12:28] mborzecki: It pops it up in the list, but it doesn't resend notifications [12:30] popey/mborzecki: changed. [12:30] <3 [12:30] aww, shucks. [12:34] interesting observation, not a problem though, i was automatically redirected to https://forum.snapcraft.io/t/environment-variables/7983 by discourse, but the same did not happen on docs.snapcraft.io [12:36] mborzecki: 'snap fork a-snap a-snap_foo' [12:37] Chipaca: snap wait ... [12:37] oh wait! [12:38] or maybe 'snap switch --rename=a-snap_foo a-snap' [12:38] hmm [12:38] Chipaca: snap rename [12:38] snap rename core core18 [12:38] mbuahaha [12:39] switch is wrong, because it isn't instant [12:39] it'd have to be 'snap refresh' and then not having the equivalent switch would be strange [12:39] so maybe 'snap rename' is the potato [12:40] PR classic-snap#28 opened: enable spread tests for core as well [12:40] snap instantiate [12:40] snap summon [12:43] PR snapd#6021 opened: data/systemd, wrappers: tweak system-shutdown helper for core18 (2.36) [12:45] Chipaca: conjure [12:46] snap dwim [12:46] snap frogger [12:46] * Chipaca checks his drink [12:46] looks like it's free-association-friday [12:47] I'll skip standup to grab some food, plus no way to have a call now [13:27] I'm improving the git-ubuntu importer service, which lives inside the snap and is currently just a command. I want to make it into a systemd service which a sysadmin can enable, and once enabled, it will run as a specific user (not root). It seems to make sense to me to put its persistent data in $SNAP_DATA. But: 1) how should I ship a snap such that the service isn't enabled by default, but it can be [13:27] enabled; 2) $SNAP_DATA is owned by root. Can I change that? What should the mechanism be to do that? [13:29] Most git-ubuntu users will never use the service. However we maintain it in the same code base, and the snap is a convenient way of deploying it. I could split it into a different snap but would like to avoid having to maintain two. [13:30] (and splitting it doesn't help me with ownership of $SNAP_DATA I don't think) [13:30] PR snapd#6020 closed: overlord/snapshotstate/backend: detect path to tar in unit tests [13:34] rbasak: so, first off, we don't currently support running services as non-root [13:34] rbasak: nor do we support setuid and fly [13:36] rbasak: but, to ship a service that's default disabled you can have a hook [13:36] rbasak: e.g. have a config hook that creates a file, and the service starts and quits if the file isn't there [13:37] Chipaca: in current master you can disable it from install hook [13:37] yes :-) but that's a week or so away at least [13:37] probably more [13:38] mborzecki: is it 2.36? [13:38] or --edge :) [13:38] Chipaca: thanks [13:38] Chipaca: yes [13:39] Given that the service is only expected to be used by (essentially just) me, perhaps I'll keep the service out of the snap for now then, together with its persistent directory. [13:39] The classic snap gives me a command, and maybe I can run that command using a manually (non-snap) defined systemd service. [13:39] Then I can run it as a user as well. [13:52] rbasak: OTOH james h has been working on user session services, but I have no idea how usable that is yet [13:52] rbasak: solutions are in the pipeline --- but it's a long, thin pipe [13:52] and it's like molasses in there :-p [13:53] PR snapd#6007 closed: tests/lib: add an @mozilla.com exception to the CLA checker