[06:53] <mfilipe> hello! I want compile a custom kernel with generic-pae config but the https://help.ubuntu.com/community/Kernel/Compile doesn't help :(
[06:54] <mfilipe> how do I do this? I only compile a custom kernel same config of generic-pae 
[06:54] <mfilipe> for start
[06:55] <mfilipe> after I want apply a custom patch but I need apply with patch program or is there any way more organized? 
[06:55] <mfilipe> I see that kernel-package has the --apply-patches but I don't know if it works with custom patch
[06:58] <mfilipe> I tried extract the /usr/src/linux-source-2.6.38.tar.bz2, copied the config of generic-pae in /boot and compile with make-kpkg, but I always get kernel panic
[08:27] <smb> mfilipe, https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel might help more.
[08:29] <mfilipe> smb, it is very confuse :(
[08:30] <mfilipe> I see tree ways to compile kernel: (1) using commands of kernel vanilla, (2) debian/rules and (3) kernel-package
[08:30] <mfilipe> some people say that kernel-package is the better solution
[08:31] <mfilipe> but when I compile my kernel with it, I get kernel panic
[08:31] <mfilipe> I will try with debian/rules
[08:32] <smb> Not if you want a kernel compiled as the provided one. Then dpkg / debian is the way to go. Everything else either has not the whole packaging or is not too well tested (we don'T use kernel-package)
[08:40] <mfilipe> smb, the better way to apply a patch is in kernel source with patch command or is there a way more organized?
[08:42] <smb> mfilipe, For just applying the change patch is the way to do it. And the simplest
[08:42] <mfilipe> thanks a lot for your help! :)
[08:43] <smb> Usually "patch -p1 < <source file>"
[12:33] <jjohansen> rebooting
[14:00] <mfilipe> hello! I want apply a patch in generic-pae. So, how do I do to create a kernel called i915patch using debian/rules based in generic-pae?
[14:01] <smb> mfilipe, You can modify the version number in debian.master/changelog
[14:01] <smb> So on the first line
[14:01] <tgardner> mfilipe, everything you need to know is somewhere in here: https://wiki.ubuntu.com/Kernel
[14:01] <smb> change 2.6.x-y.z -> 2.6.x-y.6+i915patch
[14:02] <smb> err last 6 should be z
[14:04] <tgardner> ogasawara, did you ever find the armel build problem with oneiric? I rebased to -rc6 last night and pushed to master-next.
[14:06] <ogasawara> tgardner: I've finally been able to reproduce it on kakadu.  It's basically because the compiler is optimizing a loop in megaraid_sas into a divmod call, but the error message isn't verbose enough to point out where, so I'm still hunting it down.
[14:08] <tgardner> ogasawara, has is struck you that kakadu is vaguely scatological ?
[14:08] <ogasawara> tgardner: hehe, not till you mentioned it :)
[14:09] <tgardner> ogasawara, now I've ruined your mind  with an idea :)
[14:09]  * smb thinks he might ask tgardner whatever that means over a beer...
[14:10] <tgardner> smb, giyf
[14:12] <smb> wtfmgiyf
[14:12] <ogasawara> heh
[14:12] <ogasawara> smb: google is your friend
[14:13] <smb> ogasawara, Heh, ok. Thanks. :)
[14:14] <smb> Usually I ask leo whenever our leader comes up with a even more mystical attribute for a release...
[14:16] <smb> Ok, so wikipedia knew it... :-P
[14:16] <ogra_> tgardner, armel doesnt build atm, gcc issues that cause apt to segfault
[14:16] <ogra_> dont even try :)
[14:17] <ogra_> Bug 774175
[14:17] <ubot2> Launchpad bug 774175 in apt "apt segfaults on armel in oneiric" [Critical,Confirmed] https://launchpad.net/bugs/774175
[14:18] <mfilipe> smb, thanks man! :)
[14:18] <tgardner> ogra_, ok. oneiric  _is_ getting quite aways into the build but we're encountering a missing symbol error. We're not gonna worry about it too much for awhile.
[14:18] <ogra_> tgardner, ah
[14:19] <ogra_> well, i dont expect image builds before A1
[14:19] <ogra_> tgardner, btw, would you mind bringing my ultra small wlan stick to UDS ? i forgot to claim it back last time
[14:21] <tgardner> ogra_, hmm, its so small that I haven't seen it in awhile.
[14:21] <tgardner> I'll look around for it
[14:21] <tgardner> that the problem with thos itty bitty gizmos. they are easily lost
[14:21] <ogra_> hehe, or forgotten :)
[14:21] <tgardner> well, that too
[15:18] <ogasawara> tgardner: don't suppose we'll ever get armel chroots on tangerine for oneiric?
[15:18] <tgardner> ogasawara, hrmph. I can't even get them working reliably for natty.
[15:18] <tgardner> not on a lucid host, that is.
[15:19] <ogasawara> tgardner: I figured as much, I won't hold my breath
[15:19] <tgardner> ogasawara, I guess we'll just have to stick with cross compiling for now
[15:21] <bjf> JFo, i'm going to edit: https://wiki.ubuntu.com/Kernel/BugTriage/BugStates, feel free to revert my changes if you feel them inappropriate
[15:24] <tgardner> ogasawara, one thing we could consider is upgrading tangerine to natty. that would at least give you a natty armel schroot. alternatively, I could spend some serious time with slangasek whilst in Budapest to see if we can figure out the Lucid host issues.
[15:28] <bjf> JFo, i take that back, i made no changes, i'm unhappy with the page but not sure how to "fix" it
[15:29] <ogasawara> tgardner: nah, cross compiling should be fine, it's just unfortunately not triggering the gcc error at the moment
[15:36]  * ogasawara back in 20
[15:40] <JFo> bjf, I feel the same
[15:40] <JFo> :-/
[15:40] <JFo> been trying to figure out how best to address it
[15:40] <JFo> but not making much in the way of progress
[15:40] <bjf> JFo, i'll send email with my thoughts, mostly what I don't like about it
[15:41] <JFo> sounds good
[15:41] <JFo> I'll respond with some of what I have been thinking of as well
[15:41] <JFo> maybe we can figure it out
[16:11] <Kano> hi, is it possible to get 32+64 bit mainline kernel for 39rc6
[16:11] <Kano> since rc5 32 bit is not available
[16:12] <Kano> it can not be that compilcated to change the config in order to skip that stupid module that does not build
[16:13] <Kano> since 20th april only 64 bit is there
[16:13] <Kano> 2 weeks for a config change?
[16:22] <tgardner> Kano, whats the config option that isn't building. I guess we don't check the success of the daily crack builds very often.
[16:23] <Kano> maybe look at the log
[16:24] <JFo> I would have expected you had done that given your statement
[16:26] <Kano> olpc_dcon
[16:26] <Kano> fails, the option should not be that hard to find
[16:27] <tgardner> CONFIG_FB_OLPC_DCON ?
[16:28] <Kano> looks reasonable
[16:32] <apw> tgardner, turning off those things is normally done via the 'adhoc' patches
[16:32] <apw> which are based on the bust version of the file
[16:33] <apw> there is one for another of the files in that driver
[16:33] <tgardner> apw, looks like we've a patch in the ubuntu repo that include delay.h
[16:33] <bjf> JFo, wiki page rant sent
[16:33] <apw> adding the checksum to the patch for that additioanl file should do the trick i think
[16:34] <apw> tgardner, ok i'll look at switching the adhoc to that then
[16:34] <tgardner> apw, there is already a 0004-DISABLE-olpc.patch
[16:34] <apw> yeah thats dependant on a file which seems to have gotten fixed
[16:35] <apw> tgardner, i'll widen it to all the files in that driver or something
[16:35] <tgardner> apw, cool. its your baby now.
[16:46] <mfilipe> anyone has the processor intel iX? If answer yes, what is the temperature when it compiling kernel?
[16:46] <mfilipe> it is compiling kernel*
[16:47] <Kano> there are iX cpus with 3 or 4 numbers
[16:48] <mfilipe> I'm using intel i5 560M and the temperature is 84C when compile kernel
[16:48] <smb> mfilipe, The kernel compile surely tests how well your cooling works as it uses all cores
[16:49] <smb> 84 is surely not good
[16:50] <mfilipe> it is a mobile version 
[16:50] <mfilipe> i'm compiling with --jobs=4 (make-kpkg)
[16:52] <mfilipe> smb, i use a thinkpad with cooler control through software (thinkfan)
[16:52] <smb> From personal experience compiling on a laptop usually causes high temperature. I would probably try to limit the upper frequence though it takes longer then
[16:53] <JFo> bjf, I think your explanation clarifies what I was worried about and provides a better way forward than what I had. I agree completely.
[16:53] <mfilipe> the cooler is running with disengaged level
[16:53] <mfilipe> hehe
[16:54] <bjf> JFo, i'm wondering if i should pass that around to a larger audience as a general comment on our wiki pages
[16:54] <JFo> I think so. It would definitely benefit imo
[16:54] <smb> mfilipe, Well disabling fans and running cpu intensive tasks is a good recipe for meltdown.. :-P
[16:55] <mfilipe> lol
[16:55] <mfilipe> but disengaged level is the extreme level of cooler... it is running with ~5800 RPM
[16:56] <smb> ah, so the wording is a bit misleading
[17:21] <apw> tgardner, ok rebuilding the last mainline tag to see if that fixes things
[17:22] <tgardner> apw, kano thanks you
[17:22] <Kano> would be nice for oss testing
[17:22] <Kano> a new kernel
[17:23] <Kano> for userspace i have got already scripts
[17:26] <jgould> I installed a new kernel .deb (and the header.debs) Now none of my modules are working.  for the life of me I can't recall how to complie the modules for the new kernel
[17:27] <Kano> if you try .39 kernel you may need to patch em
[17:27] <Kano> which modules do you need
[17:28] <jgould> ndiswrapper, plymouth for srue
[17:28] <Kano> plymouth has no module
[17:28] <Kano> but ndiswrapper was a kernel patch, logically you need that now external
[17:28] <apw> jgould, it would depend which kernel you are installing
[17:28] <jgould> 2.6.39-999
[17:29] <apw> jgould, yeah so thats mainline and doesn't include ndiswrapper, thats an ubuntu add on and those are not ubuntu kernels
[17:29] <jgould> I can't use the stock .38-8-generic
[17:30] <apw> jgould, why so ?
[17:30] <jgould> It contains the bug that affects the i915 graphic chipset
[17:30] <apw> which bug is that?
[17:30] <apw> is the 38-9 kernel in -proposed affected ?
[17:30] <jgould> https://bugzilla.redhat.com/show_bug.cgi?id=669489
[17:30] <ubot2> bugzilla.redhat.com bug 669489 in kernel "Include ACPI _DSM index and label support" [High,New]
[17:32] <jgould> apw: you lost me with -proposed
[17:32] <jgould> I'm just coming back to Ubuntu after about 10 years away from linux
[17:32] <apw> there is a proposed pocket, this contains the likely next updates, and does currently contain a kernel update
[17:33] <apw> jgould, but either way you won't find an ndiswrapper for the mainline kernels, as they don't include ubuntu modules
[17:34] <jgould> damn
[17:37] <jgould> fucking intel hardware
[17:37] <apw> jgould, worth testing both the proposed kernel and the preproposed on as both have a lot of stable updates
[17:37] <apw> https://wiki.ubuntu.com/Testing/EnableProposed
[17:37] <apw> ^^ for the proposed kernels
[17:38] <apw> https://launchpad.net/~kernel-ppa/+archive/pre-proposed
[17:38] <apw> ^^ for pre-proposed
[17:42] <apw> jgould, if there is no ubuntu bug for that filed, please file one and link it to the redhat one
[17:43] <apw> tgardner, am i expecting brcm80211 to work at all?  i just noticed i am using it on this machine, rather unexpectedly
[17:43] <Kano> bye
[17:43] <tgardner> apw, 2.6.39 ?
[17:43] <apw> no i seem to be running a 2.6.38-9 kernel
[17:43] <tgardner> it works in most cases. I think it still has issues with WPA2 enterprise.
[17:44] <tgardner> its still staging
[17:44] <apw> hmmm, ok, i'll let it play this week and see how/if it copes 
[17:45] <jgould> apw, I've never found one, but I may not have the right terms
[17:46] <apw> i wonder when it switched over
[17:46] <apw> jgould, then do file one with ubuntu-bug
[17:47] <mfilipe> smb, I could compile the kernel with make-kpkg!!! :)
[17:47] <mfilipe> the commend was very big: make-kpkg --rootcmd=fakeroot --initrd --append-to-version=-i915patch --overlay-dir=/home/mfilipe/Workspace/linux-2.6.38-i915patch/linux-2.6.38 --revision=1 --jobs=4 kernel_image kernel_headers
[17:47] <mfilipe> hehehe
[17:51] <hggdh> bjf: I just ran SRU tests against the karmix EC2 kernel; but the versions being reported are weird
[17:51] <bjf> hggdh, weird as in ?
[17:52] <hggdh> bjf: /proc/version_signature reports Ubuntu 2.6.31-308.28-ec2, but dpkg shows 2.6.31-308.29
[17:52] <hggdh> sorry, slow typing
[17:55] <bjf> hggdh, not sure what to say about that
[17:55] <bjf> sconklin, thoughts? ^
[17:56] <sconklin> reading
[17:56] <sconklin> strange, let me look at that branch of the repo
[18:00] <bjf> sconklin, looking at the .changes for the package i uploaded, it looks right to me
[18:03] <tgardner> bjf, the repo shows Ubuntu-2.6.31-308.29
[18:03] <bjf> tgardner, yes
[18:04] <tgardner> bjf, this might be a  CONFIG_VERSION_SIGNATURE issue
[18:07] <tgardner> hggdh, are you sure you booted the right kernel ?
[18:09] <hggdh> tgardner: sure? No. But please see http://pastebin.ubuntu.com/603352/
[18:09]  * ppisati -> gym
[18:12] <tgardner> hggdh, hmm, definitely bizarre.
[18:13] <hggdh> hum. Let me do a quick sanity check with smoser
[18:15] <hggdh> tgardner: some ec2 versions have peculiarities...
[18:15] <jgould> Bug has been filed
[18:16] <tgardner> hggdh, well, they shouldn't have version peculiarities.
[18:18] <tgardner> hggdh, I downloaded the package and groveled vmlinuz-2.6.31-308-ec2 for strings:Linux version 2.6.31-308-ec2 (buildd@crested) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu9) ) #29-Ubuntu SMP Fri Mar 18 22:02:21 UTC 2011 (Ubuntu 2.6.31-308.29-ec2)
[18:21] <bjf> tgardner, i did some comparison between what is in our ppa and what is in the pocket, and they match
[18:21] <hggdh> so I really need to check with smoser
[18:21] <tgardner> hggdh, yep. good catch on the version though.
[18:21] <hggdh> tgardner: the peculiarities come in play on how one boots the original instance...
[18:21] <bjf> hggdh, something seems wonky on your end
[18:22] <hggdh> indeed
[18:32] <jgould> Ok. Back to the MacOS on this other machine for a while...
[18:37] <JFo> <-grabbing food... back soon
[18:54]  * tgardner --> lunch
[20:16]  * jjohansen -> lunch
[20:58] <smoser> hggdh, i would assume that the kernel is reporting itself wrong in that case.
[21:00] <tgardner-afk> smoser, its can't be. that string is only stored in one place. I think the wrong kernel got installed.
[21:02] <smoser> tgardner-afk, hggdh so, i suspect that what happened here is that hggdh booted a karmic instance and apt-get upgrade (or perhaps apt-get dist-upgrade)
[21:02] <smoser> the result is that the kernel in dpkg was upgraded, but karmic will forever boot the kernel that it booted with
[21:05] <tgardner-afk> smoser, that seems likely
[21:42] <smb> hggdh, smoser Be careful when looking at versions as it is sometimes easy to catch the version of the meta-package instead of the binary
[21:47]  * smb -> off for real
[21:48] <hggdh> smb indeed, will keep it in mind