[00:46] PR snapcraft#1891 closed: lifecycle: use in-snap mksquashfs if running from snap [01:50] jdstrand, I have requested manual review for the other architectures of snap test-snapd-gpio-memory-control [01:50] jdstrand, when you have a minute, could you please approve them [01:50] tx [02:18] cachio: done [02:47] jdstrand, tx [04:38] PR snapd#4563 opened: tests: new spread test for gpio-memory-control interface [06:01] morning [06:40] forum is down? [06:41] mvo: morning [06:48] mborzecki: good morning [06:48] mborzecki: yeah, looks down from here as well [06:53] * mvo still needs a review for 4342 [06:55] good morning [06:55] https://github.com/snapcore/snapd/pull/4560 is ready for 2nd review [06:55] PR #4560: cmd/snap-confine,data/systemd: fix removal of snaps inside LXD [06:55] and I'll work on breakfast for kids, see you soon [06:57] PR snapd#4560 closed: cmd/snap-confine,data/systemd: fix removal of snaps inside LXD [06:57] zyga-ubuntu: I already commented, one tiny nitpick about a comment but that should be a followup, no need to hold this PR back [06:57] zyga-ubuntu: I need a review for 4342, its blocking ~rc2 currently [07:00] I know, I will do your review after kids go to school [07:00] ta [07:02] zyga-ubuntu: morning [07:22] oka [07:22] daughter is all set and ready for school [07:23] mvo: thank you for the feedback, I'll update the PR and merge it [07:26] ah, it's merged now :) [07:26] k, looking at that zenity branch [07:27] mvo: btw, I'm very sorry for not looking at it yesterday, I saw your requests but I was busy with the feedback from gustavo [07:27] mvo: will you do a RC3 for 2.31? [07:27] PR snapd#4564 opened: data/systemd: tweak comment [07:27] mvo: I really want to land 4471 today [07:27] mvo: and make it into the release [07:27] otherwise we should probably back out the new content interface features [07:28] gustavo approved the design but requested tweaks on how that code operates to drop the helper function (tryIt etc) [07:28] zyga-ubuntu: if 4471 is ready today +1, if not I think we need a revert PR [07:28] zyga-ubuntu: how was the feedback yesterday? all looking good to fix it today? [07:29] mvo: yes [07:29] Is the forum down for anyone else? Nginx 502 bad gateway. [07:29] mvo: I need to inline that function back [07:29] mvo: nothing major [07:29] ok [07:29] bashfulrobot: it's down for me too [07:30] zyga-ubuntu thanks for the confirmation! [07:35] woah, the wind today is very strong [07:35] trees are swinging like grass! [07:52] jdstrand: are you in US or still sprinting somewhere? [07:56] good morning [07:56] I'm getting a 502 on forum.snapcraft.io [07:56] is it just me? [07:56] no, it's everyone [08:01] jdstrand: if you could moderate the updated base-18 in the store that would be great [08:08] mvo: what is %[1]q - is that golang syntax for fmt? [08:09] hey there spineau [08:10] morning zyga-ubuntu [08:11] mvo: nitpick 2018 in your new files [08:11] mornings [08:12] hey pawel [08:12] the forum is borked? [08:13] yes [08:13] mvo: so I get what \0 is but \00 ? is that the same thing or {'\0', '0'} in C syntax? [08:14] man, today is windy :/ [08:14] sliff [08:15] zyga-ubuntu: %[1]q is fmt syntax [08:15] zyga-ubuntu: \00 should be \0, let me check, maybe I made a silly mistake [08:16] mvo: at line ... 43 and 44 [08:17] mvo: so meta-comment, nothing -1, I want to play with it [08:17] but we need the desktop team to help and I don't know, roll this into gnome settings [08:17] or into other appropriate place [08:17] right now it feels like a hack that keeps us walking till we can run [08:18] mvo, hey, shall I squash #4440 for easy cherry-picking into 2.31? [08:18] PR #4440: state: unknown tasks handler [08:18] pstolowski: its fine as is, I looked over master this morning and all is fine for .31 [08:19] mvo, ok [08:19] zyga-ubuntu: aha, sorry. this should read \0\0 [08:19] zyga-ubuntu: i.e. a double \0 marks the end of a command [08:19] zyga-ubuntu: let me fix this [08:20] thank you! [08:20] * zyga-ubuntu reads rest [08:21] zyga-ubuntu: hmm looking at 4565 i was wondering why i'm ending up with snap.mount on arch [08:21] mvo, hi, it seems there was an issue uploading the base-18 build: https://code.launchpad.net/~mvo/+snap/base-18/+build/138724 [08:21] PR snapd#4440 closed: state: unknown tasks handler [08:22] zyga-ubuntu: turns out i'd really like to switch data to autotools [08:22] mborzecki: no objection, fire a PR and let's do it [08:36] mvo: and in strings, is \000 just {'\0'} or is it something else [08:36] e.g. here: +call = strings.TrimSuffix(call, "\000") [08:45] ackk: yeah, I ask jamie to moderate the upload, it is currently stuck in the review queue [08:46] zyga-ubuntu: this should be \0 as well, sorry for this [08:46] oh ok, thanks [08:50] mvo: did you run it in practice? [08:54] zyga-ubuntu: just running the tests [08:55] zyga-ubuntu: but the zenity tests use \n in their args [08:55] zyga-ubuntu: so it should work [08:55] mvo: how about setting this thing in practice, getting the prompt and all of that [08:55] * zyga-ubuntu is still reading the code [09:04] do we have to wait for niemeyer to get the forum back up? [09:07] sparkiegeek: I'm afraid so, we're not sure what caused it [09:10] zyga-ubuntu: I tested this with the brave browser [09:10] zyga-ubuntu: sorry for the delay in answering [09:10] zyga-ubuntu: if that is what you mean with "testing in practise" or do you mean something else? [09:15] no that's fine [09:15] did you test both kde and non-kde paths? [09:20] zyga-ubuntu: yeah, i tested once with kdialog and once with zenity [09:21] zyga-ubuntu: I think mborzecki has a point that ideally it would check the desktop env too, I can make a PR for that too [09:21] mvo: yeah, I responded to that part as well [09:21] * kalikiana coffee [09:22] mvo: reviwed [09:22] reviewed* [09:23] mvo: can you have a quick look at https://github.com/snapcore/snapd/pull/4564 please [09:23] PR #4564: data/systemd: tweak comment [09:23] let's either merge it or tell me to tweak the install code [09:25] PR snapd#4564 closed: data/systemd: tweak comment [09:25] zyga-ubuntu: I think its fine, we can always tweak further [09:25] thanks! [09:26] hi, is the forum down (502) ? [09:26] yes [09:26] I think we need a post mortem on the forum and some plan for gustavo being on holidays [09:26] *cough* IS *cough* [09:29] kalikiana: https://regexper.com/ [09:31] `/home/ubuntu/goroot/pkg/tool/linux_386/link: running gcc failed: exit status 1` uhh not my lucky day [09:32] mborzecki: it's your NaNth lucky day [09:33] oh hey, also gnome-shell crashed out of the blue [09:33] pff strace to the rescue: [pid 8615] write(2, "/usr/bin/ld", 11) = -1 ENOSPC (No space left on device) [09:34] uhh [09:34] careful with those torrents [09:34] qemu can eat a lot of space on -snapshot [09:35] zyga-ubuntu: it's xenial cloud image [09:35] * zyga-ubuntu takes a break to look through bugs befor jumping onto PR feedback [09:35] didn't know those are 2gb [09:35] hey Chipaca! [09:35] mborzecki: uh [09:35] Chipaca: morning [09:36] mborzecki: zyga-ubuntu: hiya [09:36] pstolowski: can you please look at https://bugs.launchpad.net/snapd/+bug/1611638 [09:36] Bug #1611638: snap upgrade hook [09:36] I think it's fixed so we can just update the bug but I wanted you to confimr [09:36] *confirm even [09:37] zyga-ubuntu, looking [09:38] zyga-ubuntu: Hmmm looks quite nice. Although it seems very "analyze afterwards". It's not live and there's no test string [09:38] mborzecki: I assigned a bug about testing on arch to you (since you're doing that anyway) [09:39] kalikiana: yeah, not perfect but it's nice to see those cute railroad diagrams [09:41] zyga-ubuntu: ack [09:43] zyga-ubuntu, commented on the bug, it's implemented, although now as I checked only on of those was released (post-refresh) and pre-refresh will come with 2.31 [09:44] pstolowski: perfect, thank you! [09:45] * Chipaca carries on refactoring unseen code [09:49] Chipaca: I do that a lot though sometimes I think I'm doing the coding version of modern art ;) [09:49] zyga-ubuntu: not art, but craft [09:50] zyga-ubuntu: the difference is mostly around how we get paid :-) [09:51] haha [09:51] art is when you don't get paid [09:52] I often write a piece of code and the refactor it, sometimes many many times, before sending out the first PR [09:54] pstolowski: another one for you https://bugs.launchpad.net/snapd/+bug/1664155 [09:54] Bug #1664155: Interface hooks slots should know the name of the client snap [09:54] mvo: trivial conflict on https://github.com/snapcore/snapd/pull/4443 [09:54] PR #4443: [RFC] snap: improve error for snaps not available in the given context [09:54] pedronis: you around? [09:55] PR snapd#4565 opened: httputil: include Go runtime version in user agent string [09:55] trivial PR ^^ [09:56] kalikiana: can you look at https://bugs.launchpad.net/snapd/+bug/1669291, perhaps a low hanging fruit [09:56] Bug #1669291: 'snap info' does not handle versions that end in 0 well [09:56] kalikiana: at least triage it please [09:56] zyga-ubuntu, k, will comment on it when forum is back, I think it was discussed long time ago (and Gustavo was against doing it) [09:56] mborzecki: nie! [09:56] nice! [09:56] :) [09:56] pstolowski: just give some feedback on the bug report, we don't have to move the discussion elsewhere [09:57] mborzecki: what is the runtime string like? [09:57] zyga-ubuntu: added a comment in the PR [09:57] mborzecki: and another hint, send it in the / request so that (perhaps) snap version can show it [09:57] zyga-ubuntu, sure, I just need to try find that discussion [09:57] mborzecki: looks good [09:58] zyga-ubuntu: Aye [09:59] Chipaca: yes [09:59] pedronis: hiya, welcome back :-) [09:59] hi [09:59] pedronis: while you were away I was wondering whether a local snapd could "sign" stuff [09:59] kalikiana: thank you [10:00] pedronis: and thought you were the person to ask [10:00] Chipaca: sign stuff in which sense? [10:00] pstolowski: perhaps another bug for you https://bugs.launchpad.net/snapd/+bug/1672747 -- feel free to ignore, I'm just combing the bug tracker [10:00] Bug #1672747: configure hook missing reason it was invoked [10:00] hm good news, i can reproduce the segfault when building snapd on xenial with go1.9.3 [10:00] pedronis: as a way of ensuring not only the integrity of a snapshot, but also its origin [10:01] ah [10:01] zyga-ubuntu, the bug makes sense, but it's slowly improving with new hooks [10:01] Chipaca: if it has a serial yes, then it has a device key [10:02] that can be tracked to the serial [10:02] pedronis: snapshots have a metadata file with hashsums of the archives themselves, so AFAIUI if I signed that (relatively small) file and included the signature, I'd be able to warn or block people from restoring snapshots that weren't created by their own host [10:03] should be doable in some way [10:03] (i imagine adding a --ignore-signature or something) [10:03] pedronis: ok, good to know. I'll pester you about it once everything else is shipshape. [10:03] depends on the attack you are trying to avoid, or is just not mismatching stuff? [10:05] guys, is #4487 good to be merged now? [10:05] PR #4487: cmd/snap: snap refresh --time with new and legacy schedules [10:06] mborzecki: looking [10:07] with 4 +1s, sure! [10:07] pedronis: the attack is fairly contrived, in that you'd have to either be able to write to the spool directory where snapshots live (and in a properly configured system users won't even be able to read it), or convince an admin to accept a snapshot file somehow [10:07] PR snapd#4487 closed: cmd/snap: snap refresh --time with new and legacy schedules [10:15] mvo: can we do something about seccomp before 18.04? [10:16] zyga-ubuntu: do somethng about it in what sense? [10:18] Chipaca: just saying that if you are root you can get the key that is used for signing [10:19] pedronis: yeah [10:19] mvo: make it so that on 18.04 we can enable the non-kill behavior [10:19] Chipaca: anyway I suppose if people ship them somewhere and back it's a bit more interesting [10:19] pedronis: I expect snapshots will be part of a backup solution that includes remote backups, yes [10:19] but those things should be signed at a separate layer anyway [10:19] pedronis: I think I'll check with jamie, and if he agrees it's too tenuous, i'll forget it [10:20] ok, np [10:20] pedronis: thanks [10:21] zyga-ubuntu: its tricky the updated libseccomp is not out, but we might be able to split out this part of the work in a separate pr [10:23] idk theres something charming about a security stack that opts to commit seppuku to protect the user [10:23] mvo: upstream has not released it or it hasn't found its way into ubuntu? [10:23] ikey: did snap-confine refuse to run for you? :) [10:24] ikey: (hey :-) [10:24] hey :) nah not recently, i meant the seccomp thing [10:24] ikey: ah [10:24] well, that's not seppuku, IMO it's like us shooting a thread because it asked to go to the loo [10:24] the thread _asked_ [10:24] just saying no wasn't in the vocabulary [10:24] yeh but i mean, going to the loo, during class time [10:24] idk man.. [10:24] >_> [10:25] yeah, so mean [10:25] it's an _internal_ problem ;) [10:25] lol [10:25] I'd love to see that bug fixed, I'm wondering what we can do [10:25] the kernel part is done now [10:25] and everyting else is just userspace [10:25] so distros just need to update libseccomp? [10:26] it's complicated [10:26] yes [10:26] and golang bindings on top [10:26] and it seems it's not even out upstream yet [10:26] orite [10:26] PR snapd#4565 closed: httputil: include Go runtime version in user agent string [10:27] mborzecki: make sure the store team can parse that ^ talk to ... perhaps noise][ ? [10:27] zyga-ubuntu: upstream has not released an new golang-seccomp [10:28] its looking likely im going to need to rework my nvidia PR to account for some fedora weirdness [10:28] mvo: is the upstream for the C and golang lib the same? [10:28] looks like they stuff their entire tree under /usr/lib64/nvidia-304xx/* [10:28] so idk if i need to do that as separate PR, commit or what [10:28] given the one i have is marked accepted.. [10:28] ikey: no, just stack on top there [10:28] thank you for caring about fedora! [10:29] well we're all cousins in this world [10:29] (not literally. that'd make christmas so freakin awkward) [10:30] with RMS and linus smiling from a family photo on the wall [10:31] ... [10:31] weird silence [10:31] XD [10:33] hmm no segfault with go1.8.3 [10:34] * Chipaca gives up on emacs and goes back to paper [10:37] zyga-ubuntu: its two different people. but the upstream C is also not released yet [10:37] zyga-ubuntu: its just part of git [10:37] zyga-ubuntu: and the golang is not yet part of git because there is no libseccomp yet released with the bits needed [10:40] mvo: aha, I see; we can ask them to release or distro patch in ubuntu but I wonder how that complicates building the packages and the snaps [10:40] mvo: craazy idea: what if snap-seccomp was a .. snap itself [10:41] and we could pull it in to build the profiles [10:41] (it's a bit chicken-eggy) [10:41] but would work around building issues [10:41] zyga-ubuntu: we distro patchi n ubuntu already, thats fine. but e.g. fedora is not distro patching [10:42] aha. smoke break granted me the wisdom to fix the gl thing.. [10:42] zyga-ubuntu: mborzecki: that format is not standard afaik (it would need to be system/version) [10:42] zyga-ubuntu: if fedora would allow us to bundle the problem would also not exist [10:42] mvo: I think we can bundle but we could also patch the packages there if maintainers agree [10:42] pedronis: oh, thank you for noticing [10:42] pedronis: so golang/... [10:42] the forum seems very 502y today [10:42] (or similar) [10:42] something like that [10:43] yes [10:43] Chipaca: yes, it's 100% reliably 500s today [10:43] Chipaca: input on #4565 [10:43] PR #4565: httputil: include Go runtime version in user agent string [10:43] it's merged but I think it needs tweaks [10:44] pedronis: opening a followup with fixes in a minute [10:44] hmmm [10:44] that should be go/xyz [10:45] Chipaca: pedronis: runtime.Version() already returns `go1.9.3`, that would make it golang/go1.9.3 [10:45] mborzecki: what does it look like with gccgo? [10:45] also a bit unclear whether it's useful? [10:46] mborzecki: what's the goal here? [10:46] I'd be ok with go/goX.Y.Z if goXYZ is what runtime.Version returns [10:46] getting this in the logs? [10:46] pedronis: yes [10:46] pedronis: it'd be in error reports also [10:46] both could be done without changing the user agent [10:46] it's a bit strange to put the compiler there [10:47] otoh it's also the standard lib [10:47] mborzecki: what does go itself does? [10:47] it has a default user-agent afaik [10:47] pedronis: also stdlib carries the http client [10:47] that we are overriding [10:47] we probably should do something similar [10:50] pedronis: probably Go-http-client/1.1 (that's what they expect in the tests anyway) [10:51] mborzecki: zyga-ubuntu: anyway I fear this will also break the store [10:51] we need to be a bit careful [10:52] Chipaca: pedronis: `golang/go1.9.3` then? [10:52] why the repeated go? [10:53] anyway I also need to check where to put it if at all [10:53] * zyga-ubuntu -> important errand [10:54] hmm [10:54] mborzecki: problem [10:54] i can always move the go runtime version string to daemon.go and log it there, after all i just want to see the version somewhere, don't really care if it's the user agent string [10:55] go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994] [10:55] ^ runtime.Version() with gccgo [10:55] fun [10:55] right, and go returns go1.9.3 [10:55] oh, w8, that's the whole string? [10:55] mborzecki: "go1.6.1 gccgo (Ubuntu 6.0.1-0ubuntu1) 6.0.0 20160414 (experimental) [trunk revision 234994]" [10:56] mborzecki: that's printed with %q for your enjoyment [10:56] damn [10:56] ok, i'll log it in the daemon [10:56] and the store can keep guessing which buggy version of go http.Client was that :) [10:57] mborzecki: anyway, indeed as it is it would break the store parsing of it [10:57] ok, i"ll open a pr reverting the change [10:58] the issue there is mostly putting it at the end I think [11:00] PR snapcraft#1892 opened: meta: warn if version is not a string [11:00] PR snapd#4566 opened: Revert "httputil: include Go runtime version in user agent string" [11:01] what do you use to format the C files in snapd? [11:01] ikey: indent [11:01] any sample invocation? i tried indent but it mangled the file [11:01] don't laugh though please :) [11:02] * ikey is only used to clang-format [11:02] there's .indent in cmd [11:02] `make fmt` should do the trick [11:02] mborzecki: or not, maybe I'm confused (regexps are fun that way) [11:03] ah ty [11:03] mvo, i see xnox just made systewmd default to persistent journald logging ... https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1618188 for your base 18 you might want to turn it off to not wear out MMCs [11:04] Bug #1618188: systemd journal should be persistent by default: /var/log/journal should be created Bionic):Fix Released by xnox> [11:05] mborzecki: https://golang.org/pkg/runtime/#Version says it could also be a hash and date [11:05] (oh, and indeed make sure /var/log/journal is writable [11:05] ) [11:06] ogra_: base-18 has everything writable [11:06] ouch [11:06] will you keep it that way ? [11:06] ogra_: we will see if it works out, but whats the downside? [11:07] https://forum.snapcraft.io/t/forum-offline-today-post-mortem/3760 [11:08] ogra_: thanks for the heads up, I will look into making sure this is not written to disk by default then [11:11] niemeyer: Apologies for any inconvenience this may have cause*d* you. [11:11] niemeyer: and thank you for getting it back up :-) [11:11] niemeyer: hey [11:12] niemeyer: woot, thank you for for the post morterm [11:12] Chipaca: Thnaks [11:12] * zyga-ubuntu makes lunch and reads [11:12] Chipaca: *Thanks* :) [11:12] niemeyer: I thought that was on porpoise [11:12] :-) [11:13] niemeyer: it's at least very comforting to know the forum died while making a backup :) [11:13] Chipaca: afaict runtime.Version() can be whatever :/ [11:13] zyga-ubuntu: Yeah [11:14]