On 14/10/10 01:36, Dan McGee wrote:
On Wed, Oct 13, 2010 at 10:12 AM, Allan McRae<[email protected]> wrote:
On 14/10/10 01:11, Allan McRae wrote:
On 14/10/10 00:59, Dan McGee wrote:
On Wed, Oct 13, 2010 at 9:54 AM, Allan McRae<[email protected]> wrote:
On 14/10/10 00:11, Dan McGee wrote:
I think this was alluded to a while back, but we are starting to show
some problems with our naming scheme and bash variable/function naming
rules:
/usr/bin/makepkg: line 1831: declare: `package_python-xlwt': not a
valid identifier
With latest makepkg built from git.
Any chance of some more info on how to replicate? At least the
pkgname line
or even the whole PKGBUILD?
Haha, my bad.
wget http://aur.archlinux.org/packages/python-xlwt/python-xlwt.tar.gz
bsdtar xf python-xlwt.tar.gz
cd python-xlwt
makepkg
I can not replicate with 4.1.x or 3.2.x.
^ these are bash version....
Hmmmmm. Build output attached, and here is the relevant part of this
particular version of makepkg:
1825 # test for available PKGBUILD functions
1826 if declare -f build>/dev/null; then
1827 BUILDFUNC=1
1828 fi
1829 if declare -f package>/dev/null; then
1830 PKGFUNC=1
1831 elif [[ $SPLITPKG -eq 0 ]]&& declare -f package_${pkgname}
/dev/null; then
1832 SPLITPKG=1
1833 fi
OK - I can replicate. I forgot my makepkg-git package builds from my
working branch which had not been rebased to master after the last
couple of pushes. But it turns out that was a good thing as there were
only a couple of patches that could cause this issue:
05f0a28932c1acab7a9ddb58435d69626dad54da is the first bad commit
commit 05f0a28932c1acab7a9ddb58435d69626dad54da
Author: Nezmer <[email protected]>
Date: Tue Oct 12 02:23:16 2010 +0300
Use sysconfdir, localstatedir, BASH instead of hardcoded values
This applies to contrib/ files, our scripts, and the documentation.
Dan: fix 'make clean' in contrib/ directory.
Signed-off-by: Nezmer <[email protected]>
Signed-off-by: Dan McGee <[email protected]>
....
which does this to the top of makepkg:
#!/bin/sh -e
which is bad... even when we symlink that to bash as it starts in
standards compliance mode. So you have not broken bash, you have broken
configure!
So looking at configure output:
checking for bash... /bin/sh
and the configure check:
AC_CHECK_PROGS([BASH], [bash bash4 bash3], [false])
So... WTF? It turns out the issues is that the BASH variable seems to
be used elsewhere and we have a naming conflict...
Allan
