| cachio | niemeyer, I am running with -vv trying to reproduce the error locally | 03:01 |
|---|---|---|
| cachio | let's see if it give us more information about the response which is causing that | 03:01 |
| tismith | Hi guys - I'm trying to build a rust program using snap craft, and the rust plugin is working ... sort of, but when I do a 'snapcraft clean build' I have trouble with cargo not finding rustc | 04:39 |
| tismith | The build log is here: https://build.snapcraft.io/user/tismith/device-checkout-rs/239825 | 04:41 |
| tismith | it looks like it's a problem with the rust plugin, but if so, I'm wondering why I'm hitting it and seemingly no-one else | 04:41 |
| tismith | I've also posted this to the forum: https://forum.snapcraft.io/t/problem-building-rust-based-snap/5776 | 04:59 |
| mborzecki | morning | 05:05 |
| alphawarrior | Hello everyone. I have some ancient old snapcraft installed on my gentoo and I can't upgrade with (snap install snapcraft) as it fails with Mount snap "snapcraft" (1594) (info failed to parse: invalid confinement type: "classic". How could I upgrade the confinement app? | 05:26 |
| mup | PR snapd#5204 closed: data: add helper that can generate/start/stop the snapd service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5204> | 05:57 |
| mup | PR snapd#5269 closed: systemd: adjust TestWriteMountUnitForDirs() to use squashfs.MockUseFuse(false) <Simple> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5269> | 06:25 |
| mup | PR snapd#5267 closed: tests: retry 'restarting into..' match in the snap-confine-from-core test <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5267> | 06:26 |
| mvo | mborzecki: hey, whats the status of 5030? should this be labeled blocked, i.e. is it waiting for input from e.g. neal? | 06:28 |
| zyga | good morning | 06:49 |
| * zyga overslept | 06:49 | |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 06:50 |
| mvo | hey zyga and pstolowski | 06:50 |
| mborzecki | pstolowski: zyga: hey | 06:51 |
| mborzecki | gitlab continues playing bad-MS card https://about.gitlab.com/2018/06/05/gitlab-ultimate-and-gold-free-for-education-and-open-source/ | 07:11 |
| jamesh | zyga: hi. Is there anything more you'd want on https://github.com/snapcore/snapd/pull/5184 ? | 07:24 |
| mup | PR #5184: interfaces: add {contacts,calendar}-service interfaces <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5184> | 07:24 |
| zyga | jamesh: no, it looks good now, I will approve it | 07:29 |
| jamesh | zyga: thanks | 07:29 |
| jamesh | zyga: it has niemeyer's interface name changes in now, so I don't think it needs to go back to him | 07:30 |
| zyga | I agree | 07:30 |
| zyga | and really, thank you for this work :) | 07:30 |
| mup | PR snapd#5184 closed: interfaces: add {contacts,calendar}-service interfaces <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5184> | 07:43 |
| zyga | https://github.com/snapcore/snapd/pull/5268 needs a 2nd review and is marked as critical | 07:51 |
| mup | PR #5268: tests: fix flaky test for hooks undo <Critical> <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5268> | 07:51 |
| pstolowski | #5268 needs second review, it's a trivial | 08:02 |
| mup | PR #5268: tests: fix flaky test for hooks undo <Critical> <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5268> | 08:02 |
| Chipaca | pstolowski: I'm looking at 5268 | 08:03 |
| Chipaca | pstolowski: I don't understand the change | 08:03 |
| Chipaca | pstolowski: (good morning!) | 08:04 |
| * zyga is not the only one then | 08:04 | |
| zyga | Chipaca: I think looking at broader context helps | 08:04 |
| Chipaca | I'm looking at the whole file | 08:04 |
| Chipaca | still don't get it :-) | 08:05 |
| pstolowski | Chipaca: see the description. the test was adding things to s.change and s.task, but TestSetup adds configure hook | 08:05 |
| pstolowski | the test doesn't account for configure hook | 08:06 |
| pstolowski | it's not linked to other tasks created by the test itself | 08:06 |
| Chipaca | pstolowski: you can't get the configure hook task? | 08:06 |
| zyga | mborzecki: what is the term that we want to use for snap name with possibly an instance name? | 08:07 |
| zyga | mborzecki: surely not snap name | 08:07 |
| pstolowski | Chipaca: i don't need configure, i don't care about it for this test | 08:07 |
| mborzecki | zyga: heh, i'm using InstanceName and StoreName now | 08:07 |
| zyga | hello-world_demo | 08:07 |
| mborzecki | the PR i proposed used LocalName and StoreName | 08:08 |
| zyga | is that an instance name or a store name? | 08:08 |
| mborzecki | hello-world_foo -> instance/local name | 08:08 |
| mborzecki | hello-world -> store name | 08:08 |
| zyga | and foo? | 08:08 |
| zyga | :) | 08:08 |
| mborzecki | again, in the PR i proposed it was LocalKey, now it's InstanceKey | 08:08 |
| zyga | will you adjust the snap-confine PR as well? | 08:09 |
| zyga | I'm happy with instance key | 08:09 |
| zyga | store name | 08:09 |
| zyga | and ... local name (or is that instance) | 08:09 |
| zyga | as long as we are consistent | 08:09 |
| mborzecki | s-c PR is using sc_snap_drop_instance_name (maybe it should be key?) | 08:09 |
| zyga | I made some comments there too, please look | 08:10 |
| zyga | so if you adjust please let's keep the terminology | 08:10 |
| zyga | and before it sinks in, document the terminology in the function description please | 08:10 |
| mborzecki | zyga: can you take a look at https://forum.snapcraft.io/t/parallel-snap-installs/5763 ? it's using 'local name' and 'local key' | 08:11 |
| mborzecki | and it's based on the notes we took during the sprint | 08:11 |
| mborzecki | i'll be updating the post as we come to agreements on the naming and stuff :) | 08:11 |
| zyga | ack | 08:11 |
| mborzecki | zyga: just to be sure, the paths in apparmor profiles are all mount-ns local right? | 08:12 |
| zyga | ish | 08:14 |
| zyga | it's more complicated | 08:14 |
| zyga | they are local to the namespace because we pivot root | 08:14 |
| Chipaca | robert_ancell: morning sir | 08:14 |
| mborzecki | 'it's complicated' ;) | 08:14 |
| zyga | so you can think about it as such | 08:15 |
| mborzecki | ack | 08:15 |
| zyga | but I don't know if this is just apparmor not knowing about pivot root | 08:15 |
| zyga | or apparmor handling pivot root in this specific way | 08:15 |
| Chipaca | robert_ancell: is it Bluefin you're at this week? I can go in _today_ | 08:15 |
| Chipaca | no afternoon school run, suddenly | 08:15 |
| mborzecki | zyga: i'm asking cause the profiles will be referencing store-name, while we bind mount the local-name on top of it | 08:15 |
| zyga | for this purpose yes, you can think of the paths as those that are visible inside the mount namespace | 08:16 |
| robert_ancell | Chipaca, I am in Bluefin! | 08:17 |
| Chipaca | robert_ancell: would me going in make sense? right now, or after lunch? | 08:17 |
| robert_ancell | Chipaca, we're in the middle of a design process - so you could come in if you want to be involved | 08:17 |
| Chipaca | robert_ancell: i'm too much of a chicken (in the chicken-and-pigs sense) for that, i suspect | 08:18 |
| Chipaca | sounds fun though :-) | 08:19 |
| mup | PR snapd#5268 closed: tests: fix flaky test for hooks undo <Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5268> | 08:24 |
| mvo | Chipaca: did we ever discuss client/packages.go:Snap.Developer ? the daemon/snaps.go code assigns the publisher to it | 08:24 |
| mvo | Chipaca: so now I wonder how to describe what we do in the new l`snap list --format=help` | 08:25 |
| Chipaca | mvo: note there isn't a 'publisher' field | 08:25 |
| mvo | Chipaca: I wonder if a) I should use something neutral like owner b) remove the help and add Snap.Publisher c) something else | 08:25 |
| mvo | Chipaca: yeah, I noticed that too :) | 08:25 |
| Chipaca | mvo: it gets more fun | 08:27 |
| Chipaca | mvo: because the snap.Info.Publisher is set from the store's Developer | 08:27 |
| mvo | Chipaca: meh, I remember trying to untangle this and failing badly | 08:29 |
| mvo | Chipaca: I think I go with something neutral then for now | 08:29 |
| mvo | Chipaca: I also vaguely remember that once the new api is available things could be untangled(?) | 08:30 |
| zyga | caretaker | 08:30 |
| robert_ancell | Chipaca, you should come in though! | 08:30 |
| pedronis | they untangled in the server yes, there's is only publisher | 08:30 |
| mvo | zyga: The name of a ca\ | 08:30 |
| mvo | retake of the snap" | 08:30 |
| Chipaca | mvo: in the current details api, 'origin' is the developer username, 'publisher' is the developer's display name, and developer_id is noise | 08:30 |
| mvo | pedronis: nice | 08:30 |
| pedronis | Chipaca: mvo: we discussed a bit about with Gustavo as well, I think for a while we want both Developer and Publisher in our own API | 08:31 |
| zyga | Chipaca: noise owns all the snaps ;) | 08:31 |
| pedronis | Chipaca: an to rename the list header in snap list to publisher | 08:31 |
| pedronis | Chipaca: mvo: bit of a question, is the timing of this | 08:31 |
| Chipaca | mvo: in the next-gen details api :) 'publisher' is an object, with username, id, and display-name | 08:32 |
| mvo | pedronis: so we would have client:Snap.{Developer,Publisher} and both would set to the correct value? | 08:32 |
| mvo | Chipaca: oh, ok | 08:32 |
| pedronis | mvo: they would be set to the same value for a while | 08:32 |
| Chipaca | mvo: let's not touch the client api for a bit please? | 08:32 |
| pedronis | we really don't have uploaders in the api | 08:32 |
| pedronis | so far | 08:33 |
| Chipaca | mvo: i need to move us to the v2 info api | 08:33 |
| mvo | pedronis: would it hurt if I add "Publisher" to client now? | 08:33 |
| mvo | Chipaca: meh, ok | 08:33 |
| Chipaca | mvo: so any change now will need to get reworked | 08:33 |
| pedronis | mvo: no, but best to double check again with Gustavo | 08:33 |
| Chipaca | and you risk going in the wrong direction :-) | 08:33 |
| mvo | Chipaca: I was thinking if I add "Publisher" and only expose help there things would improve | 08:33 |
| Chipaca | mvo: ah, this is for --format? | 08:33 |
| Chipaca | hmm hmmmm | 08:33 |
| mvo | Chipaca: mostly | 08:33 |
| Chipaca | this is more user-facing than the client api | 08:33 |
| mvo | Chipaca: I mean, I think it would be a good idea in general | 08:33 |
| mvo | Chipaca: but I am touching it because of --format | 08:34 |
| pedronis | as I said the column itself s/Developer/Publisher/ afaict | 08:34 |
| pedronis | from discussion | 08:34 |
| Chipaca | right, but having the client api have both for compatibility is fine; having both in the user-facing world is ugly | 08:34 |
| mvo | Chipaca: i.e. no helper for "Developer" (so its not displayed via format=help) and publisher with help and the right values | 08:34 |
| Chipaca | ok, let's do the other thing and change it to be Publisher everywhere that's user-facing? | 08:34 |
| mvo | pedronis: s/Developer/Publisher/ in the column is something I can do in the same go | 08:35 |
| Chipaca | robert_ancell: I'll go in, to be there around noon. | 08:35 |
| mvo | Chipaca: ok, sounds good. I can prepare a tiny PR for this | 08:35 |
| Chipaca | robert_ancell: the gods of trains willing | 08:35 |
| Chipaca | mvo: pedronis: sounds good | 08:35 |
| Chipaca | mvo: tag me on the PR, if it's not the format one | 08:37 |
| mvo | Chipaca: will do, I will do it as a separate one for easier review | 08:38 |
| Chipaca | ok | 08:38 |
| Chipaca | I'm off for a while, will bbl | 08:39 |
| mvo | Chipaca: see you | 08:39 |
| mup | PR snapd#4917 closed: repo: added repo ConnectionsInfo method (for the new snap connections API) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/4917> | 08:41 |
| mup | PR snapd#5270 opened: snap,client: Show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270> | 08:52 |
| mvo | pedronis: good morning - do you have an opinion on 5259 at this point? should I work on the "core" config handling as part of this PR or in a followup? | 08:53 |
| pedronis | mvo: well, as it is it will use snapd which we said is not what we want initially, so I think it might need a prequel more than a follow up | 08:59 |
| pedronis | mvo: the prequel should make snapd a synonym of core like system for config, and block doing config on bases | 09:00 |
| pedronis | mvo: unless I'm confused there's a bit of stuff we don't need if we continue hanging config on "core" in 5259 atm | 09:01 |
| pedronis | mvo: not sure it makes sense to land it to remove it again | 09:02 |
| pedronis | mvo: it's also relatively small so you could do everything there, but I wouldn't land it as is | 09:02 |
| mvo | pedronis: thank you! I will do a prequel then first. was mostly wondering because I'm exploring creating spread images which of course need firstboot support but I agree the order you have in mind makes more sense | 09:08 |
| mborzecki | zyga: pushed changes to #5256 | 09:12 |
| zyga | ack | 09:12 |
| mup | PR #5256: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5256> | 09:12 |
| zyga | mvo: failure on #5270 | 09:28 |
| mup | PR #5270: snap,client: Show "publisher" in `snap list` and expose in client API <Created by mvo5> <https://github.com/snapcore/snapd/pull/5270> | 09:28 |
| mvo | zyga: thank you, looking | 09:31 |
| mvo | zyga: aha, I think we have a bunch of spread tests | 09:32 |
| mup | PR snapd#5256 closed: cmd/libsnap-confine-private: helper for extracting store snap name from local-name <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5256> | 10:06 |
| abeato | mvo, hey, I have created https://forum.snapcraft.io/t/denials-when-opening-libraries-appear-after-snapcraft-change/5783 , I would appreciate if you can take a quick look | 10:16 |
| morphis_ | zyga, mvo: https://forum.snapcraft.io/t/base-snaps-with-defined-applications/5784 | 10:23 |
| zyga | thanks | 10:23 |
| morphis_ | I left it pretty generic but can detail my use case if needed | 10:23 |
| zyga | commented on the forum, thanks for starting this | 10:25 |
| mvo | abeato: thank you, I suspect that snapcraft did some patchelf magic to set the rpath in your binary | 10:35 |
| abeato | dough! | 10:35 |
| mvo | abeato: this is a regular snap, right? not classic or anything | 10:35 |
| abeato | mvo, yes, a confined one | 10:35 |
| mvo | abeato: iirc there is an option to disable it, let me quickly check | 10:35 |
| mvo | abeato: I mean there is an option to disable patchelf | 10:35 |
| abeato | sure | 10:35 |
| mvo | abeato: please try: parts:\n part-name:\n build-attributes: [no-patchelf]" | 10:38 |
| mvo | abeato: I will also reply in the forum for reference | 10:38 |
| abeato | mvo, thanks! so, which is the rationale for using patchelf? should not be *not* using it the default? | 10:39 |
| mvo | abeato: I don't know, sorry. thats probablay a question for sergio. can you quickly quick with "objdump -x /path/to/your/binary | grep RPATH? | 10:41 |
| mborzecki | github having a hard time? | 10:41 |
| mvo | abeato: or readself -d | 10:41 |
| mvo | mborzecki: yeah, for me as well | 10:41 |
| zyga | mvo, abeato: the snapcraft team have requested that all questions go to the forum | 10:41 |
| zyga | please ask your question there abeato | 10:41 |
| zyga | it will both allow snapcraft team members to respond when they are around (different timezone) and make the question useful to others that may search for it | 10:41 |
| mvo | mborzecki: I will avoid comments about prematurely moving the servers to windows nt | 10:42 |
| mborzecki | mvo: yeah, just restarted the travis job on master branch :/ | 10:42 |
| zyga | mvo: windows NT is very efficient if you use less than 10 files | 10:42 |
| mborzecki | mvo: i wouldn't mind winnt, unless they don't use iis to host anything | 10:42 |
| abeato | mvo, https://pastebin.canonical.com/p/zNTbNmg6gn/ there is something called $ORIGIN there | 10:42 |
| zyga | abeato: that's defined by the ELF standard | 10:43 |
| abeato | mvo, zyga sure, will ask in the forum, thanks | 10:43 |
| mvo | zyga, abeato I think this is new | 10:43 |
| zyga | abeato: http://man7.org/linux/man-pages/man8/ld.so.8.html | 10:43 |
| * zyga needs to break to take a shower and take the dog out, bbl | 10:44 | |
| abeato | interesting... | 10:45 |
| mvo | abeato: yeah, pretty sure this is snapcrafts patchelf magic | 10:45 |
| mvo | abeato: anyway I replied. sorry that I'm not more helpful, Sergio (sergiusens) hopefully can tell you more about the background, i.e. why this was changed | 10:46 |
| abeato | mvo, thanks a lot, I'll create a new post. As /snap/core was around I asked you first ;) | 10:46 |
| mvo | abeato: heh, sure | 10:47 |
| mvo | abeato: hm,hm, but $ORIGIN/../lib in the rpath still does not quite explain why it picked /snap/core/ - please let me know if disabling patchelf helps or if you still get the same denials | 10:52 |
| zyga | abeato: what's the issue? | 10:54 |
| mvo | niemeyer: is 5234 (support for dynamic list output via user provided templtaes like: snap list --format="{{.ID}}|{{.Name") something you want to review at a high level ? as its very user facing? (probably no need for an in-depth code review, just want to make sure you are happy on the high-level) | 10:54 |
| mvo | zyga: https://forum.snapcraft.io/t/denials-when-opening-libraries-appear-after-snapcraft-change/5783/ | 10:54 |
| abeato | mvo, will let you know | 10:54 |
| mvo | abeato: ta | 10:54 |
| abeato | zyga, https://forum.snapcraft.io/t/denials-when-opening-libraries-appear-after-snapcraft-change/5783 | 10:55 |
| mvo | zyga: ld tries to load stuff from /snap/core/$rev/usr/lib | 10:55 |
| mvo | zyga: and its a bit unclear where this comes from | 10:55 |
| mvo | zyga: I mean, why this is happening, it was not happening before | 10:55 |
| zyga | mvo: in normally confined snaps? | 10:55 |
| mvo | zyga: correct | 10:56 |
| zyga | abeato: what's readelf -a ? | 10:56 |
| zyga | (pastebin that please) | 10:56 |
| mvo | zyga: https://pastebin.canonical.com/p/zNTbNmg6gn/ is readelf -d | 10:56 |
| abeato | zyga, https://pastebin.canonical.com/p/gW7QXgdynQ/ | 10:57 |
| * abeato has to go, back in a bit | 10:58 | |
| * zyga didn't notice this is in Spanish | 11:02 | |
| zyga | I should go back to school one day | 11:02 |
| zyga | mvo, abeato: your pastes differ | 11:04 |
| zyga | one has RPATH while the other does not | 11:04 |
| zyga | in any case, neither specify /snap/core directly | 11:04 |
| zyga | the use of /snap/core is not allowed | 11:04 |
| zyga | apps must use the rootfs paths like /lib | 11:05 |
| zyga | so I don't know what's causing that yet | 11:05 |
| zyga | anyway -> walk | 11:05 |
| zyga | thanks for the pastebins to both of you | 11:05 |
| mvo | ppisati: I updated the bionic ppa, sorry for the delay, will reply also to the mail (after lunch). might not be published yet | 11:14 |
| ppisati | mvo: k | 11:16 |
| mup | PR snapd#5271 opened: [WIP] cmd: attempt to start the document portal if running with a session bus <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5271> | 11:22 |
| * cachio afk | 11:46 | |
| mborzecki | jdstrand: travis job in 5250 is currently failing due to eperm/eaccess | 12:09 |
| === pstolowski is now known as pstolowski|lunch | ||
| jdstrand | mborzecki: yes, I know. I'm in the process of looking at it | 12:09 |
| jdstrand | thanks | 12:10 |
| jdstrand | (I saw the PR comments) | 12:10 |
| zyga | re | 12:17 |
| zyga | jdstrand: hey, can you please look at the segment PR again | 12:18 |
| zyga | I think it's ready and it just needs your ack | 12:18 |
| abeato | zyga, ah, silly me, this is the real thing: https://pastebin.canonical.com/p/9tpKb52fqj/ (sorry for the locale, I think they should not translate this sort of stuff :D | 12:18 |
| zyga | I'm still working on validation in two branches down the pipe, while on a walk I found a bug in my previous idea and I think I have (I think) the right thing that will solve all the current constraints (trespassing, tmpfs origin, squashfs, fuse) but I need to code it to try | 12:19 |
| zyga | abeato: no worries, I understand Spanish well enough for that :) | 12:19 |
| abeato | :) | 12:19 |
| niemeyer | mvo: Seems reasonable.. one small concern I have is marrying with the language | 12:19 |
| mvo | niemeyer: ok, happy to address that | 12:20 |
| niemeyer | mvo: Maybe not so much of a practical concern | 12:20 |
| niemeyer | mvo: The text template in Go has a nice feeling to it.. down side is we'd need to reimplement if we ever move elsewhere | 12:21 |
| Chipaca | mvo: niemeyer: hello from bluefin | 12:22 |
| niemeyer | Chipaca: Hey! | 12:22 |
| Chipaca | i'm not going to make the standup today | 12:22 |
| jdstrand | zyga: yes | 12:22 |
| Chipaca | but i'll be syncing with gnome software and in particular robert_ancell | 12:22 |
| zyga | jdstrand: thank you :) | 12:22 |
| niemeyer | Chipaca: Nice, please let us know | 12:22 |
| Chipaca | niemeyer: mvo: meanwhile I'm working on small branches to make a cross-platform snap-packer | 12:23 |
| Chipaca | small detour :-) | 12:23 |
| mvo | niemeyer: hm, hm, that is a fair point | 12:24 |
| niemeyer | Chipaca: Isn't that "snap pack"? | 12:27 |
| mvo | niemeyer: it is except that "GOOS=windows go build github.com/snapcore/snap/cmd/snap" is unhappy right now because of too much syscall. use. aiui Chipaca build something that can be cross build more easily | 12:28 |
| mvo | niemeyer: do you think we should limit the use of the template language, i.e. only allow {{.XXX}} as constructs? | 12:28 |
| niemeyer | mvo: That's one possibility.. another idea might be to outsource the actual formatting by providing json | 12:29 |
| niemeyer | About the packer, should we make a goal to not have syscall in snap itself | 12:30 |
| niemeyer | ? | 12:30 |
| niemeyer | Instead of having a different tool? | 12:30 |
| niemeyer | This is the client, after all.. | 12:30 |
| mvo | niemeyer: outsource - you mean snap list would just output all json and the user deals with how to format it using something like jq? | 12:31 |
| niemeyer | mvo: Yeah | 12:32 |
| zyga | mvo: if we go down that path I would suggest that we add a generic way to see the raw output of API requests over CLI | 12:32 |
| zyga | this would make sense to many query-type commands | 12:32 |
| zyga | snap list, snap changes, snap... | 12:32 |
| zyga | lots of them could just grow a --raw=json | 12:33 |
| zyga | (or something appropriate) | 12:33 |
| mvo | zyga: yeah, I'm not actually sure we need a command, then we can as well document curl --unix-socket etc (just thinking alout) | 12:33 |
| zyga | and then instead of providing their usual output, give the raw json object on stdout | 12:33 |
| niemeyer | zyga: Sort of.. the idea is nice, but commands also do some processing, often with multiple calls.. I wonder if we can get something sensible | 12:33 |
| zyga | mvo: a command is more natural IMO | 12:33 |
| zyga | niemeyer: that's true, things that poll/wait | 12:33 |
| niemeyer | zyga: I agree with the principle that we shouldn't have to rethink the output format, though | 12:34 |
| zyga | still, my point is that if we do the raw idea it should not be list specific, it's really nice for integration with other languages as they don't need to use glib bindings if they can just naturally process CLI output without writing a parser | 12:34 |
| zyga | at the same time, yes, we have the socket | 12:34 |
| zyga | but perhaps it is still nice to use a CLI (e.g. when we grow remote calls and more auth) | 12:34 |
| mvo | niemeyer: I might also implement a trivial template engine to avoid our dependency on the (quite rich) golang templating package | 12:35 |
| niemeyer | zyga, mvo: Maybe something in between.. we might offer an additional command that talks to the API, does some basic processing (auth, errors, etc), and otherwise offers the raw API | 12:35 |
| zyga | niemeyer: snap json /v2/snaps/ | 12:35 |
| zyga | {...} | 12:35 |
| niemeyer | Yeah, something along those lines | 12:36 |
| zyga | this is also nice because it's not that suddenly you notice some commands have a --json switch and some don't i | 12:36 |
| niemeyer | mvo: What's the use case? | 12:36 |
| niemeyer | zyga: Yeah, literally everything is available from day one | 12:37 |
| zyga | instead you can look at what the json command supports (e.g. via json --help) | 12:37 |
| niemeyer | It's a nice way to play as well | 12:37 |
| niemeyer | (and learn) | 12:37 |
| zyga | niemeyer: and a day layer you'd have python-snaps packages or snapd-js or whatever people use | 12:37 |
| zyga | and a zoo of things that grow on top, which is nice for ecosystem | 12:38 |
| niemeyer | Perhaps not the zoo part, but otherwise yes :P | 12:38 |
| mvo | niemeyer: the use case is a user request to have something like dpkg-query --format or rpm --whatever-the-option-is-called-there | 12:38 |
| niemeyer | What are they trying to do? | 12:38 |
| mup | PR snapcraft#2157 closed: nodejs plugin: update to the latest 6.x LTS point release <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2157> | 12:39 |
| mvo | niemeyer: its for the sos system and it just includes the installed software (debs, snaps) as part of a support request aiui | 12:39 |
| niemeyer | Ah, interesting | 12:39 |
| zyga | mvo: so presumably they could just as well consume json directly | 12:39 |
| zyga | unless it's written in shell :/ | 12:40 |
| mvo | niemeyer: "dpkg-query -W -f='${Package}|${Version}\\n' # debian" is what they are doing today | 12:40 |
| zyga | (is it?) | 12:40 |
| niemeyer | I see | 12:40 |
| mvo | zyga: they can, I'm fine either way. to me it feels more user friendly to have --format={{Name}} etc. but I am biased :) learning jq is not hard, ist just one more step | 12:41 |
| mvo | zyga: I would not be surprised if written in shell, let me see | 12:41 |
| zyga | mvo: for users it is less friendly but for developers that integrate it is more because it unlocks more APIs | 12:42 |
| mvo | zyga: sure, its orthogonal to some extend. in any case, I just need a decision, I can also work on the `snap json` thing | 12:43 |
| * zyga agrees | 12:44 | |
| mvo | zyga: and I'm biased, I have grown to like the snap list --format=help and so. but thats a poor reason to not go for something better | 12:45 |
| zyga | mvo: I think it's not a sin if we do both | 12:45 |
| zyga | it's a client side thing anyway | 12:45 |
| zyga | and would help people with ad-hoc scripts in shell | 12:45 |
| * mvo nods | 12:46 | |
| niemeyer | mvo: We should at least write down how that would look like with the "snap api" call or whatever it is | 12:49 |
| niemeyer | mvo: If it feels like a monster, that's a sign :) | 12:49 |
| === pstolowski|lunch is now known as pstolowski | ||
| jdstrand | mborzecki: ok, I tacked on the time-control bit at the end of last week and forgot to run it through spread. I've fixed it. I'll remove the blocked tag after the tests pass (they do locally) | 12:53 |
| mborzecki | halfway done, 38 files changed, 456 insertions(+), 293 deletions(-) <-- that's after introducing InstanceName() & StoreName() instead of info.Name(), hopefully the review will be rather simple (albeit long) | 12:56 |
| mup | PR snapd#4889 closed: cmd/snap-update-ns: don't trespass on host filesystem <Blocked> <Squash-merge> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4889> | 12:57 |
| mup | PR snapd#4767 opened: interfaces: disconnect hooks <Critical> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767> | 13:00 |
| mup | PR snapd#5254 closed: cmd/snap-update-ns: discard the concept of segments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5254> | 13:31 |
| zyga | jdstrand: thanks, I just opened the 1st batch of error cleanups | 13:32 |
| mup | PR snapd#5272 opened: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <https://github.com/snapcore/snapd/pull/5272> | 13:32 |
| jdstrand | np | 13:32 |
| === tyhicks is now known as Guest86792 | ||
| zyga | https://github.com/snapcore/snapd/pull/5272 is small, green and could land easily :) | 14:02 |
| mup | PR #5272: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <https://github.com/snapcore/snapd/pull/5272> | 14:03 |
| * zyga cleaned up after lunch now | 14:03 | |
| mborzecki | zyga: we should have 'alien' tag for those, small, green.. | 14:03 |
| zyga | hahaha | 14:03 |
| zyga | they are _grey_ | 14:03 |
| zyga | didn't you shoot enough to know ;) | 14:03 |
| zyga | (offtopic, x-com remake was free on GOG yesterday) | 14:04 |
| mborzecki | zyga: yup, got it :P | 14:04 |
| mborzecki | also bought swos, mk123, crusader and pharaoh :) | 14:04 |
| === kyrofa_ is now known as kyrofa | ||
| zyga | oooh man | 14:05 |
| zyga | I don't have time to play any games anymore | 14:05 |
| zyga | I bought one game actually, I hope to try it this weekend | 14:05 |
| * zyga checks | 14:05 | |
| zyga | foxtail | 14:05 |
| zyga | it's a point-and-click game | 14:05 |
| zyga | with lovely hand-pixelated graphics | 14:06 |
| zyga | I'd love to write a game like that one day | 14:06 |
| mborzecki | zyga: heh, don't have much time to play either, treating it as a reminder how games used to be :P hopefully the kids will pick it up and have as much fun as i had | 14:09 |
| Chipaca | popey: 'snap info sudo' | 14:12 |
| popey | wat | 14:12 |
| Chipaca | robert_ancell: https://forum.snapcraft.io/t/spooling-old-changes/5787?u=chipaca | 14:14 |
| mup | PR snapd#5273 opened: testutil: add test support for Fstatfs <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5273> | 14:28 |
| zyga | popey: offtopic, could we ship atom as a snap? | 14:48 |
| zyga | the old text mode adom | 14:48 |
| cachio | niemeyer, about removing linode, we need to fix this https://travis-ci.org/snapcore/spread-cron/builds/388108696#L536 | 14:50 |
| cachio | niemeyer, currently we trigger from a vm the branches by doing git push | 14:50 |
| cachio | niemeyer, then travis run the tests automatically when a change is pushed to a branch | 14:51 |
| cachio | but, seems to be missing the google key for this project | 14:51 |
| cachio | niemeyer, if you have the key I could update all the branches | 14:52 |
| popey | zyga: never heard of it | 14:57 |
| zyga | popey: it's a netback-like game that was very popular in the 90s-00s | 15:01 |
| zyga | nethack* | 15:01 |
| zyga | it's a single elf file that just runs | 15:02 |
| zyga | I wonder if we can package a free but non FOSS game | 15:02 |
| mup | PR snapd#5274 opened: configstate: deny configuration of base snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/5274> | 15:05 |
| mvo | pedronis: in a meeting right now so maybe I don't get this straight, but I wonder if we can simply disable config on snapd as well maybe? and just use "core" everywhere for the config | 15:07 |
| niemeyer | cachio: Ack | 15:11 |
| niemeyer | cachio: Let's sit down together at some point to fix it | 15:11 |
| pedronis | mvo: that's an option (keep only core/system, prohibit bases/snapd), don't know if niemeyer has opinions on that | 15:13 |
| * zyga looks at his PR which failed on econreset | 15:17 | |
| zyga | https://api.travis-ci.org/v3/job/388796612/log.txt | 15:17 |
| mvo | pedronis: it might make things easier at least in the short term because the alias/unalias is a bit simple right now | 15:20 |
| popey | zyga: got a link? | 15:23 |
| zyga | sure, one sec | 15:23 |
| zyga | https://www.adom.de/home/index.html in general | 15:23 |
| zyga | but the specific binary is | 15:23 |
| zyga | https://www.adom.de/home/download/current/adom_linux_ubuntu_64_3.0.6.tar.gz | 15:23 |
| zyga | there's a 32 bit version (for intel) as well | 15:23 |
| zyga | there's a graphical build as well at around 500MB | 15:24 |
| cachio | niemeyer, ok, just ping me when you want | 15:24 |
| cachio | niemeyer, I am trying to reproduce the error on spread | 15:26 |
| cachio | but no luck so far | 15:26 |
| pedronis | mvo: it's fine for me, I think on core18 systems people should really do snap set system | 15:35 |
| mvo | pedronis: +1 | 15:41 |
| mvo | pedronis: I will disable snapd for now and ask for a review from gustavo on this specifically (and address your points too :) | 15:41 |
| === Savicq is now known as Saviq | ||
| roadmr | hey folks! how can I ask snapd to tell me which architecture the current system uses? | 15:44 |
| zyga | hmm | 15:45 |
| roadmr | or should I just use uname --hardware-platform for this? | 15:45 |
| zyga | I don't think you can today | 15:45 |
| zyga | there's some translation we do internally | 15:45 |
| zyga | e.g. amd64 and not x86_64 | 15:45 |
| roadmr | hmm | 15:45 |
| roadmr | at a high level what I want is to help someone determine whether their system is arm64 from snapd's point of view | 15:46 |
| zyga | perhaps we should add "snap debug architecture" | 15:46 |
| zyga | roadmr: just that? | 15:46 |
| zyga | aarch64 => yes | 15:46 |
| roadmr | https://forum.snapcraft.io/t/can-not-install-snap-app/5790 not to be mysterious about it :) I think he's just on arm64 but I asked point blank "what's your arch?" and he didn't seem to parse that | 15:46 |
| zyga | ask for name -a | 15:47 |
| zyga | uname -a | 15:47 |
| roadmr | zyga: ok, I'll go that way then. Not a problem! thanks! | 15:47 |
| Chipaca | mvo: so is --format=... not happening? | 15:58 |
| zyga | Chipaca: can you please do a quick pass over https://github.com/snapcore/snapd/pull/5273 | 16:00 |
| mup | PR #5273: testutil: add test support for Fstatfs <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5273> | 16:00 |
| niemeyer | cachio: The panic should give us a nice clue already.. if you restart the test in Travis, please just make sure to copy the panic elsewhere so we can have a look | 16:04 |
| mvo | Chipaca: it looks like there is some resistance, i.e. snap list | awk can archive the use case. I'm a bit biased because I have grown to like it but in general less code is a plus (even though I think this was a particular nice pr) | 16:05 |
| Saviq | cachio: hey, are you planning to provide ubuntu devel (18.10 today) images in the google project for spread? or are they there already? | 16:05 |
| Chipaca | zyga: i'll try | 16:05 |
| Chipaca | mvo: I like it as well, especially if we implement the current list as just the default format | 16:05 |
| === tyhicks is now known as Guest87080 | ||
| === pstolowski is now known as pstolowski|afk | ||
| cachio | Saviq, we are not planning to provide them | 16:13 |
| cachio | but the ubuntu devel project should have | 16:13 |
| cachio | let me check | 16:14 |
| Saviq | cachio: thanks, we've been using the latest release and `do-release-upgrade -d`, but that stopped working, was wondering if there's something quicker we may do | 16:16 |
| cachio | Saviq, if you run > gcloud compute images list --project ubuntu-os-cloud-devel | 16:17 |
| cachio | Saviq, daily-ubuntu-1804-bionic-v20180531 | 16:18 |
| cachio | I think this is pretty new | 16:18 |
| Saviq | right, so ubuntu-1810 should work | 16:18 |
| Saviq | cachio: how do I reference that in spread.yaml? | 16:18 |
| cachio | you specify a new system, something like ubuntu-18.04-64-daily | 16:19 |
| cachio | and then image: ubuntu-os-cloud-devel/daily-ubuntu-1804-bionic | 16:19 |
| cachio | or ubuntu-os-cloud-devel/daily-ubuntu-1804-bionic-v20180531 | 16:19 |
| cachio | if you don't specify the -vxxxxx | 16:20 |
| cachio | it should take the last one publish | 16:20 |
| Saviq | ah was wondering if the FAMILY field would work | 16:20 |
| Saviq | I'll try things out, thanks! | 16:20 |
| cachio | Saviq, yes | 16:21 |
| cachio | I would work | 16:21 |
| cachio | it is better if you use the family | 16:21 |
| Saviq | ack, thanks! | 16:22 |
| cachio | Saviq, try this ubuntu-os-cloud-devel/ubuntu-1804-lts | 16:22 |
| cachio | if it does not work, please let me know | 16:22 |
| Saviq | will do | 16:23 |
| Saviq | cachio: seems good, thanks! | 16:53 |
| cachio | Saviq, great, just make sure the image allocated is the one you want | 16:54 |
| Saviq | cachio: it's cosmic, that's all I need ;) | 16:54 |
| cachio | Saviq, nice | 16:54 |
| Saviq | it also failed to build, as expected | 16:54 |
| cachio | hehe :) | 16:55 |
| Saviq | popey: you'll probably know, I'm snapping subsurface and missing usb/serial hotplug makes it miss a bunch of functionality - would you say it's a case for classic or devmode until we have hotplug? both have (dis)advantages... | 16:55 |
| popey | Saviq: there's usbraw, which might help? | 17:00 |
| popey | Saviq: i hear usb hotplug is on the list for this cycle - pstolowski|afk is on it | 17:01 |
| Saviq | popey: will that give me access to /dev/ttyUSB0 do you know? | 17:01 |
| Saviq | yeah I know about hotplug... can't get there soon enough ;) | 17:01 |
| popey | Serial interface might | 17:02 |
| Saviq | only gadget | 17:02 |
| popey | Sorry, I don't know any more on that.i am channelling chipaca | 17:03 |
| Saviq | nw, thanks! | 17:03 |
| popey | As we walk to the pub | 17:04 |
| Saviq | enjoy! | 17:05 |
| cachio | niemeyer, https://paste.ubuntu.com/p/73CftWjqdz/ | 17:38 |
| cachio | niemeyer, spread is receiving a 500 | 17:38 |
| niemeyer | cachio: Nice, thanks.. should be easy to fix.. should just be a mishandling of the error in our side | 17:39 |
| kyrofa | niemeyer, build VM meeting now if you're available | 18:04 |
| niemeyer | kyrofa: Hoping calls.. omw | 18:04 |
| jdstrand | mvo: hey, it seems like the shared account's email address has changed to snaps@canonical.com. do you know what this is about? (looking at snap usns) | 18:42 |
| mvo | jdstrand: mostly because its user visible in snap info core | 18:44 |
| mvo | jdstrand: and the old name was a bit long | 18:44 |
| jdstrand | mvo: ok, that's fine. I have some logic to map the shared account email to groups of people depending on the snap name so that, say, the desktop team gets desktop snap usn notifications and the snapd team gets snappy ones | 18:47 |
| jdstrand | mvo: I just need to update that (no biggie, just confirming) | 18:47 |
| * cachio afk | 19:06 | |
| * zyga woke up | 19:14 | |
| zyga | mvo: hey, are you still around? | 19:16 |
| zyga | jdstrand: or you perhaps | 19:38 |
| jdstrand | zyga: what's up? | 19:47 |
| zyga | hey! I was wondering if you could do a small review for error cleanups https://github.com/snapcore/snapd/pull/5272/files | 19:47 |
| mup | PR #5272: cmd/snap-update-ns: improve wording in many errors <Created by zyga> <https://github.com/snapcore/snapd/pull/5272> | 19:47 |
| zyga | the diff is small but there are also three patches that show what's going on with more detail | 19:48 |
| jdstrand | zyga: sure. you don't have to do it now, but fyi PR 5240 has addressed your comments | 19:48 |
| mup | PR #5240: tests: add test to ensure /dev/input/event* for non-joysticks is denied <Created by jdstrand> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5240> | 19:48 |
| jdstrand | sorry | 19:48 |
| * zyga looks | 19:48 | |
| jdstrand | PR 5250 | 19:48 |
| mup | PR #5250: interfaces/udev,misc: only trigger udev events on input subsystem as needed <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5250> | 19:48 |
| jdstrand | zyga: ^ | 19:48 |
| zyga | jdstrand: I did a partial pass over that code now | 19:59 |
| jdstrand | zyga: I'm satisfied for what it aims to do in that it will provide a real benefit to people | 20:05 |
| jdstrand | zyga: I didn't care for having to unconditionally trigger joysticks (it is cheap so not a problem, but don't like it) | 20:06 |
| jdstrand | zyga: for disconnect | 20:06 |
| jdstrand | zyga: not that we should implement it right now, but I was wondering if you had thoughts about callouts to backends on disconnect | 20:07 |
| === pbek_ is now known as pbek | ||
| jdstrand | zyga: the ensure dir concept means we dont usually have to care. but in this one case, it would be nice | 20:08 |
| jdstrand | zyga: we can chat about that tomorrow. I have another small topic to discuss too | 20:21 |
| zyga | jdstrand: mmm, as to the question of callouts to backends on disconnect, no I didn't think about that, currently the code is setup (pun not intended) is that Setup would do the right thing (perhaps at a price). We could arrange it so that a new method Adjust/Amend/Update or similar is available to tweak an existing state. It might (perhaps I'm reading it too shallowly though) also play nicely with composed apparmor profiles later | 20:25 |
| zyga | down the line | 20:25 |
| zyga | jdstrand: yeah, let's chat tomorrow morning your time | 20:25 |
| om26er | popey: hey! is everything ok with the build system now, can we publish axel ? | 20:28 |
| kjackal | Hi people, is the output of the hooks stored somewhere? I have a few print messages, plus I need to be some debugging | 21:28 |
| zyga | kjackal: AFAIR... no | 21:28 |
| zyga | but please ask pstolowski tomorrow | 21:28 |
| zyga | I'm heading to bed so I won't jump into the code to check now, sorry | 21:29 |
| kjackal | thanks zyga goodnight | 21:29 |
| zyga | kjackal: (to be precise, the output is _probably_ stored but discarded unless something errors) | 21:29 |
| kjackal | we do not know where it stored | 21:29 |
| zyga | stored in memory I mean | 21:30 |
| zyga | I doubt it's stored anywhere on disk | 21:30 |
| Odd_Bloke | Is there a way for me to exclude my .tox directory when I `snapcraft cleanbuild`? | 21:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!