[00:23] <JFo> bjf, am now
[00:23] <bjf> JFo, no big deal, someone was pointing out a Launchpad oddity
[00:23] <JFo> ah
[00:24] <bjf> JFo, just emailed some links to you
[00:25] <JFo> sweet
[00:25]  * JFo looks
[00:25] <bjf> the "current series" is 2.6.31
[00:25] <bjf> i'd never looked at any of those pages
[01:07] <JFo> yeah, we need to change the development focus :)
[03:36] <MTecknology> jussi: You ever get that figured out?
[08:05]  * amitk waves
[08:07]  * cooloney waves back to amitk 
[09:00] <om26er> is there any technical name for gpu-switching? (for finding related bugs upstream)
[09:07] <apw> om26er, not sure i even know what you mean by gpu-switching
[09:09] <om26er> apw, there are system with two graphics card. e.g alienware m11x
[09:09] <apw> i would call those dual-gpu something like that
[09:23] <ogra> apw, do you know if anyone is on top of bug 595949 ?
[09:23] <ubot2> Launchpad bug 595949 in linux-meta-ti-omap (Ubuntu Maverick) (and 1 other project) "linux-meta-ti-omap depends on the wrong binary kernel in maverick (affects: 1) (heat: 8)" [Critical,New] https://launchpad.net/bugs/595949
[09:56] <apw> ogra, not sure, will look
[10:23] <apw> achaemenes, wondering why you need to turn off that option?
[10:26] <achaemenes> apw: I'm doing some security research, and writing a rootkit for 8.04 - however from 2.6.24-19 to 2.6.24-28, that option has been enabled - as is happening with most kernels in most distros - however i have to keep it disabled because my work hasn't yet finished, but I'd like to be on the latest 8.04 kernel while developing it
[10:27] <achaemenes> once it's complete, I'll have to write an anti-rootkit for it
[10:27] <achaemenes> and after that, again a rootkit that does not modify syscall tables at all, and again an anti-rootkit for that... etc. 
[10:32]  * achaemenes git clones
[10:33] <apw> achaemenes, if you have a local linux-2.6 tree you can --reference that, as we are pretty close to mainline
[10:34] <achaemenes> ahh thanks, good to know
[10:55] <lag> Has anyone build the Lucid ti-omap branch recently?
[10:55] <lag> built*
[10:56] <ogra> lag, i guess smb since there were security updates in lucid
[10:56] <lag> Thanks ogra
[10:59] <apw> i built it i believe to when testing the debian commonisation changes
[11:17] <achaemenes> i hear make-kpkg is now the "old way" :)
[11:17] <achaemenes> man i felt old after reading that
[11:19] <arun> achaemenes,  what's the new way to build kernels?
[11:27] <ogra> apw, hmm, dont we end up with clashing binaries now for linux-omap ? 
[11:28] <ogra> since the old one still exists in the archive
[11:34] <achaemenes> arun - i was just reading the ubuntu page which is where i read that comment: https://help.ubuntu.com/community/Kernel/Compile#Alternate Build Method: The Old-Fashioned Debian Way
[11:37] <achaemenes> apw - is that the best page i should be reading for doing what i'm doing?
[11:39] <apw> achaemenes, i would normally build from the git tree
[11:40] <apw> git checkout -b foo <tag>
[11:40] <apw> then use a chroot to build it
[11:40] <achaemenes> since the clone, all ive done is "git checkout Ubuntu-2.6.24-28.71                     "
[11:40] <apw> fakeroot debian/rules clean; fakeroot debian/rules binary-generic
[11:40] <apw> (both inside the chroot)
[11:41] <achaemenes> and i am guessing debian/config/i386/condif.server shoud be == /boot/config-`uname -r`
[11:43] <apw> yep the config fragments used to make the configs are in debian/config
[11:44] <achaemenes> hmmm, this is odd: /usr/src/ubuntu-hardy is not clean, please run 'make mrproper'
[11:44] <achaemenes> if i mrproper, all the goodies will disappear
[11:44] <apw> try rmdir include/config
[11:45] <achaemenes> hmm, no such directory - I'll just post a complete log of what I've done in case I'm doing something silly (/me prepares pastebin)
[11:47] <achaemenes> http://pastebin.com/kTNmSsY0
[11:47] <achaemenes> and there is no include/config or include/config*
[11:48] <apw> what does git ls-files -o show
[11:49] <achaemenes> no output at all
[11:52] <apw> achaemenes, oh you have .config
[11:52] <apw> you don't put the .config in the top level
[11:52] <achaemenes> apw - oh? they how will it know what to build?
[11:53] <apw> it will build the flavour config for the flavour that you speciified
[11:53] <apw> binary-server for the server config
[11:53] <achaemenes> ohhhh
[11:53] <achaemenes> of course!
[11:53] <achaemenes> duh
[11:53] <apw> rm .config and it'll work i suspect
[11:53] <achaemenes> thankyou apw - you've been increadably helpful - and yet - that was it!
[11:54] <achaemenes> i didnt even think twice on that
[11:55] <achaemenes> apw will you be making it (or interested in) ruxcon? :)
[11:55] <apw> heh don't think i'll be there
[11:55] <apw> some of our security people might though
[12:09] <amitk> cooloney: lag: so TI-omap4 is based on 2.6.33 or 34?
[12:09]  * amitk thinks it is .34, based on the renamed package
[12:09] <ogra> amitk, .34
[12:10]  * ogra will start building hand-rolled test images today for omap4
[12:10] <ogra> so you can try it if you have omap4 HW
[12:10] <amitk> ok, I got confused by some commits I saw from lucid in there
[12:10] <lag> VERSION = 2
[12:10] <lag> PATCHLEVEL = 6
[12:10] <lag> SUBLEVEL = 34
[12:10] <lag> EXTRAVERSION =
[12:10] <lag> NAME = Sheep on Meth
[12:10] <lag> :)
[12:10] <amitk> ogra: no OMAP4 HW here
[12:10] <lag> Who names these things?
[12:10] <lag> :)
[12:10] <ogra> time you get some 
[12:11] <apw> ogra, the linux-image-omap meta packages are updated in maverick
[12:11] <apw> lag, thats linus himself
[12:11] <lag> apw: Maybe he needs to stay off the stuff himself 
[12:12] <apw> lag, very likely :)
[12:12] <lag> /
[12:30] <thangam_arun> Hello All
[12:31] <thangam_arun> i am building kernel on Ubuntu-8.10
[12:32] <thangam_arun> but at the end i am getting two .deb files(image, kernel-header)
[12:32] <thangam_arun> But i want to build debug kernel 
[12:32] <thangam_arun> how do i get that .deb file ??
[12:32] <thangam_arun> linux-headers-2.6.27-17-core2_2.6.27-17.46_i386.deb linux-image-2.6.27-17-core2_2.6.27-17.46_i386.deb 
[12:33] <thangam_arun> these are tow files i got, after compionilat
[12:33] <thangam_arun> *compilation
[12:33] <thangam_arun> sudo CONCURRENCY_LEVEL=2 NOEXTRAS=1 skipabi=true skipmodule=true fakeroot debian.master/rules binary-core2
[12:34] <thangam_arun> the above one is used for kernel compilation 
[12:34] <thangam_arun> Can you please some one help to get "debug" kernel .deb file 
[12:37] <thangam_arun> i am witing for reply ??
[12:44] <smb> thangam_arun, If you are looking for the package that contains the unstripped binaries, try adding a skipdbg=false to you cmd line
[12:45] <thangam_arun> smb: Okay
[12:45] <thangam_arun> smb: wht about "binary-debs" ??
[12:46] <thangam_arun> smb, Any idea?
[12:47] <smb> No I am trying to understand what exactly you mean with binary-debs.
[12:47] <smb> As an argument
[12:47] <smb> or as something else
[12:47] <thangam_arun> okay
[12:48] <smb> That was sort of a question on my side. :)
[12:48] <smb> As targets I usually use only binary-<flavour> or binary or binary-arch
[12:49] <thangam_arun> oh ok
[12:49] <smb> I mean, you got a linux-image apparently, which would be the binary kernel package.
[12:49] <thangam_arun> yes that correct
[12:50] <smb> You might want to make a run with either binary-indep or binary-header which creates the common headefr package
[12:50] <thangam_arun> is that enough for debugging purpose ?
[12:51] <bguthro> Hello,
[12:51] <smb> Depends on how you debug. If you add printk's or use special debugging options you might not need the debug package. That only help to disassemble stuff or find symbols or profile
[12:52] <smb> thangam_arun, But otherwise that should be enough
[12:52] <thangam_arun> in this build i have configured "debug" in the "kernel hacking" section
[12:53] <bguthro> I'm attempting to chase down an Intel i915 problem in lucid - nothing displayed on an E6410... I've tried up to the mainline builds of 2.6.35-rc1: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid - and now wanted to try the Intel-drm development branch from kernel.org...but wanted to know if there was some build patch that I can apply over the top, to get the deb build system...
[12:55] <bguthro> I assume this is one of kees trees here: http://kernel.ubuntu.com/git?p=kees/linux-2.6.git;a=summary - but didn't know if there was a patch I should be using, to apply on top of a different devel branch: http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=summary
[12:56] <smb> thangam_arun, Hm, I cannot say from my head what exactly that enables. Generally the build has bdebugging informationenabled but strips things for the normal packages
[12:58] <smb> bullgard4, It looks like something from kees and maybe you will find useful things under mainline-build in git://kernel.ubuntu.com/ubuntu/kteam-tools.git but apw may have better info or even written a wikke 
[12:58] <thangam_arun> smb, okay
[12:58] <thangam_arun> smb, let me experiment and see
[12:59] <smb> thangam_arun, best way to go. :)
[13:00] <thangam_arun> smb, bwt when i gave binary-debs building extra modules, i do not know why :)
[13:00] <apw> bguthro, don't we already build the drm-intel branch in the mainline builds ?
[13:01] <smb> thangam_arun, Ugh, I fail to parse that last sentence. o_O
[13:01] <apw> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
[13:01] <apw>  thangam_arun which ones extra do you get ?  .udebs perhaps ?
[13:01] <bguthro> Excellent. I missed that. Thanks - saves me some time!
[13:02] <thangam_arun> smb, when i pass "binary-debs" option for compliation, it is compiling new modules 
[13:03] <bguthro> Is there a git tree somewhere that this is generated from that I could dig into, if I have to debug this LVDS issue?
[13:03] <apw> bguthro, nope.  but the scheme is simple, checkout the debian* directories from lucid/master into your mainline tree, update the configs and buil
[13:04] <apw> build .. thats is what the mainline builds do
[13:04] <bguthro> apw, sounds like a plan. Thanks a lot
[13:04] <smb> thangam_arun, Hm, ok. Maybe the udeb packages?
[13:05] <thangam_arun> smb, might be. waiting for build to complete
[13:32] <achaemenes> apw - i forgot to ask, say i want to amend the "binary-server" - which config file do i change?
[13:33] <achaemenes> debian/config/i386/config.server maps to binary-server? or there is more magic to it?
[13:38] <apw> i think you change debian/config/i386/config:CONFIG_DEBUG_RODATA=y
[13:38] <apw> and usually run debian/rules updateconfigs afterwards
[13:44] <achaemenes> right, and all the other configs in there are regened
[13:46] <achaemenes> hmmm, no 
[13:46] <achaemenes> git status shows only that file to have changed
[13:46] <apw> thats good, that means your change stuck
[13:47] <achaemenes> is there an inheritance model with those files then?
[13:47] <apw> yeah the config is common to the others
[13:47] <achaemenes> ahh ok now i get it
[14:32] <ccheney> apw: i need kernels please... ;-)
[14:33] <ccheney> apw: aka is there a status update yet? :)
[14:34] <ccheney> tgardner, or do you happen to know?
[14:45] <tgardner> ccheney, eh? know about what?
[14:46] <ccheney> tgardner, oh sorry i didn't explain what i am asking about, i need ppa test kernels (or however they will be provided) for rc's between 2.6.32 and 2.6.33 to track down the cause of bug 588861
[14:46] <ubot2> Launchpad bug 588861 in linux (Ubuntu Maverick) (and 4 other projects) ""pad block corrupted" error when trying to register an image with 2.6.34 kernel (affects: 1) (heat: 12)" [High,Triaged] https://launchpad.net/bugs/588861
[14:46] <ccheney> tgardner, its a blocker for UEC
[14:46] <tgardner> ccheney, uh, hang on while I figure it out
[14:46] <ccheney> tgardner, jjohansen was looking into it but said he might not have time to get to them and so you or andy might end up generating them
[14:47] <ccheney> its becoming more urgent as i'm pretty sure your kernel alpha 2 freeze window is rapidly approaching :)
[14:48] <tgardner> ccheney, well, I'm pretty sure you're releasing A2 with a Lucid kernel
[14:48] <ccheney> tgardner, yea i think at this point we will probably need to do that
[14:48] <ccheney> even if we find the kernel it broke in it might not be obvious how to fix it
[14:49] <tgardner> ccheney, this is the -virtual flavour, right?
[14:51] <ccheney> -server
[14:51] <ccheney> i tested using the ppa mainline kernels where it was seen as well
[14:51] <ccheney> the error happens on the walrus server not inside a kvm instance
[14:52] <tgardner> ccheney, what is a walrus server?
[14:52] <ccheney> its the part of eucalyptus that stores images for use by instances
[14:53] <ccheney> tgardner, so basically i try to add a lucid image to the uec machine to be used by instances that want to use it and when doing so it gives me the pad block corrupted error
[14:55] <tgardner> ccheney, so you want a -server flavour built from sources somewhere between 2.6.32.15.5 and 2.6.33 ?
[14:55] <ccheney> yes -server if possible but for testing it can be even mainline like at http://kernel.ubuntu.com/~kernel-ppa/mainline/ as it shows the same issue
[14:56] <ccheney> whichever is easier on you guys
[14:59] <tgardner> ccheney, damn, I had apw clean up all those daily builds just last week.
[14:59] <tgardner> ccheney, I'll start reproducing the 2.6.33-rcX builds to see if we can narrow it down
[15:01] <ccheney> tgardner, sorry we didn't get to it sooner I was out on paternal leave for the past 2 weeks and got assigned the bug on last Friday, from what I recall they were already gone at that time.
[15:07] <pgraner> JFo: can you get this on one of our lists? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/449043
[15:08] <ubot2> Launchpad bug 449043 in linux (Ubuntu) "Suspend/resume failing with Audigy2 PCMCIA attached (affects: 5) (dups: 1) (heat: 30)" [Undecided,Triaged]
[15:08] <JFo> pgraner, yessir
[15:45] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/2.6.33/linux-image-2.6.33-rc1_2.6.33-rc1-1_amd64.deb
[15:51] <ccheney> thanks
[15:52] <tgardner> ccheney, -rc2 is building, but I suspect you'll find that -rc1 doesn't work. -rc1 is where most of the new changes appear
[15:52] <ccheney> ok thanks
[15:53] <tgardner> I'll bisect between 2.6.32 and 2.6.33-rc1 if that is the case
[15:53]  * ccheney hopes he didn't corrupt his setup, might have to reinstall maverick before testing
[15:54] <ccheney> ok will try to get this tested asap, my euca-* commands aren't working at the moment, going to see if rebooting helps, otherwise may be another hour before i can test to do a full reinstall
[15:56] <ccheney> wow that deb is giant :)
[15:57] <tgardner> ccheney, its probably not stripped. I build using the Kbuild deb-pkg target
[15:57] <ccheney> oh ok
[15:57] <tgardner> it'll make bisection a lot quicker
[15:57] <smb> sconklin, Hi Steve, be careful with that last SRU. I was under the impression it was invalid
[15:58] <JFo> apw, you around?
[15:59] <JFo> looks like we need to do some updating to https://edge.launchpad.net/linux/
[16:02] <tgardner> JFo, wow, I've never seen that page
[16:02] <JFo> heh
[16:02] <JFo> bjf pointed it out to me yesterday
[16:03] <JFo> along with this one https://edge.launchpad.net/linux/2.6.31
[16:03] <JFo> but there doesn't appear to be a corresponding .35 page
[16:04] <JFo> or anything later than that for that matter
[16:04] <ogasawara> JFo: is that the project to allow setting upstream bug watches?
[16:04] <JFo> ogasawara, I think so, but I am not sure
[16:05] <JFo> it is owned by us though
[16:06] <JFo> ogasawara, we can change these pages yes?
[16:06] <JFo> since it is showing .31 as the dev effort :)
[16:06] <ogasawara> JFo: not sure if we can or if we have to ask the launchpad team to help
[16:06] <sconklin> smb: you mean only the one from Manoj, right? If so, I agree and it is not in my branch
[16:06] <JFo> hmmm
[16:06] <ogasawara> JFo: right, definitely out of date
[16:06] <JFo> heh
[16:06]  * JFo tries something
[16:07] <smb> sconklin, Right I was referring to that. It sounded like that was next on your list when quickly reading over that
[16:07] <JFo> ogasawara, want me to try changing it to .35?
[16:07] <bjf> JFo, there was a page were you could register a new "series"
[16:07] <JFo> I think I have the power
[16:07] <ogasawara> JFo: sure
[16:07] <bjf> JFo, but I didn't play with it
[16:07] <JFo> hmmm
[16:07] <sconklin> smb: no, I couldn't tell what was needed and it looked incomplete so I was going to leave it alone
[16:08] <smb> sconklin, Ok, right. Taht was one were apw and myself have looked at and did not find real eviddence why it should be broken. And I think manjo wanted to test it again and I don't remember feddback there.
[16:08]  * JFo waits for LP to refresh
[16:09] <JFo> ogasawara, look at it now
[16:09] <ccheney> tgardner, it tells me unknown command recordfail
[16:09] <JFo> I changed it to trunk
[16:09] <JFo> as dev seried
[16:09] <ccheney> tgardner, at grub when trying to boot your kernel
[16:09] <JFo> err series
[16:09] <ogasawara> JFo: cool
[16:10] <bjf> JFo, on https://launchpad.net/linux/ there is a link "Register a series"
[16:10] <smb> bjf, sconklin I am currently listening to a training session. But we can get together after that when you want to. (to sort out questions)
[16:10]  * ccheney wonders if something he did when he removed the old kernels and installed the new one messed up grub somehow
[16:10] <bjf> smb, wfm
[16:10] <ogasawara> JFo: and it is indeed the project that was set up that allows setting the upstream bug watches
[16:10] <JFo> cool, I thought it must be
[16:11] <ogasawara> JFo: I opened a bug with an upstream bug watch and followed the links back to that page
[16:11] <JFo> cool :)
[16:12] <tgardner> ccheney, you can still boot older kernels? you though you might have borked you UEC enviro.
[16:12] <tgardner> thought*
[16:12] <ccheney> tgardner, well i didn't know i had borked grub, but yea it seems to not boot any kernel now for some reason and i see insmod messages in the grub config, which seem somehow wrong as well
[16:12]  * ccheney looks at his other systems grub config file
[16:13] <jaminc> I'm currently experiencing Bug #593650, as part of the troubleshooting I've tested a few kernel builds from the mainline PPA.  Each of the builds I've tested so far (.35-rc3 and .34) appear to correct the crash issue, but each appear to be interact badly with libvirtd managed VMs... suggestions?
[16:13] <ubot2> Launchpad bug 593650 in linux (Ubuntu) "periodic kernel crash and system reboot (affects: 1) (heat: 8)" [Undecided,Confirmed] https://launchpad.net/bugs/593650
[16:13] <tgardner> ccheney, well, make sure you have a stable boot environment first.
[16:13] <ccheney> hmm i bet the insmod stuff has to do with grub2, i don't know that much about the newer version
[16:16] <JFo> ogasawara, I find it interesting that https://edge.launchpad.net/linux/trunk shows incomplete info
[16:16] <JFo> looks like there may be a bzr branch somewhere that isn't up to date or something
[16:16] <ccheney> hmm yea it booted back up fine under 2.6.35-4-server, will try the test kernel again to see what is going on
[16:17] <ogasawara> JFo: yah was wondering why it was only showing through 2.6.32-rc8
[16:17] <JFo> ogasawara, is this ours ~vcs-imports/linux/trunk ?
[16:18] <ogasawara> JFo: no idea, I'm not sure where the trunk actually lives
[16:18] <JFo> hmmm
[16:19] <JFo> ogasawara, looks like it is here https://code.edge.launchpad.net/~vcs-imports/linux/trunk
[16:19] <ccheney> tgardner, hmm yea just the test kernel fails with 'recordfail' related error message, the server kernel works, tested it a second time
[16:19]  * ccheney looks to see what the cause of that would be
[16:19] <ogasawara> JFo: interestingly, the recent revisions notes looks accurate (ie 2.6.35-rc3)
[16:20] <JFo> yeah, was just looking at that
[16:20] <tgardner> ccheney, shit, must be the way the kernels are packaged. are you running update-initramfs ?
[16:20] <ogasawara> JFo: Ah, "This branch is an import of the HEAD branch of the Git repository at git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git."
[16:20] <ogasawara> JFo: so it seems to generate from mainline which is good
[16:20] <ccheney> tgardner, not manually, but i can if needed
[16:20] <tgardner> ccheney, give that a try
[16:21] <tgardner> 'update-initramfs -u' after 'dpkg -i'
[16:21] <JFo> ogasawara, wonder why the other data is wrong then
[16:21] <ogasawara> JFo: but I can't explain why it's then displaying out of date
[16:21] <JFo> hmmm
[16:21] <JFo> let me think on it a minute
[16:21] <JFo> I may have an idea why
[16:21] <ccheney> running: update-initramfs -k all -c  to see if it helps
[16:23] <ccheney> just running that didn't seem to help
[16:23] <ccheney> maybe i should run it verbose to see if it is having problems? it didn't return any errors when i ran it though
[16:24] <tgardner> ccheney, lemme build a 2.6.32.15 kernel just to make sure its a packaging issue.
[16:24] <ogasawara> JFo: maybe has to do with the milestones? https://edge.launchpad.net/linux/+milestones
[16:24] <ccheney> tgardner, ok
[16:24] <JFo> could be
[16:24] <ogasawara> JFo: as those look to only go up through 2.6.32-rc8
[16:24] <JFo> hmmm
[16:24] <JFo> that has to be it
[16:25] <JFo> so ogasawara it looks like it pulls those from registered series
[16:25] <JFo> I registered https://edge.launchpad.net/linux/2.6.35
[16:25] <JFo> but it has no milestones
[16:25] <JFo> wonder where those were coming from before
[16:26] <ogasawara> JFo: "Milestones belong to a series and can be created from the series page by a project owner or series release manager."
[16:27] <JFo> hmmm, but I am sure no one from upstream was creating these in LP
[16:27] <jaminc> any ideas on what would cause mainline kernel builds to somehow cause libvirt managed VM disk image files to be non-writable?
[16:27] <JFo> or rather, reasonably sure
[16:27] <ogasawara> JFo: I think the project ower is actually the ubuntu-kernel-team
[16:27] <JFo> yeah, that makes sense due to us owning the pages/branch/etc
[16:28] <ogasawara> JFo: so I think you need administrative rights with the ubuntu-kernel-team to then create the milestones for a series
[16:28] <JFo> hmmm
[16:28] <JFo> looks like I have that type of permission
[16:28] <JFo> if I hit create milestone
[16:28] <JFo> it gives me a dialog where I can enter the info
[16:29] <JFo> looking at this page https://edge.launchpad.net/linux/2.6.34
[16:29] <JFo> toward the bottom
[16:29] <JFo> you have it too I bet
[16:29] <ogasawara> JFo: I don't have that magic
[16:29] <ogasawara> JFo: you'r special
[16:29] <JFo> oooh
[16:29]  * JFo feels powerful
[16:29] <JFo> :P
[16:30] <JFo> well, if you feel it is worthwhile, I can look up the milestones for .34 and .35 and add them I guess
[16:30] <JFo> not sure what the benefit is though
[16:30] <ogasawara> JFo: not sure who actually looks at that page
[16:30] <JFo> same here
[16:30] <JFo> or if it has some impact on anything in bugs
[16:31] <ogasawara> JFo: and it seems annoying you'd have to go and set the milestone for each -rc kernel that comes out
[16:31] <JFo> yep, we are thinking the same
[16:31] <ogasawara> JFo: maybe just set 2.6.35-rc1, 2.6.35-rc2, and 2.6.35-rc3 and call it done
[16:31] <JFo> so maybe I just do it for the kernels we determine to use for a release
[16:32] <JFo> sounds fine
[16:32] <ogasawara> JFo: yah, I wouldn't bother with 2.6.33 or 2.6.34
[16:32] <JFo> yeah
[16:32] <JFo> k
[16:32] <JFo> will do
[16:34] <JFo> ogasawara, is there a good place to find release dates for RC?
[16:35] <ogasawara> JFo: hrm, just a sec and let me see if I can find you something
[16:35] <JFo> ooh, I may have found something
[16:36] <ogasawara> JFo: shoot, I thought the kernel version map might have it
[16:36] <JFo> I found an RSS feed for releases
[16:36] <ogasawara> but doesn't :(
[16:36] <JFo> lemme check
[16:36] <JFo> ogasawara, I found http://www.kernel.org/kdist/rss.xml
[16:36] <JFo> it shows release dates :-)
[16:36] <JFo> June 11 was RC3 yes?
[16:37] <ogasawara> JFo: yep that sounds right
[16:37] <JFo> RC2 June 6?
[16:37]  * JFo is so handy
[16:37] <JFo> wait a sec...
[16:37] <ogasawara> JFo: you have the git tree cloned locally?
[16:38] <JFo> ogasawara, I do
[16:38] <ogasawara> JFo: git show v2.6.35-rc3
[16:38] <smb> bjf, sconklin Ok, I am finished over there
[16:38] <bjf> smb, just be a sec, getting mumble setup for today
[16:38] <maco> JFo: that rss feed doesnt look like it agrees with you...
[16:38] <JFo> ogasawara, sweet
[16:39] <ogasawara> JFo: wash, rinse, repeat for the others
[16:39] <JFo> ogasawara, :-P
[16:39] <JFo> maco, how so?
[16:39] <maco> JFo: that rss feed is showing rc2&3 on the 11th
[16:39] <maco> (you sound more likely to be right)
[16:40] <JFo> I don't see that
[16:40] <JFo> oh no, that is git6 of RC2
[16:40] <JFo> I looked back for the RC2 release
[16:40] <maco> oh
[16:41] <maco> um ok. im confused. i dont see june 6 anywhere on there
[16:49] <jaminc> alright, this just more and more strange... with the current stable lucid kernel (2.6.32-22-generic) I'm able to start VMs backed by a qcow2 file using libvirt just fine... the same VM with a mainline kernel fails to start via libvirt... however, changing ownership of the qcow2 file to root:root fixes the problem... anyone have ideas as to why?
[16:49] <JFo> mainline:	2.6.35-rc2	2010-06-06
[16:50] <JFo> maco ^ that is from that RSS
[16:51] <JFo> ogasawara, odd that now it still isn't showing up
[16:51]  * JFo tries something
[16:51] <ogasawara> JFo: maybe refreshes hourly or something
[16:52] <JFo> think I figured it out
[16:52] <JFo> one sec
[16:55] <JFo> ah well, I'll look back in on it later 
[17:01] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/2.6.33/linux-image-2.6.32.15_2.6.32.15-2_amd64.deb
[17:06] <ccheney> tgardner, thanks
[17:23] <ogasawara> jjohansen: do you think we'll have the apparmor maverick update before Fri?
[17:24] <jjohansen> ogasawara: yeah sorry, the testing took a little longer than I planned, I am working on the cleaned up rebase for you now
[17:24] <ogasawara> jjohansen: sweet, thanks
[17:27] <tgardner> apw, mumble me when you get around
[17:32] <ccheney> tgardner, 32.15 didn't work either, was that the test to see if it was the packaging issue?
[17:32] <tgardner> ccheney, yep, so I've gotta figure out what the hell I'm doing wrong.
[17:32] <ccheney> tgardner, ok, not sure what is causing it, i haven't seen that kind of error before
[17:34] <ccheney> tgardner, when i remove recordfail i get a little further
[17:34] <ccheney> it says the following:
[17:35] <ccheney> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[17:35] <ccheney> the system uses lvm
[17:36] <tgardner> ccheney, hmm, thats definitely an initramfs issue, or perhaps teh default config doesn't build in the right drivers
[17:36] <ccheney> oh
[17:40] <ccheney> tgardner, http://pastebin.com/6GMaie6T not sure if that is useful for you to see, but it does look normal to me at least like the other grub entries that work
[17:49] <maks_> tgardner: no
[17:49] <maks_> aboves message means that it is a bootloader issue.
[17:49] <maks_> aboves is a linux-2.6 message when it can't mount root.
[17:49] <maks_> this means it never got the initramfs.
[17:49] <tgardner> maks_, well, its still a apackaging issue in the way I was building. I used the internal kpg-deb target
[17:50] <maks_> well i didn't see the kernel commandline
[17:50] <maks_> it may well be that the initramfs wasn't passed at all.
[17:51] <tgardner> maks_, likely, thats why I suggested it was an initramfs issue. its the normal culprit when you can't mount the root FS.
[17:52] <maks_> no that is not an initramfs issue itself :P
[17:52] <maks_> as it wasn't loaded ;)
[17:53] <tgardner> semantics
[17:53] <maks_> ccheney: in http://pastebin.com/6GMaie6T  why do you have toplevel dir entries?
[17:54] <maks_> just use the stuff in /boot/
[17:56] <maks_> hmm don't see a faulty entry although if those symlinks exists
[17:56] <maks_> ccheney: does ls -l /initrd.img-2.6.32.15 really exist?
[17:56] <ccheney> maks_, i didn't modify that, its the way maverick does it
[17:56] <ccheney> maks_, maybe its buggy?
[17:57] <ccheney> all i did to it was run update-grub2 to make sure it was up to date
[17:57] <ccheney> after installing 32.15 for some reason it didn't even appear in the boot list until i did that
[17:57] <maks_> can you please anser the ls
[17:57] <maks_> hmm i might have an outdated grub2 here in Squeeze, but I see /boot/ everywhere.
[17:58] <ccheney> maks_, hmm let me see something
[17:58] <ccheney> it might make sense, looking
[17:59] <ccheney> maks_, yea since i am using lvm / is the non lvm boot dir
[17:59] <ccheney> so that should be sane
[17:59] <ccheney> http://pastebin.com/jm6trFQv
[17:59] <ccheney> http://pastebin.com/a5JpZZVT
[17:59] <ccheney> those are my fdisk -l output and lvscan output
[18:00] <maks_> ls -l  /initrd.img-2.6.32.15 # or you land on fucking ignore
[18:01] <ccheney> there is no  /initrd.img-2.6.32.15 on my root filesystem but that isn't what grub2 is looking at when it boots (or shouldn't be anyway) since it is lvm
[18:01] <ccheney> i can create a link to it but it won't work unless grub2 magically reads lvm volumes now, will verify
[18:02] <ccheney> maks_, and note the other kernels also work fine without any symlink there
[18:03] <maks_> hmm so it sees /boot as /, okay fun never saw that yet.
[18:03] <maks_> and the ls -l /boot//initrd.img-2.6.32.15 exists ?
[18:04] <ccheney> still did not work with the same error as expected
[18:04] <ccheney> yes
[18:05] <ccheney> i also regenerated the 33-rc1 initramfs before tgardner sent me a 32.15 to test with, regenerating it did not help at least for the 33-rc1 kernel he sent me
[18:05] <maks_> what's it's size, compared to the others?
[18:06] <maks_> (have to run so will read later)
[18:06] <tgardner> jjohansen, what else besides 'fdr binary-server AUTOBUILD=1 no_dumpfile=1' ? I'm getting errors when its generating the package, 'dh_installdeb: package linux-image-2.6.32-23-ref-server is not in control info'
[18:06] <ccheney> maks_, much larger from what i recall, iirc he thought it was not stripped
[18:06] <ccheney> system just finished booting, looking now
[18:06] <jjohansen> tgardner: hrmm I don't recall ever seeing that
[18:07] <ccheney> maks_, the two that don't work are over 85MB, and the one that does is 11MB for the initrd
[18:07] <jjohansen> tgardner: what you have looks good to me, I haven't done it for a while, maybe something in the updated build infrastructe?
[18:08] <jjohansen> I have just kicked off a build to see what I get
[18:08]  * ccheney wonders if initramfs/initrd can get too big to work
[18:08] <tgardner> jjohansen, shit, I didn't want to have to _think_ about this.
[18:19] <tgardner> ccheney, how do I replicate what you have for a testbed?
[18:20] <ccheney> tgardner, i installed maverick alpha 1 and then installed your image (i did a few things in between but no package upgrades)
[18:20] <tgardner> ccheney, no, I meant how do I replicate what you're doing with UEC ?
[18:21] <tgardner> isn't that is whats failing?
[18:21] <ccheney> tgardner, oh i see
[18:21] <ccheney> yea, i can email you the script i am running
[18:22] <tgardner> ccheney, I don't know jack shit about UEC, so make it an installation guide for idiots.
[18:22] <ccheney> ok
[18:28] <ccheney> tgardner, ok i wrote it up, if you have any questions let me know
[18:29] <ccheney> tgardner, it should be fairly straight forward, the test doesn't really need any knowledge of UEC beyond getting through the install steps I referenced in the email
[18:29] <ccheney> tgardner, and to see if the issue is happening you grep under /var/log/eucalyptus after running the script for the 'pad block corrupted' message as noted in the bug report
[18:30] <tgardner> ccheney, ack
[18:59] <cking> tgardner, emerald isn't too happy, it's kinda stuck on some builds
[19:00] <tgardner> cking, emerald.mills ?
[19:00] <cking> yep
[19:01] <jjohansen> yeah, for me too
[19:01] <tgardner> oops in dmesg
[19:01] <cking> yep, looks kinda wrong to me
[19:03] <tgardner> cking, jjohansen: I'm installing ogasawara's latest kernel, rebooting in a sec
[19:03] <cking> cool
[19:03] <jjohansen> tgardner: thanks
[19:07] <tgardner> cking, jjohansen: maybe its this: http://launchpadlibrarian.net/50396107/qemu-kvm_0.12.3%2Bnoroms-0ubuntu9_0.12.3%2Bnoroms-0ubuntu9.1.diff.gz
[19:09] <jjohansen> ccheney: ^
[19:11] <tgardner> jjohansen, no, I meant that the mem leak in qemu might be why processes stall on emerald after awhile
[19:12] <cking> seems to happen a lot now we do a load of QEMU assisted builds
[19:12] <jjohansen> tgardner: yeah, I hadn't looked at it yet when I did that and just assumed was for the ccheney conversation, and tab completion had gotten you :)
[19:17] <JFo> pgraner, I find the last comment here disturbing: bug 365739
[19:17] <ubot2> Launchpad bug 365739 in linux (Ubuntu) "Loud cracking sound before suspend to RAM (affects: 1) (heat: 16)" [Undecided,Fix released] https://launchpad.net/bugs/365739
[19:18] <JFo> sorry, wrong bug
[19:18] <JFo> bug 592598
[19:18] <ubot2> Launchpad bug 592598 in linux (Ubuntu) "dell latitude 2110: speakers work; headphones don't work (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/592598
[19:18] <JFo> pgraner, ^^
[19:29]  * tgardner lunches
[19:43] <jjohansen> -> lunch
[19:44] <apw> tgardner, been laid flat by my head ... will try and catch you after your lunch
[19:56] <tgardner> apw, no problem, I've about gotthe local mainline build stuff figured out. I'm gonna add some notes to the README in the giot repo
[20:16] <cking> this day is never gonna end
[20:35]  * ogasawara lunch
[21:11] <tgardner> ccheney, http://kernel.ubuntu.com/~rtg/mainline/v2.6.33-rc1-maverick/
[21:11] <ccheney> tgardner, thanks
[21:13] <tgardner> ccheney, if -rc1 works for you, then watch at http://kernel.ubuntu.com/~rtg/mainline/ for the next one to appear in about an hour
[21:15] <ccheney> it booted mostly ok, some alsa backtrace, testing now
[21:18] <ccheney> tgardner, looks like the problem is there in 33rc1
[21:18] <ccheney> tgardner, i'm seeing some of the errors already, I have it run the test 10 times but it definitely looks like it was in rc1 already
[21:19] <tgardner> ccheney, ok, I'll start bisecting between 2.6.32.15 and 2.6.33-rc1
[21:19] <ccheney> ok
[21:32] <ccheney> tgardner, it finished and failed all 10 tries
[21:33] <tgardner> ccheney, k
[22:04] <bguthro> I have what I'm sure will come across as a stupid question but here goes... I'm used to developing outside of a .deb environment...so I am still getting used to this build system. How can I do an incremental build, without rebuilding the entire tree? I start by doing DEB_BUILD_OPTIONS=parallel=4 AUTOBUILD=1 NOEXTRAS=1 skipabi=true skipmodule=true fakeroot debian/rules binary-generic - but then subsequent executions of that do not seem to build the
[22:04] <bguthro>  tree, only install it...
[22:05] <bguthro> If I'm working on just 1 module - what is the best way to do iterative work?
[22:06] <jjohansen> bguthro: when developing and doing incremental builds, I actually build outside of the .deb env
[22:06] <jjohansen> bguthro: once done with that I will move patches inside the deb
[22:07] <jjohansen> its just faster, and no overhead of packaging up the kernel into .debs etc either
[22:07] <bguthro> jjohansen: so you have the tree, and just do a "make modules", "make install" ?
[22:08] <jjohansen> basically
[22:08] <bguthro> ok, thanks.
[22:08] <jjohansen> you need to make the kernel first and install it
[22:08] <bguthro> clearly
[22:08] <jjohansen> then you can just install the modules to that kernel
[22:08] <bguthro> and a depmod -a...
[22:08] <jjohansen> yeah
[22:08] <bguthro> ok, thanks
[22:09] <jjohansen> the you need update-initramfs, and update-grub
[22:18] <kees> ogasawara: my hangs are i915 related.  yay
[22:18] <ogasawara> kees: yuck
[22:19] <kees> ogasawara: I have to blacklist both i915 and intel_agp.  though that really doesn't help because as soon as udev start on the real root, it loads them anyway and hangs the system.  and if I blacklist them in both initramfs and real root, X still tries to load them.  *stabby*
[22:19] <ogasawara> heh, stabby
[22:22] <ogasawara> kees: you said this started with 2.6.35-rc1?
[22:22] <kees> ogasawara: yup.
[22:35] <apw> bguthro, you can remove the build stamp from the debian/stamps directory then it will only incrementally build
[22:43] <ogasawara> bah, stupid disconnect.  kees, did you see my above msgs?
[22:45] <kees> 21:22 < ogasawara> kees: you said this started with 2.6.35-rc1?
[22:45] <kees> 21:22 < kees> ogasawara: yup.
[22:45] <kees> ogasawara: that's all I saw
[22:45] <ogasawara> [14:40:21] <ogasawara> kees: was browsing through rafael's regression list http://lkml.org/lkml/2010/6/20/143 but I'm not seeing anything noted there similar to what you're seeing
[22:45] <ogasawara> [14:40:34] <ogasawara> kees: ogasawara@emiko:~/linux-2.6$ git log --pretty=oneline v2.6.34..v2.6.35-rc1 -- drivers/gpu/drm/i915 | wc -l
[22:45] <ogasawara> [14:40:34] <ogasawara> 71
[22:45] <ogasawara> [14:40:54] <ogasawara> kees: If I started building bisect kernels, could you test?
[22:45] <kees> ogasawara: yup, totally
[22:53] <ogasawara> kees: amd64?
[22:54] <kees> ogasawara: yuppers
[22:55] <kees> ogasawara: if you show me how to do the bisect while keeping a sane debian/ directory, I can do it :)
[22:55] <ogasawara> kees: was going to sorta try and see if I could just bisect amongst those 71 commits first
[22:56] <ogasawara> kees: I don't think there's a sane way to do that though
[22:56] <ogasawara> kees: using 'git bisect' at least
[22:57] <ogasawara> kees: I wanted to avoid having to bisect all of 2.6.34..2.6.35-rc1
[23:05] <ogasawara> kees: I started doing the following on tangerine . . . git bisect start v2.6.35-rc1 v2.6.34 -- drivers/gpu/drm/i915
[23:05] <ogasawara> kees: I think the debian directory is still ok, but we'll see how long that lasts
[23:07] <ogasawara> nm, it's hosed
[23:18] <ogasawara> kees: http://kernel.ubuntu.com/git?p=ubuntu/kteam-tools.git;a=blob;f=mainline-build/README;h=448b7308f357764e812a607033d717ce7625962f;hb=HEAD
[23:19] <ogasawara> kees: I think I can use those instructions, will let you know
[23:23] <kees> ogasawara: hunh.  okay