Jonathan wrote:
someone on irc discovered today that the ffmpeg-svn package failed to build with the odd error seen below...
I am using the following version of pacman in archlinux (non-testing): Name : pacman Version : 3.1.1-1 Architecture : i686 Build Date : Sun 20 Jan 2008 07:51:41 PM PST
$ makepkg ==> Determining latest svn revision... -> Version found: 11825 emove sed: -e expression #1, char 28: unterminated `s' command
makepkg --holdver with old and new versions built ok.
the suspect line in makepkg: newpkgver=$(svn log $_svntrunk --limit 1 | sed -n 's/^r\([^ ]* \) .*$/\1/p')
here's the svn log at the time: ------------------------------------------------------------------------ r11825 | lorenm | 2008-02-02 19:21:47 -0800 (Sat, 02 Feb 2008) | 2 lines
remove some movq in ff_h264_idct8_add_mmx. 288->280 cycles on core2.
------------------------------------------------------------------------
while a full reproduction requires a controlled svn server, a test can be done with this: $ svn log -r 11825 --limit 1 svn://svn.mplayerhq.hu/ffmpeg/trunk | sed -n 's/^r\([^ ]*\) .*$/\1/p' 11825 emove
the following is a patch that forces sed to test only the second line of the log. while this works, it will break if the log header is reformatted in the future. But I couldn't find any documentation on how to change the format, or any variations in the logs of the handful of svn servers I've looked at. So it seems ok to do this.
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 0997386..bd6a7fe 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -1007,7 +1007,7 @@ devel_check() { newpkgver=$(date +%Y%m%d) elif [ ! -z ${_svntrunk} ]&& [ ! -z ${_svnmod} ] ; then msg "$(gettext "Determining latest svn revision...")" - newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n 's/^r\([0-9]* \) .*$/\1/p') + newpkgver=$(svn log $_svntrunk --limit 1 -q | sed -n '2s/^r\([0-9]* \) .*$/\1/p') elif [ ! -z ${_bzrtrunk} ]&& [ ! -z ${_bzrmod} ] ; then msg "$(gettext "Determining latest bzr revision...")" newpkgver=$(bzr revno ${_bzrtrunk})
Jonathan Frazier
Yes, stonecrest already reported this on irc one week ago, here is the patch I proposed which has been merged : http://projects.archlinux.org/git/?p=pacman.git;a=commit;h=f950c2630798e03bb... Notice that the command you are using for reproducing the bug, and the command you edited in your patch is not the same. I added the -q option for fixing the very same problem :) This will be in 3.1.2.