[02:00] <jbailey> BenC: Apparently git isn't all setup yet, and CVS should be still considered canonical.
[02:00] <jbailey> BenC: They'renot expecting to be over on git for at least another week.
[02:00] <BenC> who's that?
[02:01] <BenC> parisc?
[02:26] <zul> BenC: its there now
[02:31] <jbailey> BenC: Yes, sorry. =)
[02:31] <zul> doh...mental note...dont put anything in /tmp
[02:34] <jbailey> It's fine until you reboot. =)
[02:36] <zul> duh...
[02:36] <zul> :)
[02:36] <zul> so when are you coming back?
[02:37] <jbailey> Back where?
[02:37] <zul> here
[02:37] <jbailey> I *am* here.
[02:37] <zul> er...ottawa
[02:38] <jbailey> Oh.  Mmm.
[02:38] <jbailey> Unlikely to be in 2005.
[02:39] <zul> ah..
[02:39] <zul> true...
[02:39] <jbailey> Maybe in January to hang out with Carlos for a weekend picking his brain on toolchain btis.
[02:40] <zul> neato
[03:14] <BenC> finally, running 2.6.15-5.7 on all my machines except the a500
[03:15] <BenC> even reverted to stable rt2500 for my mame cabinet
[03:17] <zul> heh
[04:11] <BenC> infinity: ping
[04:21] <jbailey> BenC: It's runnig on the ppc64 and the sparc boxes?
[05:01] <infinity> BenC : pong... I'm doing test builds of the vga16fb change... Can you hold off on 5.7 for a bit?
[05:06] <infinity> BenC : If you're itching to get it uploaded and go to bed, just do it, and I'll do a 5.8 later when I've tested this stuff more.
[05:16] <BenC> jbailey: running on my g4, not ppc64 though
[05:16] <BenC> jbailey: but definitely test it, since there were more ppc64 updates this time around
[05:16] <BenC> infinity: how soon before you can get the vga16fb patch ready?
[05:17] <BenC> infinity: also, what's the ETA on lrm?
[05:17] <BenC> infinity: update-initramfs and notifier changes are in 5.7, btw
[06:40] <fabbione> mornig guys
[06:40] <BenC> hey fabbione
[06:40] <fabbione> hey Ben
[06:40] <fabbione> still up?
[06:40] <BenC> yeah, was hoping to catch adam again
[06:41] <BenC> I'd like to wait for the vga16fb patch before uploading -5.7, but I want to see how long he'll be with it
[06:42] <fabbione> i think he is out for lunch
[06:46] <BenC> I've got -5.7 building cleanly on 5 architectures, I need to do an upload before something breaks it :)
[06:46] <fabbione> aahha
[06:46] <fabbione> bah crappp!!!!!
[06:46] <infinity> BenC : Just upload it, then.  I may be up all night. :/
[06:47] <infinity> I'm having a pretty miserable day of one step forward, two steps back.
[06:47] <fabbione> so fltk doesn't export opengl stuff on sparc that makes openexr FTBFS that stalls all of KDE
[06:47] <fabbione> GO KDE!
[06:47] <BenC> infinity: ok, I'll just do another upload when you get that patch ready
[06:47] <BenC> infinity: is there anything I can do to help with lrm, so we can get linux-meta updated?
[06:49] <fabbione> BenC: nah.. 
[06:49] <fabbione> it's better infinity does LRM and get the blames :)
[06:51] <BenC> I'm more than willing to put the blame on infinity :)
[06:51] <BenC> even if I break it :)
[06:53] <fabbione> ehehhe
[07:00] <fabbione> lol
[07:01] <fabbione> congratulation dude
[07:01] <BenC> don't congratulate me till the buildd's agree with my assessment :)
[07:02] <BenC> this time though, I did all my builds through to udeb builds, so I should be good to go
[07:03] <fabbione> ehhe
[07:03] <fabbione> ok fltk1.1 fixed
[07:04] <fabbione> kde will unleash soon
[07:04] <fabbione> good night ben
[07:04] <fabbione> cya later
[07:04] <BenC> good night
[07:25] <infinity> BenC : No, I just need to figure out some minor details.
[07:25] <fabbione> dilinger: ping?
[01:47] <jbailey> BenC: Checked ppc64, it still fails with the same rtc failure even though you've built it in.
[02:17] <zul> heylo
[02:25] <oldguy> quick ot ok/
[02:27] <jbailey> oldguy: Dad?
[02:27] <jbailey> =)
[02:28] <oldguy> yeah i m a dad..but got three girls
[02:28] <jbailey> I have long hair, but that's as close as I get, sorry.
[02:29] <oldguy> im trying to build a 2/6 kernel for netvista and ltsp-4.2..i built an uncompressed kerenl and catted the initramfs onto it..but  get unsupported file type..
[02:30] <oldguy> so if vmlinux is unsupported..and vmlinuz is unsupported..what else is there?
[02:38] <CataEnry> hi all
[02:38] <chrisle> hi 
[03:06] <jbailey> BenC, fabbione: What's the word on Xen on Breezy?
[03:07] <jbailey> oldguy: You can't cat the initramfs onto a kernel.  You have to embed it in the data segment.
[03:07] <jbailey> oldguy: Or you can pass it in using the initrd mechanism.
[03:14] <fabbione> jbailey: Xen has some kind of .12 support afaik.. but that's it
[03:14] <fabbione> jbailey: last time i did try a merge they were at .11
[03:14] <fabbione> and we were shipping .12
[03:14] <jbailey> But it's nothing we support natively.
[03:14] <fabbione> nope
[03:14] <jbailey> 'kay, thanks,
[03:25] <BenC> fedora's .14 based kernel has patches
[03:27] <jbailey> Ah, cool.
[03:27] <BenC> kick ass, the big three have successful builds for -5.7
[03:27] <BenC> jbailey: feel free to test -5.7 on ppc64 when you get a chance
[03:27] <jbailey> It's more someone I have looking for us to support Xen.
[03:27] <jbailey> BenC: See my comment to you in this channel from a little under 2 hours ago. =)
[03:28] <BenC> jbailey: I looked into it, but the patches are so big and so invasive, I didn't see the point trying at this point
[03:28] <BenC> ah
[03:28] <fabbione> hmm
[03:28] <BenC> jbailey: let me see if there's a kernel command line option that can disable rtc or something
[03:29] <fabbione> if we really really want Xen we can pull it in from their development branch
[03:29] <jbailey> BenC: 'k
[03:29] <BenC> fabbione: is there a Xen git?
[03:29] <BenC> IIRC, they are going to try to get it into 2.6.16
[03:29] <fabbione> BenC: there is an hg tree
[03:29] <fabbione> the tool that's similar to git
[03:29] <fabbione> it's also on kernel.org afaik
[03:30] <BenC> fabbione: -5.7 hit your sparc buildd yet?
[03:30] <fabbione> http://www.kernel.org/hg/
[03:30] <fabbione> BenC: it's building as we speak
[03:32] <BenC> jbailey: can you past the URL to that oops again, please?
[03:32] <fabbione> http://www.cl.cam.ac.uk/Research/SRG/netos/xen/downloads.html
[03:32] <fabbione> The public Mercurial repository for Xen, the modified Linux, and the domain control tools is hosted on http://xenbits.xensource.com, where you can browse the source and inspect the
[03:33] <fabbione> 15 hours ago:  	The device sharing check races when more than one file backed vbd is
[03:33] <fabbione> author:  	rread@ubuntu.eng.hq.xensource.com
[03:34] <fabbione> *perhaps* we can try to get in touch with that guy :)
[03:35] <jbailey> BenC: Hmm, grep isn't turning it up in my logs.
[03:35] <BenC> let me check firefox history, what host name would it be?
[03:36] <jbailey> That's what I'm trying to remember. =)
[03:36] <BenC> lol
[03:36] <jbailey> Something ending in .nl =)
[03:37] <jbailey> grep pastebin.ubuntulinux.nl * | grep jbailey
[03:37] <jbailey> isn't giving me anything.  hmm
[03:37] <jbailey> No, right!
[03:37] <jbailey> I didn't put it in there.
[03:37] <jbailey> I took a picture instead.
[03:38] <dilinger> fabbione: pong
[03:38] <jbailey> http://people.ubuntu.com/~jbailey/P1010042.JPG
[03:38] <BenC> thanks
[03:38] <jbailey> BenC: If you want I can update it for -5.7
[03:38] <BenC> yeah, that'd be nice. see if you can get the whole screen aswell
[03:40] <fabbione> dilinger: hey.. thanks i did manage without :)
[03:43] <infinity> BenC : Okay, LRM ABI switches are now a one-button affair, much like linux-meta, but MUCH SCARIER under the hood.
[03:43] <infinity> BenC : So, once this thing &#@$ing builds for me, your minor maintenance tasks with it should be a no-brainer.
[03:43] <BenC> if I ever have to pop the hood, I'll be sure to take it to the shop(you) rather than work on it myself :)
[03:45] <infinity> Of course, now I have an irritating QT build issue to deal with.
[03:48] <infinity> About time.
[03:49] <BenC> so far everything has built fine
[03:49] <BenC> I expect sparc to build, but I know hppa will fail
[03:50] <fabbione> BenC: sparc is at 64-smp (half way)
[03:50] <BenC> it had been so long since I booted my i2k this weekend, I actually had to smack it on the side of the case to get it to power on
[03:50] <fabbione> it won't take much much longer
[03:51] <BenC> fabbione: sweet
[03:51] <fabbione> i am falling asleep and partman-auto-lvm on ppc is winning 2:0
[03:51] <fabbione> time for coffe and smoking bof
[03:56] <BenC> opinions...in linux-meta, because {686,k7}-smp are going away, should I make the linux-{image,headers}-{686,k7}-smp meta packages depend on linux-{image,headers}-{686,k7} meta packages or make them depend on the kernel-abi-version packages directly (sans the -smp)?
[03:57] <infinity> Make them depend on the other meta packages, so we can eventually remove the SMP packages.
[03:57] <BenC> that's what I was thinking
[03:57] <infinity> (Assuming we want to down the road)
[03:58] <BenC> lamont: ia64 built :)
[03:58] <lamont> BenC: woot!
[03:58] <lamont> and hppa is still git-ftbfs?
[03:58] <BenC> yeah
[03:59] <BenC> if we had 64-bit hppa64 userspace, it wouldn't be a problem :)
[04:00] <lamont> well, yeah
[04:01] <jbailey> lamont: willy said to keep using CVS for at least another week.
[04:01] <lamont> ah, I see.
[04:04] <BenC> probably take a week to get a decent patch out of CVS anyway :)
[04:05] <BenC> anyone packaged git 0.99.9x for ubuntu yet, or even debian?
[04:06] <oldguy> jbailey: thanks..gonna try an experiment
[04:06] <BenC> debian has it...we should grab that to dapper
[04:08] <fabbione> BenC: i think we already sync that automatically
[04:08] <BenC> universe?
[04:09] <BenC> yep, there it is, thanks
[04:12] <BenC> jbailey: can you disable the hwclock problem (mv it out of the way, and symlink to /bin/true, e.g.) and see where you get after that?
[04:12] <jbailey> BenC: You scare me.
[04:12] <jbailey> But okay. =)
[04:12] <BenC> disable hwclock program I meant
[04:12] <jbailey> Is that really the only thing that will cause an rtc event?
[04:13] <jbailey> Or should I avoid using this system for much after that?
[04:13] <oldguy> rootcd /opt/lytsp/i386-4.2
[04:13] <BenC> nothing else should
[04:13] <jbailey> 'k
[04:13] <BenC> everything else should use the system clock rather than the rtc directly
[04:15] <infinity> (should)
[04:20] <BenC> odd that his system seems to oops/freeze on sig 7 from I/O accesses, I would have thought that hw traps would recover from that
[04:20] <BenC> jbailey: running?
[04:20] <jbailey> $ uname -a
[04:20] <jbailey> Linux starshine 2.6.15-5-powerpc64-smp #1 SMP Tue Nov 29 07:20:51 UTC 2005 ppc64 GNU/Linux
[04:20] <BenC> sweet
[04:20] <BenC> ready to attempt to crash it? :)
[04:20] <BenC> cat /proc/drivers/rtc
[04:20] <jbailey> The only observation so far is that power mgmt is also a bit broken.
[04:21] <jbailey> The fans are slowly speeding up.
[04:21] <BenC> odd
[04:21] <jbailey> Should I be on the console for that? =)
[04:21] <BenC> yeah
[04:21] <jbailey> NO such file or directory
[04:22] <jbailey> mm
[04:22] <jbailey> driver singular.
[04:22] <jbailey> BenC: I got an oops, but no crash.
[04:22] <BenC> well, it's a start
[04:22] <BenC> can you email me the oops?
[04:22] <infinity> Did you actually get any output? :)
[04:23] <BenC> yeah, did any output come out, or did the cat process lockup?
[04:23] <jbailey> BenC: http://paste.ubuntulinux.nl/5190
[04:23] <BenC> well, it would have to get to the end of the proc function before the buffer was returned to the user
[04:23] <BenC> jbailey: thanks
[04:24] <jbailey> (Recovered from dmesg so I can just paste)
[04:24] <BenC> that's not what I expected
[04:25] <BenC> I was expecting to see rtc_get_rtc_time() again
[04:26] <BenC> heh, that can't be good :)
[04:26] <BenC> jbailey: thanks, I'll be able to do more with this dmesg now
[04:27] <BenC> maybe I'll have something you can test later, if you have time
[04:27] <jbailey> Apparently doing it a second time to see if there was any output crashes the machine. =)
[04:27] <BenC> at the very least, a little sprinkling of printk's to see where it actually oopses
[04:27] <jbailey> BenC: Cool.  I'll try to run anything I need long term in screen sessions on other machines. =)
[04:37] <jbailey> infinity: At some point when you're bored... ;)
[04:50] <infinity> ?
[04:50] <infinity> Not that that point is now, but I may want to plan for the future.
[04:51] <mjg59> Is usplash working for everyone now?
[04:51] <mjg59> And what magic does it need in its postinst?
[04:52] <infinity> a) Don't know
[04:52] <infinity> b) update-initramfs -u
[05:00] <mjg59> infinity: Is the 640x400 patch submitted yet?
[05:00] <mjg59> I want to shift to 640x400 artwork in the next usplash upload
[05:14] <infinity> Too focussed on making LRM work. :/
[05:14] <infinity> If yo uhave a tested patch, give it to BenC, otherwise I'll do mine tomorrowish.
[05:14] <jbailey> infinity: I have instruction here on making kdump work to store OOPS information when it happens.
[05:15] <jbailey> infinity: I collected it at OLS last year, and dug it up a couple days ago.
[05:15] <infinity> Though, you should be able to switch the artwork anyway, since artwork that's smaller than the fb isn't a problem.
[05:15] <mjg59> Yeah
[05:15] <infinity> (As evidenced by the tiny artwork in the middle of my massive vesafb)
[05:16] <BenC> usplash looks tiny on my readonfb at 1024x768
[05:16] <infinity> (What will happen with artwork that's bigger than the FB?... For people upgrading?)
[05:16] <BenC> anyway to scale usplash on higher resolutions? :)
[05:16] <infinity> BenC : Did you see it on my 1400x1050?
[05:17] <BenC> nah, hehe
[05:17] <infinity> Speaking of seeing things on my laptop, did you finally finish watching Family Guy and regain productivity? :)
[05:17] <BenC> I have about 10 episodes left to watch :)
[05:18] <mjg59> Also: usplash needs to check if the display is capable of 256 colours
[05:18] <infinity> mjg59 : I don't suppose that one daemonises (and removes the sleep from the init)?
[05:18] <mjg59> Nope
[05:18] <mjg59> I'll do that next time
[05:18] <infinity> Kay.  I'll do that the first time I touch it, then.
[05:18] <mjg59> Can you file a bug?
[05:18] <infinity> Unless you're on a warpath. :)
[05:18] <mjg59> Well, I'm in bed, ill
[05:19] <infinity> Which, obviously, leads to hacking graphical boot thingees.
[05:39] <lucasvo> hi
[05:41] <lucasvo> I would like to make a clustering system with upstream compatible Kernel for terminal server. What do you suggest?
[05:41] <mjg59> I have found scary ways of helping vesafb survive suspend/resume
[05:42] <BenC> lucasvo: I don't undetstand your question
[05:42] <BenC> terminal server and clustering conflict in my brain
[05:42] <lucasvo> BenC: I would like to develop clustering which may be included by ubuntu
[05:43] <BenC> what sort of clustering?
[05:43] <infinity> mjg59 : It always has done for me anyway.
[05:43] <lucasvo> if one uses powerful ltsp clients, one could use them for clustering
[05:43] <lucasvo> BenC: like openmosix
[05:43] <mjg59> infinity: Yeah, it doesn't here
[05:43] <BenC> mjg59: FYI, the fb-no-write patch is in -5.7
[05:44] <infinity> BenC : LRM has turned into a mauch larger headache than I'd originally hoped.  I'm going to go catch a 4 hour nap (It's 4am now) and finish up in the morning. :/
[05:44] <BenC> lucasvo: oh, you lost me, I don't do much with that sort of thing
[05:44] <mjg59> BenC: Thanks
[05:44] <lucasvo> BenC: ok
[05:44] <BenC> infinity: ok
[05:44] <BenC> lucasvo: but I still don't know what you are asking..."what do you suggest" is very vague :)
[05:45] <lucasvo> BenC: I need a clustering system which is accepted by ubuntu policy
[05:46] <BenC> we have ocfs2, but I'm not sure if that suits your needs, since it's only a clustering filesystem
[05:46] <lucasvo> BenC: exactly, I need RAM/CPU sharing
[05:46] <fabbione> lucasvo: we don't have that solution yet
[05:46] <BenC> and "accepted by ubuntu policy" is something you'll have to gain somewhere down the line, it's not something that can be decided before hand
[05:46] <fabbione> lucasvo: and probably won't
[05:47] <fabbione> lucasvo: what kind of clustering exactly are you looking for?
[05:47] <BenC> fabbione: what is the clustering thing that was talked about at UBZ?
[05:48] <fabbione> lucasvo: something like openmosix or a batch/queue/job scheduler?
[05:48] <BenC> some IBM thing
[05:48] <lucasvo> fabbione: yes, I want to make one for ubuntu
[05:48] <lucasvo> fabbione: yes
[05:48] <fabbione> lucasvo: yes it's not an answer to what i did ask :).
[05:48] <BenC> there's another guy wanting to do the same thing
[05:48] <BenC> and pretty much, he is having to do his work outside of ubuntu, in the hopes that he can prove its viability for dapper+1
[05:48] <lucasvo> fabbione: hm I didn't see the or
[05:49] <lucasvo> fabbione: I mean something like openmosix
[05:49] <fabbione> BenC: i don't remember talkign about IBM solutions really.. but we have something on the boilerplate
[05:49] <fabbione> lucasvo: no, we won't have openmosix or similar solution for some time
[05:49] <BenC> fabbione: maybe it was HP
[05:50] <fabbione> BenC: yeah HP
[05:50] <fabbione> openssi
[05:50] <BenC> lucasvo: email -devel about it and see if you can catch the attention of other people (and there are some) looking to do the same
[05:50] <lucasvo> fabbione: what I would like to do is to include a clustering system into ubuntu which is accepted by upstream
[05:50] <BenC> yeah, that's it
[05:50] <lucasvo> BenC: ubuntu-devel?
[05:50] <fabbione> lucasvo: https://wiki.ubuntu.com/UbuntuClusters
[05:51] <fabbione> lucasvo: most of solutions like openmosix are for 2.4 kernels only
[05:51] <BenC> lucasvo: yeah
[05:51] <fabbione> and we don't support 2.4
[05:51] <fabbione> porting to 2.6 is on the way but still at a too early stage to be even considered
[05:51] <lucasvo> fabbione: there is some 2.6 code at openmosix but it is not accepted by Linus 
[05:51] <BenC> as we discussed at the last Developers Summit, a group will have to develop this outside of ubuntu proper, and then seek inclusion, so I suggest getting on the bandwagon with people who want to do the same to avoid extra work and conflicts
[05:52] <fabbione> lucasvo: because the userland is broken.
[05:52] <fabbione> and the patch for 2.6 probably sucks
[05:52] <fabbione> BenC: exactly
[05:52] <BenC> lucasvo: accepted by upstream as in linus?
[05:53] <BenC> don't see that happening with many clustering systems
[05:53] <lucasvo> I mean this use case: Hospital delta is deploying hundreds of thin clients with Ubuntu and LTSP, and wants complete failover for the terminal services.
[05:54] <lucasvo> BenC: yes
[05:54] <BenC> it will get into ubuntu before it gets into kernel proper :)
[05:54] <fabbione> lucasvo: that's not an openmosix cluster
[05:54] <BenC> why the criteria for inclusion with linus?
[05:54] <fabbione> that's a HA cluster
[05:55] <lucasvo> fabbione: yes
[05:56] <lucasvo> fabbione: but I actually want HPC
[05:56] <fabbione> lucasvo: we don't have it and we won't for a while :) same answer as before. ;)
[05:57] <fabbione> lucasvo: we might be able to provide slurm (job queue scheduler)
[05:57] <fabbione> but that's it for dapper
[05:57] <lucasvo> fabbione: I am not talking about dapper more about dapper+ 1 or 2
[05:58] <lucasvo> fabbione: and I would like to develop it, I don't want out of the box solution
[05:58] <fabbione> lucasvo: from here to dapper+1 there are at least another 10 months.. perhaps by that time there will be available solution..
[05:58] <fabbione> who knows..
[06:08] <zul> hola fabbione 
[06:08] <fabbione> hey zul
[06:09] <BenC> yo zul
[06:10] <zul> hey benco
[06:11] <BenC> jbailey: ping
[06:17] <zul> ugh..this is an ugly website
[06:17] <zul> http://wwwredesign.gentoo.org/
[06:19] <fabbione> BenC: sparc is at dpkg-deb now :)
[06:20] <BenC> fabbione: sparc success will finally mean an upload went as planned :)
[06:20] <fabbione> ehehhe
[06:21] <BenC> goal for -6 is to disable all the drivers that have missing symbols (mostly smp and 64-bit incompatible drivers)
[06:22] <fabbione> yeah
[06:22] <fabbione> i saw a bunch
[06:24] <BenC> wow, linus tagged 2.6.15-rc3 just a mere 29 minutes after I tagged 2.6.15-5.7
[06:24] <BenC> my timing is improving :)
[06:25] <dilinger> heh
[06:25] <fabbione> ehhe
[06:25] <zul> slacker
[06:25] <zul> :)
[06:32] <zul> BenC: i wrote a patch for the atkbd last night its in my git archive
[06:32] <fabbione> zul: patch to do what?
[06:32] <zul> remove that unknown key bullshit
[06:37] <zul> fabbione: http://zulinux.homelinux.net/cgi-bin/gitweb.cgi?p=ubuntu-2.6.git;a=commit;h=1ec11f9bc0963516a9b944e43fb89fbf5545a27b
[06:40] <BenC> silly printk, warnings are for developers
[06:41] <fabbione> bah it's just a warning
[06:42] <fabbione> linux-source-2.6.15_2.6.15-5.7: successful
[06:42] <BenC> but it causes uneeded bug reports
[06:42] <BenC> sweet
[06:43] <BenC> cool, latest git has --no-merge for git-pull
[06:43] <BenC> so you can inspect before merging and committing
[06:44] <fabbione> eheh
[06:44] <fabbione> i didn't play with git that much
[06:44] <fabbione> i rely mostly on what you tell me
[06:44] <fabbione> + my ppc is down until i can unfuck partman-auto-lvm
[06:48] <zul> fabbione: i know but a user complained about it and its annoying the fuck out of me on my laptop
[06:48] <fabbione> BenC: 
[06:48] <fabbione> fabbione willy: i am cool with that.. ben is merging rc3 and i was wondering when we could pull from you.. i expect lamont wants that ;)
[06:48] <fabbione> willy fabbione: keep pulling from cvs
[06:48] <fabbione> ^^ hppa tree
[06:49] <BenC> fabbione: not only that, but even if we switch it to KERN_INFO, it will still cause uneeded fillage of kern.log (and clearing of the dmesg buffer)
[06:49] <BenC> fabbione: I'll leave it up to lamont to get me a diff from CVS
[06:50] <fabbione> BenC: is there actually anything that use that output? iirc we were using it to track kernel -> X -> gnome keyboard issues
[06:50] <fabbione> BenC: didn't you pull from hppa git once?
[06:50] <BenC> fabbione: yeah
[06:51] <fabbione> ok
[06:51] <lamont> BenC: once they finish the rc3 merge, I'll gen a diff
[06:51] <BenC> not sure about tracking the keys
[06:51] <fabbione> lamont: better if you push them to move to git :P
[06:52] <BenC> yeah, there's a freaking CVS tool fot git anyway :)
[06:52] <lamont> fabbione: the trick is to help them get the infrastructure git-happy, and then it'll happen... it's not that they don't want to move.
[06:52] <lamont> BenC: its the autobuild stuff, and such
[06:52] <BenC> ah
[06:52] <lamont> bunch of home-grown tools to do thing
[06:52] <lamont> s
[06:52] <fabbione> lamont: yeah i understand that...
[06:53] <BenC> I'm a little leary of taking a cold monolithic patch for hppa, if they will get around to being in git real soon
[06:53] <fabbione> that's exactly what i was thinking
[06:53] <BenC> maybe we can do what fabbione and I discussed and just run patch/unpatch for that one diff
[06:53] <fabbione> but you might endup duplicating the merge work
[06:54] <BenC> or I might be off by a line or two and cause uneeded deltas in our tree
[06:54] <fabbione> since they do it and you have to do it to pull in rc3
[06:54] <fabbione> perhaps talk with them and see how to handle it best?
[06:55] <lamont> gah. git-core goes through 0.99.9i, and then it's git_0.99.9j - wish they'd make up their mind
[06:56] <BenC> lamont: apt-get install git-core (from dapper universe)
[06:58] <BenC> fabbione: bah, git-core is not built for sparc yet! :)
[06:58] <fabbione> BenC: hmmm probably
[06:59] <fabbione> git-core:
[06:59] <fabbione>   Package             : git-core
[06:59] <fabbione>   Version             : 0.99.9j-1
[06:59] <fabbione>   State               : Needs-Build
[06:59] <fabbione> yeah
[06:59] <fabbione> ahhahahahah
[07:00] <fabbione> BenC: the universe buildd is almost at the end of gcc-snapshot
[07:00] <fabbione> that's probably why it didn't built yet
[07:00] <fabbione> and i did unleash the kde mess just today
[07:01] <fabbione> so the main buildd is like utterly busy
[07:01] <BenC> fabbione: FYI, if you have trouble finding an affordable ultra for the DC, I know where you can get UE 4500's for pretty cheap
[07:02] <fabbione> BenC: you should tell that to elmo/znarl.. but afaik they are looking into new hw
[07:02] <fabbione> it needs to be as small as possible (size wise)
[07:02] <fabbione> because we pay hosting by size
[07:02] <fabbione> but i am not sure 100%
[07:02] <fabbione> things keep changing on a daily base
[07:03] <BenC> yeah, the 4500 isn't small, but it's cheap and powerful
[07:03] <fabbione> yeah i know
[07:06] <fabbione> ok time to stop for today
[07:06] <fabbione> or better
[07:06] <fabbione> start cooking some real food
[07:16] <lamont> git push ssh://rookery.ubuntu.com/home/lamont/public_html/archives/ubuntu-2.6.git
[07:16] <lamont> bash: git-receive-pack: command not found
[07:16] <lamont> and grumbles, too
[07:16] <lamont> BenC: would you be so kind as to send RT a request to install git on rookery?
[07:18] <lamont> meanwhile, I've updated ~/.bashrc
[07:18] <BenC> on rookery, you can point to my git bin's
[07:18] <lamont> only if .bashrc says to
[07:27] <BenC> lamont: done
[07:27] <BenC> well, rt ticket sent, not installed yet :)
[07:30] <lamont> right
[07:30] <lamont> thanks
[07:30] <lamont> 'tis better coming from you, and all that.
[08:26] <CataEnry> bye all
[08:28] <zul> garrr...i hate batch files
[09:14] <mjg59> BenC: ACPI sleep support doesn't seem to be getting initialised on i386, for some reason
[09:15] <BenC> mjg59: ok, I'll look at it in a little bit
[09:17] <mjg59> BenC: Uhm. CONFIG_ACPI_SLEEP is missing
[09:17] <mjg59> On -686, at least
[09:22] <mjg59> BenC: Also, http://lkml.org/lkml/2005/11/29/74
[09:22] <mjg59> Can we grab that?
[09:25] <BenC> Kconfig shows "depends ... (!SMP ...)" for ACPI_SLEEP
[09:25] <BenC> I'll get that patch, sure
[09:25] <BenC> is suspend/resume not compatible with smp?
[09:38] <mjg59> I was under the impression it had been fixed
[09:38] <mjg59> But that may not have been merged yet
[09:40] <mjg59> BenC: If we can't fix that, then I guess we'll have to go back to UP kernels
[09:43] <BenC> I can do another pull from acpi git and see
[09:45] <mjg59> Looks like there were patches in April
[09:45] <mjg59> They may never have been merged
[09:46] <mjg59> The acpi git tree doesn't seem to have been updated in months
[09:55] <BenC> are you checking the right acpi branch?
[09:55] <mjg59> Hm. Which is the right one?
[09:55] <BenC> I'm using the "test" branch that -mm uses
[09:55] <mjg59> Ah
[09:56] <BenC> lamont: ping
[09:56] <mjg59> Yeah, last one there seems to be September
[09:58] <mjg59> The code isn't in -mm now. It was back in 2.6.12 time.
[10:02] <BenC> -mm is pulling from that test git branch is all
[10:04] <mjg59> Well, either we forward-port the stuff from 6 months ago, or we go back to shipping UP kernels
[10:10] <BenC> how large was the "works on smp" stuff?
[10:11] <BenC> a huge portion of the acpi stuff was already merged, so we can't just apply the acpi dpatch from breezy
[10:20] <mjg59> I don't know if we had it in Breezy
[10:20] <mjg59> And I can't find the patches nicely bundled anywhere
[10:23] <mjg59> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12/2.6.12-mm1/broken-out/ seems to be the latest ones
[10:23] <mjg59> Various patches from there are needed
[10:26] <mjg59> But it looks like there's runtime checks /anyway/
[10:26] <mjg59> So just force the !SMP for now?
[10:28] <mjg59> Hang on
[10:28] <mjg59> It looks like there's support for it
[10:29] <mjg59> BenC: Nngh
[10:29] <mjg59> BenC: Can you just turn on CONFIG_HOTPLUG_CPU?
[10:30] <mjg59> That ought to make it work
[10:38] <BenC> ok
[10:44] <dilinger> this machine loves to hang for 1/2 a second at random times since upgrading to breezy :/
[10:52] <BenC> lamont: ping
[10:52] <zul^> later folks
[11:11] <BenC> lamont: I got a hppa64-smp vmlinux
[11:11] <BenC> lamont: most of the breezy hppa patch was in the git, except the compat signal/siginfo stuff, which wasn't that much
[11:12] <BenC> I'll try to boot it shortly
[11:13] <lamont> oh, way cool
[11:13] <BenC> mjg69: enabled hotplug_cpu for amd64 and i386 targets, along with acpi sleep/suspend stuff
[11:20] <mjg59> BenC: Rock, thanks
[11:20] <mjg59> BenC: Does that break ABI?
[11:20] <BenC> doing an abi bump anyway, since I synced a lot from linus
[11:21] <mjg59> Ok
[11:21] <mjg59> Any ETA on uploading it?
[11:21] <BenC> lamont: do you have a breezy palo.conf I can look at?
[11:21] <BenC> mjg59: 2-3 days, depending on lrm and vga16fb patch
[11:21] <mjg59> Suspend/resume tends to show breakage at all sorts of inopportune moments, so it'd be good to get as much testing time as possible
[11:21] <mjg59> BenC: Ok, sounds good
[11:22] <BenC> just glad we could enable it without a lot of extra patching :)
[11:22] <lamont> BenC: yeah
[11:23] <BenC> and /etc/kernel-img.conf if you don't mind
[11:23] <BenC> my system is just a dist-upgraded woody box (really old)
[11:23] <lamont> btw, if you're so inclined, please enable BLK_DEV_IDEPCI, BLK_DEV_IDEDMA_PCI, and then BLK_DEV_NS87415 - fabbione and I will thank you
[11:23] <lamont> all hppa configs, as modules where appropriate
[11:24] <BenC> ok, I wont need those for my A500, right?
[11:24] <lamont> no, the NS87415 chipset is a PCI IDE chipset that is used for the J[57] 000 and others.
[11:24] <lamont> as well as some sparc64 machines.
[11:25] <lamont> so as it sits, I get to net-install J series boxen
[11:29] <BenC> sure thing
[11:33] <BenC> lamont: confs?
[11:36] <lamont> as in, you want me to make configs that I'm happy with and point you at them, yes?
[11:36] <BenC> or paste ones you already have :)
[11:36] <BenC> I'm not sure how to setup palo.conf for initrd and *.old stuff
[11:37] <lamont> ah, ok. we currently have kernel-package tweaked to default to initrd (instead of initramfs) for hppa/ia64, if that's what you mean
[11:38] <lamont> cat /etc/palo.conf 
[11:38] <lamont> --commandline=2/vmlinux root=/dev/sda5 initrd=2/initrd.img HOME=/
[11:38] <lamont> --recoverykernel=/boot/vmlinux-2.6.12-9-hppa32-smp
[11:38] <lamont> --init-partitioned=/dev/sda
[11:38] <lamont> that's what palo.conf looks like for me.
[11:38] <BenC> ok
[11:38] <lamont>  cat /etc/kernel-img.conf 
[11:38] <lamont> do_symlinks = yes
[11:38] <lamont> relative_links = yes
[11:38] <lamont> do_bootloader = no
[11:38] <lamont> do_bootfloppy = no
[11:38] <lamont> do_initrd = yes
[11:38] <lamont> link_in_boot = yes
[11:38] <lamont> both stock install results
[11:38] <BenC> thanks
[11:39] <lamont> the list I gave you above of BLK_DEV defines is the dependency chain to turn on NS87415, fwiw
[11:39] <BenC> yeah, already done in my git
[11:39] <BenC> so it will be in the next upload
[11:41] <lamont> thanks
[11:56] <BenC> lamont: here goes nothing...
[12:00] <BenC> hippo:~# uname -a
[12:00] <BenC> Linux hippo 2.6.15-6-hppa64-smp #1 SMP Tue Nov 29 16:26:27 EST 2005 parisc64 GNU/Linux
[12:01] <BenC> lamont: you can thank me with a beer at the next dev summit :)
[12:03] <lamont> YIPPEEE!!!!