[00:25] <cjwatson> ogasawara: heads-up on bug 893395
[00:25] <ubot2> Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Undecided,New] https://launchpad.net/bugs/893395
[00:25] <cjwatson> shame I missed today's upload
[04:41] <ogasawara> cjwatson: pushed a fix for 893395, I'll upload once the current upload finishes building (eta 5hrs). will then get linux-meta uploaded as well.
[08:25] <smb> morning .+
[08:27] <abogani> morning
[08:58]  * apw waves weakly
[11:24] <ppisati> smb`: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/view/head:/scripts/kernel/guard-page/split-stack.c
[11:25] <ppisati> smb`: do you remember if it relates to a CVE or a particular kernel option?
[11:44] <smb> ppisati, it had to do with a cve, but I cannot remember exactly what/which
[11:44] <ppisati> smb: found
[11:44] <ppisati> smb: https://bugs.launchpad.net/ubuntu/jaunty/+source/linux-mvl-dove/+bug/646114
[11:45] <ubot2> Launchpad bug 646114 in linux "mlock on stack will create guard page gap" [Undecided,Fix released]
[11:45] <smb> ppisati, Well, I believe that was a problem introduced by the attempted fix for the other problem
[11:47] <smb> The guard page thing was supposed to prevent some bad collision but unfortunately the way this was shown to user-space was one-off (or so)
[11:48] <smb> Hm, actually might have been that if the area was spanning more than one vm area the guard page hole was presented for each area
[11:48] <smb> which is a lie for anything but the lowest (if your stack grows downwards)
[11:50] <ppisati> smb: ok, seems to be 28d2e371327c8961ae593e1a3e275df32b35dd7d maverick/master
[11:53] <smb> ppisati, That was the fix. It started with 52423b90e1f5b1bdbbcc6e32f4d37ada29b790c4
[11:53] <smb> ppisati, CVE-2010-2240
[11:53] <ubot2> smb: The do_anonymous_page function in mm/memory.c in the Linux kernel before 2.6.27.52, 2.6.32.x before 2.6.32.19, 2.6.34.x before 2.6.34.4, and 2.6.35.x before 2.6.35.2 does not properly separate the stack and the heap, which allows context-dependent attackers to execute arbitrary code by writing to the bottom page of a shared memory segment, as demonstrated by a memory-exhaustion attack against the X.Org X server. (http://cve.mitre.org/c
[11:55] <ppisati> cool, i'll import it
[11:55] <ppisati> btw, does that mean that secuiry test routine were not run on arm branches?
[11:56] <ppisati> but first, lunch! :)
[11:56] <smb> ppisati, We do security on arm? :-P
[11:57] <smb> Well it should be in there
[11:57] <ppisati> well, it seems we just started to do security on arm... :)
[11:57] <smb> The CVE required a whole bunch of changes but for Maverick those seem to be in from upstream stable
[11:58] <smb> It turned out that the minimal invasive patch was a maximum pain in the butt
[11:58] <ppisati> sounds like something to remember... :)
[11:59]  * smb does not think that anything minimal invasive exists in memory management...
[12:00] <ppisati> smb: well, but you made my facebook status quote :)
[12:01]  * smb tries to hide
[13:50] <apw> ppisati, so did someone in qa just bring up that security failure ?
[13:51] <apw> ppisati, cirtainly in the early days we didn't record derivative branches as well as we do now, and so they had not CVE tracker entries and didn't get updated always; and once missed that was it
[13:53] <herton> apw, bug 893190 (first reported on tracking bug 888569)
[13:53] <ubot2> Launchpad bug 893190 in linux-ti-omap4 "Qa-testing failures for 2.6.35-903.27" [Undecided,New] https://launchpad.net/bugs/893190
[13:53] <ubot2> Launchpad bug 888569 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 2.6.35-903.27 -proposed tracker" [Undecided,Fix released] https://launchpad.net/bugs/888569
[13:53] <apw> so it must be new testing i suspect then, a good thing if a little late
[13:54] <apw> herton, but if it is a missing CVE which simply is not applied to that branch, then its not a regression
[13:54] <herton> indeed, I guess that's it also
[13:54] <apw> herton, and we'd not necessarily want to hold the update.  the previous release is as bad
[13:55] <herton> apw, I was thinking about it as well, that's true, shouldn't hold if not a regression. If GrueMaster can confirm is not a regression, we could go forward with the update and release it
[13:56] <apw> ppisati, is this just a cve we have missed on this branch, ie are the fixes simply missing?
[13:56] <apw> herton, if that is a yes ^^ then its defnatly not a regression
[13:56] <apw> let me know if so so i can get the security team to pull that entry back from retired for the matrix too
[13:58] <herton> ok. There is more 1 test failure on the report, not sure if they are all missing cves, but if not a regression on all then ok
[13:58] <herton> *more than 1
[13:59] <apw> ahh ok, so ppisati any cves we find missing via this testing i need the numbers for to reopen the CVEs
[13:59] <smb> From past experience it can be worth looking at the failed test closely since some are doing statistical checks and sometimes those were to tightly checking
[13:59] <smb> (like the stack randomization checks)
[13:59] <apw> yep there is that, for the random placement checks they are poor
[14:00] <apw> and can fail once in a while without being broken
[14:00] <smb> Yep, I guess with less memory random place is less random than with more...
[14:01] <apw> i believe that arm has less bits to be random with iirc
[14:11] <ogasawara> apw: would you be able to stand in for me at the release meeting on fri
[14:12] <apw> ogasawara, sure, i think there is a change to how its done which you'd have to get me up to speed on
[14:12] <ogasawara> apw: yep, we send out our team specific bits to the ubuntu-release mailing list ahead of time.  then the meeting is just any follow up Q&A for what we sent out.
[14:13] <apw> ogasawara, and we chose the bugs for the list as well ?
[14:13] <ogasawara> apw: yep
[14:13] <apw> how we been picking them
[14:13] <ogasawara> apw: apw: I'll go ahead and send out the email to ubuntu-release.  that way you can just sit in on the meeting.
[14:13] <apw> are we relying on jo for that, or do we have a tag
[14:14] <apw> ogasawara, ok fair enough
[14:14] <ogasawara> apw: mainly relying on the rls-p-tracking tag
[14:14] <ogasawara> apw: but we're responsible for putting that on the bugs
[14:14] <ogasawara> apw: but since we've just uploaded a 3.2 kernel, I haven't been real aggressive with using the tag just yet as it's not clear if some of the bugs will resolve themselves with the newer kernel.
[14:15] <ogasawara> apw: but I've been keeping an eye on some, which I'll list in the email.
[14:15] <apw> yeah for sure, till that mess is in and stable we're spinning wheels
[14:16] <ogasawara> apw: I also uploaded a new 3.2.0-1.3 to fix up bug 893395
[14:16] <ubot2> Launchpad bug 893395 in linux "ext2 modular in precise but missing from fs-core-modules" [Critical,Fix released] https://launchpad.net/bugs/893395
[14:16] <ogasawara> apw: once that builds I'll hopefully want to upload linux-meta finally
[14:16] <ogasawara> tseliot: were you able to take a peek at wl?
[14:17] <apw> ogasawara, yeah saw that on irc scroll back, a good decision me thinks
[14:18] <tseliot> ogasawara: I'm working on it as we speak. I think I've found the change that causes the build to fail. I have to see if this is the only change though
[14:18] <ogasawara> tseliot: great, thanks.  please keep us posted.
[14:18] <tseliot> ogasawara: sure
[14:38] <ogasawara> jsalisbury: think you'll you be ready to pick up chairing the weekly IRC meeting next week?
[14:48] <tseliot> ogasawara, apw: my patch at least allows the module to build. Now I only need to test it on a device with broadcom
[14:48] <apw> sounds good
[14:50] <tseliot> now remembering which one of the bazillion devices that I have around has broadcom is the main problem ;)
[14:51] <jsalisbury> ogasawara, yes, next week is good for me
[14:52] <ogasawara> jsalisbury: and I haven't forgotten about the bug you pinged about yesterday, will get to it soon
[14:53] <jsalisbury> ogasawara, cool.  thanks
[15:03]  * herton -> lunch
[15:29]  * ogasawara back in 20
[15:40] <TeTeT> apw: thanks for the dpms suggestion for the random freezes!
[15:41] <apw> hey np
[15:49]  * tseliot has finally found a device with a broadcom chipset \o/
[15:54] <mdeslaur> herton: is this table accurate? https://wiki.ubuntu.com/Kernel/Dev/ABIPackages
[15:55] <mdeslaur> herton: is that what you use, or do you have a more authoritative source?
[15:56] <herton> mdeslaur, yes, it's the official source
[15:56] <mdeslaur> herton: ok...can I correct everything that's inaccurate in it then?
[15:56] <herton> mdeslaur, yep
[16:00] <apw> ogasawara, we need to add a WI to update the above page and its friends when we are about to release, by kernel freeze we should know i'd think
[16:00] <apw> ogasawara, with our standard ones like emailing out the config
[16:02] <tseliot> apw, ogasawara: unfortunately the only laptop (that works) which has a broadcom card only uses the open driver. I think the laptop that I used for testing is the one with the dead monitor...
[16:03] <apw> tseliot, if you have .debs i have brcm that works with wl i believe
[16:03] <tseliot> apw: sure, for amd64?
[16:03] <apw> sadly its 32bit
[16:03] <tseliot> apw: ok, let me create a 32bit chroot then
[16:05] <apw> tseliot, hang on
[16:05] <apw> tseliot, its a dkms package, isn't it an _all ?
[16:05] <tseliot> apw: no, as we only support i386 and amd64
[16:05] <tseliot> unfortunately
[16:06] <apw> tseliot, but the package would be identicle, as in its not a binary package?
[16:07] <tseliot> apw: the makefile is patched so that the right binary is used according to the architecture
[16:07] <apw> tseliot, yeah i mean if i just force the xmd64 binary on it'll work right ?
[16:07] <tseliot> there are separate binaries in the same package for the two archs
[16:07] <apw> oh ick ok, i'll shut up now
[16:08] <apw> ogasawara, is the meeting in an hour ?
[16:08] <ogasawara> apw: yep
[16:08] <apw> you or joe?
[16:08] <ogasawara> apw: me.  joe will take over next week.
[16:09] <tseliot> apw: even if you force the installation I think dpkg --print-architecture would report the right architecture and things should be fine
[16:09] <tseliot> apw: so it's probably worth trying
[16:09] <tseliot> (the makefile is called by DKMS)
[16:09] <apw> tseliot, can do if you point me to a binary
[16:09] <tseliot> apw: sure let me upload the deb file
[16:11] <tseliot> apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_amd64.deb
[16:12] <tseliot> apw: no, wait
[16:12] <tseliot> it won't work
[16:13] <apw> tseliot, /me waits
[16:13] <tseliot> apw: some files are renamed when the package is built, therefore it's not gonna work
[16:13] <apw> tseliot, ok
[16:14] <tseliot> apw: hopefully my chroot will be ready in a few
[16:14] <apw> ok
[16:23] <tseliot> apw: the creation of an i386 chroot failed (because of perl...). I'm using my Lucid 32bit chroot
[16:24]  * tseliot keeps his fingers crossed
[16:25] <apw> heheh
[16:28] <ppisati> i didn't see the usual kernel meeting warning
[16:28] <ppisati> it's still scheduler in 30mins, right?
[16:29] <ppisati> *scheduled
[16:29] <apw> ppisati, indeed should be, ogasawara did we miss a 1hr warning?
[16:29] <ogasawara> yah, got sidetrack and didn't spam the channel
[16:30] <ppisati> np
[16:30] <ogasawara> ##
[16:30] <ogasawara> ## Kernel team meeting today @ 17:00 UTC
[16:30] <ogasawara> ##
[16:30] <cking> eek
[16:30] <apw> (that is in 30 minutes people)
[16:30] <smb> he lives...
[16:30] <cking> who me?
[16:30] <smb> yes
[16:30] <smb> :)
[16:30] <cking> I've been grinding data all day
[16:30] <apw> cking, i expect you have half a dozen reports for the thing right ?
[16:31] <cking> I'm still working on it
[16:31] <smb> I guess the meeting will take then a bit longer than usual... :)
[16:32]  * cking keeps on finding weird corner cases which need double checking
[16:34] <GrueMaster> herton, apw.  Not a regression, definately.  I was just recently able to get the qrt kernel tests working on armel w/o a lot of false positives. 
[16:37] <apw> GrueMaster, ok cool, herton that sounds like we can at least release it
[16:37] <ogasawara> jsalisbury: just fyi, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/892675/comments/2
[16:37] <ubot2> Launchpad bug 892675 in linux "include/linux/usb.h missing" [Medium,Invalid]
[16:37] <apw> ppisati, we do need to get a list of all the CVEs which are truly not fixed on there so i can get them active again
[16:37] <herton> yep, GrueMaster can you tag it passing qa on the maverick ti-omap4 bug? ppisati opened a new bug to work on the failures
[16:38] <GrueMaster> Will do.
[16:38] <jsalisbury> ogasawara, thanks!
[16:39] <ppisati> apw: so far, only 1 seems good and it's not a CVE
[16:39] <ppisati> apw: it's a fix for the fix of a CVE
[16:39] <apw> ahh, it should probabally have had a CVE number and didn't
[16:40] <ppisati> apw: 2 of the failing tests seem not applicable to maverick/omap4
[16:40] <tseliot> apw: http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.112+bdcom-0ubuntu1_i386.deb
[16:40] <ppisati> apw: and now i'm looking atthe last one
[16:40] <apw> ogasawara, as the reporter is mentioning /usr/include those would be the copies in linux-libc-dev, are they in there too ?
[16:41] <GrueMaster> There is one test that is failing (/dev/mem) that needs more research, but I am not counting it in the test failure results yet.
[16:41] <apw> ogasawara, and indeed on my precise install there is no /usr/include/linux/usb.h
[16:42] <ogasawara> hrm, /me double checks
[16:43] <apw> ogasawara, that it _is_ in headers and not linux-libc-dev doesn't mean its meant to be in /usr/include of course
[16:43] <apw> there is a process in the kernel to copy it over ...
[16:43] <apw> ogasawara, i can take a look if you like
[16:43] <ogasawara> apw: sure, go for it
[16:43] <ppisati> GrueMaster: SECCOMP and STRICT_DEVMEM are not applicable to that release
[16:43] <ppisati> GrueMaster: i sent you a test kernel for the mlock split stuff
[16:44] <ppisati> GrueMaster: and the only missing part are the PTRACE* checks
[16:45] <GrueMaster> ppisati: Not seeing a kernel link
[16:46] <ppisati> GrueMaster: i sent it in #ubuntu-arm
[16:46] <ppisati> GrueMaster: anyway
[16:46] <ppisati> GrueMaster: http://people.canonical.com/~ppisati/linux-image-2.6.35-903-omap4_2.6.35-903.27~mlockfix_armel.deb
[16:46] <ppisati> GrueMaster: this should fix the
[16:46] <HadiM> hi
[16:46] <ppisati> GrueMaster: "Make sure the stack guard page does not split the stack on mlock ... FAIL"
[16:46] <ppisati> GrueMaster: in test-kernel.py
[16:47] <HadiM> I dont find iwlwifi / iwlagn modules in 3.2 ubuntu kernel
[16:47] <HadiM> http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
[16:47] <HadiM> is that normal ?
[16:48] <HadiM> (sorry if I am on the wrong channel)
[16:51] <ogasawara> HadiM: not sure about the mainline build (which is the url you posted), but I'm using the iwlwifi driver right now on a 3.2.0-1.2 Ubuntu kernel
[16:52] <ogasawara> modinfo iwlwifi
[16:52] <ogasawara> filename:       /lib/modules/3.2.0-1-generic/kernel/drivers/net/wireless/iwlwifi/iwlwifi.ko
[16:52] <HadiM> 32bit or 64 ?
[16:52] <ogasawara> HadiM: 64
[16:52] <HadiM> ok same here
[16:52] <HadiM> I double check the deb
[16:54] <HadiM> in the url I gave you the kernel name is 3.2.0-030200rc2-generic/
[16:54] <apw> ogasawara, when you did the rebase did you notice anything about those changing name
[16:54] <HadiM> and there is no iwlwifi dir in /lib/modules/3.2.0-030200rc2-generic/kernel/drivers/net/wireless/
[16:54] <ogasawara> apw: not that I'm aware, but tgardner did the original v3.2-rc1 rebase
[16:55] <HadiM> oh youre using the precise kernel build
[16:55] <ogasawara> HadiM: right
[16:55] <HadiM> I suppose it is not the same as http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.2-rc2-oneiric/
[16:55] <HadiM> thats strange
[16:56] <HadiM> I will try the precise build on my oneiric
[16:56] <ogasawara> HadiM: that url is to the upstream vanilla v3.2-rc2 kernel.  although I'm not sure why it would be missing there.
[16:56] <apw> tseliot, on it
[16:56] <HadiM> it is missing in 3.2 rc1 and rc2 for sure
[16:56] <tseliot> apw: thanks
[16:57] <GrueMaster> ppisati: Your kernel fixes that bug, but it must be an older spin.  It is giving me a different mac on boot, and the eth0 is now usb0.
[16:58]  * apw notes a netbook is not the speedyiest
[16:58] <ppisati> GrueMaster: no, i put the patches on top of maverick/omap4 tip
[16:59] <GrueMaster> Well, system came up with a different mac, so not sure what is different.
[16:59]  * ppisati notes kernel.ubuntu.com is dead slow...
[17:00] <ogasawara> meeting time...
[17:00] <smb> already
[17:01] <ppisati> GrueMaster: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4
[17:01] <ppisati> GrueMaster: latest 4 patches are the fix
[17:01] <ppisati> GrueMaster: and are on top of the rest
[17:03] <GrueMaster> Well it is failing my testmac test, which enables/disables the ethernet port 10 times and compares mac addresses in between.  I can't reach the system now until dns catches up with dhcp (I'm remote and the system is at home).
[17:05] <GrueMaster> Wait, I think I see the problem.  It isn't polling the die id.
[17:07] <GrueMaster> Let me reboot to the proposed kernel and verify.
[17:09] <GrueMaster> ppisati: Sorry, I guess I just never noticed it before.  I don't think 2.6.35 polls the die id for the mac address.  nevermind.
[17:10] <GrueMaster> I usually run sru tests on it locally.
[17:10] <apw> tseliot, not looking good on my machine here ... seems to partially think its a wired network and generally doesn't connect
[17:11] <jsalisbury> ogasawara, followed along ok.  I should be fine to take over next week.  Will you update the runes file to include ckings power topic?  Or should I do it when updating it from the agenda next week?
[17:11] <ogasawara> jsalisbury: I'll go ahead and update it
[17:11] <tseliot> apw: did you reboot?
[17:11] <jsalisbury> ogasawara, cool, thanks
[17:11] <apw> tseliot, yep
[17:12] <ogasawara> jsalisbury: I'm also thinking it would probably be good for you to take over reporting the "[TOPIC] Release Metrics and Incoming Bugs"
[17:12] <jsalisbury> ogasawara, sure
[17:12] <apw> tseliot, also hand blacklisted the kernel modules which pick up this device otherwise
[17:12] <ogasawara> jsalisbury: it's just a copy and past of http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:12] <jsalisbury> ogasawara, ok
[17:13] <ogasawara> jsalisbury: if there are any other bugs which you want us to look at as well, that's probably a good time time to raise them as well.
[17:13] <jsalisbury> ogasawara, good idea.  I can add a reminder about the hot list.
[17:13] <tseliot> apw: I also updated the driver to a new release, so maybe we're facing 2 different problems here. I could write a patch against the old driver and see if it helps
[17:14] <apw> tseliot, ok whatever you think
[17:14] <apw> cirtainly something is odd cause nm is mistaking it for a wired port
[17:17] <apw> tseliot, though i have no idea how nm knows what sort of port any port is
[17:18] <tseliot> apw: this is all I did: http://pastebin.ubuntu.com/746118/
[17:19] <apw> yeah seems unlikely that would fookulize everything else, so we must suspect the new driver
[17:20] <tseliot> apw: right (hopefully). Let's see if the old driver works
[17:31] <tseliot> apw: is this any better? http://people.canonical.com/~amilone/bcmwl-kernel-source_5.100.82.38+bdcom-0ubuntu5_i386.deb
[17:42]  * ppisati -> eod
[17:43] <apw> tseliot, ok with that one, after a reboot i get what appears to be working wiki
[17:43] <apw> wifi, done a bit of surfing so far, nothing hardcore
[17:46] <tseliot> apw: \o/
[17:46]  * apw watches a movie on it
[17:47] <tseliot> apw: ok, I'll keep the old driver with my patch on top
[17:48] <apw> tseliot, seems like a good first step to me
[17:51] <tseliot> apw, ogasawara: ok, I've just uploaded the broadcom driver with my patch (in Precise)
[17:51] <ogasawara> tseliot: awesome, thanks
[17:56] <tseliot> yw
[17:56] <tseliot> apw: thanks for testing
[17:57] <apw> tseliot, thanks for fixing :)  at least we have a full set of binary drivers before the kernel goes live, that must be a first
[17:57] <tseliot> apw: hehe, nice :)
[19:42] <iceroot> is it possible to build an amd64-kernel on an i386-cpu without amd64-instructions?
[19:43] <iceroot> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/869502/comments/118  then i can provide here the amd64 version too
[19:43] <ubot2> Launchpad bug 869502 in linux "Kernel-Panic with 3.0.0.12-generic on asus eee pcs and msi wind (both using rt2800 wifi chipset)" [High,Confirmed]
[19:45] <iceroot> atm i am using skipabi=true skipmodule=true fakeroot debian/rules binary-iceroot and that is building i386 here
[19:48] <ogasawara> smb: thanks for your review, I've reverted the "UBUNTU: SAUCE: xen: Do not use pv spinlocks on HVM" patch on Precise master-next.  I'll rebase it out of existence at the next rebase.
[20:16] <cdhm> Hi. I have done a lot of kernel building, but not withinb Ubuntu. What I want to do is build logfs as a module and load it.
[20:17] <cdhm> There are a lot of howtos, each different, and different for various versions. So here is what I did:
[20:18] <cdhm> mkdir /opt/ubuntu-kernel-src
[20:18] <cdhm> cd /opt/ubuntu-kernel-src
[20:18] <cdhm> sudo apt-get build-dep --no-install-recommends linux-image-$(uname -r)
[20:18] <cdhm> apt-get source linux-image-$(uname -r)
[20:18] <cdhm> cp /boot/config-2.6.38-12-generic-pae  .config 
[20:19] <cdhm> make; make modules_install
[20:20] <cdhm> That unfortunately builds and installs modules for 2.6.38.8 and not 2.6.38-12-generic-pae
[20:20] <cdhm> Hints??
[20:20] <tgardner> cdhm, make oldconfig scripts prepare; make M=`pwd`/fs/logfs
[20:21] <tgardner> cdhm, oh, first do 'fakeroot debian/rules prepare-generic-pae;cp debian/build/*/.confg .'
[20:29] <cdhm> tgardner: So what's the order of operations... do the apt-gets, then do the fakeroot thing, then the make config, then make changes to .config to turn on CONFIG_LOGFS then make logfs. Is that correct?
[20:31] <tgardner> cdhm, no, you want to change the  CONFIG_LOGFS option in debian.master/config first, then the fakeroot thing
[20:33] <cdhm> tgardner: Ok, so the order is:do the apt-gets, then nobble the debian.master/config then  do the fakeroot thing, then regular make; make modules_install
[20:36] <tgardner> cdhm, not regular make, e.g., 'cp debian/build/build-generic-pae/.config .;make oldconfig scripts prepare;make M=`pwd`/fs/logfs'
[20:37] <cdhm> tgardner: So what then does the modules install?
[20:37] <tgardner> cdhm,  assuming you're running that kernel you can simply 'sudo insmod fs/logfs/logfs.o'
[20:39] <cdhm> tgardner: Not that easy... logfs wants other modules installed too. Doing the depmod/install would be neater.
[20:40] <tgardner> cdhm, well then perhaps you should just build the whole kernel and .deb, e.g., 'fakeroot debian/rules clean binary-generic-pae', then install the linux-image debian package that gets created.
[20:42] <cdhm> So isn't there a middle ground without drinking the whole Debian KoolAid?
[20:43] <tgardner> cdhm, not really. welcome to building kernels...
[20:46] <cdhm> Hmmm. Building kernels for embedded is a lot more straight-forward with a quicker turnaround.
[22:04] <Q-FUNK> howdy!  would anyone have an ETA for applying the fix indicated for bug #892615 to the Precise kernel? 
[22:04] <ubot2> Launchpad bug 892615 in linux "3.2.0-1-generic: completely fails to boot on Geode LX" [High,Confirmed] https://launchpad.net/bugs/892615
[22:05] <Q-FUNK> someone spotted an upstream commit that allegedly fixes it.
[22:07] <tgardner> Q-FUNK, presumably it will show up in the normal course of development before 3.2 is released
[22:31] <Q-FUNK> tgardner: it currently flat out prevents the kernel from loading.