I'm beginning the process of unmasking USE=libressl in the tree. I've tested this out on github. See pull 5299 referenced in ${URL}. Since libressl blocks against openssl, and most arch testers are running openssl systems, you may have to do just a compile test by manually stepping through the phases with ebuild, like this: ebuild =dev-libs/libressl-2.6.0 clean install This doesn't do a qmerge, but hopefully this won't be needed. I have extensively tested on amd64, arm and x86 and could stabilize myself on those, but I'd like feedback from the arch testers.
KEYWORDS="amd64 arm hppa ppc ppc64 x86"
amd64 done (switched laptop long ago anyway)
Hey guys, do you know about bug 625944 : "dev-qt/qtnetwork-5.7.1 doesn't know about dev-libs/libressl, it forces to use dev-libs/openssl" dependencies, shown by equery output - especially look at needed USE ssl: # equery -C d dev-qt/qtnetwork * These packages depend on dev-qt/qtnetwork: dev-qt/designer-5.7.1 (~dev-qt/qtnetwork-5.7.1) dev-qt/qtdeclarative-5.7.1 (~dev-qt/qtnetwork-5.7.1) (xml ? ~dev-qt/qtnetwork-5.7.1) dev-qt/qtgui-5.7.1-r1 (tuio ? ~dev-qt/qtnetwork-5.7.1) dev-qt/qtprintsupport-5.7.1 (test ? ~dev-qt/qtnetwork-5.7.1) dev-qt/qtsingleapplication-2.6.1_p20150629 (qt5 ? dev-qt/qtnetwork:5) dev-qt/qtwebkit-5.7.1 (~dev-qt/qtnetwork-5.7.1) dev-qt/qtxml-5.7.1 (test ? ~dev-qt/qtnetwork-5.7.1) dev-qt/qtxmlpatterns-5.7.1 (~dev-qt/qtnetwork-5.7.1) kde-frameworks/khtml-5.37.0 (>=dev-qt/qtnetwork-5.7.1:5[ssl]) kde-frameworks/kio-5.37.0 (>=dev-qt/qtnetwork-5.7.1:5[ssl]) kde-frameworks/kxmlgui-5.37.0 (>=dev-qt/qtnetwork-5.7.1:5[ssl]) media-video/kaffeine-2.0.12.1 (>=dev-qt/qtnetwork-5.6.1:5) net-p2p/qbittorrent-3.3.12 (dev-qt/qtnetwork:5[ssl]) x11-misc/sddm-0.15.0 (>=dev-qt/qtnetwork-5.6:5) --
(In reply to Ulenrich from comment #3) > Hey guys, do you know about bug 625944 : > "dev-qt/qtnetwork-5.7.1 doesn't know about dev-libs/libressl, it forces to > use dev-libs/openssl" > This does not belong here. We can move to stabilize and remove the use.stable.masks without every package in the tree supporting both openssl and libressl.
Seeing as none of the arch teams will touch this, I'll take care of everything but hppa. @hppa team, can you please just check that libressl-2.6.0 compiles.
hppa stable
Bug 625266 is blocking stabilization for x86
(In reply to Thomas Deutschmann from comment #7) > Bug 625266 is blocking stabilization for x86 That bug has gcc-6.3.0 which is not stable yet. I did not hit any problems on amd64 with gcc-5.4.0-r3? Are you getting any problems with gcc-5.4.0-r3 on x86?
(In reply to Anthony Basile from comment #8) > That bug has gcc-6.3.0 which is not stable yet. I did not hit any problems > on amd64 with gcc-5.4.0-r3? > > Are you getting any problems with gcc-5.4.0-r3 on x86? Yes, sys-devel/gcc-5.4.0-r3 on (stable) x86. I attached build.log and "emerge --info" details to bug 625266.
(In reply to Thomas Deutschmann from comment #9) > (In reply to Anthony Basile from comment #8) > > That bug has gcc-6.3.0 which is not stable yet. I did not hit any problems > > on amd64 with gcc-5.4.0-r3? > > > > Are you getting any problems with gcc-5.4.0-r3 on x86? > > Yes, sys-devel/gcc-5.4.0-r3 on (stable) x86. I attached build.log and > "emerge --info" details to bug 625266. The problem is in tests, so I've added RESTRICT=test for 2.6.0 so we can continue with the stabilization. I don't know why cd-ing directly into the build directory and running make check works, but it doesn't from the portage environment. So it looks like its more an issue of tests not working right in portage rather than `make check` being broken. I'll take care of the remaining two arches, arm and x86.
x86 stable without running test suite
arm stable, all done
sparc stable (thanks to Rolf Eike Beer)
(In reply to Sergei Trofimovich from comment #13) > sparc stable (thanks to Rolf Eike Beer) thanks i'll unmask it
