Interested in helping open source friends on HP-UX?

Interested in helping open source friends on HP-UX?

[Junio C Hamano]

Hello, all.

H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
source communities, wants help porting more recent Git on these
boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
volunteer.  Please contact him directly if you are interested.

Thanks.

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 9676 bytes --]

On Wed, 10 Dec 2014 23:46:25 -0800, Junio C Hamano <gitster@pobox.com>
wrote:

> Hello, all.
> 
> H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
> source communities, wants help porting more recent Git on these
> boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
> volunteer.  Please contact him directly if you are interested.

No-one. Disappointing :(

I started to work on 2.3.0 on HP-UX 11.23/63 ia64


Did *anyone* ever test with NO_ICONV?
Too many tests fail without iconv

It is *very* hard to decide from the current status if all
remaining failures are related to (Asian) locale failures and (thus)
can be safely ignored (in my environment).


Specifics at the end


FAILures from scratch with no iconv:
--------------------------------------------------------------------------------
t3513-revert-submodule.sh       Tests: 14 Failed:  5 Failed tests: 1-2, 4, 6-7                   TODO passed:   10-11
t3900-i18n-commit.sh            Tests: 34 Failed:  8 Failed tests: 15-17, 23-25, 27-28
t3901-i18n-patch.sh             Tests: 15 Failed:  8 Failed tests: 2-3, 6-7, 9, 11, 14-15
t4041-diff-submodule-option.sh  Tests: 44 Failed:  5 Failed tests: 5-7, 9-10
t4201-shortlog.sh               Tests: 11 Failed:  1 Failed tests: 9
t4204-patch-id.sh               Tests: 15 Failed:  3 Failed tests: 7, 10, 13
t4205-log-pretty-formats.sh     Tests: 46 Failed: 20 Failed tests: 12-14, 17, 19, 21, 23-29, 31, 33, 35, 37 39, 41-42
t4210-log-i18n.sh               Tests:  5 Failed:  4 Failed tests: 2-5
t5100-mailinfo.sh               Tests: 35 Failed: 11 Failed tests: 20-30
t5570-git-daemon.sh             Tests: 12 Failed:  2 Failed tests: 4-5      Parse errors: No plan found in TAP output
t6006-rev-list-format.sh        Tests: 54 Failed: 11 Failed tests: 9-10, 12, 25-27, 30-34
t6041-bisect-submodule.sh       Tests: 14 Failed:  9 Failed tests: 1-2, 4-7, 12-14               TODO passed:   10-11
t7001-mv.sh                     Tests: 46 Failed:  2 Failed tests: 38-39
t7102-reset.sh                  Tests: 30 Failed:  1 Failed tests: 2
t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
t8005-blame-i18n.sh             Tests:  5 Failed:  3 Failed tests: 2-4
t9350-fast-export.sh            Tests: 34 Failed:  1 Failed tests: 4
Files=687, Tests=12091

FAILures from scratch with iconv:
--------------------------------------------------------------------------------
t3513-revert-submodule.sh       Tests: 14 Failed:  5 Failed tests: 1-2, 4, 6-7                   TODO passed:   10-11
t3900-i18n-commit.sh            Tests: 34 Failed:  6 Failed tests: 16-17, 24-25, 27-28
t4204-patch-id.sh               Tests: 15 Failed:  3 Failed tests: 7, 10, 13
t4210-log-i18n.sh               Tests:  5 Failed:  4 Failed tests: 2-5
t5100-mailinfo.sh               Tests: 35 Failed:  2 Failed tests: 20, 23
t5536-fetch-conflicts.sh        Tests:  7 Failed:  3 Failed tests: 3, 6-7
t5570-git-daemon.sh             Tests: 12 Failed:  2 Failed tests: 4-5      Parse errors: No plan found in TAP output
t6041-bisect-submodule.sh       Tests: 14 Failed:  9 Failed tests: 1-2, 4-7, 12-14               TODO passed:   10-11
t7001-mv.sh                     Tests: 46 Failed:  2 Failed tests: 38-39
t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
t8005-blame-i18n.sh             Tests:  5 Failed:  3 Failed tests: 2-4
Files=687, Tests=12091
Result: FAIL

running «sh t****.sh -x -i»


t/t7001-mv.t
------------
cp uses -P flag, which is unknown to HP's (non-GNU) version of cp

Changing the two occurrences from

		cp -R -P -p ../.git/modules/sub .git &&
to
		rsync -aHl ../.git/modules/sub/ .git/ &&

make the tests pass (on those systems that have a working rsync)

t/t3513-revert-submodule.sh
---------------------------
tar uses z flag, which is unknown to HP's (non-GNU) version of tar
config.mak.uname defines TAR = gtar, but that obviously does not help

putting GNU-tar temporary in from of my $PATH makes the test pass
/me thinks the z in not required in that test at all

	tar cf "$TRASH_DIRECTORY/tmp.tar" * &&
and
	tar xf "$TRASH_DIRECTORY/tmp.tar" &&

work just as well and prevent the breakage

t/t3900-i18n-commit.sh
----------------------
As my HP boxes have *NO* JP or other space eating asian locale stuff
installed, it is highly likely that *anything* dealing with asian
locales will fail. On modern Linux hardware, disk space is cheap. On
most HP-UX boxes disk space is expensive and when having nothing to do
with Asian languages, removing all Asian-related packages is a fast and
cheap way to regain disk space.

Changing compare_with to

compare_with () {
    case "$1$2$3" in
	*eucJP*|*ISO-2022-JP*) true ;;
	*)
	    git show -s $1 | sed -e '1,/^$/d' -e 's/^    //' >current &&
	    case "$3" in
		'')
		    test_cmp "$2" current ;;
		?*)
		    iconv -f "$3" -t UTF-8 >current.utf8 <current &&
		    iconv -f "$3" -t UTF-8 >expect.utf8 <"$2" &&
		    test_cmp expect.utf8 current.utf8
		    ;;
		esac
	    ;;
	esac
    }

makes all my tests pass

t/t4204-patch-id.sh
-------------------

No idea yet

+ test_patch_id_file_order irrelevant --stable --stable
Already on 'same'
cmp: patch-id_ordered-ordered-order---stable-irrelevant: No such file or directory

$ find * | grep 4204 | grep stable
trash directory.t4204-patch-id/patch-id_order---stable-irrelevant
trash directory.t4204-patch-id/patch-id_ordered-order---stable-irrelevant

t/t4210-log-i18n
----------------

$ dump "trash directory.t4210-log-i18n/actual"
00000000  75 74 66 38 0A                                      utf8.
$ dump "trash directory.t4210-log-i18n/expect"
00000000  6C 61 74 69 6E 31 0A 75  74 66 38 0A                latin1.utf8.
$ dump "trash directory.t4210-log-i18n/msg"
00000000  6C 61 74 69 6E 31 0A 0A  74 E9 73 74 0A             latin1..t.st.

t/t5100-mailinfo.sh
-------------------
+ git mailinfo -u rfc2047/0001-msg rfc2047/0001-patch
+ 0< rfc2047/0001 1> rfc2047/0001-info
fatal: cannot convert from US-ASCII to UTF-8
error: last command exited with $?=128

t/t5536-fetch-conflicts.sh
--------------------------
+ setup_repository ccc +refs/heads/branch1:refs/remotes/origin/branch1 +refs/heads/branch2:refs/remotes/origin/branch1
Initialized empty Git repository in /pro/3gl/LINUX/git-2.3.0p/t/trash directory.t5536-fetch-conflicts/ccc/.git/
+ cd ccc
+ test_must_fail git fetch origin
+ 2> error
+ verify_stderr
+ 0< /var/tmp/sh6096.2
cmp: EOF on actual
error: last command exited with $?=1
not ok 3 - fetch conflict: config vs. config

t/t5570-git-daemon.sh
---------------------
I will ignore this myself, as I have no intention of using HP-UX as a
git server. We already have a dedicated Linux box doing so.

+ test_cmp file clone/file
ok 3 - clone git repository

expecting success:
        echo content >>file &&
        git commit -a -m two &&
        git push public &&
        (cd clone && git pull) &&
        test_cmp file clone/file

+ echo content
+ 1>> file
+ git commit -a -m two

arg sulong failed. 0, 0x9fffffffbffff058

 Setup args failed.

Pid 6238 was killed due to failure in writing to user register stack - possible stack overflow.
[master bca99f0] two
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+)
+ git push public

t/t6041-bisect-submodule.sh
---------------------------
config.mak.uname defines TAR = gtar, but that obviously does not help

+ git_bisect add_sub1
tar: z: unknown option
tar: usage  tar [-]{txruc}[eONvVwAfblhm{op}][0-7[lmh]] [tapefile] [blocksize] [[-C directory] file] ...

changing my $PATH to have a GNU tar in front makes all tests pass


t/t7610-mergetool.sh
--------------------
HP-UX' mktemp obviously is not compatible with GNU mktemp (which I have
not installed/available on HP-UX)

 SYNOPSIS
      mktemp [-c] [-d directory_name] [-p prefix]

Resolved 'subdir/file3' using previous resolution.
Automatic merge failed; fix conflicts and then commit the result.
+ git mergetool --no-prompt --tool myecho -- both
+ 1> actual
error: mktemp is needed when 'mergetool.writeToTemp' is true
error: last command exited with $?=1
not ok 18 - temporary filenames are used with mergetool.writeToTemp


t/t7800-difftool.sh
-------------------
HP-UX doesn't have readlink

+ git difftool --dir-diff --symlink --extcmd ./.git/CHECK_SYMLINKS branch HEAD
./.git/CHECK_SYMLINKS: line 5: readlink: command not found
./.git/CHECK_SYMLINKS: line 5: readlink: command not found
./.git/CHECK_SYMLINKS: line 5: readlink: command not found
/pro/3gl/LINUX/git-2.3.0p/git-difftool line 472: No such file or directory
fatal: 'difftool' appears to be a git command, but we were not
able to execute it. Maybe git-difftool is broken?
error: last command exited with $?=128
not ok 49 - difftool --dir-diff --symlink without unstaged changes


t/t8005-blame-i18n.sh
---------------------
SJIS again, I DO NOT CARE!

+ 1> actual
+ test_cmp actual expected
actual expected differ: char 56, line 3
error: last command exited with $?=1
not ok 2 - blame respects i18n.commitencoding

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

H.Merijn Brand venit, vidit, dixit 18.02.2015 17:00:
> On Wed, 10 Dec 2014 23:46:25 -0800, Junio C Hamano <gitster@pobox.com>
> wrote:
> 
>> Hello, all.
>>
>> H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
>> source communities, wants help porting more recent Git on these
>> boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
>> volunteer.  Please contact him directly if you are interested.
> 
> No-one. Disappointing :(

Well, how can we help if we don't even know the limitations of that
platform?

In short, you are putting additional restrictions in by not having GNU
tools around.

> Did *anyone* ever test with NO_ICONV?
> Too many tests fail without iconv

There is iconv the library and iconv the command. With NO_ICONV, many
tests fail for me even on my standard Linux distro. But our tests keep
using iconv the command. The subtests which pass in t3900, for example,
mostly test that certain things fail, for one reason or another...

But we should guard a few tests in case of NO_ICONV, of course, and
probably not use iconv the command in this case either.

> 
> It is *very* hard to decide from the current status if all
> remaining failures are related to (Asian) locale failures and (thus)
> can be safely ignored (in my environment).
> 
> 
> Specifics at the end
> 
> 
> FAILures from scratch with no iconv:
> --------------------------------------------------------------------------------
> t3513-revert-submodule.sh       Tests: 14 Failed:  5 Failed tests: 1-2, 4, 6-7                   TODO passed:   10-11
> t3900-i18n-commit.sh            Tests: 34 Failed:  8 Failed tests: 15-17, 23-25, 27-28
> t3901-i18n-patch.sh             Tests: 15 Failed:  8 Failed tests: 2-3, 6-7, 9, 11, 14-15
> t4041-diff-submodule-option.sh  Tests: 44 Failed:  5 Failed tests: 5-7, 9-10
> t4201-shortlog.sh               Tests: 11 Failed:  1 Failed tests: 9
> t4204-patch-id.sh               Tests: 15 Failed:  3 Failed tests: 7, 10, 13
> t4205-log-pretty-formats.sh     Tests: 46 Failed: 20 Failed tests: 12-14, 17, 19, 21, 23-29, 31, 33, 35, 37 39, 41-42
> t4210-log-i18n.sh               Tests:  5 Failed:  4 Failed tests: 2-5
> t5100-mailinfo.sh               Tests: 35 Failed: 11 Failed tests: 20-30
> t5570-git-daemon.sh             Tests: 12 Failed:  2 Failed tests: 4-5      Parse errors: No plan found in TAP output
> t6006-rev-list-format.sh        Tests: 54 Failed: 11 Failed tests: 9-10, 12, 25-27, 30-34
> t6041-bisect-submodule.sh       Tests: 14 Failed:  9 Failed tests: 1-2, 4-7, 12-14               TODO passed:   10-11
> t7001-mv.sh                     Tests: 46 Failed:  2 Failed tests: 38-39
> t7102-reset.sh                  Tests: 30 Failed:  1 Failed tests: 2
> t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
> t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
> t8005-blame-i18n.sh             Tests:  5 Failed:  3 Failed tests: 2-4
> t9350-fast-export.sh            Tests: 34 Failed:  1 Failed tests: 4
> Files=687, Tests=12091
> 
> FAILures from scratch with iconv:
> --------------------------------------------------------------------------------
> t3513-revert-submodule.sh       Tests: 14 Failed:  5 Failed tests: 1-2, 4, 6-7                   TODO passed:   10-11
> t3900-i18n-commit.sh            Tests: 34 Failed:  6 Failed tests: 16-17, 24-25, 27-28
> t4204-patch-id.sh               Tests: 15 Failed:  3 Failed tests: 7, 10, 13
> t4210-log-i18n.sh               Tests:  5 Failed:  4 Failed tests: 2-5
> t5100-mailinfo.sh               Tests: 35 Failed:  2 Failed tests: 20, 23
> t5536-fetch-conflicts.sh        Tests:  7 Failed:  3 Failed tests: 3, 6-7
> t5570-git-daemon.sh             Tests: 12 Failed:  2 Failed tests: 4-5      Parse errors: No plan found in TAP output
> t6041-bisect-submodule.sh       Tests: 14 Failed:  9 Failed tests: 1-2, 4-7, 12-14               TODO passed:   10-11
> t7001-mv.sh                     Tests: 46 Failed:  2 Failed tests: 38-39
> t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
> t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
> t8005-blame-i18n.sh             Tests:  5 Failed:  3 Failed tests: 2-4
> Files=687, Tests=12091
> Result: FAIL
> 
> running «sh t****.sh -x -i»
> 
> 
> t/t7001-mv.t
> ------------
> cp uses -P flag, which is unknown to HP's (non-GNU) version of cp
> 
> Changing the two occurrences from
> 
> 		cp -R -P -p ../.git/modules/sub .git &&
> to
> 		rsync -aHl ../.git/modules/sub/ .git/ &&
> 
> make the tests pass (on those systems that have a working rsync)

"rsync -r -l -o -p -t" would be the proper equivalent. -aH does more for
my rsync. I don't know what HP-UX rsync understands, though.

> t/t3513-revert-submodule.sh
> ---------------------------
> tar uses z flag, which is unknown to HP's (non-GNU) version of tar
> config.mak.uname defines TAR = gtar, but that obviously does not help
> 
> putting GNU-tar temporary in from of my $PATH makes the test pass
> /me thinks the z in not required in that test at all
> 
> 	tar cf "$TRASH_DIRECTORY/tmp.tar" * &&
> and
> 	tar xf "$TRASH_DIRECTORY/tmp.tar" &&
> 
> work just as well and prevent the breakage

We can do without z.

> t/t3900-i18n-commit.sh
> ----------------------
> As my HP boxes have *NO* JP or other space eating asian locale stuff
> installed, it is highly likely that *anything* dealing with asian
> locales will fail. On modern Linux hardware, disk space is cheap. On
> most HP-UX boxes disk space is expensive and when having nothing to do
> with Asian languages, removing all Asian-related packages is a fast and
> cheap way to regain disk space.
> 
> Changing compare_with to
> 
> compare_with () {
>     case "$1$2$3" in
> 	*eucJP*|*ISO-2022-JP*) true ;;
> 	*)
> 	    git show -s $1 | sed -e '1,/^$/d' -e 's/^    //' >current &&
> 	    case "$3" in
> 		'')
> 		    test_cmp "$2" current ;;
> 		?*)
> 		    iconv -f "$3" -t UTF-8 >current.utf8 <current &&
> 		    iconv -f "$3" -t UTF-8 >expect.utf8 <"$2" &&
> 		    test_cmp expect.utf8 current.utf8
> 		    ;;
> 		esac
> 	    ;;
> 	esac
>     }
> 
> makes all my tests pass

So you do have iconv the command, but don't want to link with the library?

Availability of the locales should be covered by a prerequisite, like we
do in t9129.

> t/t4204-patch-id.sh
> -------------------
> 
> No idea yet
> 
> + test_patch_id_file_order irrelevant --stable --stable
> Already on 'same'
> cmp: patch-id_ordered-ordered-order---stable-irrelevant: No such file or directory
> 
> $ find * | grep 4204 | grep stable
> trash directory.t4204-patch-id/patch-id_order---stable-irrelevant
> trash directory.t4204-patch-id/patch-id_ordered-order---stable-irrelevant

The "Already"-part is normal output. The rest looks a bit crazy - and
shell related?

> t/t4210-log-i18n
> ----------------
> 
> $ dump "trash directory.t4210-log-i18n/actual"
> 00000000  75 74 66 38 0A                                      utf8.
> $ dump "trash directory.t4210-log-i18n/expect"
> 00000000  6C 61 74 69 6E 31 0A 75  74 66 38 0A                latin1.utf8.
> $ dump "trash directory.t4210-log-i18n/msg"
> 00000000  6C 61 74 69 6E 31 0A 0A  74 E9 73 74 0A             latin1..t.st.
> 
> t/t5100-mailinfo.sh
> -------------------
> + git mailinfo -u rfc2047/0001-msg rfc2047/0001-patch
> + 0< rfc2047/0001 1> rfc2047/0001-info
> fatal: cannot convert from US-ASCII to UTF-8
> error: last command exited with $?=128

Is that mailinfo erroring out? Do you have those locales?

OK, I'll have to stop fishing in the dark here.

> t/t5536-fetch-conflicts.sh
> --------------------------
> + setup_repository ccc +refs/heads/branch1:refs/remotes/origin/branch1 +refs/heads/branch2:refs/remotes/origin/branch1
> Initialized empty Git repository in /pro/3gl/LINUX/git-2.3.0p/t/trash directory.t5536-fetch-conflicts/ccc/.git/
> + cd ccc
> + test_must_fail git fetch origin
> + 2> error
> + verify_stderr
> + 0< /var/tmp/sh6096.2
> cmp: EOF on actual
> error: last command exited with $?=1
> not ok 3 - fetch conflict: config vs. config
> 
> t/t5570-git-daemon.sh
> ---------------------
> I will ignore this myself, as I have no intention of using HP-UX as a
> git server. We already have a dedicated Linux box doing so.
> 
> + test_cmp file clone/file
> ok 3 - clone git repository
> 
> expecting success:
>         echo content >>file &&
>         git commit -a -m two &&
>         git push public &&
>         (cd clone && git pull) &&
>         test_cmp file clone/file
> 
> + echo content
> + 1>> file
> + git commit -a -m two
> 
> arg sulong failed. 0, 0x9fffffffbffff058
> 
>  Setup args failed.
> 
> Pid 6238 was killed due to failure in writing to user register stack - possible stack overflow.
> [master bca99f0] two
>  Author: A U Thor <author@example.com>
>  1 file changed, 1 insertion(+)
> + git push public
> 
> t/t6041-bisect-submodule.sh
> ---------------------------
> config.mak.uname defines TAR = gtar, but that obviously does not help
> 
> + git_bisect add_sub1
> tar: z: unknown option
> tar: usage  tar [-]{txruc}[eONvVwAfblhm{op}][0-7[lmh]] [tapefile] [blocksize] [[-C directory] file] ...
> 
> changing my $PATH to have a GNU tar in front makes all tests pass
> 
> 
> t/t7610-mergetool.sh
> --------------------
> HP-UX' mktemp obviously is not compatible with GNU mktemp (which I have
> not installed/available on HP-UX)
> 
>  SYNOPSIS
>       mktemp [-c] [-d directory_name] [-p prefix]
> 
> Resolved 'subdir/file3' using previous resolution.
> Automatic merge failed; fix conflicts and then commit the result.
> + git mergetool --no-prompt --tool myecho -- both
> + 1> actual
> error: mktemp is needed when 'mergetool.writeToTemp' is true
> error: last command exited with $?=1
> not ok 18 - temporary filenames are used with mergetool.writeToTemp
> 
> 
> t/t7800-difftool.sh
> -------------------
> HP-UX doesn't have readlink
> 
> + git difftool --dir-diff --symlink --extcmd ./.git/CHECK_SYMLINKS branch HEAD
> ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> /pro/3gl/LINUX/git-2.3.0p/git-difftool line 472: No such file or directory
> fatal: 'difftool' appears to be a git command, but we were not
> able to execute it. Maybe git-difftool is broken?
> error: last command exited with $?=128
> not ok 49 - difftool --dir-diff --symlink without unstaged changes
> 
> 
> t/t8005-blame-i18n.sh
> ---------------------
> SJIS again, I DO NOT CARE!
> 
> + 1> actual
> + test_cmp actual expected
> actual expected differ: char 56, line 3
> error: last command exited with $?=1
> not ok 2 - blame respects i18n.commitencoding
> 

Re: Interested in helping open source friends on HP-UX?

[Jeff King]

On Wed, Feb 18, 2015 at 06:46:04PM +0100, Michael J Gruber wrote:

> >> H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
> >> source communities, wants help porting more recent Git on these
> >> boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
> >> volunteer.  Please contact him directly if you are interested.
> > 
> > No-one. Disappointing :(
> 
> Well, how can we help if we don't even know the limitations of that
> platform?

I'm not sure, but I think the original call for help may have been "I
will give you shell access to these boxes if you want to play around".

> > t/t7001-mv.t
> > ------------
> > cp uses -P flag, which is unknown to HP's (non-GNU) version of cp
> > 
> > Changing the two occurrences from
> > 
> > 		cp -R -P -p ../.git/modules/sub .git &&
> > to
> > 		rsync -aHl ../.git/modules/sub/ .git/ &&
> > 
> > make the tests pass (on those systems that have a working rsync)
> 
> "rsync -r -l -o -p -t" would be the proper equivalent. -aH does more for
> my rsync. I don't know what HP-UX rsync understands, though.

It seems like we could use

  (cd src && tar cf - .) | (cd dst && tar xf -)

here as a more portable alternative. I don't think we can rely on rsync
being everywhere.

-Peff

Re: Interested in helping open source friends on HP-UX?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Wed, Feb 18, 2015 at 06:46:04PM +0100, Michael J Gruber wrote:
>
>> Well, how can we help if we don't even know the limitations of that
>> platform?
>
> I'm not sure, but I think the original call for help may have been "I
> will give you shell access to these boxes if you want to play around".

Yeah, that probably was my bad---I didn't make it clear enough that the
request for volunteer from H.Merijn was exactly that.

> It seems like we could use
>
>   (cd src && tar cf - .) | (cd dst && tar xf -)
>
> here as a more portable alternative. I don't think we can rely on rsync
> being everywhere.

Thanks; I wasn't even aware that we used rsync in our tests.  We
certainly do not want to rely on it.

Why not "cp -r src dst", though?

Re: Interested in helping open source friends on HP-UX?

[Jeff King]

On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:

> > It seems like we could use
> >
> >   (cd src && tar cf - .) | (cd dst && tar xf -)
> >
> > here as a more portable alternative. I don't think we can rely on rsync
> > being everywhere.
> 
> Thanks; I wasn't even aware that we used rsync in our tests.  We
> certainly do not want to rely on it.

I don't think we do.

Grepping for rsync in t/, it is mentioned in three places:

  1. In t1509, we use it, but that test script does not run unless you
     set a bunch of environment variables to enable it.

  2. In a sample patch for t4100. Obviously this one doesn't execute. :)

  3. In t5500, to test "rsync:" protocol supported. This is behind a
     check that we can run rsync at all (though it does not properly use
     prereqs or use the normal "skip" procedure).

> Why not "cp -r src dst", though?

I was assuming that the "-P" in the original had some purpose. My "cp
-r" does not seem to dereference symlinks, but maybe there is something
I am missing.

-Peff

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

Jeff King venit, vidit, dixit 18.02.2015 19:57:
> On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:
> 
>>> It seems like we could use
>>>
>>>   (cd src && tar cf - .) | (cd dst && tar xf -)
>>>
>>> here as a more portable alternative. I don't think we can rely on rsync
>>> being everywhere.
>>
>> Thanks; I wasn't even aware that we used rsync in our tests.  We
>> certainly do not want to rely on it.
> 
> I don't think we do.
> 
> Grepping for rsync in t/, it is mentioned in three places:
> 
>   1. In t1509, we use it, but that test script does not run unless you
>      set a bunch of environment variables to enable it.
> 
>   2. In a sample patch for t4100. Obviously this one doesn't execute. :)
> 
>   3. In t5500, to test "rsync:" protocol supported. This is behind a
>      check that we can run rsync at all (though it does not properly use
>      prereqs or use the normal "skip" procedure).
> 
>> Why not "cp -r src dst", though?
> 
> I was assuming that the "-P" in the original had some purpose. My "cp
> -r" does not seem to dereference symlinks, but maybe there is something
> I am missing.
> 
> -Peff

There's a symlink in sub that needs to be preserved.

I'm cooking up a mini-series covering tar/cp -P so far and hopefully the
JP encodings later. Do I understand correctly that for Merijin's use
case on HP-UX, we want

- as few extra tools (GNU...) as possible for the run time git
- may get a few more tools installed to run the test

I still don't have a clear picture of the iconv situation: Does your
iconv library require OLD_ICONV to compile? Is there a reason you want
to disable it?

Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
sure we should care to protect so many tests with a prerequisite.

Michael

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 3468 bytes --]

On Thu, 19 Feb 2015 11:33:01 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> Jeff King venit, vidit, dixit 18.02.2015 19:57:
> > On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:
> > 
> >>> It seems like we could use
> >>>
> >>>   (cd src && tar cf - .) | (cd dst && tar xf -)
> >>>
> >>> here as a more portable alternative. I don't think we can rely on rsync
> >>> being everywhere.
> >>
> >> Thanks; I wasn't even aware that we used rsync in our tests.  We
> >> certainly do not want to rely on it.
> > 
> > I don't think we do.
> > 
> > Grepping for rsync in t/, it is mentioned in three places:
> > 
> >   1. In t1509, we use it, but that test script does not run unless you
> >      set a bunch of environment variables to enable it.
> > 
> >   2. In a sample patch for t4100. Obviously this one doesn't execute. :)
> > 
> >   3. In t5500, to test "rsync:" protocol supported. This is behind a
> >      check that we can run rsync at all (though it does not properly use
> >      prereqs or use the normal "skip" procedure).
> > 
> >> Why not "cp -r src dst", though?
> > 
> > I was assuming that the "-P" in the original had some purpose. My "cp
> > -r" does not seem to dereference symlinks, but maybe there is something
> > I am missing.
> > 
> > -Peff
> 
> There's a symlink in sub that needs to be preserved.
> 
> I'm cooking up a mini-series covering tar/cp -P so far and hopefully the
> JP encodings later. Do I understand correctly that for Merijin's use

Merijn, no second j. You can also call me Tux, as that is what the perl
people do just because of that :)

> case on HP-UX, we want
> 
> - as few extra tools (GNU...) as possible for the run time git
> - may get a few more tools installed to run the test

You can require as many GNU tools for testing as you like: I'll install
them. I just need to be sure they are not required runtime. (tar, cp)

> I still don't have a clear picture of the iconv situation: Does your
> iconv library require OLD_ICONV to compile?

No

> Is there a reason you want to disable it?

Yes, if I build a package/depot, and the package depends on iconv, it
is highly likely to fail on the client side after installation, as I do
not control the version of iconv/libiconv installed.

As HP does not have libiconv installed by default, I have experienced
many tools to be unusable after installation because of that dependency.

Another reason is that I built 64bitall, as my CURl and SSL environment
is 64bitall for every other project on these systems (including Oracle
related, which *only* ships 64bit objects on HP-UX) and the OpenSource
repos for HP-UX only ship 32bit software (sad, but true). That implies
that I cannot require libiconv.so to be present on the client side.

I'd like my git to be as standalone as possible

> Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
> sure we should care to protect so many tests with a prerequisite.

How feasible is it to isolate those tests into separate test files that
people that know to not use e.g. Asian can safely ignore them?

> Michael

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

H.Merijn Brand venit, vidit, dixit 19.02.2015 12:14:
> On Thu, 19 Feb 2015 11:33:01 +0100, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
> 
>> Jeff King venit, vidit, dixit 18.02.2015 19:57:
>>> On Wed, Feb 18, 2015 at 10:47:16AM -0800, Junio C Hamano wrote:
>>>
>>>>> It seems like we could use
>>>>>
>>>>>   (cd src && tar cf - .) | (cd dst && tar xf -)
>>>>>
>>>>> here as a more portable alternative. I don't think we can rely on rsync
>>>>> being everywhere.
>>>>
>>>> Thanks; I wasn't even aware that we used rsync in our tests.  We
>>>> certainly do not want to rely on it.
>>>
>>> I don't think we do.
>>>
>>> Grepping for rsync in t/, it is mentioned in three places:
>>>
>>>   1. In t1509, we use it, but that test script does not run unless you
>>>      set a bunch of environment variables to enable it.
>>>
>>>   2. In a sample patch for t4100. Obviously this one doesn't execute. :)
>>>
>>>   3. In t5500, to test "rsync:" protocol supported. This is behind a
>>>      check that we can run rsync at all (though it does not properly use
>>>      prereqs or use the normal "skip" procedure).
>>>
>>>> Why not "cp -r src dst", though?
>>>
>>> I was assuming that the "-P" in the original had some purpose. My "cp
>>> -r" does not seem to dereference symlinks, but maybe there is something
>>> I am missing.
>>>
>>> -Peff
>>
>> There's a symlink in sub that needs to be preserved.
>>
>> I'm cooking up a mini-series covering tar/cp -P so far and hopefully the
>> JP encodings later. Do I understand correctly that for Merijin's use
> 
> Merijn, no second j. You can also call me Tux, as that is what the perl
> people do just because of that :)
> 
>> case on HP-UX, we want
>>
>> - as few extra tools (GNU...) as possible for the run time git
>> - may get a few more tools installed to run the test
> 
> You can require as many GNU tools for testing as you like: I'll install
> them. I just need to be sure they are not required runtime. (tar, cp)
> 
>> I still don't have a clear picture of the iconv situation: Does your
>> iconv library require OLD_ICONV to compile?
> 
> No
> 
>> Is there a reason you want to disable it?
> 
> Yes, if I build a package/depot, and the package depends on iconv, it
> is highly likely to fail on the client side after installation, as I do
> not control the version of iconv/libiconv installed.
> 
> As HP does not have libiconv installed by default, I have experienced
> many tools to be unusable after installation because of that dependency.
> 
> Another reason is that I built 64bitall, as my CURl and SSL environment
> is 64bitall for every other project on these systems (including Oracle
> related, which *only* ships 64bit objects on HP-UX) and the OpenSource
> repos for HP-UX only ship 32bit software (sad, but true). That implies
> that I cannot require libiconv.so to be present on the client side.
> 
> I'd like my git to be as standalone as possible

OK, so we should use NO_ICONV on HP_UX then.

>> Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
>> sure we should care to protect so many tests with a prerequisite.
> 
> How feasible is it to isolate those tests into separate test files that
> people that know to not use e.g. Asian can safely ignore them?
> 
>> Michael

We have the prerequisite mechanism for that, and most probably, the
tests are "isolated" already, in the sense that with NO_ICONV, only
trivial setup tests succeed for those test files but all "proper" tests
fail. But I'll check. Need a good test to set the prerequisite, though.

Michael

Re: Interested in helping open source friends on HP-UX?

[Jeff King]

On Thu, Feb 19, 2015 at 12:20:02PM +0100, Michael J Gruber wrote:

> OK, so we should use NO_ICONV on HP_UX then.
> 
> >> Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
> >> sure we should care to protect so many tests with a prerequisite.
> > 
> > How feasible is it to isolate those tests into separate test files that
> > people that know to not use e.g. Asian can safely ignore them?
> 
> We have the prerequisite mechanism for that, and most probably, the
> tests are "isolated" already, in the sense that with NO_ICONV, only
> trivial setup tests succeed for those test files but all "proper" tests
> fail. But I'll check. Need a good test to set the prerequisite, though.

I took a first pass at this. The results are below (and I am hoping one
of you can use it as a base to build on, as I do not want to commit to
doing the second half, as you will see :) ).

It passes NO_ICONV through to the test suite, sets up a prerequisite,
disables some test scripts which are purely about i18n (e.g.,
t3900-i18n-commit), and marks some of the scripts with one-off tests
using the ICONV prereq.

Note that it also has some code changes around reencode_string_len.
These aren't strictly necessary, but they silence gcc warnings when
compiled with NO_ICONV. In that case we do:

  #define reencode_string_len(a,b,c,d,e) NULL

but "e" is an out-parameter. We don't promise it is valid if the
function returns NULL (which it does here). I'm kind of surprised the
compiler doesn't realize that:

  foo = reencode_string_len(...);
  if (foo)
	bar();

is dead code, since the first line becomes "foo = NULL". So that's
optional.

So, on to the tricky parts. Here are the failures that remain:

  1. The script builds up a commit history through the script, and later
     tests depend on this for things like commit timestamps or the exact
     shape of history. t9350 is an example of this (it has one failing
     test which can be marked, but then other tests later fail in
     confusing ways).

  2. The script creates commits with encoded commit messages, then uses
     those both for cases that care about the encoding, and those that
     do not. t4041 is an example here. I think it would be best to use
     vanilla commit mesages for the main body of tests, and then
     explicitly test the encoding-related features separately. I think
     t4205 and t6006 are in this boat, too.

I also tested this on a system with a working "iconv". If we are
building with NO_ICONV, I am tempted to say that there should be no need
to run the "iconv" command-line program at all. But t6006, for example,
does it a lot outside of any test_expect_*. Probably it should be:

  test_lazy_prereq ICONV '
	test -z "$NO_ICONV" &&
	utf8_o=$(printf "\303\263") &&
	latin1_o=$(printf "\363") &&
	test "$(echo $utf8_o | iconv -f UTF-8 -t ISO-8559-1)" = "$latin1_o"
  '

or something, and all of that setup should be wrapped in a
"test_expect_success ICONV ...". Of course that is the easy part. The
hard part is splitting the ICONV setup from the vanilla commit setup so
that the other tests can run.

---
diff --git a/Makefile b/Makefile
index e8ce649..c460ce8 100644
--- a/Makefile
+++ b/Makefile
@@ -2112,6 +2112,7 @@ endif
 ifdef GIT_TEST_CMP_USE_COPIED_CONTEXT
 	@echo GIT_TEST_CMP_USE_COPIED_CONTEXT=YesPlease >>$@
 endif
+	@echo NO_ICONV=\''$(subst ','\'',$(subst ','\'',$(NO_ICONV)))'\' >>$@
 	@echo NO_GETTEXT=\''$(subst ','\'',$(subst ','\'',$(NO_GETTEXT)))'\' >>$@
 	@echo GETTEXT_POISON=\''$(subst ','\'',$(subst ','\'',$(GETTEXT_POISON)))'\' >>$@
 ifdef GIT_PERF_REPEAT_COUNT
diff --git a/pretty.c b/pretty.c
index 9d34d02..74fe5fb 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1497,7 +1497,7 @@ void format_commit_message(const struct commit *commit,
 	}
 
 	if (output_enc) {
-		int outsz;
+		int outsz = 0;
 		char *out = reencode_string_len(sb->buf, sb->len,
 						output_enc, utf8, &outsz);
 		if (out)
diff --git a/strbuf.c b/strbuf.c
index 88cafd4..6d8ad4b 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -94,7 +94,7 @@ void strbuf_ltrim(struct strbuf *sb)
 int strbuf_reencode(struct strbuf *sb, const char *from, const char *to)
 {
 	char *out;
-	int len;
+	int len = 0;
 
 	if (same_encoding(from, to))
 		return 0;
diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
index 4bf1dbe..d522677 100755
--- a/t/t3900-i18n-commit.sh
+++ b/t/t3900-i18n-commit.sh
@@ -7,6 +7,11 @@ test_description='commit and log output encodings'
 
 . ./test-lib.sh
 
+if ! test_have_prereq ICONV; then
+	skip_all='skipping i18n tests, iconv not available'
+	test_done
+fi
+
 compare_with () {
 	git show -s $1 | sed -e '1,/^$/d' -e 's/^    //' >current &&
 	case "$3" in
diff --git a/t/t3901-i18n-patch.sh b/t/t3901-i18n-patch.sh
index a392f3d..c4f9d06 100755
--- a/t/t3901-i18n-patch.sh
+++ b/t/t3901-i18n-patch.sh
@@ -7,6 +7,11 @@ test_description='i18n settings and format-patch | am pipe'
 
 . ./test-lib.sh
 
+if ! test_have_prereq ICONV; then
+	skip_all='skipping i18n tests, iconv not available'
+	test_done
+fi
+
 check_encoding () {
 	# Make sure characters are not corrupted
 	cnt="$1" header="$2" i=1 j=0 bad=0
diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
index 7600a3e..6ac7150 100755
--- a/t/t4201-shortlog.sh
+++ b/t/t4201-shortlog.sh
@@ -159,7 +159,7 @@ $DSCHO (2):
 
 EOF
 
-test_expect_success !MINGW 'shortlog encoding' '
+test_expect_success !MINGW,ICONV 'shortlog encoding' '
 	git reset --hard "$commit" &&
 	git config --unset i18n.commitencoding &&
 	echo 2 > a1 &&
diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
index e585fe6..12b82f9 100755
--- a/t/t4210-log-i18n.sh
+++ b/t/t4210-log-i18n.sh
@@ -3,6 +3,11 @@
 test_description='test log with i18n features'
 . ./test-lib.sh
 
+if ! test_have_prereq ICONV; then
+	skip_all='skipping i18n tests, iconv not available'
+	test_done
+fi
+
 # two forms of é
 utf8_e=$(printf '\303\251')
 latin1_e=$(printf '\351')
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 60df10f..d904696 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -53,7 +53,7 @@ test_expect_success 'split box with rfc2047 samples' \
 
 for mail in `echo rfc2047/00*`
 do
-	test_expect_success "mailinfo $mail" '
+	test_expect_success ICONV "mailinfo $mail" '
 		git mailinfo -u $mail-msg $mail-patch <$mail >$mail-info &&
 		echo msg &&
 		test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-msg &&
diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh
index 6da9422..fde4fbb 100755
--- a/t/t5550-http-fetch-dumb.sh
+++ b/t/t5550-http-fetch-dumb.sh
@@ -204,12 +204,12 @@ test_expect_success 'git client shows text/plain with a charset' '
 	grep "this is the error message" stderr
 '
 
-test_expect_success 'http error messages are reencoded' '
+test_expect_success ICONV 'http error messages are reencoded' '
 	test_must_fail git clone "$HTTPD_URL/error/utf16" 2>stderr &&
 	grep "this is the error message" stderr
 '
 
-test_expect_success 'reencoding is robust to whitespace oddities' '
+test_expect_success ICONV 'reencoding is robust to whitespace oddities' '
 	test_must_fail git clone "$HTTPD_URL/error/odd-spacing" 2>stderr &&
 	grep "this is the error message" stderr
 '
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index 98bcfe2..a7168d3 100755
--- a/t/t7102-reset.sh
+++ b/t/t7102-reset.sh
@@ -62,14 +62,14 @@ check_changes () {
 	done | test_cmp .cat_expect -
 }
 
-test_expect_success 'reset --hard message' '
+test_expect_success ICONV 'reset --hard message' '
 	hex=$(git log -1 --format="%h") &&
 	git reset --hard > .actual &&
 	echo HEAD is now at $hex $(commit_msg) > .expected &&
 	test_cmp .expected .actual
 '
 
-test_expect_success 'reset --hard message (ISO8859-1 logoutputencoding)' '
+test_expect_success ICONV 'reset --hard message (ISO8859-1 logoutputencoding)' '
 	hex=$(git log -1 --format="%h") &&
 	git -c "i18n.logOutputEncoding=$test_encoding" reset --hard > .actual &&
 	echo HEAD is now at $hex $(commit_msg $test_encoding) > .expected &&
diff --git a/t/t8005-blame-i18n.sh b/t/t8005-blame-i18n.sh
index 847d098..8c3ab28 100755
--- a/t/t8005-blame-i18n.sh
+++ b/t/t8005-blame-i18n.sh
@@ -3,6 +3,11 @@
 test_description='git blame encoding conversion'
 . ./test-lib.sh
 
+if ! test_have_prereq ICONV; then
+	skip_all='skipping i18n tests, iconv not available'
+	test_done
+fi
+
 . "$TEST_DIRECTORY"/t8005/utf8.txt
 . "$TEST_DIRECTORY"/t8005/euc-japan.txt
 . "$TEST_DIRECTORY"/t8005/sjis.txt
diff --git a/t/test-lib.sh b/t/test-lib.sh
index bb1402d..cef41a8 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -940,6 +940,7 @@ test -z "$NO_PERL" && test_set_prereq PERL
 test -z "$NO_PYTHON" && test_set_prereq PYTHON
 test -n "$USE_LIBPCRE" && test_set_prereq LIBPCRE
 test -z "$NO_GETTEXT" && test_set_prereq GETTEXT
+test -z "$NO_ICONV" && test_set_prereq ICONV
 
 # Can we rely on git's output in the C locale?
 if test -n "$GETTEXT_POISON"

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

Jeff King venit, vidit, dixit 19.02.2015 13:54:
> On Thu, Feb 19, 2015 at 12:20:02PM +0100, Michael J Gruber wrote:
> 
>> OK, so we should use NO_ICONV on HP_UX then.
>>
>>>> Failing so many tests with NO_ICONV is certainly not ideal, but I'm not
>>>> sure we should care to protect so many tests with a prerequisite.
>>>
>>> How feasible is it to isolate those tests into separate test files that
>>> people that know to not use e.g. Asian can safely ignore them?
>>
>> We have the prerequisite mechanism for that, and most probably, the
>> tests are "isolated" already, in the sense that with NO_ICONV, only
>> trivial setup tests succeed for those test files but all "proper" tests
>> fail. But I'll check. Need a good test to set the prerequisite, though.
> 
> I took a first pass at this. The results are below (and I am hoping one
> of you can use it as a base to build on, as I do not want to commit to
> doing the second half, as you will see :) ).
> 
> It passes NO_ICONV through to the test suite, sets up a prerequisite,
> disables some test scripts which are purely about i18n (e.g.,
> t3900-i18n-commit), and marks some of the scripts with one-off tests
> using the ICONV prereq.

Hmm. I know we pass other stuff down, but is this really a good idea? It
relies on the fact that the git that we test was built with the options
from there. This assumptions breaks (with) GIT_TEST_INSTALLED, if not more.

Basically, it may break as soon as we run the tests by other means than
"make", which is quite customary if you run single tests.

(And we do pass config.mak down, me thinks, but NO_ICONV may come from
the command line.)

> Note that it also has some code changes around reencode_string_len.
> These aren't strictly necessary, but they silence gcc warnings when
> compiled with NO_ICONV. In that case we do:
> 
>   #define reencode_string_len(a,b,c,d,e) NULL
> 
> but "e" is an out-parameter. We don't promise it is valid if the
> function returns NULL (which it does here). I'm kind of surprised the
> compiler doesn't realize that:
> 
>   foo = reencode_string_len(...);
>   if (foo)
> 	bar();
> 
> is dead code, since the first line becomes "foo = NULL". So that's
> optional.
> 
> So, on to the tricky parts. Here are the failures that remain:
> 
>   1. The script builds up a commit history through the script, and later
>      tests depend on this for things like commit timestamps or the exact
>      shape of history. t9350 is an example of this (it has one failing
>      test which can be marked, but then other tests later fail in
>      confusing ways).
> 
>   2. The script creates commits with encoded commit messages, then uses
>      those both for cases that care about the encoding, and those that
>      do not. t4041 is an example here. I think it would be best to use
>      vanilla commit mesages for the main body of tests, and then
>      explicitly test the encoding-related features separately. I think
>      t4205 and t6006 are in this boat, too.
> 
> I also tested this on a system with a working "iconv". If we are
> building with NO_ICONV, I am tempted to say that there should be no need
> to run the "iconv" command-line program at all. But t6006, for example,
> does it a lot outside of any test_expect_*. Probably it should be:
> 
>   test_lazy_prereq ICONV '
> 	test -z "$NO_ICONV" &&
> 	utf8_o=$(printf "\303\263") &&
> 	latin1_o=$(printf "\363") &&
> 	test "$(echo $utf8_o | iconv -f UTF-8 -t ISO-8559-1)" = "$latin1_o"
>   '
> 
> or something, and all of that setup should be wrapped in a
> "test_expect_success ICONV ...". Of course that is the easy part. The
> hard part is splitting the ICONV setup from the vanilla commit setup so
> that the other tests can run.

Jeff, you got it wrong. You should do the hard part and leave the easy
part to us!

Thanks anyways, I'll add this to my HP_UX branch.

> ---
> diff --git a/Makefile b/Makefile
> index e8ce649..c460ce8 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2112,6 +2112,7 @@ endif
>  ifdef GIT_TEST_CMP_USE_COPIED_CONTEXT
>  	@echo GIT_TEST_CMP_USE_COPIED_CONTEXT=YesPlease >>$@
>  endif
> +	@echo NO_ICONV=\''$(subst ','\'',$(subst ','\'',$(NO_ICONV)))'\' >>$@
>  	@echo NO_GETTEXT=\''$(subst ','\'',$(subst ','\'',$(NO_GETTEXT)))'\' >>$@
>  	@echo GETTEXT_POISON=\''$(subst ','\'',$(subst ','\'',$(GETTEXT_POISON)))'\' >>$@
>  ifdef GIT_PERF_REPEAT_COUNT
> diff --git a/pretty.c b/pretty.c
> index 9d34d02..74fe5fb 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1497,7 +1497,7 @@ void format_commit_message(const struct commit *commit,
>  	}
>  
>  	if (output_enc) {
> -		int outsz;
> +		int outsz = 0;
>  		char *out = reencode_string_len(sb->buf, sb->len,
>  						output_enc, utf8, &outsz);
>  		if (out)
> diff --git a/strbuf.c b/strbuf.c
> index 88cafd4..6d8ad4b 100644
> --- a/strbuf.c
> +++ b/strbuf.c
> @@ -94,7 +94,7 @@ void strbuf_ltrim(struct strbuf *sb)
>  int strbuf_reencode(struct strbuf *sb, const char *from, const char *to)
>  {
>  	char *out;
> -	int len;
> +	int len = 0;
>  
>  	if (same_encoding(from, to))
>  		return 0;
> diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
> index 4bf1dbe..d522677 100755
> --- a/t/t3900-i18n-commit.sh
> +++ b/t/t3900-i18n-commit.sh
> @@ -7,6 +7,11 @@ test_description='commit and log output encodings'
>  
>  . ./test-lib.sh
>  
> +if ! test_have_prereq ICONV; then
> +	skip_all='skipping i18n tests, iconv not available'
> +	test_done
> +fi
> +
>  compare_with () {
>  	git show -s $1 | sed -e '1,/^$/d' -e 's/^    //' >current &&
>  	case "$3" in
> diff --git a/t/t3901-i18n-patch.sh b/t/t3901-i18n-patch.sh
> index a392f3d..c4f9d06 100755
> --- a/t/t3901-i18n-patch.sh
> +++ b/t/t3901-i18n-patch.sh
> @@ -7,6 +7,11 @@ test_description='i18n settings and format-patch | am pipe'
>  
>  . ./test-lib.sh
>  
> +if ! test_have_prereq ICONV; then
> +	skip_all='skipping i18n tests, iconv not available'
> +	test_done
> +fi
> +
>  check_encoding () {
>  	# Make sure characters are not corrupted
>  	cnt="$1" header="$2" i=1 j=0 bad=0
> diff --git a/t/t4201-shortlog.sh b/t/t4201-shortlog.sh
> index 7600a3e..6ac7150 100755
> --- a/t/t4201-shortlog.sh
> +++ b/t/t4201-shortlog.sh
> @@ -159,7 +159,7 @@ $DSCHO (2):
>  
>  EOF
>  
> -test_expect_success !MINGW 'shortlog encoding' '
> +test_expect_success !MINGW,ICONV 'shortlog encoding' '
>  	git reset --hard "$commit" &&
>  	git config --unset i18n.commitencoding &&
>  	echo 2 > a1 &&
> diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
> index e585fe6..12b82f9 100755
> --- a/t/t4210-log-i18n.sh
> +++ b/t/t4210-log-i18n.sh
> @@ -3,6 +3,11 @@
>  test_description='test log with i18n features'
>  . ./test-lib.sh
>  
> +if ! test_have_prereq ICONV; then
> +	skip_all='skipping i18n tests, iconv not available'
> +	test_done
> +fi
> +
>  # two forms of é
>  utf8_e=$(printf '\303\251')
>  latin1_e=$(printf '\351')
> diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
> index 60df10f..d904696 100755
> --- a/t/t5100-mailinfo.sh
> +++ b/t/t5100-mailinfo.sh
> @@ -53,7 +53,7 @@ test_expect_success 'split box with rfc2047 samples' \
>  
>  for mail in `echo rfc2047/00*`
>  do
> -	test_expect_success "mailinfo $mail" '
> +	test_expect_success ICONV "mailinfo $mail" '
>  		git mailinfo -u $mail-msg $mail-patch <$mail >$mail-info &&
>  		echo msg &&
>  		test_cmp "$TEST_DIRECTORY"/t5100/empty $mail-msg &&
> diff --git a/t/t5550-http-fetch-dumb.sh b/t/t5550-http-fetch-dumb.sh
> index 6da9422..fde4fbb 100755
> --- a/t/t5550-http-fetch-dumb.sh
> +++ b/t/t5550-http-fetch-dumb.sh
> @@ -204,12 +204,12 @@ test_expect_success 'git client shows text/plain with a charset' '
>  	grep "this is the error message" stderr
>  '
>  
> -test_expect_success 'http error messages are reencoded' '
> +test_expect_success ICONV 'http error messages are reencoded' '
>  	test_must_fail git clone "$HTTPD_URL/error/utf16" 2>stderr &&
>  	grep "this is the error message" stderr
>  '
>  
> -test_expect_success 'reencoding is robust to whitespace oddities' '
> +test_expect_success ICONV 'reencoding is robust to whitespace oddities' '
>  	test_must_fail git clone "$HTTPD_URL/error/odd-spacing" 2>stderr &&
>  	grep "this is the error message" stderr
>  '
> diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
> index 98bcfe2..a7168d3 100755
> --- a/t/t7102-reset.sh
> +++ b/t/t7102-reset.sh
> @@ -62,14 +62,14 @@ check_changes () {
>  	done | test_cmp .cat_expect -
>  }
>  
> -test_expect_success 'reset --hard message' '
> +test_expect_success ICONV 'reset --hard message' '
>  	hex=$(git log -1 --format="%h") &&
>  	git reset --hard > .actual &&
>  	echo HEAD is now at $hex $(commit_msg) > .expected &&
>  	test_cmp .expected .actual
>  '
>  
> -test_expect_success 'reset --hard message (ISO8859-1 logoutputencoding)' '
> +test_expect_success ICONV 'reset --hard message (ISO8859-1 logoutputencoding)' '
>  	hex=$(git log -1 --format="%h") &&
>  	git -c "i18n.logOutputEncoding=$test_encoding" reset --hard > .actual &&
>  	echo HEAD is now at $hex $(commit_msg $test_encoding) > .expected &&
> diff --git a/t/t8005-blame-i18n.sh b/t/t8005-blame-i18n.sh
> index 847d098..8c3ab28 100755
> --- a/t/t8005-blame-i18n.sh
> +++ b/t/t8005-blame-i18n.sh
> @@ -3,6 +3,11 @@
>  test_description='git blame encoding conversion'
>  . ./test-lib.sh
>  
> +if ! test_have_prereq ICONV; then
> +	skip_all='skipping i18n tests, iconv not available'
> +	test_done
> +fi
> +
>  . "$TEST_DIRECTORY"/t8005/utf8.txt
>  . "$TEST_DIRECTORY"/t8005/euc-japan.txt
>  . "$TEST_DIRECTORY"/t8005/sjis.txt
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index bb1402d..cef41a8 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -940,6 +940,7 @@ test -z "$NO_PERL" && test_set_prereq PERL
>  test -z "$NO_PYTHON" && test_set_prereq PYTHON
>  test -n "$USE_LIBPCRE" && test_set_prereq LIBPCRE
>  test -z "$NO_GETTEXT" && test_set_prereq GETTEXT
> +test -z "$NO_ICONV" && test_set_prereq ICONV
>  
>  # Can we rely on git's output in the C locale?
>  if test -n "$GETTEXT_POISON"
> 

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> Jeff, you got it wrong. You should do the hard part and leave the easy
> part to us!
> 
> Thanks anyways, I'll add this to my HP_UX branch.

I did not mention this in earlier mails. When using the HP C-ANSI-C
compiler, MAX_INT is not set.

I had to add
--8<---
#ifndef   SIZE_MAX
#  define SIZE_MAX              (18446744073709551615UL)
/* define SIZE_MAX              (4294967295U) */
#  endif
-->8---

to these files

sha1_file.c
utf8.c
walker.c
wrapper.c

And yes, that could be dynamic and probably be in another header file

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56:
> On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
> 
>> Jeff, you got it wrong. You should do the hard part and leave the easy
>> part to us!
>>
>> Thanks anyways, I'll add this to my HP_UX branch.
> 
> I did not mention this in earlier mails. When using the HP C-ANSI-C
> compiler, MAX_INT is not set.
> 
> I had to add
> --8<---
> #ifndef   SIZE_MAX
> #  define SIZE_MAX              (18446744073709551615UL)
> /* define SIZE_MAX              (4294967295U) */
> #  endif
> -->8---
> 
> to these files
> 
> sha1_file.c
> utf8.c
> walker.c
> wrapper.c
> 
> And yes, that could be dynamic and probably be in another header file
> 

In compat/regex/regex_internal.h we have

/* For loser systems without the definition.  */
#ifndef SIZE_MAX
# define SIZE_MAX ((size_t) -1)
#endif

Does this work in your environment?

[Trying to not let this fall into oblivion...]

Michael

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 2446 bytes --]

On Tue, 03 Mar 2015 15:55:48 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56:
> > On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber
> > <git@drmicha.warpmail.net> wrote:
> > 
> >> Jeff, you got it wrong. You should do the hard part and leave the easy
> >> part to us!
> >>
> >> Thanks anyways, I'll add this to my HP_UX branch.
> > 
> > I did not mention this in earlier mails. When using the HP C-ANSI-C
> > compiler, MAX_INT is not set.
> > 
> > I had to add
> > --8<---
> > #ifndef   SIZE_MAX
> > #  define SIZE_MAX              (18446744073709551615UL)
> > /* define SIZE_MAX              (4294967295U) */
> > #  endif
> > -->8---
> > 
> > to these files
> > 
> > sha1_file.c
> > utf8.c
> > walker.c
> > wrapper.c
> > 
> > And yes, that could be dynamic and probably be in another header file
> > 
> 
> In compat/regex/regex_internal.h we have
> 
> /* For loser systems without the definition.  */
> #ifndef SIZE_MAX
> # define SIZE_MAX ((size_t) -1)
> #endif
> 
> Does this work in your environment?

I think it does:

make
    CC sha1_file.o
    CC utf8.o
    CC walker.o
"walker.c", line 119: warning #4232-D: conversion from "struct object *" to a
          more strictly aligned type "struct commit *" may cause misaligned
          access
                if (process_commit(walker, (struct commit *)obj))
                                           ^

"walker.c", line 124: warning #4232-D: conversion from "struct object *" to a
          more strictly aligned type "struct tree *" may cause misaligned
          access
                if (process_tree(walker, (struct tree *)obj))
                                         ^

"walker.c", line 132: warning #4232-D: conversion from "struct object *" to a
          more strictly aligned type "struct tag *" may cause misaligned access
                if (process_tag(walker, (struct tag *)obj))
                                        ^

    CC wrapper.o
    AR libgit.a


> [Trying to not let this fall into oblivion...]

Much appreciated!

> Michael


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

H.Merijn Brand venit, vidit, dixit 03.03.2015 16:30:
> On Tue, 03 Mar 2015 15:55:48 +0100, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
> 
>> H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56:
>>> On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber
>>> <git@drmicha.warpmail.net> wrote:
>>>
>>>> Jeff, you got it wrong. You should do the hard part and leave the easy
>>>> part to us!
>>>>
>>>> Thanks anyways, I'll add this to my HP_UX branch.
>>>
>>> I did not mention this in earlier mails. When using the HP C-ANSI-C
>>> compiler, MAX_INT is not set.
>>>
>>> I had to add
>>> --8<---
>>> #ifndef   SIZE_MAX
>>> #  define SIZE_MAX              (18446744073709551615UL)
>>> /* define SIZE_MAX              (4294967295U) */
>>> #  endif
>>> -->8---
>>>
>>> to these files
>>>
>>> sha1_file.c
>>> utf8.c
>>> walker.c
>>> wrapper.c
>>>
>>> And yes, that could be dynamic and probably be in another header file
>>>
>>
>> In compat/regex/regex_internal.h we have
>>
>> /* For loser systems without the definition.  */
>> #ifndef SIZE_MAX
>> # define SIZE_MAX ((size_t) -1)
>> #endif
>>
>> Does this work in your environment?
> 
> I think it does:
> 
> make
>     CC sha1_file.o
>     CC utf8.o
>     CC walker.o
> "walker.c", line 119: warning #4232-D: conversion from "struct object *" to a
>           more strictly aligned type "struct commit *" may cause misaligned
>           access
>                 if (process_commit(walker, (struct commit *)obj))
>                                            ^
> 
> "walker.c", line 124: warning #4232-D: conversion from "struct object *" to a
>           more strictly aligned type "struct tree *" may cause misaligned
>           access
>                 if (process_tree(walker, (struct tree *)obj))
>                                          ^
> 
> "walker.c", line 132: warning #4232-D: conversion from "struct object *" to a
>           more strictly aligned type "struct tag *" may cause misaligned access
>                 if (process_tag(walker, (struct tag *)obj))
>                                         ^
> 
>     CC wrapper.o
>     AR libgit.a
> 
> 

Hmmh. Did you get these same warnings with the fix you had before? They
don't make feel that confident...

>> [Trying to not let this fall into oblivion...]
> 
> Much appreciated!
> 
>> Michael
> 
> 

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 2969 bytes --]

On Tue, 03 Mar 2015 17:05:53 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> H.Merijn Brand venit, vidit, dixit 03.03.2015 16:30:
> > On Tue, 03 Mar 2015 15:55:48 +0100, Michael J Gruber
> > <git@drmicha.warpmail.net> wrote:
> > 
> >> H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56:
> >>> On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber
> >>> <git@drmicha.warpmail.net> wrote:
> >>>
> >>>> Jeff, you got it wrong. You should do the hard part and leave the easy
> >>>> part to us!
> >>>>
> >>>> Thanks anyways, I'll add this to my HP_UX branch.
> >>>
> >>> I did not mention this in earlier mails. When using the HP C-ANSI-C
> >>> compiler, MAX_INT is not set.
> >>>
> >>> I had to add
> >>> --8<---
> >>> #ifndef   SIZE_MAX
> >>> #  define SIZE_MAX              (18446744073709551615UL)
> >>> /* define SIZE_MAX              (4294967295U) */
> >>> #  endif
> >>> -->8---
> >>>
> >>> to these files
> >>>
> >>> sha1_file.c
> >>> utf8.c
> >>> walker.c
> >>> wrapper.c
> >>>
> >>> And yes, that could be dynamic and probably be in another header file
> >>>
> >>
> >> In compat/regex/regex_internal.h we have
> >>
> >> /* For loser systems without the definition.  */
> >> #ifndef SIZE_MAX
> >> # define SIZE_MAX ((size_t) -1)
> >> #endif
> >>
> >> Does this work in your environment?
> > 
> > I think it does:
> > 
> > make
> >     CC sha1_file.o
> >     CC utf8.o
> >     CC walker.o
> > "walker.c", line 119: warning #4232-D: conversion from "struct object *" to a
> >           more strictly aligned type "struct commit *" may cause misaligned
> >           access
> >                 if (process_commit(walker, (struct commit *)obj))
> >                                            ^
> > 
> > "walker.c", line 124: warning #4232-D: conversion from "struct object *" to a
> >           more strictly aligned type "struct tree *" may cause misaligned
> >           access
> >                 if (process_tree(walker, (struct tree *)obj))
> >                                          ^
> > 
> > "walker.c", line 132: warning #4232-D: conversion from "struct object *" to a
> >           more strictly aligned type "struct tag *" may cause misaligned access
> >                 if (process_tag(walker, (struct tag *)obj))
> >                                         ^
> > 
> >     CC wrapper.o
> >     AR libgit.a
> > 
> > 
> 
> Hmmh. Did you get these same warnings with the fix you had before? They
> don't make feel that confident...

Yes, these are unrelated to SIZE_MAX

> >> [Trying to not let this fall into oblivion...]
> > 
> > Much appreciated!
> > 
> >> Michael


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[Jeff King]

On Thu, Feb 19, 2015 at 02:21:11PM +0100, Michael J Gruber wrote:

> > It passes NO_ICONV through to the test suite, sets up a prerequisite,
> > disables some test scripts which are purely about i18n (e.g.,
> > t3900-i18n-commit), and marks some of the scripts with one-off tests
> > using the ICONV prereq.
> 
> Hmm. I know we pass other stuff down, but is this really a good idea? It
> relies on the fact that the git that we test was built with the options
> from there. This assumptions breaks (with) GIT_TEST_INSTALLED, if not more.
> 
> Basically, it may break as soon as we run the tests by other means than
> "make", which is quite customary if you run single tests.
> 
> (And we do pass config.mak down, me thinks, but NO_ICONV may come from
> the command line.)

It's not quite so bad as you make out. We write the value to the
GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
load that in test-lib.sh. So:

  make NO_ICONV=Nope
  cd t
  ./t3901-i18n-patch.sh

works just fine (for this and for any of the other options we mark
there).

It won't work for GIT_TEST_INSTALLED, but that is not a new problem.
Fundamentally you cannot expect to test a version built without option X
without telling git _somehow_ that it was built that way.

I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
would have complained before. But if we really want to support it, I
think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
that "git --build-options" dumps it. It might also have value for
debugging and forensics in general.

> Jeff, you got it wrong. You should do the hard part and leave the easy
> part to us!

Oops. :)

-Peff

Re: Interested in helping open source friends on HP-UX?

[Michael J Gruber]

Jeff King venit, vidit, dixit 20.02.2015 02:48:
> On Thu, Feb 19, 2015 at 02:21:11PM +0100, Michael J Gruber wrote:
> 
>>> It passes NO_ICONV through to the test suite, sets up a prerequisite,
>>> disables some test scripts which are purely about i18n (e.g.,
>>> t3900-i18n-commit), and marks some of the scripts with one-off tests
>>> using the ICONV prereq.
>>
>> Hmm. I know we pass other stuff down, but is this really a good idea? It
>> relies on the fact that the git that we test was built with the options
>> from there. This assumptions breaks (with) GIT_TEST_INSTALLED, if not more.
>>
>> Basically, it may break as soon as we run the tests by other means than
>> "make", which is quite customary if you run single tests.
>>
>> (And we do pass config.mak down, me thinks, but NO_ICONV may come from
>> the command line.)
> 
> It's not quite so bad as you make out. We write the value to the
> GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
> load that in test-lib.sh. So:
> 
>   make NO_ICONV=Nope
>   cd t
>   ./t3901-i18n-patch.sh
> 
> works just fine (for this and for any of the other options we mark
> there).

It survives a cd, sure... Now, change your config.mak before the cd and
forget the make. Not everyone does

make -C t t3901-i18n-patch.sh

Though, having just discovered that shell completion works for that
form, too, I may do it more often (and then complain about having to use
GIT_TEST_OPTS ;) )

> It won't work for GIT_TEST_INSTALLED, but that is not a new problem.
> Fundamentally you cannot expect to test a version built without option X
> without telling git _somehow_ that it was built that way.
> 
> I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
> would have complained before. But if we really want to support it, I
> think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
> that "git --build-options" dumps it. It might also have value for
> debugging and forensics in general.

Yep, that would be helpful in general. I don't think we should worry
about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?

Michael

Re: Interested in helping open source friends on HP-UX?

[Jeff King]

On Fri, Feb 20, 2015 at 11:36:27AM +0100, Michael J Gruber wrote:

> > It's not quite so bad as you make out. We write the value to the
> > GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
> > load that in test-lib.sh. So:
> > 
> >   make NO_ICONV=Nope
> >   cd t
> >   ./t3901-i18n-patch.sh
> > 
> > works just fine (for this and for any of the other options we mark
> > there).
> 
> It survives a cd, sure...

I think the interesting thing is that it survives running `./tXXXX`
rather than running the test through make.

> Now, change your config.mak before the cd and
> forget the make. Not everyone does
> 
> make -C t t3901-i18n-patch.sh
> 
> Though, having just discovered that shell completion works for that
> form, too, I may do it more often (and then complain about having to use
> GIT_TEST_OPTS ;) )

Yeah, I never use "make tXXXX" myself. But nor would I expect the tests
to respect a version of git I had not actually built. E.g., if you build
with NO_PERL, and then remove NO_PERL from your config.mak but do _not_
actually run "make", should that work? Ditto for NO_ICONV, for that
matter. The tests must match the binary, and the best guess we have
about the binary is the last thing we built.

Adding "git --build-options" would give us a better guess (it may not be
what the user _wanted_ to test, but it is what they _are_ testing).

> > I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
> > would have complained before. But if we really want to support it, I
> > think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
> > that "git --build-options" dumps it. It might also have value for
> > debugging and forensics in general.
> 
> Yep, that would be helpful in general. I don't think we should worry
> about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?

Clearly a crazy person. :) I am not saying it is a _bad_ idea. Only that
the responsibility to make sure the installed version matches the
current build parameters lies with the user (and for that matter, the
current set of tests; we add new tests that would fail on old versions,
and you cannot mix and match).

So an alternate explanation than "not widely used" is "all of the users
of it are responsible individuals who do not make bogus bug reports to
the list". :)

-Peff

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

On Fri, 20 Feb 2015 05:49:21 -0500, Jeff King <peff@peff.net> wrote:

> On Fri, Feb 20, 2015 at 11:36:27AM +0100, Michael J Gruber wrote:
> 
> > > It's not quite so bad as you make out. We write the value to the
> > > GIT-BUILD-OPTIONS file during "make", no matter where it comes from, and
> > > load that in test-lib.sh. So:
> > > 
> > >   make NO_ICONV=Nope
> > >   cd t
> > >   ./t3901-i18n-patch.sh
> > > 
> > > works just fine (for this and for any of the other options we mark
> > > there).
> > 
> > It survives a cd, sure...
> 
> I think the interesting thing is that it survives running `./tXXXX`
> rather than running the test through make.

I always use prove

$ prove -v t1234.sh

> > Now, change your config.mak before the cd and
> > forget the make. Not everyone does
> > 
> > make -C t t3901-i18n-patch.sh
> > 
> > Though, having just discovered that shell completion works for that
> > form, too, I may do it more often (and then complain about having to use
> > GIT_TEST_OPTS ;) )
> 
> Yeah, I never use "make tXXXX" myself. But nor would I expect the tests
> to respect a version of git I had not actually built. E.g., if you build
> with NO_PERL, and then remove NO_PERL from your config.mak but do _not_
> actually run "make", should that work? Ditto for NO_ICONV, for that
> matter. The tests must match the binary, and the best guess we have
> about the binary is the last thing we built.
> 
> Adding "git --build-options" would give us a better guess (it may not be
> what the user _wanted_ to test, but it is what they _are_ testing).
> 
> > > I suspect GIT_TEST_INSTALLED is not all that widely used, or somebody
> > > would have complained before. But if we really want to support it, I
> > > think the right thing is to bake GIT-BUILD-OPTIONS into the binary, so
> > > that "git --build-options" dumps it. It might also have value for
> > > debugging and forensics in general.
> > 
> > Yep, that would be helpful in general. I don't think we should worry
> > about GIT_TEST_INSTALLED too much. Who came up with that feature anyway...?
> 
> Clearly a crazy person. :) I am not saying it is a _bad_ idea. Only that
> the responsibility to make sure the installed version matches the
> current build parameters lies with the user (and for that matter, the
> current set of tests; we add new tests that would fail on old versions,
> and you cannot mix and match).
> 
> So an alternate explanation than "not widely used" is "all of the users
> of it are responsible individuals who do not make bogus bug reports to
> the list". :)
> 
> -Peff


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

On Wed, 18 Feb 2015 10:47:16 -0800, Junio C Hamano <gitster@pobox.com>
wrote:

> Jeff King <peff@peff.net> writes:
> 
> > On Wed, Feb 18, 2015 at 06:46:04PM +0100, Michael J Gruber wrote:
> >
> >> Well, how can we help if we don't even know the limitations of that
> >> platform?
> >
> > I'm not sure, but I think the original call for help may have been "I
> > will give you shell access to these boxes if you want to play around".
> 
> Yeah, that probably was my bad---I didn't make it clear enough that the
> request for volunteer from H.Merijn was exactly that.

Plus some possible help in how HP-UX is organized plus maybe install
more developer tools on request.

> > It seems like we could use
> >
> >   (cd src && tar cf - .) | (cd dst && tar xf -)
> >
> > here as a more portable alternative. I don't think we can rely on rsync
> > being everywhere.
> 
> Thanks; I wasn't even aware that we used rsync in our tests.  We
> certainly do not want to rely on it.

You don't. It was a quick hack from me to see if this was the only
cause of failure for that test

> Why not "cp -r src dst", though?


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[H.Merijn Brand]

[-- Attachment #1: Type: text/plain, Size: 13407 bytes --]

On Wed, 18 Feb 2015 18:46:04 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:

> H.Merijn Brand venit, vidit, dixit 18.02.2015 17:00:
> > On Wed, 10 Dec 2014 23:46:25 -0800, Junio C Hamano <gitster@pobox.com>
> > wrote:
> > 
> >> Hello, all.
> >>
> >> H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
> >> source communities, wants help porting more recent Git on these
> >> boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
> >> volunteer.  Please contact him directly if you are interested.
> > 
> > No-one. Disappointing :(
> 
> Well, how can we help if we don't even know the limitations of that
> platform?

I have offered to give any serious git developer an HP-UX account, so
one can found out themselves. I can then - hopefully - answer any
remaining question.

> In short, you are putting additional restrictions in by not having GNU
> tools around.

There *are* GNU tools around, and I *can* add other tools. I - of
course - cannot install *all* GNU tools. I don't put serious
restrictions on the wishes of developers. You ask we play. Mostly.

The problem here is that I can configure, build, and test any tool
(git) on my system using every GNU tool I might have available, but
once I convert this build into a package/distribution, and people
around the world download it and expect it to work, it will fail if
the tool (git) depends on available system commands that now do not
meet the needs of the tool (git).

Note that I have put TAR = gtar in config.mak.uname, but it is not
consistently used

> > Did *anyone* ever test with NO_ICONV?
> > Too many tests fail without iconv
> 
> There is iconv the library and iconv the command. With NO_ICONV, many
> tests fail for me even on my standard Linux distro. But our tests keep
> using iconv the command. The subtests which pass in t3900, for example,
> mostly test that certain things fail, for one reason or another...
> 
> But we should guard a few tests in case of NO_ICONV, of course, and
> probably not use iconv the command in this case either.
> 
> > It is *very* hard to decide from the current status if all
> > remaining failures are related to (Asian) locale failures and (thus)
> > can be safely ignored (in my environment).
> > 
> > Specifics at the end
> > 
> > 
> > FAILures from scratch with no iconv:
> > --------------------------------------------------------------------------------
> > t3513-revert-submodule.sh       Tests: 14 Failed:  5 Failed tests: 1-2, 4, 6-7                   TODO passed:   10-11
> > t3900-i18n-commit.sh            Tests: 34 Failed:  8 Failed tests: 15-17, 23-25, 27-28
> > t3901-i18n-patch.sh             Tests: 15 Failed:  8 Failed tests: 2-3, 6-7, 9, 11, 14-15
> > t4041-diff-submodule-option.sh  Tests: 44 Failed:  5 Failed tests: 5-7, 9-10
> > t4201-shortlog.sh               Tests: 11 Failed:  1 Failed tests: 9
> > t4204-patch-id.sh               Tests: 15 Failed:  3 Failed tests: 7, 10, 13
> > t4205-log-pretty-formats.sh     Tests: 46 Failed: 20 Failed tests: 12-14, 17, 19, 21, 23-29, 31, 33, 35, 37 39, 41-42
> > t4210-log-i18n.sh               Tests:  5 Failed:  4 Failed tests: 2-5
> > t5100-mailinfo.sh               Tests: 35 Failed: 11 Failed tests: 20-30
> > t5570-git-daemon.sh             Tests: 12 Failed:  2 Failed tests: 4-5      Parse errors: No plan found in TAP output
> > t6006-rev-list-format.sh        Tests: 54 Failed: 11 Failed tests: 9-10, 12, 25-27, 30-34
> > t6041-bisect-submodule.sh       Tests: 14 Failed:  9 Failed tests: 1-2, 4-7, 12-14               TODO passed:   10-11
> > t7001-mv.sh                     Tests: 46 Failed:  2 Failed tests: 38-39
> > t7102-reset.sh                  Tests: 30 Failed:  1 Failed tests: 2
> > t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
> > t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
> > t8005-blame-i18n.sh             Tests:  5 Failed:  3 Failed tests: 2-4
> > t9350-fast-export.sh            Tests: 34 Failed:  1 Failed tests: 4
> > Files=687, Tests=12091
> > 
> > FAILures from scratch with iconv:
> > --------------------------------------------------------------------------------
> > t3513-revert-submodule.sh       Tests: 14 Failed:  5 Failed tests: 1-2, 4, 6-7                   TODO passed:   10-11
> > t3900-i18n-commit.sh            Tests: 34 Failed:  6 Failed tests: 16-17, 24-25, 27-28
> > t4204-patch-id.sh               Tests: 15 Failed:  3 Failed tests: 7, 10, 13
> > t4210-log-i18n.sh               Tests:  5 Failed:  4 Failed tests: 2-5
> > t5100-mailinfo.sh               Tests: 35 Failed:  2 Failed tests: 20, 23
> > t5536-fetch-conflicts.sh        Tests:  7 Failed:  3 Failed tests: 3, 6-7
> > t5570-git-daemon.sh             Tests: 12 Failed:  2 Failed tests: 4-5      Parse errors: No plan found in TAP output
> > t6041-bisect-submodule.sh       Tests: 14 Failed:  9 Failed tests: 1-2, 4-7, 12-14               TODO passed:   10-11
> > t7001-mv.sh                     Tests: 46 Failed:  2 Failed tests: 38-39
> > t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
> > t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
> > t8005-blame-i18n.sh             Tests:  5 Failed:  3 Failed tests: 2-4
> > Files=687, Tests=12091
> > Result: FAIL
> > 
> > running «sh t****.sh -x -i»
> > 
> > 
> > t/t7001-mv.t
> > ------------
> > cp uses -P flag, which is unknown to HP's (non-GNU) version of cp
> > 
> > Changing the two occurrences from
> > 
> > 		cp -R -P -p ../.git/modules/sub .git &&
> > to
> > 		rsync -aHl ../.git/modules/sub/ .git/ &&
> > 
> > make the tests pass (on those systems that have a working rsync)
> 
> "rsync -r -l -o -p -t" would be the proper equivalent. -aH does more for
> my rsync. I don't know what HP-UX rsync understands, though.

HP has no rsync. I installed it myself.
As HP does not have rsync, it does not conflict. If I would install cp
however, I bet many system-tasks could fall over.

> > t/t3513-revert-submodule.sh
> > ---------------------------
> > tar uses z flag, which is unknown to HP's (non-GNU) version of tar
> > config.mak.uname defines TAR = gtar, but that obviously does not help
> > 
> > putting GNU-tar temporary in from of my $PATH makes the test pass
> > /me thinks the z in not required in that test at all
> > 
> > 	tar cf "$TRASH_DIRECTORY/tmp.tar" * &&
> > and
> > 	tar xf "$TRASH_DIRECTORY/tmp.tar" &&
> > 
> > work just as well and prevent the breakage
> 
> We can do without z.

TOP!

> > t/t3900-i18n-commit.sh
> > ----------------------
> > As my HP boxes have *NO* JP or other space eating asian locale stuff
> > installed, it is highly likely that *anything* dealing with asian
> > locales will fail. On modern Linux hardware, disk space is cheap. On
> > most HP-UX boxes disk space is expensive and when having nothing to do
> > with Asian languages, removing all Asian-related packages is a fast and
> > cheap way to regain disk space.
> > 
> > Changing compare_with to
> > 
> > compare_with () {
> >     case "$1$2$3" in
> > 	*eucJP*|*ISO-2022-JP*) true ;;
> > 	*)
> > 	    git show -s $1 | sed -e '1,/^$/d' -e 's/^    //' >current &&
> > 	    case "$3" in
> > 		'')
> > 		    test_cmp "$2" current ;;
> > 		?*)
> > 		    iconv -f "$3" -t UTF-8 >current.utf8 <current &&
> > 		    iconv -f "$3" -t UTF-8 >expect.utf8 <"$2" &&
> > 		    test_cmp expect.utf8 current.utf8
> > 		    ;;
> > 		esac
> > 	    ;;
> > 	esac
> >     }
> > 
> > makes all my tests pass
> 
> So you do have iconv the command, but don't want to link with the library?

Maybe it is too old?

$ iconv --version
iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.

> Availability of the locales should be covered by a prerequisite, like we
> do in t9129.
> 
> > t/t4204-patch-id.sh
> > -------------------
> > 
> > No idea yet
> > 
> > + test_patch_id_file_order irrelevant --stable --stable
> > Already on 'same'
> > cmp: patch-id_ordered-ordered-order---stable-irrelevant: No such file or directory
> > 
> > $ find * | grep 4204 | grep stable
> > trash directory.t4204-patch-id/patch-id_order---stable-irrelevant
> > trash directory.t4204-patch-id/patch-id_ordered-order---stable-irrelevant
> 
> The "Already"-part is normal output. The rest looks a bit crazy - and
> shell related?

I have set SHELL_PATH = /pro/local/bin/bash

The default /bin/sh on HP-UX is almost as bare as the old bourne shell
So, shell related? Likely!

> > t/t4210-log-i18n
> > ----------------
> > 
> > $ dump "trash directory.t4210-log-i18n/actual"
> > 00000000  75 74 66 38 0A                                      utf8.
> > $ dump "trash directory.t4210-log-i18n/expect"
> > 00000000  6C 61 74 69 6E 31 0A 75  74 66 38 0A                latin1.utf8.
> > $ dump "trash directory.t4210-log-i18n/msg"
> > 00000000  6C 61 74 69 6E 31 0A 0A  74 E9 73 74 0A             latin1..t.st.
> > 
> > t/t5100-mailinfo.sh
> > -------------------
> > + git mailinfo -u rfc2047/0001-msg rfc2047/0001-patch
> > + 0< rfc2047/0001 1> rfc2047/0001-info
> > fatal: cannot convert from US-ASCII to UTF-8
> > error: last command exited with $?=128
> 
> Is that mailinfo erroring out? Do you have those locales?

$ locale -a
C
POSIX
C.iso88591
C.iso885915
C.utf8
univ.utf8
nl_NL.iso88591
nl_NL.iso885915@euro
nl_NL.roman8
en_GB.iso88591
en_GB.iso885915@euro
en_GB.roman8
en_US.iso88591
en_US.roman8
nl_NL.utf8
en_GB.utf8
en_US.utf8

> OK, I'll have to stop fishing in the dark here.
> 
> > t/t5536-fetch-conflicts.sh
> > --------------------------
> > + setup_repository ccc +refs/heads/branch1:refs/remotes/origin/branch1 +refs/heads/branch2:refs/remotes/origin/branch1
> > Initialized empty Git repository in /pro/3gl/LINUX/git-2.3.0p/t/trash directory.t5536-fetch-conflicts/ccc/.git/
> > + cd ccc
> > + test_must_fail git fetch origin
> > + 2> error
> > + verify_stderr
> > + 0< /var/tmp/sh6096.2
> > cmp: EOF on actual
> > error: last command exited with $?=1
> > not ok 3 - fetch conflict: config vs. config
> > 
> > t/t5570-git-daemon.sh
> > ---------------------
> > I will ignore this myself, as I have no intention of using HP-UX as a
> > git server. We already have a dedicated Linux box doing so.
> > 
> > + test_cmp file clone/file
> > ok 3 - clone git repository
> > 
> > expecting success:
> >         echo content >>file &&
> >         git commit -a -m two &&
> >         git push public &&
> >         (cd clone && git pull) &&
> >         test_cmp file clone/file
> > 
> > + echo content
> > + 1>> file
> > + git commit -a -m two
> > 
> > arg sulong failed. 0, 0x9fffffffbffff058
> > 
> >  Setup args failed.
> > 
> > Pid 6238 was killed due to failure in writing to user register stack - possible stack overflow.
> > [master bca99f0] two
> >  Author: A U Thor <author@example.com>
> >  1 file changed, 1 insertion(+)
> > + git push public
> > 
> > t/t6041-bisect-submodule.sh
> > ---------------------------
> > config.mak.uname defines TAR = gtar, but that obviously does not help
> > 
> > + git_bisect add_sub1
> > tar: z: unknown option
> > tar: usage  tar [-]{txruc}[eONvVwAfblhm{op}][0-7[lmh]] [tapefile] [blocksize] [[-C directory] file] ...
> > 
> > changing my $PATH to have a GNU tar in front makes all tests pass
> > 
> > 
> > t/t7610-mergetool.sh
> > --------------------
> > HP-UX' mktemp obviously is not compatible with GNU mktemp (which I have
> > not installed/available on HP-UX)
> > 
> >  SYNOPSIS
> >       mktemp [-c] [-d directory_name] [-p prefix]
> > 
> > Resolved 'subdir/file3' using previous resolution.
> > Automatic merge failed; fix conflicts and then commit the result.
> > + git mergetool --no-prompt --tool myecho -- both
> > + 1> actual
> > error: mktemp is needed when 'mergetool.writeToTemp' is true
> > error: last command exited with $?=1
> > not ok 18 - temporary filenames are used with mergetool.writeToTemp
> > 
> > 
> > t/t7800-difftool.sh
> > -------------------
> > HP-UX doesn't have readlink
> > 
> > + git difftool --dir-diff --symlink --extcmd ./.git/CHECK_SYMLINKS branch HEAD
> > ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> > ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> > ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> > /pro/3gl/LINUX/git-2.3.0p/git-difftool line 472: No such file or directory
> > fatal: 'difftool' appears to be a git command, but we were not
> > able to execute it. Maybe git-difftool is broken?
> > error: last command exited with $?=128
> > not ok 49 - difftool --dir-diff --symlink without unstaged changes
> > 
> > 
> > t/t8005-blame-i18n.sh
> > ---------------------
> > SJIS again, I DO NOT CARE!
> > 
> > + 1> actual
> > + test_cmp actual expected
> > actual expected differ: char 56, line 3
> > error: last command exited with $?=1
> > not ok 2 - blame respects i18n.commitencoding

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: Interested in helping open source friends on HP-UX?

[David Aguilar]

On Wed, Feb 18, 2015 at 05:00:07PM +0100, H.Merijn Brand wrote:
> On Wed, 10 Dec 2014 23:46:25 -0800, Junio C Hamano <gitster@pobox.com>
> wrote:
> 
> > Hello, all.
> > 
> > H. Merijn Brand runs a few HP-UX boxes to help perl5 and other open
> > source communities, wants help porting more recent Git on these
> > boxes, running HP-UX 10.20, 11.00, and 11.23, and looking for a
> > volunteer.  Please contact him directly if you are interested.
> 
> No-one. Disappointing :(
> 
> I started to work on 2.3.0 on HP-UX 11.23/63 ia64
> 
> 
> Did *anyone* ever test with NO_ICONV?
> Too many tests fail without iconv
> 
> It is *very* hard to decide from the current status if all
> remaining failures are related to (Asian) locale failures and (thus)
> can be safely ignored (in my environment).
> 
> 
> Specifics at the end
> 
> 
> FAILures from scratch with no iconv:
> --------------------------------------------------------------------------------
> [...snip...]
> t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
> t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
> [...snip...]
> 
> FAILures from scratch with iconv:
> --------------------------------------------------------------------------------
> [...snip...]
> t7610-mergetool.sh              Tests: 18 Failed:  1 Failed tests: 18
> t7800-difftool.sh               Tests: 56 Failed:  1 Failed tests: 49
> [...snip...]


I think it's safe to say that these mergetool and difftool
failures are not iconv-related.


> t/t7610-mergetool.sh
> --------------------
> HP-UX' mktemp obviously is not compatible with GNU mktemp (which I have
> not installed/available on HP-UX)
> 
>  SYNOPSIS
>       mktemp [-c] [-d directory_name] [-p prefix]
> 
> Resolved 'subdir/file3' using previous resolution.
> Automatic merge failed; fix conflicts and then commit the result.
> + git mergetool --no-prompt --tool myecho -- both
> + 1> actual
> error: mktemp is needed when 'mergetool.writeToTemp' is true
> error: last command exited with $?=1
> not ok 18 - temporary filenames are used with mergetool.writeToTemp


We have prerequisites that can be used by tests to mark specific
tests as skippable.  It looks like inventing a prereq for mktemp
would be helpful here.

Maybe we don't need a global prereq, but certainly checking
whether mktemp is compliant for our use case could be used as a
criterion for skipping this test.

A further improvement would be to have have test coverage over
the failure scenario to ensure that the expected error message
is reported and that the correct exit code is returned when we
attempt to use a non-compliant mktemp.

I'd be happy to help review changes to this test.

I'm busy this week(end), but I might be able to poke around next
week if you wanted to give me a shell account.

That said, this error is non-fatal for most use cases ~ as long
as you don't set mergetool.writeToTemp then mergetool will work
fine as it will not attempt to use mktemp.


> t/t7800-difftool.sh
> -------------------
> HP-UX doesn't have readlink
> 
> + git difftool --dir-diff --symlink --extcmd ./.git/CHECK_SYMLINKS branch HEAD
> ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> ./.git/CHECK_SYMLINKS: line 5: readlink: command not found
> /pro/3gl/LINUX/git-2.3.0p/git-difftool line 472: No such file or directory
> fatal: 'difftool' appears to be a git command, but we were not
> able to execute it. Maybe git-difftool is broken?
> error: last command exited with $?=128
> not ok 49 - difftool --dir-diff --symlink without unstaged changes


This sounds like another case where a prereq would be helpful.
In this instance it'd be a "readlink" pre-req.

The --dir-diff code should probably be a little more careful
here, nonetheless.

The error about, "fatal: 'difftool' appears to be a git command"
seems like it might be something that can be improved.

It seems like difftool is returning an error code that the
caling code is misinterpreting as meaning, "not able to execute"
vs.  the real situation where difftool simply exited with an
(unexpected) error code.

It seems like we'd want to catch the error within difftool and
exit with a known error code.
-- 
David