FS#19932 - Makepkg uses a wrong pattern match in write_pkginfo()

Attached to Project: Pacman
Opened by Neal van Veen (Nvveen) - Wednesday, 23 June 2010, 20:37 GMT
Last edited by Allan McRae (Allan) - Thursday, 01 July 2010, 05:59 GMT
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity Low
Priority Normal
Reported Version 3.4.0
Due in Version 3.4.1
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Summary and Info:

With pacman < 3.4.0 the command to get the disk usage by a pkg is obtained via awk, which (to my understanding), works. With 3.4.0 this has been replaced by a regex pattern match, which doesn't work and gives the following error:

/usr/bin/makepkg: line 902: * 1024 : syntax error: operand expected (error token is "* 1024 ")

whenever makepkg is invoked. Reverting back to 3.3.3 or splitting up the command removes the error, although it is not clear if it fixes the issue.

Steps to Reproduce:

Update Pacman to 3.4.0.
Run a makepkg script

Confirmed architecture: x86_64, 1 day older than Pacman version 3.4.0, Asus Turion64 dualcore laptop.
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 01 July 2010, 05:59 GMT
Reason for closing:  Fixed
Additional comments about closing:  git commit: http://projects.archlinux.org/pacman.git /commit/?h=maint&id=0ea52e3a
Comment by Dan McGee (toofishes) - Wednesday, 23 June 2010, 20:42 GMT
What is your locale set to?

@@ -882,7 +884,8 @@ write_pkginfo() {
else
local packager="Unknown Packager"
fi
- local size=$(du -sk | awk '{print $1 * 1024}')
+ local size="$(du -sk)"
+ size="$(( ${size%%[^0-9]*} * 1024 ))"

msg2 "$(gettext "Generating .PKGINFO file...")"
echo "# Generated by makepkg $myver" >.PKGINFO

This is the relevant change; I wonder if there are spaces to the left of the numbers causing the issues as that was tightened up a bit.

If you run `echo $(du -sk)` in some small-ish directory, what is the output?
Comment by Neal van Veen (Nvveen) - Wednesday, 23 June 2010, 20:45 GMT
Bug report is the same as #19865, must have missed that one. This one can be merged/deleted.
Comment by Ionut Biru (wonder) - Wednesday, 23 June 2010, 20:45 GMT Comment by Dan McGee (toofishes) - Wednesday, 23 June 2010, 20:47 GMT
Does cw replace the du binary, or how does it work? We can probably try harder to make sure we use the actual du...
Comment by Andres P (llanero) - Wednesday, 23 June 2010, 21:37 GMT
It doesn't replace anything, it relies on export PATH="/usr/lib/cw:$PATH"

cw isn't the only utility that needs to add to PATH.

makepkg sources /etc/profile which is site dependant. It's like sourcing a file in /usr/local.

makepkg should either use explicit paths or be strict and set PATH in-line, sourcing /etc/profile in a subshell.
Comment by Andres P (llanero) - Thursday, 24 June 2010, 08:24 GMT
This is not a regression in 3.4; using shell arith just made this old bug easier to spot.

With cw, makepkg was making .PKGINFO with 'size = 0':
$ du -sk | awk '{print $1 * 1000}'
0
$ /bin/du -sk | awk '{print $1 * 1000}'
5904000

Apparently the cw wrapper isn't smart enough to know when stdout isn't a terminal:
$ du -sk | cat -A
^[[00;37m^[[01;37m5904^[[00;37m^I.^[[0m$
Comment by Allan McRae (Allan) - Tuesday, 29 June 2010, 12:50 GMT
The whole point of sourcing /etc/profile is to get all the additions to the PATH that are needed by the dependencies of a package. The "solution" of course is to build in a clean chroot so that superfluous additions are not present.

Anyway... to provide the full path to the coreutils du, we need some autoconf type stuff (it is at /bin/du in Arch but /usr/bin/du in many places). Does someone want to attempt that?
Comment by Allan McRae (Allan) - Wednesday, 30 June 2010, 03:32 GMT

Loading...