On 09/08/11 12:44, Dave Reisner wrote:
On Tue, Aug 09, 2011 at 08:35:35AM +1000, Allan McRae wrote:
On 09/08/11 08:18, Dan McGee wrote:
commit 1a919a11b85cb882bf5e632036a9030e4a98aba0
Author: Dave Reisner<[email protected]>
Date:   Mon Aug 8 17:20:53 2011 -0400

     makepkg: ignore epoch when undeclared

     In this case, we skip the epoch versioning entirely, as if it were
     declared as 0.

     Prevents errors such as:

     /usr/bin/makepkg: line 244: ((: !  : syntax error: operand expected
     (error token is " ")
     ==>   Finished making: cower-git :20110808-1 (Mon Aug  8 17:17:27 EDT
     2011)

     Signed-off-by: Dave Reisner<[email protected]>
     Signed-off-by: Dan McGee<[email protected]>



How do you ever get that?

# set defaults if they weren't specified in buildfile
pkgbase=${pkgbase:-${pkgname[0]}}
epoch=${epoch:-0}

So epoch should always be set...   perhaps the real bug should be fixed.

Allan


Well, we're clearly inconsistant about it. I show some calls to
get_full_version returning epoch as 0 and some returning epoch as a null
string. It leads to a pkgver that's could possibly be something like
":20110808". Excerpts from my debugging:

==>  Entering fakeroot environment...

EPOCH=|0|
FAKEROOTKEY=|1562776010|
==>  Starting package()...

....stuff happens....

==>  Creating package...
   ->  Generating .PKGINFO file...

EPOCH=||
FAKEROOTKEY=|1562776010|
/home/noclaf/src/c/pacman/scripts/makepkg: line 246: ((: !  : syntax
error: operand expected (error token is "!  ")
   ->  Compressing package...

EPOCH=||
FAKEROOTKEY=|1562776010|
/home/noclaf/src/c/pacman/scripts/makepkg: line 246: ((: !  : syntax
error: operand expected (error token is "!  ")
==>  Leaving fakeroot environment.

EPOCH=|0|
FAKEROOTKEY=||
==>  Finished making: cower-git 20110808-1 (Mon Aug  8 22:40:36 EDT 2011)


So is it fakeroot fucking with us here? Doesn't seem to be, but
somewhere along the line our epoch value is wrenched out from under us.

NB: (( ! $epoch )) isn't the same as (( ! epoch )). One expands to 0
when its unset and the other throws a syntax error.



Hmmm... that does look like it is getting lost when we go to fakeroot. But then why have we never had issues with pkgbase doing the same? I need to look into this further...

Allan


Reply via email to