Re: Need .config files for Debians kernel-image-2.4.24-mips(el)
Guido Guenther <agx@debian.org> writes:
> removing linux-mips.org from the cc: list, since this is actually Debian
> stuff.
>
> On Tue, Jan 20, 2004 at 05:23:39PM +0100, Goswin von Brederlow wrote:
> > I saw that and am updating it. I was planing of sending you a patch
> > when its done and working. If you feel your time is running short
> Please be _very_ carefull. Just updating to .24 won't help. It's broken
> on almost all subarchs relevant to Debian.
>
> > Is the kernel-patch-2.4.22-mips relative to the debian kernel source
> > or the vanilla source? And is the result (after patching) the mips cvs
> > or cvs merged with the debian patch? And should that be done that way
> > again?
> We build against kernel-image-2.4.x debian package but we diff against
> linux-mips.org CVS.
Ok, thats what I have now too. I run into problems with loadkeys and
made a one line patch for it (--mktable turns on quiet implicitly). If
the console-tools maintainer doesn't go for that the kernel makefiles
should be changed to add "-q" for the loadkeys call. Maybe that should
be done just in case anyway.
> > Apart from updating the patch (vanila->mips cvs, testing if it gives
> > any conflicts now) I added my own system XXS1500 board from MyCable to
> > the configs and added the kernel-image deb and udebs to the control
> > file. No major changes yet.
> That's no big deal. Updated configs are very welcome as long (and as
> they are not mips64 since we don't build these by default yet).
The defconfig-xxs1500 looked very good so I just copied that. I
checked for all the essential options but haven't checked every
thing. But I don't think it needs much refining, its a pretty limited
hardware for the system.
> > Have you thought about dropping the udebs and letting debian-installer
> > build -di udebs the way it does for several other arches now?
> What would this buy us?
> -- Guido
D-I splits a kernel-image with modules into several udebs according to
what modules are wanted and module dependencies. It uses the same
package nameing scheme for all architectures and subarchs and has the
same contents (as far as its available and usefull) in each udeb.
If all archs use the same scheme the architecture independent package
lists can contain the kernel packages instead of each architecture
having its own copy with minor differences.
Once I get the 2.4.24 kernel images build I will look into creating
the d-i kernel udebs from that. They can easily coexist for the time
being and once they have been tested the old ones can be discontinued
if you choose so.
An advantage of having the d-i kernel udebs would be that they are
created when d-i cd/net images are made and kept in the same version
untill new ones are required. With the current udebs an kernel update
would mean that users can't rebuild the d-i cd/net images as they
are. But thats just a minor advantage. The unified nameing scheme is
more important I think.
MfG
Goswin
Reply to: