RE: [ANNOUNCE] Git v2.36.0-rc0 - Build failure on NonStops

[<rsbecker@nexbridge.com>]

On April 6, 2022 12:14 PM, Junio C Hamano wrote:
><rsbecker@nexbridge.com> writes:
>
>> On April 4, 2022 6:33 PM, Junio C Hamano wrote:
>>>To: Randall S. Becker <rsbecker@nexbridge.com>
>>>Cc: Git Mailing List <git@vger.kernel.org>;
>>>git-packagers@googlegroups.com
>>>Subject: Re: [ANNOUNCE] Git v2.36.0-rc0 - Build failure on NonStops
>>>
>>>CSPRNG_METHOD?
>>
>> We already have
>>
>>         CSPRNG_METHOD = openssl
>>
>> In the config for NonStop. Should that not have worked?
>
>In your original report, you said
>
>>> I thought we did not have a direct reference to OpenSSL. What do I
>>> need here to resolve this?
>
>I misread it as "I did not directly ask to use OpenSSL---why am I seeing
breakage
>from RAND_bytes() that is an OpenSSL thing?", and where my suggestion to
look
>for CSPRNG_METHOD came from.
>
>Downthread, folks seem to have figured out that OpenSSL support failed to
>include a necessary header and link with libraries, while I was offline
yesterday, so
>hopefully all is well?
>
>Since d073bdc6 (Merge branch 'bc/csprng-mktemps', 2022-02-11) the CSPRNG
>code has been in 'master/main' and the topic was merged to 'next' much
earlier,
>at 2e32375c (Merge branch 'bc/csprng-mktemps'
>into next, 2022-02-04).  I was puzzled why it took this long for your
report to come,
>as I somehow thought you've been quite good at reporting portability issues
to
>your platform quickly, and was wondering if we broke something between the
>time we merged it to 'next' and -rc0, but it seems that it was not working
from the
>beginning X-<.

I have no explanation on why this and the PATH issue showed up at 2.36.0-rc0
and not at 2.35.1. 2.35.0. Our build/test cycles are thorough but only on
the releases and rc* notices because it takes 50+ hours to run the whole
test cycle. The CSPRNG_METHOD was already set in the platform config, so we
did not have to change that. wrapper.c had an issue that was missing the
required includes on more than just our platform - adding that in did help.
t6200 did not previously fail but we are looking into whether an OpenSSH
install caused that. I think we will have to selectively modify the path in
config.mak.uname for each build going forward for tests to pass.

I am sorry that I do not have better or more clear info.
--Randall