> I have confirmed that I can build the current branch-3.6 on my machine,
using GCC 12.2.0.
Thank you for testing it!!
> Does the build/test pipeline need to be updated to verify this? Why make
it a manual/release step.
> Perhaps part of the reason we're seeing this now is lack of CI on
I have confirmed that I can build the current branch-3.6 on my machine,
using GCC 12.2.0. I agree with your point that the GCC version might not be
root cause, and it's also possible that it's caused by a difference in
OpenSSL headers. My OpenSSL version is 3.0.7.
Perhaps part of the reason we're
Does the build/test pipeline need to be updated to verify this? Why make it
a manual/release step.
Patrick
On Thu, Dec 15, 2022 at 3:35 PM Szalay-Bekő Máté
wrote:
> Thanks for checking!
>
> I don't have a strong opinion. It would make sense to support newer gcc
> versions in a new release. On
Thanks for checking!
I don't have a strong opinion. It would make sense to support newer gcc
versions in a new release. On the other hand, it is not a regression on the
branch-3.6 (the c-client in this rc compiles with the same gcc versions
which were compatible with 3.6 3).
But I am OK to make
Unfortunately, I can't compile the C client because of the FIPS_mode bug
(ZOOKEEPER-4641). I'm on a newer version of GCC: 12.2.0. I see that
ZOOKEEPER-4641 was committed to branch-3.6 with a fix version of 3.6.5.
However, we're intending that 3.6.4 is the final 3.6 release, so there
never will be
+1 (binding)
I did the following tests for the release candidate:
- verified checksum and gpg signature of the artifacts
- I built the source code (incl. the C-client, using -Pfull-build) on
Ubuntu 20.04.5 using OpenJDK 8u352, maven 3.6.3 and GCC version 9.4.0
- all the unit tests passed (both
This is a bugfix release candidate for 3.6.4. It fixes 40 issues, including
CVE fixes,
log4j1 removal (using reload4j from now) and various other bug fixes
(thread leaks, data
corruption, snapshotting and SASL related fixes).
Please note, that based on our Release Strategy (
