On Fri, Aug 06, 2004 at 10:33:37AM +0200, Jens Schmalzing wrote: > > If you just replace the patch, you will break the path between the > first and the second revision, because you get:
So when I want to create an updated patch, I need a tree with the first patch applied, a tree with the second patch applied, plus an upstream tree and a linux-CVS tree where I get my m68k patches from, all unpacked? I know Herbert explained this before, but I did not get it. Why does the kernel-source package change at all, I though it is uploaded only once for every upstram version and the rest goes in patches. I am sure this is a very clever trick to achieve something great, but I still do not see what. Do you have any tools that help you in preparing updated patches? Is this explained somewhere so that non-IT professionals can understand it? I know, it was all on the list, in bits and pieces, one single document to read would be nice. But don't worry about m68k screwing up your system, we still do not have 2.6.x kernels. I just managed to build all seven 2.4.26 images from one source package, I guess every arch maintainer has to design his own system for that, or do we have a best practices document somewhere? I guess it will work for 2.6.x as well, but now all kernel images for all arches should be built from one source package? As Sven(?) said yesterday, it is a waste of CPU cycles to rebuilt on all arches if one powerpc driver is fixed. Thats why I'd like to keep a kernel-patch-m68k package around, also for those m68k specific patches that can not be included in the debian patch package. Unless somebody convinces me to do otherwise. I can do tests with a cross compiler now, which is reasonably fast. I'd hate to run a test build for days on the real hardware... any hints, skeleton rules are welcome. Christian
