=== doko_ [n=doko@dslb-084-059-083-129.pools.arcor-ip.net] has joined #ubuntu-kernel [12:43] it's sad that the 2x550Mhz A500 can compile faster than the 2x800Mhz i2k [12:43] the A500 is on it's third kernel while the i2k is still working on the first === anavim [n=anavim@nat1.supportsoft.com] has joined #ubuntu-kernel [01:20] jbailey: ping === mkrufky [n=mk@user-12lcpqp.cable.mindspring.com] has joined #ubuntu-kernel [01:27] BenC: pong [01:28] jbailey: talked to benh, and got some things squared away...so I expect 2.6.15-6.8 to work for you [01:28] rtc and fan problem [01:28] Ooo! [01:28] What was it? [01:29] CONFIG_RTC => CONFIG_GEN_RTC (change in ppc for 2.6.15), since we are using the wrong rtc module [01:29] and for the cpu, therm_pm72 needs to be loaded [01:29] Is that the generic timekeeping patch I saw on lkml a couple weeks ago? [01:29] 'k. Should therm_pm72 be loaded in the initramfs then, I guess, sam as fan.ko is on acpi systems? [01:29] nah [01:30] well, in breezy it was built-in [01:30] so I am going to do that for least-surprise reasons [01:30] Hmm. [01:30] almost every G5 needs it [01:30] I'm a strong fan of get-it-out-of-the-kernel. [01:31] without it, you get the "vaccum cleaner mode" as benh put it :) [01:31] The initramfs has to handle it for laptops anyway. Keybuk's laptop gets about 20 seconds before it overheats otherwise. [01:31] so in this case, since 99% of the users of this kernel will need it, I think it's best to put it in [01:31] yeah, but every laptop is different in someway, isn't it? [01:32] Soudns like a trick question. =) [01:32] or is that general acpi? [01:32] yeah, it was a little tricky :) [01:32] General acpi. [01:33] In the init-premount hook, we have a scrip that just does: [01:33] modprobe -q fan [01:33] modprobe -q thermal [01:33] It's be simple enough to just add therm_pm72 into there, too. [01:35] FWIW, should I also test reboot and try to load the fan module to be sure on that one? =) [01:35] My glibc build is almost done. [01:35] yeah, that would be good === anavim [n=anavim@nat1.supportsoft.com] has left #ubuntu-kernel [] === jbailey tries that therm test now. === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [02:12] BenC: I'm giving it a moment for the fans to get going so that I can clearly hear tht they've stopped after. [02:12] ok [02:12] therm_p72 should be the module [02:12] They're usually doing pretty good by about 4 minutes. [02:13] yup, that does it. =) [02:13] fixed it? [02:14] Yup [02:14] sweet, thanks! [02:14] Are you going to build it in, or should I upload initramfs-tools with a fix? [02:15] The other option is that you can link it in /lib/modules/${VER}/initrd [02:15] initramfs honours those too. [02:15] But I'd rather see those go away. [02:17] BENC LIED TO ME. [02:18] infinity: I'm about 30 minutes from an upload [02:18] (h is fair, given the number of times I've lied to him..) [02:18] s/(h/(Which/ [02:18] jbailey: if you could upload it, it would give me more time to get -6.8 out :) [02:18] Sure, but since infinity's here.. [02:19] I didn't expect to take this long, had to back out and redo some patches for parisc at the last moment [02:19] infinity: You planning an upload in the next couple of minutes for initramfs-tools anyway? [02:19] yeah, infinity, initramfs-tools needs to load therm_pm72 for powerpc fans :) [02:19] infinity: I was thinking of just stuffing it in scripts/init-premount/acpi =) [02:19] it's strictly a ppc64 thing [02:20] Maybe rename it to heat [02:20] We can have ikeaesque names. === jbailey does Yet Another Build of glibc. [02:21] BenC: Are you still using all the space on concordia? [02:21] It would probably be handy for me to try this build there, although the changes are sufficiently non-invasive that I'm not worried about a multi-arch test right now. [02:22] I should be empty on there...let me do a clean [02:23] Thanks/ [02:24] ok, 6.6G free [02:32] If we want IKEA names, I should make it nonsensical, like scripts/init-premount/jerker or something. [02:32] "jerker is the name of my desk... I may have purchased it just for that reason) [02:33] s/"/(/ [02:34] BenC: are you 1394 maintainer? [02:36] Didn't Jody take that over? [02:36] Okay, I see two names in scrollback. Is the module therm_pm72 or therm_p72 [02:36] ? [02:36] $ lsmod |grep therm [02:36] therm_pm72 36856 0 [02:39] I just uploaded. [02:39] infinity: Hey, in terms of testsuites.. Right now I only test the glibc that I absoluely know can be run on every class of machine that might build it. (Like I run ppc tests, but not ppc64. However, all our buildds are i686 at least, so I run i386 and i686 tests). Is it worth putting a hack in there to try and detect if the buildd is actually capable of running a particular test and enabling it? [02:40] infinity: Or would you rather that builds be more deterministic than that? [02:40] Well, the more tests, the merrier. [02:40] Our buildds are all ppc64, fwiw. [02:41] I want deterministic BUILDS, but deterministic testsuites don't seem quite as crucial. Testing based on detection of the metal you're currently running on doesn't seem so horrible. [02:42] 'k. I'll think about that for the next round of retooling, then. [02:43] I'm going to actually start checking for regression in the testsuite instead of merely logging what failed, so it's a good time to think about this. =) [02:44] mkrufky: technically, but I don't really do much with it anymore [02:52] BenC: gotcha.... i only ask because stoth described an obscure 1394 problem to me, i thought u might be interested [02:52] i directed him to #linux1394 [02:53] ok === lamont [n=lamont@mix.mmjgroup.com] has joined #ubuntu-kernel === lamont [n=lamont@mix.mmjgroup.com] has joined #ubuntu-kernel [03:18] BenC: I'm afk for about 1h for dinner and hanging out with Angie. I'll be back after to finish my glibc upload and stuff. If there's anything you need me to do (test reboots, etc.) I can do them then. [03:19] ok === infinity updates madwifi while he waits for the new kernel. [03:22] I wonder if I should be a do-gooder and make ltmodem build again, too. [03:48] woohoo, all the testsuites passed. === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [04:00] Is it expected that the new udev HW detection doesn't seem to find my nic? [04:01] BenC: I think that the kernel should fail the install if update-initramfs fails. When replacing current modules, there's a reasonable risk that if it fails that you have an unbootble system. [04:01] right now, it fails in postinst if update-initramfs returns an error [04:02] Hmm. [04:02] So update-initramfs needs to return an error then, I guess. =) [04:02] I ha to revert to an old kernel and do a takeover. [04:02] it does already [04:02] It did not as of about 10 minutes ago. [04:03] atleast it did when I tried installing with an existing initrd there [04:03] The -5.7 that's in the archive. [04:03] hmm [04:03] the -5.7 you got from me wont [04:03] the one in the archive _should_ [04:03] It gave me the message saying that couldn't overwrite it, and then appeared to continue succesfully. [04:03] oh, weird [04:03] I was replacing the -5.7 I got from you with the one in the archive. [04:03] So maybe some sort of weird issue with replacing the current version? === jbailey goes hunting why the new initramfs didn't load therm_pm72 correctly. [04:06] Dear infinity: It's lovely that you've modprobed the thermal module, please also actually include it in the initramfs, kthxbye. [04:07] Dear jbailey: stop making requests before I've woken up. [04:07] I've seen no evidence that you sleep. [04:08] infinity: Would you like me to upload an actually tested version? =) [04:11] A version tested by someone with a ppc64 machine?... That's a novel idea. [04:13] glibc is now officially in the "worksforme" category, up she goes. [04:14] infinity: -6.8 in T-Minus 1 minute [04:15] Ahaha, sweet. glibc and the kernel on the buildds. [04:15] QUICK! SOMEONE UPLOAD X! [04:15] and gcc :) [04:17] done [04:17] jbailey: did I beat your glibc upload? [04:18] well, the cron will run at the same time, guess linux-source-2.6.15 will become victim to glibc only because of the silly alphabet === ..[topic/#ubuntu-kernel:BenC] : Ubuntu kernel development discussion ONLY | New git tree for dapper: https://wiki.ubuntu.com/KernelGitGuide | 2.6.15-6.8 uploaded (The "Can it get much better?" release) [04:19] infinity: *pomp* the ball's in your court now :) [04:21] No one will be anyone's victim, there's more than one buildd per arch. :) === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [04:24] Well. Here's hoping that particular crash was random and not my fault. [04:24] Xorg spun out. === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel === BenC is off to bed [04:40] g'n Ben. [04:43] jbailey: any chance you got glibc tested on sparc? [04:43] did you do any major updates to it? [04:43] BenC: I tested it before the last round of changes, but those worked on ppc, i386 and amd64 so I'm expecting it to build everywhere. [04:43] debian's glibc just got broken for the 64-bit build, and I want to make sure we don't do the same :) [04:43] I didn't get nptl on sparc64 working [04:43] Nah, I actually test my changes. [04:43] The NMU was poorly timed and lartable there. [04:44] Although if I could still have access to your machine at some point. Backporting on a sparc5 is really sucking rocks. =) [04:45] is TLS enabled for sparc? [04:45] lol, yeah, after this weekend, I can give out accounts for usage [04:46] TLS and NPTL are on sparcv9 and sparcv9b [04:46] what about 64-bit? [04:46] I gave it compiling on sparc64, but segfaulting in the linker. =) [04:46] So I stuck with LT for this upload and did the minimal fix to get it building again. [04:47] cool [04:48] keep 64-bit the same until fabbione or I hear different from davem, he says TLS is broken on 64-bit === jb770 [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [04:48] Roar [04:49] This machine seems to crash out x now [04:49] No idea yet which change is doing it. :( === jb770 tries the old kernel first === wjb [n=Miranda@auproxy1.proxy.lucent.com] has joined #ubuntu-kernel === jbailey_ [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel === mkrufky [n=mk@user-12lcpqp.cable.mindspring.com] has left #ubuntu-kernel [] [05:46] BenC: So far no X hang when I revert to 2.6.12. Dunno if that's the new udev or the new kernel though. [05:46] (-5.7) [06:22] BenC : Any plans to resurrect acx_pci? [06:22] hey jbailey_ === JaneW [n=JaneW@dsl-146-171-180.telkomadsl.co.za] has joined #ubuntu-kernel [07:30] jbailey_ : Hahah. Was that meant to be a subtle joke, or were you having editor woes? :) [07:31] jbailey_ : (initramfs...ubuntu3 has a debian/changelog.dch.save with a different changelog entry than debian/changelog..) === fabbione [n=fabbione@port49.ds1-van.adsl.cybercity.dk] has joined #ubuntu-kernel === ispiked [n=ispiked@unaffiliated/ispiked] has joined #ubuntu-kernel === ispiked_ [n=ispiked@Lee-12-238.rh.ncsu.edu] has joined #ubuntu-kernel === chmj [n=chmj@dsl-146-147-133.telkomadsl.co.za] has joined #ubuntu-kernel === jbailey__ [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel === lbm [n=lbm@cpe.atm4-0-1301006.0x50a0824e.vgnxx6.customer.tele.dk] has joined #ubuntu-kernel === CataEnry [n=cataenry@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [10:45] hi all [11:00] bye :) === chmj [n=chmj@dsl-146-179-166.telkomadsl.co.za] has joined #ubuntu-kernel [01:29] infinity: *Lol* I had been originally going to use that as the quote, and decided that I didn't feel that antagonistic. Then X crashed on me. =) [01:32] jbailey__: are you running -6.8 now? [01:32] fabbione: ping [01:32] BenC: pong [01:33] fabbione: -6.8 build on sparc yet? [01:34] it's in the queue after perl and glibc [01:34] it will take sometime to get there [01:34] BenC: No, still -5.7 [01:34] Actually. [01:34] Hmm [01:34] No, I'm running 2.6.12 so that my session will stay running. [01:34] I'll try -6.8 in a moment. [01:34] damnit, I knew glibc would slow me down :) [01:35] BenC: glibc will also unleash modular X on sparc, for which we don't have sparc specific drivers [01:36] later guys [01:44] fabbione: later [01:45] BenC: Should I try -6.8 and see if it eats my machine? [01:45] yes, please [01:45] and reenable hwclock too, if you could === janimo [n=jani@Home03207.cluj.astral.ro] has joined #ubuntu-kernel [02:15] wow, I have malone bugs [02:19] Yeah, the upshot of having two bug tracking systems is that people use both of them. *sigh* [02:29] Most of my Malone bugs have been pretty simple wishlists so far, so I haven't minded. [02:29] Which is good, cause Malone and I don't get alone yet. [02:30] a/alone/along/ === infinity gets alone with Malone and shows it a good time. [02:36] infinity: I think Malone will show _you_ a good time, since you're the one that has to "Submit" :) [02:41] BenC : I'm off to bed, lrm is waiting in binary NEW. When elmo gets around to processing it, feel free to do the linux-meta ABI bump again (perhaps confirm with Kamion first that it won't screw his d-i mangling/testing) [02:42] ok [02:42] Though at this point in the game, where d-i gets screwed every 5 minutes by some random uploa,d he'll probably say "just do it". [02:42] is udev done? [02:42] Define "done". [02:42] uploaded [02:42] It's been uploaded several times. It half works, and is half broken. [02:43] Yeah, it was uploaded ages ago, and linut-meta was already uploaded for 2.6.15-5... YOu missed that? :) [02:43] (mdz made the order, despite powerpc being broken) [02:43] no, I saw that [02:43] oh, I had missed that [02:43] So, yeah. -meta just needs another bump for -6... When LRM gets out of NEW. [02:44] ok [02:44] I probably have 2 or 3 more "real" LRM uploads to do this cycle, but the rest I'm going to leave to you. [02:45] If you want to grab the source and look at the top of debian/rules, you'll see where it automagically figures out kernel versions and such. ABI dumps are now a matter of changing one integer in debian/rules and adding a changelog entry. Same as with linux-meta. [02:45] linux-meta needs a dh compat bump [02:45] And this concludes me signing off on "make sure Ben's up to speed on being able to update LRM" [02:45] sweet [02:46] later :) === CataEnry [n=cataenry@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [02:57] hi all === mgalvin [n=mgalvin@host-66-202-95-170.spr.choiceone.net] has joined #ubuntu-kernel === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [03:08] BenC: I'm on the new kernel, cat'ing that file works, hwclock works. [03:08] My fans are behaving with the new initramfs-tools [03:09] Now just need to see if X dies on me again. =) [03:11] nice [03:18] Well, 10 minutes of idle didn't kill it. [03:32] 'nother 10 minutes under steady usage, no prob. === jbailey fires up a make -j5 ccache'd glibc build in a visible terminal. [03:32] The only other thing I can think of it to surf a couple dozen pr0n pages to test the image cache. [03:32] bye [03:37] beat it into submission [03:37] let it know who's boss :) [03:43] Right [03:43] pr0n it is then. =) === zul [n=chuck@ubuntu/member/zul] has joined #ubuntu-kernel [03:58] heylo [04:06] hey zul [04:07] Zool! [04:08] BenC: I just passed an hour of uptime. glibc build going in a window, lots of email, web surfing, openning/closing terminals, etc. [04:08] It didn't make it 10 minutes before like this, so I think that -6.8 also solves that. I think we can stamp ppc64 as gold. [04:08] excellent! thanks === _maydayjay_ [n=maydayja@gimel.nas.net] has joined #ubuntu-kernel [04:25] must...do...kernel...work...tonight === jbailey770 [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [04:27] Benc: x just died on me. Anything i can check before i reboot ? === CataEnry [n=Enrico@host204-30.pool8248.interbusiness.it] has joined #ubuntu-kernel [04:30] hi all [04:34] jbailey: not sure [04:35] jbailey: any processes in D state? [04:36] jbailey: dmesg, "ps axuwww", send me those if you can [04:36] if any processes are in d-state, send me "cat /proc//wchan" aswell [04:37] K [04:38] BenC: i think i narrowed it down a bitmto when im typing alot. [04:39] I don't see anything in d state. [04:41] Ok to reboot now? [04:41] yeah [04:41] X freezing, mouse still works, I'm wondering if this is a hal problem [04:42] sounds like some bug reports I've heard about concerning hal [04:44] Well mouse is usually hwcursor isn't it? [04:45] Kill -9 of x gets the rest of the system happy again . === jbailey [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [04:47] BenC: Fired off the email. [04:47] thanks [04:48] New udev, I'll load that. [04:49] BenC: When I look at when it's failed, it's been when I was editting a long changelog entry, doing lots of typing, writing emails, or writing things in RT. [04:50] All primarily kbd based. [04:51] nothing in the process list sticks out, so I can only assume that it's the kernel that starts killing the load [04:52] all the processes are in sleep except X, so it something in the xserver directly [04:52] X definitely isn't waiting on something (else it would be in sleep too) [04:53] hard to say who is at fault [04:53] wish I had asked you to kill X, and try restarting it, but you can try that later when you have some time [04:53] oh, nm [04:53] I see you did that :) [04:53] I'm still in 2.6.15, so it's going to recur at some point. =) [04:53] Well, I didn't try restarting X. [04:54] I typed, reboot, realised that it was going to take forever to do that, and did a kill -9 of X. [04:54] It rebooted a moment or two after. =) [04:54] try "ctrl+alt+backspace" next time if you can, to see if it will restart X by itself [04:55] I'd tried that before, it doesn't work. [04:55] No keyboard input seems to have any effect, I cannot change VTs. [04:55] Although, I could try a chvt from the ssh session. [05:06] ok [05:13] Everyone ignore the linux-meta upload I just did. It wasn't me. I'm asleep. [05:13] That is all. [05:20] Oh, also. [05:21] BenC : Misdirected complaint... [05:21] infinity: linux-doc-2.6.15 conflict/overwrites linux-doc-2.6.12 [05:21] yeah, got a bug report already === lbm [n=lbm@x1-6-00-13-10-7a-d1-e4.k233.webspeed.dk] has joined #ubuntu-kernel [05:43] fabbione: ping === lamont__ [n=lamont@mib.fc.hp.com] has joined #ubuntu-kernel === trevilor [n=trevilor@p549CD7D7.dip.t-dialin.net] has joined #ubuntu-kernel [05:59] hi guys === chmj [n=chmj@dsl-146-179-166.telkomadsl.co.za] has joined #ubuntu-kernel === jbailey_ [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-kernel [07:31] Hmm, actually had a real kernel crash that time. [07:31] BenC: No idea what from, nothing in the logs. I got out of the shower to a machine with the fans going full tilt and not answering pings or ssh [07:33] BenC: Do you have a -6.8 kernel done with gcc-3.4 at all? I wonder if that would make a difference. === zul [n=chuck@CPE0006258ec6c2-CM000a73655d0e.cpe.net.cable.rogers.com] has joined #ubuntu-kernel [08:56] fs: pong? === mkrufky [n=mk@68.160.103.77] has joined #ubuntu-kernel [08:57] fabbione: hi =) [08:57] fs: hey dude [08:58] i don't have much time now.. we have a meeting in 3 minutes or so [08:58] what can i do for you my friend? [08:58] fabbione: do you remember by chance what the amd64-int3-fix.patch in linux-2.6 was for? [08:58] it was added in 2.6.10 along with another couple of patches which where all merged upstream, just this one not [08:58] fs: hmm i think i saw it in the Debian kernel, but i did never look at it [08:59] or was it in our kernel? [08:59] ok thanks =) [08:59] I think it was in both [08:59] thus the question [08:59] i am checking [09:00] as soon as my raid will resume from sleep [09:00] and somebody will explain me why my disks went to sleep [09:00] btw, do you have a current rediffed version of drivers-scsi-megaraid_splitup.patch or was it dropped from ubuntu kernel too? [09:00] fs: it's in git [09:00] heh, asleep raid disks? [09:00] on my workstation [09:00] scary [09:01] indeed :) [09:01] i just upgraded to 15-rc3 [09:01] fs: what does the patch patch? [09:01] i don't see anything like that in my patch list [09:01] perhaps a different name? [09:01] the megaraid one? it lists you as the author =) [09:02] it splits pci ids from newgen and legacy megaraid drivers, so both can be compiled [09:02] no sorry i am talking about the amd64 one [09:02] the legacy supports a few old cards the newgen one does not [09:02] i know about the megaraid [09:03] bye all [09:03] oh, it adds 2 lines to a case DIE_INT3 in arch/x86_64/kernel/kprobes.c [09:03] it's debian specific [09:03] I dropped it for 2.6.14, and it caused no harm so far [09:03] lsdiff -H * |grep kprobes [09:03] I just wonder [09:03] null [09:04] ok, then I'll remove it [09:04] eheh [09:04] thanks man =) [09:04] no problem dude [09:04] any time [09:07] fs: should be fixed since 2.6.12 [09:07] -> http://www.ussg.iu.edu/hypermail/linux/kernel/0503.3/1974.html [09:07] BenC: #ubuntu-meeting [09:11] makx: looks good, thank you =) [09:11] fs: no thank you dude for going 2.6.15. [09:41] mdz: already there [09:58] BenC: we might not even need or want to merge them, if the packages we have work fine [09:59] I was thinking that too [09:59] we probably want to look at possible kernel-wedge bug fixes [09:59] but kernel-package has been taking a direction that we might have problems with [09:59] yeah, it's been broken up into "module" scripts [09:59] yes [09:59] we can for sure give it a shot [09:59] interesting how the ubuntu kernel build infrastructure has grown completely different than the debian one [10:00] fs: git pushed us into a different direction [10:00] fabbione: I searched around in git, you don't have a debian/patches dir anymore? is the megaraid driver split implemented directly in drivers/scsi/megaraid? [10:00] fs: what ben sais :) [10:00] fs: yes. it's in a git commit [10:00] yeah, looks pretty interesting =) [10:01] fs: yes, "git-whatchanged " [10:01] especially building the udebs from the same source [10:01] fs: that will never be accepted in Debian [10:01] i had that discussion already on debian-boot [10:01] when the 2 build systems were closer [10:01] well then, I guess I have to checkout the whole thing [10:02] fs: yes... [10:02] fabbione: we had the discussion again a week ago, it soon went a highly emotional way [10:03] fs: i am not surprised :) [10:03] maybe if someone makes a decent proposal with some working code, it will be accepted [10:04] fs: the code was working... and it still does [10:04] it kinda needs to be updated to your new build system [10:04] we still use it :) [10:05] fs: in regards of keeping 2 different build system i think it's good [10:05] fs: we keep developing different bits merging/splitting/remerging and so on [10:06] fs: if you look at the history.. [10:06] we started with the same build system done by herbert [10:06] we landed in 2 different places [10:06] yeah [10:07] debian did push later (after sarge) in a similar directions that we did already explore here [10:07] (build all from one source) [10:07] using a different and probably more clean implementation [10:07] on my suggestion and discussion with others [10:07] Debian did the config. file split/allignement [10:07] that now we are partially pulling back [10:07] so even if the code is not exactly the same [10:07] we rely on the same concepts [10:08] and we are both improving by a bit of competition [10:08] who is doing what now? [10:08] that imho is very good [10:08] zul: what? [10:08] what are you guys on about? [10:08] Debian <-> Ubuntu kernel build system sync [10:09] ah ok.. [10:09] fs: personally i believe we did achieve a lot working this way.. probably more than sharing the same code [10:09] fs: not convinced. ;) === fabbione takes a smoking break [10:09] ehh upps fabbione. :) [10:10] I guess I need to track your development much closer ;) [10:39] you can start with our git tree ;) [10:43] BenC: linux-source-2.6.15 needs to Depend: gcc-3.4 on architectures using 3.4... [10:43] more to the point, linux-source-2.6.12 has this issue, and causes some ftbfs pain [10:43] only one I know of is hppa [10:43] which is does [10:44] *it [10:44] see http://buildd.mmjgroup.com/buildLogs/c/cpqarrayd/2.2-1/cpqarrayd_2.2-1_20051129-1652-hppa-failed.gz [10:45] and the last (sparc) build in the same directory [10:45] linux-source-2.6.15 the .deb, you mean? [10:45] --> linux-source-2.6.12 has a bug [10:45] yes. [10:45] the deb [10:45] needs to Depends: $THERIGHTGCC [10:46] ok, that should only affect hppa [10:46] uh... sparc cpqarrayd has the same failure.... [10:46] gcc-3.4: command not found [10:47] ISTR 2.6.12 was all built with gcc-3.4 [10:47] sparc builds with gcc-4, unless fabbione is forcing something [10:47] no i don't force anything [10:47] cpqarrayd build-depends: linux-source-2.6.12 [10:47] so that probably needs to change to -2.6.15 [10:47] yeah === mkrufky [n=mk@68.160.103.77] has left #ubuntu-kernel [] [10:48] crappy, I can't do build-dep like arch depends :) === mkrufky [n=mk@68.160.103.77] has joined #ubuntu-kernel [10:57] mjg59: ping? [11:03] BenC: nope... have to gen them into existance [11:04] fabbione: have you got anyone using amd64-k8-smp on dual opterons? [11:04] er, for breezy that is [11:04] dilinger: no idea, why? [11:04] are you going to send me for testing? [11:05] actually [11:05] hehe [11:05] Mithrandir does run that stuff [11:05] my machine blows up spectacularly w/ smp [11:05] Linux rho 2.6.12-9-amd64-k8-smp #1 SMP Mon Oct 10 13:18:18 BST 2005 x86_64 GNU/Linux [11:05] there [11:05] it works great here [11:05] up to make -j1000 on the kernel [11:05]