[06:43] <pwnguin> so how does one use the kernel in the topic?
[10:23] <tepsipakki> kylem: the new kernel in dapper-proposed works fine with the new tg3 that we have tested, thanks!
[10:24] <kylem> excellent. i'm glad to hear that.
[10:25] <tepsipakki> only problem is that I can't install the machine all the way using that kernel, since d-i doesn't know how to fetch stuff from both dapper and dapper-proposed :)
[10:25] <tepsipakki> but, waiting for the official version
[10:26] <kylem> you should be able to chroot into the install target and install the kernel from apt just after installing bootloader and just before rebooting.
[10:26] <fabbione> hem
[10:26] <fabbione> the installer is NOT supposed to fetch from -proposed
[10:26] <fabbione> but it does fetch from -updates once the fix is propagated
[10:27] <tepsipakki> fabbione: exactly, but the kernel-udebs are there
[10:27] <fabbione> they are only in the pool
[10:27] <fabbione> but not in the Packages files
[10:27] <fabbione> (for dapper and -updateS)
[10:27] <tepsipakki> it does, however, manage to get network up, which is the point
[10:27] <tepsipakki> fabbione: ah!
[10:27] <kylem> i don't think new kernels should go into -updates without extensive *extensive* testing.
[10:30] <kylem> or possibly ever, i'm not really sure what we're going to do with them. the idea seems to be using -proposed to vet patches for merging, not to propogate.
[10:31] <tepsipakki> kylem: that's cool, tg3 is fine for merging :)
[10:32] <tepsipakki> fabbione: if the udebs are not in Packages, how did I manage to build d-i with -proposed?
[10:33] <tepsipakki> or does it matter
[10:33] <fabbione> tepsipakki: you can build it manually if you have -proposed in your sources.list
[10:33] <fabbione> but it won't fetch udebs from proposed at install time IIRC
[10:34] <tepsipakki> yep, ok
[10:35] <kylem> tepsipakki, what was the bug # for that? have you posted the results to the bug?
[10:35] <tepsipakki> kylem: not yet. let me find it
[10:35] <kylem> ok, thanks.
[10:36] <tepsipakki> https://launchpad.net/bugs/72696
[11:48] <kylem> BenC, http://acpi.sourceforge.net/documentation/processor.html for the description between acpi P/C/T states.
[11:54] <BenC> kylem: thanks
[11:54] <mjg59> http://madwifi.org/browser/branches/dadwifi-openhal - win
[11:55] <mjg59> kylem: You've got an Atheros, right? Fancy giving that a go?
[11:56] <kylem> it's back in ottawa and only in minipci form, i'd need to take apart the laptop.
[11:56] <kylem> i have the new atheros in my macbook though.
[11:56] <mjg59> Yeah
[11:57] <BenC> mjg59: sweet
[11:57] <mjg59> That's what I was thinking of
[11:57] <kylem> ok.
[11:57] <kylem> that's hot.
[11:57] <mjg59> I've got an Atheros somewhere here that wasn't supported with the last version of madwifi I tested
[11:57] <BenC> I've got access to a laptop with an atheros that doesn't work with 0.9.2 either
[11:58] <thom> mjg59: doesn't look like that has the pci ids for the core 2 duo MBP atheros part at least :/
[11:58] <mjg59> thom: Easy to add
[11:58] <mjg59> At least with openhal, we have /some/ chance of being able to get something working
[11:58] <kylem> the MBP atheros needs a new HAL.
[11:59] <mjg59> Does it need a new HAL, or does it need new IDs adding to the existing code?
[11:59] <thom> mjg59: new HAL
[11:59] <mjg59> Oh!
[11:59] <kylem> i think a new hal.
[11:59] <thom> mjg59: http://madwifi.org/ticket/1001
[11:59] <mjg59> Rip it out of the macos X driver
[11:59] <mjg59> It's madwifi based
[11:59] <kylem> hmm. not a bad idea.
[11:59] <thom> mjg59: ORLY? nice
[12:00] <kylem> so i can just replace the damned card entirely. :)
[12:00] <mjg59> Or try hacking up openhal
[12:00] <mjg59> I suspect that it's not actually that different
[12:01] <kylem> adding ipw3945 to macos, or making power management in linux not suck.
[12:02] <Mithrandir> the former, so you should do the latter.
[12:02] <gnomefreak> does dapper have an xen kernel?
[12:02] <kylem> Mithrandir, heh. :)
[12:03] <BenC> gnomefreak: nope
[12:03] <BenC> mjg59: I think mine needed new hal...I added the ID's to current madwifi and it just crashed
[12:04] <gnomefreak> BenC: we got people wanting a libc6-xen for dapper's existing version of glibc  and they were told not gonna be backported and they dont understand why
[12:04] <BenC> gnomefreak: Because dapper can't run as a xen guest would be my best answer
[12:04] <mjg59> BenC: Right, the current hal will refuse to run on them
[12:05] <gnomefreak> k
[12:05] <mjg59> That doesn't necessarily mean that there are significant differences
[12:05] <BenC> and if they are compiling their own domU kernels, they can compiler their own libc6 too :)
[12:05] <tepsipakki> hrm, my feisty-desktop is resetting the sata-port constantly when under load, should I blame the hardware or something else?
[12:05] <kylem> mjg59, i'll go fetch my macbook from my hotel room after lunch and try to rip out the hal.
[12:05] <Mithrandir> gnomefreak: because feisty has a completely different glibc version and we don't backport core libraries.
[12:06] <gnomefreak> they were told that ;)
[12:06] <mjg59> kylem: Hm. Though reading that bug, I'm not sure what's going on.
[12:06] <mjg59> Apple may have changed to a new driver design.
[12:06] <Mithrandir> yes, and I didn't see a response signifying that they didn't understand why glibc would not be backported.
[12:06] <mjg59> Certainly older versions gave identical hal errors to Linux if you tried to run on an unsupported card
[12:07] <gnomefreak> Mithrandir: came back with just the xen patches to create a libc6-xen for dapper's existing version of glibc
[12:07] <kylem> mjg59, i toss binutils at it and see what sticks.
[12:07] <gnomefreak> either way it means backporting core libs
[12:08] <Mithrandir> gnomefreak: then that'd not be a backport, but a stable release update.  I doubt we would accept an update for such a core package to support functionality not in dapper.
[01:05] <tepsipakki> it's normal that 2.6.17 won't boot on feisty? I'd like to debug the sata_sil reset thingie more..
[01:07] <tepsipakki> http://lkml.org/lkml/2007/1/3/144
[04:37] <kylem> gentoo users are muppets
[04:37] <kylem> The Core2Duo is an improved Pentium 4 with 64 bit extensions (x86-64). Thus with GCC 4.1 the nocona architecture is the one to use in 32 bit mode:
[04:37] <kylem>   CHOST="i686-pc-linux-gnu"
[04:37] <kylem>   CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe"
[04:37] <kylem> (news at 11, i suppose)
[04:37] <mjg59> Oh dear.
[04:38] <thom> *boggle*
[04:39] <zul> er..ok
[04:39] <Mithrandir> they should use -pipe -pipe -pipe for better optimisations.
[04:40] <kylem> if they'd just used x86-64, they wouldn't need -fomit-frame-pointer and get debuggability /and/ more registers still...
[04:40] <kylem> not to mention just how wrong using a pentium4 instruction scheduler in core2 is
[04:40] <mjg59> They've confused Core2 and Pentium D
[04:40] <mjg59> The fact that Intel released two entirely different series of dual-core 64 bit CPUs probably didn't help
[04:41] <kylem> only one of them was actually worth buying.
[04:41] <mjg59> Well, yeah
[04:49] <kylem> groo.
[08:44] <zul> BenC: uploaded and emailed