Re: Uploaded kernel-package 3.38 (source all) to master
Manoj Srivastava wrote:
> [snip]
> >>"Mrvn" == Goswin Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
>
> Mrvn> - Adding all arch specific files and patches of each arch to the package
>
> Umm, no, no actual kernel code ever goes into kernel-package;
> people are encouraged instead to issue kernel-patch-m68k (or
> whatever) packages conforming to the scheme outlined below.
Thats fine with me, but every now and then somebody complains about the
number of packages increasing. Maybe it would be a good idea to have
them in one package, the diffs should be so few KB.
What I ment with the above was that the arch/m68k files from the
linux-m68k kernel should go into the main kernel source, cause the m68k
Source is the upstream Source for that. Whereas any changes the
linux-m68k made to other files not in arch/m68k should go into the diff.
The reason is that the arch/m68k files should not break anything, and if
they do it's not their fault, whereas on other files the risk of
breaking something is high. This also benefit the merging back of the
patches into the mainstream kernel which should be the goal we are
working towards.
> Mrvn> - Makeing a diff for all changes to common files or files from different
> Mrvn> archs.
>
> Making separate patches for each architecture? I didn't quite
> understand the sentence above.
Only the files not from /arch/<arch> should be in the diff, all others
should be merged into the kernel Source. see above.
> Mrvn> - Have the diff for the arch aplied to the source during installation
> Mrvn> ( - have a command to remove a diff or add a diff to the source [make
> Mrvn> m68kdiff or make m68kundiff )
>
> I went with the patch suppliers putting a shell script in
> a well known directory. That way, people can put in tests (grab the
> kernel major and minor version from the Makefile, and abort if
> necesary, or ensure compatibility with patches being applied at the
> same time). Please look at the example patch scripts in the proposal;
> I think you'll like them.
The script looked good, also I had only a glance on it.
> [snip]
> ============================================================
> #! /bin/sh
> set -e
> PATCHNAME=<patch name or number>
> PATCHDIR=/usr/src/kernel-patches/$ARCHITECTURE
>
> if ! test -d kernel -a -d Documentation ; then
> echo "Not in kernel top level directory. Exiting" >&2
> exit 1
> fi
>
> ARCHITECTURE=`dpkg --print-installation-architecture`
> VERSION=$(grep ^VERSION Makefile 2>/dev/null | \
> sed -e 's/[^0-9]*\([0-9]*\)/\1/')
> PATCHLEVEL=$( grep ^PATCHLEVEL Makefile 2>/dev/null | \
> sed -e 's/[^0-9]*\([0-9]*\)/\1/')
> SUBLEVEL=$(grep ^SUBLEVEL Makefile 2>/dev/null | \
> sed -e 's/[^0-9]*\([0-9]*\)/\1/')
>
> PATCH_VERSION=$(patch -v | head -1 | sed -e 's/[^0-9\.]//g')
>
> if dpkg --compare-versions $(PATCH_VERSION) >= 2.2
> then
> PATCH_OPTIONS= -l -s -z -p1
> else
> PATCH_OPTIONS= -l -s -b -p1
> fi
>
> if test -f debian/APPLIED_$ARCHITECTURE_$PATCHNAME ; then
> exit 0
> fi
>
> patch -R $PATCH_OPTIONS < $PATCHDIR/$PATCHNAME
> echo "Removing empty files after patching" >&2
> find . -type f -size 0 -exec rm {} \; -print
> touch debian/APPLIED_$ARCHITECTURE_$PATCHNAME
> exit 0
The asm link (and any other links) should be corected as well. (Does
make menuconfig/config/xconfig set asm right?)
It should also be possible to include a patch from a different
architekture with the help of the script so one can test if it braeks
anything.
For this the script (sniped from below) is also important, cause if it
breaks or after testing people want their original source back.
>[snip]
May the Source be with you.
Mrvn
PS: I'm looking forwar to have a Debian Kernel build from Debian Source
instead of the watchtower kernel I'm using now. (Even if the only
difference is the Version string saying Debian) :)
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . Trouble?
e-mail to templin@bucknell.edu .
Reply to: