[06:25] <mup> PR snapd#3344 closed: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3344>
[06:26] <morphis> mvo: thanks!
[06:27] <mvo> morphis: thank you, that was a really useful fix!
[06:27] <morphis> :-)
[06:28] <mvo> morphis: want a hand with 3307? I can apply the simplifications if you want, otherwise the branch looks good so I'm keen to get it in soon(ish)
[06:29] <morphis> mvo: ah you approved it, was waiting for another review to get this further before I rework this
[06:29] <morphis> mvo: let me do that now
[06:29] <mvo> ta
[06:31] <morphis> mvo: pushed
[06:32] <morphis> mvo: while we're on it, what are we doing now with https://github.com/snapcore/snapd/pull/3308
[06:32] <mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
[06:32] <morphis> mvo: I will work on getting it through the tests today but would like to have a final agreement on how we implement this
[06:34] <zyga> good morning
[06:36] <mvo> morphis: looking again
[06:36] <morphis> zyga: morning!
[06:37] <morphis> zyga: I would like to get to an agreement for https://github.com/snapcore/snapd/pull/3308
[06:37] <mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
[06:38] <morphis> zyga, mvo: maybe we can quickly discuss anything left here
[06:41] <zyga> morphis: sounds good
[06:42] <zyga> morphis: I think I made my statement, I will respect whatever mvo decides
[06:42] <zyga> and if it doesn't work down the line (whatever we choose), it's just a commit away to change :)
[06:42] <morphis> true :-)
[06:42] <mup> PR snapd#3346 opened: [WIP] allow access to nm-dispatcher scripts <Created by felicianotech> <https://github.com/snapcore/snapd/pull/3346>
[06:47] <mvo> zyga: I added another comment, but I agree, I think we just move forward we can always revisit the decision
[06:48] <zyga> ok, let's merge it then
[06:49] <morphis> mvo, zyga: thanks!
[06:49] <morphis> anymore real code-review comments?
[06:51] <zyga> morphis: I just had a look but I think that's all for now
[06:51] <morphis> zyga: ok, then let me see that tests are passing
[06:59] <morphis> mvo, zyga: https://github.com/snapcore/snapd/pull/3337 can have another review too
[06:59] <mup> PR snapd#3337: errtracker: try multiple paths to read machine-id <Created by morphis> <https://github.com/snapcore/snapd/pull/3337>
[07:16] <abeato> zyga, hi, what is this system-shutdown command for? when is it used?
[07:16] <mvo> abeato: it used internally to ensure everything can be unmounted on shutdown
[07:16] <zyga> abeato: it's used on shutdown of a core system, it exists because systemd cannot by itself untagle the mount situation
[07:17] <mvo> zyga: snap :)
[07:17] <zyga> :D
[07:17] <abeato> zyga, hmm, so it is called by the shutdown/reboot command?
[07:18] <zyga> abeato: not really, it is called by systemd from initrd on shutdown
[07:18] <zyga> abeato: why?
[07:19] <abeato> zyga, I need to do some changes to how we reboot on core/kernel updates. I need to add an argumento to the reboot syscall so nex reboot goes to the recovery partition
[07:19] <abeato> so I¡m trying to understand how the reboot process works
[07:20] <zyga> abeato: aha
[07:20] <abeato> zyga, for instance "reboot -f recovery" does the desired thing, but "shutdown +10 recovery" does not
[07:20] <zyga> abeato: well, I think this is useful
[07:21] <zyga> abeato: well the reboot command above is special as "recovery" is not a term normally parsed
[07:22] <abeato> zyga, it is passed directly to the kernel: https://linux.die.net/man/2/reboot
[07:22] <zyga> abeato: but the good thing is that you can patch system-shutdown to reboot the way you need
[07:22] <abeato> zyga, yep, seems like a feasible hack
[07:22] <zyga> abeato: I know the man page, 'recovery' is not there
[07:22] <zyga> abeato: my point is that the command you quoted is custom
[07:22] <abeato> zyga, that is why I say it goes straight to the kernek
[07:23] <zyga> abeato: right
[07:23] <abeato> yep
[07:23] <zyga> abeato: so if you can express the desired reboot semantics via the system call you can do what you want
[07:23] <zyga> abeato: but note that you cannot pass any argument to system-shutdown
[07:25] <abeato> zyga, so how does it worl when I run "reboot"? first systemd, then initrd is mounted again and then system-shutdown is called? don't really know the details
[07:27] <zyga> abeato: I don't know for certain (read systemd code to know); I believe what happens is that when a special systemd unit is present (we make one) systemd ensures that shutdown is terminated from initrd using this executable
[07:28] <abeato> zyga, ok, I will pull the thread from there, thanks!
[07:29] <zyga> quote of the day for me:
[07:29] <zyga> from LWN
[07:29] <zyga> "and thus Torvalds is not sure if it a mount point can be tested if it is a bind mount or not"
[07:29] <zyga> jdstrand: ^^ :DD
[07:29]  * zyga has +1000 karma
[07:32] <abeato> zyga, the call to shutdown when there is a core/kernel update happens in daemon.go:Start(), is that right?
[07:34] <pedronis> abeato: atm yes
[07:34] <abeato> ok
[07:35] <pedronis> I mean, the code is there, it doesn't happen there, that code is setting a callback
[07:36] <abeato> pedronis, yes yes :)
[07:37] <icey> how hard would it be to have snaps installable as a non-root user, ie: a I could install a snap (without sudo) for myself?
[07:45] <zyga> icey: for yourself, not planned
[07:45] <zyga> icey: without sudo, just "sudo snap login" once ;)
[07:45] <zyga> icey: but the per-user install case is not anywhere on the roadmap
[07:45] <icey> zyga: I mean that I wish I could fo per-user snaps :-P
[07:45] <pedronis> it would be fairly involved
[07:45] <icey> even into something like $HOME/snap
[07:45] <icey> would be awesome :)
[07:46] <icey> add additional user level restrictions on top of the snap security model
[07:46] <zyga> icey: I agree with pedronis, it's not anything trivial
[07:46] <zyga> icey: on many many levels
[07:46] <pedronis> mvo: hi,  did you see my question in snapd#2592 ... do we need to skip creating /snap/foo links for those ?
[07:46] <mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
[07:47] <icey> I get that it's not trivial, but it would be *awesome*
[07:47] <icey> so, wishlist ;)
[07:47] <pedronis> pstolowski: hi, you haven't created that topic in the forum yet about interface hooks , right?
[07:47] <zyga> icey: well, it needs to fit design; right now it's not part of the design, even as a whislist item
[07:48] <zyga> icey: I would recommend to open a forum thread to describe it
[07:48] <zyga> icey: how you envision it might work, including services, confinement and what not
[07:48] <pstolowski> pedronis, that's right but I didn't forget about it, I'll do today
[07:48] <icey> zyga: I'll do some thinking about it and post something, I don't really think it'd work with services unless systemd supports per-user services
[07:49] <icey> rather, services owned by a specific user
[07:49] <zyga> icey: it does but it doesn't mean something can run as that user
[07:49] <zyga> icey: e.g. an "apache" snap
[07:49] <zyga> icey: it's a different beast entirely
[07:50] <icey> zyga: right, services would be tough to model, which is why I want to think about it some more; I'm considering more from a tool perspective
[07:50] <zyga> icey: and there's ongoing for for user services but only as a part for "regular" snaps
[07:50] <zyga> icey: for tools it might be doable, just not sure why interesting
[07:50] <icey> zyga: consider a user downloading something like nginx, and running it (on no priv port) as their own user
[07:50] <icey> could be nice to use a snap instead of just running `nginx -{}`
[07:51] <zyga> icey: it feels like a rat's nest of issues
[07:51] <icey> zyga: there are a lot of wishlist snaps that are just tools, inkscape, picasa, etc
[07:51] <zyga> icey: would all snaps work well this way?
[07:51] <zyga> icey: do you want them to run as yoursel?
[07:51] <icey> and it would be very interesting to be to be able to install those without root
[07:51] <zyga> icey: you *can* install *anything* without root
[07:51] <zyga> icey: if you sudo snap login first
[07:51] <zyga> icey: that tells us you managed to be root once
[07:52] <zyga> icey: is the no-root thing some special requirement?
[07:52] <zyga> icey: e.g. on a machine you don't have root on otherwise?
[07:52] <icey> there's a snap that managed to break apt a bit ago, no idea if it still does since I have removed it, but it would have been unable to if instaleld without root ;-)
[07:53] <zyga> icey: that was classic-confinement snap
[07:53] <icey> the `snap install $SNAPNAME` for that snap messed around with the global system in unfortunate ways
[07:53] <zyga> icey: so it can do anything
[07:53] <icey> zyga: now imagine if it didn't have root on install ;)
[07:53] <zyga> icey: and that snap would not work at all then
[07:53] <zyga> icey: "--classic"
[07:53] <pedronis> well that snap managed to break because it needed lots of privileges in the first place
[07:53] <zyga> icey: you want impossible things
[07:53] <pedronis> it would not have worked anyway
[07:53] <pedronis> and it was bad that it made a mess of apt
[07:54] <icey> pedronis: I'm curious about that, I kind of want to isntall it into a virtualenv and see if it still works ;-)
[07:54] <icey> pedronis: yeah, made me sad because I like that tool, haven't had it on my computer since then
[07:54] <zyga> icey: virtualenv? what has that to do with anything?
[07:54] <icey> fortunately, I haven't needed it
[07:54] <icey> the tool is written in python
[07:54] <zyga> icey: anything that installs with --classic is just like a typical deb/rpm, it has full access to everything on the system
[07:54] <icey> so I want to actually try using it from source, to see what these functions it "needs" are :)
[07:54] <icey> agree zyga
[07:57] <zyga> icey: I really encourage you to think about how it should work, it might be possible to create a per-user install of certain kinds of snaps (pure apps, no services), but there are lots of quirks to figure out first
[07:57] <zyga> icey: a forum thread is a way to explore that
[07:57] <icey> zyga: certainly, I bet that classic snaps could work too, but services would be really hard (and probably not worth it?)
[07:57] <zyga> icey: maybe with the session snapd deamon it might be doable but still many hard things there
[07:58] <zyga> icey: (e.g. imagine encrypted $HOME)
[07:58] <icey> zyga: yeah, it'd have to be something that was entirely after $USER was logged in fully, I think that services for a user level snap would be not worth it
[07:58] <icey> but being able to `snap install inkscape` without having root would be cool :)
[07:59] <mvo> pedronis: checking that question now
[08:01] <mvo> pedronis: is the question if wrappers.IsService need to take into account if its a dbus activatable service?
[08:03] <pedronis> mvo: yes, which means though that we would not create /snap/svc for those
[08:05] <mvo> pedronis: no /snap/bin/svc ? not doing those is actually desirable
[08:05] <pedronis> yes
[08:05] <pedronis> sorry
[08:05] <pedronis> no /snap/bin/svc
[08:06] <mvo> pedronis: slightly interessting how to organize the code so that we know in wrappers.IsService() if it is a dbus activated service
[08:07] <Chipaca> icey: well, you only need root once
[08:07] <Chipaca> (good morning peeps!)
[08:07] <Chipaca> icey: 'sudo snap login', and then you don't need sudo to snap install stuff
[08:07] <icey> Chipaca: but snaps installed thereafter would have root access during install yeah?
[08:07] <Chipaca> yep
[08:08] <icey> Chipaca: my wish would be to have non-root snaps as well
[08:08] <mvo> hey Chipaca, good morning
[08:08] <Chipaca> icey: ah
[08:08] <Chipaca> icey: to the forum! :-)
[08:08] <icey> Chipaca: I'll thinkabout it and put something on the forum once I've thought it through a bit more :)
[08:08] <Chipaca> mvo: how's things?
[08:08] <Chipaca> icey: fair
[08:08] <mvo> Chipaca: good, thank you. how are you?
[08:08] <Chipaca> mvo: not bad
[08:08] <Chipaca> i opened my big mouth and promised a patch for go, it seems :-) but that's not necessarily *bad*
[08:09] <Chipaca> (in https://github.com/golang/go/issues/19546)
[08:10] <mvo> Chipaca: \o/
[08:12] <Chipaca> I hadn't noticed IsService
[08:12] <Chipaca> why is it not a method of AppInfo?
[08:13] <mvo> Chipaca: a good question. it is pretty recent
[08:14] <mvo> Chipaca: so yeah, we should have a look at moving it
[08:14] <Chipaca> I can do it as part of this service and wrappers shuffle i'm doing
[08:14] <Chipaca> in fact I can piggy back it into snapd#3342; nobody's reviewed that yet :-)
[08:14] <mup> PR snapd#3342: many: refactor in preparation for 'snap start' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342>
[08:16] <pedronis> Chipaca: because it's not clear snap should have opinions on that, indeed with dbus service the logic gets quite complicated for being in snap
[08:17] <Chipaca> pedronis: how so?
[08:17] <pedronis> Chipaca: have you looked at the dbus activation branch?
[08:17] <pedronis> anyway
[08:17] <mvo> pedronis: yeah, I'm actually not super happy about the complexity we have there currently already
[08:18] <Chipaca> pedronis: snapd#2592?
[08:18] <mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
[08:18] <pedronis> Chipaca: also Services would need to be something else, because now we have services that are not dbus services
[08:18] <pedronis> I mean your new method
[08:18] <mvo> pedronis: and I much agree about snaps opinion about dbus etc
[08:18]  * mvo scratches head
[08:18] <pedronis> Chipaca: you should probably look at it
[08:19] <Chipaca> so, if we need to call them daemons instead of services, fine
[08:19] <pedronis> because it has influence at on names of stuff and where wrappers.IsService should go
[08:19] <pedronis> Chipaca: unrelatedly,  a 2nd review for snapd#3322 would be appreciated :)
[08:19] <mup> PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
[08:19] <Chipaca> but so far "services" are things that systemd starts
[08:20] <pedronis> Chipaca: now we have dbus activated "services", like classic classic classic
[08:20] <Chipaca> as you see from {Add,Remove,Start,Stop}SnapServices
[08:20] <Chipaca> and start-snap-services
[08:20] <Chipaca> etc
[08:21] <pedronis> Chipaca: I'm happy not to care, and let you and mvo figure it out ;)
[08:22] <mvo> Chipaca: what pedronis said is true, there is the potential to have dbus services (user session) now and systemd unit that are dbus activated (soon)
[08:22] <mvo> pedronis: hehe
[08:23] <mvo> Chipaca: but maybe for your branch yu can mostly ignore it, the only thing I will need is some way to figure out that its a dbus service so that I don't write a /snap/bin/foo-dbus-activated file that is useless to the user
[08:23] <Chipaca> mvo: as things stand there's a lot of places where we use "service" to mean something that has a systemd unit
[08:23] <mvo> Chipaca: indeed, so maybe a new term? dubsActivated or somesuch
[08:24] <Chipaca> having a systemd unit that is dbus-activated instead of socket-activated or type=notify is just a variant, it's the same thing
[08:24] <Chipaca> but having a service that does not have a unit associated would be strange
[08:24] <mvo> Chipaca: right, the user session will not have a unit
[08:24] <Chipaca> we *could* split it int SystemdService and DbusService
[08:24] <Chipaca> OTOH... are you sure the user session will not have a unit?
[08:24] <mvo> Chipaca: I mean, we could implement it via systemd but 16.04 has no systemd user session so things will fall apart there
[08:25] <Chipaca> i mean, do we support user services on things that don't use systemd for the user session?
[08:25] <mvo> Chipaca: dbus activation works fine without systemd user sessions, its an older concept
[08:25] <Chipaca> i know
[08:25] <Chipaca> upstart alos works fine
[08:25] <Chipaca> the question is whether we want to support it :-)
[08:26] <mvo> Chipaca: heh :) fair enough. if we don't we exclude 14.04 and 16.04 and possilbly 16.10 (have not checked this one)
[08:27] <mvo> Chipaca: or maybe we need to spawn our own systemd user session with snapd
[08:27] <mvo> Chipaca: no idea if that is feasible but if it is it might be nice way out
[08:27] <Chipaca> mvo: anyway, backpedaling from the "do we want to do this" question, _if_ we do this, we should split service in two
[08:27]  * mvo nods
[08:27] <Chipaca> or call them daemons vs servcies
[08:27] <Chipaca> or daemons and sprites, and confuse everybody
[08:27]  * Chipaca grins evily
[08:28] <mvo> Chipaca: sounds resonable, I will look into it in a little bit
[08:29] <Chipaca> mvo: I haven't looked at your branch in detail; is there any place where you need to grab all services, both dbus and systemd?
[08:30] <Chipaca> looks like you implement a separate isDbusService, and use that
[08:31] <mvo> Chipaca: yeah, I think that will be sufficient for now
[08:31] <Chipaca> mvo: also you don't do things from start-snap-service and related tasks
[08:31] <Chipaca> afaict
[08:33] <Chipaca> so, for now, i'm leaving Services in snap, and moving IsService in there
[08:33] <Chipaca> and afaict (but tell me if i'm wrong), at most we'll be renaming them to SystemdServices/IsSystemdService, not making them more complex
[08:33] <Chipaca> (or to Daemons/IsDaemon)
[08:33] <Chipaca> (or Vegetable/IsVegetable)
[08:34] <Chipaca> (or ..)
[08:34] <pedronis> Chipaca: well, no, we need IsService to return true for the things mvo is working on, that's the matter
[08:35] <Chipaca> pedronis: those things don't have daemon set
[08:35] <pedronis> Chipaca: indeed
[08:36] <Chipaca> pedronis: and dbus-activated systemd services are services in the current sense
[08:36] <pedronis> but we don't want to create /snap/bin/foo for them
[08:36] <pedronis> at the moment IsService decides whether the thing should have a /snap/bin entry
[08:36] <Chipaca> pedronis: right, so the current code in binaries would change from IsService to IsService || IsDbusService (or whatever)
[08:36] <pedronis> (and consequently whether to support aliases)
[08:36] <Chipaca> pedronis: but what I'm wanting is to drop all the _other_ app.Daemon == ""
[08:36] <pedronis> Chipaca: there are usages in snapstate too
[08:37] <Chipaca> in aliasesv2
[08:37] <Chipaca> yup
[08:37] <pedronis> yes
[08:37] <pedronis> it would be saner if they didn't all have to call two helpers
[08:37] <pedronis> but that's my 2cts
[08:38] <mvo> we could add wrappers.IsBinary maybe?
[08:38] <Chipaca> pedronis: so maybe as part of the dbus branch we IsService -> IsSystemdService, have IsDbusService, and have IsService that ||s the two
[08:38] <pedronis> mvo: yea, maybe that
[08:38] <Chipaca> mvo: that would be confusing, at least to me, because I'd expect IsBinary to be !IsService, always
[08:39] <Chipaca> bah
[08:39] <Chipaca> hmm
[08:39] <pedronis> Chipaca: it would be
[08:39] <pedronis> if I understand things
[08:39] <Chipaca> pedronis: if IsService is the || above, yes
[08:40] <Chipaca> mvo: why would it be wrappers.IsBinary and not snap.(*AppInfo).IsBinary?
[08:41] <pedronis> because the logic for IsDbusService is complicated
[08:41] <morphis> rharper: ping
[08:41] <pedronis> and about policies that are 5 layers away from the basics of snaps
[08:42] <pedronis> but you can read it both ways
[08:42] <mvo> Chipaca: yeah, what pedronis said, probably in wrapper as its complex(ish)
[08:42] <pedronis> I mean the issue is mostly not to have that logic in many places
[08:42] <mvo> +1 on that
[08:43] <Chipaca> agreed that that's #1
[08:43] <pedronis> Chipaca: completion timeout that doesn't seem related to create-key: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170518_083559_ce30f@/log.gz
[08:43] <Chipaca> OTOH that you can't tell whether an app is a dbus service from looking at the app, to me is a red flag
[08:44] <Chipaca> or at least a bright yellow flag :-)
[08:44] <Chipaca> pedronis: not only, no
[08:44] <Chipaca> waaait
[08:45] <Chipaca> that's a different completion
[08:45] <mvo> Chipaca: we could make it more explicit. right now its entirely based on the dbus slot, however we could add something explicit to the app yaml part
[08:45] <mvo> Chipaca: 2592 has an example of the current syntax, maybe we move the "service: true" part up to the app level (and rename it to something sensible or fold it into daemon:)
[08:47] <Chipaca> pedronis: that timeout makes no sense :-(
[08:47] <abeato> zyga, hey, I think you are the only one missing in https://github.com/snapcore/snapd/pull/3324 :)
[08:47] <mup> PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324>
[08:48] <Chipaca> mvo: what would one on the system dbus look like?
[08:49] <Chipaca> mvo: does it running on the system dbus mean it runs as root?
[08:49] <mvo> Chipaca: that is not decided yet, probably exactly the same excep tthat bus: session becomes bus: system
[08:49] <mvo> Chipaca: correct
[08:50] <Chipaca> mvo: how is a dbus-activated system dbus service different from a bus-activated systemd service
[08:51] <Chipaca> the manpage points me to /usr/share/dbus-1/system-services/org.example.simple-dbus-service.service which doesn't exist. Hrmph.
[08:51] <mvo> Chipaca: I have not looked into the details for the system dbus services, but I expect that we want to do the systemd unit route here
[08:52] <mvo> Chipaca: i.e. there may be very little for us to do
[08:52] <Chipaca> so they'd be quite different in that case?
[08:52] <Chipaca> or would it still need a plug and etc?
[08:52] <mvo> Chipaca: the user session was the most interessitng one to me as there are some gnome apps that use this mechanism and we can not support them ucrrently
[08:53] <mvo> Chipaca: AIUI there is still a plug needed to ensure appamor allows all the dbus things that the dbus activated service wants to do
[08:53] <mvo> (but take it with a grain of salt, I have not looked into the details for dbus in system services)
[08:53] <ackk> hi, how do I remove a snap that's marked as broken,disabled?
[08:55] <Chipaca> ackk: snap remove snapname?
[08:55] <Chipaca> ackk: (how did it get into that state?)
[08:55] <ackk> Chipaca, I had installed locally 2 versions of a snap, when I tried to sudo snap remove <snap> it hang for several minutes removing one of the versions
[08:56] <ackk> Chipaca, I C-c'd it and after that it was broken
[08:56] <ackk> Chipaca, fwiw it's a snap installed in an LXD container
[08:56] <Chipaca> zyga: you want to look at this?
[08:57] <ackk> Chipaca, uhm, it seems it eventually deleted itself, I don't see it anymore now :/
[08:58] <Chipaca> ackk: 'snap changes
[08:58] <Chipaca> agh
[08:58] <Chipaca> ackk: 'snap changes' should be able to shed light on things
[08:58] <ackk> Chipaca, I see a series of "install" and a "remove" at the end
[08:59] <Chipaca> ackk: snap tasks <the number with the remove>
[08:59] <ackk>  
[08:59] <ackk> 2017-05-18T08:47:55Z ERROR cannot remove snap file "basic-auth-service", will retry in 3 mins: umount: /snap/basic-auth-service/x1: not mounted
[08:59] <ackk> 2017-05-18T08:50:55Z ERROR cannot remove snap file "basic-auth-service", will retry in 3 mins: umount: /snap/basic-auth-service/x1: not mounted
[08:59] <ackk> Chipaca, ^^
[09:01] <Chipaca> ackk: where's that from? (and what did 'snap tasks' say?)
[09:01] <mvo> pedronis: I updated the repair capability with a new "running repairs" proposal based on the ideas from gustavo. feedback welcome
[09:02] <Chipaca> ackk: ('snap tasks' used to be 'snap change', if your snapd is slightly old try that instead)
[09:04] <pstolowski> zyga, hey, any objections to expose rm_rf_tmp from ns-supoort-tests to utils-test or similiar? I need to cleanup tmp stuff in my new test
[09:04] <pstolowski> s/expose/expose and move/
[09:04] <pedronis> mvo: I'm not quite sure why we need --probe ?
[09:04] <pedronis> that wasn't part of Gustavo proposals
[09:06] <pedronis> mvo: also is not clear, but we still need the the latest good in snapd/gadget, otherwise we will download all assertions since forever
[09:06] <mvo> pedronis: thats fine, I can change it. it felt slightly cleaner to make it explicit but I guess its an unneeded extra step
[09:06] <pedronis> mvo: well it begs questions about the state after the real run
[09:07] <mvo> pedronis: ok, let me update it
[09:07] <pedronis> for when it's unknown
[09:08] <pedronis> basically bigger state machine
[09:21] <mvo> pedronis: updated it yet again
[09:24] <pedronis> mvo: fixed the when repair section
[09:26] <pedronis> mvo: I think with this approach the every 4h  seems reasonable, later we could have some approach that do it as well if snapd is down since a while
[09:29] <mvo> pedronis: great
[09:33] <zyga> pstolowski: no, go ahead
[09:33] <zyga> Chipaca: yes, gladly
[09:34]  * zyga is back, sorry, some unexpected stuff at home
[09:34] <zyga> ackk: ah, LXD
[09:34] <zyga> ok, I might as well explore LXD, this would fit nicely in my mount namespace layout tests
[09:34] <zyga> abeato: looking
[09:34]  * zyga refrains from reading the rest of the backlog
[09:36] <ackk> Chipaca, it's from snap tasks
[09:40] <Chipaca> ackk: could you pastebin the whole output of the relevant 'snap tasks'?
[09:40] <ackk> Chipaca, http://paste.ubuntu.com/24597955/
[09:41] <ackk> Chipaca, fwiw it was eventually removed correctly
[09:41] <pstolowski> pedronis, https://forum.snapcraft.io/t/interface-hooks-attributes/673
[09:41] <zyga> abeato: some things are still not documented (golint)
[09:41] <zyga> a bit nitpick but I think it's relatively easy to do
[09:42] <abeato> zyga, I tried golint, but I got no output
[09:42] <zyga> abeato: in that directory?
[09:42] <abeato> zyga, yes
[09:43] <abeato> $ golint *.go
[09:43] <abeato> androidbootenv_test.go is in package androidbootenv_test, not androidbootenv
[09:43] <abeato> zyga, this is the only output I see *^^
[09:44] <pstolowski> zyga, thanks
[09:44] <zyga> abeato: commented again
[09:44] <zyga> abeato: let me look, that's still wrong :) probably
[09:45] <zyga> abeato: but check my feedback
[09:45] <abeato> zyga, sure, thanls
[09:46] <morphis> ogra_: is rsyslog already removed in edge?
[09:46] <mvo> morphis: yes
[09:47] <morphis> mvo: hm, so is the journal sync'ed to disk?
[09:47] <pedronis> pstolowski: thanks, it seems to capture the discussion points, I added a comment there
[09:48] <pstolowski> pedronis, yes, saw it, thanks
[09:49] <zyga> woohoo
[09:49] <zyga> I see core edge :)
[09:50]  * zyga sees the content interface changes work :D
[09:50] <zyga> I'd say woot but that's be self serving
[09:50] <zyga> still
[09:50] <zyga> very happy :)
[09:55] <mvo> morphis: aiui it is not
[09:55] <mvo> morphis: it is only if the /var/log/journal dir exists or something
[09:55] <morphis> hm
[09:56] <mvo> zyga: what content interface chagne is that?
[09:58] <abeato> zyga, answering your comment, I do not care about deterministic order
[09:58] <abeato> zyga, were the test you proposing about that? If that is the case, it is not needed either
[10:01] <zyga> abeato: yes, I think we want that
[10:01] <zyga> abeato: it's almost always desirable IMO
[10:01] <abeato> zyga, not in this case
[10:02] <abeato> zyga, it is a hurdle we do not really care about
[10:04] <NicolinoCuralli> Hi guys, is it now possibile revoke a gpg key on the Store?
[10:06] <zyga> abeato: can you justify that?
[10:09] <abeato> zyga, neither the bootloader or snapd cares about the orde in which env vars are stored
[10:09] <abeato> so no reason to enorce that
[10:10] <abeato> *enfroce
[10:10] <abeato> enfroce
[10:47] <zyga> heh
[10:47] <zyga> make a file called '<' by accident
[10:47] <zyga> then remove it
[10:47] <zyga> fun :)
[10:49] <Chipaca> zyga: “rm \<” ?
[10:56] <zyga> Chipaca: yes but it took me a second to find that :)
[10:56] <zyga> Chipaca: this is both you vs shell as well as you vs program parsing it :)
[10:56] <Chipaca> zyga: the program shouldn't be doing parsing of the filename
[10:56] <Chipaca> unless it were "-foo" or something
[10:56] <ogra_> hmm
[10:56] <Chipaca> (for which "--" exists)
[10:57] <ogra_> building something for snapcore via build.snapcraft.io requires additional organization access :/
[10:57]  * ogra_ wonders why ... given my GH account already has readonly access to the branches which should be enough to build it
[11:00] <zyga> Chipaca: yep, I tried with -- but that was just my naive idea ;)
[11:05] <mup> PR snapd#3347 opened: snap-confine: moved rm_rf_tmp to test-utils <Created by stolowski> <https://github.com/snapcore/snapd/pull/3347>
[11:06] <pstolowski> zyga, ^ something for you ;)
[11:07] <cjwatson> ogra_: BSI needs admin access to the repo in order to install a webhook
[11:07] <cjwatson> I think we even explain that on the GH permission request page nowadays
[11:08]  * zyga looks
[11:09] <ogra_> cjwatson, well, the GH page itself is a bit confising ... telling me at the top that it has readonly access and requesting additional organization access at the bottom ... the snapcraft.io page is better designed but i get redirected first
[11:10] <cjwatson> there's a limit to how much we can do about that; best we can do is explain it in the bits of text we get to control
[11:10] <ogra_> yeah
[11:11] <ogra_> we should just rent out mpt to GH for a redesign ;) (for most of the UI actually IMHO)
[11:12] <pstolowski> thx zyga
[11:12] <cjwatson> ogra_: it has its good points
[11:13] <ogra_> some. yeah ...
[11:27] <Chipaca> did somebody say lunch
[11:29] <zyga> Chipaca: DEFCON-1 LUNCH!!!!
[11:29] <Chipaca> actually a siesta might be what i need
[11:29] <Chipaca> but no! onwards!
[11:29] <Chipaca> zzmmmhyeah
[11:31] <pedronis> mvo: wrote something in the forum about the last-refresh unset question/"issue"
[11:32] <zyga> Chipaca: question, sir, how would you suggest to tweak this: http://pastebin.ubuntu.com/24598370/
[11:32] <zyga> (apart from fixing s/slots/snaps/)
[11:33] <Chipaca> zyga: “access the network as a client” reads wrong, and is fluffy and imprecise
[11:33] <zyga> fluffy is what we had in a comment so far :)
[11:33] <zyga> suggestions welcome
[11:33] <zyga> I made it possible to expose meta-data about interfaces
[11:34] <zyga> and shoved them through the pipeline to the CLI
[11:34] <Chipaca> zyga: <this interface> lets apps do <exactly these things>?
[11:34] <zyga> Chipaca: acccessing the network as a client is exactly what the doctor ordered though
[11:34] <zyga> Chipaca: I know it's techy but not sure how to make it better
[11:34] <zyga> but but
[11:34] <zyga> this is not that thing I asked about
[11:34] <Chipaca> my point is it's not techy enough :-)
[11:34] <zyga> how would you display information about an interface
[11:34] <zyga> aaah
[11:34] <Chipaca> zyga: what did you ask me about :-)
[11:34] <zyga> (not the particular wording)
[11:35] <Chipaca> ah! that seems fine
[11:35] <zyga> I just print the description if you ask via -i ifacename
[11:35] <Chipaca> i assume you're using wrap() there?
[11:35] <zyga> oh, no
[11:35] <zyga> nice! let me look
[11:35] <Chipaca> maybe use wrap then
[11:35] <zyga> the patch is not long,  I'll post it in a moment
[11:35] <Chipaca> wait was it wrap()
[11:35]  * Chipaca digs
[11:35] <Chipaca> zyga: fill()
[11:36] <Chipaca> might need tweaking as it's only for errors right now (so it assumes an indent)
[11:36] <mup> PR snapd#3348 opened: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
[11:37] <zyga> Chipaca: hmm, wonky
[11:37] <Chipaca> oh?
[11:37] <Chipaca> zyga: how so?
[11:39] <zyga> http://pastebin.ubuntu.com/24598396/
[11:39] <zyga> Chipaca: (offtopic) bash completion for http would be lovely ;)
[11:40] <Chipaca> zyga: main problem there is the indent, which i warned you about :-)
[11:40] <zyga> Chipaca: how do I make http talk to snapd again?
[11:40] <Chipaca> http snapd:///v2/system-info
[11:40] <zyga> snapd:// is a thing?!
[11:40] <zyga> wow
[11:40] <Chipaca> it is in the snap :-D
[11:40] <zyga> I tried unix://
[11:45] <zyga> Chipaca: ok, a bit better now
[11:47] <Chipaca> zyga: http://pastebin.ubuntu.com/24598417/
[11:48] <Chipaca> en nu, lunch
[11:49] <zyga> Chipaca: I did something like that
[11:58] <Chipaca> zyga: note you can kill filledError; it slipped in by accident (was going to use it, didn't in the end)
[12:00] <zyga> Chipaca: yep, I killed it
[12:00]  * Chipaca goes back to his leftovers
[12:01] <mup> PR snapd#3235 closed: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3235>
[12:01] <pstolowski> yay :)
[12:02] <pstolowski> thanks pedronis!
[12:02] <zyga> pstolowski: all red on the rm-rf test move
[12:03] <ogra_> morphis, oops, sorry, missed your ping ... yes, rsyslog is gone for good in edge so we get potential feedback before next release
[12:03] <morphis> ogra_: actually what I missed today was that I was booting an image in kvm which failed and I didn't got access, then stopped kvm, mounted the image and missed the syslog for inspection
[12:03] <ogra_> morphis, if you want a persistent journal you can create /var/log/journal, journald will drop its blobs in there then and they persist across reboots
[12:04] <ogra_> morphis, hmm, we should probably allow a cmdline option that creates that dir from the initrd for debug purposes
[12:05] <ogra_> (not sure how else we could do it)
[12:05] <morphis> ogra_: yes, that would be nice
[12:05] <pstolowski> zyga, seems to be about formatting.. looking
[12:05] <zyga> pstolowski: make fmt
[12:05] <ogra_> would you comment on the forum thread ? i'd like to get gustavos input on it before starting to hack on anything
[12:05] <zyga> pstolowski: feel free to force push this, I hate things like that breaking bisect
[12:06] <zyga> Chipaca: how did you get around that terminal width issue in testing?
[12:07] <Chipaca> zyga: regular expressions
[12:08] <Chipaca> zyga:  MATCH -z "${expected// /[[:space:]]+}"
[12:10] <zyga> Chipaca: ah, I used unit tests
[12:10] <zyga> wanna see?
[12:10] <Chipaca> zyga: even easier then :-)
[12:10] <zyga> Chipaca: look at zyga/feature/iface-metadata please
[12:13] <pstolowski> zyga, ok, pushed
[12:13]  * zyga loves how this works 
[12:18] <Chipaca> zyga: looks good; the level of nits i have are probably not worth it =)
[12:19] <Chipaca> zyga: there's a bug there though
[12:19] <zyga> yes?
[12:19] <Chipaca> zyga: probably because it's doing something unGo-ly
[12:19] <Chipaca> zyga: it does `ifaces, err := Client().Interfaces()`
[12:19] <Chipaca> zyga: and then a super long block of `if err == nil`
[12:20] <Chipaca> zyga: and then outside of that block, it uses ifaces
[12:20] <zyga> Chipaca: aha, let me look
[12:20] <zyga> ah, in cmd_interfaces.go
[12:20] <zyga> thanks
[12:20] <Chipaca> suggest switching that to a `err != nil`, exiting early, and so on
[12:21] <zyga> Chipaca: diff would be longer
[12:21] <zyga> I'll change that but separately
[12:21] <Chipaca> zyga: code would be better
[12:22] <zyga> Chipaca: fair enough
[12:22] <zyga> I wrote it like that for 100% coverage (I was cheating)
[12:23] <zyga> Chipaca: fetch again
[12:24] <zyga> or maybe just look here: https://github.com/snapcore/snapd/pull/3349
[12:24] <mup> PR snapd#3349: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
[12:24] <mup> PR snapd#3349 opened: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
[12:24] <Chipaca> tput reset; GOPATH=~/canonical/snappy goctest -coverprofile .coverage/profile.out -v github.com/snapcore/snapd/cmd/snap && GOPATH=~/canonical/snappy go tool cover -html=.coverage/profile.out
[12:25] <Chipaca> oops, wrong paste :-)
[12:25] <Chipaca> zyga: you didn't get 100% anyway :-D
[12:25] <zyga> Chipaca: it used to be 100%
[12:26] <zyga> I just reall why it was written this way before
[12:26] <zyga> I think this will be a welcome feature
[12:26] <zyga> I'd like to document interfaces on the forum
[12:26] <zyga> and add a forum URL to meta-data :)
[12:27] <Chipaca> zyga: i thought the github wiki was the place for docs
[12:27] <Chipaca> zyga: 91.7% coverage as it stands now
[12:27] <Chipaca> zyga: 93.6% before
[12:28] <Chipaca> zyga: when you say 'add a forum URL to meta-data' you mean structuredly?
[12:28] <Chipaca> also: http://imgur.com/a/IeRjS
[12:29] <pedronis> Chipaca: I think docs now go to the forum doc category
[12:30] <pedronis> Gustavo was planning to move over bits from the wiki and then close it
[12:30] <niemeyer> Yeah, this is gradually happening already
[12:30] <niemeyer> (good morning)
[12:30] <niemeyer> A handful of documents have been moved
[12:31] <Chipaca> zyga: I stand corrected :-)
[12:31] <niemeyer> https://forum.snapcraft.io/c/doc
[12:32] <Chipaca> well, 'stand' is a manner of speaking
[12:33] <zyga> Chipaca: yes
[12:33] <zyga> niemeyer: oh, nice
[12:34] <niemeyer> We just need to be careful to not overload the forum with mechanical posts
[12:34] <niemeyer> That's part of the reason why I'm not just taking things and moving over
[12:36] <ogra_> woah ... popey ! 2.2k views for your wishlist post
[12:37] <Chipaca> ogra_: it's been busy :-)
[12:37] <ogra_> yeah
[12:37]  * Chipaca 's finger hovers over [Spam]
[12:37] <ogra_> heh
[12:37] <Chipaca> but then i posted there, so shouldn't complain :-D
[12:38] <zyga> Send-pings-after-midnight
[12:38] <Chipaca> zyga: i think that PR will fail static check btw
[12:38]  * zyga tries
[12:39] <Chipaca> zyga: if you hurry you might beat travis :-D
[12:40] <zyga> ah damn simplify rulels
[12:40] <zyga> rules*
[12:40] <zyga> I need to teach vim to do that
[12:40] <Chipaca> or your eyes :-p
[12:42] <zyga> Chipaca: yes, I wrote that after all :")
[12:43] <Chipaca> zyga: here, try these: 8
[12:43] <zyga> offtopic, today I installed a webcam in a T530 (not mine)
[12:43] <zyga> I must say, damn, thinkpads are fantastic :)
[12:44] <zyga> tooking the LCD bezel apart was trivial, I found official docs online, the panel had the connector cable installed already, all with proper tape to ensure it is held in place
[12:44] <zyga> the connector was keyed so it was easy to get it right
[12:44] <zyga> and the whole procedure took 10 minutes including the part where the machine was turned off and disconnected from battery
[12:45] <zyga> I thought we'd 1) fail 2) take long time 3) buy more parts 4) succeed next time, maybe
[12:45] <zyga> super happy with the result :)
[12:46] <Chipaca> i guess i've been spoiled by my e-series latitude
[12:46] <zyga> is that a dell?
[12:46] <Chipaca> yeap
[12:46] <zyga> on the other hand the camera-less laptop is pretty rare for me
[12:46] <Chipaca> single-screw access to all the guts
[12:46] <zyga> (feels like government stuff)
[12:47] <Chipaca> (well, not all, but the most common)
[12:47] <zyga> nice :) I took many laptops apart but I never touched the screen bezel or internals
[12:47] <zyga> and now I'm thinking of swapping a panel (on that same laptop) to a highere res one
[12:47] <Chipaca> anyway. i'm going to go get some tea, let's see if it wakes me up
[12:47] <Chipaca> otherwise some of us might be asleep at the standup
[12:47] <zyga> enjoy :)
[12:47] <Chipaca> can't have that
[12:49] <morphis> mvo, zyga: can you have a look at https://github.com/snapcore/snapd/pull/3337 again?
[12:49] <mup> PR snapd#3337: errtracker: try multiple paths to read machine-id <Created by morphis> <https://github.com/snapcore/snapd/pull/3337>
[12:49] <morphis> niemeyer: you had time to look at https://github.com/snapcore/snapd/pull/3222 already?
[12:49] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[12:50] <zyga> morphis: sure
[12:50] <morphis> zyga: thanks
[12:51] <zyga> morphis: cannot find?
[12:51] <zyga> morphis: cannot read
[12:51] <morphis> ?
[12:51] <zyga>  +logger.Noticef("cannot find %s: %s", id, err)
[12:51] <morphis> fine for me
[12:51] <zyga> morphis: fix that and LGTM
[12:52] <morphis> zyga: done
[12:52] <niemeyer> Would anyone have a plausible explanation for this:
[12:53] <niemeyer> root@worker-c:/root# ls -l /bin/mount
[12:53] <niemeyer> -rwsr-xr-x 1 root root 40152 Dec 16 15:40 /bin/mount
[12:53] <niemeyer> root@worker-c:/root# /bin/mount -h
[12:53] <niemeyer> bash: /bin/mount: Permission denied
[12:53] <zyga> morphis: thanks!
[12:53] <niemeyer> This is inside a devmode snap
[12:53] <zyga> niemeyer: one sec
[12:53] <zyga> niemeyer: I think I know why
[12:53] <zyga> niemeyer: do you have any denials?
[12:53] <niemeyer> Well, I must do
[12:54] <niemeyer> Checking
[12:54] <Chipaca> zyga: if [[ "$USER" =~ niemeyer ]]; then exit EPERM; fi
[12:54] <zyga> niemeyer: hmm, no my idea is not there
[12:54] <niemeyer> [  421.101403] audit: type=1400 audit(1495111946.792:42): apparmor="DENIED" operation="open" profile="snap.discourse.shell" name="/bin/mount" pid=1630 comm="bash" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[12:54] <zyga> niemeyer: we used to have an explicitly deny for mount
[12:54] <zyga> aha
[12:54] <zyga> iiinteresting
[12:54]  * zyga looks
[12:54] <niemeyer> Yeah, I assumed that was the case
[12:54] <niemeyer> What I don't understand is why
[12:55] <zyga> niemeyer: cna you look at the profile, is it really a complain-mode profile?
[12:55] <zyga> niemeyer: there's nothing that explains this for me so far
[12:56] <niemeyer> Nope
[12:56] <niemeyer> I think we have a bug in the profile generation
[12:56] <zyga> niemeyer: can you pastebin the head of the profile? (or the whole thing)
[12:56] <niemeyer> I've already enabled and disabled the snap, which removes the case of something being left over
[12:57] <niemeyer> https://www.irccloud.com/pastebin/R0nWdOwZ/
[12:57] <niemeyer> zyga: ^
[12:58] <niemeyer> snap list confirms it's devmode, FWIW
[12:58] <pedronis> pstolowski: do you still have a todo about CheckChangeConflict and connect/disconnect ?
[12:58] <popey> ogra_: yeah, bit sad cafe isn't surfaced on the front page
[12:59] <niemeyer> zyga: I had observed this problem yesterday, but I thought it was related to reverts.. but now I managed to reproduce it without a revert
[12:59] <zyga> niemeyer: interesting, this is *not* devmode
[12:59] <niemeyer> Right
[12:59] <zyga> niemeyer: hop into the standup
[12:59] <zyga> niemeyer: we can chat
[12:59] <niemeyer> omw
[12:59] <ogra_> popey, well, probably niemeyer can change that
[12:59] <zyga> niemeyer: snap list says it is devmode?
[13:01] <pstolowski> pedronis, I need to refresh my memory. last time I checked I couldn't really see what was wrong with it
[13:17] <pedronis> pstolowski: oh, I though you understood the problem
[13:18] <pedronis> pstolowski: Connect/Disconnect check  but CheckChangeConflict don't consider disconnect/connect tasks
[13:18] <pedronis> pstolowski: so you can run install why you are trying to Connect/Disconnect
[13:18]  * Chipaca crosses “hear mvo describe something as «gnarly»” from his bucket list
[13:19] <pstolowski> pedronis, yes, but the I looked at this method and as far as I remember it doesn't care about task type, it just looks for another task affecting same snap
[13:19] <pstolowski> s/the/then/
[13:20] <pedronis> pstolowski: ?
[13:20] <pedronis> pstolowski: there's a full map of task types
[13:21] <pedronis> the issue is that the connect/disconnect carry two snaps
[13:21] <pedronis> so there's a bit more to do
[13:21] <pstolowski> pedronis, you're right, i see
[13:21] <Saviq> ogra_, hey, I'm trying to update https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ a bit - it mentions rpi3 gpu support "not in stable yet" - I suppose this note should go away now?
[13:22] <jdstrand> zyga (cc niemeyer): fyi, we don't have any explicit denies for mount in any of the policy (we avoid explicit denies as much as possible)
[13:23] <zyga> jdstrand: it's a different bug
[13:23] <zyga> jdstrand: the profile is for strict
[13:23] <zyga> some state is mixed up
[13:23] <ogra_> Saviq, nope, it is a gadget thing and we can not update gadgets yet
[13:23] <Saviq> ogra_, ack, leaving it be, then
[13:23] <ogra_> Saviq, so we only have it in !stable channels
[13:23] <jdstrand> zyga: I know, but I didn't want the idea to propagate that we have explicit denies for mount
[13:23] <zyga> jdstrand: aha
[13:24] <zyga> jdstrand: I have a branch I'm sure you will like
[13:24] <zyga> https://github.com/snapcore/snapd/pull/3349
[13:24] <mup> PR snapd#3349: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
[13:29] <niemeyer> popey: The point of cafe was for things that are usually pretty offtopic ("look at that sun set!"), which is not what people expect when they go to forum.snapcraft.io..
[13:30] <niemeyer> popey: If you have an entry that you wish was presented in the front page, that's likely not something to be discussed on the cafeteria :)
[13:31] <zyga> mvo: could we support C coverage via codecov as well?
[13:31] <mvo> zyga: I think so, I have not looked into it
[13:31] <zyga> mvo: I'll look at that
[13:32] <jdstrand> zyga: oh that's nice. note that 'The core snap provides the slot that is shared by all the snaps' is handy, but that is defined elsewhere (implicit.go and the base declaration). this makes a third spot to keep in sync. I'm not sure how to fix that, but wanted to mention it
[13:32] <zyga> jdstrand: yes, that will go away too :)
[13:32] <zyga> jdstrand: I'll make implicit.go just ask for meta-data :)
[13:32] <zyga> jdstrand: but I didn't want to clobber it here
[13:33] <zyga> jdstrand: initially I also folded Name into meta-data but I think not doing so is just easier
[13:34] <zyga> jdstrand: I could also fold base declaration but I think you were against that
[13:34] <popey> niemeyer: I didnt expect that thread to blow up like that tbh. Thought it might be a casual conversation with 2 or 3 comments
[13:35] <niemeyer> popey: Ah, on that thread, it really doesn't feel so coffeey.. I moved it to the snap category earlier today already, so it is now in the front page
[13:35] <popey> Sweet, thanks!
[13:36] <jdstrand> zyga: I'm ok with folding the base declaration into it cause that makes a good bit of sense, but it would be handy to be able to dump the entire base declaration with a command
[13:36] <zyga> jdstrand: aha
[13:36] <zyga> jdstrand: that's doable via snap debug interface, I'll look at that as well then
[13:36] <Saviq> zyga, hey, is there a GH issue or PR we can reference about https://bugs.launchpad.net/snappy/+bug/1646333 ?
[13:36] <mup> Bug #1646333: bind mounts related to content interface plugs remain stale on snap disconnect/connect or snap updates <Snappy:New> <https://launchpad.net/bugs/1646333>
[13:36] <zyga> jdstrand: so with this interfacecs would become 100% self-contained
[13:36] <zyga> Saviq: ha
[13:36] <zyga> Saviq: use edge
[13:37] <zyga> Saviq: that's fixed now :)
[13:37] <jdstrand> zyga: really, I think defining everything within the interface file is good, since you can see everything in one place
[13:37] <zyga> jdstrand: yes, I agree, I think this will be nicer for everyone
[13:37] <Saviq> zyga, is cjson back in edge yet? ;)
[13:37] <ogra_> Saviq, yes
[13:37] <zyga> Saviq: I didn't check but I think ogra_ pushed it
[13:37] <jdstrand> zyga: what I was against is the policy being spread out over multiple file and thus making it hard to see. this is making things easy to see :)
[13:37]  * zyga nods 
[13:38] <Saviq> ogra_, zyga thanks, that's helpful
[13:38] <Son_Goku> zyga, morphis: snapd 2.26.3 and snapd-glib 1.12 are building
[13:38] <zyga> Saviq: this will be in 2.27 (mount changes)
[13:38] <ogra_> Saviq, i was actually greeted with a running kisok-app when entering my office this morning ;) thanks to auto-update
[13:38] <morphis> Son_Goku: nice!
[13:38] <Son_Goku> morphis: I had to drop the libexecdir test fixes patch because it wouldn't build
[13:38] <zyga> hey Son_Goku, sounds great :-)
[13:38] <Son_Goku> and the changes were too drastic
[13:38] <Saviq> ogra_, :)
[13:38] <morphis> Son_Goku: a simple rebase didn't work?
[13:38] <Son_Goku> Nope
[13:38] <Son_Goku> there were way too many changes
[13:38] <Son_Goku> anyway, tests are still not enabled in the Fedora packages anyway
[13:39] <morphis> right
[13:39] <Son_Goku> that thing needs to be merged for 2.27
[13:39] <morphis> need to follow up with the various bugs I filed to get packages updated and AFAIK you still need to review one :-)
[13:42] <zyga> fgimenez: can you tell me more about that test that you just mentioned?
[13:43] <fgimenez> zyga: of course thanks, let me push the last changes https://github.com/snapcore/snapd/pull/3348
[13:43] <mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
[13:43] <zyga> fgimenez: thank you
[13:51] <fgimenez> zyga: last changes pushed
[13:51] <zyga> fgimenez: looking
[13:52] <fgimenez> thank you zyga
[13:55] <fgimenez> zyga: you can execute it with "spread -v qemu:ubuntu-16.04-64:tests/nested/core-revert"
[13:55] <mup> PR snapcraft#1322 closed: state: ignore the 'any' architecture in the build packages apt cache <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1322>
[13:55] <fgimenez> zyga: anyway i'm not sure if just installing network-manager is enough for surfacing the problem, maybe it should be configured somehow?
[13:57] <Son_Goku> zyga, morphis: https://bodhi.fedoraproject.org/updates/FEDORA-2017-74f7c7df46 (F26), https://bodhi.fedoraproject.org/updates/FEDORA-2017-2e4459fa03 (F25), https://bodhi.fedoraproject.org/updates/FEDORA-2017-866e9643a8 (F24)
[13:57] <morphis> Son_Goku: can you add those to the forum thread?
[13:57] <Son_Goku> I don't know which one to add it to, and I have to go to work
[13:58] <rharper> morphis: here
[14:00] <zyga> fgimenez: let me show you what CE did
[14:03] <pedronis> zyga: jdstrand: notice that there was still the open idea to let the base declaration be updateable from the store
[14:03] <pedronis> splitting it might make understanding that flow harder, don't know
[14:06] <zyga> Chipaca: we found the issue
[14:06] <zyga> pedronis: aha
[14:06] <Chipaca> zyga: is it potatoes
[14:06] <zyga> pedronis: I thought that was ony about the snap declaration, not the base declaration
[14:06] <zyga> Chipaca: it's snap list,
[14:06] <zyga> Chipaca: snap is not in devmode in state
[14:06] <zyga> Chipaca: but notesFromLocal has some logic that is probably stale
[14:06] <Chipaca> that's a relief (in that at least that bug i got)
[14:06] <zyga> Chipaca: I'm going to look at that now
[14:06] <Chipaca> ok
[14:16]  * zyga actually should eat lunch first
[14:17] <zyga> niemeyer: the kernel change is one thing, the snapd change is another thing
[14:17] <zyga> niemeyer: when we change core, that core's snapd needs to do the setup
[14:17] <zyga> niemeyer: (like 2-phase setup really)
[14:18] <zyga> niemeyer: maybe we should re-exec into new core snapd even on core systems
[14:18] <zyga> niemeyer: then shutdown will need to care after the kernel part of the problem only
[14:19] <pedronis> zyga: we wait for reboot on core systems before doing the 2nd phase
[14:19] <zyga> pedronis: reboot yes but I mean we should restart and reexec snapd on core as well
[14:19] <zyga> pedronis: I don't think we do that
[14:19] <pedronis> zyga: ?
[14:19] <pedronis> we don't finish the install
[14:19] <zyga> pedronis: (so that the incoming snapd gets to finish profile generation before boot)
[14:19] <pedronis> until we are after reboot
[14:19] <zyga> pedronis: yes, and that is also part of the problem
[14:19] <pedronis> one of the thing we planned to change is not too wait for the reboot long
[14:19] <zyga> pedronis: don't get me wrong, just one of many options
[14:20] <zyga> pedronis: the bug is that on boot the profiles are stale
[14:20] <zyga> pedronis: and they can be stale because kernel or core changed (or maybe gadget too, I didn't think about it)
[14:20] <zyga> pedronis: gustavo suggested to update profiles on shutdown, this would allow us to do kernel changes correctly
[14:20] <zyga> pedronis: but core changes cannot be handled this way
[14:21] <zyga> I also wonder what this means for attribute hooks
[14:21] <pedronis> well we cannot restart snapd
[14:21] <pedronis> because core is the full root
[14:21] <pedronis> isn't unclear things would work in all casses
[14:21] <zyga> pedronis: aha
[14:22] <zyga> pedronis: well, we could make it work
[14:22] <zyga> but I think the general case needs to be investigated more
[14:23] <Chipaca> ok, i'm off to a parents' evening (a.k.a. teachers' nightmare). Bbl...
[14:23] <zyga> Chipaca: will there be tapas?
[14:23] <zyga> Chipaca: enjoy :)
[14:24] <Chipaca> I don't think there'll be anything to eat
[14:24] <Chipaca> but i could be wrong
[14:24] <Chipaca> but i won't eat it anyway
[14:24] <Chipaca> because, waste time
[14:24] <pedronis> zyga: anyway moving starting snapd as early as possible on the core would also solve the problem, no?
[14:25] <pedronis> I early in the boot sequence
[14:26] <zyga> pedronis: yes
[14:26] <zyga> pedronis: though it is unclear what happens if, say, snapd fails and things go south
[14:26] <zyga> pedronis: or how long will that slow down the boot sequence
[14:27] <pedronis> well on a core device
[14:27] <pedronis> all interesting things will be snap
[14:27] <pedronis> so they need those profiles
[14:27] <zyga> pedronis: also we probably want to say "hey snapd, start but hold it there for most activities as, you know, we're still booting"
[14:27] <zyga> pedronis: then say "ok, GO" later
[14:28] <zyga> could be pretty nice actually
[14:28] <zyga> snapd could hold a mode (in memory only)
[14:28] <zyga> booting, running, shutting-down (or something)
[14:28] <zyga> and could react to requests
[14:28] <zyga> and alter ensure as appropriate
[14:28] <pedronis> maybe, we don't a lot at all
[14:28] <pedronis> there
[14:29] <pedronis> under normal circumstances
[14:29] <pedronis> profile rewriting is probably the biggest bit
[14:29] <pedronis> but also the one we want
[14:29] <zyga> I'd like to avoid things like bootup, super early, just out of initrd and we run refresh or what not
[14:29] <zyga> yes, I agree
[14:29] <pedronis> well refresh is scheduled
[14:30] <zyga> yes, but it will run if we're unlucky
[14:30] <pedronis> we can do things about that
[14:30] <zyga> yes
[14:30] <zyga> that's my point about the mode variable
[14:30] <zyga> not do things that are not appropriate
[14:30] <pedronis> anyway sounds a forum topic
[14:30] <zyga> very much so
[14:35] <mup> PR snapd#3350 opened: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <https://github.com/snapcore/snapd/pull/3350>
[14:54] <morphis> zyga, mvo: https://github.com/snapcore/snapd/pull/3308 is ready for merging if you don't see anything else
[14:54] <mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
[15:11] <mvo> morphis: commented, there is another micro opitmization you could do, but I can also merge and propose this later
[15:12] <mvo> morphis: tests are green so
[15:12] <mvo> morphis: I will just merge and push my diff later
[15:12] <niemeyer> Lunch
[15:12] <mup> PR snapd#3337 closed: errtracker: try multiple paths to read machine-id <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3337>
[15:13] <davhou> Can someone offer a solution to this error I get when trying to run an installed snap? https://paste.ubuntu.com/24599229/plain/
[15:13] <mup> PR snapd#3351 opened: errtracker: small simplification around readMachineID() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3351>
[15:14] <davhou> receiving: "cannot create lock directory /run/snapd/lock: Permission denied" running as root or via sudo
[15:14]  * zyga goes to handle some errands
[15:14] <davhou> running Ubuntu 16.04.2 LTS
[15:16] <ogra_> davhou, stop doing that as root, and dont use sudo
[15:26] <morphis> mvo: sounds good! thanks
[15:27] <mup> PR snapd#3308 closed: tests/lib: introduce pkgdb helper library <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3308>
[15:27] <mup> PR snapd#3352 opened: interfaces/log-observe: allow using journalctl from hostfs for classic distro <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3352>
[15:30] <mup> PR snapd#3347 closed: snap-confine: move rm_rf_tmp to test-utils <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3347>
[15:34] <morphis> niemeyer: do you saw https://github.com/snapcore/snapd/pull/3274 already?
[15:34] <mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
[15:41] <Saviq> can I change privacy of a snap after I've registered a name, but before I've uploaded anything? does it matter before I publish anything?
[15:44] <niemeyer> morphis: If there are no comments there from me probably not
[15:44] <zyga> we should really fix the openvswitch test
[15:44] <zyga> I'll check out why it keeps timing out :/
[15:45] <morphis> niemeyer: references to you are there, asking for your comments :-)
[15:45] <niemeyer> morphis: So you'll get them..
[15:46]  * zyga moved to the pier to observe uncommon event of two cruise ships departing
[15:46] <zyga> I can obviously do code reviews at the same itme
[15:47] <zyga> jdstrand: I posted a question on https://github.com/snapcore/snapd/pull/3352#pullrequestreview-38977547
[15:47] <mup> PR snapd#3352: interfaces/log-observe: allow using journalctl from hostfs for classic distro <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3352>
[15:51] <zyga> jdstrand: and replied to myself :)
[15:51] <zyga> sorry for the noise
[16:07] <kyrofa> Saviq, I don't even think you get a snapd ID before you upload anything
[16:07] <kyrofa> Err, snap ID
[16:08] <kyrofa> Saviq, for example, you can't add collaborators until you've uploaded at least one revision
[16:08] <kyrofa> (at least, last I checked)
[16:17]  * Chipaca returns from the void
[16:18] <kyrofa> Chipaca, lost in time and space? (arkham horror reference /me hopes someone gets)
[16:18]  * Chipaca hugs kyrofa 
[16:19] <Chipaca> kyrofa: nobody gets it, but we like you anyway
[16:19] <Chipaca> :-p
[16:19] <kyrofa> :(
[16:19] <Chipaca> :-D
[16:19]  * kyrofa hugs Chipaca back anyway
[16:21] <Chipaca> kyrofa: in my defence, I've just been through 11 interviews with as many teachers in an hour and a bit, so I'm feeling slightly evil
[16:22] <ogra_> and ? are your kids hired
[16:22] <ogra_> ?
[16:22] <Chipaca> it's a bit of a record I've only had to censor myself with one of them
[16:22] <kyrofa> Chipaca, oh brutal
[16:22] <Chipaca> ogra_: I think they go to the next phase because of audience votes
[16:22] <ogra_> lol
[16:22] <Chipaca> ogra_: the jury definitely voted them out
[16:27]  * Chipaca wonders if he should bling up his PR so it gets reviews
[16:28] <pedronis> Chipaca: is the service refactor reviewable? or does it need changes because of this morning discussions?
[16:28] <Chipaca> pedronis: it's reviewable
[16:29] <Chipaca> pedronis: it includes what I think is the outcome of this morning's discussions, already
[16:29] <pedronis> ok
[16:29] <pedronis> Chipaca: snapd#3322 needs a 2nd review
[16:29] <mup> PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
[16:29] <kyrofa> Chipaca, I hear ALL CAPS and containing "you won't believe what happens" helps
[16:29] <Chipaca> kyrofa: http://www.commitstrip.com/en/2014/08/07/our-cto-has-discovered-an-incredible-way-of-making-developers-read-his-commit-messages-you-wont-even-believe-how-he-did-it/?
[16:30] <ogra_> pedronis, boo ... now you made us all miss the opportunity to see how a blinged up Chipaca PR looks like
[16:30] <Chipaca> ogra_: so. much. unicode
[16:30] <ogra_> haha hands and all ?
[16:31] <kyrofa> Chipaca, hahahahaha, EXACTLY what I was talking about
[16:31] <Chipaca> ogra_: the only limit is the version of unicode people have
[16:31] <kyrofa> "This was the most stupid bug in the world, fixed in the smartest way ever" <- how I feel about much of my work, but no one realizes it was my bug in the first place
[16:32] <Chipaca> ogra_: like, if i want to use an avocado, i'd better hope people are on yakkety
[16:32] <Chipaca> kyrofa: :-D
[16:32] <ogra_> dang ... no avocados for me then
[16:32] <Chipaca> ogra_: 🥑
[16:32] <ogra_> :(
[16:33] <Chipaca> ogra_: 🤘?
[16:33] <ogra_> trapped in 16.04 .... only square avocados
[16:33] <ogra_> that one works !
[16:33] <Chipaca> see? that one's in unicode 8 :-)
[16:37] <pedronis> Chipaca: we never have services so far in snapstate tests ?
[16:37] <Chipaca> pedronis: correct
[16:37] <Chipaca> pedronis: ARE YOU SCARED
[16:38] <pedronis> no, but I need to say something in the review
[16:38] <Chipaca> ok :-)
[16:43] <pedronis> Chipaca: reviewed
[16:43] <Chipaca> woo
[16:44] <Chipaca> psh! tests
[16:44] <pedronis> Chipaca: I think now I understood your question from the ther day, and I answered it, the alias tests have a similar problem
[16:44] <pedronis> they needed actual apps
[16:44] <pedronis> at Info-level actual apps
[16:45] <Chipaca> yeah
[16:45] <pedronis> s/at/at least/
[16:45] <Chipaca> ah well, I'll dig into that tomorrow
[16:45] <pedronis> sorry
[16:45] <Chipaca> was going to have to do it at some point anyway
[16:45] <Chipaca> no problem! you're probably right :-)
[16:45] <Chipaca> (otherwise i'd argue back -- you know i do)
[16:45] <pedronis> but you need to change all the tests anyway
[16:45] <pedronis> so :/
[16:46] <Chipaca> ¯\_(ツ)_/¯
[16:46] <pedronis> I mean is not like you managed not to touch them there
[16:47] <Chipaca> I did say I had 21 failing tests :-)
[16:47] <Chipaca> pedronis: thank you for the review!
[16:50] <sdrobertw> [Ubuntu core question] Does Ubuntu core supports any library to deploy the built-in GPS in DB410c, just as android has?
[16:50] <sdrobertw> [Ubuntu core question] Is there a way to "convert" existing SW applications installed via RPM or apt-get, to snappy packages so I can install them on DB410c?
[16:52] <Chipaca> ogra_: is that the dragonboard we support?
[16:53]  * Chipaca never remembers
[16:53] <kyrofa> Chipaca, indeed
[16:53] <ogra_> Chipaca, yes, but we dont have any userspace snaps for GPS or anything
[16:53] <Chipaca> ogra_: what interface is it?
[16:53] <ogra_> (i'm not even sure we have a snap interface for GPS yet)
[16:54] <ogra_> no idea ... never used it
[16:54] <Chipaca> i mean, usb? i2c? potato-over-carrier-pidgeon?
[16:54] <Chipaca> ah
[16:54] <ogra_> (i rarely carry moy board outside, to even get a sattelite fix)
[16:54] <ogra_> *my
[16:54] <kyrofa> sdrobertw, I'll let these guys debate over your first question, but your second question: you can tell snapcraft to unpack debs into a snap using `stage-packages`
[16:55] <kyrofa> sdrobertw, but that needs to be done on a machine with those debs available via their sources.list configuration. If this is just a deb you have, you can supply it directly via the `source` keyword
[16:55] <ogra_> sdrobertw, https://github.com/ogra1/laidout is a very ugly but working way ... (pretty old snap i guess there are better ways to get rid of the wrapper.sh nowadays)
[16:57] <ogra_> indeed, if you want to just use a deb from the ubuntu archive, just stage-packages shoudl eb enough
[16:57] <ogra_> *should be
[16:57] <kyrofa> sdrobertw, the one complication you can run into by essentially packaging a deb as a snap is that a snap is mounted in a particular directory: where the deb might be configured to reach out to /usr/share, it now need to to use $SNAP/usr/share
[16:57] <kyrofa> Just depends on the application
[16:58] <sdrobertw> will you join OpenHours real quick?
[16:58] <kyrofa> Sure!
[16:59]  * ogra_ sadly can't ... on my way out the door, only Chipaca's ping stopped me
[16:59] <sdrobertw> http://link.linaro.org/openhoursjoin
[16:59]  * Chipaca hugs ogra_ 
[16:59] <sdrobertw> Thanks!
[16:59] <Chipaca> ogra_: have a good one
[16:59]  * ogra_ hugs Chipaca 
[16:59] <ogra_> you too
[16:59] <kyrofa> Those germans, always leaving at the beginning of the day
[16:59] <ogra_> kyrofa, but we also dont sleep til afternoon
[16:59] <ogra_> !
[16:59] <kyrofa> Hahaha
[16:59] <sdrobertw> 943216362
[17:00]  * ogra_ looks around in case there are any asian earlybirds still up :P
[17:08]  * Chipaca fades into the bushes
[17:33] <kyrofa> sdrobertw, you know where to find us if you have questions when making those tutorials-- always happy to help!
[17:40] <sdrobertw> Thanks for all of your help ogra_ and kyrofa
[17:41] <kyrofa> sdrobertw, any time
[17:47] <morphis> mvo: https://github.com/snapcore/snapd/pull/3307 is ready for merging too :-)
[17:47] <mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
[18:06] <mup> PR snapd#3351 closed: errtracker: small simplification around readMachineID() <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3351>
[18:07] <niemeyer> morphis: ping
[18:07] <morphis> niemeyer: pong
[18:07] <niemeyer> morphis: Heya
[18:07] <morphis> hey!
[18:08] <niemeyer> morphis: Quite note on PR process: we avoid rebasing while changes are in review, otherwise we lose track of what was reviewed
[18:08] <niemeyer> s/Quite/Quick
[18:08] <niemeyer> morphis: snapd#3222 as one example
[18:08] <mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
[18:09] <morphis> niemeyer: fine for me, trying to keep my git log clean but if that is preferred I will follow that
[18:09] <niemeyer> morphis: Without the rebase, I could click on "View changes" since my last review and get an idea of where we are
[18:10] <niemeyer> morphis: Feel free to keep it anyway you want before pushing for review.. after that, it's more important that people can track what is being done, otherwise it's a full review every time
[18:10] <morphis> aye
[18:11] <morphis> niemeyer: what are you referring to with "I would actually prefer the original approach. "?
[18:11] <morphis> niemeyer: what I implemened or what mvo suggests?
[18:11] <niemeyer> morphis: Neither.. the original one, in the tree
[18:12] <niemeyer> morphis: systems: -debian* feels pretty good to me
[18:12] <morphis> niemeyer: the thing is that we want to run portions of these tests
[18:12] <morphis> as we have a bundled situation with seccomp enabled but AppArmor not
[18:13] <morphis> so we want at least verify the connected part of the interfaces tests works fine
[18:13] <morphis> but leave out the parts which verify the interface denies things
[18:13] <morphis> (the disconnected case)
[18:14] <niemeyer> morphis: Ah, I see
[18:15] <niemeyer> Okay, let me provide a new review then
[18:16] <morphis> niemeyer: thanks!
[18:28] <niemeyer> morphis: np, review updated
[19:22] <mup> PR snapcraft#1323 closed:  state: search for the build package that provides a virtual package <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1323>
[20:10] <mup> PR snapcraft#1315 closed: lxd: mock platform in the FakeLXD fixture <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1315>
[20:11]  * ahoneybun wonders when the filesystem bug would be fixed
[20:11] <ahoneybun> elopio: ^
[20:12] <kyrofa> ahoneybun, which filesystem bug?
[20:13] <ahoneybun> well all the snaps show as loop devices in file managers
[20:13] <ahoneybun> dolphin and nautilus
[20:15] <davhou> @ogra, OK, so back to my id, can you tell me what the folder ownership should be for /run/snapd?
[20:15] <nothal> davhou: No such command!
[20:16] <davhou> ogra_,  OK, so back to my id, can you tell me what the folder ownership should be for /run/snapd?
[20:17] <davhou> ogra_, it was root:david although I am getting the same error message as id david when i try to run the snap
[20:19] <kyrofa> davhou, mine is the same
[20:20] <davhou> kyrofa, the ownership on folder?
[20:20] <kyrofa> davhou, yeah
[20:20] <kyrofa> (but no errors here)
[20:21] <kyrofa> Though that surprises me a bit... what happens with multiple users?
[20:35] <kyrofa> noise][, is transferring snap IDs to other publishers easy these days? Or still a yucky manual process? i.e. should I still be giving the "register <snap>-<nick>" advice?
[20:41] <noise][> kyrofa: easy
[20:41] <kyrofa> noise][, excellent!
[20:41] <noise][> we still want reasonable commitment / justification to take a reserved name, but we've been a lot more free with them since transfers got easy
[20:42] <kyrofa> Of course, makes sense
[20:44] <kyrofa> noise][, okay, a harder question: if I was starting today, I'd request the upstream name. However, I'm not, and I have thousands of users (well, downloads anyway) of my snap. Do we have a process for renaming snaps?
[20:51] <kyrofa> noise][1, looks like your internet flaked there, not sure if you saw my question
[20:53] <noise][1> nope, sorry
[20:55] <nacc> kyrofa: fwiw, i recently renamed a snap by adding a wrapper to my old snap's yaml that replaced teh comamnds with 'please don't run this, use this snap isntead'
[20:56] <kyrofa> nacc, yeah... I don't want to do that to my users though
[20:56] <nacc> kyrofa: i wish there was some sort of rename op at the store level, but it would force the store to carry historical state (forever?)
[20:56] <nacc> and i'm not sure if it's organized in that way (i have no idea, i mean)
[20:56] <kyrofa> nacc, not really: nothing in snapd cares about the name, it uses a snap ID
[20:56] <kyrofa> That's not quite true, the name is used to form file paths
[20:57] <kyrofa> So that sounds hard
[20:57] <kyrofa> So the store would probably be fine with it, but snapd will probably barf
[20:57] <kyrofa> I'll just live with my namespaced snap name
[20:57] <nacc> kyrofa: oh i didn't realize it was all via IDs
[20:58] <nacc> so it could in theory have a lookup table for IDs
[20:58] <nacc> (the store)
[20:58] <nacc> but yeah, snapd would need to dtrt
[20:58] <kyrofa> Indeed