Bug#818943: possibly add -openssl-linked ./conifugre option for building Qt (issue with Mumble)
Lisandro Damián Nicanor Pérez Meyer:
> First of all sorry for the formatting, I'm on the phone right now.
The mail seems to contain both HTML and TEXT, so no worries AFAIC.
> Second: thanks for digging this issue that much! I have now a quite clear
> (although I might need to re read something) idea of the issue.
I've been working on this problem since early November. ;-) It's been both
a frustrating and fascinating bug to work on, and I've learned a bit in the
process. Thankfully I've also had a good bit of help -- there's no way I
would have figured this out on my own.
> Let's start with the configure option: the problem it's not a technical
> one. If we forget about possible licensing problems then using the
> necessary switch is just one upload away.
>
> Now I can't decide whether it's safe or not to use this option
> license-wide. As I understand this the RT is not the authoritative source
> for this, but the FTP team.
Yes another DD I commonly work with told me that [debian-legal] is just a
discussion list and that the FTP masters have final say concerning both
legal and licensing issues [concerning package uploads]. That seems like a
lot of responsibility.
> Even if I'm wrong wrt team's responsabilities, I'm still uncertain wrt
> the licensing issue. As far as I understand nothing has changed
> license-wide, so Modestas' reply is still valid.
>
> Sadly I can't also think of a way of marking qt to be rebuilt with some
> libssl upload without linking to it...
>
> I'm afraid the only suitable fix would be to fix ssl's licensing terms.
This is another interesting twist -- Kurt reported OpenSSL upstream is
looking to change the license (to the Apache2 license, sounds like) but
hasn't happened yet:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804487#112
and if you see the message that follows it says that there are still likely
some GPLv2 licensing incompatibilities to consider.
Lisandro Damián Nicanor Pérez Meyer:
> On Monday 21 March 2016 21:47:50 Lisandro Damián Nicanor Pérez Meyer
> wrote: [snip]
>> Sadly I can't also think of a way of marking qt to be rebuilt with some
>> libssl upload without linking to it...
>
> Actually there is a **very** **hackish** way to let qt4/qtbase be rebuilt
> with the necessary libssl versions. It would be possible to code a very
> simple app that links against it with the proper licensing terms and ship
> it in it's own binary package. This app would be built from qt4/qtbase's
> src. Yes, that means a useless binary package in the archive...
Ooof. A sort of "fake" package for metadata purposes. Yeah I see it; thank
you for mentioning the idea. If it comes to that naturally I'd want to
mention the bug reports in either a README file in the "fake" package and/or
the description in the debian/control file to make it clear why the package
exists.
This would shorten the length of time of the transition and so would either
shorten the time of Mumble breakage or the time where Mumble would double
load libssl/libcrypto versions, and leaves the dilemma of which of these to do.
Lisandro Damián Nicanor Pérez Meyer:
> Actually the binary built can be installed in a private path alongside
> qtnetwork (in it's package) and might even be a private lib without
> headers. That should be enough to keep stuff in sync.
I'm not sure I fully understand this, but it vaguely sounds good.
> By the way, how is mumble's porting to qt5 going?
That part is already ready. Mumble 1.3.x (which doesn't yet have a release)
already builds with Qt5 fine and I've got the Debian packaging ready for
when there's a release to ship. Mumble 1.3.x can be built with Qt4 or Qt5,
Mumble 1.4.x will be Qt5 only.
-- Chris
--
Chris Knadle
Chris.Knadle@coredump.us
Reply to: