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
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 ***
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 ==========================
OK, that's interesting, we'll need to check that then.
(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?
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.
> 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.
> 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
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)
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.
(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
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.
Created attachment 489258 [details, diff] Libressl flag for qtnetwork
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.
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.
*** Bug 635854 has been marked as a duplicate of this bug. ***
(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.
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.
(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?
(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?
(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.
(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 .
(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?
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.
Let's continue on the original bug. *** This bug has been marked as a duplicate of bug 562050 ***