[10:44] <bboschman> Hi
[10:44] <bboschman> I get the following error while kernelcompile:
[10:45] <bboschman> http://paste.debian.net/12712/
[10:46] <bboschman> the only I changed was debian/changelog (new version) and CONFIG_VERSION_SIGNATURE
[12:04] <alex_joni> bboschman: what's the command you used?
[12:30] <bboschman> alex_joni, CONCURRENCY_LEVEL=2 AUTOBUILD=1 NOEXTRAS=1 fakeroot debian/rules binary-server
[14:38] <soren> I see you moved the virtio drivers into a seperate udeb, and marked it priority: extra.. Is the latter deliberate?
[14:45] <johanbr> Is timg around? He's marked bug #183033 as "fix committed" for intrepid, which I don't think it is.
[15:47] <BenC> soren: it is...we don't want all those modules being forced in lowmem netboots
[15:48] <soren> I can think of modules that are much more ripe for a move to extra than virtio. virtio will actually be used. :)
[15:49] <BenC> soren: but if it's forced to be loaded on lowmem systems, it makes the lowmem install useless :)
[15:49] <soren> AFAICS, it's only virtio and crypto that are extra, while *everything* else is there by default.
[15:49] <soren> Or am I reading too much into the priority of the udebs?
[15:49] <BenC> I can change the extra setting if you want, I just need it in a separate udeb
[15:50] <BenC> I think you are reading too much into it
[15:50] <soren> Ok.
[15:50] <soren> What I'm seeing is that the virtio_pci and virtio_ring modules were missing in the installer.
[15:50] <soren> d-i failed to find my nic.
[15:51] <soren> Truth be told, I didn't spend *that* much time on it, but it just seemed to me that the only difference between now and back when it worked was that virtio_ring and virtio_pci were moved to a udev with priority: extra.
[15:52] <soren> ...and it just so happens that the only two udebs marked as extra are crypto and virtio.
[18:22] <orangepeelbeef> guys how do i build the git linux-modules in hardy it keeps saying it needs the source for 2.6.24-21 but the latest package in the repo is 2.6.24-19
[19:08] <orangepeelbeef> how do i retrieve a specific version from the git kernel repository
[21:17] <baron1984> what kernel release is the 2.6.26-4 kernel in Intrepid using?
[21:20] <amitk> baron1984: 2.6.26
[21:20] <baron1984> final?
[21:22] <baron1984> will the backports for ACPI in the Linus git tree be backported into Intrepid?
[21:22] <amitk> baron1984: 2.6.26 final + cherry picked patches from 2.6.27-rcX is the plan
[21:22] <erle-> suspend to ram broken since last kernel update in hardy 64 bit
[21:22] <erle-> anybody who can confirm that?
[21:23] <baron1984> suspend to RAM just doesn't work in ANY Linux kernel for me
[21:23] <amitk> baron1984: what are the backports for ACPI?
[21:23] <baron1984> it does in 2.6.26-4 on Intrepid
[21:23] <baron1984> but when I reboot
[21:23] <baron1984> it freezes
[21:23] <erle-> kernel panic comes up
[21:23] <baron1984> just before it restarts
[21:23] <erle-> suspend works with kernel 2.6.24-19
[21:23] <baron1984> I've filed a bug on it
[21:23] <baron1984> [patch] acpi: fix crash in core ACPI code, triggered by CONFIG_ACPI_PCI_SLOT=y
[21:24] <baron1984> may fix this?
[21:24] <baron1984> bug 251338
[21:24] <baron1984> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/251338
[21:25] <baron1984> the initial report was for Hardy
[21:25] <baron1984> but I redid the dumps with 2.6.26-4 on Intrepid
[21:26] <amitk> baron1984: I am not sure what your situation is - Is the intrepid kernel a regression from Hardy?
[21:27] <baron1984> amitk: No, in fact it's a large improvement, ACPI has gone from hardly working at all to working "more"
[21:27] <baron1984> it crashes on reboot after having suspended
[21:28] <baron1984> I've asked Foxconn what their problem is
[21:28] <baron1984> they told me to go buy Vista
[21:28] <baron1984> well, after several layers of "support"
[21:29] <mkrufky> sounds like fighting words to me
[21:29] <mkrufky> or like a mystical curse
[21:29] <mkrufky> who "buys vista" ?
[21:29] <baron1984> telling me to yank out my RAM modules and see if the problem continues?
[21:29] <mkrufky> never install vista on an old machine!
[21:29] <amitk> baron1984: so what are you looking to be backported? and from where?
[21:29] <baron1984> oh, I have Vista, it's an OEM copy
[21:29] <baron1984> and this motherboard is a replacement
[21:30] <mkrufky> it makes sense to run vista on a NEW machine that COMES with it installed
[21:30] <mkrufky> (if you absolutely must)
[21:30] <baron1984> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/246222
[21:30] <baron1984> I think this may fix the problem? 
[21:33] <amitk> baron1984: that bug only enables custom DSDTs. Do you have one for your board?
[21:33] <baron1984> I'm sure I could come up with one
[21:33] <baron1984> there was a Gentoo guide on how to do it
[21:35] <baron1984> http://www.lesswatts.org/projects/acpi/overridingDSDT.php
[21:35] <baron1984> that may work
[21:36] <baron1984> but only when the patch that allows it lands
[21:36] <baron1984> unless I want to futz about with a custom kernel on an Alpha distribution
[21:36] <baron1984> (I really don't)
[21:40] <baron1984> amitk: If I understand this correctly
[21:41] <baron1984> I'd build the DSDT, and just place it into /boot?
[21:42] <amitk> baron1984: you could give it a try when the next kernel is available. The git commits have already landed. I just checked
[21:43] <amitk> baron1984: correct
[21:44] <baron1984> amitk: How exactly would I fix the DSDT I have?
[21:44] <baron1984> I do not know assembler
[21:46] <amitk> baron1984: there is a lot of documentation around to fix DSDT, but you should start by looking if someone has already posted something for your board at http://acpi.sourceforge.net/dsdt/view.php
[21:47] <amitk> http://acpi.sourceforge.net/dsdt/index.php
[21:54] <baron1984> amitk: should I upload my disassembled dsdl in to Launchpad?
[21:54] <baron1984> or would this not be kosher?
[21:55] <baron1984> amitk
[21:55] <baron1984> looks like it probes to find out what Windows it's using
[21:55] <baron1984> and if it doesn't find one, it falls back to NT 4
[21:57] <amitk> baron1984: that is usually the beginning of DSDT problems - customization of behaviour for differnt windows versions :)
[21:57] <baron1984> If (MCTH (_OS, "Linux"))
[21:57] <baron1984>   Store (0x03, OSVR)
[21:57] <baron1984> peculiar
[21:57] <baron1984> it doesn't do that setting for any Windows version
[21:58] <baron1984> it gets better
[21:58] <amitk> baron1984: it is unlikely that anybody will be able to help with a particular DSDT. You are on your own there because it is so HW specific. But the acpi list is a good place to ask for help.
[21:58] <baron1984> there is no package 0x03
[21:58] <baron1984> only 0x04
[21:59] <baron1984> you figure recompiling it telling it to detect Linux and use Windows Vista's DSDT package would help?
[21:59] <baron1984> B-)
[21:59] <amitk> baron1984: as a rule of thumb, from the ACPI maintainer - they try to be bug-compliant with Windows for the ACPI implementation. And they keep pleading to BIOS vendors not to do different things for different OSes.
[22:03] <baron1984> amitk: This is sabotage
[22:03] <baron1984> plain and simple
[22:03] <baron1984> there's no other explanation for telling Linux to use different DSDL table
[22:05] <baron1984> amitk: I recompiled it and got 7 warnings
[22:05] <baron1984>  Acquire (MUTE, 0x03E8)
[22:06] <baron1984> Warning  1103 -                                 ^ Possible operator timeout is ignored
[22:07] <baron1984> oh hell no
[22:07] <baron1984> I know what they did
[22:07] <baron1984> they gave a bogus table just for Linix
[22:07] <baron1984> *Linux
[22:07] <baron1984> that they know will break it
[22:08] <baron1984> clever bastards
[22:13] <baron1984> http://ubuntuforums.org/showthread.php?p=5451708#post5451708
[22:33] <BenC> soren: ping
[22:44] <soren> BenC: Oui?
[22:45] <BenC> soren: in zinc:~bcollins/ is the test virtual package
[22:45] <soren> BenC: i386?
[22:45] <BenC> soren: amd64
[22:45] <soren> Whee!
[22:46] <soren> My favourite :)
[22:46] <BenC> soren: I can do 32-bit later if needed
[22:46] <BenC> soren: NOTE: it's based on -server build, so uname looks like -server and everything is installed as 2.6.26-4-server, and it conflicts with the -server image
[22:46] <BenC> soren: I don't see that as a problem really, but just so ya know
[22:47] <soren> BenC: I'm curious how you'll pull of building an amd64 kernel for i386, though. You said you'd use the same approach, right?
[22:48] <soren> s/of/off/
[22:48] <BenC> soren: I have no intention of doing that
[22:48] <soren> Oh, ok.
[22:49] <soren> You did mention a similar use case for this approach in Boston, didn't you?
[22:51] <BenC> Perhaps, but I can't recall what it is