Re: Debian kernel maintainter takeover
On Mon, May 17, 2004 at 10:02:03AM +0200, Andreas Barth wrote:
> * Francesco P. Lovergine (frankie@debian.org) [040517 09:55]:
> > On Sun, May 16, 2004 at 09:34:46AM +0200, Andreas Barth wrote:
>
> > > One other change I'd like to see ASAP is to having a "first class
> > > architecture set" instead of a individual kernel for i386 and alpha
> > > (and possible more to add to this).
>
> > Could you please explain this better? What's s first class arch set?
>
> see http://lists.debian.org/debian-devel/2004/04/msg06531.html for an
> explanaition.
Oh... how come I've never seen this before? I thought I subscribed to
debian-kernel.
Guess it is time I introduce myself, I am a second class kernel maintainer,
neat title, right? Or maybe m68k has already been promoted to third class?
What comes after third class, general kernel maintainer???
I don't know why everybody is picking on m68k, let me try to explain the
kernel situation, I don't think it is that bad for m68k (except for the fact
that 2.4 is not working on macs currently, and maybe never will). When I
create a new kernel-patch for m68k, I am just merging the changes from
linux-m68k CVS which have not been accepted upstream yet. Geert is usually
pretty good at sending patches to Linus, but some are just not accepted for
whatever reason. This makes up the largest part of the m68k patch. The rest
consists of typos introduced by the debian kernel maintainer which are
introduced in m68k drivers, typos in linux-m68k CVS (which usually appear in
CVS pretty soon), and some changes in drivers I make to support my hardware
better, but those patches are ony shipped, not applied to the standard
kernel builds. Those patches all apply easily to the debian kernel source, I
haven't checked for conflicts with other arches though, what do we do when
two arches have different patches for one driver? And I forgot one patch,
ARCH and CC in the main Makefile are patched for m68k, ARCH is predefined to
m68k, might work without this, but only if you don't cross compile, with CC
I have my doubts that other arches want to use gcc272 for 2.2.x, gcc-2.95
for 2.4.x. What are the plans for conflicting patches?
I have been working on combining all m68k kernel-image packages into one, I
guess I could even merge the kernel-patch and kernel-header package into
this one package. The big drawback is, it will take a long time to build
one big package. If I have a new patch to fix one driver for one subarch,
it does not make sense to rebuild the kernel-images for the other five
subarches as well, but if security requires this, we could do it. Of course
it might be faster if we would run individual kernel builds on three
machines, but if it is urgent, I could always switch back to indivual image
builds.
So my biggest problem is (besides from some packaging problems I still have
with six kernel-images), how are conflicting arch specific patches going to
be handled?
...and when will there be a kernel-source-2.2.26?
Christian
PS do I get a "2nd class kernel maintainer" sticker?
Reply to: