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

> 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