=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
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:25 |
---|---|---|
morphis | mvo: thanks! | 06:26 |
mvo | morphis: thank you, that was a really useful fix! | 06:27 |
morphis | :-) | 06:27 |
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:28 |
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:29 |
morphis | mvo: pushed | 06:31 |
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:32 |
zyga | good morning | 06:34 |
mvo | morphis: looking again | 06:36 |
morphis | zyga: morning! | 06:36 |
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:37 |
morphis | zyga, mvo: maybe we can quickly discuss anything left here | 06:38 |
zyga | morphis: sounds good | 06:41 |
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:42 |
mvo | zyga: I added another comment, but I agree, I think we just move forward we can always revisit the decision | 06:47 |
zyga | ok, let's merge it then | 06:48 |
morphis | mvo, zyga: thanks! | 06:49 |
morphis | anymore real code-review comments? | 06:49 |
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:51 |
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> | 06:59 |
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:16 |
mvo | zyga: snap :) | 07:17 |
zyga | :D | 07:17 |
abeato | zyga, hmm, so it is called by the shutdown/reboot command? | 07:17 |
zyga | abeato: not really, it is called by systemd from initrd on shutdown | 07:18 |
zyga | abeato: why? | 07:18 |
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:19 |
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:20 |
zyga | abeato: well the reboot command above is special as "recovery" is not a term normally parsed | 07:21 |
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:22 |
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:23 |
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:25 |
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:27 |
abeato | zyga, ok, I will pull the thread from there, thanks! | 07:28 |
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:29 | |
abeato | zyga, the call to shutdown when there is a core/kernel update happens in daemon.go:Start(), is that right? | 07:32 |
pedronis | abeato: atm yes | 07:34 |
abeato | ok | 07:34 |
pedronis | I mean, the code is there, it doesn't happen there, that code is setting a callback | 07:35 |
abeato | pedronis, yes yes :) | 07:36 |
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:37 |
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:45 |
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:46 |
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:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
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:53 |
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:54 |
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:57 |
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:58 |
mvo | pedronis: checking that question now | 07:59 |
mvo | pedronis: is the question if wrappers.IsService need to take into account if its a dbus activatable service? | 08:01 |
pedronis | mvo: yes, which means though that we would not create /snap/svc for those | 08:03 |
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:05 |
mvo | pedronis: slightly interessting how to organize the code so that we know in wrappers.IsService() if it is a dbus activated service | 08:06 |
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:07 |
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:08 |
Chipaca | (in https://github.com/golang/go/issues/19546) | 08:09 |
mvo | Chipaca: \o/ | 08:10 |
Chipaca | I hadn't noticed IsService | 08:12 |
Chipaca | why is it not a method of AppInfo? | 08:12 |
mvo | Chipaca: a good question. it is pretty recent | 08:13 |
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:14 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
pedronis | Chipaca: I'm happy not to care, and let you and mvo figure it out ;) | 08:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
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:27 | |
mvo | Chipaca: sounds resonable, I will look into it in a little bit | 08:28 |
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:29 |
Chipaca | looks like you implement a separate isDbusService, and use that | 08:30 |
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:31 |
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:33 |
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:34 |
Chipaca | pedronis: those things don't have daemon set | 08:35 |
pedronis | Chipaca: indeed | 08:35 |
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:36 |
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:37 |
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:38 |
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:39 |
Chipaca | mvo: why would it be wrappers.IsBinary and not snap.(*AppInfo).IsBinary? | 08:40 |
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:41 |
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:42 |
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:43 |
Chipaca | or at least a bright yellow flag :-) | 08:44 |
Chipaca | pedronis: not only, no | 08:44 |
Chipaca | waaait | 08:44 |
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:45 |
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:47 |
Chipaca | mvo: what would one on the system dbus look like? | 08:48 |
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:49 |
Chipaca | mvo: how is a dbus-activated system dbus service different from a bus-activated systemd service | 08:50 |
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:51 |
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:52 |
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:53 |
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:55 |
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:56 |
ackk | Chipaca, uhm, it seems it eventually deleted itself, I don't see it anymore now :/ | 08:57 |
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:58 |
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, ^^ | 08:59 |
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:01 |
Chipaca | ackk: ('snap tasks' used to be 'snap change', if your snapd is slightly old try that instead) | 09:02 |
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:04 |
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:06 |
mvo | pedronis: ok, let me update it | 09:07 |
pedronis | for when it's unknown | 09:07 |
pedronis | basically bigger state machine | 09:08 |
mvo | pedronis: updated it yet again | 09:21 |
pedronis | mvo: fixed the when repair section | 09:24 |
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:26 |
mvo | pedronis: great | 09:29 |
zyga | pstolowski: no, go ahead | 09:33 |
zyga | Chipaca: yes, gladly | 09:33 |
* 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:34 | |
ackk | Chipaca, it's from snap tasks | 09:36 |
Chipaca | ackk: could you pastebin the whole output of the relevant 'snap tasks'? | 09:40 |
ackk | Chipaca, http://paste.ubuntu.com/24597955/ | 09:40 |
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:41 |
abeato | zyga, I tried golint, but I got no output | 09:42 |
zyga | abeato: in that directory? | 09:42 |
abeato | zyga, yes | 09:42 |
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:43 |
pstolowski | zyga, thanks | 09:44 |
zyga | abeato: commented again | 09:44 |
zyga | abeato: let me look, that's still wrong :) probably | 09:44 |
zyga | abeato: but check my feedback | 09:45 |
abeato | zyga, sure, thanls | 09:45 |
morphis | ogra_: is rsyslog already removed in edge? | 09:46 |
mvo | morphis: yes | 09:46 |
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:47 |
pstolowski | pedronis, yes, saw it, thanks | 09:48 |
zyga | woohoo | 09:49 |
zyga | I see core edge :) | 09:49 |
* 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:50 |
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:55 |
mvo | zyga: what content interface chagne is that? | 09:56 |
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 | 09:58 |
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:01 |
abeato | zyga, it is a hurdle we do not really care about | 10:02 |
NicolinoCuralli | Hi guys, is it now possibile revoke a gpg key on the Store? | 10:04 |
zyga | abeato: can you justify that? | 10:06 |
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:09 |
abeato | *enfroce | 10:10 |
abeato | enfroce | 10:10 |
zyga | heh | 10:47 |
zyga | make a file called '<' by accident | 10:47 |
zyga | then remove it | 10:47 |
zyga | fun :) | 10:47 |
Chipaca | zyga: “rm \<” ? | 10:49 |
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:56 |
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 | 10:57 | |
zyga | Chipaca: yep, I tried with -- but that was just my naive idea ;) | 11:00 |
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:05 |
pstolowski | zyga, ^ something for you ;) | 11:06 |
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:07 |
* zyga looks | 11:08 | |
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:09 |
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:10 |
ogra_ | we should just rent out mpt to GH for a redesign ;) (for most of the UI actually IMHO) | 11:11 |
pstolowski | thx zyga | 11:12 |
cjwatson | ogra_: it has its good points | 11:12 |
ogra_ | some. yeah ... | 11:13 |
Chipaca | did somebody say lunch | 11:27 |
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:29 |
pedronis | mvo: wrote something in the forum about the last-refresh unset question/"issue" | 11:31 |
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:32 |
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:33 |
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:34 |
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:35 |
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:36 |
zyga | Chipaca: hmm, wonky | 11:37 |
Chipaca | oh? | 11:37 |
Chipaca | zyga: how so? | 11:37 |
zyga | http://pastebin.ubuntu.com/24598396/ | 11:39 |
zyga | Chipaca: (offtopic) bash completion for http would be lovely ;) | 11:39 |
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:40 |
zyga | Chipaca: ok, a bit better now | 11:45 |
Chipaca | zyga: http://pastebin.ubuntu.com/24598417/ | 11:47 |
Chipaca | en nu, lunch | 11:48 |
zyga | Chipaca: I did something like that | 11:49 |
Chipaca | zyga: note you can kill filledError; it slipped in by accident (was going to use it, didn't in the end) | 11:58 |
zyga | Chipaca: yep, I killed it | 12:00 |
* Chipaca goes back to his leftovers | 12:00 | |
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:01 |
pstolowski | thanks pedronis! | 12:02 |
zyga | pstolowski: all red on the rm-rf test move | 12:02 |
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:03 |
ogra_ | morphis, hmm, we should probably allow a cmdline option that creates that dir from the initrd for debug purposes | 12:04 |
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:05 |
zyga | Chipaca: how did you get around that terminal width issue in testing? | 12:06 |
Chipaca | zyga: regular expressions | 12:07 |
Chipaca | zyga: MATCH -z "${expected// /[[:space:]]+}" | 12:08 |
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:10 |
pstolowski | zyga, ok, pushed | 12:13 |
* zyga loves how this works | 12:13 | |
Chipaca | zyga: looks good; the level of nits i have are probably not worth it =) | 12:18 |
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:19 |
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:20 |
zyga | Chipaca: diff would be longer | 12:21 |
zyga | I'll change that but separately | 12:21 |
Chipaca | zyga: code would be better | 12:21 |
zyga | Chipaca: fair enough | 12:22 |
zyga | I wrote it like that for 100% coverage (I was cheating) | 12:22 |
zyga | Chipaca: fetch again | 12:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
pedronis | Chipaca: I think docs now go to the forum doc category | 12:29 |
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:30 |
Chipaca | zyga: I stand corrected :-) | 12:31 |
niemeyer | https://forum.snapcraft.io/c/doc | 12:31 |
Chipaca | well, 'stand' is a manner of speaking | 12:32 |
zyga | Chipaca: yes | 12:33 |
zyga | niemeyer: oh, nice | 12:33 |
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:34 |
ogra_ | woah ... popey ! 2.2k views for your wishlist post | 12:36 |
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:37 |
zyga | Send-pings-after-midnight | 12:38 |
Chipaca | zyga: i think that PR will fail static check btw | 12:38 |
* zyga tries | 12:38 | |
Chipaca | zyga: if you hurry you might beat travis :-D | 12:39 |
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:40 |
zyga | Chipaca: yes, I wrote that after all :") | 12:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:47 |
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:49 |
zyga | morphis: sure | 12:50 |
morphis | zyga: thanks | 12:50 |
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:51 |
morphis | zyga: done | 12:52 |
niemeyer | Would anyone have a plausible explanation for this: | 12:52 |
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:53 |
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:54 |
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:55 |
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:56 |
niemeyer | https://www.irccloud.com/pastebin/R0nWdOwZ/ | 12:57 |
niemeyer | zyga: ^ | 12:57 |
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:58 |
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? | 12:59 |
pstolowski | pedronis, I need to refresh my memory. last time I checked I couldn't really see what was wrong with it | 13:01 |
pedronis | pstolowski: oh, I though you understood the problem | 13:17 |
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:18 | |
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:19 |
pedronis | pstolowski: ? | 13:20 |
pedronis | pstolowski: there's a full map of task types | 13:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:29 |
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:30 |
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:31 |
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:32 |
zyga | jdstrand: initially I also folded Name into meta-data but I think not doing so is just easier | 13:33 |
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:34 |
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:35 |
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:36 |
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:37 | |
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:38 |
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:39 |
zyga | fgimenez: can you tell me more about that test that you just mentioned? | 13:42 |
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:43 |
fgimenez | zyga: last changes pushed | 13:51 |
zyga | fgimenez: looking | 13:51 |
fgimenez | thank you zyga | 13:52 |
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:55 |
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:57 |
rharper | morphis: here | 13:58 |
zyga | fgimenez: let me show you what CE did | 14:00 |
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:03 |
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:06 |
* zyga actually should eat lunch first | 14:16 | |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
zyga | pedronis: well, we could make it work | 14:22 |
zyga | but I think the general case needs to be investigated more | 14:22 |
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:23 |
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:24 |
pedronis | I early in the boot sequence | 14:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:35 |
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> | 14:54 |
mvo | morphis: commented, there is another micro opitmization you could do, but I can also merge and propose this later | 15:11 |
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:12 |
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:13 |
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:14 |
ogra_ | davhou, stop doing that as root, and dont use sudo | 15:16 |
morphis | mvo: sounds good! thanks | 15:26 |
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:27 |
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:30 |
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:34 |
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:41 |
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:44 |
morphis | niemeyer: references to you are there, asking for your comments :-) | 15:45 |
niemeyer | morphis: So you'll get them.. | 15:45 |
* 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:46 |
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:47 |
zyga | jdstrand: and replied to myself :) | 15:51 |
zyga | sorry for the noise | 15:51 |
kyrofa | Saviq, I don't even think you get a snapd ID before you upload anything | 16:07 |
kyrofa | Err, snap ID | 16:07 |
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:08 |
* Chipaca returns from the void | 16:17 | |
kyrofa | Chipaca, lost in time and space? (arkham horror reference /me hopes someone gets) | 16:18 |
* Chipaca hugs kyrofa | 16:18 | |
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:19 | |
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:21 |
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:22 |
* Chipaca wonders if he should bling up his PR so it gets reviews | 16:27 | |
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:28 |
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:29 |
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:30 |
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:31 |
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:32 |
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:33 |
pedronis | Chipaca: we never have services so far in snapstate tests ? | 16:37 |
=== chihchun is now known as chihchun_afk | ||
Chipaca | pedronis: correct | 16:37 |
Chipaca | pedronis: ARE YOU SCARED | 16:37 |
pedronis | no, but I need to say something in the review | 16:38 |
Chipaca | ok :-) | 16:38 |
pedronis | Chipaca: reviewed | 16:43 |
Chipaca | woo | 16:43 |
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:44 |
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:45 |
Chipaca | ¯\_(ツ)_/¯ | 16:46 |
pedronis | I mean is not like you managed not to touch them there | 16:46 |
Chipaca | I did say I had 21 failing tests :-) | 16:47 |
Chipaca | pedronis: thank you for the review! | 16:47 |
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:50 |
Chipaca | ogra_: is that the dragonboard we support? | 16:52 |
* 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:53 |
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:54 |
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:55 |
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:57 |
sdrobertw | will you join OpenHours real quick? | 16:58 |
kyrofa | Sure! | 16:58 |
* 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 | 16:59 |
* ogra_ looks around in case there are any asian earlybirds still up :P | 17:00 | |
* Chipaca fades into the bushes | 17:08 | |
kyrofa | sdrobertw, you know where to find us if you have questions when making those tutorials-- always happy to help! | 17:33 |
sdrobertw | Thanks for all of your help ogra_ and kyrofa | 17:40 |
kyrofa | sdrobertw, any time | 17:41 |
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> | 17:47 |
mup | PR snapd#3351 closed: errtracker: small simplification around readMachineID() <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3351> | 18:06 |
niemeyer | morphis: ping | 18:07 |
morphis | niemeyer: pong | 18:07 |
niemeyer | morphis: Heya | 18:07 |
morphis | hey! | 18:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
niemeyer | morphis: Ah, I see | 18:14 |
niemeyer | Okay, let me provide a new review then | 18:15 |
morphis | niemeyer: thanks! | 18:16 |
niemeyer | morphis: np, review updated | 18:28 |
=== JanC is now known as Guest79336 | ||
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> | 19:22 |
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:10 |
* ahoneybun wonders when the filesystem bug would be fixed | 20:11 | |
ahoneybun | elopio: ^ | 20:11 |
kyrofa | ahoneybun, which filesystem bug? | 20:12 |
ahoneybun | well all the snaps show as loop devices in file managers | 20:13 |
ahoneybun | dolphin and nautilus | 20:13 |
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:15 |
davhou | ogra_, OK, so back to my id, can you tell me what the folder ownership should be for /run/snapd? | 20:16 |
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:17 |
kyrofa | davhou, mine is the same | 20:19 |
davhou | kyrofa, the ownership on folder? | 20:20 |
kyrofa | davhou, yeah | 20:20 |
kyrofa | (but no errors here) | 20:20 |
kyrofa | Though that surprises me a bit... what happens with multiple users? | 20:21 |
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:35 |
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:41 |
kyrofa | Of course, makes sense | 20:42 |
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:44 |
kyrofa | noise][1, looks like your internet flaked there, not sure if you saw my question | 20:51 |
noise][1 | nope, sorry | 20:53 |
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:55 |
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:56 |
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:57 |
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 | 20:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!