diff mbox

Building testing kernels

Message ID 1296818478.2240.16.camel@herton-IdeaPad-Y430
State Not Applicable
Headers show

Commit Message

Herton Ronaldo Krzesinski Feb. 4, 2011, 11:21 a.m. UTC 
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(-)

Comments

Tim Gardner Feb. 4, 2011, 1:42 p.m. UTC | #1 
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
Stefan Bader Feb. 4, 2011, 6:41 p.m. UTC | #2 
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
Herton Ronaldo Krzesinski Feb. 4, 2011, 6:51 p.m. UTC | #3 
Em Sex, 2011-02-04 às 19:41 +0100, Stefan Bader escreveu:
> On 02/04/2011 02:42 PM, Tim Gardner wrote:
> > 
> > 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.

I noticed that most of time I think users will have to install with dpkg
anyway the .deb packages, as new kernel versions appear or you dont
upload a meta package to auto update, so indeed a personal directory
should do almost the same.

> 
> That way there can be individiual packages per bug.

Can't you create more than one ppa, to have a per bug set?

> 
> -Stefan
>
Kamal Mostafa Feb. 4, 2011, 6:51 p.m. UTC | #4 
On Fri, 2011-02-04 at 09:21 -0200, 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?

Hi Herton-

FWIW, I do usually publish my test kernels as PPA's, but I know that
some of our other developers often just distribute binary .debs from
their public web directories.

I also found the kteam-tools script for building PPA's to be too stale,
and more complex than necessary.  I build my kernel PPA's using
'debuild' with a relatively simple procedure.  I think of this as the
minimal set of steps to construct a kernel source package for upload:

        edit debian.master/changelog: add new "+kamal~whatever" entry
        cp debian.master/changelog debian/changelog
        abi-disable  {various versions of this script exist}
        debuild -S -I -i

Notes on that sequence:
- The 'cp' is needed to get the proper version string to appear in uname
  (even though the cp also occurs at some point during the debuild, it
  happens too late).

- You may or may not actually need to disable the ABI check (and modules
  check) but I always disable them for my test kernel builds -- nothing
  is worse than waiting 7 hours for Launchpad to build your PPA only to
  have it choke on the ABI check in the final moments.

Hope that information is useful!

 -Kamal
Kamal Mostafa Feb. 4, 2011, 7:03 p.m. UTC | #5 
On Fri, 2011-02-04 at 19:41 +0100, Stefan Bader wrote:
> 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.

On Fri, 2011-02-04 at 16:51 -0200, Herton Ronaldo Krzesinski wrote:
> Can't you create more than one ppa, to have a per bug set?

Yes you can!  You can make separate PPA's for each bug (or at an even
finer granularity if you like)  I do this all the time.

I very much prefer to use PPA's than to distribute my test kernels as
binary .debs...

First, the PPA system offers me (as a developer) an important measure of
protection that binary .deb's do not offer:  If a user installs a
binary .deb that I put up for download, and then the next day some awful
thing happens (their system eats itself, or they get attacked by a
hacker, or whatever) the user might be inclined to accuse me of having
planted some badness in that binary kernel.  By contrast, if I've
distributed it as a PPA, then the source that (provably) built the
kernel is right there for inspection -- I could easily prove that I had
not planted any badness in their kernel.

Second, if I were to get hit by a bus, having uploaded to a PPA would
protect my work from being lost.

PPA's are good.  The only down-side is the long build times.  (I always
build binary packages first on tangerine for my own hack-test-hack
cycle, but then when I'm ready to publish, I upload to a PPA).

 -Kamal
diff mbox

Patch

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