Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?

Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?

[Jan Wielemaker]

Hi,

After upgrade to SuSE 11.0 I was forced to update GIT (changed libcurl).
I did (with some trickery) a pull of the latest git and built it using
make prefix=/usr/local ..., to find out that /usr/local/bin/git-daemon
starts /usr/sbin/git-upload-pack.

After creating a symlink to /usr/local/bin/git-upload-pack all works fine
again, but I guess this is a mistake?

	Cheers --- Jan

P.s.	This is quite nasty to debug.  I was forced to to run git-daemon
	stand-alone (not xinetd) another port and run strace -f -p <pid>
	to discover the	cause of this problem.  Even with --verbose, the
	only error response was the client complaining on unexpected EOF.

Re: Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?

[Junio C Hamano]

Jan Wielemaker <J.Wielemaker@uva.nl> writes:

> After upgrade to SuSE 11.0 I was forced to update GIT (changed libcurl).
> I did (with some trickery) a pull of the latest git and built it using
> make prefix=/usr/local ..., to find out that /usr/local/bin/git-daemon
> starts /usr/sbin/git-upload-pack.
>
> After creating a symlink to /usr/local/bin/git-upload-pack all works fine
> again, but I guess this is a mistake?

I think this is a distro issue.

Pre-1.6.0 git installs git-everything in $(bindir) and knows things are
there.  Current 'master' we are preparing for 1.6.0 instead installs
git-mostofthem in $(prefix)/libexec/git-core and git-someofthem in
$(bindir); our executables know which binaries are installed in $(bindir)
and which ones are installed in $(prefix)/libexec/git-core.

The point is we never install $anywhere/sbin unless the person who is
building explicitly does so (either by futzing the Makefile or giving
bindir=$somewhere from the command line of "make").  The reason your
/usr/local/bin/git-daemon (we do not know who compiled it and how) spawns
something in /usr/sbin is not our doing.  Find out who configured it and
why, and more importantly, what _other_ changes are made in the build and
installation procedure to support that change in location.

Re: Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?

[Jan Wielemaker]

Hi Junio,

On Wednesday 09 July 2008 23:14:06 Junio C Hamano wrote:
> Jan Wielemaker <J.Wielemaker@uva.nl> writes:
> > After upgrade to SuSE 11.0 I was forced to update GIT (changed libcurl).
> > I did (with some trickery) a pull of the latest git and built it using
> > make prefix=/usr/local ..., to find out that /usr/local/bin/git-daemon
> > starts /usr/sbin/git-upload-pack.
> >
> > After creating a symlink to /usr/local/bin/git-upload-pack all works fine
> > again, but I guess this is a mistake?
>
> I think this is a distro issue.
>
> Pre-1.6.0 git installs git-everything in $(bindir) and knows things are
> there.  Current 'master' we are preparing for 1.6.0 instead installs
> git-mostofthem in $(prefix)/libexec/git-core and git-someofthem in
> $(bindir); our executables know which binaries are installed in $(bindir)
> and which ones are installed in $(prefix)/libexec/git-core.
>
> The point is we never install $anywhere/sbin unless the person who is
> building explicitly does so (either by futzing the Makefile or giving
> bindir=$somewhere from the command line of "make").  The reason your
> /usr/local/bin/git-daemon (we do not know who compiled it and how) spawns
> something in /usr/sbin is not our doing.  Find out who configured it and
> why, and more importantly, what _other_ changes are made in the build and
> installation procedure to support that change in location.

If you read carefully you see some "I ..." :-)  Summarising to avoid all
confusion:

	* I had git installed in /usr/local/bin, this was git from git,
	close to 1.5.6.  The machine was running SuSE 10.2.
	* I installed SuSE 11.0, whiping /, but git remained as 
	/usr/local is on a seperate partition.
	* Git refused to run (dependency on libcurl.so.3; 11.0 ships with
	libcurl.so.4).
	* I copied libcurl.so.3 from backup into /usr/lib64, which at least
	made git run again.
	* Then I did 

		% git pull
		% git clean -x -f
		% make prefix=/usr/local all doc info 
		# make prefix=/usr/local install install-doc install-info
		
	* All went smooth, but clients to git:// complained that the other site
	hung up unexpectedly.
	* Ran git-daemon --verbose --export-all --user=git --port=4000 /some/path
	* Ran strace -f -p <pid>
	* Ran git clone git://localhost:4000/some/path to find it was trying to
	start /usr/sbin/git-upload-pack.

I understand bit changes are underway, so it might not be worthwhile to try 
and
get to the bottom of this.

	Cheers --- Jan

Re: Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?

[Brian Foster]

On Wednesday 09 July 2008 22:20:10 Jan Wielemaker wrote:
>[ ... ]
> P.s.	This [ git-daemon using a weird path to exec git-upload-pack
>       was ] quite nasty to debug.  I was forced to to run git-daemon
> 	stand-alone (not xinetd) another port and run strace -f -p <pid>
> 	to discover the	cause of this problem.  Even with --verbose, the
> 	only error response was the client complaining on unexpected EOF.

 Just a hint:  I had some odd exec problems in the past
 (as it happens, also from xinetd and also path-related,
 but not(?) your problem), and found that exporting

    GIT_TRACE=/tmp/LOG-git-daemon

 gave some valuable clews.  I'm unaware of GIT_TRACE
 being documented.  I also concur it's annoying neither
 --syslog nor --verbose seems to cause these sort of
 errors to be logged.

cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?

[Jeff King]

On Thu, Jul 10, 2008 at 09:32:06AM +0200, Brian Foster wrote:

>     GIT_TRACE=/tmp/LOG-git-daemon
> 
>  gave some valuable clews.  I'm unaware of GIT_TRACE
>  being documented.  I also concur it's annoying neither

It's in git(1).

-Peff