Created attachment 574078 [details] emerge --info dev-perl/Net-SSLeay The problem is present after dev-libs/libressl-2.9.1 update.
Created attachment 574080 [details] build.log
Same error present in v 1.820.0 after the upgrade to LibreSSL-2.9.1 on amd64
Created attachment 574082 [details, diff] Libre291-perl-ssl.patch Another missing "&& !defined(LIBRESSL_VERSION_NUMBER)" statement. Since this one worked before with LibreSSL-2.8.3, I threw in some more well-defined "if" logic for the defined logic paths. Testing: Installs good with dev-perl/Net-SSLeay-1.82 I hope it works well on v1.85!
Created attachment 574084 [details, diff] Libre291-perl-ssl.patch cleaner install.
Thanks, I can confirm the patch works for 1.850.0 as well.
Confirmed. I hit this issue using dev-perl/Net-SSLeay-1.820.0 and dev-libs/libressl-2.9.1. Rebuilding with applied patch fixes this. Patch works. dev-perl/Net-SSLeay-1.850.0 hast not been tested. Thanks.
Patch doesn't work for me on 1.85 : * Applying Libre291-perl-ssl.patch ... 1 out of 1 hunk FAILED -- saving rejects to file SSLeay. [ !! ]
Masked 1.85, I confirm that patch fixes build for 1.82
You can use dev-perl/Net-SSLeay-1.860.0* from the libressl overlay (https://github.com/gentoo/libressl) It supports LibreSSL without any patches.
Presumably the stable release 1.88 should have the necessary changes as well...
1.860.0_p9 works well at a stable LibreSSL system
*** Bug 687136 has been marked as a duplicate of this bug. ***
*** Bug 687196 has been marked as a duplicate of this bug. ***
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=19f6b8c827f9212ccd27e7d24de21c07630ecac2 commit 19f6b8c827f9212ccd27e7d24de21c07630ecac2 Author: Stefan Strogin <steils@gentoo.org> AuthorDate: 2019-05-25 10:22:02 +0000 Commit: Kent Fredric <kentnl@gentoo.org> CommitDate: 2019-07-10 08:13:00 +0000 dev-perl/Net-SSLeay: Bump version to 1.880.0 - Restore previously broken tests - CFLAGS repsect logic reworked for upstream tooling changes - LIBDIR respect logic reworked for upstream tooling changes - NETWORK_TESTS handling logic reworked for upstream tooling changes Upstream: - Clarify licensing to be consistently Artistic-2 - Improved OpenSSL 1.1.1 support - Improved TLS 1.3 support - Fixed memory leaks in cb_data_advanced_put Bug: https://rt.cpan.org/Ticket/Display.html?id=106314 Bug: https://rt.cpan.org/Ticket/Display.html?id=128207 Closes: https://bugs.gentoo.org/556010 Closes: https://bugs.gentoo.org/684308 Closes: https://bugs.gentoo.org/686730 Closes: https://github.com/gentoo/gentoo/pull/12101 Package-Manager: Portage-2.3.66, Repoman-2.3.12 Signed-off-by: Stefan Strogin <steils@gentoo.org> Signed-off-by: Kent Fredric <kentnl@gentoo.org> dev-perl/Net-SSLeay/Manifest | 1 + dev-perl/Net-SSLeay/Net-SSLeay-1.880.0.ebuild | 63 ++++++++++++++++++++++ .../files/Net-SSLeay-1.88-fix-libdir.patch | 27 ++++++++++ .../files/Net-SSLeay-1.88-fix-network-tests.patch | 17 ++++++ 4 files changed, 108 insertions(+)
*** Bug 690522 has been marked as a duplicate of this bug. ***
*** Bug 695512 has been marked as a duplicate of this bug. ***
Guess its not fixed yet....
(In reply to Kent Fredric (IRC: kent\n) from comment #18) > Guess its not fixed yet.... It’s fixed, I’ve just built it with dev-libs/libressl-3.0.0
(In reply to Kent Fredric (IRC: kent\n) from comment #18) > Guess its not fixed yet.... It is. The problem is that, for as long as the fixed version remains stuck behind ~arch keywords, many libressl users are going to keep on running head first into this issue. Not everyone uses ~arch globally, or expects to do so in order to benefit from this kind of fix.
(In reply to Kerin Millar from comment #20) > It is. The problem is that, for as long as the fixed version remains stuck > behind ~arch keywords, many libressl users are going to keep on running head > first into this issue. Not everyone uses ~arch globally, or expects to do so > in order to benefit from this kind of fix. I dont know how others are trying to fix libressl related issues, but when I encounter one, I’m trying ~arch versions to see if it can fix it. I’m running a stable arch system with ~arch for some packages.
(In reply to Quentin R. from comment #21) > I dont know how others are trying to fix libressl related issues, but when I > encounter one, I’m trying ~arch versions to see if it can fix it. > I’m running a stable arch system with ~arch for some packages. That's a sensible thing to do in the course of troubleshooting but it wasn't really the point. To recap:- • The compatibility issue is addressed in Net-SSLeay but the stable-keyworded version remains affected. • Users of libressl that don't act as you do continue to report bugs against Net-SSLeay. • These additional reports cause sufficient confusion for this bug to have been re-opened in error. Assuming that there are no peripheral reasons to avoid doing so, the obvious resolution to all of this is to keyword as stable the version of Net-SSLeay that addresses this bug.
I'm thinking its "not fixed" due to the dupe reports that indicate they tested this exact fixed version. Bug #695512 > Tested with 1.820.0, 1.850.0 and 1.880.0 So either the reporter mis-tested, lied, or its not fixed. But I don't have the tools to determine the truth.
I tested with `emerge -va1 =dev-perl/Net-SSLeay-1.880.0` in https://bugs.gentoo.org/695512 and it fails with the same error as with 1.820.0 Did not alternated other packages, the dev-libs/libressl was 2.9.2. Anyway, I cannot retest them again because I am crawling back to openssl.
(In reply to Kent Fredric (IRC: kent\n) from comment #23) > I'm thinking its "not fixed" due to the dupe reports that indicate they > tested this exact fixed version. > > Bug #695512 > > > Tested with 1.820.0, 1.850.0 and 1.880.0 > > So either the reporter mis-tested, lied, or its not fixed. > > But I don't have the tools to determine the truth. The only thing I can tell is that libressl 3.0.0 and Net-SSLeay 1.880.0 works together. I haven't tested other versions.
I use libressl-2.9.2, which is the stable version from the perspective of both Gentoo and upstream. Note that libressl-2.9.1 was not a stable release and neither was 2.9.0. Essentially, a given minor release of a given major series constitutes the first (officially) stable version of the major series whenever upstream say so. Anyway, I can build Net-SSLeay-1.888.0 against libressl-2.9.2 without issue. Indeed, that's why I have had the former sitting in package.accept_keywords since it became available.
I can confirm that with dev-libs/libressl-2.9.2 the error is still there with current stable and 1.850.0. dev-perl/Net-SSLeay-1.880.0 compiles just fine with above libressl version.
(In reply to Thomas Raschbacher from comment #27) > I can confirm that with dev-libs/libressl-2.9.2 the error is still there > with current stable and 1.850.0. > > dev-perl/Net-SSLeay-1.880.0 compiles just fine with above libressl version. Well seems like things can only get better.
Please stabilize dev-perl/Net-SSLeay-1.880.0
x86 stable
amd64 stable
arm stable
arm64 stable
sparc stable
s390 stable
ppc64 stable
ppc stable
ia64 stable
alpha stable
hppa stable Last arch. Closing.
