[07:17] 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] 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] needs to happen on all releases with the kernels. [07:39] rtg, ^ [07:40] cyphermox, ack [07:40] rtg: ack === chrisccoulson_ is now known as chrisccoulson === JanC is now known as Guest29167 === JanC_ is now known as JanC [14:36] cyphermox, [14:36] rtg@ubuntu:/proc/sys/kernel$ cat secure_boot [14:36] 1 [14:36] rtg@ubuntu:/proc/sys/kernel$ cat moksbstate_disabled [14:36] 0 [14:36] cyphermox, is that sufficient ? [14:42] cyphermox, is that mok...._disabled the same "True/False" way round as the shim change ? [14:43] well, the shim change looks for a real MokSBStateRT variable just like all the other UEFI vars [14:43] but that could work too, provided I add the hooks in the script [14:53] Does anyone have access to the logs of Brad's bug bot thing that deals with proposed tracker bugs? [14:55] It has been doing something very very strange to bug 1591458 which caused a partial Launchpad outage [14:55] Error: Could not gather data from Launchpad for bug #1591458 (https://launchpad.net/bugs/1591458). The error has been logged [14:55] cjwatson, oh .. [14:56] 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] It seems to have stopped doing that, but uh [14:56] cjwatson, bjf thinks that was a state flipper gone mad, and he thought he had stopped it a couple of hours ago [14:57] cjwatson, "bjf: oops sorry" [14:58] cjwatson, we do belive the issue is fixed, and if you arn't seeing it any more, that is good [14:59] cjwatson, we are talking about making sure we don't make this class of errors [15:15] apw: OK, thanks. Figuring out how to clean it up at the moment. [15:32] apw: is that really "True"/"False", or 0/1 ? [15:32] nevermind, I fail at remembering [15:45] apw, any idea when we might see a 4.7 in unstable ? [16:13] apw: (cleaned up) [22:46] * lamont as an ipv6 trusty/xenial question... [22:46] no firewalls involved, 3.13.0-83-generic and 4.4.0-24-generic kernels. [22:47] ping6 "ip on the other machine on the common subnet" ==> neigbor solicitiation, but no reply. But only sometimes. thoguhts/ [22:47] ? [22:48] 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] and, of course, not currently reproducible === Serge is now known as Guest36294 === kees_ is now known as kees === Guest36294 is now known as wtf_freenode === logan_ is now known as Guest6911 === dasjoe_ is now known as dasjoe === eichiro_ is now known as eichiro === meatmanek_ is now known as meatmanek === DavidDuffey is now known as dduffey === ikonia_ is now known as ikonia === Guest6911 is now known as logan-