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

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.

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

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.

Hi Junio,

On Wednesday 09 July 2008 23:14:06 Junio C Hamano wrote:

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

On Wednesday 09 July 2008 22:20:10 Jan Wielemaker wrote:

 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-

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

It's in git(1).

-Peff