bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#16843: Error caused due to regression in git


From: Eric Blake
Subject: Re: bug#16843: Error caused due to regression in git
Date: Mon, 24 Feb 2014 07:00:30 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

thanks
[adding gnulib]

On 02/22/2014 02:01 AM, Darshit Shah wrote:
> automake --version: 1.14.1
> autoconf --version: 2.69
> 
> The error occured when attempting to run the test suite GNU Wget's git
> source.
> `make` works correctly, but `make check` happens to fail with the following
> output:
> 
> if test -d ./.git                               \
>         && git --version >/dev/null 2>&1; then                  \
>   cd . &&                                               \
>   git submodule --quiet foreach                                 \
>       test '"$(git rev-parse "$sha1")"'                 \
>       = '"$(git merge-base origin "$sha1")"'                    \
>     || { echo 'maint.mk: found non-public submodule commit' >&2;        \
>          exit 1; };                                             \
> else                                                            \
>   : ;                                                           \
> fi
> Stopping at 'gnulib'; script returned non-zero status.
> maint.mk: found non-public submodule commit
> maint.mk:1394: recipe for target 'public-submodule-commit' failed
> make: *** [public-submodule-commit] Error 1

This rule comes from upstream gnulib, so it will break on more than just
automake as more people start upgrading to newer git.

> 
> 
> In the repository, gnulib is used as a submodule. Running:
> $ git submodule foreach echo $name, $path, $sha1
> returns an empty string which implies that git is unable to see the
> submodules correctly.
> 
> I bisected the git source to find the commit causing the problems. The
> following is the commit message:
> 
> commit 1c4fb136dbad762c9c4350ee79c3474ae8037587

> 
>     To fix this, if the user passes more than one argument, execute "$@"
>     directly instead of passing it to eval.
> 

> 
> Hence, this seems to me as a feature, not a bug in Git. Maybe, automake
> needs to fix its scripts accordingly? Because the issue with `make check`
> was introduced through this specific commit.

Yes, we need to update the gnulib rule to behave nicely on both old and
new versions of git.

Based on the test that is failing, can you please show the output of:

  git submodule --quiet foreach echo 'a  b' '"c  d"'

On my version (1.8.5.3), I get 'a b c  d' (that is, echo saw three
arguments rather than 2, where only my 'c  d' argument survived because
it was double-quoted).  I'm guessing your version preserves extra
quotes, because it is not being passed through a layer of shell
interpretation?

Have you reported this regression to the git folks?

> 
> Do let me know if I can provide any more help.
> Also, I am not sunscribed to this mailing list, hence, please ensure to
> leave my email in the CC list.

Yes, reply-to-all is list policy (both for automake and for gnulib).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]