[07:17] <cyphermox> apw: ping; about that mirroring of MokSBState as MokSBStateRT in sysfs; so we can see when Secure Boot is enabled but that validation is disabled in shim
[07:18] <cyphermox> apw: as I was saying; shim will eventually provide that variable; but for the time being it would be good if the kernel should put it in sysfs; that will mean less prompting to disable SB when SB is already disabled :)
[07:18] <cyphermox> needs to happen on all releases with the kernels.
[07:39] <apw> rtg, ^
[07:40] <rtg> cyphermox, ack
[07:40] <cyphermox> rtg: ack
[14:36] <rtg> cyphermox, 
[14:36] <rtg> rtg@ubuntu:/proc/sys/kernel$ cat secure_boot 
[14:36] <rtg> 1
[14:36] <rtg> rtg@ubuntu:/proc/sys/kernel$ cat moksbstate_disabled 
[14:36] <rtg> 0
[14:36] <rtg> cyphermox, is that sufficient ?
[14:42] <apw> cyphermox, is that mok...._disabled the same "True/False" way round as the shim change ?
[14:43] <cyphermox> well, the shim change looks for a real MokSBStateRT variable just like all the other UEFI vars
[14:43] <cyphermox> but that could work too, provided I add the hooks in the script
[14:53] <cjwatson> Does anyone have access to the logs of Brad's bug bot thing that deals with proposed tracker bugs?
[14:55] <cjwatson> It has been doing something very very strange to bug 1591458 which caused a partial Launchpad outage
[14:55] <apw> cjwatson, oh ..
[14:56] <cjwatson> You can't see it on the bug index page, but it made about 15000 changes flipping the status of kernel-sru-workflow/security-signoff back and forth
[14:56] <cjwatson> It seems to have stopped doing that, but uh
[14:56] <apw> cjwatson, bjf thinks that was a state flipper gone mad, and he thought he had stopped it a couple of hours ago
[14:57] <apw> cjwatson, "bjf: oops sorry"
[14:58] <apw> cjwatson, we do belive the issue is fixed, and if you arn't seeing it any more, that is good
[14:59] <apw> cjwatson, we are talking about making sure we don't make this class of errors
[15:15] <cjwatson> apw: OK, thanks.  Figuring out how to clean it up at the moment.
[15:32] <cyphermox> apw: is that really "True"/"False", or 0/1 ?
[15:32] <cyphermox> nevermind, I fail at remembering
[15:45] <manjo> apw, any idea when we might see a 4.7 in unstable ? 
[16:13] <cjwatson> apw: (cleaned up)
[22:46]  * lamont as an ipv6 trusty/xenial question...
[22:46] <lamont> no firewalls involved, 3.13.0-83-generic and 4.4.0-24-generic kernels.
[22:47] <lamont> ping6 "ip on the other machine on the common subnet" ==> neigbor solicitiation, but no reply.  But only sometimes.  thoguhts/
[22:47] <lamont> ?
[22:48] <lamont> and if I poke things with tcpdump enought (can you say promisc?), then all of a sudden it works, until later when it stops agsin
[22:49] <lamont> and, of course, not currently reproducible