=== abner is now known as Guest68496 === Abhishek_ is now known as Guest42362 === ikey is now known as ikey|zzz === JoshStrobl is now known as JoshStrobl|zzz [02:27] PR snapd#3734 opened: add packaging for debian-unstable [03:26] I am looking for help with snapcraft (on a working snap), anyone here good at it? === ubott2 is now known as ubottu [04:44] whoa the failure in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-snappy-dev-image/artful/amd64/s/snapd/20170815_034238_adfc1@/log.gz is funky [04:44] (and surely not related to the change) === mardy_ is now known as mardy [07:38] PR snapd#3727 closed: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go [08:09] PR snapd#3726 closed: interfaces: backport broadcom-asic-control interface (2.27) [08:12] mvo: hello [08:12] mvo: I see you are busy already :) [08:12] mvo: I'm off today, just preping the leave the house === ShalokShalom_ is now known as ShalokShalom [08:12] zyga-suse: good morning! yes :) [08:13] zyga-suse: uploading a 2.27.2~rc1 to artful to get the "real" autopkgtest running on it [08:13] zyga-suse: to validate the the i386 416 issue is really fixed [08:14] great [08:15] mvo: if you make a tarball and give me the URL I'd love to check suse later [08:16] re [08:16] sorry I got disconnected [08:16] what is the 416 issue? [08:18] zyga-suse: no worries. there is an autopkgtest failure in artful (and other) on i386 where the server replies 416 [08:19] zyga-suse: turns out (apparently) we already have the full snap and send a GET anyway and the content-rage is data>size which the server cannot honor [08:21] zyga-suse: welcome back, did you see anything I wrote before you disconnected? [08:26] ah, I see, I _found_ that problem :D [08:26] zyga-suse: to validate the the i386 416 issue is really fixed [08:26] this is the last message I saw [08:26] do you have the RC tarball already [08:27] and will you change it again to remove the rc wording? [08:28] mvo: to watch later, https://www.youtube.com/watch?v=SPr--u4n8Xo [08:29] zyga-suse: I will change the rc wording hopefully this evening, unfortunately the publishing/autopkgtest runs takes a litte while :( [08:29] zyga-suse: but it will be quicker than a 2.27.3 if this is not actuallly the issue :) [08:29] * popey hugs diddledan [08:31] * zyga-suse merges big PR to help gary-wzl [08:31] gary-wzl: can you please merge master into your udev branch now [08:31] gary-wzl: I think everything has landed so we should now see the interesting parts in that diff [08:32] PR snapd#3714 closed: interfaces: a bunch of interfaces test improvement [08:32] zyga-suse: Oh nice. working on it now [08:32] thank you! [08:33] I just happened to ping you as there's only one(bit) PR left to merge. You did it [08:33] Thanks! [08:37] mvo: do watch that, it's interesting [08:37] zyga-suse: you remember that error when snap/snapd versions got out of sync? iirc you had that at some point [08:37] yes [08:38] zyga-suse: I wrote a testcase that tries to reproduce it but for me on core install undo things get restarted correctly :/ you don't happen to have more details/memory about the failure? [08:38] "crazy insecure lunacy of appimage" [08:38] oh boy, shots fired [08:39] mvo: mmm, is it the case where snapd is new and snap is old? [08:39] zyga-suse: correct [08:40] while I may be missing the details I think one thing that is sufficient is a refresh failing so if you hack the script (like we did in one other test) to always fail (the configure script) I think you can then refresh to that snap [08:40] and then I think it will happen [08:40] I know we allow the configure to fail [08:40] but there must be a real way to make this happen as it runs in the wild [08:40] zyga-suse: yeah, I did pretty much that and it restarts back to the right version for me [08:40] was it also related to changelog and stale version number? [08:40] oh? it restarts? [08:41] zyga-suse: yeah, it restarts into the new version but on undo it also restarts into the old version - this is the puzzling part [08:41] mmm [08:41] indeed [08:41] is that also the case that gustavo hit? [08:41] I mean, for him it did _not_ restart [08:41] zyga-suse: I will push the test soon, there must be something I am missing, as gustavo hit it too [08:41] what happened there? [08:41] zyga-suse: correct [08:42] zyga-suse: I don't know, I keep digging, for gustavo it was "out-of-diskspace", anyway, just wanted to check if there is anything you remember that might help me :) [08:47] I see, sorry I'm not much of a help [08:48] Bug #1627643 changed: oops on pi3 (seemingly wlan related)

[08:48] Bug #1678076 changed: console-conf crashes with eth0 and wlan0 on Pi 3 [08:48] zyga-suse: no worries, I keep digging [08:51] Bug #1627643 opened: oops on pi3 (seemingly wlan related)

[09:03] * zyga-suse goes to the park with his family [09:03] good luck mvo, please PM me on telegram with the 2.27.2 URL [09:03] I'll release suse then [09:16] pedronis: aw! that PR was all green, and now i've got to push to it. You know it's not going to be all green next time :-( [09:17] pedronis: ^^^ that's a joke by the way [09:17] * Chipaca has had too little sleep === chihchun_afk is now known as chihchun [09:21] oh. lovely ! [09:21] https://askubuntu.com/questions/938606/dwarf-fortress-starting-during-apt-get-upgrade [09:21] (nearly as good as "libreoffice only prints on thursdays" ) [09:23] Chipaca: heh === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:54] Chipaca: mmh, now that I think, is this stuff tested by spread? or only the global setup? === ikey|zzz is now known as ikey [10:55] pedronis: good point, i could add a spread test variant that doesn't source complete.sh [10:55] pedronis: but [10:55] pedronis: in both cases it'll now be testing the snippets :-) [10:56] Chipaca: so sourcing it and having the snippet at the same time doesn't confuse things? [10:57] nope [10:57] good [10:57] well [10:57] no, but now that i think of it, if you source it it doesn't hit the snippets [10:57] so we want that spread variant [10:57] … which is a lot more work than just adding a variant because it doesn't multiply on its own :-/ [10:58] eh. i could just try the snippets, and test the snippetless in one case [10:58] anyway, i'll get back to it and add something [10:58] right now i have panics to sort out :-) [10:58] silly managers_test [11:00] Chipaca, pedronis, zyga: have you ever seen something like this runtime: pointer 0x11673605 to unused region of span (http://paste.ubuntu.com/25318446/ ) - this is an autopkgtest failure in artful on i386 that is blocking us currently. I will write a forum topic too and investigate further just wanted to hear if you guys have seens this before [11:01] (extra fun, the autopkgtest log is 20mb big and makes poor old firefox very unhappy) [11:03] mvo: niiiice [11:03] mvo: https://github.com/CanonicalLtd/dqlite/issues/7 [11:04] Chipaca: extra points because I can *not* reproduce it in my own autopkgtest setup when I run it inside qemu :( [11:07] mvo: artful is 1.8? [11:07] Chipaca: yes [11:07] “In Go 1.8 the garbage collector has changed so that when you change the value of a pointer field, the old pointer is "shaded". In this case the C code has modified that old pointer so that it is no longer a valid Go pointer, since Go pointers, unlike C pointers, are not permitted to point past the end of an object. The garbage collector is now detecting that fact, and is complaining.” [11:08] mvo: i'm terrible at understanding what in that stacktrace is the code _doing_ that, however :-/ [11:08] Chipaca: hmmmmm, interessting. I would assume this only affect cgo and we have elimiated all that code, no? [11:08] Chipaca: yeah, the trace is hard to read [11:08] mvo: I'm pretty sure we have cgo again [11:09] Chipaca: hm, maybe that was a bad idea then :) [11:09] Chipaca: also funny, only happening on i386, not on amd64 [11:10] mvo: would I be shocked if it were a bug in os/user.a or net.a in go itself? [11:10] mvo: your autopkgtest setup that you run in qemu, is it also artful? [11:11] Chipaca: net.a sounds plausible indeed [11:12] Chipaca: I will run again, maybe I used the wrong image, i did not sleep well last night :( [11:12] mvo: my next question was whether your qemu was multi-cpu, and whether the "real" autopkgtest was also mutli-cpu [11:13] Chipaca: aha, thats a good one, I need to check. If I can reproduce, I can try a cgo-less built and see if it goes away (if we can still do it) [11:13] mvo: probably not, but maybe [11:13] mvo: i _think_ there's a replacement pure-go user.Current() (which 1.6 didn't have, so it would panic) [11:13] mvo: but i'm not 100% [11:14] Chipaca: it looks like we still have the test for it [11:14] mvo: yes, but it's a runtime panic, not a build failure [11:14] Chipaca: tests/main/static [11:14] Chipaca: sure, what I mean is it ought to still be possible to built it without cgo [11:15] Chipaca: thanks a lot for your ideas so far, I will poke at it a bit harder [11:15] mvo: yes! yes. What I meant is that with 1.6 you can build it but user.Current() throws an error [11:15] Chipaca: aha, ok [11:15] Chipaca: sorry, misunderstood. [11:16] mvo: because os/user/lookup_stubs.go's Current(), which is the one that loads without cgo, just returns 'not implemented' [11:16] but that's 1.6 [11:16] fun [11:16] ah [11:16] 1.8's stub is much smarter [11:16] https://golang.org/src/os/user/lookup_stubs.go [11:19] Chipaca: aha, nice [11:19] Chipaca: I keep you updated, thanks again for your help [11:19] * mvo gets lunch [11:20] lunch! a radical concept [12:05] niemeyer: i think this is because i had a slightly older spread, but: http://pastebin.ubuntu.com/25318689/ [12:31] Chipaca: Looks like a Linode issue ("something went wrong") [12:31] Chipaca: I don't recall spread being broken in that way [12:34] mvo: any idea what that crash may be? [12:34] anything happening at that time [12:34] zyga-suse: the one with the weird backtrace? [12:35] yes [12:35] zyga-suse: cgo fighting with the garbage collector [12:35] with gc crashing [12:35] aha [12:35] cgo? [12:35] cgo [12:35] because syscall? [12:35] or because of something else? [12:35] zyga-suse: syscall <=!=> cgo [12:35] ok [12:35] zyga-suse: probably net, but could be os/user [12:36] only bits of cgo we have in snapd [12:36] zyga-suse: I'm writing a forum post now, I can reproduce in an artful i386 vm [12:36] huzzah! [12:37] luck in bad luck [12:37] reproduce != fix :( [12:37] but yeah, progress! [12:37] mvo: we are experts, we can do _anything_ [12:37] (looks thorny though) [12:37] including fixing compiler and GC bugs [12:38] * mvo conjures up a unicorn and a cup of tea [12:38] zyga-suse: indeed we can :) [12:38] * zyga-suse was partially joking about 7 perpendicular lines [12:45] Chipaca: I would hope net is more exercized than os/user [12:45] otoh 386 , might a be a size issue [12:47] mvo: to be clear, if this is what we think it is, it's going to be a slow one to resolve [12:48] as in, quickest involves a ticket with upstream go, and if they agree on our analysis, distropatching [12:49] also do we know if it fails with 18.3 ? seems that's in artful proposed [12:49] 1.8.3? [12:49] yes, sorry [12:49] mvo: could you try with golang from artful proposed? [12:52] Chipaca: yeah, trying some things now. I was not able to reproduce it with git master, maybe related to the packaging in some way [12:52] mvo: ours, or theirs, git master? [12:52] our git master [12:52] of snapd [12:52] (sorry) [12:52] that sounds weird [12:52] apology accepted [12:52] * Chipaca goes for mate [12:53] otoh not unhread of that moving stuff in memory [12:53] fixes this kind of stuff [12:59] niemeyer, I-ll be few minutes late [13:00] ikey: just installed a snap locally on up to date solus, and it hasn't connected any of the interfaces automatically. [13:00] ikey: seen that before? [13:00] don't know enough about them at this point [13:00] i know the gnome ones do that [13:00] but thats a known issue on the forums [13:00] cachio: Ack, thanks for the note [13:01] opengl/home/etc/ all work here [13:01] lemme try another one, maybe this snap at fault [13:01] ok [13:01] none of them connected here, with a snap locally installed - not from the store [13:01] oh locally [13:01] ok that ive not tried [13:02] ok, worked with this second snap, so must be my snap at fault :S [13:02] sorry for the noise :) [13:02] no np at all - i like that its getting testing from folks more qualified than me :)) [13:02] Steady :) [13:03] I'm not _that_ qualified :) [13:03] well im certainly not :p i mashed bits together until they fit [13:03] lol [13:03] solus in a nut shell really.. [13:03] xD [13:03] :) [13:03] gotta ask ... [13:03] which version of solus did you get? [13:03] oh my, I'm not sure I want to admit the level of fail I have made [13:04] s/version/edition/ [13:04] lsb_release says 3 [13:04] gnome/mate/budgie? [13:04] oh, i have all three :D [13:04] oh wow ok lol [13:04] ALL THE VMS [13:04] flexiondotorg casually ignores the others like they dont exist and only sees MATE :p [13:04] I'm currently in the budgie one because that's the OG one IMO [13:05] hah ty [13:05] mate mate mate mate mate [13:05] XD [13:05] (I missed the word "plugs:" in my yaml) [13:05] * ikey just sees the finding nemo seagulls [13:05] o/ [13:05] This is surprisingly not detected by snapcraft! [13:05] * zyga-suse sends regards from his free day [13:05] \o [13:08] * ikey is playing it a bit fast and loose with version numbers lately [13:08] Budgie 10.3.1 -> Budgie 10.4 = change basically everything [13:09] this isnt how minor releases work.. [13:09] then solus 2017.04.18.0 -> 3 [13:09] XD [13:09] * ikey will pretend that the versions were stored in mariadb with VARCHAR(1) hence the increment [13:12] jjohansen: hey [13:12] jjohansen: can you please tell me quickly what is missing in 4.14 wrt apparmor, AFAIR you said you will not get one patch in, can you shed some light on that? [13:15] zyga-suse: it'll be a little while before he starts his day but I can help [13:15] tyhicks: oh, thank you, if you know about this I'm all ears [13:15] zyga-suse: the mediation feature that won't make it in is UNIX domain socket mediation [13:16] zyga-suse: that kernel feature translates to policy rules such as "unix (getattr, shutdown) addr=none," [13:17] zyga-suse: signals, mount, and AF_SOCKET mediation will make it in [13:18] tyhicks: thank you! [13:18] zyga-suse: unfortunately, dbus mediation depends on the UNIX domain socket mediation so "unix" and "dbus" rules will be the only two remaining rules that aren't supported in 14.14 [13:18] s/14.14/4.14/ [13:19] I was wondering if we could do a policy for 4.14 vanilla without this patch around [13:19] or if this patch is huge [13:19] * zyga-suse looks at http://kernel.ubuntu.com/git/ubuntu/ubuntu-artful.git/log/security/apparmor [13:19] aha [13:19] tyhicks: do you know if this is still being discussed upstream or is it just because of merge window timings? [13:20] zyga-suse: merge window timings - jj had some reworking to do on the UNIX mediation implementation that is taking a little longer than what will be possible to land in 4.14 [13:23] ack [13:40] mvo: hey, are you going to be fixing the test errors on https://github.com/snapcore/snapcraft/pull/1419 ? [13:40] PR snapcraft#1419: meta: add `base` as a type and top level property [13:40] or should I bump that to the next release? We are cutting it today === JoshStrobl|zzz is now known as JoshStrobl === sergiusens_ is now known as sergiusens [13:53] niemeyer: btw the first PR for repairs is this one: snapd#3560 [13:53] PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence [13:55] pedronis: Thanks! [13:55] pedronis: Is the numeric order the best one to do reviews also? [13:56] 8-| [13:56] mostly yes [13:56] why is the managers_test hitting the actual real store [13:56] * Chipaca takes a break before coming back to dig [13:56] Chipaca: it usually shouldn't, but maybe somethign has changed [13:57] pedronis: well, I changed something :-D [13:57] Chipaca: it runs the real Ensure [13:57] but … bah. need to dig. [13:57] fwiw [13:57] so unless you are careful it will tend to talk to the real store [13:57] pedronis: yeah but as there's a fake store in there i assumed it was hitting that [13:57] for some stuff [13:58] it depends exactly what you do [13:58] I know I had to tweak again in one of my PRs for example [13:58] * Chipaca goes to take that break [13:58] pedronis: i'll come back with a shovel and a mug of tea [14:01] niemeyer: yes about number for repairs, I have some other PRs around about generic and stuff, of those only snapd#3710 would be nice to land sooner [14:01] PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand [14:09] pedronis: Ok, I'll start from there then [14:12] pedronis: my ensureMisc thing just needed to check CanAutoRefresh != nil :-D [14:16] * Chipaca is Very Good With Names [14:34] popey, I've submitted the gradio PR: https://github.com/haecker-felix/gradio/pull/197 [14:34] PR haecker-felix/gradio#197: add support for snap package building [14:34] diddledan: yay! [14:34] thanks diddledan [14:37] Chipaca: we don't set a Timeout on the client for downloads because if don't know how long it will take, but there's Transport.ResponseHeaderTimeout , do you think it would make sense to set that? [14:38] s/if don't/we don't/ [14:38] pedronis: what is it by default? [14:38] and is it there in 1.6? i thought finer timeout control was post-1.6 [14:38] it's in 1.6 [14:38] cool [14:38] and default is as usual, no timeout [14:41] I mean also in DefaultTransport [14:41] pedronis: no timeout means OS timeout means 30 seconds i think [14:41] so not worth for download [14:41] we just take that [14:42] sgclark: heya https://forum.snapcraft.io/t/change-owner-of-some-kde-apps/1682/2 - could you confirm the account to migrate to please? :) [14:42] pedronis: i think so [14:42] pedronis: for other things i'd love to make it much smaller, but people will get upset [14:43] ok, asked because I need to twek httputil.ClientOpts to control some tls stuff [14:43] pedronis: there were some notes by netflix (or was it backblaze?) about tweaking these timeouts for production, did you see that? [14:43] it's about 6 months old i think [14:43] * sgclark looks [14:43] don't remember [14:44] ah, https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/ [14:44] pedronis: ^ [14:45] popey: done :) [14:46] * popey hugs sgclark [14:46] thanks [14:46] pedronis, niemeyer: if I write a single everything-panics fakeStore, should I put it in store/fake and call it Store? [14:47] Chipaca: we tend to put that sort of stuff in X/Xtest like snap/snaptest or asserts/assertstest [14:47] Chipaca: It's a bit unclear what the use is for something that only panics... not sure if that deserves to be on its own package? [14:47] storetest.FakeStore is at least 20% less cute than fake.Store though :-) [14:48] niemeyer: we have 4 implementations of it already [14:48] niemeyer: :-) [14:48] Chipaca: I said it was unclear to me, not that that it wasn't being used :) [14:48] niemeyer: :-) [14:48] Chipaca: Why do we need those? [14:48] niemeyer: everything that needs a fake store stubs out some of them, and implements the ones it cares about [14:49] Chipaca: I see [14:49] Chipaca: Yeah, what pedronis said then.. sounds like storetest [14:49] niemeyer: overlord/devicestate/devicestate_test.go vs overlord/assertstate/assertstate_test.go vs daemon/api_test.go vs overlord/snapstate/backend_test.go [14:49] Chipaca: storetest.Mock ? [14:49] Chipaca: The issue with fake is that we cannot have fake.Assert, fake.Store, fake.Foo [14:50] Chipaca: Because they all conflict [14:50] niemeyer: unless we had testutil/fake/ [14:50] Chipaca: Yeah, but then you have a massive package which . it.. you get [14:50] *... you get it [14:50] Chipaca: this comes from the stdlib, http/httptest etc [14:50] ok [14:50] TFW you dont make it into this week in snapcraft.. :p [14:50] so what's the thing itself called? [14:51] * Chipaca hugs ikey [14:51] xD [14:51] Chipaca: I don't think we have uppercase Fake stuff [14:51] except in tests/lib/ maybe [14:51] Chipaca: storetest.BrokenStore? :P [14:51] PanicingStore [14:51] storetest.LetsGoShopping [14:52] storetest.Store seems fine :) [14:52] okey doke [14:52] * Chipaca runs with it === chihchun is now known as chihchun_afk [14:58] sergiusens: i missed the errors, sorry, on it now [14:58] * ogra sees https://forum.snapcraft.io/t/snap-dependencies/1699/1 and runs away screaming [15:00] build + runtime dependencies.. [15:00] hm what else can do that.. [15:02] no, this is about actual snap dependencies (things you want pre-installed before a snap can run) [15:02] pretty much going back to dpkg [15:02] (instead of bundling) [15:05] ya swhat i said :p [15:05] heh, sorry ... [15:05] oh don't be - i'm surprised ive gotten this far in life with anyone understanding me xD [15:16] PR snapd#3735 opened: many tests: move all panicing fake store methods to a common place [15:19] sgclark: cprov has moved the snaps over, over to you! :D [15:20] pedronis: #3710 just reviewed.. will have lunch and continue soon [15:22] popey: thanks so much for your help :) [15:22] hey sgclark good to see you around :) [15:23] sgclark: hey, are you also taking care of konversation (the snap is my current irc app)? [15:23] popey: does the lxd snap work on solus? [15:23] hi ogra! yeah I am happily on the neon team and we are snappifying kde apps [15:23] yay [15:24] sergiusens: hi! yes we will be moving to snaps for all apps, in time [15:24] oh, nice! [15:24] much work to be done :) [15:25] sergiusens: no [15:25] oh ? [15:25] why not ? [15:26] http://paste.ubuntu.com/25319481 [15:26] sgclark: great to hear, the contact info in the snap tells me to go to kde.org but I was wondering if there is a better place to report issues? [15:26] my current one now is that opening links is quite slow and I have to choose the handler every time [15:27] popey, hmm ... ouch ... sounds like LD_LIBRABRY_PATH bits missing ? [15:27] popey: that's unfortunate, it would of made me switch for a while ;-) [15:27] *LIBRARY [15:28] ogra: but it works on ubuntu and fedora [15:28] sergiusens: doesn't look like we have konversation, let find out who did it [15:28] me* [15:28] hah [15:28] sergiusens, yeah, must be something missing in snap-configne for classic snaps on solus ... i bet liblxc.so.1 is somewhere undr /snap/lxd/current/ [15:29] *confine ... [15:29] ogra: lxd is not classic [15:29] * ogra cant type anymore [15:29] oh [15:29] indeed [15:29] lxd-support interface ? [15:29] popey: does the client side work? `lxc list` [15:29] yeah, maybe the interface is not connected, but it should [15:29] (does solus have that yet) [15:30] it complains that lxd isnt setup [15:30] solus doesn't have lxd, because, well, it wasn't really in demand.. [15:30] and we kinda have docker, etc.. [15:30] ikey, well, its a snap :) ... just needs the interface enabled [15:30] ikey: there is a snap, just figuring out why it doesn't work [15:31] could try LD_DEBUG=files in the environment before running lxc/lxd [15:31] and find out where the linker is looking [15:31] where it shouldnt [15:31] tis possible the snap is making some multiarch assumption [15:32] sergiusens: ok looks like sitter did it under KDE infra, please report on bugs.kde.org [15:33] ok, sounds good, but sgclark are you taking that under the neon umbrella soon? [15:33]