On Tuesday 22 March 2016 03:48:48 Chris Knadle wrote: [snip] > > 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.
Well, we should keep an eye on that for sure.
> 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.
Actually as far as I understand it this will make src:qt4-x11 and src:qtbase
to be involved in the next libssl transition, thus the breakage should be just
a normal one.
> 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.
Easy: instead of creating a new package just ship a very very simple app
alongside libqt4-network/libqt5network5. This will make dh_shlibdeps add the
current version of libssl as a dependency of the package so we can warrant two
things: the src package will get rebuilt with any libssl transition and an
appropriate version of libssl will be a hard dependency of each qtnetwork
package.
We just need to use the proper licensing for that dummy app :)
That being said I'm not having much time on my hands to code and integrate the
app, although I would definitely do it if I happen to have it.
> > 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.
Excellent! Let's hope that happens in time for Stretch.
--
Background: talking about Nokia's aquisition of Trolltech.
<mukidohime> That's why there's the FreeQt agreement, a poison pill against
just that sort of thing.
...
<MoDaX> mukidohime: agreements can be broken
<mukidohime> MoDaX: Yes, with a massive lawsuit following soon after.
<mukidohime> If Nokia pulled something like that, aseigo would entirely pull
some sort of dragonball Z-esque maneuver, and it would probably
be visible from the ISS.
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
signature.asc
Description: This is a digitally signed message part.
