On Wed, Oct 13, 2010 at 05:40:44PM -0500, Dan McGee wrote: > On Wed, Oct 13, 2010 at 5:32 PM, Allan McRae <[email protected]> wrote: > > 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... > > Oh man, this makes so much more sense. WTF, configure? > > The shell itself sets this, try the following (which is what > ./configure ends up doing): > #!/bin/sh > echo $BASH > > I think I have a patch on the way... > > -Dan >
My bad. I would have caught this If I tested with Arch. This does not happen in FreeBSD. What is setting BASH exactly?
