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

From: David Aguilar <davvid@gmail.com>
Date: Feb 21, 2015, 23:31 UTC
Message-ID: <20150221233154.GA90150@gmail.com>
In-Reply-To: <20150218170007.784be6aa@pc09.procura.nl>

On Wed, Feb 18, 2015 at 05:00:07PM +0100, H.Merijn Brand wrote:

Show 39 quoted lines

> 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.

Show 15 quoted lines

> 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.

Show 13 quoted lines

> 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