[PlanetCCRMA] Re: initial observations and broken packages

[Steve Arnold]

Fernando Pablo Lopez-Lezcano wrote:

> I said:
>>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)

I needed to patch the desktop 7.3/Planet kernel with the 
usb-ethernet driver for the Zaurus cradle.

>>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 :-)  

No (the Z has no FPU, and thus sucks as an audio platform - maybe 
the newer xscale chips are better) and no.  In order, I updated the 
RH7.3 install kernel with the Planet CCRMA acpi kernel rpm (and 
installed and configured the alsa drivers; everything worked fine). 
  Then I had to install the Planet CCRMA acpi kernel source package, 
manually apply the usb-ethernet patch (see above) and configure and 
build a custom kernel.

So I do:

rpm -ivh kernel-source-x.rpm
make xconfig; make dep; make clean; make bzImage, etc.

The kernel build failed without the asm-ia64 headers.  I've been 
building RedHat kernels since 1.2.13, all the way through 2.4.18-x 
(and now 2.4.19) and I've never seen this happen before.  I couldn't 
seem to make it build without actually putting back all the ia64 
header files (from my Gentoo box) that RedHat takes out.

Side-note: I always seem to need a custom kernel, for the Zaurus, 
and for several other drivers either not in the current 2.4.x kernel 
source, or not new enough in RedHat's kernel.  This includes a usb 
Wifi card and the latest lm_sensors package, which I'll tackle 
shortly.  I also usually cut out several sections of kernel modules 
that I don't need, such as ISDN, telephony, etc.  But I always go 
for ACPI, usb, v4l, my SCSI and ethernet cards, etc.

>>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). 

After building and installing the above kernel and modules, I tried 
re-installing the alsa-driver rpms (the binaries).  But because of 
the redhat custom kernel naming scheme, the planet CCRMA alsa 
packages ignore the new kernel modules dir and install to the old 
one.  So I tried building the alsa-driver-x.src.rpm instead:

rpm --rebuild alsa-driver-x.src.rpm

but that died while it was still unpacking the source (corrupted 
header error).  So I tried the other way:

rpm -ivh alsa-driver-x.src.rpm
cd /usr/src/redhat/SPECS
rpm -bb alsa-driver-x.src.rpm

but that also died with the same error while unpacking the tar.bz2 
file inside the rpm (so the rpm was not corrupt, but the bzip-tar 
file inside was damaged somehow).  So I did what I described below, 
and all the bzip-tar files created by your get-cvs script were fine.

>>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...

Enlightnement doesn't care about switchdesk, at least not E 16.5 
(the rpm doesn't even have a gdm session entry).  I added one 
myself, but I guess the default way to start E (after installing 
from the rpm) is the old startx way.

It would be easy to make an apt-get rpm package for e-16.5, but 
there are some dependencies (mostly there on redhat).  Stuff like 
fnlib, imlib, freetype, etc.  I might have time to help you with 
that in the next week or two...

I probably didn't explain myself compeletely, but I think there are 
several package issues with the kernel-source and alsa driver 
packages that need to be fixed.  I'll post another message with a 
summary of my issues (hopefully tonight).

Thanks, Steve