Our friendly X-developer, Branden, wrote: (gee, how do I write that so it doesn't sound like something from Marvel comics?)
> --rwEMma7ioTxnRzrJ > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > I've got a patch that successfully fixes the too-clever hack in libXft > involing va_lists. > However, unfortunately, some things in the XFree86 tree (the Wacom input > module, at least) build differently on kernel 2.4 systems than they do on > 2.2 systems. More to the point, building xf86Wacom.c flat out fails on 2.4 > boxen. > Dan Jacobowitz has suggested that I force XFree86's idea of the installed > OS version to 2.2 instead of trying to autodetect it. I'd like to ask _what_ it sees as being different about kernel 2.4 from kernel 2.2. Just guessing from the fact that it's an input device, and in a generic sense the input layer has changed on 2.4 systems than on 2.2 systems... except there's a bigger catch: Many people here on this list are using versions of the 2.2 kernel with the relevant input sections of the 2.4 kernel's source "backported" to it, so that they have a 2.4-like input layer. I'm one of those people. Due to various constraints, users of newer Mac hardware will probably be either using a 2.2 kernel with backported stuff or a 2.4 kernel. > Can anyone see any potential hazards with doing this? > > CC'ing BenC because he maintains the kernel headers provided by glibc. I didn't cc: anyone because you didn't want any cc'd replies, I thought. If you want to forward this message to anyone, go ahead. > In other news, the donated B&W G3 showed up, but I am having difficulty > partitioning it. mac-fdisk is not the world's friendliest tool! I'm sure > the folks on #debian-devel can get me going, though. There's a really nifty tutorial for mac-fdisk (or whatever else you're supposed to be using) at Ethan Benson's web site, at http://www.alaska.net/~erbenson. The long and the short of it is, you'll have to work out the size of your combined linux partitions; don't forget the bootstrap partition! Then use MacOS's partitioner to create a single partition that size ahead of your planned MacOS partition(s), if any. You then boot your linux CD, go into mac-fdisk, delete the big placeholder partition, and create a bunch of partitions where it was, starting with the bootstrap partition (which must be hfs, not hfs+, and about 800k. Again, see the web site for the instructions, including details on mac-fdisk.) I've found that having MacOS present on the hard drive can be a help if one accidentally screws up the yaboot.conf on the bootstrap partition so that you can't boot the Linux partition to fix the yaboot.conf there, BTW. Yes, it's inelegant, but I think you've noticed by now there's no place to stick a rescue floppy in the machine. You can use the CD if things get that bad... Anyway, I have to go. I hope that helped. (Maybe it would help if some of us pitched in and donated memory for one of the machines, so you would have faster compile times? I think we should discuss this before I'm broke again). Phil [EMAIL PROTECTED]
