git-1.4.0 make problems

git-1.4.0 make problems

[Michael Somos]

I downloaded the git-1.4.0.tar.bz2 recently and encountered a few problems.

1) The untar process creates a stray file "pax_global_header".
I am using GNU tar v1.13.22 and I get this message :

======================================================================
> tar jxf ~/u/source/git-1.4.0.tar.bz2
tar: pax_global_header: Unknown file type 'g', extracted as normal file
======================================================================

2) The make install process ignores the "prefix=..." argument. I have
to comment out one line for this :

======================================================================
> diff Makefile git-1.4.0/
94c94 
< #prefix = $(HOME)
---
> prefix = $(HOME)
======================================================================

3) The make has a problem with "expat" include and libararies.
I have to add more lines to the Makefile to handle this like some
of the other include and libraries :

======================================================================
351,358c351
< endif
<
< ifndef NO_EXPAT
<       ifdef EXPATDIR
<               # This is still problematic -- gcc does not always want -R.
<               ALL_CFLAGS += -I$(EXPATDIR)/include
<               EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
<           else
---
>       ifndef NO_EXPAT
360c353
<           endif
---
>       endif
======================================================================

Other than that, it installed okay. I will have to read the docs and
use it to see how it goes otherwise.

Re: git-1.4.0 make problems

[Rene Scharfe]

| I downloaded the git-1.4.0.tar.bz2 recently and encountered a few
| problems.
|
| 1) The untar process creates a stray file "pax_global_header".
| I am using GNU tar v1.13.22 and I get this message :
|
| ======================================================================
| > tar jxf ~/u/source/git-1.4.0.tar.bz2
| tar: pax_global_header: Unknown file type 'g', extracted as normal
| file
| ======================================================================

You can ignore or delete that file.  It is a pax extended global header,
containing the git commit ID as a comment.  GNU tar started supporting
pax headers with version 1.13.93 (released 2004-02-23).  Version 1.13.22
was released on 2001-08-29, by the way.  May I ask what operating system
and version you are using?

| 2) The make install process ignores the "prefix=..." argument. I have
| to comment out one line for this :
|
| ======================================================================
| > diff Makefile git-1.4.0/
| 94c94
| < #prefix = $(HOME)
| ---
| > prefix = $(HOME)
| ======================================================================

It took me a while to realize that your diffs are reversed.  It's too
early for me, I think I'll go to bed again. :)

Anyway, prefix handling is currently being worked on.  Yakov Lerner sent
a patch which seems to make make do what you need.

| 3) The make has a problem with "expat" include and libararies.
| I have to add more lines to the Makefile to handle this like some
| of the other include and libraries :
|
| ======================================================================
| 351,358c351
| < endif
| <
| < ifndef NO_EXPAT
| <       ifdef EXPATDIR
| <               # This is still problematic -- gcc does not always want -R.
| <               ALL_CFLAGS += -I$(EXPATDIR)/include
| <               EXPAT_LIBEXPAT = -L$(EXPATDIR)/lib -R$(EXPATDIR)/lib -lexpat
|
| <           else
| ---
| >       ifndef NO_EXPAT
| 360c353
| <           endif
| ---
| >       endif
| ======================================================================

Looks sensible, except for the formatting.

| Other than that, it installed okay. I will have to read the docs and
| use it to see how it goes otherwise.

A good first exercise would be to fetch the git repository, edit Makefile
and commit your change, and then send a patch to this list -- all using
git (except the editing part). :-)  Care to try that?  Please let us know
of any difficulties you may encounter.

Thanks,
René

Re: git-1.4.0 make problems

[Junio C Hamano]

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> | 1) The untar process creates a stray file "pax_global_header".
> | I am using GNU tar v1.13.22 and I get this message :
> |
> | ======================================================================
> | > tar jxf ~/u/source/git-1.4.0.tar.bz2
> | tar: pax_global_header: Unknown file type 'g', extracted as normal
> | file
> | ======================================================================
>
> You can ignore or delete that file.  It is a pax extended global header,
> containing the git commit ID as a comment.  GNU tar started supporting
> pax headers with version 1.13.93 (released 2004-02-23).  Version 1.13.22
> was released on 2001-08-29, by the way.  May I ask what operating system
> and version you are using?

I've been using (in my non-git related project aka day-job)

  git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar 

to avoid this.  Although all of my target machines have gtar
that are recent enough so I do not need it, but when the tarball
has version string in its name, there is not much point having
the pax header to identify the contents (where the pax header
shines is when the result does not have the version string in
its name).

This might be a sensible thing to do for our dist target as
well.  The product of our dist target is for people who build
from the source to bootstrap themselves (if they have git, then
fetching the source using git is preferred anyway), as opposed
to using pre-built binaries, so being as friendly as we can to
different implementations of tar is a good thing.

Re: git-1.4.0 make problems

[Rene Scharfe]

Junio C Hamano schrieb:
> I've been using (in my non-git related project aka day-job)
> 
> git-tar-tree HEAD^{tree} $(PROJECT)-$(RELNAME) >$(PROJECT)-$(RELNAME).tar
> 
> to avoid this.  Although all of my target machines have gtar that are
> recent enough so I do not need it, but when the tarball has version
> string in its name, there is not much point having the pax header to
> identify the contents (where the pax header shines is when the result
> does not have the version string in its name).
> 
> This might be a sensible thing to do for our dist target as well.
> The product of our dist target is for people who build from the
> source to bootstrap themselves (if they have git, then fetching the
> source using git is preferred anyway), as opposed to using pre-built
> binaries, so being as friendly as we can to different implementations
> of tar is a good thing.

Hrm.  Is the header really that unfriendly?  With a non-POSIX tar you
get an extra file and a nice, if somewhat cryptic, reminder to upgrade
your archiver. ;-)  Seriously, this is way below my annoyance-radar,
but I'm obviously biased.

What do you think about the following patch for starters?  It adds an
example to the git-tar-tree documentation showing your "tree trick"
and corrects two formatting buglets.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>

diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index 831537b..c93a8fe 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -45,11 +45,16 @@ git tar-tree HEAD | (cd /var/tmp/ && mkd
 	latest commit on the current branch, and extracts it in
 	`/var/tmp/junk` directory.
 
-git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz
+git tar-tree v2.6.17 linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
 
 	Create a tarball for v2.6.17 release.
 
-git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar
+git tar-tree v2.6.17{caret}\{tree\} linux-2.6.17 | gzip >linux-2.6.17.tar.gz::
+
+	Create a tarball for v2.6.17 release, but without a
+	global extended pax header.
+
+git tar-tree --remote=example.com:git.git v0.99 >git-0.99.tar::
 
 	Get a tarball v0.99 from example.com.
 

Re: git-1.4.0 make problems

[Junio C Hamano]

Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Hrm.  Is the header really that unfriendly?  With a non-POSIX tar you
> get an extra file and a nice, if somewhat cryptic, reminder to upgrade
> your archiver. ;-)  Seriously, this is way below my annoyance-radar,
> but I'm obviously biased.

I do not mind tar-tree producing the header by default and
having to override it with ^{tree} -- actually I think it is a
good default.  I think that particular use in our Makefile,
however, is not necessary.

> What do you think about the following patch for starters?

Documentation updates are always welcome, and I think this is a
good change.  Thanks.

Re: git-1.4.0 make problems

[Michael Somos]

Rene Scharfe wrote :

> | tar: pax_global_header: Unknown file type 'g', extracted as normal

> You can ignore or delete that file.  It is a pax extended global header,

Yes, I knew I could ignore the file right away. I figured it was due
to some new feature of GNU tar.

> was released on 2001-08-29, by the way.  May I ask what operating system
> and version you are using?

Mandrake 8,1 for i586. I had not encountered problems with GNU tar 1.13.22
before. A quick google showed this was not a rare problem, but nothing in
the tarball for git-1.4.0 mentioned this problem. I understand that it may
be a rare or nonexistant problem for the target audience of "git", but just
a sentence or two would be enough clue to help out those who may need it.

> It took me a while to realize that your diffs are reversed.  It's too

Yes, unfortunately, I did reverse it, but even patch can handle that.

> A good first exercise would be to fetch the git repository, edit Makefile
> and commit your change, and then send a patch to this list -- all using

A good suggestion, but I am a newbie as you can tell, and would prefer to
play in a sandbox for some time before I would attempt it. Of more concern
to me now is a failed test :

> * FAIL 12: apply diff between 3 and 2
>        git-apply <diff.3-2 && diff frotz.2 frotz
> * failed 2 among 12 test(s)
> make[1]: *** [t4101-apply-nonl.sh] Error 1

All the other tests worked which is great. Thanks for your reply. Shalom,
Michael

Re: git-1.4.0 make problems

[Dennis Stosberg]

Michael Somos wrote:

> A good suggestion, but I am a newbie as you can tell, and would prefer to
> play in a sandbox for some time before I would attempt it. Of more concern
> to me now is a failed test :
> 
> > * FAIL 12: apply diff between 3 and 2
> >        git-apply <diff.3-2 && diff frotz.2 frotz
> > * failed 2 among 12 test(s)
> > make[1]: *** [t4101-apply-nonl.sh] Error 1

I have seen this test failing on FreeBSD 5.3, too.  FreeBSD comes with a
version of "diff" which does not add the "\ No newline at end of file"
remark.  Maybe your "diff" is simply too old.  In that case, it's not a
serious problem because Git uses its own internal diff implementation.

The intention of this test is to test git-apply and not the system's
"diff", so perhaps it should bring along all its patches and not rely
on the system's "diff" to generate them...

Regards,
Dennis

Re: git-1.4.0 make problems

[Rene Scharfe]

Michael Somos wrote:
> A good suggestion, but I am a newbie as you can tell, and would prefer to
> play in a sandbox for some time before I would attempt it.

You already sent a diff in your first message, so you're not that much
of a newbie. :-)

Thanks for telling us about your first encounter with git, by the way.
Take your time, and have fun learning and using git!

René

Re: git-1.4.0 make problems

[Michael Somos]

Dennis  Stosberg wrote :

> I have seen this test failing on FreeBSD 5.3, too.  FreeBSD comes with a
> version of "diff" which does not add the "\ No newline at end of file"
> remark.  Maybe your "diff" is simply too old.  In that case, it's not a
> serious problem because Git uses its own internal diff implementation.

You are exactly right. My "diff" is a bit too old. It was 2.7 and the
latest stable is 2.8.1 which fixes the newline problem.

> The intention of this test is to test git-apply and not the system's
> "diff", so perhaps it should bring along all its patches and not rely
> on the system's "diff" to generate them...

That seems like a good suggestion if it is as you wrote. Thanks for the
information regarding diff and git. Shalom, Michael