Hmm. One of your users poked me for support this morning, with the following problem while attempting to build a fresh kernel. To quote him: --- make[3]: *** No rule to make target `drivers/char/speakup/makemapdata', needed by `drivers/char/speakup/mapdata.h'. Stop. make[2]: *** [drivers/char/speakup] Error 2 make[1]: *** [drivers/char] Error 2 make: *** [drivers] Error 2 kernel: 2.6.8.1 latest speakup, from checkout script. --- I'm a BSD user, and I'm bad enough with BSD make, but I did check out the repository and determine the Makefile was touched a few times in fairly-'recent' history... Unfortunately, this doesn't mean I'm clued enough to guess what it could be. (Would/could/should the fix of "host-progs-y to hostprogs-y" be the culprit? I'm not feeling like walking someone through trial-and-error with an unfamiliar system.) I'm also not sure what the ".1" in 2.6.8.1 could mean, but if this sounds like a bad 2.6 to try with, recommendation of a 'blessed' version might help. Meanwhile, as relates to the thread on cdcd... He's a Debian user, and I'm sure he's upgrading because of a bug we had with 2.4.24-1-speakup. Linux has apparently only switched to a CAM-like "ide-scsi" abstraction recently, and something about this, or changes in the ata driver and associated APIs, saw the system failing to send appropriate audio-playing commands to either of his CD drives, whether addressing the 'ide-scsi' nodes (/dev/srN) or the ATA hdX devices directly. To the user having trouble with "cdcd play" doing nothing, check your dmesg after a playback attempt for errors like "sr1: CDROM not ready. Make sure there is a disc in the drive," or "sr0: CDROM (ioctl) error." If those are present, it's likely the same bug; if not, and the disc can be heard spinning, perhaps you need to try the headphone jack on the front of the drive? At last check, there seemed to be some sort of confusion over which API should now be used to send the ATAPI(?) commands, effectively stranding the issue between the cdcd maintainers and the kernel developers. I had another user ask me about a similar issue with xmms (which may rely on the same underlying library), so it sounds like something systemic between software and certain revisions of 2.4. (Maybe compiling libcdaudio locally will produce a build that 'does the right thing?' I've yet to try this, or check to see if they have anything in their build process that would account for it at compile-time instead of runtime.) -Oh well. Thanks, for reading, hope someone can help! -Joe "Floid" Kanowitz cc:s appreciated, though I've subscribed to get this post through. My apologies if it shows up twice.
