[03:48] <bjf> pgraner, nevermind, seems to have fixed itself
[08:19]  * apw waves
[08:20] <amitk> hey apw 
[08:20] <apw> morning amitk hows it going?
[08:21] <amitk> fleshing out specs and pushing pending patches upstream
[08:21] <amitk> you?
[08:22]  * smb good mornings the channel
[08:24]  * amitk good mornings smb
[08:24] <smb> hi amitk 
[08:24] <amitk> .. and adds "morning" to webster's dictionary as a verb
[08:26] <cooloney> apw and amitk smb, good morning guys, what's up
[08:26] <smb> cooloney, I am (more or less) :-P
[08:26] <apw> amitk, heheh
[08:27] <apw> smb, moin
[08:27] <apw> cooloney, just fighting aufs2 and the liveCDs
[08:27] <cooloney> smb: do we still have the kernel debug package?
[08:27] <smb> apw, still?
[08:27] <apw> smb, the fighting is now to ensure i've got and tested the right image
[08:27] <smb> cooloney, you mean on ddebs.ubuntu.com?
[08:27] <cooloney> so if we wanna to debug a module, we need a .ko with debug info, right?
[08:27] <apw> i think its fixed
[08:28] <apw> cooloney, symbols are often helpful
[08:28] <smb> The only problem might be I did not upload lately
[08:28] <amitk> apw: will union-mounts happen?
[08:28] <smb> They would be there with the next security update
[08:28] <apw> amitk, too soon to tell, i am waiting on testing of it
[08:28] <apw> smb, i think lucid is the only one missing isn't it?
[08:29] <apw> just due to luck
[08:29] <cooloney> smb: since our kernel package including the module which were --strip-debug, how's the debug kernel package?
[08:29] <smb> apw, Would need to check. I changed another one to the new format
[08:29] <smb> apw, Might have been karmic
[08:29] <smb> cooloney, Its packaged without strip
[08:29] <apw> smb, yeah but last i looked there was .31 ones there
[08:30] <smb> cooloney, http://ddebs.ubuntu.com/pool/main/l/linux/
[08:30] <cooloney> smb: yeah, so that's for debugging. but i never use that before. this question comes from TI guys
[08:30] <smb> cooloney, But if you need Lucid, it will take one or two more days
[08:31] <smb> cooloney, The package basically contains the unstrippeped modules and the full vmlinux
[08:31] <cooloney> smb: thanks a lot. cool, fully understand now
[08:31] <cooloney> smb: if someone wanna debug the modules, he can install this debug kernel package, right?
[08:32] <smb> cooloney, right, if they don't vanish again, which should not be the case, hopefully...
[08:32]  * amitk recovers from hours of reading the "suspend blocker api" thread on LKML
[08:33] <smb> An api to block suspend or one to find them?
[08:35] <amitk> smb: an api to block suspend after enabling "automatic aggressive suspend" (called opportunistic suspend by Google)
[08:35] <cooloney> apw: is there any way to build udebs from a source package?
[08:35] <cooloney> apw: i can use sbuild to get udebs. is there another way?
[08:36] <smb> cooloney, skip_dbg=false
[08:36] <cooloney> i tried 'fdr binary-arch', but no udebs. 
[08:36] <cooloney> smb: skipdbg=false for udebs?
[08:36] <smb> err udebs
[08:36]  * smb clear his glasses
[08:36] <cooloney> smb: i think that is for debug package, right?
[08:36] <smb> cooloney, Yeah, forget what I said
[08:37] <smb> cooloney, I would not thinks so because you need the modules to be build to create packages with the modules referenced
[08:37] <apw> cooloney, ok udebs are currently only enabled if you have /CurrentlyBuilding
[08:38] <cooloney> apw: no idea what's /CurrentlyBuilding
[08:39] <cooloney> apw: a directory which i need to create manually?
[08:39] <smb> cooloney, Its a file
[08:39] <apw> its possible that if you build binary-arch binary-udebs it will do it
[08:39] <apw> but if you make /CurrentlyBuilding in the chroot, it will also build it
[08:40] <smb> cooloney, sudo touch /CurrentlyBuilding in your chroot
[08:40]  * cooloney finds using sbuild to native build my ti-omap4 source package is very fast in tyler.mills
[08:40]  * apw adds _documenting_ and cleaning up the controls for all releases to his TODO
[08:40] <cooloney> just 1 hr
[08:41] <apw> cooloney, that sounds acceptable to me
[08:42] <cooloney> smb and apw, yeah, does that work for cross compiling?
[08:42] <cooloney> 'fdr binary-arch binary-udebs' works for cross compiling? 
[08:44] <apw> the problem is if linux-tools is enabled it does not work
[08:44] <apw> so yuo'll need do_tools=false at least to cross compile i think
[08:44] <cooloney> apw, ok, no problem, i will try that.
[09:09] <apw> cking, hey ... when filing bugs on iso testing, is there any special magic for that?
[09:09] <apw> ie. how do identify the bugs so they can be found
[09:13] <cking> apw, there is a field in the bug tracker as per test case to enter the bug number - this is all I do
[09:13] <apw> cking, ok thanks
[09:14] <cking> but there may be some tags that I don't know about
[09:15] <cking> All the notes say is: "Please report any bugs you identify in Launchpad and report on the success or failure of the test in the tracker: https://launchpad.net/ubuntu/"
[09:15] <cking> apw, you biting the QA bullet - cool!
[09:15] <apw> cking, dipping a toe in the pool
[09:16] <cking> see how many bugs you can find - I aim for 4 each spin - usually it ends up as stupid ones (e.g. broken eye candy) 
[09:20] <ericm_> apw, I've added the link bjf mentioned in the reply to https://wiki.ubuntu.com/KernelTeam/MeetingHowTo for easier reference, hope that's OK
[09:21] <apw> ericm_, ok
[09:22]  * cking goes to get some H/W from the loft - back in 5
[09:50] <cooloney> apw: just a quick feedback, 'fdr binary-arch binary-udebs' works fine with cross compile
[09:50] <cooloney> it will give us all the udebs as well as kernel image and header packages in parent dir
[09:52] <dupondje> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588643 => if somebody feels checking :)
[09:52] <ubot2> Launchpad bug 588643 in linux (Ubuntu) "Lockup with stacktrace (native_smp_send_reschedule) (affects: 1) (heat: 6)" [Undecided,New]
[09:59] <apw> cooloney, good
[11:42] <dupondje> Some small queryion, could bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588643 be caused by an error in BIOS ?
[11:42] <ubot2> Launchpad bug 588643 in linux (Ubuntu) "Lockup with stacktrace (native_smp_send_reschedule) (affects: 1) (heat: 8)" [Undecided,New]
[11:55]  * apw returns 
[11:56] <kraut> moin
[13:05] <ogra> hmm
[13:06] <ogra> looking at https://edge.launchpad.net/ubuntu/+source/linux/2.6.34-5.13/+build/1768097 we dont seem to build any omap udebs at all anymore
[13:13] <apw> ogra, it seems unlikely we ever did
[13:13] <ogra> we did with the topic branch in lucid
[13:14] <ogra> (and we need them for netinst images)
[13:14] <ogra> there seem to also be issues with the DSS code on a beagle XM
[13:14] <apw> ogra, yep but omap in maverick is a complete rebuild
[13:14] <ogra> i know
[13:14] <apw> ogra, its a shame noone ever tests things when they go in, only the day before the milest
[13:15] <ogra> i'm just examining the omap3 kernel now and note down issues i find :)
[13:15] <ogra> i dont test because A1 is due :)
[13:15] <ogra> we dont build A1 images for arm
[13:15] <ogra> its just coincidence :)
[13:16] <ogra> apw, btw, would there be a chance to not have the kernel produce an oops if it doesnt find its rootfs device and instead have it spit out a userfriendly error msg ?
[13:17] <ogra> http://paste.ubuntu.com/443294/ is what i typically get if there is no rootfs device 
[13:17] <apw> ogra, i thought it dropped to busybox
[13:17] <ogra> not if you dont have an initramfs
[13:18] <ogra> see the bottom of the paste
[13:18] <apw> then its meant to tell you which things you have
[13:18] <ogra> i seem to remember (from my pre ubuntu times) that it properly panicked and gave a useful error 
[13:18] <apw> ogra, given that shows the card appearing the instant before it explodes i suspect this is not cause it doesn't find root
[13:19] <ogra> i'm only using initramfs since ubuntu :)
[13:19] <apw> when my root is missing i see a panic which ends with a list of the filesystems and devices available
[13:19] <ogra> weird
[13:19] <ogra> i get the panic since i use arm 
[13:19] <ogra> actually i got used to have it but thinking about it i remember it was not always that way
[13:20] <apw> from the panic i'd say that a timer is firing to flash the cursor, but the framebuffer didn't initialise
[13:20] <ogra> yes, there are definately other issues with that kernel on the XM board i'm justy trying
[13:20] <apw> [    2.365386] Waiting for root device /dev/mmcblk0p2...
[13:20] <apw> [    2.385223] mmc0: new SD card at address aff7
[13:20] <apw> [    2.390167] mmcblk0: mmc0:aff7 SU02G 1.89 GiB 
[13:20] <apw> [    2.395141]  mmcblk0: p1 p2
[13:20] <ogra> but i see the oops across all arm arches
[13:21] <apw> from that you can even see that the disk was appearing, so its not at all clear its anything to do with root at all
[13:21] <ogra> i also saw it on imx51 before or on dove when experimenting with SDs without rootfs and initrd
[13:21] <apw> notice it dies here:
[13:21] <apw> [    2.490692] LR is at cursor_timer_handler+0x34/0x38
[13:21] <apw> that sounds very suspicious
[13:22] <ogra> hmm
[13:26]  * ogra unpacks a rootfs to the SD 
[13:29] <apw> ogra, that callback seems to be the cursor flasher ... every half second
[13:30] <apw> i think there is a bug in the omap fb which is leaving the cursor running when it fails to init
[13:31] <ogra> yeah, you are right, i even get the oops with a valid rootfs in place
[13:31] <ogra> the DSS/frambuffer code is a mess on omap i guess we will need a bunch of patches from the linux-omap tree to make it work
[13:32]  * apw can't hear you :)
[13:32] <ogra> (it doesnt work at all on the touchbook or zoom2)
[13:32] <apw> i am somewhat intriqued who tested the image and what on, cause it was tested
[13:32] <ogra> and apparently also on the beagle XM
[13:32] <apw> i suspect just an official beagle is the only one supported
[13:32] <ogra> it likely works on one of the older beagles
[13:32] <ogra> XM is official
[13:33] <ogra> zoom2 is official too but will need patches
[13:33] <ogra> we agreed to support all these devices 
[13:33] <apw> XM will be official at release, i am sure up to now we've not even had one
[13:33] <ogra> AI touchbook would be a nice to have since its an actual ARM netbook out there
[13:33] <ogra> apw, we have two in the company since about two months :)
[13:33] <apw> ogra, and who has them ?
[13:34] <apw> i bet noone who is doing the kernel work
[13:34] <ogra> amitk had one for kernel, not sure where it went
[13:34] <ogra> i have one as well
[13:34] <ogra> and i think there were even more
[13:34] <ogra> plars and jamiebennet used to have one each iirc but i'm not 100% sure
[13:35] <ogra> i am sure about the ones amitk and i have though
[13:35] <apw> shame that its eric doing the kernel work... ho hum
[13:35] <ogra> heh
[13:35] <ogra> erm, you mean bryan
[13:35] <apw> possibly, the disconnect is the same
[13:35] <ogra> he is doing omap4 atm 
[13:36] <ogra> and he is doing it awesome :) without having HW at all i got a fully working kernel for my blaze board :)
[13:36] <apw> then i suspect noone is doing it
[13:36] <apw> ho hum
[13:36] <ogra> i know mpoirier and lag are supposed to do omap 
[13:36] <ogra> under leadership of cooloney and amitk 
[13:37] <ogra> but cooloney is busy with omap4 for the special 10.07 release
[13:39] <amitk> apw: ogra: The HW situation should improve soon(ish). We should probably revisit our HW allocations and get unused boards into hands of people that need them
[13:39] <ogra> yeah
[13:42] <dupondje> Now that there is some action here, could somebody tell me if http://dupondje.be/DSCF1025.JPG can be caused by a broken BIOS?
[13:46] <apw> dupondje, hard to say as thats not the first panic
[13:47] <cking> dupondje, if you could capture more of the first panic then we could say for certain - the trace before the apic timer interrupt would be handy
[13:48] <apw> dupondje, the panic you do have implies a CPU is offline when we are not expecting it to be so, if its repeating then we are truly confused
[13:48] <dupondje> I need full hd tv :P
[13:49] <dupondje> used mainline kernel, and there it gives 'BUG: cpu soft lockup' ... :s
[13:49] <dupondje> 2.6.34 as mainline kernel btw
[13:52] <apw> Keybuk, hey ... did you get to do any testing on the init args kernels ??
[13:53] <dupondje> to bad its not possible to scroll when the stacktrace is displayed 
[14:00] <Keybuk> apw: not yet
[14:01] <Keybuk> apw: I will be doing that today
[14:11] <Keybuk> apw: while I can see items vanishing off my todo list, I feel like I'm not accomplishing much at the moment
[14:11] <Keybuk> too much catch-up
[14:17] <lag> http://webcache.googleusercontent.com/search?q=cache:EGSLAZNT6VwJ:www.pubbs.net/kernel/200907/83651/+"no+console+suspend"&cd=1&hl=en&ct=clnk&gl=uk
[14:17] <apw> kernel/printk.c:__setup("no_console_suspend", console_suspend_disable);
[14:18] <apw> Keybuk, i can only sympathise.  i had 5 items on mine, i've done 4 of them, but still have 6 to do for alpha-1 ... go figure
[14:32] <apw> Keybuk, do you  know if you need special mount support for union-mounts ?
[14:35] <Keybuk> yes
[14:36] <apw> Keybuk, damn, i'll go look for those then
[14:36] <Keybuk> I have that ready
[14:37] <apw> Keybuk, ahh, if you have something i can slurp up i'll get it into the PPA as well
[14:37] <apw> Keybuk, then i can go do some testing myself
[14:40] <apw> Keybuk, actually it looks to be only two patches if i am reading Valerie's page correctly ... match your expectations?
[14:44] <Keybuk> that would require me getting some time to actually sort the package out
[14:49] <lag> BOOT_IMAGE=<blar> root=<blar> ro console=tty1 no_console_suspend quiet splash
[14:50] <cking> lag,  it looks ok to me
[14:50] <cking> remove quiet and splash too
[14:52] <cking> mumble fail
[14:53] <lag> It sounded like you were on a CB radio and you were transmitting via a piece of string prior to dampening 
[14:54] <cking> lag, my audio is screwy after a suspend/resume cycle - dunno why
[14:56] <cking> lag, console=tty is the normal default.
[14:56] <ogra> cking, talk to a kernel dev 
[14:56] <ogra> :)
[14:56] <cking> "physician, heal thyself"
[15:00] <JFo> "Hoist by me own petard."
[15:02] <lag> JFo: Are you a fan of the great WS?
[15:03] <JFo> I am
[15:04] <lag> "Man does not live by bread alone"
[15:07] <bjf> moin yall
[15:07] <cking> hi bjf
[15:22] <JFo> moin bjf
[15:22] <JFo> from bug 571378
[15:22] <JFo> Jun 1 16:42:23 warthog libvirtd: 16:42:23.833: error : udevStrToLong_ui:73 : Failed to convert '008' to unsigned int#012
[15:22] <ubot2> Launchpad bug 571378 in linux (Ubuntu) "C-Media USB Headphone fails to enummerate (affects: 2) (heat: 10)" [Medium,Triaged] https://launchpad.net/bugs/571378
[15:22] <JFo> looks like some udev failure?
[15:23] <apw> JFo, well that has libvirtd in it as well
[15:23] <JFo> ah yes
[15:23] <apw> i'd tend to blame that first, and let them blame udev :)
[15:23] <JFo> heh
[15:24] <JFo> who owns that bit?
[15:24] <bjf> JFo, moin, since we have maverick daily isos now, i'll work on producing daily maverick test isos (shouldn't take more than a minute or two)
[15:24] <JFo> or rather those bits
[15:24] <JFo> bjf awesome
[15:30] <bjf> anyone know if emerald.pgraner is among the living?
[15:35]  * cking notes that suspend/resume on maverick alpha 1 is very speedy on his old dell 6400
[15:38] <Keybuk> apw: updating my laptop so I can install your test kernels
[15:39] <JFo> is the Lucid bacport kernel going to be based on .34 or .35? I was thinking the latter.
[15:39] <apw> Keybuk, i've run maverick kerenels on lucid no bother
[15:40] <Keybuk> apw: laptop is at a broken mid-maverick point ;)
[15:40] <Keybuk> updating to get it to boot again
[15:41] <apw> Keybuk, ooosp :)
[15:42] <apw> Keybuk, the 'text only' plymouth like screen (with four dots) is that part of plymouth as a package |?
[15:42] <Keybuk> plymouth-theme-ubuntu-text iirc
[15:46] <pgraner> bjf: I'm working on it
[15:46] <pgraner> bjf: had to bandage a cut finger
[15:47]  * ogasawara bails to dentist apt, back in an hour
[15:47] <tgardner> JFo, the LTS backport kernel is tracking Maverick
[15:48] <JFo> thought so
[15:49] <manjo> smb, https://wiki.ubuntu.com/Kernel/Tagging
[15:52] <jmfthevci> Hi all, anyone know the reasons behind the move of autoconf.h and utsrelease from the /usr/src/linux-headers-2.6.34-5-generic/include/linux directory?
[15:52] <cking> manjo, box is on it's way - probably get to you by Friday
[15:52] <jmfthevci> It caused VMware's tools script to die - vmware-config.pl
[15:52] <jmfthevci> Took a bit of digging but found this: https://blueprints.launchpad.net/ubuntu/+spec/kernel-maverick-misc
[15:53] <jmfthevci> Any comments?
[15:58] <sconklin> hi folks, I'm bck from the conference and should be in the normal swing again
[16:05] <JFo> woo hoo! welcome back sconklin 
[16:06] <cking> lag: +CONFIG_USB_SERIAL=y
[16:06] <cking>  +CONFIG_USB_SERIAL_CONSOLE=y
[16:06] <cking> CONFIG_USB_SERIAL_CH341=y
[16:06] <cking> CONFIG_USB_SERIAL_PL2303=y
[16:07] <lag> I'm going to do it via the menu system
[16:07]  * lag is looking
[16:07] <cking> lag, I added them to debian.master/config/config.common.ubuntu
[16:10] <lag> cking: Why CH341? Surely you mean CONFIG_USB_SERIAL_FTDI_SIO?
[16:10] <cking> lag, you need to chose the appropriate driver ;-)
[16:11] <lag> I thought there were only two in the UK?
[16:11] <lag> FTDI and PLxxxx
[16:13] <cking> lag, well, what ever is appropriate - I've got CH341 and PL2303 for some reason 
[16:13] <bjf> JFo, something is busted building the maverick test isos (was working fine for lucid), am debugging 
[16:15] <JFo> k
[16:24] <manjo> cking, thanks for the box
[16:25] <cking> manjo, it requires a US power lead - it did not come with one
[16:25] <manjo> cking, I can get that
[16:25] <cking> and I formatted it up to boot Karmic, so you can see it will work ;-)
[16:26] <manjo> apw, you worked on some of the fan cntrl stuff, are we missing any modules for the sensors? (lucid/maverick) ?
[16:27] <manjo> apw, what sensor modules need to be loaded ? 
[16:27] <manjo> apw, when I run pwmconfig it says at the end /usr/sbin/pwmconfig: No sensors found! (modprobe sensor modules?)
[16:29] <manjo> apw, sensors-detect tell me what modules .. never mind 
[16:30] <apw> manjo, yep sensors-detect ... but even then sometimes there are none still
[16:37] <dupondje> JFo: thanks for commenting my bug, by the latest upsteam kernel ? you mean the latest daily build on kernel.ubuntu.com? Or compile a fresh one from kernel.org ?
[16:38] <JFo> dupondje, there is a MainlineKernels page on the wiki
[16:38] <JFo> we build them so you don't have to :)
[16:38]  * JFo goes to find the link
[16:38] <dupondje> well i'll try it when i'm home :)
[16:39] <manjo> tgardner, https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/475641
[16:39] <ubot2> Launchpad bug 475641 in linux (Ubuntu) "pwmconfig does not work after upgrade to 9.10 on TYAN server (affects: 2) (heat: 12)" [Medium,Triaged]
[16:39] <dupondje> 2.6.34 gave 'BUG: soft lockup ...' :)
[16:39] <dupondje> didn't try 2.6.35 yet
[16:39] <JFo> hmmm
[16:40] <JFo> dupondje, here is the link to all the info: https://wiki.ubuntu.com/KernelTeam/MainlineBuilds?action=show&redirect=KernelMainlineBuilds
[16:40] <JFo> let me know how it goes :)
[16:41] <dupondje> i'll do, and take some 'screenshots' ;)
[16:45] <JFo> cool
[16:48] <dupondje> its not possible to scroll up right ? cause if the error is to long, can't see everything then :s
[16:54] <apw> dupondje, right no up scrolly
[16:55] <dupondje> gotto ask full hd tv then :)
[17:14] <lag> cking: Are you around?
[17:18] <cking> yep
[17:20] <lag> read 2675 modules : new(121)  missing(3)
[17:20] <lag> EE: Missing modules (start begging for mercy)
[17:20] <lag> make: *** [module-check-generic] Error 1
[17:21] <cking> lag, gimme 5 - I've got to sort out the gas men again
[17:21] <lag> k
[17:23] <cking> lag, build with skipmodule=true I believe
[17:29] <cking> lag, fakeroot debian/rules .... skipmodule=true
[17:32] <lag> cking: Trying
[17:32] <lag> :)
[17:33] <cking> yet another rune to remember
[17:33] <lag> :(
[17:34] <lag> I already skip the abi test
[17:34] <lag> Why doesn't it allow you to have any built-ins?
[17:35] <cking> eh? skipmodule=true should work
[17:37] <cking> see line 104 of debian/scripts/module-check - this is where it skips the missing modules check
[17:39] <lag> I mean, why doesn't it allow built-ins by default
[17:39] <jpds> Would anyone know why kdump wouldn't be working on a HP Z600 workstation?
[17:39] <jpds> Or how to go about debugging why it isn't working?
[17:39] <cking> lag, oh, I see. dunno
[17:52] <akgraner> bjf, are you around
[17:52] <bjf> akgraner, present
[17:53] <akgraner> can you take a look at the the Kernel Team Meetings listed on the Fridge and let me know if the series is correct
[17:53] <akgraner> if it is not can you let me know so I can get it fixed immediately :-)
[17:54] <bjf> akgraner, is it on the front page?
[17:55] <bjf> akgraner, give me a URL to what you want me to look at
[17:56]  * manjo needs food.. goes to look in the kitchen
[18:00] <akgraner> bjf, oh sorry let me get you the link
[18:00] <akgraner> bjf, http://fridge.ubuntu.com/calendar
[18:02] <bjf> akgraner, and from the calendar I do what? the calendar looks fine :-)
[18:02] <akgraner> bjf, nothing if all the times are correct
[18:03] <bjf> akgraner, 1700 UTC is the correct time, so that looks good to me
[18:03] <manjo> apw, smb is balcony open ?
[18:03] <smb> manjo, only if you have beer
[18:04] <akgraner> ok noted that Tuesday -1700 UTC is the time for all Kernel Team Meetings unless I am told otherwise - thanks!
[18:04] <bjf> akgraner, np
[18:04]  * bjf will brb
[18:41] <apw> mpoirier_, just to say i am still working on the omap udebs, its being truculant
[18:42] <mpoirier_> apw: truculant is definitely a new word for me :)
[18:42] <apw> and likely spelt wrong by me of course
[18:43] <mpoirier_> no, i just looked it up - it is correct.
[18:44] <apw> mad as it looks awful spelt that way
[18:44] <apw> anyhow its being truculant, but i think i've nearly got it licked
[18:45] <mpoirier_> fabulous.
[18:45] <mpoirier_> in the mean time sbuild worked for me.
[18:45] <mpoirier_> I can finally move on.
[18:45] <mpoirier_> thanks for the tips.
[18:46] <apw> mpoirier_, awsome
[18:46] <mpoirier_> it took a bloody long time, even on tyler.mills.
[18:47] <apw> Keybuk, hey ... how did your testing go ?
[18:47] <apw> mpoirier_, arround an hour ?
[18:47] <mpoirier_> is there a way to disable all the udebs except the one you are interesed  in ?
[18:47] <mpoirier_> no, more than that.  I'll 'time' it next time.
[18:48] <apw> if you are considering that to make things faster you won't gain anything, as the whole kernel being built is a pre-requisite to generate any udebs
[18:48] <apw> mpoirier_, once i have this lot fixed I should be able to cross compile only one flavour and generate udebs for it
[18:48] <apw> which for me here takes about 20 mins
[18:48] <mpoirier_> ok, it will be even faster on tyler.
[18:49] <mpoirier_> it's worth the wait.
[18:50] <apw> if i haven't killed it by then
[18:51] <Keybuk> apw: it hasn't happened yet
[18:52] <Keybuk> apw: your initargs kernel didn't build, so there's no deb to try
[18:53] <apw> Keybuk, crap will sort that out
[18:54] <Keybuk> did the "was used" patches end up in the maverick kernel?
[18:54] <apw> Keybuk, nope not yet
[18:54]  * apw adds to todo
[18:55] <Keybuk> k, if you want to go via ppa first, that's fine :)
[18:55] <apw> yeah sounds like a plan
[19:14] <JFo> kro, off to grab a bit of lunch
[19:14] <JFo> err ok
[19:31] <jjohansen-afk> -> lunch
[20:15] <apw> ogasawara, you abuot ?
[20:15] <ogasawara> apw: yep
[20:15] <apw> yo ... are you doing the -rc1 rebase 'next' ?
[20:15] <apw> as i am reminded it will need an aufs update before it will build right
[20:15] <ogasawara> apw: was just starting
[20:15] <apw> so as soon as you have the base rebase, perhaps you can push it somewhere i can get to it
[20:15] <ogasawara> apw: just squashing debian commits as we speak
[20:16] <ogasawara> apw: ack
[20:16] <apw> and i'll do the update for aufs in the morning on top
[20:16] <apw> wicked :)
[20:50] <JFo> ogasawara, bug 587444 looks interesting
[20:50] <ubot2> Launchpad bug 587444 in linux (Ubuntu) "Wrong dependency in linux-headers-2.6.34-x-generic (affects: 4) (heat: 20)" [High,Triaged] https://launchpad.net/bugs/587444
[20:50] <ogasawara> JFo: will take a look in a sec
[20:50] <JFo> kro, np
[20:50] <JFo> sigh*
[20:51] <ogasawara> JFo: ah, that seems one for tgardner as it's the maverick lts backports
[20:51] <JFo> ah right you are
[20:52] <tgardner> I can live with that
[20:52] <JFo> sorry to interrupt you :)
[20:52] <tgardner> JFo, wtf is that marked high? its not even a released package
[20:52] <JFo> heh
[20:53] <JFo> I apparently hit the wrong one
[20:53] <JFo> meant for medium
[20:53] <JFo> second time I have done that today
[20:53] <JFo> first one I caught as it happened
[20:53] <tgardner> JFo, nominate for Lucid and assign me so I don't forget
[20:54] <JFo> kro, will do
[20:54] <JFo> why does that keep happening
[20:54] <JFo> ah, it is tab completing
[20:55] <JFo> yep, automatic nick completion was checked
[20:55] <JFo> sorry about that kro 
[20:58] <JFo> tgardner, done
[21:02] <JFo> cnd, looks like you could get a nice chunk of change to resolve bug 576601
[21:02] <ubot2> Launchpad bug 576601 in linux (Ubuntu) (and 1 other project) "[MacBookPro 7,1]mcp89 sata link reset fails, no disks detected (affects: 79) (heat: 462)" [High,Triaged] https://launchpad.net/bugs/576601
[21:02] <JFo> http://www.cofundos.org/project.php?id=187
[21:04] <cnd> JFo: heh, upstream looks like they're getting involved
[21:05] <JFo> cool
[21:09] <dupondje> JFo: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588643 => was able to get a dmesg output when it got locked
[21:09] <ubot2> Launchpad bug 588643 in linux (Ubuntu) "Lockup with stacktrace (native_smp_send_reschedule) (affects: 1) (heat: 8)" [Undecided,Incomplete]
[21:09] <JFo> excellent!
[21:12] <dupondje> need to mark the bug as New again ? or you change status ? :)
[21:14] <smoser> hey all.
[21:14] <smoser> lets just pretend that i had a hardy xen domU running 2.6.24-24-xen
[21:14] <smoser> what would be the most reasonable way to get ext4 filesystem support for that pretend guest
[21:19] <JFo> dupondje, I have changed it
[21:20] <JFo> I was reading over the bug
[21:21] <dupondje> any idea what could be causing it ? could it be an instable BIOS version ?
[21:23] <tgardner> smoser, I don't think you can. ext4 did not exist for 2.6.24 IIRC
[21:23] <smoser> well, it does exist. its there.
[21:23] <smoser> at least ./Documentation/filesystems/ext4.txt
[21:23] <smoser> its just likely old and buggy
[21:24] <tgardner> smoser, its was probably a preview and marked EXPERIMENTAL
[21:24] <smoser> yes
[21:28] <dupondje> JFo: also notice the segfaults, seems like some apps segfault randomly also :s
[21:30] <JFo> dupondje, not sure what could be causing it. odd that some apps are segfaulting randomly
[21:31] <dupondje> its totally random also 
[21:35] <dupondje> happens since I changed CPU and did BIOS upgrade ... but before it was a single core, now quad .. so
[21:37] <jjohansen> smoser: define support?  You could build the module externally, but no one will provide any kind of support for ext4 on 2.6.24
[21:37] <smoser> i need it to work.
[21:38] <smoser> i'm guessing reasonable ext4 support is not backported that far back.
[21:38] <smoser> the driver in 2.6.24 will probably compile and maybe even work.
[21:39] <smoser> right now our UEC images build system is running the aforementioned kernel version, and I want to build images with an ext4 filesystem, which requires mounting said filesystem.
[21:39] <jjohansen> I don't think reasonable ext4 support for 2.6.24 is viable
[21:39] <jjohansen> you should be able to compile the fs and have it mostly work
[21:39] <jjohansen> there will be bugs (ext4 still has bugs)
[21:40] <manjo> smoser, make sure you have latest bug fixes for ext4, lucid kernel is missing those too, Bug #588069 
[21:40] <ubot2> Launchpad bug 588069 in linux (Ubuntu) "Lucid kernel is missing a large number of important ext4 bug fixes (affects: 4) (heat: 24)" [High,Triaged] https://launchpad.net/bugs/588069
[21:41] <jjohansen> manjo: I doubt those will even come close to applying to .24 era ext4
[21:42] <manjo> jjohansen, I assumed smoser was going to backport... never mind then
[21:45] <smoser> manjo, i was assuming you had volunteered to backport for me
[21:45]  * manjo ducks and hides
[21:47] <smoser> make sure that you get those latest patches :)
[21:47] <smoser> thanks all, i got somewhat what i expected.
[22:01] <kamal> mjg59: Hi -- A few weeks ago you proposed overriding the often-busted ACPI brightness control with an i915 opregion-based method -- I have implemented such a scheme -- are you available to talk about it?
[22:30] <stenten> Can someone help me finish triaging Bug #587136?
[22:30] <ubot2> Launchpad bug 587136 in linux (Ubuntu) "2nd Resume from Suspend results in reboot on Toshiba Satellite U400. Fixed in 2.6.34 Mainline. (affects: 2) (dups: 1) (heat: 22)" [High,Confirmed] https://launchpad.net/bugs/587136
[22:31] <stenten> Since it's a suspend/resume bug, there's absolutely no debugging information in the logs, and I'm at a loss of what else to ask for. What should the Status be in that case?
[22:31]  * JFo looks
[22:33] <mjg59> kamal: For a few minutes, sue
[22:33] <kamal> mjg59: For review:  http://kernel.ubuntu.com/~kamal/i915bri~3e/
[22:33] <kamal> It works very well on two out of three laptops I've tested, but on the third laptop the i915 method silently fails (its a "GM45" card -- pci-id 0x2a42 ... IS_I915G() and IS_GM45() are true).
[22:33] <kamal> Perhaps you might have a look at the patch and/or scratch your head about why it doesn't work on that GM45?
[22:33] <JFo> stenten, he is on server?
[22:33] <JFo> may not be easy to test, but the mainline kernel testing would be nice
[22:34] <JFo> if he is willing and this isn't production
[22:34] <JFo> other than that, it looks almost ready
[22:34] <stenten> He's on a Toshiba laptop.
[22:34] <kamal> mjg59: fyi, same patch in a git tree:  http://kernel.ubuntu.com/git?p=kamal/ubuntu-lucid.git;a=shortlog;h=refs/heads/i915bri-3e
[22:34] <JFo> hmm
[22:34] <stenten> And he's already tested with the 2.6.34 mainline, and the problem is resolved.
[22:35] <JFo> stenten, all that is left is proper tagging fos subsystem
[22:35] <JFo> have you seen https://wiki.ubuntu.com/Kernel/Tagging ?
[22:35] <JFo> for the subsystem tags?
[22:36] <stenten> We got all the way to the RTC overwrite part in debugging, but he has questions in Comment #10 that I'm really not qualified to answer.
[22:36] <JFo> cool
[22:37] <mjg59> kamal: Mm. Could be that the gm45 case is broken somehow.
[22:37] <JFo> stenten, so this one needs the kernel-power tag and the kernel-needs-review tag
[22:37] <mjg59> kamal: That's broadly what I was thinking though, sure
[22:37] <JFo> stenten, then it will be all set
[22:37] <stenten> JFo: Just saw that today (in your email actually). Tag it as 'kernel-power' and mark as Triaged?
[22:37] <JFo> yep
[22:37] <mjg59> kamal: I think it's worth posting this upstream, if only to try to find out if anyone's got a better idea
[22:38] <JFo> don't forget the kernel-needs-review tag
[22:38] <JFo> that way it gets on the radar from monday
[22:38] <JFo> stenten, ^
[22:38] <stenten> Is 'kernel-needs-review' the part that tells you it needs a dev to look at it?
[22:38] <JFo> well, it is the bit that gets it reviewed for inclusion on the 'hot list'
[22:38] <JFo> :)
[22:38] <kamal> mjg59: ok, if you consider it decent enough to sign off on it (or ack, or whatever), I'll post it upstream (with a note that its known to fail on this gm45.
[22:38] <stenten> Is there any difference between the meaning of 'kernel-needs'review' and marking it as triaged?
[22:39] <JFo> yep
[22:39] <mjg59> kamal: I think post it to linux-acpi and intel-gfx as an RFC for the moment
[22:39] <mjg59> And we'll bounce some ideas around
[22:39] <mjg59> But I suspect that this is probably how it's going to be
[22:39] <JFo> stenten, triaged simply means it has everything needed to go to a dev, not that it will necessarily get to one
[22:39] <JFo> given the amount of bugs we have that is
[22:39] <kamal> mjg59: ah, got it, ok, I'll do that -- thanks much!
[22:41] <JFo> stenten, are there any particular subsystems of the kernel that interest you?
[22:41] <JFo> sound, graphics, etc.?
[22:42] <stenten> JFo: Not particularly. I'm working in xserver-xorg-video-intel with Geir Ove Myhr, and we get a lot of suspend/resume bugs that end up being reassigned to the kernel, so I like to followup on them.
[22:42] <JFo> good deal
[22:45] <stenten> JFo: Do you mind changing the Status on that bug to Triaged? I'm only a lowly Bug Squad member :)
[22:46] <JFo> I don't mind at all :)
[22:46] <JFo> done
[22:46] <stenten> Thanks kindly.
[22:46] <JFo> my pleasure
[23:08] <kro> JFo: :-)
[23:08] <JFo> :-)
[23:08] <JFo> been using your name in vain all day
[23:10] <kro> hehe, I noticed