[00:33] <ppisati> ogasawara: USB_GPIO_VBUS totally clueless, seems ok to =m
[00:34] <jwi> ogasawara: hm, did you get my reply before you pinged out?
[00:34] <ogasawara> jwi: yes thanks
[00:34] <jwi> k
[13:10] <skaet> ogasawara, bjf - backscroll is inconclusive, and there are no updates in the incident report.     What is the status with the kernel built yesterday?
[15:33] <ogasawara> bjf: https://wiki.ubuntu.com/PrecisePangolin/12.04.1
[15:58] <bdmurray> smb: perhaps I should upload kerneloops turning it off until we sort out the crashes?
[16:07] <henrix> smb: can you take a look at my git lucid/lts-backport-oneiric and push it if OK?
[16:18] <derwaffenss> Let’s put a stop to the subversive Judaics and any selfish slime allied with them.  WHITE AMERICA: Time for some serious house cleaning! http://incogman.net/
[16:27] <smb> bdmurray, Err which realease was that? For Quantal I thought I had it turned it off by default
[16:27] <smb> henrix, maybe
[16:28] <bdmurray> smb: I turned it on when I was down there on Tuesday
[16:28] <bdmurray> smb: after talking to jsalisbury
[16:29] <henrix> smb: ok, if you're busy i can bug herton
[16:29] <smb> henrix, I'll try to squeeze it in :)
[16:29] <smb> bdmurray, Ah, missed that
[16:29] <henrix> smb: ok, cool. thanks
[16:29] <jsalisbury> smb, yeah, kerneloops is on for Quantal now, it will be on until just before release
[16:29] <smb> bdmurray, Yeah, I was not sure it did work, but always got distracted before actually testing
[16:30] <bdmurray> smb: okay, well it doesn't! ;-)
[16:30] <smb> In theory it should pipe itnto apport
[16:30] <bdmurray> right, there is a problem with just running the daemon though
[16:31] <smb> bdmurray, Then we may turn it better off... Oh bugger... :-P
[16:31] <jsalisbury> bdmurray, smb, I saw a kerneloops bug this morning, and it looks like apport had an issue: bug 1026936
[16:31] <ubot2> Launchpad bug 1026936 in linux "BUG: Bad page map in process Xorg pte:5b840067 pmd:7f4cc067" [Medium,Incomplete] https://launchpad.net/bugs/1026936
[16:31] <jsalisbury> message box:
[16:31] <jsalisbury> This problem report is damaged and cannot be processed.
[16:31] <jsalisbury> Error('Incorrect padding',)
[16:31] <jsalisbury> three or four popup messages at once,
[16:32] <bdmurray> smb: okay, I'll just turn it off for now
[16:32] <smb> jsalisbury, Ok, so best turn it off... Hm, I wonder whether this is because I was told to drop some of the applet patches because we dont need the applet (which apparently we do do need)
[16:32] <smb> bdmurray, Ok, yes. Thanks
[16:32] <smb> jsalisbury, Probably you can assign the bug to me, so I will find it again when I try to
[16:33] <jsalisbury> smb, ack
[17:10] <bjf> utlemming: can you test the oneiric kernel that is in -proposed?
[17:10] <utlemming> bjf: in progress now
[17:10] <bjf> utlemming: many thanks
[17:11] <ogasawara> arges: around?  we want to see that testing doc you posted
[17:19] <slangasek> rtg, ogasawara: hey, question on this linux-hwe-generic thing
[17:19] <slangasek> why is the backport release not in the package name?
[17:19] <slangasek> we're going to have more than one of these in the precise archive over time, and they need to remain co-installable
[17:20] <slangasek> (bug #1026831)
[17:20] <ubot2> Launchpad bug 1026831 in debian-installer "Seed the correct Q LTS backport kernel meta package in the 12.04.2 point release" [Undecided,Invalid] https://launchpad.net/bugs/1026831
[17:20] <ogasawara> slangasek: we intend for the hwe meta package to always point to the current point release kernel
[17:20] <ogasawara> slangasek: there is an additional release specific meta package
[17:20] <slangasek> that's problematic
[17:20] <ogasawara> slangasek: the linux-hwe-generic will point to this
[17:20] <ogasawara> slangasek: wiki.ubuntu.com/Kernel/Release/Rolling has our specific details
[17:20] <slangasek> because if you're installing linux-hwe-generic, at the next point release, you get auto-switched to the next backport kernel
[17:21] <slangasek> which is not supposed to happen
[17:21] <ogasawara> slangasek: correct, which is what we intend
[17:21] <slangasek> er, that's not what had been discussed / approved at UDS
[17:22] <ogasawara> slangasek: hrm, that's not our recollection.  seems we have a disconnect.
[17:22] <ogasawara> slangasek: what was your memory of the discussions, we don't auto roll forward?
[17:23] <ogasawara> slangasek: how else would we roll forward for security for 5 years.  12.10 is only supported for the 18mo.
[17:23] <slangasek> ogasawara: q, r, s backport kernels would be available under separate metapackage names in precise, and track the security updates for the respective releases
[17:23] <slangasek> correc
[17:23] <slangasek> t
[17:23] <slangasek> but the point is that we were going to *only* roll forward from the q kernel to the t kernel once q itself is EOL for security
[17:23] <bjf> https://wiki.ubuntu.com/Kernel/Release/Rolling
[17:23] <slangasek> so that users who've installed 12.04.2 don't get a separate upstream kernel release every 6 months
[17:24] <slangasek> which is what happens if you use a single name
[17:25] <ogasawara> slangasek: I assumed this is practice/prototype for 14.04 when we do go for a rolling kernel policy
[17:25] <utlemming> bjf, smb: tested and confirmed to work. 
[17:25] <slangasek> ogasawara: that was not my understanding at all
[17:26] <bjf> utlemming: can you add a comment to bug 1026730 ?
[17:26] <ubot2> Launchpad bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1026730
[17:26] <slangasek> this is the first time I've heard of a rolling kernel upgrade policy for 14.04
[17:29] <ogasawara> slangasek: hrm, so you're view is the upgrade paths are Q->T, R->T, S->T right? and would those transitions happen when T releases or 3mo after T releases?
[17:30] <slangasek> ogasawara: I don't remember if it was "when T releases" or "3 mo after"; it was discussed in the UDS session
[17:30] <slangasek> but yes, that's what I was expecting to see as the upgrade path
[17:30] <slangasek> which means keeping separate named metapackages for each backport channel
[17:30] <ogasawara> slangasek: our reasoning for doing the rolling upgrade of Q->R->S->T was to minimize the maintenance burden
[17:30] <slangasek> well
[17:31] <slangasek> my understanding was that it was already agreed that the kernel team would take on that maintenance burden, as the cost of providing a suitable LTS experience :)
[17:31] <slangasek> an upstream kernel upgrade every 6 months for anyone who needs any post-12.04 hardware enablement isn't very LTS-y
[17:33] <ogasawara> slangasek: we're digging up our notes from UDS...
[17:33] <slangasek> ok :)
[17:38] <infinity> slangasek: They get "a new one every 6 months" anyway, just with an initial 18-month delay.
[17:38] <infinity> slangasek: (With your proposed scheme)
[17:38] <slangasek> infinity: not at all
[17:38] <slangasek> infinity: they get "the one they installed", followed by "the one from the next LTS"
[17:39] <infinity> slangasek: Oh, right.  Okay, fair enough.  But.  Well.  How is that better?
[17:39] <slangasek> it's better because one kernel switch is better than more than one kernel switch :)
[17:39] <infinity> (I'm not convinced on the "12.04.2 should ship with the backport kernel" plan, mind you, but that's unrelated)
[17:40] <infinity> slangasek: It's one massive kernel switch, rather than smaller incremental ones.  Both suck, I guess.
[17:40] <infinity> I do think that the whole foo-lts-backport-$release thing is madness, though.
[17:41] <slangasek> in terms of administration cost, one massive kernel switch is clearly better
[17:41] <slangasek> which is why the users have chosen the LTS in the first place :)
[17:43] <infinity> slangasek: It might be better for upgrade scariness costs, yes.  I'd argue that the quality of support we (or anyone) can provide on a system with multiple shipping kernel versions is probably worse.
[17:43] <infinity> (When you do a userspace SRU on lucid that's scary and wonky, do you test on lucid's kernel, plus all the backports?)
[17:45] <infinity> And while we clearly need to be doing the backport thing to support new hardware, having several of them instead of the One True Backport Kernel does make things a bit of a nightmare.
[17:45] <infinity> It does for end-users too, who find that they have 3 different kernels installed, based on when they installed their machines.
[17:47] <henrix> smb: finally, pkg upload has completed!  it's on zinc
[17:47] <smb> henrix, ok. looking
[17:49] <infinity> slangasek: I really have no sense for what the average user finds good, sensible, or maintainable.  But I know I live in a bit of an all-or-nothing state where my ideal is "all my machines have the same kernel and never change, ever", but the next best thing is "they all upgrade together and have the same version at all times".  Having the possibility to have 3 or 4 versions in play based on when in the enablement cycle I jumped on board is awful, IM
[17:50] <slangasek> infinity: well, in that case you still have the option to upgrade them all to the latest enablement kernel for consistency
[17:50] <slangasek> but users shouldn't be forced to be an a 6-month kernel upgrade treadmill just because their hardware enablement missed 12.04 by 3 months
[17:55] <ogasawara> slangasek: we're unable to find notes which definitively document the solution that was discussed but we clearly remember different results.  I think we're at a stand still atm.
[17:56] <ogasawara> slangasek: am contemplating best way to move forward
[17:57] <infinity> ogasawara: A linux-meta-lts-backport-latest that gave the rolling experience would allow users the choice between option A or B.
[17:58] <infinity> ogasawara: That doesn't solve the headache that you guys have to support N kernel versions on the LTS, but if that support is effectively just backport-and-forget (has it been vaguely effortless for lucid?), then that may be a non-argument.
[17:59] <apw> infinity, yeah and lts-hwe-falvour is your one there, we are going to have 'this lts backport' and the 'latest lts backport' meta packages
[17:59] <apw> infinity, the argument is about which is default for a .N release
[18:00] <rtg> infinity, linux-hwe-generic and linux-image-generic-lts-quantal are the 2 meta package names right now
[18:01] <slangasek> ogasawara: maybe the X guys can break the tie... since the X stack and kernel need to be doing the same thing :)
[18:02] <apw> slangasek, heh yeah
[18:02] <ogasawara> slangasek: they definitely need to be brought into this discussion
[18:04] <rtg> infinity, slangasek: this is the description of how meta packages are meant to behave based on my memory of UDS sessions (which I wrote the week after IIRC): https://wiki.ubuntu.com/Kernel/Release/Rolling
[18:06] <slangasek> rtg: yes, everyone is pointing me at the wiki page; I'm saying that's not what I understood was being agreed to
[18:08] <slangasek> I'm not saying you misremembered, I'm just saying that apparently not everyone in the sessions understood the same thing
[18:08] <rtg> slangasek, clearly :)
[18:08] <bjf> !vote!
[18:08] <ubot2> Factoid 'vote!' not found
[18:08]  * apw votes slangasek gets the first round in
[18:10] <smb> henrix, its signed now
[18:10] <henrix> smb: ack, thanks!
[18:16] <infinity> apw: Was there a reason no one felt the proposed 14.04 plan wouldn't be appropriate for 12.04 too?
[18:16] <infinity> apw: (If you recall)
[18:17] <apw> infinity, that applied the same to the 'release' kernel as well, and i think people were scared of that
[18:17] <apw> infinity, before people were used to a regular new kernel
[18:17] <infinity> I can see how it's scary, but if it's scary now, it's scary in two years too.
[18:17] <infinity> So, this needs to be hashed out sooner or later.
[18:19] <apw> i see it as a slightly scarier combination, and 14.04 the same level of scary compared to this
[18:23] <bjf> jjohansen: bug 1026853
[18:23] <ubot2> Launchpad bug 1026853 in qa-regression-testing "test-kernel-security fails on seccomp on Oneiric AWS" [Undecided,New] https://launchpad.net/bugs/1026853
[18:23] <jjohansen> bjf:  thanks
[18:26] <jjohansen> infinity: because the 12.04 plan was announced before what is currently planned for 14.04, and maybe deals where made based on that
[18:26] <arges> ogasawara, hi
[18:27] <ogasawara> arges: heya, are you still on holiday?  If so, go away
[18:27] <arges> ogasawara, no i'm back today! family left a day early
[18:27] <ogasawara> arges: ah, I can see the doc now, thanks!
[18:28] <arges> ogasawara, yup. no problem
[18:53] <cking> apw, this is a fun elf article: http://timelessname.com/elfbin/
[19:00] <ogasawara> rtg: https://wiki.ubuntu.com/X/Blueprints/LtsPointUpdatesForXorg
[19:01] <ogasawara> rtg: look at their Questions section at the end
[19:08] <infinity> cking: Haha.  Love the animated gif of jmps.
[19:10] <rtg> ogasawara, hmm
[19:48] <hggdh> smb: while testing the new oneiric kernel, I got a crash on m1.small: http://pastebin.ubuntu.com/1102330/
[19:48] <hggdh> repeating the test did not result in a crash
[19:51] <smb> hggdh, I think I saw this kind of failure somewhere before but I cannot remember exactly where. Does repeating the test involve starting another instance? (which I assume)
[19:52] <smb> It would be good if there are complete dmesgs of fail or not fail (in order to see which xen version this was)
[19:54] <jjohansen> yeah
[19:54] <infinity> Could be hypervisor versions, or even underlying hardware.  Not all instances are created equal. :/
[19:54] <jjohansen> smb, hggdh can't you just reboot the instance, instead of starting a new one so we are guaranteed the same Xen/machine
[19:57] <smb> jjohansen, with manual attempts certainly. Though I would think from jenkins its probably always starting a fresh one
[19:57] <smb> With all the "repeatability" 
[19:57] <hggdh> smb, jjohansen
[19:57] <hggdh> ; the instance was rebootged
[19:57] <smb> Unfortunately ec2 is a bit "surprising" there
[19:58] <hggdh> this is being run manually
[19:58]  * jjohansen wasn't sure if this was from a jenkins or manual test
[19:58]  * smb neither
[20:05] <hggdh> jjohansen: I will rerun on the previous kernel
[20:10] <hggdh> and this may explain the failure I got yesterday runniong the -17
[20:22] <hggdh> jjohansen, smb just ran seccomp on -22, no errors
[20:22] <hggdh> I am starting to think I am getting different xen versions
[20:23] <smb> hggdh, As did I (get no errors) when running it yesterday. That one was something 3.4.3-kaos...
[20:23] <jjohansen> hggdh: likely, what we need to do is multiple runs, and get the full boot log
[20:24] <hggdh> the failing one (on -23.39 is [    0.000000] Xen version: 3.0.3-rc5-8.1.14.e
[20:25] <hggdh> the one with no failure (on -22) is [    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)
[20:25] <hggdh> smb: isn't the 3.03 the one we had an issue some time ago?
[20:26] <hggdh> how many bloody different versions does AWS run?
[20:26] <bjf> hggdh: are you ready to sign off on the "incident" bug so we can get this oneiric kernel into -proposed? 
[20:27] <smb> hggdh, Usually the older the more issues. There was one, and it might have been this one that had issues with installing java on 32bit t1.micro
[20:27] <ogasawara> ppisati: can you add DRM_OMAP to your investigation list
[20:27] <smb> hggdh, bjf Certainly this is not any regression (that much we already were ready to agree yesterday)
[20:28] <smb> jjohansen, Note that the crash there is another path of setting cr4 (remember osxsave)?
[20:31] <hggdh> I just ran another one under [    0.000000] Xen version: 3.4.3-2.6.18 (preserve-AD)
[20:32] <jjohansen> smb: no, not at all /me sticks fingers in ears and shouts I'm not listening, I'm not listening
[20:33] <smb> hggdh, aaaaand?
[20:33] <hggdh> hum. Let me repeat, the instance seems to have vanished :-(
[20:33] <jjohansen> sigh /me really dislikes dealing with all Xen version on ec2
[20:34] <smb> hggdh, That does not exactly sound like a repeat
[20:34] <hggdh> dammit. I have the feeling it was a 3.0.3-whatever, under -17. I will restart
[20:39] <hggdh> smb: no, it does not. I never had an instance simply vanish in thin air
[20:41] <hggdh> found it, it was just lurking. It is indeed a 3.0.3-rc5-8.1.14.f, on -17
[20:43] <smb> hggdh, I have the same gp fault on another 3.0.3 I started and I certainly had no problems yesterday which ran on 3.4.3
[20:43] <hggdh> smb: the other 3.0.3 above also died on an OOPS
[20:44] <hggdh> smb: I agree this sounds like a bad Xen on AWS
[20:48] <hggdh> apart from that, no errors on KVM, and bare-metal (except that all jobs on two specific machines failed, but this is due to a problem with the CDU
[20:48] <hggdh> oh, perfect, now I have a thunderstorm over me
[20:49] <hggdh> smb, jjohansen: do you agree this is most probably related to the 3.0.3-crappy Xen on AWS?
[20:51] <jjohansen> hggdh: that does seem to be a possibility, but I a haven't seen enough data to be comfortable claiming such.  Basically I have seen one instance that we can definitively make the correlation.  I would like a lot more data than that
[20:51] <smb> hggdh, Having seen it pass depending on host Xen version or not and even fail on older releases when not, this really does not sound like any regression
[20:53] <bjf> this is *not* a regression. a bug has been filed, we need to add data to that but do we wan't to hold up on the release of this kernel?
[20:55] <bjf> hggdh, jjohansen ^ ?
[20:56] <hggdh> bjf: jjohansen is correct -- it seems not a regression, but I would like to try another one
[20:56]  * hggdh is almost convinced
[20:57] <jjohansen> hggdh, bjf: I am convinced it is not a regression we have sufficient data to show it happening on older releases.  The only thing I am unsure of is the correlation of all the failures to Xen version 3.0.3-crappy
[20:57] <jjohansen> bjf: what is the bug number again
[20:57] <bjf> jjohansen: bug 1026730
[20:58] <ubot2> Launchpad bug 1026730 in linux "linux: 3.0.0-23.39 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1026730
[20:58] <hggdh> jjohansen: running on 3.4.3-kaos-whatever
[21:00] <smb> jjohansen, I agree that pinning badness to one exact version we will need to repeat the tests more often. There might be versions in between showing the same or different problems (or none)
[21:01] <hggdh> so far we have at least 3 different versions involved... who knows how many are there?
[21:02] <smb> $DEITY knows...
[21:03] <smb> Still this should not let us delay getting rid of the other mess
[21:03] <hggdh> OK. ran on 3.4.3-kaos_droplet (preserve-AD), -17 kernel, no issues
[21:03] <hggdh> I vote to approve
[21:03] <smb> +1
[21:03] <jjohansen> +1
[21:03] <hggdh> jjohansen: ?
[21:03] <hggdh> heh
[21:03] <bjf> hggdh: you can cast your vote by changing the task :-)
[21:04]  * hggdh goes updating the task
[21:05] <hggdh> jjohansen: there is a confirmed task there for you also
[21:07]  * hggdh goes terminating all m1.small instances
[21:07] <jjohansen> hggdh: yeah, its going to take a few minutes, I am running the scripts now
[21:11] <bjf> jjohansen: i believe the bug is waiting on "security signoff'
[21:11] <jjohansen> bjf: yes, I am working on it
[21:12] <bjf> jjohansen: :-) thanks
[21:12] <infinity> Oh, hah, I just mentioned that in another channel.
[21:12] <infinity> La la la.
[21:13] <infinity> I'd question why Amazon is using xen3 at all instead of xen4, but whatever. :/
[21:17] <hggdh> not only xen3, but a really old on at that
[21:17] <hggdh> s/ on/&e/
[21:29] <jjohansen> hggdh, bjf, infinity: released
[21:29]  * hggdh goes to cross all fingers and toes, just in case
[21:30] <bjf> jjohansen: ack
[21:30] <bjf> infiniti, it is in your hands
[21:32] <bjf> infinity, the bot is not going to set the release tasks due to it being friday :-)
[21:34] <henrix> bjf: and will it set the 'promote-to-proposed' task on the lts kernel tracking bug?
[21:36] <hggdh> bjf: BTW, have you seen https://jenkins.qa.ubuntu.com/view/SRU%20Kernel/ ? We are now listing the kernel version there; I think it is good enough, care to comment?
[21:38] <bjf> hggdh: yes, that is very nice in the description. are these in the "dashboard" yet?
[21:39] <herton> henrix, yes, nothing was changed related to the promote-to-proposed task
[21:39] <henrix> herton: ack, thanks
[21:41] <infinity> bjf: Haha, right.  On it.
[21:41] <hggdh> bjf: I think so (based on gema's EOD in G+)
[21:43] <infinity> bjf: Was the promote-to-security task a mistake there?  The previous -23.38 was only in -updates.
[21:44] <infinity> bjf: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1020623 <-- No security task.
[21:44] <ubot2> Ubuntu bug 1020623 in linux "linux: 3.0.0-23.38 -proposed tracker" [Undecided,Fix released]
[21:44] <infinity> bjf: Doesn't seem to make sense for 23.39 to have one.
[21:45] <henrix> infinity: there is a security task there as well, which was marked as invalid i believe.
[21:46] <henrix> infinity: see comment #4
[21:46] <herton> yes, the bot would set it to invalid, but as it doesn't run today the task stays as new
[21:46] <infinity> henrix: I meant "there wasn't a valid one". :P
[21:47] <infinity> herton: The bot really should be marking security (and signoff) tasks invalid long before it comes up.  Could have saved jjohansen some time too.
[21:47] <infinity> (Though I'm not sure how the bot even knows, I would have thought it was a human task)
[21:47] <herton> infinity, no, the bot doesn't go as far as that, I thought you meant about the task as being in new state
[21:47] <bjf> infinity, jjohansen set the task
[21:48] <infinity> herton: No, no.  I meant it should be invalid.
[21:48] <jjohansen> infinity: we have scripts etc, to help determine if its invalid, but in the end it currently a human call
[21:49] <herton> infinity, the bot sets it to invalid if jjohansen sets the security-signoff to invalid. But it sets this along with the promote-to-updates step
[21:49] <jjohansen> infinity: so I ran my check, it reports it needs to be looked at, and another script reports it doesn't believe there are any CVEs, but I need to do the check and make the final call
[21:49] <infinity> herton: Ahh, kay.  So, jjohansen also didn't set signoff to invalid, so I'll blame him. :)
[21:49] <infinity> Oh, wait.  He did.  I'm blind.
[21:49] <infinity> IGNORE ME.
[21:50] <jjohansen> herton: I did set the security sign-off to invalid
[21:50]  * infinity plays bot, and releases.
[21:50] <jjohansen> herton: oh ignore I read that wrong
[21:51] <henrix> infinity: since you're around... would you care to take a look at oneiric lts kernel? :)
[21:51] <infinity> henrix: Needs a PPA copy?
[21:52] <bjf> infinity: it just went into the upload queue
[21:52] <henrix> infinity: yep. i know its friday, but its the same issue so... i guess we're having an exception here as well
[21:52] <infinity> bjf: Alright.  Will accept and fix the override on the one binary if it breaks the same way.
[21:52] <henrix> thanks
[21:54] <infinity> jjohansen: If you want to pre-emtively security-invalidate https://bugs.launchpad.net/kernel-sru-workflow/promote-to-proposed/+bug/1026884 now, so we don't have to worry about it later? :)
[21:54] <ubot2> Ubuntu bug 1026884 in linux-lts-backport-oneiric "linux-lts-backport-oneiric: 3.0.0-23.39~lucid1 -proposed tracker" [Medium,In progress]
[21:54] <rtg> http://bytesmedia.co.uk/2012/07/17/richard-stallman-uefi/
[21:54] <infinity> rtg: That's a terrifying combination of nouns.
[21:55] <rtg> infinity, as you might have guess, he's not all that positive about UEFI
[21:55] <infinity> rtg: s/UEFI/SecureBoot/
[21:56] <infinity> rtg: And even then, probably only vendor restrictions on SB, I'd bet.
[21:56] <rtg> infinity, right
[21:56]  * infinity wishes people would stop conflating (u)efi and SB.
[21:56] <rtg> I've conflated UEFI with SB 'cause its all I've thought about lately
[21:56] <infinity> We have a "supporting UEFI" session at DebConf that was entirely dominated by SB prattle, which was useless.
[21:57] <infinity> s/have/had/
[21:58] <jjohansen> infinity: unfortunately microsoft is forcing the the conflation of UEFI SB and RB
[22:00] <infinity> jjohansen: To be fair, I think it's mostly the free software world that's doing that, especially the people who don't seem to be aware that there have been EFI machines for years that they supported poorly (or failed to support entirely).
[22:01] <infinity> jjohansen: So, now that the world is moving to UEFI wholesale, and it happens to coincide with the Win8 SB cutover, people are acting as though "supporting EFI" and "supporting SB" are the same task, when they're two very different beasts.
[22:01] <infinity> (And those of us who supported EFI for years know this)
[22:02] <jjohansen> infinity: previous efi did not conform to the SB specification and microsoft wasn't forcing its use for RB nor was it the root key authority
[22:03] <infinity> jjohansen: Yes.  But that doesn't make A equal to B.
[22:03]  * infinity shrugs.
[22:03] <infinity> It's a pet peeve.
[22:03] <jjohansen> infinity: agreed that EFI and SB are different but its because microsoft is forcing SB/RB that its a problem
[22:03] <infinity> Not made better by, like I said, a one hour session of people talking about secureboot, as if that mattered when Debian doesn't even support EFI properly.
[22:04] <infinity> jjohansen: SB/RB goes from annoying to downright hostile, but even without it, modern OSes need to support EFI, and most don't actually do it right.
[22:05] <jjohansen> infinity: true, though /me can wish that EFI was never even conceived
[22:07] <infinity> I do rather wish that Intel/HP had gone with OpenFirmware back when they decided to flirt with PC BIOS alternatives.
[22:07] <infinity> The reinvention of the wheel was irksome.
[22:07] <infinity> From a "firmware addon" developer POV, EFI is much more pleasant, though.  Maybe that was part of the motivation.
[22:12] <jjohansen> infinity: heh if firmware addons are what you want what of coreboot
[22:14] <infinity> jjohansen: coreboot is politically distasteful to a lot of people, I suspect.
[22:14] <jjohansen> infinity: well yes :)
[22:14] <jjohansen> infinity: but so is SB
[22:14] <infinity> OF would have been a reasonably neutral choice, I thought.
[22:14] <infinity> IBM, Sun, Apple, and many others had invested in it.
[22:14] <jjohansen> it was the logical choice at the time
[22:14] <infinity> But, too late now.
[22:14] <jjohansen> yep
[22:39] <ogasawara> ppisati: CONFIG_NLS_ISO8859_1 does this need to be =y on omap4 or can we flip it to =m
[22:44] <ogasawara> ppisati: CONFIG__OMAP_IOVMM=n, should that be =m?
[23:20] <ppisati> ogasawara: OMAP_IOVMM should be deprecated in modern kernels, is it =y or =m anywhere?
[23:21] <ogasawara> ppisati: it's set =m on omap3
[23:21] <ogasawara> ppisati: so we should turn it off yes?