On April 6, 2022 12:14 PM, Junio C Hamano wrote: ><rsbecker@xxxxxxxxxxxxx> writes: > >> On April 4, 2022 6:33 PM, Junio C Hamano wrote: >>>To: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> >>>Cc: Git Mailing List <git@xxxxxxxxxxxxxxx>; >>>git-packagers@xxxxxxxxxxxxxxxx >>>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