| === ssweeny_ is now known as ssweeny | ||
| mup | Issue snapcraft#1466 closed: scriptlets erroring behavior <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1466> | 00:51 |
|---|---|---|
| mup | PR snapcraft#1537 closed: project_loader: aliases are deprecated <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1537> | 00:51 |
| mup | PR snapcraft#1526 closed: catkin plugin: don't assume catkin is in underlay <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1526> | 01:18 |
| mup | PR snapcraft#1525 closed: typo: replace occured with occurred <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1525> | 02:03 |
| === chihchun_afk is now known as chihchun | ||
| === JoshStrobl is now known as JoshStrobl|AFK | ||
| mup | PR core#57 opened: fix typo in 500-create-xdg-wrapper.binary <Created by mvo5> <https://github.com/snapcore/core/pull/57> | 06:31 |
| mup | PR snapd#3904 opened: tests: test the real "xdg-open" from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/3904> | 07:08 |
| mup | PR snapd#3905 opened: tests: add new test that checks that the compat snapd-xdg-open works <Created by mvo5> <https://github.com/snapcore/snapd/pull/3905> | 07:52 |
| mup | PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58> | 08:13 |
| mvo | meh, we are at 26 open PRs again, code reviews for the rescue please! | 08:15 |
| mvo | to the rescue even | 08:15 |
| Chipaca | ouch | 08:17 |
| mvo | 3880 is probably an easy win | 08:17 |
| Chipaca | how's #3777 ? | 08:18 |
| mup | PR #3777: snap-repair: implement basic `snap-repair list` (with --verbose) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3777> | 08:18 |
| mvo | Chipaca: I think I need to address some bits from samuele first | 08:22 |
| === pachulo_ is now known as pachulo | ||
| Chipaca | pstolowski: what's up with #3810 ? | 08:23 |
| mup | PR #3810: interfaces/hooks: PlugData and SlotData wrappers <Created by stolowski> <https://github.com/snapcore/snapd/pull/3810> | 08:23 |
| pstolowski | Chipaca, working on it | 08:24 |
| pstolowski | will push soon | 08:24 |
| Chipaca | pstolowski: thank you for the tweaks to #3852 | 08:29 |
| mup | PR #3852: hooks: commands for controlling own services from snapctl <Created by stolowski> <https://github.com/snapcore/snapd/pull/3852> | 08:29 |
| pstolowski | Chipaca, no, thank YOU! | 08:30 |
| Chipaca | zyga-ubuntu: #3860 had spread failures that looked like network issues; i kicked it off again | 08:30 |
| mup | PR #3860: packaging: don't include any macros in comments <Created by zyga> <https://github.com/snapcore/snapd/pull/3860> | 08:31 |
| zyga-ubuntu | Chipaca: thank you | 08:31 |
| Chipaca | mwhudson: conflicts in #3872 | 08:31 |
| mup | PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872> | 08:31 |
| mwhudson | Chipaca: hooray | 08:32 |
| Chipaca | i wonder if you can use non-ascii chars in env var names | 08:33 |
| zyga-ubuntu | Chipaca: prooobably not want to ;) | 08:33 |
| Chipaca | EINVAL name is NULL, points to a string of length 0, or contains an '=' character. | 08:34 |
| Chipaca | nothing about having bittiness | 08:34 |
| Chipaca | zyga-ubuntu: agreed :-) | 08:34 |
| mup | PR snapd#3906 opened: many: use snapcore/snapd/i18n instead of i18n/dumb <Created by mvo5> <https://github.com/snapcore/snapd/pull/3906> | 08:53 |
| sitter | is there a best practice way of running snapd in an isolated env (docker/vm/lxd)? | 08:56 |
| pedronis | Chipaca: #3890 is an easy one OTOH it seems that always fails spread tests for unrelated reasons :/ | 08:56 |
| mup | PR #3890: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle <Created by pedronis> <https://github.com/snapcore/snapd/pull/3890> | 08:56 |
| Chipaca | pedronis: i just reviewed that one | 08:57 |
| Chipaca | pedronis: :-D | 08:57 |
| Chipaca | it'll probably conflict my PR though | 08:57 |
| * Chipaca thinks the unverse is unfair every time that older PRs get conflicts from newer ones | 08:57 | |
| zyga-ubuntu | Chipaca: universe was never meant to be fair but maybe that's just fair to discover the hard way :) | 08:59 |
| Chipaca | zyga-ubuntu: knowing it is unfair, and being reminded it's unfair, are completely separate | 08:59 |
| pedronis | Chipaca: well, my branch might never land if spread tests continues like that, notice it changes only unit test so apart from that it should affect tests at all | 09:00 |
| pedronis | *not affect | 09:00 |
| mup | PR snapd#3884 closed: store: simplify api url config <Created by atomatt> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3884> | 09:12 |
| mup | PR snapd#3902 closed: tests: try to fix staging tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3902> | 09:15 |
| mup | PR snapd#3897 closed: systemd: do not run auto-import and repair services on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3897> | 09:17 |
| * Chipaca finishes a review pass | 09:22 | |
| * Chipaca thinks he deserves a gold star | 09:22 | |
| * zyga-ubuntu hands Chipaca a gold star | 09:22 | |
| zyga-ubuntu | (insert mario chime) | 09:22 |
| Chipaca | zyga-ubuntu: thank you :-D | 09:23 |
| Chipaca | zyga-ubuntu: also, finish your review of #3835 plz | 09:23 |
| mup | PR #3835: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <https://github.com/snapcore/snapd/pull/3835> | 09:23 |
| mvo | zyga-ubuntu: what is the magic again to clean a mount namespace for a snap? context is https://forum.snapcraft.io/t/xdg-open-regression/2085/5 and I suspect that for him the fix does not work because his core snap is still the older version(?) | 09:28 |
| zyga-ubuntu | mvo: I replied on the forum | 09:44 |
| zyga-ubuntu | mvo: sorry, I saw the forum notification, no notification for irssi here | 09:44 |
| zyga-ubuntu | mvo: are you on gnome shell now? | 09:45 |
| mvo | zyga-ubuntu: not yet but I plan to move my workstation "soon" | 09:47 |
| mvo | zyga-ubuntu: ish :) | 09:47 |
| zyga-ubuntu | I cannot stand the idiotic alt-tab | 09:47 |
| zyga-ubuntu | when I have two apps and dozens of windows open it's useless | 09:48 |
| zyga-ubuntu | browser + terminal, on various workspaces | 09:48 |
| zyga-ubuntu | alt-tab flies me across the workspaces | 09:48 |
| zyga-ubuntu | sigh | 09:48 |
| ogra_ | zyga-ubuntu, you want alt+^ | 09:49 |
| pedronis | my Mock branch failed again, something somewhere doesn't want it in | 09:49 |
| zyga-ubuntu | ogra_: I think gnome shell designers want that | 09:49 |
| ogra_ | well, yes | 09:50 |
| zyga-ubuntu | ogra_: the problem with alt~ is that I now need to differentiate apps and windows | 09:50 |
| zyga-ubuntu | and I much more prefer not to | 09:50 |
| ogra_ | yep, same here | 09:50 |
| zyga-ubuntu | and in fact, I suspect users may not even grok the difference much | 09:50 |
| zyga-ubuntu | "new is shiny" eh :/ | 09:50 |
| ogra_ | i was ranting against that since unity implemented it years ago | 09:50 |
| ogra_ | (unity has a way to switch back to the ld behaviour though ... i dont think gnome-shhell does) | 09:51 |
| ogra_ | *old | 09:51 |
| mvo | zyga-ubuntu: silly question about the discard-ns, should we run htis automatically, i.e. why did this user not get the updated xdg-open without manual work? | 09:55 |
| zyga-ubuntu | mvo: this is https://bugs.launchpad.net/snapd/+bug/1667479 | 09:56 |
| mup | Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:In Progress by zyga> <https://launchpad.net/bugs/1667479> | 09:56 |
| zyga-ubuntu | mvo: I should update that bug | 09:56 |
| zyga-ubuntu | mvo: I'll add a comment shortly | 09:56 |
| zyga-ubuntu | mvo: updated | 10:03 |
| Chipaca | hah! systemd's "job for snapd.service canceled" error in real life! | 10:04 |
| Chipaca | https://launchpadlibrarian.net/336695206/DpkgTerminalLog.txt | 10:04 |
| Chipaca | (from bug#1716641) | 10:04 |
| Chipaca | (from bug 1716641) | 10:04 |
| mup | Bug #1716641: package snapd 2.26.10 failed to install/upgrade: subprocess new pre-removal script returned error exit status 1 <amd64> <apport-package> <xenial> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1716641> | 10:04 |
| mvo | zyga-ubuntu: aha, thank you | 10:04 |
| * mvo hugs Chipaca for all his reviews | 10:05 | |
| * Chipaca hugs mvo back | 10:06 | |
| zyga-ubuntu | Chipaca: i wonder what does that mean in systemd-speak | 10:08 |
| zyga-ubuntu | stop after start but before started? | 10:08 |
| Chipaca | zyga-ubuntu: a daemon-reload hit during a 'stop' | 10:08 |
| zyga-ubuntu | aha | 10:08 |
| Chipaca | zyga-ubuntu: this might be because of our roll-our-own systemd overrides | 10:09 |
| Chipaca | zyga-ubuntu: but it might also be just dh_systemd | 10:09 |
| ogra_ | ondra, https://forum.snapcraft.io/t/sources-of-snap-find-macaddr0/2089 ... why would /run/macaddr0 not be created when the dargonboard runs from eMMC ? (sounds really weird) | 10:15 |
| ondra | ogra_ yeah sounds very strange | 10:18 |
| ogra_ | ondra, can you check this n a board that runs from eMMC ? | 10:26 |
| ogra_ | (i dont want to taint my board here and keep it in original state) | 10:27 |
| ondra | ogra_ just testing some other bits on dragoboard so I can have a look here | 10:30 |
| ogra_ | thanks | 10:30 |
| ogra_ | i wonder if he uses his own kenel snap or so | 10:30 |
| ondra | ogra_ yeah,something looks strange | 10:30 |
| === ShalokShalom_ is now known as ShalokShalom | ||
| * zyga-ubuntu looks outside at the shimmering rain | 10:33 | |
| zyga-ubuntu | Chipaca: can rain shimmer? is that a good way to say this? | 10:38 |
| ogra_ | it surely shimmers if there is enough oil in the drops :P | 10:39 |
| Chipaca | zyga-ubuntu: well, there's a song about it | 10:40 |
| Chipaca | zyga-ubuntu: but it's from final fantasy | 10:40 |
| joc | mvo: hi, do you know if/why there was a rebuild of 2.27.6? | 10:40 |
| mvo | joc: yes, see https://forum.snapcraft.io/t/xdg-open-regression/2085 | 10:42 |
| joc | mvo: ah, thank you | 10:43 |
| ogra_ | (shouldnt really matter for non-desktop ) | 10:46 |
| zyga-ubuntu | Chipaca: I mean it, I'm inclined to learn the rain terminology | 10:52 |
| zyga-ubuntu | and UK is the best place to learn | 10:52 |
| zyga-ubuntu | mvo: do I undestand correctly that we only need a core rebuild and we don't need a new snapd | 10:52 |
| zyga-ubuntu | mvo: regarding the xdg-open regression | 10:53 |
| mvo | zyga-ubuntu: correct, the core change has already happend | 10:53 |
| Chipaca | zyga-ubuntu: well, i've never heard rain described as shimmering, and google also thinks it's a proper name and not just an adjective | 10:54 |
| zyga-ubuntu | Chipaca: how would you describe a rain that falls steadily, with no wind | 10:54 |
| zyga-ubuntu | Chipaca: with rather large but not huge droplets | 10:55 |
| Chipaca | zyga-ubuntu: steady rain? | 10:55 |
| Chipaca | also ps just because i live in the uk doesn't make me rainman | 10:56 |
| Chipaca | :-D | 10:56 |
| mvo | Chipaca: quick sanity check about i18n coming from the client. we would need some sort of context/thread-local-storage per request. so quite a change compared to how we do i18n right now (and how gettext traditionally does it). or do you have an idea about something smart we could do? | 10:58 |
| Chipaca | mvo: we're needing a context for other things, but yes | 10:59 |
| Chipaca | it's not a minor change | 10:59 |
| === chihchun is now known as chihchun_afk | ||
| mvo | Chipaca: it looks like a gigant change right now but maybe I'm missing something. every place that calls i18n.G() would have to have access to this context | 11:00 |
| Chipaca | mvo: in my minid at least it's part of the same refactor of daemon to get rid of gorilla | 11:01 |
| Chipaca | yes, major | 11:01 |
| Chipaca | 'have a daemon2 package and transition things' major | 11:01 |
| mvo | Chipaca: but it would be more, no? i mean, we would have to pass the context even into e.g. snapstate.Install() and similar? as those generate i18n.G() messages? | 11:02 |
| zyga-ubuntu | Chipaca: "rainman" sounds like a nice song title | 11:02 |
| mvo | Chipaca: don't get me wrong, not asking how it could be done, just if I have a thinko somewhere | 11:04 |
| Chipaca | mvo: everything needs a context | 11:05 |
| mvo | Chipaca: ok, thanks | 11:05 |
| itsfemme[m] | I tried to install the edge core snap and got the following error: - Setup snap "core" (2894) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": fork/exec /usr/lib/snapd/snap-update-ns: no such file or directory) | 11:10 |
| itsfemme[m] | cmd.go:140: exe doesn't have snap mount dir prefix: "/usr/lib/snapd/snapd" vs "/snap" and handlers.go:208: Reported install problem for "core" as 95e9cec8-97a9-11e7-9958-fa163e192766 OOPSID | 11:15 |
| itsfemme[m] | are the only things I found from journalctl | 11:15 |
| zyga-ubuntu | itsfemme[m]: hey, can you tell me which distribution are you on | 11:17 |
| itsfemme[m] | subgraph os, which is a derivative of debian stretch | 11:18 |
| mup | PR snapd#3907 opened: cmd/snapctl: allow snapctl -h without a context (regression fix) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3907> | 11:18 |
| zyga-ubuntu | itsfemme[m]: does subgraph os rebuild packages from source? | 11:20 |
| zyga-ubuntu | itsfemme[m]: personally, would you mind contriuting to http://github.com/zyga/os-release-zoo | 11:20 |
| zyga-ubuntu | itsfemme[m]: can you show me the source package of snapd from subgraph os? it looks curious | 11:20 |
| mvo | Chipaca: a (slightly) crazy idea https://github.com/mvo5/snappy/commit/029f38be38ff9c634cb21d10e30ff6dba094ca34 | 11:21 |
| itsfemme[m] | Not all packages, it uses the debian repo with its own repo for kernels and additional apps | 11:21 |
| * mvo lunches | 11:21 | |
| zyga-ubuntu | itsfemme[m]: is snapd rebuild or reused? | 11:21 |
| itsfemme[m] | reused | 11:22 |
| zyga-ubuntu | itsfemme[m]: which version do you have in the package? | 11:22 |
| itsfemme[m] | this is the repo https://devrepo.subgraph.com/subgraph/ | 11:23 |
| * itsfemme[m] sent a long message: itsfemme[m]_2017-09-12_11:23:59.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/PxsNVKydOHgxYYkZgVpJKhQS> | 11:24 | |
| itsfemme[m] | I have PaX (from grsecurity) enabled but I didn't see anything from that in journalctl | 11:25 |
| zyga-ubuntu | interesting | 11:27 |
| zyga-ubuntu | so snapd restarted into 2.27.6 | 11:27 |
| zyga-ubuntu | but snap (the client) did not | 11:27 |
| pedronis | what does snap restarting means? | 11:27 |
| zyga-ubuntu | pedronis: I mean re-exec | 11:27 |
| zyga-ubuntu | itsfemme[m]: for now, can you please open a forum topic | 11:28 |
| pedronis | that's a super confusing way to call that :) | 11:28 |
| zyga-ubuntu | itsfemme[m]: this will be eaier to track | 11:28 |
| zyga-ubuntu | pedronis: sorry, I didn't mean that | 11:28 |
| zyga-ubuntu | itsfemme[m]: I guess someone should try subgraph and see what's going on | 11:28 |
| * ogra_ wouldnt be surprised if gsecurity patches had influence on seccomp, apparmor and cgroups behaviour | 11:28 | |
| zyga-ubuntu | yes, that's possible | 11:29 |
| itsfemme[m] | I mean I use all those things daily | 11:29 |
| ogra_ | (sadly its is closed source so you wont easily find out :P ) | 11:29 |
| zyga-ubuntu | itsfemme[m]: what's the kernel version you are on? | 11:29 |
| itsfemme[m] | it's not closed source you can go to the repo and get the kernel source | 11:29 |
| itsfemme[m] | 4.9.33-subgraph | 11:30 |
| zyga-ubuntu | thank you | 11:31 |
| itsfemme[m] | But as I said, I use apparmor, namespaces and seccomp to sandbox my daily applications so I know those work | 11:32 |
| zyga-ubuntu | itsfemme[m]: thank you for the report, I'm pulling the release to see how it looks like | 11:36 |
| zyga-ubuntu | itsfemme[m]: I would appreciate if you could open a thread on the snapcraft forum | 11:37 |
| zyga-ubuntu | I will also check out debian stable and sid to see if this affects the parent | 11:37 |
| ogra_ | itsfemme[m], i thought the current source is only available against money (only a subset is public) ? | 11:39 |
| * ogra_ only knows what he read in linus rants about GPL violations actually ... ICBW for sure :) | 11:41 | |
| ogra_ | it would definitely be good to make sure it all works though (regardless of licenses, politics or rants :) )... | 11:43 |
| Chipaca | mvo: I don't think we can use gls for this; there is AFAIK no connection between a request and the goroutine the handlers run on | 11:46 |
| * Chipaca ~> lunch | 11:46 | |
| pedronis | mvo: I'm not sure I want to look what gls does | 11:49 |
| pedronis | mvo: what's the inpulse to work on those? gnome software? | 11:50 |
| Chipaca | mvo: also: Accept-Language is the header to use :-) | 11:50 |
| Chipaca | pedronis: the i18n pr up right now | 11:50 |
| Chipaca | pedronis: snapd#3906 | 11:51 |
| mup | PR #3906: many: use snapcore/snapd/i18n instead of i18n/dumb <Created by mvo5> <https://github.com/snapcore/snapd/pull/3906> | 11:51 |
| * Chipaca ~> really lunch | 11:51 | |
| pedronis | Chipaca: sounds like a huge distraction to me right now | 11:51 |
| pedronis | even worse if instead of that we make a hackish exercise | 11:52 |
| pedronis | Chipaca: given we have async stuff and global bits it's all a bit unclear how this should be properly designed | 11:54 |
| pedronis | Chipaca: there's a lot going in snapd that is not tied to a request, or only indirectly, or could be potentially visited from different locales (think snap changes) | 11:55 |
| mup | PR snapd#3890 closed: overlord: use overlord.Mock in more tests, make sure we check the outcome of Settle <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3890> | 11:59 |
| mvo | pedronis: yeah, not saying we should do any of this gls stuff, just thinking aloud as it seems to be a bit difficult right now to get a handle on this per-connection i18n | 12:25 |
| zyga-ubuntu | mvo: I'd vote for explicit, context-based i18n since traditional approach to implicit (thread local state) is harder in go | 12:26 |
| zyga-ubuntu | Found unused ./vendor packages: | 12:26 |
| zyga-ubuntu | vu github.com/mvo5/net/bpf | 12:26 |
| mvo | zyga-ubuntu: yes, update your vendor dir, thats fine | 12:27 |
| pedronis | mvo: as I said I feart apart the tech expect, there are interesting conceptual questions if we start having per request i18n | 12:27 |
| pedronis | it's probably weeks of work to get that right | 12:27 |
| mvo | pedronis: yes | 12:27 |
| mvo | zyga-ubuntu: re context-based i18n> seems like everyone agrees with this | 12:28 |
| mvo | anyway, I won't persuse this, it was just a short explore round | 12:28 |
| pedronis | mvo: its seems we would need to do i18n very close to where we build the response | 12:28 |
| pedronis | not all over the place as we do now | 12:29 |
| mup | PR snapcraft#1523 closed: node plugin: record installed node packages in manifest <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1523> | 12:29 |
| zyga-ubuntu | pedronis: yes | 12:29 |
| zyga-ubuntu | pedronis: or pass the context deeply everywhere which seems insane-ish | 12:29 |
| pedronis | that doesn't help | 12:29 |
| pedronis | some strings have not direct request | 12:29 |
| mvo | pedronis: right, which is tricky once you have format strings in the i18n, e.g. something in snapstate: fmt.Errorf(i18n.G("cannot install %q snap"), snapName) | 12:29 |
| pedronis | like all the stuff in changes | 12:30 |
| zyga-ubuntu | pedronis: yes, I agree | 12:30 |
| pedronis | and tasks | 12:30 |
| pedronis | mvo: we would need complex ways to pass strings around | 12:30 |
| pedronis | as I said | 12:30 |
| pedronis | weeks of work | 12:30 |
| mvo | pedronis: yes | 12:30 |
| mvo | pedronis: we are in agreement :) | 12:30 |
| zyga-ubuntu | I wonder if we can start with some common problems and come up with a cheaper solution for that | 12:30 |
| zyga-ubuntu | so _some_ errors could get context-sensitive i18n | 12:30 |
| pedronis | we need to mark them but translate them late | 12:30 |
| zyga-ubuntu | but not all | 12:30 |
| zyga-ubuntu | N_(...) | 12:31 |
| pedronis | and keep the info of what needs translating | 12:31 |
| pedronis | etc etc | 12:31 |
| zyga-ubuntu | pedronis: and also store interpolation | 12:31 |
| pedronis | yes | 12:31 |
| pedronis | lots of fun | 12:31 |
| pedronis | seems a bit the wrong time to dive into that | 12:31 |
| pedronis | too much other stuff | 12:31 |
| mvo | +1 | 12:31 |
| zyga-ubuntu | yes | 12:31 |
| zyga-ubuntu | I agree | 12:32 |
| mvo | speaking of other stuff> arm/armhf/powerpc fail to build in master right now :/ | 12:32 |
| zyga-ubuntu | unless someone external goes to explore and then works on this exclusively without breaking everything for a while | 12:32 |
| zyga-ubuntu | mvo: fun | 12:32 |
| Son_Goku | mvo: wut? | 12:32 |
| pedronis | "fun" | 12:32 |
| zyga-ubuntu | mvo: let's raise a glass to unpopular architectures | 12:33 |
| pedronis | at least I could merge my Mock branch, I think I had to retry 5+ times (or more, I really don't remember) | 12:33 |
| ikey | lol "unpopular" | 12:33 |
| zyga-ubuntu | ikey: heh | 12:33 |
| zyga-ubuntu | ikey: good to see you | 12:33 |
| ikey | ta, you too | 12:33 |
| pedronis | it's all relative | 12:33 |
| zyga-ubuntu | ikey: I've installed solus and I loved the experience :) | 12:33 |
| zyga-ubuntu | ikey: I played with the build tools a little | 12:33 |
| ikey | oh im so sorry | 12:33 |
| ikey | xD | 12:33 |
| zyga-ubuntu | ikey: but I could not find the snapd package (I cloned everything using the helper make) | 12:34 |
| mvo | cachio: hey, can I get commit access to spread-cron please :) | 12:34 |
| zyga-ubuntu | ikey: I wanted to help with co-maintenance | 12:34 |
| ikey | oh you legend | 12:34 |
| zyga-ubuntu | ikey: and to update snapd to 2.27.6 | 12:34 |
| ikey | https://dev.solus-project.com/source/snapd/ | 12:34 |
| ikey | everything is nested on our dev portal | 12:34 |
| ikey | the "main" file is https://dev.solus-project.com/source/snapd/browse/master/package.yml | 12:35 |
| ikey | its basically bash script decorated with sexy yaml | 12:35 |
| ikey | omg zygaception | 12:35 |
| zyga-ubuntu | ikey: should this have been cloned by make pull? | 12:35 |
| ikey | uhm so the "make pull" thing relies on the old common/packages notion | 12:36 |
| Son_Goku | you can clearly see the pisi influence :) | 12:36 |
| zyga-ubuntu | ah | 12:36 |
| zyga-ubuntu | :) | 12:36 |
| ikey | no you can't Son_Goku | 12:36 |
| zyga-ubuntu | some stale docs I ran into then | 12:36 |
| ikey | pisi is XML. | 12:36 |
| zyga-ubuntu | what is pisi | 12:36 |
| Son_Goku | the changelog is still in pisi format :) | 12:36 |
| ikey | eopkg is forked from pisi | 12:36 |
| ikey | Son_Goku, what? | 12:36 |
| ikey | what changelog..? | 12:36 |
| ikey | zyga-ubuntu, pisi is what eopkg is forked from | 12:36 |
| Son_Goku | err, pspec | 12:36 |
| Son_Goku | pspec_x86_64.xml | 12:36 |
| ikey | thats automatically generated for introspection | 12:36 |
| ikey | its not actually used by the build | 12:37 |
| ikey | ypkg emits the eopkg itself | 12:37 |
| Son_Goku | ah, so you're not writing it :) | 12:37 |
| ikey | in the old days we used to rely on the machine files | 12:37 |
| ikey | oh god no | 12:37 |
| Son_Goku | haha | 12:37 |
| ikey | ypkg was to get us away from that old crap | 12:37 |
| * Son_Goku remembers rpmxmlbuild | 12:37 | |
| ikey | and make packaging sane | 12:37 |
| zyga-ubuntu | ikey: got it | 12:37 |
| ikey | zyga-ubuntu, so yeah we infra-changed and some things broke ™ | 12:37 |
| Son_Goku | ikey, there was a point where rpm spec files could be written as XML :P | 12:37 |
| ikey | Son_Goku, intentionally?! | 12:38 |
| zyga-ubuntu | ikey: how do I send patches to that packaging? | 12:38 |
| Son_Goku | yep, back in the early rpm 4.0.x ~ 4.3.x days | 12:38 |
| ikey | zyga-ubuntu, you're gonna want to install "arcanist" | 12:38 |
| Son_Goku | jbj implemented it to make people back off about wanting a schema for rpm spec | 12:38 |
| ikey | https://solus-project.com/articles/packaging/submitting-a-package/en/ | 12:38 |
| ikey | see the arcanist links down below | 12:39 |
| ikey | basically you mangle and alter your clone of our repo | 12:39 |
| ikey | get your commit in order | 12:39 |
| ikey | and send it with "arc diff" (once arc is setup) | 12:39 |
| ikey | then it creates a new patch against snapd in our infra | 12:39 |
| Son_Goku | ikey: probably the next go around, there will be an rpmyamlbuild :) | 12:39 |
| ikey | Son_Goku, yeah yaml is "so hot right now" :P | 12:39 |
| cachio | mvo, let me check | 12:39 |
| zyga-ubuntu | ikey: I'll try | 12:39 |
| ikey | you gotta have a dev site account fwiw | 12:40 |
| * zyga-ubuntu needs to clean his desk | 12:40 | |
| ikey | you can log in with github anyway | 12:40 |
| zyga-ubuntu | ikey: how do I get that? | 12:40 |
| Son_Goku | ikey: someone is already working on making rpm output yaml in addition to xml | 12:40 |
| zyga-ubuntu | ah | 12:40 |
| zyga-ubuntu | I did log in | 12:40 |
| ikey | saves farting about | 12:40 |
| ikey | ok so do the "Setting up Arcanist bit" | 12:40 |
| ikey | er. misquoting but ya | 12:40 |
| ikey | basically it sets up arcanist globally for the solus instance | 12:40 |
| ikey | fwiw if you have a proper checkout with $dir/common $dir/snapd, etc, you can do "make" to actually build the package | 12:41 |
| ikey | i assume you've got solbuild setup at this point? | 12:41 |
| ikey | (because it wouldn't be solus without a shedload of badly named tools.) | 12:41 |
| zyga-ubuntu | ikey: I do | 12:42 |
| ikey | suhweet | 12:42 |
| ikey | you can `sudo solbuild update -p unstable-x86_64` to keep the base image updated fwiw | 12:42 |
| ikey | makes subsequent builds faster | 12:42 |
| ikey | (if you install `solbuild-config-unstable` you can skip the -p parameter nonsense) | 12:43 |
| ikey | always amazes me that solus users have never questioned why i opted to include the architecture field in everything for an x86_64 distro | 12:43 |
| ogra_ | mvo, seriously, kill powerpc ... we never supported it, you cant even build snaps for it so it is totally pointless to have it | 12:44 |
| ogra_ | there is so much time and energy wasted on it ... | 12:45 |
| zyga-solus | ikey: hmm, what did I do wrong? zyga@lambert ~/packaging/snapd $ make | 12:46 |
| zyga-solus | make build | 12:46 |
| zyga-solus | make[1]: Entering directory '/home/zyga/packaging/snapd' | 12:46 |
| zyga-solus | sudo solbuild build package.yml -p unstable-x86_64; | 12:46 |
| zyga-solus | Profile is not installed: Did you forget to init? | 12:46 |
| zyga-solus | make[1]: Leaving directory '/home/zyga/packaging/snapd' | 12:46 |
| zyga-solus | make abireport | 12:46 |
| zyga-solus | make[1]: Entering directory '/home/zyga/packaging/snapd' | 12:46 |
| zyga-solus | abireport -p abi_ -D `dirname package.yml` scan-packages `dirname package.yml` | 12:46 |
| zyga-solus | Error locating packages: No packages in directory . | 12:46 |
| zyga-solus | make[1]: *** [../Makefile.common:15: abireport] Error 1 | 12:46 |
| cachio | mvo, I think niemeyer can give you permissions | 12:46 |
| zyga-solus | make[1]: Leaving directory '/home/zyga/packaging/snapd' | 12:46 |
| zyga-solus | make: *** [../Makefile.common:12: complete] Error 2 | 12:46 |
| zyga-solus | oh, darn, sorry, hexchat doesn't auto-pastebin | 12:46 |
| mvo | cachio: ok, if you could merge my PR on spread-cron, that would be great | 12:47 |
| mvo | pedronis: does http://paste.ubuntu.com/25520782/ ring any bell(s)? its the failure on arm/arm64 | 12:48 |
| mup | PR snapd#3860 closed: packaging: don't include any macros in comments <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3860> | 12:48 |
| cachio | mvo, done | 12:48 |
| mvo | cachio: \o/ | 12:48 |
| mvo | cachio: I trigger a test run now | 12:48 |
| * zyga-ubuntu needs to clean his desk *really* | 12:48 | |
| zyga-ubuntu | omg, fedora mail storm :) | 12:48 |
| pedronis | mvo: no, seems weird | 12:49 |
| mvo | pedronis: yeah, also why just arm? probably some race but looks very strange, I see if I can reproduce it | 12:49 |
| ikey | zyga-ubuntu, sorry had to run downstairs | 12:49 |
| zyga-ubuntu | ikey: no worries | 12:49 |
| pedronis | mvo: doesn't seem like a race, more an issue with mocking hooks | 12:49 |
| ikey | zyga-ubuntu, did you init unstable? | 12:49 |
| ikey | unstable and main correlate to the two main solus repos | 12:50 |
| zyga-ubuntu | ikey: ... I think I don't know | 12:50 |
| ikey | typically package developers target unstable, as we don't explicitly build for main | 12:50 |
| ikey | alright well, easiest way to do this | 12:50 |
| mvo | pedronis: I wonder why its just manifesting itself on arm (this is why I suspected a race) | 12:50 |
| ikey | sudo eopkg it solbuild-config-unstable | 12:50 |
| ikey | sudo solbuild init -u | 12:50 |
| zyga-ubuntu | initializing | 12:50 |
| ikey | that'll initialise solbuild and update the base image | 12:51 |
| ikey | solbuild-config-unstable installs a global config file that pins you to unstable by default | 12:51 |
| ikey | (in /usr/share because /etc is wrong. :P) | 12:51 |
| pedronis | mvo: that stuff should be determinstic | 12:51 |
| zyga-ubuntu | ikey: writable /usr/share? curious | 12:51 |
| ikey | nope, read-only | 12:51 |
| ikey | we use layered configuration | 12:51 |
| ikey | https://github.com/solus-project/solbuild/blob/master/src/builder/config.go#L34 | 12:52 |
| ikey | /etc/solbuild takes precedence | 12:52 |
| mvo | pedronis: yeah, I'm trying this on my pi now | 12:52 |
| ikey | we have image + profile definitions | 12:52 |
| pedronis | mvo: ah, those tests don't check chg.Err, you probably need to start there | 12:52 |
| mvo | pedronis: aha! | 12:52 |
| pedronis | sorry | 12:52 |
| pedronis | they do | 12:52 |
| pedronis | but don't check ready | 12:53 |
| ikey | zyga-ubuntu, basically at solus we're weird and very opinionated about how to build a distro. :p | 12:53 |
| pedronis | mvo: not sure what is going on there | 12:53 |
| zyga-ubuntu | ikey: I think you just described snapd project :) | 12:53 |
| ikey | :D | 12:53 |
| zyga-ubuntu | ikey: we're also opinionated and some people find some things weird | 12:54 |
| ikey | good architecture usually is | 12:54 |
| zyga-ubuntu | ikey: ok, now it works! | 12:54 |
| ikey | and it has to be opinionated to be enforced | 12:54 |
| ikey | suhweet | 12:54 |
| ikey | so do you have common/ setup? | 12:54 |
| zyga-ubuntu | yes | 12:54 |
| ikey | with the symlinks and such | 12:54 |
| zyga-ubuntu | well | 12:54 |
| zyga-ubuntu | make works | 12:54 |
| ikey | if you step into snapd directory, a simple "make" should suffice | 12:54 |
| zyga-ubuntu | and I see a few symlinks for makefiles | 12:54 |
| zyga-ubuntu | yes, | 12:54 |
| zyga-ubuntu | I think I'm good now | 12:54 |
| ikey | if make works and it spits out eopkgs, you're golden | 12:54 |
| zyga-ubuntu | I'll let it build cleanly | 12:55 |
| zyga-ubuntu | then do my changes | 12:55 |
| ikey | aye | 12:55 |
| zyga-ubuntu | and then bug you to figure out how to send that :) | 12:55 |
| ikey | in solus the release number is more important than the version number | 12:55 |
| ikey | its the thing we actually track and says "this is an update" | 12:55 |
| zyga-ubuntu | ikey: ahhh | 12:55 |
| zyga-ubuntu | ikey: so like snap revision | 12:55 |
| ikey | (Even if its a downgrade) | 12:55 |
| ikey | right | 12:55 |
| zyga-ubuntu | ikey: so I should not reset it after changing version? | 12:55 |
| ikey | so all updates include a relno bump | 12:55 |
| zyga-ubuntu | ikey: interesting :) | 12:55 |
| ikey | nah bump by 1 | 12:55 |
| zyga-ubuntu | ack, will do | 12:55 |
| ikey | numbers are free so .. yknow. :) | 12:55 |
| mvo | pedronis: no worries, thanks, I try to reproduce now on my pi | 12:56 |
| zyga-ubuntu | yes, and much nicer and simpler conceptually than debian -~4-fork5 | 12:56 |
| ikey | you also have "make clean" to nuke the local eopkgs, just because | 12:56 |
| ikey | right | 12:56 |
| ikey | we didn't want epochs and such | 12:56 |
| zyga-ubuntu | ikey: and revisions are nice because versions can match upstream | 12:56 |
| ikey | exactly | 12:56 |
| zyga-ubuntu | build completed | 12:56 |
| ikey | well, fwiw eopkg having pisi heritage has some gimped notion of version fields | 12:56 |
| zyga-ubuntu | ok, let's just bump the release and the version | 12:56 |
| zyga-ubuntu | and see what happens | 12:57 |
| ikey | in that it tries to be clever and interpret them | 12:57 |
| ikey | when we replace it with 'sol', we'll make it not care what the version field means | 12:57 |
| zyga-ubuntu | ikey: after building I have a changed tree | 12:57 |
| ikey | right, pspec changed | 12:57 |
| ikey | thats fine | 12:57 |
| pedronis | mvo: ah, it might just be too slow | 12:57 |
| zyga-ubuntu | the xml changed | 12:57 |
| ikey | you see what i mean about pspec being machine generated | 12:57 |
| zyga-ubuntu | ikey: shall I commit or ignore | 12:57 |
| pedronis | mvo: I just merged checking for Settle error | 12:57 |
| ikey | just ignore it | 12:57 |
| ikey | in your final change you include your pspec diff | 12:57 |
| mvo | pedronis: oh, that sounds reasonable | 12:57 |
| ikey | as its the build record | 12:57 |
| ikey | its generated on the fly, its not sourced | 12:57 |
| zyga-ubuntu | ok | 12:57 |
| pedronis | mvo: I don't know if with master you mean with my last landing or not | 12:58 |
| ikey | it includes basic stuff to indicate the subpackages and file layout | 12:58 |
| ikey | that way we can quickly glance to make sure its half sane | 12:58 |
| mvo | pedronis: master as of ~1h or so ago | 12:58 |
| mvo | pedronis: but let me double check, the builds are always a bit delayed | 12:58 |
| pedronis | I merged it around there | 12:58 |
| pedronis | but from the failure mode | 12:59 |
| ikey | zyga-ubuntu, fwiw ypkg/solbuild does support git builds but snapd repo is set up odd without git submodules | 12:59 |
| pedronis | it probably doesn't have that code yet | 12:59 |
| ikey | so you'd need to set `networking: yes` to bypass some of the confinement we set | 12:59 |
| ikey | (we nuke networking in solbuild) | 12:59 |
| ikey | it really is a glorified container at this point.. | 12:59 |
| * zyga-solus goes for the daily standup | 12:59 | |
| zyga-solus | ikey: what's the hash in packaging? | 13:06 |
| ikey | sha256sum | 13:06 |
| ikey | if you're using git sources its the commit or branch | 13:06 |
| zyga-solus | yep | 13:06 |
| ikey | i.e. git|someSource/.git : commit | 13:07 |
| ikey | i typically look at git show in head and take the tip commit | 13:07 |
| zyga-solus | ok, building with 2.27.6 | 13:07 |
| ikey | gl! | 13:07 |
| zyga-solus | ikey: is it typical to run tests during the build | 13:08 |
| ikey | so i mean if you *want* to run tests, you can | 13:08 |
| ikey | you can just nuke it | 13:08 |
| ikey | and run tests yourself | 13:08 |
| ikey | its not always appropriate for a make check | 13:08 |
| ikey | (and solbuild lacks x11/dbus isolation atm) | 13:08 |
| zyga-solus | ok | 13:08 |
| zyga-solus | I'll try locally | 13:08 |
| ikey | we're doing those in the next major version so we can have PGO on x11 apps | 13:09 |
| ikey | like firefox ^^ | 13:09 |
| pedronis | this is a weird failure mode: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170912_124213_dfd96@/log.gz | 13:09 |
| pedronis | a panic with fatal error: runtime: address space conflict | 13:09 |
| * ikey takes `unsafe` away from golang | 13:10 | |
| zyga-solus | Sep 12 11:50:55 autopkgtest snapd[6307]: runtime: address space conflict: map(0xc820100000) = 0x7f01da1d7000 | 13:10 |
| zyga-solus | Sep 12 11:50:55 autopkgtest snapd[6307]: fatal error: runtime: address space conflict | 13:10 |
| zyga-solus | woah | 13:10 |
| === JoshStrobl|AFK is now known as JoshStrobl | ||
| greyback | ogra_: hey, were you playing with the vc4 driver on the rpi3 recently? I'm seeing rendering failures with Qt and GL, Qt is unable to allocate its atlas texture, breaking all images | 13:42 |
| ogra_ | greyback, nope, havent touched it ... | 13:43 |
| greyback | ogra_: ok. I'll see what I can figure out so. thanks! | 13:43 |
| ogra_ | greyback, ppisati recently added a fix to make /dev/fb0 work again (some malloc stuff afaik) ... perhaps that has some influence ? | 13:44 |
| pedronis | mvo: zyga-solus: that panic is interesting, not sure it something we control though | 13:44 |
| greyback | ogra_: hmm I'll keep that in mind. I don't see how that would impact it, but I've been surprised before | 13:45 |
| ogra_ | right | 13:45 |
| ogra_ | i wouldnt expect it to break anything either | 13:45 |
| === JanC_ is now known as JanC | ||
| cachio | mvo, have you ever seen this error https://travis-ci.org/snapcore/spread-cron/builds/274589912?utm_source=email&utm_medium=notification ? | 13:55 |
| mvo | cachio: I saw it but can't make sense of it, I think my other PR needs to be revert :/ I prepare a PR | 14:06 |
| cachio | mvo, ok | 14:09 |
| mvo | cachio: I opened a revert PR for this | 14:10 |
| ackk | hi, if I run "go test github.com/snapcore/snapd/cmd/snap-seccomp" in snapd master, tests seem to hang, any idea what could it be? | 14:15 |
| mvo | ackk: they are slow for me (~15sec on a fast machine). you can try "go test -check.vv github.com/snapcore/snapd/cmd/snap-seccomp" | 14:16 |
| mvo | ackk: that should give you some idea where its slow at least | 14:16 |
| mvo | ackk: what is your hardware? | 14:16 |
| ackk | mvo: can't load package: package github.com/snapcore/snapd: no buildable Go source files in /home/ack/go/src/github.com/snapcore/snapd | 14:17 |
| mvo | pedronis: 3893 looks ready (spread is green) | 14:17 |
| ackk | mvo, Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz | 14:17 |
| ackk | mvo, if I run the full suite tests pass, but running this package alone seems to hang | 14:18 |
| mvo | ackk: heh, that is a fast machine, it really should not hang, strange | 14:18 |
| mvo | ackk: aha, let me try this | 14:18 |
| * zyga-ubuntu -> tea | 14:20 | |
| ackk | mvo, do tests require a minimum kernel version (thinking about seccomp/apparmor stuff)? | 14:21 |
| cachio | mvo, when you have a minute, please could you take a look to this one | 14:21 |
| cachio | https://github.com/snapcore/spread-cron/pull/43 | 14:21 |
| mup | PR spread-cron#43: Skip manual branches <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/43> | 14:21 |
| mvo | ackk: maybe, what is puzzling is that you say that the test works when you run it as part of the entire unit tests of snapd but not when run in isolation | 14:22 |
| mvo | cachio: sure | 14:22 |
| ackk | mvo, the whole suite takes a lot of time, though | 14:22 |
| mvo | ackk: yes, no disputing this :) I'm just confused that it works there but not when run in isolation and scratching my head what might be causing this | 14:23 |
| mvo | ackk: if you "cd $GOPATH/src/github.com/snapcore/snap/cmd/snap-seccmp && go test", does that work? | 14:23 |
| * ackk tries | 14:23 | |
| mvo | ackk: and curious, are you hunting a bug in this package? anything not working for you? | 14:24 |
| ackk | mvo, i'm on go 1.6.3 if that matters | 14:24 |
| mvo | ackk: that should be ok. anything unusual about your kernel/libc/seccomp version maybe? | 14:24 |
| ackk | mvo, no, I was running tests in a brnach of mine (for adding socket activation support), tests were hanging and eventually timing out, so I was trying to get a baseline on master | 14:25 |
| ackk | mvo, I'm on yakkety, nothing special | 14:25 |
| mvo | ackk: hm, indeed, sounds all quite normal | 14:25 |
| mvo | ackk: so generally speaking this should work, so lets try to figure out why its not in your case :) - does it make a difference if you run"cd $GOPATH/src/github.com/snapcore/snap/cmd/snap-seccmp && go test" ?: | 14:26 |
| ackk | mvo, still runnning, but I suspect it's stuck | 14:26 |
| ackk | mvo, strace tells me it's stuck on a FUTEX_WAIT | 14:27 |
| ackk | weird | 14:27 |
| ackk | mvo, so, no, no change | 14:27 |
| mvo | ackk: what does "go test -check.vv" tell you now? it should print each test | 14:28 |
| mup | PR snapcraft#1546 opened: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546> | 14:29 |
| ondra | ogra_ dragonboard booting from emmc and I have there /run/macaddr0 | 14:29 |
| ackk | mvo, running, but I see some "cannot use non-native in runBpfInKernel" messages | 14:30 |
| ackk | not sure if they're relevant | 14:30 |
| mvo | ackk: thats harmless | 14:30 |
| mvo | ackk: and reminds me that I should fix those :/ thanks, I will do that in a wee bit | 14:30 |
| ackk | mvo, it's still running fwiw | 14:30 |
| mvo | ackk: can you see the last START? | 14:31 |
| mvo | ackk: i.e. in which of the tests is it hanging? | 14:31 |
| mup | PR core#57 closed: fix typo in 500-create-xdg-wrapper.binary <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/57> | 14:31 |
| ackk | mvo, snapSeccompSuite.TestRestrictionsWorkingArgsPrctl is the last one | 14:31 |
| ackk | it seems stuck there | 14:31 |
| mvo | ackk: ohh, interessting, let me look | 14:31 |
| ackk | mvo, oh, it just moved on, but 93s on that one | 14:31 |
| mvo | ackk: geeeh, that is a long time | 14:32 |
| mvo | ackk: this is master, right? I mean, its (reasonable) up-to-date with master? | 14:32 |
| ackk | mvo, yeah, I updated 2hrs ago tops | 14:33 |
| mvo | ackk: that should be fine | 14:33 |
| * mvo scratches head | 14:33 | |
| ackk | mvo, is snapd secretly written in enteprise java? :) | 14:33 |
| mvo | ackk: *cough* | 14:33 |
| mvo | ackk: lalallaa | 14:33 |
| mvo | ackk: ;) | 14:33 |
| ackk | :) | 14:33 |
| mvo | ackk: so these tests do a lot of fork/exec, the way it works is that it creates a small C helper that runs all our syscalls that we care about in sandboxes to ensure the code that generates the sandboxes works correctly. so its expensive but on your HW it should really not take so long | 14:34 |
| mvo | ackk: btw, socket activation support sounds awesome! | 14:35 |
| mup | PR snapd#3893 closed: many: introduce asserts.NotFoundError replacing both ErrNotFound and store.AssertionNotFoundError <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3893> | 14:35 |
| ackk | mvo, the problem seems locking-related, cpu is free | 14:35 |
| ackk | mvo, yeah I hope to be done soon with at least the basic stuff | 14:36 |
| mvo | cachio: https://github.com/snapcore/spread-cron/pull/43 has my +1, I can't merge currently. but if niemeyer gives me write access to the spread-cron repo I can do it | 14:36 |
| mup | PR spread-cron#43: Skip manual branches <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/43> | 14:36 |
| niemeyer | mvo: on it | 14:36 |
| pedronis | mvo: thanks, merged | 14:37 |
| mvo | ackk: strange that the cpu is idle, there are no locks in these tests, its just running a bunch of binaries (and producing the right seccomp confinement). very puzzling. still hanging? I can give you a diff that springles some debug prints so that at least we get some idea what is doing on, i.e. if compile of the seccomp code is slow or if execution is slow etc | 14:38 |
| jdstrand | mvo: fyi, https://dashboard.snapcraft.io/dev/snaps/6021/rev/2902/ got hung up so I requested to rerun the review. it passed, but needs to be released | 14:38 |
| ackk | mvo, yeah still running | 14:38 |
| mvo | jdstrand: thank you, released now | 14:39 |
| niemeyer | mvo: Done, now the committers team has rw there | 14:40 |
| mvo | ackk: I need to take a short break but I will read backlog if you find anything interessting | 14:40 |
| ackk | mvo, ok. thanks for the help | 14:41 |
| ogra_ | ondra, yeah, see the forum ... | 14:41 |
| cachio | mvo, the revert didn't fix it | 14:41 |
| cachio | mvo, the problem is not related to that :( | 14:42 |
| ogra_ | ondra, thanks fo testing though | 14:42 |
| ondra | ogra_ no prob, I just needed to sort my dragonboard as I was testing one thing and it was messed up | 14:43 |
| ackk | mvo, fwiw that tests seems to hang in a trusty container and my (artful) laptop too | 14:51 |
| ackk | mvo, those tests are definitely i/o-bound for me | 14:55 |
| ackk | no idea why | 14:55 |
| ackk | mvo, ~40Mb/s disk write | 14:58 |
| zyga-ubuntu | jdstrand: hey | 14:59 |
| zyga-ubuntu | jdstrand: do you have a chance to re-review the snap-update-ns PR | 15:00 |
| zyga-ubuntu | jdstrand: I'm still blocked on your request for changes | 15:00 |
| ryebot | Is there any way to set StartLimitIntervalSec=0 for snap-created services? | 15:03 |
| ryebot | Or otherwise force them to continue restarting forever? | 15:03 |
| ackk | mvo, ok github.com/snapcore/snapd/cmd/snap-seccomp 420.994s FTR | 15:06 |
| zyga-ubuntu | ackk: FYI on my opensuse laptop with btrfs this takes way too long to test and golang always kills it with 10 minute timeout | 15:07 |
| zyga-ubuntu | I wonder if we could somehow compile one huge executable and then fork each helper test process of it | 15:08 |
| zyga-ubuntu | as I strongly believe it is io bound on gcc for whatever reason | 15:08 |
| ackk | zyga-ubuntu, I suspected btrfs too, but it hangs even if I move $GOPATH under tmpfs | 15:08 |
| zyga-ubuntu | ackk: well that test comples an awful lot of binaries | 15:08 |
| ackk | zyga-ubuntu, can't the be compiled upfront? | 15:09 |
| ackk | *they | 15:09 |
| zyga-ubuntu | ackk: each one is compiled once | 15:09 |
| zyga-ubuntu | ackk: there are generated test programs | 15:09 |
| ackk | zyga-ubuntu, then why the IO ? | 15:09 |
| zyga-ubuntu | ackk: I assumed it was gcc but perhaps I'm missing something | 15:10 |
| mvo | ackk: hm, it should pre-generate the helpers, let me try to figure out what is going on, maybe a bug | 15:14 |
| * ackk updates master | 15:15 | |
| zyga-ubuntu | mvo: set up test vs set up test case? | 15:18 |
| zyga-ubuntu | just guessing, | 15:18 |
| mvo | zyga-ubuntu: could be something stupi dlike this | 15:18 |
| mvo | zyga-ubuntu, ackk: checking in any case | 15:18 |
| zyga-ubuntu | mvo: add a print and see :) | 15:18 |
| mvo | cachio: meh, thats nasty, wonder why the sync breaks just when the other branch gets merged, almost too much of a conicidence | 15:19 |
| mvo | ackk: just to double check, your are on btrfs? | 15:22 |
| ackk | mvo, yes, but as said I tried moving my GOPATH to tmpfs | 15:22 |
| mvo | ackk: it is definitely writing a gazillion of small files and callnig fsync and dirsync for each. | 15:22 |
| mvo | ackk: does it make a difference if /tmp is tmpfs? | 15:22 |
| zyga-ubuntu | mvo: that's super odd, what would call fsync and dirsync? | 15:22 |
| mvo | ackk: I bet it does | 15:22 |
| ackk | mvo, doesn't seem to | 15:23 |
| mvo | ackk: :/ | 15:23 |
| zyga-ubuntu | I don't think we do that outselves | 15:23 |
| ackk | mvo, but is it slow for you? | 15:23 |
| mvo | zyga-ubuntu: we do, the test writes out small bpf programs into files in /tmp/check-NNNN/bpf | 15:23 |
| zyga-ubuntu | mvo: but that should not include any of the sync calls | 15:23 |
| zyga-ubuntu | those are exception, not the norm | 15:23 |
| mvo | ackk: its certainly not fast | 15:23 |
| mvo | zyga-ubuntu: its our "normal" atomic write pattern | 15:24 |
| zyga-ubuntu | ah | 15:24 |
| zyga-ubuntu | try SNAPD_UNSAFE_IO please | 15:24 |
| mvo | zyga-ubuntu: its not using osutil - let me look why | 15:24 |
| zyga-ubuntu | that should make a difference if this is really io bound fsync | 15:24 |
| zyga-ubuntu | ahhh | 15:24 |
| mvo | zyga-ubuntu: I think it can now actually because we have atomicwrite to fds now | 15:24 |
| mvo | ackk: I think we are getting closer! thanks for your patience | 15:25 |
| ackk | thank you guys for digging into this | 15:25 |
| ackk | I'm trying SNAPD_UNSAFE_IO fwiw | 15:25 |
| ackk | oh, but you said it's not using osutil | 15:26 |
| ackk | so it shouldn't make a difference? | 15:26 |
| zyga-ubuntu | not yet | 15:26 |
| * zyga-ubuntu plays with a snap that uses content interface in $SNAP_DATA/subdir | 15:26 | |
| ogra_ | dont the most do that ? | 15:28 |
| zyga-ubuntu | ogra_: no | 15:28 |
| zyga-ubuntu | ogra_: because making that subdirectory is hard | 15:28 |
| zyga-ubuntu | well, no more | 15:29 |
| zyga-ubuntu | that's why I'm fixing it :) | 15:29 |
| ogra_ | i thought mir actually uses it like that | 15:29 |
| ogra_ | (thats the content snap i use most) | 15:29 |
| zyga-ubuntu | there are hacks | 15:29 |
| zyga-ubuntu | I'm making it easy | 15:30 |
| ogra_ | having the interface actually create it ? | 15:30 |
| zyga-ubuntu | yes | 15:30 |
| ogra_ | col | 15:30 |
| ogra_ | +o | 15:30 |
| ogra_ | hah popey beats me :) | 15:34 |
| popey | Reply twins! :D | 15:34 |
| ogra_ | :D | 15:34 |
| popey | Whee, he's getting all the love. | 15:34 |
| ogra_ | hahaha | 15:35 |
| ackk | mvo, oddly, if I run those tests in a container, they succeed in ~400s, on the actual machine they get killed after 10m | 15:36 |
| zyga-ubuntu | ackk: different mount laout | 15:38 |
| zyga-ubuntu | ackk: so proof that they are really io bound | 15:38 |
| ackk | zyga-ubuntu, yeah, but both on btrfs | 15:39 |
| zyga-ubuntu | ackk: but /tmp in container is probably tmpfs | 15:39 |
| zyga-ubuntu | not your real tmp | 15:39 |
| ackk | ah, good point | 15:39 |
| mvo | ackk: this http://paste.ubuntu.com/25521498/ with SNAPD_UNSAFE_IO=1 gives me test runs of 2s vs 14s on ext4. let me iterate a bit on this, I'm not quite happy yet | 15:44 |
| mvo | ackk: with the code and also I think there should be no need to set an environment, the test can test it itself | 15:44 |
| ackk | mvo, awesome, that worked | 15:46 |
| ackk | 2.3s | 15:46 |
| mvo | nice | 15:46 |
| mvo | ackk: I clean it up and will propose something shortly | 15:47 |
| ackk | mvo, thanks! | 15:47 |
| zyga-ubuntu | mvo: suggestion | 15:47 |
| mvo | thank you for raising it | 15:47 |
| zyga-ubuntu | mvo: make unsafe io default=1 in tests | 15:47 |
| zyga-ubuntu | mvo: I use that in opensuse packaging but it should not be hand-held that much | 15:47 |
| ackk | zyga-ubuntu, +1 :) | 15:47 |
| zyga-ubuntu | mvo: everything will benefit | 15:47 |
| mvo | zyga-ubuntu: yeah, I was thinking this | 15:47 |
| zyga-ubuntu | mvo: setting it to =0 should still do the real thing | 15:48 |
| zyga-ubuntu | mvo: and we should test that, ahem | 15:48 |
| mvo | zyga-ubuntu: yeah, I was about to ask why its controlled by the evnrionment | 15:48 |
| mvo | zyga-ubuntu: sounds good | 15:48 |
| zyga-ubuntu | mvo: just so that it's controllable | 15:48 |
| zyga-ubuntu | mvo: but then it was constrained to just tests | 15:48 |
| zyga-ubuntu | mvo: and then it made less sense as a knob that needs to be set in the "fast" position manually | 15:48 |
| ackk | like the "turbo" button on old PCs :) | 15:50 |
| mvo | Chipaca: quick question, I have a thing in seccomp that needs to write atomically to *os.File, seccomp.ExportBPF(file). do you think its reasonable to extend AtomicWriter to have a BackingFile() that would expose the "tmp" *os.File? | 15:51 |
| mvo | Chipaca: this would allow me to kill my code duplication there | 15:51 |
| Chipaca | mvo: it needs an *os.File, not an io.Writer? | 15:52 |
| mvo | Chipaca: unfortuantely | 15:53 |
| pedronis | is it historical or fundamental? | 15:53 |
| mvo | Chipaca: its talking to libseccomp and that expects an fd (int) | 15:53 |
| pedronis | ah | 15:53 |
| Chipaca | mvo: I was this >< close to making AtomicWriter be an actual struct that embedded *os.File :-) | 15:53 |
| pedronis | fundamental | 15:53 |
| mvo | pedronis: I'm afraid so | 15:53 |
| Chipaca | so | 15:53 |
| Chipaca | one thing that would be less and more than *os.File | 15:54 |
| Chipaca | is to expsoe the Fd :-) | 15:54 |
| mvo | Chipaca: export it via an Fd() call? | 15:54 |
| Chipaca | (if that's complete nonesense then tell me so -- my pressur dropped and i ended up on the floor a few minutes ago so brain isn't fully engaged yet) | 15:55 |
| Chipaca | yeah, add “Fd() int” to the interface | 15:55 |
| pedronis | Chipaca: os.File has a a Fd() uintptr | 15:55 |
| Chipaca | eh, i don't mind which | 15:55 |
| pedronis | mostly, didn't understand the more than *os.File bit of your comment | 15:56 |
| Chipaca | it's rather silly, Fd() uintptr feels all low levelly, but then low level things take ints | 15:56 |
| pedronis | it's because of multi-platform | 15:56 |
| Chipaca | pedronis: from one point of view it's more generic, as many things have fds, not just files (and not just *os.Files) | 15:56 |
| mvo | Chipaca: I actually just need *os.File, but I can do the Fd() uint thing | 15:57 |
| Chipaca | eh, BackingFile works | 15:57 |
| pedronis | Chipaca: os.File is not for files | 15:57 |
| Chipaca | mvo: want me to whip it up? | 15:57 |
| pedronis | onyl | 15:57 |
| pedronis | it has a strange name tbh | 15:57 |
| mvo | Chipaca: if its BackingFile() *os.File I have it almost ready, | 15:57 |
| Chipaca | one thing we could do if we were feeling pedantic is make it a separate interface | 15:58 |
| Chipaca | and check the interface | 15:58 |
| mvo | Chipaca: but you are welcome of course, I will do the change in snap-secomp then and merge your commit there | 15:58 |
| Chipaca | but... feels too complicated :-) | 15:58 |
| Chipaca | mvo: nah, go for it | 15:58 |
| mvo | Chipaca, pedronis: thanks for your input | 15:58 |
| Chipaca | i'm going to take 10 and lie down for a bit | 16:00 |
| ogra_ | jdstrand, hmm, where did our mpris interface go ? (i seem to remember snap interfaces shoowing mpris before ... now i dont) | 16:00 |
| ogra_ | *now i dont see it | 16:00 |
| pedronis | Chipaca: get well! | 16:00 |
| mvo | Chipaca: yeah, get well! | 16:00 |
| zyga-ubuntu | hmmmm | 16:01 |
| zyga-ubuntu | for whatever reason "mc" broke on me, all the keyboard navigation is broken and does odd things | 16:02 |
| zyga-ubuntu | like printing ".." all the time | 16:02 |
| * zyga-ubuntu uses this as a sign to reboot | 16:02 | |
| pedronis | mvo: did you find out more about those arm issues ? | 16:05 |
| zyga-ubuntu | oddly this worked | 16:05 |
| mvo | pedronis: not yet, snapd-vendor-sync broke on us :( and that triggers those builds | 16:07 |
| pedronis | :/ | 16:07 |
| pedronis | mvo: do you want me to just bump those timeouts in #3991, it might be enough ? | 16:08 |
| * zyga-ubuntu -> break | 16:08 | |
| mvo | pedronis: yeah, lets try that | 16:08 |
| ogra_ | i bet you will find that the AI on arm is strong and that it knows that in Ubuntu you can not combine foo with 128 ... you can only combine seb with 128 here ... | 16:08 |
| zyga-ubuntu | will be back to content and layouts soon | 16:08 |
| ogra_ | :) | 16:08 |
| pedronis | mvo: it also needs reviews btw | 16:08 |
| mvo | pedronis: ok, will do either next or first thing in my morning | 16:11 |
| pedronis | np | 16:13 |
| pedronis | I'll try to push some timeout bump there | 16:13 |
| jdstrand | ogra_: mpris is not an implicit slot so you eed to have an application installed that slots mpris | 16:18 |
| ogra_ | jdstrand, ah | 16:19 |
| ogra_ | irritating (given it shows up as interface in the interface docs) | 16:19 |
| jdstrand | eg, vlc, gradio | 16:19 |
| ogra_ | yeah, i was looking at the gradio thread when asking :) | 16:19 |
| mup | PR snapd#3908 opened: snap-seccomp, osutil: use osutil.AtomicFile in snap-seecomp <Created by mvo5> <https://github.com/snapcore/snapd/pull/3908> | 16:27 |
| pedronis | mvo: pushed the timeout bump | 16:27 |
| mvo | ackk: -^ this is the final PR | 16:27 |
| mvo | pedronis: thanks a lot | 16:27 |
| ackk | mvo cool | 16:30 |
| cachio | mvo, there? | 16:41 |
| cachio | I see this issue in the dragonboard v | 16:41 |
| cachio | https://paste.ubuntu.com/25521952/ | 16:41 |
| cachio | mvo, it is breaking the whole test suite on db | 16:42 |
| cachio | I'll skip that test | 16:43 |
| cachio | and rerun | 16:43 |
| * zyga-ubuntu cleans his desk | 17:00 | |
| zyga-ubuntu | most laptops off | 17:00 |
| mup | Issue snapcraft#1453 closed: nodejs plugin recording <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1453> | 17:21 |
| mup | PR snapcraft#1524 closed: node plugin: record the yarn.lock file <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1524> | 17:21 |
| bschaefer | if im on an sbuild amd64-armhf schroot how to i tell snapcraft to build an armhf package vs an amd64 one? | 17:22 |
| * bschaefer sees --target-arch ARCH and tests that | 17:23 | |
| mup | Issue snapcraft#1457 closed: remote per-project container <designed> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1457> | 17:24 |
| mup | PR snapcraft#1302 closed: lxd: mount project folder via sshfs in case of a remote <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1302> | 17:24 |
| sergiusens | tyhicks hey there! Mind taking a look at https://forum.snapcraft.io/t/record-machine-information-in-the-manifest/1961/2 ? | 17:24 |
| tyhicks | sergiusens: hey! I'll try to have a look a little later this afternoon | 17:28 |
| sergiusens | thank tyhicks! | 17:28 |
| tyhicks | np | 17:28 |
| tyhicks | ratliff: ^ fyi | 17:28 |
| ratliff | thanks, tyhicks! | 17:29 |
| mvo | cachio: hrm, hrm, so on the db network-manager did never stop? | 17:37 |
| mup | PR snapd#3906 closed: many: use snapcore/snapd/i18n instead of i18n/dumb <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3906> | 17:42 |
| mup | PR snapd#3907 closed: cmd/snapctl: allow snapctl -h without a context (regression fix) <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3907> | 17:45 |
| cory_fu | Are there any known issues with the "home" interface and trusty? The strictly confined charm snap works fine on xenial, but on trusty I get a "bad system call" or "permission denied" when trying to access files under $HOME | 18:00 |
| zyga-solus | cory_fu: hey | 18:02 |
| zyga-solus | cory_fu: please tell me more, I'm cleaning my desk but I want do debug/fix this ASAP | 18:02 |
| zyga-solus | cory_fu: is your HOME on NFS? | 18:02 |
| cory_fu | stokachu: ^ | 18:02 |
| cory_fu | zyga-solus: It's on a MAAS cluster managed by stokachu, so looping him in | 18:03 |
| zyga-solus | stokachu: hey | 18:03 |
| stokachu | cory_fu: zyga-solus they are local disks | 18:03 |
| * zyga-solus will gladly help | 18:03 | |
| stokachu | not NFS | 18:03 |
| zyga-solus | ok | 18:03 |
| zyga-solus | can you please show "snap version" and journalctl or the audit log actually | 18:03 |
| zyga-solus | (feel free to send to canonical pastebin) | 18:03 |
| cory_fu | zyga-solus: snap version: https://pastebin.ubuntu.com/25522377/ | 18:04 |
| zyga-solus | woah | 18:04 |
| zyga-solus | snapd 2.27.5~14.04 | 18:04 |
| zyga-solus | what happened here? | 18:04 |
| zyga-solus | mvo: ^ | 18:04 |
| zyga-solus | snapd doesn't reexec on 14.04 for some reason | 18:05 |
| zyga-solus | cory_fu: can you collect the system logs as well, most importantly audit log for the actual denial | 18:10 |
| zyga-solus | cory_fu: and snapd service logs for the lack or reexec please | 18:10 |
| cory_fu | zyga-solus: I'm not super familiar with debugging snaps. What are the commands for the audit log? | 18:13 |
| zyga-ubuntu | cory_fu: the system audit log should be ok (/var/log/syslog) | 18:14 |
| zyga-ubuntu | (well audit is logged there directly) | 18:14 |
| zyga-ubuntu | (on other distros it gets logged elsewhere) | 18:14 |
| cory_fu | zyga-solus: audit: https://pastebin.ubuntu.com/25522445/ | 18:16 |
| cachio | mvo, it is a tests that was modified in master | 18:17 |
| zyga-ubuntu | cory_fu: is this when you reproduce the error? | 18:17 |
| cachio | mvo, I think it was fixed for some reason | 18:18 |
| cachio | mvo, we should add all the test improvements for next beta on 2.28 if possible | 18:18 |
| kyrofa | What is the UI status on Ubuntu Core? Do we support wayland there yet? | 18:21 |
| cory_fu | zyga-solus: Well, that was just the lines that matched snap.charm. If I tail -F the syslog and run the snap commands that fail (`charm create`, `charm build`, etc), nothing new shows up in the log despite the errors | 18:23 |
| cory_fu | zyga-solus: Also, how do I get the snapd service log? I can't seem to find the proper service name | 18:23 |
| zyga-ubuntu | cory_fu: hmm, not sure on 14.04 honestly | 18:23 |
| zyga-ubuntu | cory_fu: since I'm EOD anyway please open a forum topic, I'll reproduce this first thing tomorrow | 18:24 |
| zyga-ubuntu | cory_fu: just one more question | 18:24 |
| cory_fu | Ok | 18:24 |
| zyga-ubuntu | cory_fu: is this in the ephermeral environment | 18:24 |
| zyga-ubuntu | cory_fu: or after installation? | 18:24 |
| cory_fu | zyga-solus: Not sure what you mean | 18:24 |
| zyga-ubuntu | cory_fu: was the maas note netbooted | 18:24 |
| cory_fu | But it's after I install the snap. Then the charm commands from the snap don't work as they should | 18:24 |
| zyga-ubuntu | cory_fu: is is this a vanilla 14.04 install on the disk | 18:24 |
| cory_fu | stokachu: ^? | 18:25 |
| zyga-ubuntu | cory_fu: I don't have maas at home so if I need to reproduce this, can I just use regular 14.04 system | 18:25 |
| cory_fu | zyga-solus: I believe so | 18:25 |
| cory_fu | zyga-solus: AFAIK it should just be a regular trusty system | 18:25 |
| stokachu | zyga-ubuntu: cory_fu yea these are cloud images | 18:25 |
| zyga-ubuntu | OK, thank you | 18:25 |
| cory_fu | Ok | 18:25 |
| zyga-ubuntu | stokachu: if you can add a link to the forum post, it will help me reproduce | 18:25 |
| stokachu | whats the link to the forum post again? | 18:26 |
| zyga-ubuntu | forum.snapcraft.io | 18:26 |
| stokachu | oh i thought there was a post already | 18:26 |
| cory_fu | zyga-solus: Oh, I just realized I was watching the syslog on the wrong machine. >_< | 18:26 |
| zyga-ubuntu | ^_^ | 18:26 |
| * zyga-ubuntu stays tuned for more logs | 18:27 | |
| cory_fu | zyga-solus: https://pastebin.ubuntu.com/25522507/ | 18:28 |
| zyga-ubuntu | hmm, sadly the bad system call is not logged on 14.04 | 18:29 |
| zyga-ubuntu | I'll reproduce and check | 18:29 |
| zyga-ubuntu | can you please include simple instructions about the snaps you've used? | 18:29 |
| jdstrand | roadmr: hey, can you sync r930 of the review tools? I've tested it a lot and expanded my local blackbox testing to include --json | 18:32 |
| roadmr | jdstrand: sure! will do | 18:33 |
| jdstrand | roadmr: but you may want to test a snap or two on staging. this has the change to put error()s into the error json when --json is specified | 18:33 |
| zyga-ubuntu | jdstrand: I, for one, cannot wait for seccomp logging | 18:34 |
| roadmr | jdstrand: ok, thanks, I'll do more thorough than usual testing | 18:34 |
| jdstrand | roadmr: that should get rid of (almost) all cases of 'unexpected output'. there are a couple of other places in bin/click-review that could conceivably create non-json | 18:34 |
| cory_fu | zyga-solus, stokachu: https://forum.snapcraft.io/t/issues-with-strictly-confined-snap-charm-on-trusty/2098 | 18:35 |
| zyga-ubuntu | thank you | 18:35 |
| jdstrand | roadmr: but those cases are quite unlikely | 18:35 |
| cory_fu | zyga-solus: Thanks for your help. Have a good evening! | 18:35 |
| jdstrand | zyga-ubuntu: we have seccomp logging today. what we don't have is not killing plus logging | 18:37 |
| jdstrand | zyga-ubuntu: you're probably seeing kernel rate limiting. | 18:38 |
| jdstrand | zyga-ubuntu: I've been using this: alias tail_journalctl='sudo sysctl -w kernel.printk_ratelimit=0 ; journalctl --follow' | 18:38 |
| zyga-ubuntu | jdstrand: I think it's not working at all on 1404 | 18:39 |
| zyga-ubuntu | jdstrand: logging (journald) is just absent there entirely | 18:39 |
| jdstrand | the first disables rate limiting (though it can still happen...) and the latter seems to not have things drop as often. maybe I'm imagining things there | 18:39 |
| zyga-ubuntu | jdstrand: I'm familiar with rate limiting, though I don't think we've hit it here | 18:39 |
| jdstrand | zyga-ubuntu: the 1404 lts kernel is (nearly?) identical to xenial | 18:40 |
| zyga-ubuntu | jdstrand: it's identical but userspace parts are not | 18:40 |
| jdstrand | zyga-ubuntu: perhaps rsyslog stopped logging altogether. I've seen that. try logger | 18:40 |
| zyga-ubuntu | jdstrand: AFAIK we're not loggged at all on 14.04 | 18:40 |
| zyga-ubuntu | jdstrand: systemd starts snapd | 18:40 |
| zyga-ubuntu | jdstrand: but it's not integrated with regular syslog | 18:41 |
| zyga-ubuntu | jdstrand: so on 14.04 logs are just lost (from snaps and snapd) | 18:41 |
| jdstrand | I see | 18:41 |
| jdstrand | well, that is different than 'seccomp logging' of course :) | 18:41 |
| jdstrand | seems need to wire that all up | 18:42 |
| jdstrand | I have to believe that the snapd systemd is getting the messages-- just need to shove them into rsyslog | 18:42 |
| jdstrand | but, apparmor and seccomp should log cause that is coming from the kernel, not snapd | 18:43 |
| roadmr | jdstrand: so with these latest changes - if there's a stray /tmp/blahblah, what'll be the exit code? will it exit with 1? | 18:43 |
| roadmr | (or is that considered a non-fatal condition and exits with whatever the actual review outcome was?) | 18:43 |
| jdstrand | and if they aren't, either it is rate limiting or rsyslog isn't logging (again, I've witnessed that) | 18:43 |
| jdstrand | roadmr: are you talking about the reaping code? | 18:44 |
| roadmr | jdstrand: yes, which I think is the one spitting out those "error can't find /tmp/whatever" which is what was confusing sca | 18:44 |
| jdstrand | roadmr: if so, it try's to remove the dir, if there is any exception, it logs via syslog | 18:45 |
| roadmr | nice | 18:45 |
| jdstrand | roadmr: but that is unchanged from r922 that is in prod now | 18:45 |
| jdstrand | roadmr: I thought you said before that that issue was resolved for a week or more? | 18:47 |
| roadmr | jdstrand: yes, we haven't seen that recently | 18:48 |
| jdstrand | roadmr: we had that one snap that had 'unexpected output' a few times, but no other issues (the sync today is meant to give us insight into what happened with that snap) | 18:48 |
| jdstrand | roadmr: ok, cool | 18:48 |
| roadmr | yep, that's what I meant :) thanks! | 18:48 |
| zyga-ubuntu | jdstrand: thank you for checking that systemd thing in my PR, looks like (oddly) a regression in master | 18:55 |
| zyga-ubuntu | jdstrand: did you have a chance to look at the changes I made since your previous review? | 18:58 |
| om26er | Hi! with snapd-control interface connected, can I talk to the snapd unix socket ? | 19:03 |
| om26er | currently even checking if that path exists (with snapd-control) says permission denied | 19:04 |
| om26er | zyga-ubuntu: ^ | 19:04 |
| om26er | my snap will install/remove/refresh/list snaps remotely, so need to talk to the snapd daemon. | 19:06 |
| om26er | s/daemon/unix-socket | 19:06 |
| jdstrand | zyga-ubuntu: dude | 19:09 |
| jdstrand | zyga-ubuntu: :) | 19:09 |
| jdstrand | zyga-ubuntu: I'm moving to it now. note, it still needs a deep audit of bootstrap.c | 19:10 |
| kyrofa | jdstrand, do you know the current status of wayland on Ubuntu Core? | 19:13 |
| kyrofa | Or is mir still the one used there? | 19:14 |
| jdstrand | kyrofa: mir-kiosk. no slot side policy for wayland yet (and thus no wayland snap) | 19:15 |
| kyrofa | jdstrand, okay, thank you | 19:15 |
| jdstrand | kyrofa: note, nobody afaik is assigned to create a wayland slot implementation | 19:15 |
| kyrofa | jdstrand, exactly the info I needed | 19:15 |
| kyrofa | ogra_, any chance you're around? | 19:37 |
| zyga-ubuntu | om26er: yes, you must just connect to it | 19:47 |
| kyrofa | jdstrand, we don't have a can bus interface, right? | 19:47 |
| zyga-ubuntu | jdstrand: thank you :) | 19:47 |
| jdstrand | kyrofa: correct. I'll note apparmor and snap-seccomp understand AF_CAN so an interface shouldn't be terribly difficult | 19:49 |
| kyrofa | jdstrand, good, just checking. No LIN interface either? I'm not very familiar with that one: my research says no, but I want to make sure it's not covered by something else | 19:50 |
| jdstrand | kyrofa: I'm going to say 'no' since I've never heard of LIN :P | 19:51 |
| kyrofa | Sounds about right! Thanks jdstrand :) | 19:51 |
| jdstrand | kyrofa: more seriously. no, no LIN yet | 19:51 |
| zyga-ubuntu | jdstrand: corrected the two remarks | 19:51 |
| zyga-ubuntu | kyrofa: wow, can and lin | 19:51 |
| zyga-ubuntu | kyrofa: are you making a car? | 19:52 |
| zyga-ubuntu | snap install wheel | 19:52 |
| kyrofa | zyga-ubuntu, responding to someone who is | 19:52 |
| jdstrand | kyrofa: seems that might be lumped in with CAN if one was doing it, but of course would have to research/review the implementation | 19:52 |
| bschaefer | hmm seems a new core update 2913 and im getting: | 19:55 |
| bschaefer | Sep 12 08:43:53 localhost kernel: [ 5.209208] vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops [vc4]): -517 | 19:55 |
| bschaefer | Sep 12 08:43:53 localhost kernel: [ 5.217788] vc4-drm soc:gpu: master bind failed: -517 | 19:55 |
| zyga-ubuntu | I should take a break | 19:57 |
| bschaefer | ogra_, ping if you're around :) (seems to be some vc4/kernel issues) | 20:03 |
| bschaefer | no /dev/dri | 20:03 |
| zyga-ubuntu | bschaefer: is this a stable core snap? | 20:07 |
| bschaefer | i was on an edge image | 20:08 |
| bschaefer | http://cdimage.ubuntu.com/ubuntu-core/16/edge/current/ | 20:08 |
| bschaefer | and core just bumped up to core 16-2.27.6+git365.f5f40b0 2913 canonical core | 20:08 |
| bschaefer | (or so it seemed to have updated where it wasnt before as ive been reflashing that image all day) | 20:08 |
| bschaefer | just reflashed before core updates | 20:19 |
| bschaefer | core 16-2.27.6+git363.8fc1b40 2897 canonical core | 20:19 |
| bschaefer | seems happy with vc4 | 20:19 |
| zyga-ubuntu | exit | 21:36 |
| === jkridner|pd is now known as jkridner | ||
| niemeyer | jdstrand: Still around? | 22:39 |
| mup | PR snapd#3903 closed: tests: change regex used to validate installed ubuntu core snap <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3903> | 22:46 |
| jdstrand | niemeyer: only for a moment. still working through 3621 (should be done tomorrow, got sidetracked by some high priority stuff, but back to 3621) | 22:59 |
| niemeyer | jdstrand: Yo | 22:59 |
| niemeyer | jdstrand: Any chance of a quick review for a name req? | 22:59 |
| jdstrand | niemeyer: I don't usually do name requests... /me would have to look up how to do that | 23:00 |
| niemeyer | jdstrand: Was hoping to have a call with zyga and you today, but we can do that tmorrow | 23:00 |
| jdstrand | niemeyer: what is the name and what do you want done with it? | 23:00 |
| niemeyer | jdstrand: Ah, sorry, np | 23:00 |
| jdstrand | ok | 23:00 |
| jdstrand | niemeyer: is the call about 3621? | 23:00 |
| niemeyer | jdstrand: Yeah, I think so | 23:01 |
| jdstrand | (snap-update-ns) | 23:01 |
| niemeyer | Yeah | 23:01 |
| niemeyer | jdstrand: Who usually approves names? | 23:01 |
| jdstrand | if the call is about the status, I'll have my final review done tomorrow. there won't be any blockers, but will have requested changes | 23:01 |
| niemeyer | jdstrand: Super, thanks | 23:02 |
| jdstrand | niemeyer: I feel like it's the store team or possibly advocacy. noise][ and nessita or ev would be who I personally would go to | 23:02 |
| niemeyer | jdstrand: Ack, thanks | 23:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!