Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 625944 - dev-qt/qtnetwork-5.7.1 doesn't know about dev-libs/libressl, it forces to use dev-libs/openssl
Summary: dev-qt/qtnetwork-5.7.1 doesn't know about dev-libs/libressl, it forces to use...
Status: RESOLVED DUPLICATE of bug 562050
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-22 15:09 UTC by stephane.goujet
Modified: 2017-11-05 17:20 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Missing USE flag (qtnetwork-libressl.patch,741 bytes, patch)
2017-07-30 13:15 UTC, Boris Staletic
Details | Diff
Libressl flag for qtnetwork (qtnetwork.diff,741 bytes, patch)
2017-08-16 10:07 UTC, Boris Staletic
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description stephane.goujet 2017-07-22 15:09:07 UTC
dev-qt/qtnetwork is one of the few packages that has no 'libressl' USE flag. If one uses libressl, the only way to build dev-qtnetwork is to disable SSL (with -ssl USE flag). So that can be a blocker for a system with libressl.

Is there a reason for that? Some incompatibility between libressl and qtnetwork?

On my setup, I modified the ebuild requirements so that it can use openssl OR libressl. The package built fine. I cannot tell much more about testing.

That allowed me to build sci-geosciences/qgis (cf bug https://bugs.gentoo.org/show_bug.cgi?id=625942). That build went fine, and the program launches fine too, but again, this is not a deep test :-)

Reproducible: Always
Comment 1 Michael Palimaka (kensington) gentoo-dev 2017-07-22 15:15:35 UTC
Unfortunately Qt upstream does not support libressl at all.

I suspect building qtnetwork[ssl] with libressl simply causes the ssl support to not be built at all - you could verify this with 'scanelf -n /usr/lib64/libQt5Network.so'.

*** This bug has been marked as a duplicate of bug 562050 ***
Comment 2 stephane.goujet 2017-07-22 16:10:20 UTC
Hi Michael.

No, it links to /usr/lib64/libssl.so.43 alright (with my slightly modified ebuild).

Here is the output of scanelf:
==========================
zbox ~ # scanelf -n /usr/lib64/libQt5Network.so
 TYPE   NEEDED FILE 
ET_DYN libQt5Core.so.5,libpthread.so.0,libz.so.1,libssl.so.43,libcrypto.so.41,libstdc++.so.6,libc.so.6 /usr/lib64/libQt5Network.so 
==========================

and ldd:
==========================
zbox ~ # ldd /usr/lib64/libQt5Network.so | grep ssl
	libssl.so.43 => /usr/lib64/libssl.so.43 (0x00007fe8095b0000)
==========================


And for a comparison, this what I had when I compiled it with [-ssl]:

==========================
 TYPE   NEEDED FILE 
ET_DYN libQt5Core.so.5,libpthread.so.0,libz.so.1,libstdc++.so.6,libc.so.6 /usr/lib64/libQt5Network.so 
==========================
Comment 3 Michael Palimaka (kensington) gentoo-dev 2017-07-22 16:16:01 UTC
OK, that's interesting, we'll need to check that then.
Comment 4 Davide Pesavento gentoo-dev 2017-07-22 16:20:39 UTC
(In reply to stephane.goujet from comment #2)
> No, it links to /usr/lib64/libssl.so.43 alright (with my slightly modified
> ebuild).

I assume libssl.so.43 comes from libressl, which version?
What does your "slightly modified ebuild" do differently? Did you just change the dependencies?
Comment 5 stephane.goujet 2017-07-22 16:41:56 UTC
Hi Davide,

==========================
dev-libs/libressl-2.6.0::gentoo was built with the following:
USE="asm -static-libs" ABI_X86="32 (64) -x32"
==========================

> What does your "slightly modified ebuild" do differently? Did you just change the dependencies?

Yes, just that.

==========================
stephane@zbox ~ $ diff -u  /usr/portage/dev-qt/qtnetwork/qtnetwork-5.7.1.ebuild /usr/local/portage/dev-qt/qtnetwork/qtnetwork-5.7.1-r1.ebuild
--- /usr/portage/dev-qt/qtnetwork/qtnetwork-5.7.1.ebuild	2017-07-15 07:10:08.000000000 +0200
+++ /usr/local/portage/dev-qt/qtnetwork/qtnetwork-5.7.1-r1.ebuild	2017-07-22 12:48:37.520330152 +0200
@@ -11,7 +11,7 @@
 	KEYWORDS="amd64 arm ~arm64 ~hppa ppc ppc64 x86"
 fi
 
-IUSE="bindist connman libproxy networkmanager +ssl"
+IUSE="bindist connman libproxy libressl networkmanager +ssl"
 
 DEPEND="
 	~dev-qt/qtcore-${PV}
@@ -19,7 +19,10 @@
 	connman? ( ~dev-qt/qtdbus-${PV} )
 	libproxy? ( net-libs/libproxy )
 	networkmanager? ( ~dev-qt/qtdbus-${PV} )
-	ssl? ( dev-libs/openssl:0[bindist=] )
+	ssl? (
+		!libressl? ( dev-libs/openssl:0=[bindist=] )
+		libressl? ( dev-libs/libressl:0= )
+	)
 "
 RDEPEND="${DEPEND}
 	connman? ( net-misc/connman )

==========================

It didn't seem to complain at configure step or compilation step. But I now see that there is a "test" flag in dev-qt/qtnetwork, I will try to activate it.
Comment 6 stephane.goujet 2017-07-22 18:02:06 UTC
> But I now see that there is a "test" flag in dev-qt/qtnetwork, I will try to activate it.

In fact, I cannot, it tells me "test" is RESTRICTed.
Comment 7 Ian Moone 2017-07-22 23:42:31 UTC
> Is there a reason for that? Some incompatibility between libressl and
> qtnetwork?
> 
> On my setup, I modified the ebuild requirements so that it can use openssl
> OR libressl. The package built fine. I cannot tell much more about testing.

Just adding libressl USE flag won't work properly. You need to patch it. See https://github.com/gentoo/libressl/tree/master/dev-qt/qtnetwork
Comment 8 stephane.goujet 2017-07-23 09:58:59 UTC
Hello Ian,

Apparently, there has been a change in politics concerning this issue in the development version of libressl:

https://github.com/libressl-portable/openbsd/commit/4f07e8b9030805d0b7bceb210837074e19a6cd63

I guess that means the patch is not needed with libressl-2.6.0 (like on my setup).

And that change appeared in libressl-2.5.2 . So all versions with slot 0/43 should  be OK?

zbox portage # eix libressl
[I] dev-libs/libressl
     Available versions:  (~)2.3.10(0/38) (~)2.4.5(0/39) (~)2.5.0(0/39) (~)2.5.4(0/43) (~)2.5.5(0/43) (~)2.6.0(0/43)
Comment 9 Boris Staletic 2017-07-30 13:15:44 UTC
Created attachment 487370 [details, diff]
Missing USE flag

I managed to link qtnetwork against libressl without issues, but the ebuild still lacks the appropriate USE flag. Ebuild patch is in attachment.
Comment 10 Ian Moone 2017-07-31 05:17:08 UTC
(In reply to stephane.goujet from comment #8)
>
> Apparently, there has been a change in politics concerning this issue in the
> development version of libressl:

Hello Stephane

Thank you for the link, I wasn't aware of the recent changes.

> I guess that means the patch is not needed with libressl-2.6.0 (like on my
> setup).
> 
> And that change appeared in libressl-2.5.2 . So all versions with slot 0/43
> should  be OK?

To be honest, I haven't played much in the Qt land, but I'll try to build without the patch I mentioned, and see if everything goes well here.

Cheers
Comment 11 Boris Staletic 2017-08-14 17:06:41 UTC
I've successfully merged =dev-qt/qtnetwork-5.7.1 with =dev-libs/libressl-2.6.0 and =dev-libs/libressl-2.5.4. It builds and runs fune, For testung I used qutebrowser, as it's the only thing I have that depends on qtnetwork.
Comment 12 Boris Staletic 2017-08-16 10:07:55 UTC
Created attachment 489258 [details, diff]
Libressl flag for qtnetwork
Comment 13 Michael Palimaka (kensington) gentoo-dev 2017-09-11 13:18:57 UTC
According to bug #562050 comment #39, this is once again broken in Qt 5.10 so I wonder if there's really any point introducing the USE flag for just a few versions.
Comment 14 jospezial 2017-09-15 19:14:41 UTC
Please always add the output of "emerge --info libressl qtnetwork" if you say something works together.


Is it possible yet to merge libressl and openssl on one system without file collisions?

I'm using an dummy ebuild for openssl-9999
https://github.com/gentoo/libressl/tree/24de68305ed1588a4e0d36933a22321ccfece661/dev-libs/openssl
 and allowed it in the libressl ebuild.

that is the latest commit of the ebuild before the folder was deleted at
https://github.com/gentoo/libressl/commit/94d3c2438172fca931b237a592959ed49c2abd83#diff-91b181bc4679af97ea356627d0f85107
" dev-libs/openssl: remove faux ebuild
We're no longer going to use this in the effort to push to get all ebuilds
which need it to get the libressl flag."


(In reply to Michael Palimaka (kensington) from comment #13)
> According to bug #562050 comment #39, this is once again broken in Qt 5.10
> so I wonder if there's really any point introducing the USE flag for just a
> few versions.

I think sooner or later we need an virtual/ssl on which all packages depend that are compatible to both libs.
Comment 15 Andreas Sturmlechner gentoo-dev 2017-10-29 23:30:56 UTC
*** Bug 635854 has been marked as a duplicate of this bug. ***
Comment 16 Michael Palimaka (kensington) gentoo-dev 2017-10-30 10:22:24 UTC
(In reply to jospezial from comment #14)
> I think sooner or later we need an virtual/ssl on which all packages depend
> that are compatible to both libs.

I understand that openssl and libressl are not ABI-compatible hence a virtual is not possible.
Comment 17 maurerpe 2017-10-30 23:43:58 UTC
The latest version of qtnetwork in portage: qtnetwork-5.9.2, works fine with the latest version of libressl in portage: libressl-2.6.2.  However, qtnetwork-5.9.2 lacks a libressl use flag and always tries to pull in openssl.

Please add a libressl use flag to qtnetwork-5.9.2 in portage.

In the mean time, the fixed ebuild is in the libressl overlay.

This bug was originally opened against version 5.7.1.  The ebuild in portage still has the same issue that opened this bug. 5.7.1 needs a patch to work with libressl.  For users wishing to use that version, the necessary patch and a working ebuild have been in the libressl overlay since April.
Comment 18 Michael Palimaka (kensington) gentoo-dev 2017-10-31 12:25:27 UTC
(In reply to maurerpe from comment #17)
> The latest version of qtnetwork in portage: qtnetwork-5.9.2, works fine with
> the latest version of libressl in portage: libressl-2.6.2.  However,
> qtnetwork-5.9.2 lacks a libressl use flag and always tries to pull in
> openssl.
> 
> Please add a libressl use flag to qtnetwork-5.9.2 in portage.
> 
> In the mean time, the fixed ebuild is in the libressl overlay.
> 
> This bug was originally opened against version 5.7.1.  The ebuild in portage
> still has the same issue that opened this bug. 5.7.1 needs a patch to work
> with libressl.  For users wishing to use that version, the necessary patch
> and a working ebuild have been in the libressl overlay since April.

Qt upstream does not support libressl. The fact that it works between 5.7 and 5.9 is simply a coincidence. It was reported broken in 5.6, and it's reported broken again in 5.10. Is there any point in repeatedly adding and removing a libressl USE flag?
Comment 19 stephane.goujet 2017-10-31 14:43:56 UTC
(In reply to Michael Palimaka (kensington) from comment #18)

> Qt upstream does not support libressl.

Do all packages with a libressl USE flag officially support libressl upstream?

> The fact that it works between 5.7
> and 5.9 is simply a coincidence. It was reported broken in 5.6, and it's
> reported broken again in 5.10. Is there any point in repeatedly adding and
> removing a libressl USE flag?

I gave a possible solution for 5.10 in https://bugs.gentoo.org/562050#c40 . I cannot try it myself. Why doesn't any one, any maintainer, try it?
Comment 20 Michael Palimaka (kensington) gentoo-dev 2017-11-03 14:11:44 UTC
(In reply to stephane.goujet from comment #19)
> Do all packages with a libressl USE flag officially support libressl
> upstream?

Some do, some only require trivial patching, and some "just work" out of luck.

> > The fact that it works between 5.7
> > and 5.9 is sim* Nobody in the team uses libressl so it's very difficult to actually do any work on itply a coincidence. It was reported broken in 5.6, and it's
> > reported broken again in 5.10. Is there any point in repeatedly adding and
> > removing a libressl USE flag?
> 
> I gave a possible solution for 5.10 in https://bugs.gentoo.org/562050#c40 .
> I cannot try it myself. Why doesn't any one, any maintainer, try it?

If you, a libressl user cannot try it, how do you expect the very few, openssl-using maintainers to try it?

For the record, here's a list of the main reasons why we don't have libressl support in Qt, in no particular order:
* Nobody in our extremely understaffed team uses libressl so not only is it a low priority, we have no way to work on it
* Qt upstream refuses to hack libressl support into their openssl backend (with good reason) and we try to follow upstream as best as we can
* We try to avoid downstream patching of any kind
* We especially try to avoid downstream patching where crypto is installed
* It keeps breaking

Upstream has already said they're happy to support libressl, it'll just need to have its own backend. I guess nobody upstream is using libressl either since they have produced no backend, nor has any community attempt (that I know of) to contribute a backend been made.
Comment 21 stephane.goujet 2017-11-04 17:20:01 UTC
(In reply to Michael Palimaka (kensington) from comment #20)
> (In reply to stephane.goujet from comment #19)
> > Do all packages with a libressl USE flag officially support libressl
> > upstream?

> Some do, some only require trivial patching, and some "just work" out of
> luck.

So arguing that there must not be a libressl USE flag for qtnetwork *because* upstream does not support officially libressl is moot.

 
> > > The fact that it works between 5.7
> > > and 5.9 is sim* Nobody in the team uses libressl so it's very difficult to actually do any work on itply a coincidence. It was reported broken in 5.6, and it's
> > > reported broken again in 5.10. Is there any point in repeatedly adding and
> > > removing a libressl USE flag?
> > 
> > I gave a possible solution for 5.10 in https://bugs.gentoo.org/562050#c40 .
> > I cannot try it myself. Why doesn't any one, any maintainer, try it?
> 
> If you, a libressl user cannot try it, how do you expect the very few,
> openssl-using maintainers to try it?

Because it is not a matter of libressl but of Qt. Qt is a mess to compile and I have a very limited system. I do not have room on my system to fetch and compile the whole git Qt tree. I also have a weak Celeron and compiling the whole mess takes hours, supposing I even knew how to handle the gazillion conflicts that will appear between 5.10 packages and the rest, and not end up with a broken system. I do not have a test system either.

Also because I am not a maintainer and I have little idea about how this Gentoo maintenance, 
packaging, ebuilding, ... works. I am just a *user* (you named it right). As a user, I can report things, and I can try a few simple things. For the rest, I hoped a *maintainer* would bother to write the correct 3 lines of ebuild it probably takes. Apparently not, you prefer to argue here and then send the good old WONTFIX/CANFIX/DONTGIVEFUCK signal to end all discussion.
Wonderful attitude that will take us far.


> For the record, here's a list of the main reasons why we don't have libressl
> support in Qt, in no particular order:
> * Nobody in our extremely understaffed team uses libressl so not only is it
> a low priority, we have no way to work on it

Ah, but you expect me, a user, to be able to test things on a Qt version which is not in Gentoo tree? 


> * Qt upstream refuses to hack libressl support into their openssl backend
> (with good reason) and we try to follow upstream as best as we can

But they still do have an OpenSSL 1.0 backend and LibreSSL should be compatible with it.


> * We try to avoid downstream patching of any kind
> * We especially try to avoid downstream patching where crypto is installed

Sigh...

*There is no patch involved.* Neither for 5.7 nor 5.9, nor (hopefully) 5.10 .
Comment 22 Michael Palimaka (kensington) gentoo-dev 2017-11-05 11:49:44 UTC
(In reply to stephane.goujet from comment #21)
> (In reply to Michael Palimaka (kensington) from comment #20)
> > (In reply to stephane.goujet from comment #19)
> > > Do all packages with a libressl USE flag officially support libressl
> > > upstream?
> 
> > Some do, some only require trivial patching, and some "just work" out of
> > luck.
> 
> So arguing that there must not be a libressl USE flag for qtnetwork
> *because* upstream does not support officially libressl is moot.

It's not a case of lack of official support, upstream explicitly *does not* support it. They are willing to should somebody submit a libressl backend, but so far nobody has stepped up.
 
>
> > > > The fact that it works between 5.7
> > > > and 5.9 is sim* Nobody in the team uses libressl so it's very difficult to actually do any work on itply a coincidence. It was reported broken in 5.6, and it's
> > > > reported broken again in 5.10. Is there any point in repeatedly adding and
> > > > removing a libressl USE flag?
> > > 
> > > I gave a possible solution for 5.10 in https://bugs.gentoo.org/562050#c40 .
> > > I cannot try it myself. Why doesn't any one, any maintainer, try it?
> > 
> > If you, a libressl user cannot try it, how do you expect the very few,
> > openssl-using maintainers to try it?
> 
> Because it is not a matter of libressl but of Qt. Qt is a mess to compile
> and I have a very limited system. I do not have room on my system to fetch
> and compile the whole git Qt tree. I also have a weak Celeron and compiling
> the whole mess takes hours, supposing I even knew how to handle the
> gazillion conflicts that will appear between 5.10 packages and the rest, and
> not end up with a broken system. I do not have a test system either.
> 
> Also because I am not a maintainer and I have little idea about how this
> Gentoo maintenance, 
> packaging, ebuilding, ... works. I am just a *user* (you named it right). As
> a user, I can report things, and I can try a few simple things. For the
> rest, I hoped a *maintainer* would bother to write the correct 3 lines of
> ebuild it probably takes. Apparently not, you prefer to argue here and then
> send the good old WONTFIX/CANFIX/DONTGIVEFUCK signal to end all discussion.
> Wonderful attitude that will take us far.

If you don't have the resources to test, that's fine - you don't owe us anything. I'd love to be able to provide support for every configuration but I have neither the time nor the resources. Hence, for non-standard configurations we rely on contributions.

> > For the record, here's a list of the main reasons why we don't have libressl
> > support in Qt, in no particular order:
> > * Nobody in our extremely understaffed team uses libressl so not only is it
> > a low priority, we have no way to work on it
> 
> Ah, but you expect me, a user, to be able to test things on a Qt version
> which is not in Gentoo tree? 

I don't expect you do to anything. However, the current situation is pretty clear - if we're to land libressl support for Qt, we need *someone* to step forward and help with testing.

> > * We try to avoid downstream patching of any kind
> > * We especially try to avoid downstream patching where crypto is installed
> 
> Sigh...
> 
> *There is no patch involved.* Neither for 5.7 nor 5.9, nor (hopefully) 5.10 .

I see various conflicting information about this. Looking at the libressl overlay, 5.7 requires some custom patching (which we will not ship in the main tree). 5.9 apparently "just works", but I avoided adding support because it reportedly broke again immediately in 5.10 (and has broken repeatedly in the past). You have offered a potential solution for 5.10, but so far nobody has been able to test.

I'm happy to add libressl support if no patching is required and if it looks like it will not immediately break again in a future version.

@pesa, thoughts?
Comment 23 Davide Pesavento gentoo-dev 2017-11-05 17:16:43 UTC
Let's add the flag to 5.9 and later. For 5.10 and later, enabling libressl needs to force using the old openssl 1.0 backend.
Comment 24 Davide Pesavento gentoo-dev 2017-11-05 17:17:25 UTC
Let's continue on the original bug.

*** This bug has been marked as a duplicate of bug 562050 ***