[02:27] <mup> PR snapd#3734 opened: add packaging for debian-unstable <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3734>
[03:26] <chad_young> I am looking for help with snapcraft (on a working snap), anyone here good at it?
[04:44] <mwhudson> 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] <mwhudson> (and surely not related to the change)
[07:38] <mup> PR snapd#3727 closed: daemon, snapstate: move ensureCore from daemon/api.go into snapstate.go <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3727>
[08:09] <mup> PR snapd#3726 closed: interfaces: backport broadcom-asic-control interface (2.27) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3726>
[08:12] <zyga-suse> mvo: hello
[08:12] <zyga-suse> mvo: I see you are busy already :)
[08:12] <zyga-suse> mvo: I'm off today, just preping the leave the house
[08:12] <mvo> zyga-suse: good morning! yes :)
[08:13] <mvo> zyga-suse: uploading a 2.27.2~rc1 to artful to get the "real" autopkgtest running on it
[08:13] <mvo> zyga-suse: to validate the the i386 416 issue is really fixed
[08:14] <zyga-suse> great
[08:15] <zyga-suse> mvo: if you make a tarball and give me the URL I'd love to check suse later
[08:16] <zyga-suse> re
[08:16] <zyga-suse> sorry I got disconnected
[08:16] <zyga-suse> what is the 416 issue?
[08:18] <mvo> zyga-suse: no worries. there is an autopkgtest failure in artful (and other) on i386 where the server replies 416
[08:19] <mvo> 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] <mvo> zyga-suse: welcome back, did you see anything I wrote before you disconnected?
[08:26] <zyga-suse> ah, I see, I _found_ that problem :D
[08:26] <zyga-suse> zyga-suse: to validate the the i386 416 issue is really fixed
[08:26] <zyga-suse> this is the last message I saw
[08:26] <zyga-suse> do you have the RC tarball already
[08:27] <zyga-suse> and will you change it again to remove the rc wording?
[08:28] <zyga-suse> mvo: to watch later, https://www.youtube.com/watch?v=SPr--u4n8Xo
[08:29] <mvo> zyga-suse: I will change the rc wording hopefully this evening, unfortunately the publishing/autopkgtest runs takes a litte while :(
[08:29] <mvo> 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] <zyga-suse> gary-wzl: can you please merge master into your udev branch now
[08:31] <zyga-suse> gary-wzl: I think everything has landed so we should now see the interesting parts in that diff
[08:32] <mup> PR snapd#3714 closed: interfaces: a bunch of interfaces test improvement <Created by adglkh> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3714>
[08:32] <gary-wzl> zyga-suse: Oh nice. working on it now
[08:32] <zyga-suse> thank you!
[08:33] <gary-wzl> I just happened to ping you as there's only one(bit) PR left to merge. You did it
[08:33] <gary-wzl> Thanks!
[08:37] <zyga-suse> mvo: do watch that, it's interesting
[08:37] <mvo> zyga-suse: you remember that error when snap/snapd versions got out of sync? iirc you had that at some point
[08:37] <zyga-suse> yes
[08:38] <mvo> 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] <zyga-suse> "crazy insecure lunacy of appimage"
[08:38] <zyga-suse> oh boy, shots fired
[08:39] <zyga-suse> mvo: mmm, is it the case where snapd is new and snap is old?
[08:39] <mvo> zyga-suse: correct
[08:40] <zyga-suse> 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] <zyga-suse> and then I think it will happen
[08:40] <zyga-suse> I know we allow the configure to fail
[08:40] <zyga-suse> but there must be a real way to make this happen as it runs in the wild
[08:40] <mvo> zyga-suse: yeah, I did pretty much that and it restarts back to the right version for me
[08:40] <zyga-suse> was it also related to changelog and stale version number?
[08:40] <zyga-suse> oh? it restarts?
[08:41] <mvo> 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] <zyga-suse> mmm
[08:41] <zyga-suse> indeed
[08:41] <zyga-suse> is that also the case that gustavo hit?
[08:41] <zyga-suse> I mean, for him it did _not_ restart
[08:41] <mvo> zyga-suse: I will push the test soon, there must be something I am missing, as gustavo hit it too
[08:41] <zyga-suse> what happened there?
[08:41] <mvo> zyga-suse: correct
[08:42] <mvo> 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] <zyga-suse> I see, sorry I'm not much of a help
[08:48] <mup> Bug #1627643 changed: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>
[08:48] <mup> Bug #1678076 changed: console-conf crashes with eth0 and wlan0 on Pi 3 <Snappy:New> <subiquity (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1678076>
[08:48] <mvo> zyga-suse: no worries, I keep digging
[08:51] <mup> Bug #1627643 opened: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>
[09:03]  * zyga-suse goes to the park with his family
[09:03] <zyga-suse> good luck mvo, please PM me on telegram with the 2.27.2 URL
[09:03] <zyga-suse> I'll release suse then
[09:16] <Chipaca> 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] <Chipaca> pedronis: ^^^ that's a joke by the way
[09:17]  * Chipaca has had too little sleep
[09:21] <ogra> oh. lovely !
[09:21] <ogra> https://askubuntu.com/questions/938606/dwarf-fortress-starting-during-apt-get-upgrade
[09:21] <ogra> (nearly as good as "libreoffice only prints on thursdays" )
[09:23] <pedronis> Chipaca: heh
[10:54] <pedronis> Chipaca: mmh, now that I think, is this stuff tested by spread?  or only the global setup?
[10:55] <Chipaca> pedronis: good point, i could add a spread test variant that doesn't source complete.sh
[10:55] <Chipaca> pedronis: but
[10:55] <Chipaca> pedronis: in both cases it'll now be testing the snippets :-)
[10:56] <pedronis> Chipaca: so sourcing it and having the snippet at the same time doesn't confuse things?
[10:57] <Chipaca> nope
[10:57] <pedronis> good
[10:57] <Chipaca> well
[10:57] <Chipaca> no, but now that i think of it, if you source it it doesn't hit the snippets
[10:57] <Chipaca> so we want that spread variant
[10:57] <Chipaca> … which is a lot more work than just adding a variant because it doesn't multiply on its own :-/
[10:58] <Chipaca> eh. i could just try the snippets, and test the snippetless in one case
[10:58] <Chipaca> anyway, i'll get back to it and add something
[10:58] <Chipaca> right now i have panics to sort out :-)
[10:58] <Chipaca> silly managers_test
[11:00] <mvo> 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] <mvo> (extra fun, the autopkgtest log is 20mb big and makes poor old firefox very unhappy)
[11:03] <Chipaca> mvo: niiiice
[11:03] <Chipaca> mvo: https://github.com/CanonicalLtd/dqlite/issues/7
[11:04] <mvo> Chipaca: extra points because I can *not* reproduce it in my own autopkgtest setup when I run it inside qemu :(
[11:07] <Chipaca> mvo: artful is 1.8?
[11:07] <mvo> Chipaca: yes
[11:07] <Chipaca> “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] <Chipaca> mvo: i'm terrible at understanding what in that stacktrace is the code _doing_ that, however :-/
[11:08] <mvo> Chipaca: hmmmmm, interessting. I would assume this only affect cgo and we have elimiated all that code, no?
[11:08] <mvo> Chipaca: yeah, the trace is hard to read
[11:08] <Chipaca> mvo: I'm pretty sure we have cgo again
[11:09] <mvo> Chipaca: hm, maybe that was a bad idea then :)
[11:09] <mvo> Chipaca: also funny, only happening on i386, not on amd64
[11:10] <Chipaca> mvo: would I be shocked if it were a bug in os/user.a or net.a in go itself?
[11:10] <Chipaca> mvo: your autopkgtest setup that you run in qemu, is it also artful?
[11:11] <mvo> Chipaca: net.a sounds plausible indeed
[11:12] <mvo> Chipaca: I will run again, maybe I used the wrong image, i did not sleep well last night :(
[11:12] <Chipaca> mvo: my next question was whether your qemu was multi-cpu, and whether the "real" autopkgtest was also mutli-cpu
[11:13] <mvo> 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] <Chipaca> mvo: probably not, but maybe
[11:13] <Chipaca> mvo: i _think_ there's a replacement pure-go user.Current() (which 1.6 didn't have, so it would panic)
[11:13] <Chipaca> mvo: but i'm not 100%
[11:14] <mvo> Chipaca: it looks like we still have the test for it
[11:14] <Chipaca> mvo: yes, but it's a runtime panic, not a build failure
[11:14] <mvo> Chipaca: tests/main/static
[11:14] <mvo> Chipaca: sure, what I mean is it ought to still be possible to built it without cgo
[11:15] <mvo> Chipaca: thanks a lot for your ideas so far, I will poke at it a bit harder
[11:15] <Chipaca> mvo: yes! yes. What I meant is that with 1.6 you can build it but user.Current() throws an error
[11:15] <mvo> Chipaca: aha, ok
[11:15] <mvo> Chipaca: sorry, misunderstood.
[11:16] <Chipaca> mvo: because os/user/lookup_stubs.go's Current(), which is the one that loads without cgo, just returns 'not implemented'
[11:16] <Chipaca> but that's 1.6
[11:16] <mvo> fun
[11:16] <Chipaca> ah
[11:16] <Chipaca> 1.8's stub is much smarter
[11:16] <Chipaca> https://golang.org/src/os/user/lookup_stubs.go
[11:19] <mvo> Chipaca: aha, nice
[11:19] <mvo> Chipaca: I keep you updated, thanks again for your help
[11:19]  * mvo gets lunch
[11:20] <Chipaca> lunch! a radical concept
[12:05] <Chipaca> niemeyer: i think this is because i had a slightly older spread, but: http://pastebin.ubuntu.com/25318689/
[12:31] <niemeyer> Chipaca: Looks like a Linode issue ("something went wrong")
[12:31] <niemeyer> Chipaca: I don't recall spread being broken in that way
[12:34] <zyga-suse> mvo: any idea what that crash may be?
[12:34] <zyga-suse> anything happening at that time
[12:34] <Chipaca> zyga-suse: the one with the weird backtrace?
[12:35] <zyga-suse> yes
[12:35] <Chipaca> zyga-suse: cgo fighting with the garbage collector
[12:35] <zyga-suse> with gc crashing
[12:35] <zyga-suse> aha
[12:35] <zyga-suse> cgo?
[12:35] <Chipaca> cgo
[12:35] <zyga-suse> because syscall?
[12:35] <zyga-suse> or because of something else?
[12:35] <Chipaca> zyga-suse: syscall <=!=> cgo
[12:35] <zyga-suse> ok
[12:35] <Chipaca> zyga-suse: probably net, but could be os/user
[12:36] <Chipaca> only bits of cgo we have in snapd
[12:36] <mvo> zyga-suse: I'm writing a forum post now, I can reproduce in an artful i386 vm
[12:36] <Chipaca> huzzah!
[12:37] <zyga-suse> luck in bad luck
[12:37] <mvo> reproduce != fix :(
[12:37] <mvo> but yeah, progress!
[12:37] <zyga-suse> mvo: we are experts, we can do _anything_
[12:37] <mvo> (looks thorny though)
[12:37] <zyga-suse> including fixing compiler and GC bugs
[12:38]  * mvo conjures up a unicorn and a cup of tea
[12:38] <mvo> zyga-suse: indeed we can :)
[12:38]  * zyga-suse was partially joking about 7 perpendicular lines
[12:45] <pedronis> Chipaca: I would hope net is more exercized than os/user
[12:45] <pedronis> otoh 386 , might a be a size issue
[12:47] <Chipaca> mvo: to be clear, if this is what we think it is, it's going to be a slow one to resolve
[12:48] <Chipaca> as in, quickest involves a ticket with upstream go, and if they agree on our analysis, distropatching
[12:49] <pedronis> also do we know if it fails with 18.3 ?  seems that's in artful proposed
[12:49] <Chipaca> 1.8.3?
[12:49] <pedronis> yes, sorry
[12:49] <Chipaca> mvo: could you try with golang from artful proposed?
[12:52] <mvo> 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] <Chipaca> mvo: ours, or theirs, git master?
[12:52] <mvo> our git master
[12:52] <mvo> of snapd
[12:52] <mvo> (sorry)
[12:52] <pedronis> that sounds weird
[12:52] <Chipaca> apology accepted
[12:52]  * Chipaca goes for mate
[12:53] <pedronis> otoh not unhread of that moving stuff in memory
[12:53] <pedronis> fixes this kind of stuff
[12:59] <cachio> niemeyer, I-ll be few minutes late
[13:00] <popey> ikey: just installed a snap locally on up to date solus, and it hasn't connected any of the interfaces automatically.
[13:00] <popey> ikey: seen that before?
[13:00] <ikey> don't know enough about them at this point
[13:00] <ikey> i know the gnome ones do that
[13:00] <ikey> but thats a known issue on the forums
[13:00] <niemeyer> cachio: Ack, thanks for the note
[13:01] <ikey> opengl/home/etc/ all work here
[13:01] <popey> lemme try another one, maybe this snap at fault
[13:01] <ikey> ok
[13:01] <popey> none of them connected here, with a snap locally installed - not from the store
[13:01] <ikey> oh locally
[13:01] <ikey> ok that ive not tried
[13:02] <popey> ok, worked with this second snap, so must be my snap at fault :S
[13:02] <popey> sorry for the noise :)
[13:02] <ikey> no np at all - i like that its getting testing from folks more qualified than me :))
[13:02] <popey> Steady :)
[13:03] <popey> I'm not _that_ qualified :)
[13:03] <ikey> well im certainly not :p i mashed bits together until they fit
[13:03] <ikey> lol
[13:03] <ikey> solus in a nut shell really..
[13:03] <ikey> xD
[13:03] <popey> :)
[13:03] <ikey> gotta ask ...
[13:03] <ikey> which version of solus did you get?
[13:03] <popey> oh my, I'm not sure I want to admit the level of fail I have made
[13:04] <ikey> s/version/edition/
[13:04] <popey> lsb_release says 3
[13:04] <ikey> gnome/mate/budgie?
[13:04] <popey> oh, i have all three :D
[13:04] <ikey> oh wow ok lol
[13:04] <popey> ALL THE VMS
[13:04] <ikey> flexiondotorg casually ignores the others like they dont exist and only sees MATE :p
[13:04] <popey> I'm currently in the budgie one because that's the OG one IMO
[13:05] <ikey> hah ty
[13:05] <flexiondotorg> mate mate mate mate mate
[13:05] <ikey> XD
[13:05] <popey> (I missed the word "plugs:" in my yaml)
[13:05]  * ikey just sees the finding nemo seagulls
[13:05] <zyga-suse> o/
[13:05] <popey> This is surprisingly not detected by snapcraft!
[13:05]  * zyga-suse sends regards from his free day 
[13:05] <ikey> \o
[13:08]  * ikey is playing it a bit fast and loose with version numbers lately
[13:08] <ikey> Budgie 10.3.1 -> Budgie 10.4 = change basically everything
[13:09] <ikey> this isnt how minor releases work..
[13:09] <ikey> then solus 2017.04.18.0 -> 3
[13:09] <ikey> XD
[13:09]  * ikey will pretend that the versions were stored in mariadb with VARCHAR(1) hence the increment
[13:12] <zyga-suse> jjohansen: hey
[13:12] <zyga-suse> 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] <tyhicks> zyga-suse: it'll be a little while before he starts his day but I can help
[13:15] <zyga-suse> tyhicks: oh, thank you, if you know about this I'm all ears
[13:15] <tyhicks> zyga-suse: the mediation feature that won't make it in is UNIX domain socket mediation
[13:16] <tyhicks> zyga-suse: that kernel feature translates to policy rules such as "unix (getattr, shutdown) addr=none,"
[13:17] <tyhicks> zyga-suse: signals, mount, and AF_SOCKET mediation will make it in
[13:18] <zyga-suse> tyhicks: thank you!
[13:18] <tyhicks> 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] <tyhicks> s/14.14/4.14/
[13:19] <zyga-suse> I was wondering if we could do a policy for 4.14 vanilla without this patch around
[13:19] <zyga-suse> 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] <zyga-suse> aha
[13:19] <zyga-suse> tyhicks: do you know if this is still being discussed upstream or is it just because of merge window timings?
[13:20] <tyhicks> 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] <zyga-suse> ack
[13:40] <sergiusens_> mvo: hey, are you going to be fixing the test errors on https://github.com/snapcore/snapcraft/pull/1419 ?
[13:40] <mup> PR snapcraft#1419: meta: add `base` as a type and top level property <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1419>
[13:40] <sergiusens_> or should I bump that to the next release? We are cutting it today
[13:53] <pedronis> niemeyer: btw the first PR for repairs is this one: snapd#3560
[13:53] <mup> PR snapd#3560: cmd/snap-repair: implement most logic to get the next repair to run/retry in a brand sequence <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3560>
[13:55] <niemeyer> pedronis: Thanks!
[13:55] <niemeyer> pedronis: Is the numeric order the best one to do reviews also?
[13:56] <Chipaca> 8-|
[13:56] <pedronis> mostly yes
[13:56] <Chipaca> why is the managers_test hitting the actual real store
[13:56]  * Chipaca takes a break before coming back to dig
[13:56] <pedronis> Chipaca: it usually shouldn't, but maybe somethign has changed
[13:57] <Chipaca> pedronis: well, I changed something :-D
[13:57] <pedronis> Chipaca: it runs the real Ensure
[13:57] <Chipaca> but … bah. need to dig.
[13:57] <pedronis> fwiw
[13:57] <pedronis> so unless you are careful it will tend to talk to the real store
[13:57] <Chipaca> pedronis: yeah but as there's a fake store in there i assumed it was hitting that
[13:57] <pedronis> for some stuff
[13:58] <pedronis> it depends exactly what you do
[13:58] <pedronis> I know I had to tweak again in one of my PRs for example
[13:58]  * Chipaca goes to take that break
[13:58] <Chipaca> pedronis: i'll come back with a shovel and a mug of tea
[14:01] <pedronis> 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] <mup> PR snapd#3710: many: allow and support serials signed by the 'generic' authority instead of the brand <Created by pedronis> <https://github.com/snapcore/snapd/pull/3710>
[14:09] <niemeyer> pedronis: Ok, I'll start from there then
[14:12] <Chipaca> pedronis: my ensureMisc thing just needed to check CanAutoRefresh != nil :-D
[14:16]  * Chipaca is Very Good With Names
[14:34] <diddledan> popey, I've submitted the gradio PR: https://github.com/haecker-felix/gradio/pull/197
[14:34] <mup> PR haecker-felix/gradio#197: add support for snap package building <Created by diddledan> <https://github.com/haecker-felix/gradio/pull/197>
[14:34] <popey> diddledan: yay!
[14:34] <popey> thanks diddledan
[14:37] <pedronis> 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] <pedronis> s/if don't/we don't/
[14:38] <Chipaca> pedronis: what is it by default?
[14:38] <Chipaca> and is it there in 1.6? i thought finer timeout control was post-1.6
[14:38] <pedronis> it's in 1.6
[14:38] <Chipaca> cool
[14:38] <pedronis> and default is as usual, no timeout
[14:41] <pedronis> I mean also in DefaultTransport
[14:41] <Chipaca> pedronis: no timeout means OS timeout means 30 seconds i think
[14:41] <pedronis> so not worth for download
[14:41] <pedronis> we just take that
[14:42] <popey> 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] <Chipaca> pedronis: i think so
[14:42] <Chipaca> pedronis: for other things i'd love to make it much smaller, but people will get upset
[14:43] <pedronis> ok, asked because I need to twek httputil.ClientOpts to control some tls stuff
[14:43] <Chipaca> pedronis: there were some notes by netflix (or was it backblaze?) about tweaking these timeouts for production, did you see that?
[14:43] <Chipaca> it's about 6 months old i think
[14:43]  * sgclark looks
[14:43] <pedronis> don't remember
[14:44] <Chipaca> ah, https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/
[14:44] <Chipaca> pedronis: ^
[14:45] <sgclark> popey: done :)
[14:46]  * popey hugs sgclark 
[14:46] <popey> thanks
[14:46] <Chipaca> pedronis, niemeyer: if I write a single everything-panics fakeStore, should I put it in store/fake and call it Store?
[14:47] <pedronis> Chipaca: we tend to put that sort of stuff in X/Xtest  like snap/snaptest   or asserts/assertstest
[14:47] <niemeyer> 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] <Chipaca> storetest.FakeStore is at least 20% less cute than fake.Store though :-)
[14:48] <Chipaca> niemeyer: we have 4 implementations of it already
[14:48] <Chipaca> niemeyer: :-)
[14:48] <niemeyer> Chipaca: I said it was unclear to me, not that that it wasn't being used :)
[14:48] <Chipaca> niemeyer: :-)
[14:48] <niemeyer> Chipaca: Why do we need those?
[14:48] <Chipaca> niemeyer: everything that needs a fake store stubs out some of them, and implements the ones it cares about
[14:49] <niemeyer> Chipaca: I see
[14:49] <niemeyer> Chipaca: Yeah, what pedronis said then.. sounds like storetest
[14:49] <Chipaca> 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] <pedronis> Chipaca: storetest.Mock  ?
[14:49] <niemeyer> Chipaca: The issue with fake is that we cannot have fake.Assert, fake.Store, fake.Foo
[14:50] <niemeyer> Chipaca: Because they all conflict
[14:50] <Chipaca> niemeyer: unless we had testutil/fake/<stuff>
[14:50] <niemeyer> Chipaca: Yeah, but then you have a massive package which . it.. you get
[14:50] <niemeyer> *... you get it
[14:50] <pedronis> Chipaca: this comes from the stdlib,    http/httptest etc
[14:50] <Chipaca> ok
[14:50] <ikey> TFW you dont make it into this week in snapcraft.. :p
[14:50] <Chipaca> so what's the thing itself called?
[14:51]  * Chipaca hugs ikey 
[14:51] <ikey> xD
[14:51] <pedronis> Chipaca: I don't think we have uppercase Fake stuff
[14:51] <pedronis> except in tests/lib/ maybe
[14:51] <niemeyer> Chipaca: storetest.BrokenStore? :P
[14:51] <Chipaca> PanicingStore
[14:51] <Chipaca> storetest.LetsGoShopping
[14:52] <niemeyer> storetest.Store seems fine :)
[14:52] <Chipaca> okey doke
[14:52]  * Chipaca runs with it
[14:58] <mvo> 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] <ikey> build + runtime dependencies..
[15:00] <ikey> hm what else can do that..
[15:02] <ogra> no, this is about actual snap dependencies (things you want pre-installed before a snap can run)
[15:02] <ogra> pretty much going back to dpkg
[15:02] <ogra> (instead of bundling)
[15:05] <ikey> ya swhat i said :p
[15:05] <ogra> heh, sorry ...
[15:05] <ikey> oh don't be - i'm surprised ive gotten this far in life with anyone understanding me xD
[15:16] <mup> PR snapd#3735 opened: many tests: move all panicing fake store methods to a common place <Created by chipaca> <https://github.com/snapcore/snapd/pull/3735>
[15:19] <popey> sgclark: cprov has moved the snaps over, over to you! :D
[15:20] <niemeyer> pedronis: #3710 just reviewed.. will have lunch and continue soon
[15:22] <sgclark> popey: thanks so much for your help :)
[15:22] <ogra> hey sgclark good to see you around :)
[15:23] <sergiusens> sgclark: hey, are you also taking care of konversation (the snap is my current irc app)?
[15:23] <sergiusens> popey:  does the lxd snap work on solus?
[15:23] <sgclark> hi ogra! yeah I am happily on the neon team and we are snappifying kde apps
[15:23] <ogra> yay
[15:24] <sgclark> sergiusens: hi! yes we will be moving to snaps for all apps, in time
[15:24] <sergiusens> oh, nice!
[15:24] <sgclark> much work to be done :)
[15:25] <popey> sergiusens: no
[15:25] <ogra> oh ?
[15:25] <ogra> why not ?
[15:26] <popey> http://paste.ubuntu.com/25319481
[15:26] <sergiusens> 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] <sergiusens> my current one now is that opening links is quite slow and I have to choose the handler every time
[15:27] <ogra> popey, hmm ... ouch ... sounds like LD_LIBRABRY_PATH bits missing ?
[15:27] <sergiusens> popey: that's unfortunate, it would of made me switch for a while ;-)
[15:27] <ogra> *LIBRARY
[15:28] <sergiusens> ogra: but it works on ubuntu and fedora
[15:28] <sgclark> sergiusens: doesn't look like we have konversation, let find out who did it
[15:28] <sgclark> me*
[15:28] <sergiusens> hah
[15:28] <ogra> 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] <ogra> *confine ...
[15:29] <sergiusens> ogra: lxd is not classic
[15:29]  * ogra cant type anymore 
[15:29] <ogra> oh
[15:29] <ogra> indeed
[15:29] <ogra> lxd-support interface ?
[15:29] <sergiusens> popey: does the client side work? `lxc list`
[15:29] <sergiusens> yeah, maybe the interface is not connected, but it should
[15:29] <ogra> (does solus have that yet)
[15:30] <popey> it complains that lxd isnt setup
[15:30] <ikey> solus doesn't have lxd, because, well, it wasn't really in demand..
[15:30] <ikey> and we kinda have docker, etc..
[15:30] <ogra> ikey, well, its a snap :) ... just needs the interface enabled
[15:30] <sergiusens> ikey: there is a snap, just figuring out why it doesn't work
[15:31] <ikey> could try LD_DEBUG=files in the environment before running lxc/lxd
[15:31] <ikey> and find out where the linker is looking
[15:31] <ikey> where it shouldnt
[15:31] <ikey> tis possible the snap is making some multiarch assumption
[15:32] <sgclark> sergiusens: ok looks like sitter did it under KDE infra, please report on bugs.kde.org
[15:33] <sergiusens> ok, sounds good, but sgclark are you taking that under the neon umbrella soon?
[15:33] <popey> http://paste.ubuntu.com/25319510
[15:33] <sgclark> neon is under kde umbrella :) so will remain the same
[15:33] <sgclark> sergiusens: ^
[15:33] <sergiusens> got it
[15:35] <sergiusens> popey: I guess I'll be installing solus and figuring it out unles I accidentally ping stgraber and he fixes it before I can blink ;-)
[15:37] <popey> hehe
[15:44] <pedronis> niemeyer: answered
[15:49] <ogra> jdstrand, hmm http://paste.ubuntu.com/25319575/ ... shouldnt that suggest the kernel-module-control interface instead of talking about env vars ?
[15:50] <ogra> ( i wonder what any of the vars would help here )
[16:13] <niemeyer> pedronis: certified is such a strange name for this idea
[16:13] <niemeyer> pedronis: Too late I guess
[16:13] <niemeyer> It really means "verified"
[16:16] <pedronis> yes
[16:16] <pedronis> niemeyer: I think we use it so little that we could change it, but it's a bit of a separate issue
[16:17] <niemeyer> Yeah
[16:19] <jdstrand> ogra: yes, it should. note that snappy-debug doesn't have AI so it has to be taught this stuff ;)
[16:19] <jdstrand> ogra: I'll take care of that
[16:19] <ogra> thanks :)
[16:22] <pedronis> niemeyer: anything else? as I wrote  the other changes around assertstest, NewStoreStack I would prefer to do them in a follow up
[16:22] <niemeyer> pedronis: No, per note there LGTM once you're happy
[16:23] <niemeyer> pedronis: The core change is sensible
[16:23] <pedronis> ok, I fixed the error now, then I'll merge, and rework NewStoreStack in a different PR
[16:31] <diddledan> just waiting on the review to add this to the store: https://github.com/diddledan/gnome-twitch-snap
[16:32] <mup> PR snapd#3568 closed: snapctl: add new `snapctl internal configure-core`  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3568>
[16:32] <mup> PR snapd#3594 closed: corecfg: add proxy configuration via `snap set core proxy.{http,https,ftp}=...` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3594>
[16:32] <diddledan> needs someone to approve my coopting of the name :-)
[17:01] <diddledan> popey: flexiondotorg: I've just imported gimp into snapcrafters org and set the autobuilder running
[17:13] <popey> diddledan: nice!
[17:19] <diddledan> I don't believe I can change the ownership in the store, though, so I'll have to leave that up to one of you, popey
[17:19] <mup> PR snapd#3710 closed: many: allow and support serials signed by the 'generic' authority instead of the brand <Reviewed> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3710>
[17:21] <zyga-suse> re
[17:21]  * zyga-suse is home
[17:21] <ogra> shouldnt you then be zyga-home ?
[17:21] <ogra> :P
[17:22] <zyga-suse> :-)
[17:22] <zyga-suse> I was in a tank today
[17:22] <zyga-suse> I should have joined as `zyga-tank`
[17:22] <popey> diddledan: who currently owns it?
[17:22] <popey> diddledan: you can make a request in the store category and likely cprov will action it :)
[17:22] <popey> (on the forum)
[17:23] <diddledan> I own the name in the store. so it just needs moving to snapcrafters. the git repo is moved now as I do have access to do that bit :-)
[17:23] <popey> kk, so yeah, make the request and it'll get done
[17:26] <diddledan> new snap :-) https://forum.snapcraft.io/t/call-for-testing-gnome-twitch/1701
[17:26] <popey> \o/
[17:28] <popey> diddledan: need to add "snap install gnome-3-24" to your instructions
[17:29] <diddledan> well caught. that's fixed now
[17:29] <popey> ooh, the page just dynamically changed when you edited it
[17:29] <diddledan> it's a cool forum!
[17:30] <popey> gonna post on the snapcraft socials ;)
[17:32] <diddledan> ok, I've hit a snag - it doesn't work strict with dbus issue.. let me see if I can fix that
[17:32] <popey> ok, will delay the post, just let me know when you want me to release it
[17:33] <diddledan> building now
[17:34]  * diddledan twiddles thumbs while compilation churns
[17:34] <popey> http://imgur.com/a/8gLad wanna embed that into your post to make it pretty? :)
[17:35] <popey> if you download it and just drag it into the edit window for the post it should work
[17:35] <diddledan> danke
[17:35] <diddledan> done
[17:35] <diddledan> the image is done, I mean
[17:35] <popey> np
[17:36] <diddledan> still building the fixed snap
[17:36] <mup> PR snapcraft#1419 closed: meta: add `base` as a type and top level property <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1419>
[17:37]  * diddledan sits patiently: ┏(-_-)┛┗(-_-﻿)┓┗(-_-)┛┏(-_-)┓
[17:37] <popey> Throw some coal in the launchpad builders
[17:38] <diddledan> https://imgs.xkcd.com/comics/compiling.png
[17:38] <mup> PR snapd#3736 opened: apparmor: pass --quiet to parser on load unless SNAPD_DEBUG is set <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3736>
[17:40] <jdstrand> stgraber: fyi ^
[17:41] <zyga-suse> jdstrand: +1
[17:43] <mvo> sergiusens: thank you so much
[17:43] <diddledan> "human review required due to 'deny-connection' constraint for 'slot-attributes' from base declaration declaration-snap-v2_slots_deny-connection (dbus-gnome-twitch, dbus) "
[17:44] <pedronis> Chipaca: I see, I thought a couple of times that snapstate.Store(), StorService etc should move to a something smaller, more specific under overlord  but never acted on it so farbut
[17:48] <pedronis> Chipaca: all places you change import snapstate anyway
[17:48] <cprov> diddledan, popey: gimp name transferred to snapcrafters.
[17:48] <Chipaca> pedronis: yes, but what if snapstate wants to import it
[17:48] <diddledan> thanks cprov
[17:48] <pedronis> Chipaca: ?
[17:49] <pedronis> Chipaca: snapstate_test you mean ?
[17:49] <Chipaca> ah
[17:49] <pedronis> it probably does but is not snapstate
[17:49] <Chipaca> :-)
[17:49] <Chipaca> fair 'nuf
[17:49] <Chipaca> i'll fix it (later)
[17:49] <Chipaca> right now i'm EODing with extreme prejudice
[17:49] <Chipaca> :-)
[17:54] <diddledan> just waiting on a manual review, popey. I've tested it locally and strict works, but it won't publish in the store until someone OKs the dbus socket
[17:58] <jhobbs> can someone look at https://bugs.launchpad.net/snapd/+bug/1710933 please? it seems like 2.26.10 has a regression preventing snapd from working in lxd containers
[17:58] <mup> Bug #1710933: 2.26.10: snapd doesn't start in a container <cdo-qa> <cdo-qa-blocker> <snapd:New> <https://launchpad.net/bugs/1710933>
[17:59] <pedronis> mvo: fyi, my first 'generic' PR is in now, so nothing needs reverting for 2.28
[18:05] <niemeyer> Going outside for a bit.. back soon
[18:09] <mup> PR snapcraft#1483 closed: lxd: path cannot have extra forward slashes <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1483>
[18:12] <popey> niemeyer: liked the presentation of your ideas as a video. Do you have a green screen? Seemed pretty professionally done!
[18:12] <mup> PR snapcraft#1479 closed: rosdep: add support for multiple dependency types <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1479>
[18:15] <popey> jdstrand: i just updated the slot definition for gnome-twitch for diddledan - could you verify I did the right thing? (Not done slots before)
[18:15] <popey> jdstrand: https://dashboard.snapcraft.io/dev/snaps/8171/
[18:53] <jjohansen> zyga-suse: the unix patch (in ubuntu) isn't small, but mostly self contained. However the version going upstream depends on the typesplitting work which is large.
[18:53] <zyga-suse> hey :)
[18:53] <zyga-suse> jjohansen: do you have any patches for refrence? I would like to encourage some distributions to ship that on top of 4.14
[18:54] <zyga-suse> can you tell me more about typesplitting?
[18:54] <jjohansen> zyga-suse: hey, sorry I just haven't been able to finish this stuff up
[18:54] <jjohansen> zyga-suse: the patches are a wip atm, I am hoping to have something to RFC by next week, that way I can get the upstream discussion started early
[18:55] <zyga-suse> jjohansen: no worries, I understand
[18:55] <jjohansen> zyga-suse: we need to be caching the type on objects, not just the domain label
[18:55] <zyga-suse> I see
[18:56] <jjohansen> currently (in ubuntu) we get around this problem by caching the unix socket path (a second time, ugly hack) and revalidating
[18:56] <jjohansen> that isn't going to work for other sockets, and isn't going to fly upstream
[18:57] <jjohansen> it also has a few artifacts in some corner cases
[18:59] <jjohansen> basically if you think of apparmor in terms of TE (selinux), we use the domain (task) label, and look up a set of conditionals (path, ...) to find permissions
[18:59] <jjohansen> that set of conditionals can resolved down to a type (in selinux terms). And we can store that on the object so that when we hit a revalidation case, where some of our conditionals are no longer available we can find the correct permissions
[19:00] <jjohansen> basically the LSM is more structured to selinux and we need to do somethings to make apparmor more amenable to that upstream structure
[19:02] <zyga-suse> I see
[19:02] <zyga-suse> interesting explanation, I don't know the kernel parts that well but I'm eager to lern
[19:03] <zyga-suse> learn*
[19:06] <niemeyer> popey: Thanks! I made a green screen at home for about 3USD :)
[19:07] <popey> hah, excellent
[19:07] <popey> OBS?
[19:07] <niemeyer> popey: Three layers of nonwoven fabric on an old whiteboard frame
[19:08] <niemeyer> popey: https://goo.gl/photos/RWEU7jCzBa7Cdnp78
[19:09] <popey> nice
[19:09] <popey> totally doing this
[19:13] <diddledan> what are you two scheming?!
[19:15] <popey> hiding the crap behind my head when doing videos :D
[19:15] <niemeyer> :)
[19:16] <niemeyer> Not only that, but putting more interesting crap there! :P
[19:17] <popey> true
[19:25] <jdstrand> popey: looking. note that for snap declarations I recommend you come to the security team. they can be tricky to get right (though the one you did isn't) and our reviewers tooling doesn't help you (yet)
[19:28] <jdstrand> popey: it looks fine. at this point you should scroll to the bottom of review page, add a comment like "Granting use of the well-known dbus name 'com.vinszent.GnomeTwitch' to the snap", then click 'Run the automated review again"
[19:29] <popey> thanks jdstrand
[19:29] <popey> noted for next time :)
[19:30] <jdstrand> popey: I didn't do the comment or button pushing for this one
[19:30] <jdstrand> popey: I see a bunch of snaps that came in today. I'll take a look. I think the are all dbus related
[19:30] <popey> excellent
[19:30] <popey> i hit the button...
[19:31] <jdstrand> cool
[19:31] <diddledan> \o/
[19:32]  * diddledan releases to beta
[19:32] <diddledan> done
[19:32] <popey> want me to release a social post?
[19:32] <diddledan> ok, you can fire the social now :-)
[19:32] <popey> \o/
[19:32]  * popey gets the coal
[19:32] <jdstrand> popey: I want to ask oSoMoN a question about chromium when he comes online, so am leaving that
[19:32] <popey> kk
[19:33] <popey> diddledan: sent
[19:33] <diddledan> I see it
[19:37] <ikey> adwaita
[19:37]  * ikey shudders
[19:37] <popey> You liked my choice of desktop to use in the screenshot? :)
[19:38] <ikey> forgive me for saying but is that solus 3? :P
[19:38] <popey> ya :)
[19:38] <ikey> looks like solus 2017.04.18.0
[19:38] <popey> fix ur version numbers
[19:38] <ikey> or did you rejigger it?
[19:38] <ikey> XD
[19:38] <popey> #blamepopey
[19:38] <ikey> but yeah nice use of budgie :]
[19:38] <popey> no, it's whatever I instaleld and updated
[19:38] <popey> This is one thing I love about posting on the snapcraft social stuff, we get to use whatever desktop is fun today :)
[19:38] <ikey> Solus 3 https://solus-project.com/imgs/posts/2017/08/Budgie.jpg
[19:39] <ikey> xD
[19:39] <popey> odd
[19:39] <popey> i only installed it last week or so
[19:39] <popey> and updated as per the software doohdah
[19:39] <ikey> yeah it was released around 4 this morning
[19:39] <popey> hahah
[19:39] <popey> oookay
[19:39] <ikey> its ok you'll still be updated on "Solus 3"
[19:39] <popey> gotcha
[19:39] <ikey> we used a new branding pkg in that one
[19:39] <ikey> plus this is cool because it means you're testing linux-lts (4.9.43)
[19:40] <ikey> so we get both kernels tested now
[19:40] <ikey> :]
[19:41] <jdstrand> popey: fyi, I'm leaving https://dashboard.snapcraft.io/dev/snaps/8122/rev/8/ for the advocacy team
[19:41] <jdstrand> I guess could leave a comment to ask to post something to the forum...
[19:42] <popey> I'll add a card for it
[19:42] <popey> will look in the morning
[19:48] <popey> ikey: the downside is.. people expect it to be ubuntu... https://www.facebook.com/snapcraftio/photos/a.127475154349370.1073741828.106271556469730/350162465413970/?type=3&permPage=1
[19:49] <popey> (hope that works) - person asking how you get the launcher in the top of the screen :)
[19:49] <popey> oops
[19:49] <popey> I'll throw them a solus link :)
[20:01] <ikey> hah
[20:01] <ikey> well it just so happens that budgie 10.4 was made to be backportable
[20:02] <ikey> so i mean straight up its looking like it'll be in 17.10 anyway but could easily end up in older ones with PPAs
[20:02] <ikey> supports 3.18 stack..
[20:09]  * zyga-suse pulls in budgie desktop 
[20:09] <zyga-suse> well, solus 3 that is
[20:10] <zyga-suse> ikey: any useful link on "my first solus package" or "solus for developers"?
[20:10] <ikey> erm
[20:10] <ikey> context?
[20:10] <ikey> like you need build tools right?
[20:10] <ikey> i.e build-essential equivalent?
[20:10] <zyga-suse> yes
[20:10] <zyga-suse> and packaging primer
[20:10] <ikey> sudo eopkg it -c system.devel
[20:11] <ikey> https://solus-project.com/articles/packaging/
[20:11] <ikey> note build tools are largely mutually exclusive of packaging
[20:11] <ikey> as we mandate everyone builds packages using solbuild
[20:11] <ikey> which is like basically if docker and schroot had a baby, and it wasn't an abomination
[20:11] <JoshStrobl> Also: https://www.youtube.com/watch?v=rlPnHjUBpJ8 https://www.youtube.com/watch?v=xK-1726MWqQ https://www.youtube.com/watch?v=c_vIg3ep3YE
[20:11]  * JoshStrobl goes back to watching Logan
[20:11] <ikey> where did you com..
[20:11] <ikey> logan is *win* btw, enjoy
[20:12] <zyga-suse> :)
[20:12] <ikey> this is the single most arch-linux-thing ive ever seen written https://twitter.com/fivelek/status/897544181165559813
[20:12] <zyga-suse> thanks, let me look at those
[20:12] <ikey> it served zero purpose other than telling everyone that they use arch linux xD
[20:15] <zyga-suse> ikey: no, it served a purpose
[20:15] <zyga-suse> ikey: I got to tell them snaps work on arch :D
[20:15] <ikey> oh man he got reverse-preached
[20:15]  * ikey approves
[20:25]  * zyga-suse notices this channels has 284 people 
[21:21] <pedronis> niemeyer: thanks for the repair review, I answered some things, I'll work through the feedback in my morning
[22:01] <mwhudson> wth
[22:02] <mwhudson> can someone tell me how to check if apparmor confinement is working?
[22:02] <mwhudson> i thought it was broken in debian but actually it seems to be working now, very confused
[22:03] <mwhudson> jdstrand: ^ -- is there maybe a test snap that tries to violate its confinement?
[22:11]  * mwhudson forums
[22:21] <tyhicks> mwhudson: #13 of https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor#Desktop_only would do
[22:45] <iatrou> For snaps with classic confinement, like conjure-up, is there a workaround to make them work when $HOME is on NFS?
[22:50] <mwhudson> iatrou: with classic confinement, no workaround should be needed...
[22:52] <mwhudson> tyhicks: yeah, confinement is not working :(
[22:54] <iatrou> mwhudson: and yet, running on snapd 2.25 conjure-up 2.2.2 it complaints: cannot create user data directory: /home/qz40qq/snap/conjure-up/549: Permission denied
[22:55] <mwhudson> iatrou: huh :(
[23:07] <zyga-suse> iatrou: any denials?
[23:08] <zyga-suse> iatrou: I think classic confinement _still_ applies apparmor so there might be something missing
[23:08] <zyga-suse> but ... what are the facts?
[23:36] <iatrou> mwhudson: zyga-suse http://paste.ubuntu.com/25322186/
[23:37] <zyga-suse> aha!
[23:37] <zyga-suse> interesting
[23:37] <zyga-suse> so yes
[23:37] <zyga-suse> snap-confine itself is affected
[23:37] <zyga-suse> interersting bug
[23:37] <zyga-suse> iatrou: can you please open a forum topic on forum.snapcraft.io
[23:37] <zyga-suse> I believe we can get that fixed
[23:38] <iatrou> zyga-suse: sure thing, thank you!
[23:47] <iatrou> mwhudson: zyga-suse https://forum.snapcraft.io/t/snaps-with-classic-confinement-and-nfs-home/1706
[23:47] <zyga-suse> thank you
[23:57] <mwhudson> zyga-suse: go to bed :)
[23:58] <zyga-suse> I fell asleep earlier and now I cannot sleep