On 4 July 2014 22:22, David Turner <dtur...@twopensource.com> wrote:
> On Thu, 2014-07-03 at 23:55 +0200, Øyvind A. Holm wrote:
> > When compiling newest master (v2.0.1-472-g6f92e5f) on Debian 7.5
> > (64-bit), t5150-request-pull.sh fails when compiling with
> >
> > $ make configure
> > $ ./configure
> > --prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
> > $ make prefix=/usr/local/varprg/git.master.v2.0.1-472-g6f92e5f
> > $ make
> > $ cd t
> > $ ./t5150-request-pull.sh
> Are you sure you're not running under valgrind? I can reproduce the
> test failures when I run under valgrind because I didn't add the right
> stuff to the suppression files (patch to follow).

Nope, no valgrind involved here, it's not even installed on those two
servers. The two server setups differ quite much, one of them I use for
all kind of things, the other is a dedicated web server with not much
else except Apache and some essential stuff I can't live without

> I also just went ahead and got a Linode running Debian 7.5 (64-bit),
> and I still can't reproduce the problem.

Now that's what I call commitment. :)

> Do you have any additional reproduction info that I need here?

I build new gits pretty much every time Junio pushes new stuff to
kernel.org, and I'm using this script which takes care of everything:


I have a README at


where I have listed all packages I install from apt-get before I build
the thing. The script I used to test with git bisect is at


, it simulates what the "build-git" script does.

The test works if I run a plain "make" using the standard Makefile
without ./configure .

Hm, interesting. When I don't use --prefix as mentioned above, just a

  $ make configure
  $ ./configure
  $ make
  $ cd t
  $ ./t5150-request-pull.sh

The test works. Seems as there's something fishy about the use of
--prefix in this specific commit (v2.0.1-472-g6f92e5f).

I'll dig more into this thing now to see what's going on.

Сенсорно Ваш,
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to