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

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

[rsbecker]

On April 4, 2022 4:43 PM,  Junio C Hamano wrote:
>To: git@vger.kernel.org
>Cc: git-packagers@googlegroups.com
>Subject: [ANNOUNCE] Git v2.36.0-rc0
>
>An early preview release Git v2.36.0-rc0 is now available for
>testing at the usual places.  It is comprised of 661 non-merge
>commits since v2.35.0, contributed by 80 people, 25 of which are
>new faces [*].

I rather expected this... build error hit very early on both NonStop ia64 and x86:

cc -c99 -o wrapper.o -c     -WRVU=J06.21 -g -O2 -Winline -I/usr/local-ssl3.0/include -I. -DGIT_HOST_CPU="\"NSE\"" -DCURL_STATICLIB -I/usr/local/include -DUSE_CURL_FOR_IMAP_SEND -DNO_D_TYPE_IN_DIRENT -DNO_ST_BLOCKS_IN_STRUCT_STAT -DNO_NSEC -DNO_GETTEXT -DNO_SYS_SELECT_H -DNO_POLL_H -DNO_SYS_POLL_H -DOLD_ICONV -DSHA1_DC -DSHA1DC_NO_STANDARD_INCLUDES -DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 -DSHA1DC_CUSTOM_INCLUDE_SHA1_C="\"cache.h\"" -DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C="\"git-compat-util.h\"" -DSHA256_BLK -DNO_PTHREADS -DHAVE_LIBCHARSET_H -DHAVE_STRINGS_H -DHAVE_DEV_TTY -DHAVE_OPENSSL_CSPRNG  -DSA_RESTART=0 -DHAVE_STRING_H=1 -DFREAD_READS_DIRECTORIES -DNO_POLL -Icompat/poll -DNO_STRCASESTR -DNO_STRLCPY -DNO_SETENV -DNO_MKDTEMP -DNO_UNSETENV -DNO_MMAP -DNO_PREAD -DNO_INTPTR_T -DNO_HSTRERROR -DNO_MEMMEM -Icompat/regex -DSHELL_PATH='"/usr/coreutils/bin/bash"'  wrapper.c

  	int res = RAND_bytes(buf, len);
  	          ^
"wrapper.c", line 817: error(114): identifier "RAND_bytes" is undefined

I thought we did not have a direct reference to OpenSSL. What do I need here to resolve this?

--Randall

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

[Junio C Hamano]

CSPRNG_METHOD?

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

[rsbecker]

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?

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

[Carlo Marcelo Arenas Belón]

On Mon, Apr 04, 2022 at 06:40:35PM -0400, rsbecker@nexbridge.com wrote:
> 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?

only if you are not telling your openssl to hide that function[1]

Carlo

[1] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html

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

[Carlo Marcelo Arenas Belón]

On Mon, Apr 04, 2022 at 05:26:10PM -0700, Carlo Marcelo Arenas Belón wrote:
> On Mon, Apr 04, 2022 at 06:40:35PM -0400, rsbecker@nexbridge.com wrote:
> > 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?
> 
> only if you are not telling your openssl to hide that function[1]
> 
> Carlo
> 
> [1] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html

neverming, it seems we forgot to track this header somehow, so will need
something like (untested and likely to need changes to support NO_OPENSSL)

Carlo
--- >8 ---
diff --git a/git-compat-util.h b/git-compat-util.h
index 4d444dca274..68a9b9cd975 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -525,6 +525,10 @@ void warning_errno(const char *err, ...) __attribute__((format (printf, 1, 2)));
 #include <openssl/x509v3.h>
 #endif /* NO_OPENSSL */
 
+#ifdef HAVE_OPENSSL_CSPRNG
+#include <openssl/rand.h>
+#endif
+
 /*
  * Let callers be aware of the constant return value; this can help
  * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,

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

[rsbecker]

On April 4, 2022 8:54 PM, Carlo Marcelo Arenas Belón wrote:
>On Mon, Apr 04, 2022 at 05:26:10PM -0700, Carlo Marcelo Arenas Belón wrote:
>> On Mon, Apr 04, 2022 at 06:40:35PM -0400, rsbecker@nexbridge.com wrote:
>> > 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?
>>
>> only if you are not telling your openssl to hide that function[1]
>>
>> Carlo
>>
>> [1] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html
>
>neverming, it seems we forgot to track this header somehow, so will need
>something like (untested and likely to need changes to support NO_OPENSSL)
>
>Carlo
>--- >8 ---
>diff --git a/git-compat-util.h b/git-compat-util.h index 4d444dca274..68a9b9cd975
>100644
>--- a/git-compat-util.h
>+++ b/git-compat-util.h
>@@ -525,6 +525,10 @@ void warning_errno(const char *err, ...)
>__attribute__((format (printf, 1, 2)));  #include <openssl/x509v3.h>  #endif /*
>NO_OPENSSL */
>
>+#ifdef HAVE_OPENSSL_CSPRNG
>+#include <openssl/rand.h>
>+#endif
>+
> /*
>  * Let callers be aware of the constant return value; this can help
>  * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,

I was able to make the build work, adding the above patch and libcrypto.so and libssl.so to our LDFLAGS. This patch is probably required. What confuses me somewhat is why RAND_bytes is required for anything in the fsync series, but it is what it is.

If there is a knob for force -lcrypto and -lssl in config.mak.uname, it would help. The CSPRNG_METHOD=openssl should be forcing these two libraries into the link, I would think. The DLLs do show up in other links, so I am suspecting there is an omission somewhere that includes the git-daemon link.

The test cycle has begun, but that will take at least 40 hours on an ia64 to get complete results.

--Randall

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

[Carlo Marcelo Arenas Belón]

On Mon, Apr 04, 2022 at 10:59:54PM -0400, rsbecker@nexbridge.com wrote:
> On April 4, 2022 8:54 PM, Carlo Marcelo Arenas Belón wrote:
> >On Mon, Apr 04, 2022 at 05:26:10PM -0700, Carlo Marcelo Arenas Belón wrote:
> >> On Mon, Apr 04, 2022 at 06:40:35PM -0400, rsbecker@nexbridge.com wrote:
> >> > 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?
> >>
> >> only if you are not telling your openssl to hide that function[1]
> >>
> >> Carlo
> >>
> >> [1] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html
> >
> >nevermind, it seems we forgot to track this header somehow, so will need
> >something like (untested and likely to need changes to support NO_OPENSSL)
> >
> >Carlo
> >--- >8 ---
> >diff --git a/git-compat-util.h b/git-compat-util.h index 4d444dca274..68a9b9cd975
> >100644
> >--- a/git-compat-util.h
> >+++ b/git-compat-util.h
> >@@ -525,6 +525,10 @@ void warning_errno(const char *err, ...)
> >__attribute__((format (printf, 1, 2)));  #include <openssl/x509v3.h>  #endif /*
> >NO_OPENSSL */
> >
> >+#ifdef HAVE_OPENSSL_CSPRNG
> >+#include <openssl/rand.h>
> >+#endif
> >+
> > /*
> >  * Let callers be aware of the constant return value; this can help
> >  * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,
> 
> I was able to make the build work, adding the above patch and libcrypto.so and libssl.so to our LDFLAGS.

Adding libcrypto wasn't enough?; of course it will depend on your linker
but when tested in Linux and macOS the only "U" symbol that got pulled
was RAND_bytes and -lcrypto was all that was needed.

Official patch including both libraries below, but it would be ideal to
only pull one if possible.

Carlo
-- >8 --
Subject: [PATCH] git-compat-util: really support openssl as a source of entropy

05cd988dce5 (wrapper: add a helper to generate numbers from a CSPRNG,
2022-01-17), configure openssl as the source for entropy in NON-STOP
but doesn't add the needed header or link options.

Since the only system that is configured to use openssl as a source
of entropy is NON-STOP, add the header unconditionally, and -lcrypto
to the list of external libraries.

An additional change is required to make sure a NO_OPENSSL=1 build
will be able to work as well (tested on Linux with a modified value
of CSPRNG_METHOD = openssl), and the more complex logic that allows
for compatibility with APPLE_COMMON_CRYPTO or allowing for simpler
ways to link (without libssl) has been punted for now.

Reported-by: Randall Becker <rsbecker@nexbridge.com>
Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
---
 Makefile          | 1 +
 git-compat-util.h | 4 ++++
 imap-send.c       | 2 +-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 91738485626..f8bccfab5e9 100644
--- a/Makefile
+++ b/Makefile
@@ -1972,6 +1972,7 @@ endif
 
 ifneq ($(findstring openssl,$(CSPRNG_METHOD)),)
 	BASIC_CFLAGS += -DHAVE_OPENSSL_CSPRNG
+	EXTLIBS += -lcrypto -lssl
 endif
 
 ifneq ($(PROCFS_EXECUTABLE_PATH),)
diff --git a/git-compat-util.h b/git-compat-util.h
index 4d444dca274..68a9b9cd975 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -525,6 +525,10 @@ void warning_errno(const char *err, ...) __attribute__((format (printf, 1, 2)));
 #include <openssl/x509v3.h>
 #endif /* NO_OPENSSL */
 
+#ifdef HAVE_OPENSSL_CSPRNG
+#include <openssl/rand.h>
+#endif
+
 /*
  * Let callers be aware of the constant return value; this can help
  * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though,
diff --git a/imap-send.c b/imap-send.c
index 5ac6fa9c664..a50af56b827 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -27,7 +27,7 @@
 #include "exec-cmd.h"
 #include "run-command.h"
 #include "parse-options.h"
-#ifdef NO_OPENSSL
+#if defined(NO_OPENSSL) && !defined(HAVE_OPENSSL_CSPRNG)
 typedef void *SSL;
 #endif
 #ifdef USE_CURL_FOR_IMAP_SEND
-- 
2.35.1.505.g27486cd1b2d

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

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

On 2022-04-05 at 04:28:26, Carlo Marcelo Arenas Belón wrote:
> Subject: [PATCH] git-compat-util: really support openssl as a source of entropy
> 
> 05cd988dce5 (wrapper: add a helper to generate numbers from a CSPRNG,
> 2022-01-17), configure openssl as the source for entropy in NON-STOP
> but doesn't add the needed header or link options.
> 
> Since the only system that is configured to use openssl as a source
> of entropy is NON-STOP, add the header unconditionally, and -lcrypto
> to the list of external libraries.
> 
> An additional change is required to make sure a NO_OPENSSL=1 build
> will be able to work as well (tested on Linux with a modified value
> of CSPRNG_METHOD = openssl), and the more complex logic that allows
> for compatibility with APPLE_COMMON_CRYPTO or allowing for simpler
> ways to link (without libssl) has been punted for now.

I didn't consider the case that we had NO_OPENSSL=1 because it seems a
bit bizarre to say, "No, I don't want OpenSSL—oh, wait, I do want
OpenSSL!"

This patch also didn't seem necessary for me on Linux when I tested, but
of course it might be necessary on some systems, so if it fixes things,
I'm in favour.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

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

[Carlo Arenas]

On Tue, Apr 5, 2022 at 1:10 AM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
> I didn't consider the case that we had NO_OPENSSL=1 because it seems a
> bit bizarre to say, "No, I don't want OpenSSL—oh, wait, I do want
> OpenSSL!"

NO_OPENSSL is definitely strange, for example in macOS it means: do
not link with openssl if it comes from homebrew or macports, but maybe
use the one that comes with the system, which happens to be based on
openssl anyway (based on libressl, boringssl, or even a really old
version of openssl, depending on which version of the OS you got).

Either way, the choice of using the openssl function this requires
could work with any of those if provided with the right linker
settings, but it doesn't seem worth the trouble to do, especially not
for rc0.

> This patch also didn't seem necessary for me on Linux when I tested, but
> of course it might be necessary on some systems, so if it fixes things,
> I'm in favour.

Not sure if the required changes got somehow dropped in one of the
rebases after your tests, but it definitely didn't work for me when
tested on Linux (using debian stable or sid) and I can't see how it
would work unless the crypto library is pulled in some other way, and
even in that case the lack of the header should break, at least with
DEVELOPER=1.

Carlo

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

[rsbecker]

On April 5, 2022 6:48 PM, Carlo Arenas wrote:
>To: brian m. carlson <sandals@crustytoothpaste.net>; Carlo Marcelo Arenas Belón
><carenas@gmail.com>; rsbecker@nexbridge.com; Junio C Hamano
><gitster@pobox.com>; Git Mailing List <git@vger.kernel.org>; git-
>packagers@googlegroups.com
>Subject: Re: [ANNOUNCE] Git v2.36.0-rc0 - Build failure on NonStops
>
>On Tue, Apr 5, 2022 at 1:10 AM brian m. carlson <sandals@crustytoothpaste.net>
>wrote:
>> I didn't consider the case that we had NO_OPENSSL=1 because it seems a
>> bit bizarre to say, "No, I don't want OpenSSL—oh, wait, I do want
>> OpenSSL!"
>
>NO_OPENSSL is definitely strange, for example in macOS it means: do not link with
>openssl if it comes from homebrew or macports, but maybe use the one that
>comes with the system, which happens to be based on openssl anyway (based on
>libressl, boringssl, or even a really old version of openssl, depending on which
>version of the OS you got).
>
>Either way, the choice of using the openssl function this requires could work with
>any of those if provided with the right linker settings, but it doesn't seem worth
>the trouble to do, especially not for rc0.
>
>> This patch also didn't seem necessary for me on Linux when I tested,
>> but of course it might be necessary on some systems, so if it fixes
>> things, I'm in favour.
>
>Not sure if the required changes got somehow dropped in one of the rebases
>after your tests, but it definitely didn't work for me when tested on Linux (using
>debian stable or sid) and I can't see how it would work unless the crypto library is
>pulled in some other way, and even in that case the lack of the header should
>break, at least with DEVELOPER=1.

I had to be explicit and override the LDFLAGS to include -lcrypto and -lssl at least for git-daemon with the wrapper.c patch. Testing is still going - currently at t5531 on the ia64 NonStop variant without problems. I deliberately picked the more finicky of the two systems since x86 uses a slightly simpler OpenSSL with the x86 hardware randomizer.

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

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> I didn't consider the case that we had NO_OPENSSL=1 because it seems a
> bit bizarre to say, "No, I don't want OpenSSL—oh, wait, I do want
> OpenSSL!"

Indeed ;-).

> This patch also didn't seem necessary for me on Linux when I tested, but
> of course it might be necessary on some systems, so if it fixes things,
> I'm in favour.

I think I've seen the breakage myself when I tried to force
CSPRNG_METHOD = openssl in my build.  Let's take the patch as-is for
now.

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

[rsbecker]

On April 5, 2022 12:28 AM, Carlo Marcelo Arenas Belón wrote:
>On Mon, Apr 04, 2022 at 10:59:54PM -0400, rsbecker@nexbridge.com wrote:
>> On April 4, 2022 8:54 PM, Carlo Marcelo Arenas Belón wrote:
>> >On Mon, Apr 04, 2022 at 05:26:10PM -0700, Carlo Marcelo Arenas Belón wrote:
>> >> On Mon, Apr 04, 2022 at 06:40:35PM -0400, rsbecker@nexbridge.com wrote:
>> >> > 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?
>> >>
>> >> only if you are not telling your openssl to hide that function[1]
>> >>
>> >> Carlo
>> >>
>> >> [1] https://www.openssl.org/docs/manmaster/man3/RAND_bytes.html
>> >
>> >nevermind, it seems we forgot to track this header somehow, so will
>> >need something like (untested and likely to need changes to support
>> >NO_OPENSSL)
>> >
>> >Carlo
>> >--- >8 ---
>> >diff --git a/git-compat-util.h b/git-compat-util.h index
>> >4d444dca274..68a9b9cd975
>> >100644
>> >--- a/git-compat-util.h
>> >+++ b/git-compat-util.h
>> >@@ -525,6 +525,10 @@ void warning_errno(const char *err, ...)
>> >__attribute__((format (printf, 1, 2)));  #include <openssl/x509v3.h>
>> >#endif /* NO_OPENSSL */
>> >
>> >+#ifdef HAVE_OPENSSL_CSPRNG
>> >+#include <openssl/rand.h>
>> >+#endif
>> >+
>> > /*
>> >  * Let callers be aware of the constant return value; this can help
>> >  * gcc with -Wuninitialized analysis. We restrict this trick to gcc,
>> > though,
>>
>> I was able to make the build work, adding the above patch and libcrypto.so and
>libssl.so to our LDFLAGS.
>
>Adding libcrypto wasn't enough?; of course it will depend on your linker but when
>tested in Linux and macOS the only "U" symbol that got pulled was RAND_bytes
>and -lcrypto was all that was needed.
>
>Official patch including both libraries below, but it would be ideal to only pull one if
>possible.
>
>Carlo
>-- >8 --
>Subject: [PATCH] git-compat-util: really support openssl as a source of entropy
>
>05cd988dce5 (wrapper: add a helper to generate numbers from a CSPRNG, 2022-
>01-17), configure openssl as the source for entropy in NON-STOP but doesn't add
>the needed header or link options.
>
>Since the only system that is configured to use openssl as a source of entropy is
>NON-STOP, add the header unconditionally, and -lcrypto to the list of external
>libraries.
>
>An additional change is required to make sure a NO_OPENSSL=1 build will be able
>to work as well (tested on Linux with a modified value of CSPRNG_METHOD =
>openssl), and the more complex logic that allows for compatibility with
>APPLE_COMMON_CRYPTO or allowing for simpler ways to link (without libssl) has
>been punted for now.
>
>Reported-by: Randall Becker <rsbecker@nexbridge.com>
>Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com>
>---
> Makefile          | 1 +
> git-compat-util.h | 4 ++++
> imap-send.c       | 2 +-
> 3 files changed, 6 insertions(+), 1 deletion(-)
>
>diff --git a/Makefile b/Makefile
>index 91738485626..f8bccfab5e9 100644
>--- a/Makefile
>+++ b/Makefile
>@@ -1972,6 +1972,7 @@ endif
>
> ifneq ($(findstring openssl,$(CSPRNG_METHOD)),)
> 	BASIC_CFLAGS += -DHAVE_OPENSSL_CSPRNG
>+	EXTLIBS += -lcrypto -lssl
> endif
>
> ifneq ($(PROCFS_EXECUTABLE_PATH),)
>diff --git a/git-compat-util.h b/git-compat-util.h index 4d444dca274..68a9b9cd975
>100644
>--- a/git-compat-util.h
>+++ b/git-compat-util.h
>@@ -525,6 +525,10 @@ void warning_errno(const char *err, ...)
>__attribute__((format (printf, 1, 2)));  #include <openssl/x509v3.h>  #endif /*
>NO_OPENSSL */
>
>+#ifdef HAVE_OPENSSL_CSPRNG
>+#include <openssl/rand.h>
>+#endif
>+
> /*
>  * Let callers be aware of the constant return value; this can help
>  * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though, diff --git
>a/imap-send.c b/imap-send.c index 5ac6fa9c664..a50af56b827 100644
>--- a/imap-send.c
>+++ b/imap-send.c
>@@ -27,7 +27,7 @@
> #include "exec-cmd.h"
> #include "run-command.h"
> #include "parse-options.h"
>-#ifdef NO_OPENSSL
>+#if defined(NO_OPENSSL) && !defined(HAVE_OPENSSL_CSPRNG)
> typedef void *SSL;
> #endif
> #ifdef USE_CURL_FOR_IMAP_SEND
>--
>2.35.1.505.g27486cd1b2d

Will retest when this has been rolled into rc1. Thanks
Randall

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

[rsbecker]

On April 4, 2022 8:26 PM, Carlo Marcelo Arenas Belón wrote:
>On Mon, Apr 04, 2022 at 06:40:35PM -0400, rsbecker@nexbridge.com wrote:
>> 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?
>
>only if you are not telling your openssl to hide that function[1]

There is nothing in our code that causes that.

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

[Junio C Hamano]

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

Thanks.

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

[rsbecker]

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

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

[Junio C Hamano]

<rsbecker@nexbridge.com> writes:

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

Ah, OK, so I had a wrong impression, which explains my puzzlement.

I somehow thought that you caught us soon after stuff got merged to
'master', and sometimes even to 'next', for a few times before.

Thanks.

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

[rsbecker]

>-----Original Message-----
On April 6, 2022 3:38 PM, Junio C Hamano wrote
><rsbecker@nexbridge.com> writes:
>
>> 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* ...
>
>Ah, OK, so I had a wrong impression, which explains my puzzlement.
>
>I somehow thought that you caught us soon after stuff got merged to
'master',
>and sometimes even to 'next', for a few times before.

I am working on getting a much faster system. Once that happens, I hope we
can increase the cadence of my test cycle.

Regards,
Randall

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

[rsbecker]

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

The 2.35.1 build happened on 29 Jan 2022, which appears to be before the
change. That's why I didn't report it. This was the first build/test since
then. So, no surprise actually. The build was done on commit
4c53a8c20f8984adb226293a3ffd7b88c3f4ac1a. At least we know why the problem
only showed up now. As I said, it's 50 hours to run the test cycle on ia64,
so I only run this when an announcement happens.

Regards,
Randall