[PlanetCCRMA] initial observations and broken packages

[Fernando Pablo Lopez-Lezcano]

> I just started playing with the Planet CCRMA acpi kernel on a fresh 
> 7.3 install, and I must say it's pretty cool.  The alsa stuff setup 
> was about the smoothest I've had so far.

Thanks and welcome to the planet, natives are said to be friendly :-)

> I had to configure/compile a custom kernel with an ethernet-usb 
> patch for my Sharp Zaurus.

I assume this is unrelated to your 7.3/Planet install right? (AFAIK the
Zaurus uses a StrongARM processor)

> The vanilla 2.4.19 patch applied okay, 
> except for one minor hand-edit fix.  I had a little trouble getting 
> the new kernel working; at one point last night I had a weird error 
> with mkinitrd (I boot off a scsi drive, so I need this).  I tracked 
> down the error to a supposedly missing loopback (block) device in 
> the kernel.  Is this enabled on the stock kernels provided?  It may 
> have been some kind of transient glitch, since I rebuilt the kernel 
> again tonight, and mkinitrd worked fine.  Go figure...

Strange, the loopback device is enabled in the kernel (I have a few scsi
machines that use this kernel). I sort of remember seeing this happen
some time ago, but I can't remember what was the reason (although I do
remember I sort of figured it out). 

> I also had another build error with a kernel include file (this was 
> a biggie).  I traced it down to a somewhat ugly hack in the 
> filesystem partition code here:
> 
> /usr/src/linux/fs/partitions/efi.h
> 
> where there's an include for an ia-64 header file:
> 
>   /*
>   * Yes, specifying asm-ia64 is ugly, but this lets it build on
>   * other platforms too, until efi.h moves to include/linux.
>   */
> #include <asm-ia64/efi.h>
> 
> Well, for me, it didn't build at all, since the typical redhat 
> kernel source only includes the i386 headers (including Planet 
> CCRMA).  I couldn't seem to make it build, so I grabbed the asm-ia64 
> files off my Gentoo box (which uses a *really* plain vanilla 2.4.19 
> kernel, and includes headers for all architectures).

So this is building by doing a rpm -ba on a pentium machine? That works
for me here, or was this for the rebuild of the Zaurus kernel? (it is
unclear to me whether you are trying to run Planet CCRMA on the Zaurus..
that would be certainly cool :-)  

> Once I got the kernel to build, I tried installing the alsa drivers, 
> but they wouldn't install on the new kernel (since redhat tags your 
> new kernel with a 'custom' tag on /lib/modules, etc).  So I tried 
> building the alsa-driver src.rpms (version 0.9.0-37), however, the 
> bzip-tar file inside the rpm is broken (i kept getting an error 
> during the unpacking phase).

It seems to work for me here (on a 7.2 machine). Doing an rpm -Uvh
alsa-driver-0.9.0-37.src.rpm installs without a problem. Maybe a bad
download? (unlikely, but not impossible to happen). 

> I ended up using the get-cvs script, which retrieved the current 
> source (as of a couple of hours ago).  Then I hacked the spec file 
> to build the new cvs source.  I finally have my new kernel with 
> sound and the Zaurus driver.  Cool!
> 
> Except I don't understand why there are so many alsa src.rpm files? 
> (and why is the driver src.rpm broken)  Shouldn't all the rpm 
> binaries be built from a single source rpm?  All the alsa source 
> (for everything) is in each rpm, which seems like a waste...

It is. The reason for the different src rpms is that you need to install
the driver binary rpms before building the lib rpms, and you have to
install the lib binary rpms before building the utils. You can't do that
with a single src rpm (hmm, of course it would be possible to have a
single src rpm and switches that control which package gets built). The
reason the exact same source is included in all src rpms (the origin of
the wasted space) is historical and predates by a long time the
availability of the packages on the web (Planet CCRMA is merely a
reflection of the environment I've been mantaining here at CCRMA for
quite a while). It is not hard to fix, I guess, I've been lazy :-)

> Anyway, I only built/installed the latest driver source (and not any 
> of the utils, etc) but it seems to be working fine so far (using the 
> cmpci driver).
> 
> You might want to fix the above glitches, but otherwise it seems 
> pretty cool.  I *do* like apt-get; 

Yes, it is what has made the Planet CCRMA package repository reasonably
easy to use. 

> I just wish there were a few more 
> packages (like Eterm) nad maybe a few more apt-enabled sources.  I 
> even added the tux-family and fresh-rpms to sources.list, but I 
> still didn't pick up eterm or enlightenment.  Oh well...

I could add Eterm, I do have it installed here at CCRMA (but not in the
Planet repository yet). Enlightment might be more difficult since it
would need to be integrated with the desktop switching tools and I don't
know what that entails...

-- Fernando