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

[David Aguilar <davvid@gmail.com>]

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