[01:57] <lamont> kylem: thanks, btw.  -12.38 built
[01:57] <lamont> (and is blocked by NEW for hppa, but that's OK)
[04:53] <lamont> does LRM live in git?
[04:53] <rtg> lamont: nope.
[04:53] <lamont> ah, ok
[04:53] <lamont> so the archive is the SCM for that?
[04:54] <rtg> yes
[04:54] <lamont> ok
[04:54] <lamont> (hppa)
[04:54] <lamont> 144MB tarball? wow
[04:54] <lamont> competing with OO.o, I see
[04:55] <rtg> It full of those binary blobs.
[04:55] <lamont> yeah
[04:55] <lamont> they'd be much smaller if we compressed them with AAC, you know. :-D
[04:55] <rtg> It would be my preference as well, but BenC disagreed. 
[04:56] <lamont> something to do with wanting to be able to uncompress them later, I suppose.
[04:56] <rtg> I think LRM should be under git control.
[04:56] <lamont> booring.
[04:57] <BenC> we don't recompress them because we leave them as they came from upstream
[04:57] <lamont> BenC: I was being silly and suggesting lossy compression...
[04:57] <BenC> lamont: if you want lossy, just use "rm -f *" :)
[04:58] <lamont> fwiw, at a minimum, I need to change the hppa build-dep on gcc-3.4 to 4.1, and then I'll see what more it needs to compile successfully
[04:58] <rtg> I don't care about compression so much. I just think that all of the kernel packages ought to be managed in a standard way.
[04:58] <lamont> BenC: it would be nice to drop lrm into git..
[04:58] <lamont> largish, but good.
[04:58] <BenC> we had it in git, but it was a real pita
[04:58] <BenC> didn't help us at all
[04:58] <lamont> ah, ok.
[04:58] <lamont> I can see that with the size and the blobitude
[04:59] <BenC> most of our lrm uploads are just ABI bumps, so git just adds too much overhead
[04:59] <lamont> wfm
[05:00] <lamont> lum and lbm both built, as did the kernel, so I think lrm is the only part left that hppa is lacking
[05:00] <lamont> d-i even built
[05:00] <lamont> well, will have in LP once I finish my current pulse and give it back in LP :-)
[05:10] <lamont> BenC: if we packaged lrm as .orig + .diff.gz, that'd help with uploads at least somewhat...
[05:11] <lamont> which is what we did/
[05:11] <lamont> never mind... maybe I should go to bed
[05:32] <lamont> hrm... if hppa ever supports any modules that require compiling things, we're going to have to deal with the multiple-compiler issue in debian/rules.
[05:32] <lamont> in the meantime, it's ok
[05:34] <lamont> BenC: any reason for me to not upload this fix now?
[05:35] <lamont> debian/control* (drop b-d: gcc-3.4) and debian/rules (don't use gcc-3.4)
[05:36] <lamont> W: linux-restricted-modules-2.6.22 source: maintainer-script-lacks-debhelper-token debian/linux-restricted-modules-generic.postinst
[05:36] <lamont> neato
[05:25] <BenC> zul: ping
[05:43] <zul> BenC: you are lucky I just sat down
[05:44] <BenC> zul: The xen configs don't appear to be based on our stock generic config...any reason for that?
[05:45] <BenC> e.g. CONFIG_FW_LOADER=m instead of our CONFIG_FW_LOADER=y
[05:45] <zul> BenC: correct they are based on suse's xen kernels I could go through them today 
[05:46] <BenC> zul: I was thinking the best bet would be "cat debian/config/i386/config{,.generic} > .config" and make oldconfig to get the xen options
[05:46] <BenC> otherwise we risk different support in each kernel
[05:46] <BenC> and the same for amd64
[05:46] <zul> sure not a problem ill have to recompile then to make sure they still work though
[05:47] <BenC> ok, I'd appreciate it
[05:47] <zul> nop
[06:43] <xhaker> BenC, mjg59 : could you please look into this upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=8171
[06:43] <ubotu> bugzilla.kernel.org bug 8171 in ACPICA-Core "acpi_serialize locks system during boot" [Blocking,Assigned]  
[06:43] <xhaker> there is a patch there now! :)
[06:44] <BenC> xhaker: I think we have that patch integrated in the latest kernel upload
[06:45] <BenC> maybe not, I'll check though
[06:45] <BenC> xhaker: is there a launchpad bug for this and confirmed it affects 2.6.22?
[06:45] <xhaker> BenC, 1 sec
[06:46] <xhaker> It's related to this one
[06:46] <xhaker> https://bugs.launchpad.net/linux/+bug/116185
[06:46] <ubotu> Launchpad bug 116185 in linux-source-2.6.22 "battery state not reported correctly" [High,Confirmed]  
[06:46] <mjg59> Yes, that patch looks reasonable
[06:46] <xhaker> and this one upstream
[06:46] <xhaker> http://bugzilla.kernel.org/show_bug.cgi?id=8810
[06:47] <ubotu> bugzilla.kernel.org bug 8810 in ACPICA-Core "Laptop needs acpi_serialize to works - HP Pavillion dv8230us" [Normal,Reopened]  
[06:48] <mjg59> xhaker: So, just to clarify - the first patch just stops acpi_serialize from locking the system?
[06:48] <xhaker> mjg59, yes.
[06:49] <mjg59> Right. That should certainly go in.
[06:49] <xhaker> mjg59, the first bug is about acpi_serialized not working right
[06:49] <xhaker> mjg59, but the second upstream bug report might be a good read along the end
[06:50] <mjg59> xhaker: Yes. It's still lacking a fix.
[06:50] <xhaker> upstream is considering marking _BST always serialized
[06:50] <mjg59> Yes
[06:50] <xhaker> mjg59, you seem to have helped with a recent commit too, let me search it
[06:51] <xhaker> 426ea6c8aadc921e499f490bb457086945b42a0d : Ubuntu: Allocate acpi_devices structure rather than leaving it on the stack.
[06:52] <mjg59> That fixes a bug that I introduced myself
[06:52] <xhaker> mjg59, ohh, i was under the impression it was 8171 related
[06:52] <mjg59> No
[09:48] <nixternal> toshiba satellite l35 w/ gutsy: kernel 2.6.20* works great, 2.6.22* does not work at all. when it gets to the point where it starts X, it just turns the display off and never comes up...any ideas?
[09:49] <mjg59> So if you run gutsy with the feisty kernel, it works?
[09:49] <nixternal> ya
[09:49] <nixternal> thank god you answered :)  I am at a LUG right now and this laptop just will not work at all with the 2.6.22 kernels
[09:49] <mjg59> Can you try blacklisting the video module and see if that makes any difference?
[09:49] <nixternal> I can try that
[09:51] <nixternal> so in /etc/modprobe.d/blacklist, I should add ati since that is what it is loading?
[09:51] <mjg59> No
[09:51] <mjg59> video
[09:51] <nixternal> derr
[09:53] <nixternal> no go
[09:53] <mjg59> Which graphics drivers are you using?
[09:53] <nixternal> ati
[09:53] <mjg59> RIght
[09:54] <mjg59> Try blacklisting radeon, then
[09:54] <nixternal> k
[09:56] <nixternal> still not working...this thing is a pain
[09:57] <mjg59> Are you able to ssh into the machine?
[09:57] <nixternal> it is sitting right next to me, I have physical access to it
[09:57] <mjg59> And the console still works after the failure?
[09:58] <nixternal> I can restart it in single-user mode
[09:58] <mjg59> No, that's not what I asked
[09:58] <nixternal> I can't access anything after the failure
[09:58] <nixternal> I have to push the power button and hard power down
[09:58] <mjg59> Does caps lock still work?
[09:58] <nixternal> it is working at the terminal right now yes
[09:59] <mjg59> After X has failed?
[09:59] <nixternal> after x has failed, the only thing that seems to work is the power button...you can't tell if the caps lock is working or not as there is no indicator for it
[10:00] <mjg59> Ok. So, can you ssh into the machine?
[10:00] <IntuitiveNipple> nixternal: When X fails, can you so Ctrl+Alt+SysRq+K ?
[10:00] <nixternal> hrmm, I need to install the server and give it a shot
[10:00] <IntuitiveNipple> s/so/do/
[10:00] <mjg59> IntuitiveNipple: Please don't confuse things
[10:00] <nixternal> no doubt
[10:00] <nixternal> :)
[10:00] <nixternal> let me install ssh server really quick
[10:01] <mjg59> Thanks
[10:06] <nixternal> alrighty, going to let it boot up and crash, then try and ssh into it
[10:09] <nixternal> mjg59: I can log in via ssh just fine
[10:10] <mjg59> nixternal: When it's frozen?
[10:11] <nixternal> yup
[10:11] <nixternal> so obviously it isn't frozen, just no video
[10:11] <mjg59> Ok. Can you grab /var/log/Xorg.0.log and put it somewhere?
[10:11] <nixternal> yup
[10:11] <mjg59> Right, let me know when you've done that
[10:12] <nixternal> http://www.nixternal.com/tmp/Xorg.0.log
[10:13] <mjg59> Ok, the radeon driver is still getting loaded
[10:13] <mjg59> Try just deleting /lib/modules/`uname -r`/kernel/drivers/char/drm/radeon.ko
[10:16] <nixternal> that is my fault, I remove the blacklist before I rebooted
[10:16] <mjg59> No, I suspect the server is triggering the load itself
[10:19] <nixternal> hey, refresh that log, I just uploaded an updated, while I wait to get root access tot he laptop to delete the module
[10:19] <nixternal> one sec
[10:19] <mjg59> It's the same
[10:20] <nixternal> OK, moved that file out of there, give it a reboot?
[10:20] <mjg59> Yes
[10:20] <nixternal> k
[10:22] <nixternal> holy smokes
[10:22] <nixternal> it booted up
[10:22] <mjg59> Right. Please file a bug against xserver-xorg-video-ati and linux-source-2.6.22
[10:22] <mjg59> There's a bug in either the dri or drm implementation there
[10:23] <nixternal> roger that, I will work on that
[10:23] <mjg59> Include the Xorg.0.log
[10:23] <nixternal> the one on my server right now, or the one that is booted up now?
[10:24] <mjg59> Both would be good
[10:24] <nixternal> before and after...roger that