Building testing kernels
Stefan Bader
stefan.bader at canonical.com
Fri Feb 4 18:41:33 UTC 2011
On 02/04/2011 02:42 PM, Tim Gardner wrote:
> On 02/04/2011 04:21 AM, Herton Ronaldo Krzesinski wrote:
>> Hi,
>>
>> what's the common used way to provide test kernels for users to test, is
>> it fine to use ppa in launchpad?
>>
>> Yesterday I started playing with ppa/building packages, and found that
>> we have on kteam-tools a script to build ppa packages more or less with
>> everything sorted out, build-mkppa
>>
>> But I found some problems, when trying to build a ppa for maverick's
>> kernel, using build-mkppa:
>> - It got confused by some tags in ubuntu maverick git repository, as abi
>> in them had a higher number than the last released mavericks kernel, it
>> thought that last kernel was Ubuntu-2.6.35-903.21, while the last one is
>> Ubuntu-2.6.35-26.46. I ended up removing all Ubuntu-2.6.35-90?.* tags to
>> overcome this.
>> - build-mkppa looks outdated compared with build procedures of today,
>> not knowing about debian.master in current repo. I fixed this along
>> another little nits, and then was able to build sources for a ppa.
>>
>> I created a kteam-tools repository to provide the fixes under my
>> account, please check and see if they are ok, if yes here is the pull
>> request:
>>
>> The following changes since commit 94116bd51b2b27829ea4edc517ffefc8e147d9ec:
>>
>> Added regular expression which can be used by other code. (2011-02-02
>> 14:58:10 -0800)
>>
>> are available in the git repository at:
>> ssh://kernel.ubuntu.com/srv/kernel.ubuntu.com/git/herton/kteam-tools fixes
>>
>> Herton Ronaldo Krzesinski (4):
>> Trivial typo fix in build-mkppa
>> build-mkppa: change default PPAEXT to "ppa"
>> build-mkppa: abort if git am fails
>> build-mkppa: make sure we use proper debian master directory
>>
>> buildscripts/build-mkppa | 48 ++++++++++++++++++++++++++++-----------------
>> 1 files changed, 30 insertions(+), 18 deletions(-)
>>
>> diff --git a/buildscripts/build-mkppa b/buildscripts/build-mkppa
>> index 2e0b89b..8bed21b 100755
>> --- a/buildscripts/build-mkppa
>> +++ b/buildscripts/build-mkppa
>> @@ -30,7 +30,7 @@
>> # DEBEMAIL: Those two environment variables (exported) are used by dch to
>> # set the email address and the name of the maintainer.
>> #==============================================================================
>> -PPAEXT=smb
>> +PPAEXT=ppa
>> if [ "$PPADIR" = "" ]; then
>> PPADIR="../$(basename $(pwd))-ppa"
>> fi
>> @@ -106,12 +106,14 @@ while [ $# -gt 0 ]; do
>> esac
>> shift
>> done
>> +DEBIAN=$(debian/rules printdebian)
>> +[ -n "$DEBIAN" ] || DEBIAN=debian
>>
>> #
>> # If this is missing, there is really something odd.
>> #
>> -if [ ! -f debian/changelog ]; then
>> - echo "debian/changlog not found!">&2
>> +if [ ! -f $DEBIAN/changelog ]; then
>> + echo "$DEBIAN/changelog not found!">&2
>> exit 1
>> fi
>> DIST=$(awk '
>> @@ -123,7 +125,7 @@ DIST=$(awk '
>> exit
>> }
>> }
>> -' debian/changelog)
>> +' $DEBIAN/changelog)
>>
>> case $DIST in
>> dapper|hardy|jaunty|karmic|lucid|maverick)
>> @@ -216,9 +218,17 @@ fi
>> # If one of the patches is marked "BumpABI: yes", then bump the ABI later.
>> #
>> BUMPABI=false
>> +applied=0
>> if [ -r "$PATCHDIR/series" ]; then
>> for i in $(cat $PATCHDIR/series); do
>> git am $PATCHDIR/$i
>> + if [ "$?" -ne 0 ]; then
>> + git am --abort
>> + [ "$applied" -eq 0 ] || git reset --hard HEAD~$applied
>> + echo "Aborted as one of the patches doesn't apply"
>> + exit 1
>> + fi
>> + let "applied++"
>> if [ "$(GetPatchTag BumpABI "$PATCHDIR/$i")" = "yes" ]; then
>> BUMPABI=true
>> fi
>> @@ -305,13 +315,14 @@ awk '
>> !silent{
>> print
>> }
>> -' debian/changelog>debian/changelog.$$&& \
>> - mv debian/changelog.$$ debian/changelog
>> +' $DEBIAN/changelog>$DEBIAN/changelog.$$&& \
>> + mv $DEBIAN/changelog.$$ $DEBIAN/changelog
>>
>> -dch -b -v"$PPAVER" -D"$DIST" "!!!PLACEHOLDER!!!"
>> +dch -c $DEBIAN/changelog -b -v"$PPAVER" -D"$DIST" "!!!PLACEHOLDER!!!"
>> awk -vTEXT="$CHANGES" '/!!!PLACEHOLDER!!!/{print TEXT; next} {print}' \
>> - debian/changelog>debian/changelog.$$&& \
>> - mv debian/changelog.$$ debian/changelog
>> + $DEBIAN/changelog>$DEBIAN/changelog.$$&& \
>> + mv $DEBIAN/changelog.$$ $DEBIAN/changelog
>> +[ "$DEBIAN" = "debian" ] || cp -f $DEBIAN/changelog debian/changelog
>>
>> #
>> # Update the debian control file
>> @@ -322,7 +333,8 @@ debian/rules debian/control.stub>/dev/null
>> # Stupid ABI check possibly wants stuff
>> #
>> LASTFULLVER=$VER-$LASTRELEASE
>> -if [ -d debian/abi ]; then
>> +debian/scripts/misc/getabis $VER $LASTRELEASE
>> +if [ -d $DEBIAN/abi ]; then
>> #
>> # No kABI files for the last release. If there is a tarball
>> # that provides those relative to the kernel top level dir,
>> @@ -331,27 +343,27 @@ if [ -d debian/abi ]; then
>> if [ -f $PPADIR/abi-$LASTFULLVER.tar.gz ]; then
>> echo "Found and use $FULLVER tarball."
>> tar -xzf $PPADIR/abi-$LASTFULLVER.tar.gz
>> - git add debian/abi/$LASTFULLVER
>> + git add $DEBIAN/abi/$LASTFULLVER
>> fi
>> - if [ ! -d debian/abi/$LASTFULLVER ]; then
>> + if [ ! -d $DEBIAN/abi/$LASTFULLVER ]; then
>> #
>> # If the directory is still missing, there was no tarbal.
>> # Maybe the files from an older release are there.
>> #
>> - if [ ! -d debian/abi/$LASTFULLVER ]; then
>> + if [ ! -d $DEBIAN/abi/$LASTFULLVER ]; then
>> echo "WARNING: No kABI files for $LASTRELEASE!!!"
>> - LASTRELEASE=$(ls -1 debian/abi|tail -1|cut -d- -f2)
>> + LASTRELEASE=$(ls -1 $DEBIAN/abi|tail -1|cut -d- -f2)
>> if [ "$LASTRELEASE" = "" ]; then
>> echo "Unable to continue!">&2
>> exit 1
>> fi
>> echo "Using $LASTRELEASE instead. Hope this works..."
>> echo "Generate ABI modules files..."
>> - cp -r debian/abi/$VER-$LASTRELEASE \
>> - debian/abi/$LASTFULLVER
>> - echo $ABI>debian/abi/$LASTFULLVER/abiname
>> + cp -r $DEBIAN/abi/$VER-$LASTRELEASE \
>> + $DEBIAN/abi/$LASTFULLVER
>> + echo $ABI>$DEBIAN/abi/$LASTFULLVER/abiname
>> fi
>> - git add debian/abi/$LASTFULLVER
>> + git add $DEBIAN/abi/$LASTFULLVER
>> fi
>> fi
>>
>>
>
> This truly a stale script. We've been using the abstracted debian directories
> for a good while now. Your changes look fine.
>
> Stefan - you wrote this, what do you think?
>
> rtg
Sadly it is _very_ stale. I wrote them quite early when I started and have not
used them for ages now. I would probably rather remove them.
In the beginning I thought it to be a good idea to use ppas. But for test
kernels it is rather bad as there only ever is one current version. For test
kernels it turned out to be better to just build generic packages for amd64 and
i386 and put those into a directory on people.canonical.com.
That way there can be individiual packages per bug.
-Stefan
More information about the kernel-team
mailing list