On Mon, 3 Aug 2015 09:58:35 -0300 Antonio Terceiro wrote: > On Sat, Aug 01, 2015 at 04:55:28PM +0200, Francesco Poli wrote: [...] > > B) modify libruby to link with a GPL-compatible SSL/TLS implementation > > (such as libgnutls or libnss or anything else fit for the purpose), > > so that SSL/TLS is supported without loading GPL-incompatible > > libraries [...] > > > > Would strategy B be feasible? > > I would only consider doing something like this if the code to make that > work is accepted upstream, and properly supported by the upstream > maintainers. I can understand. But do you think it would be feasible (assuming there's the green light from upstream)? > > It's probably easier to make apt-listbugs use ruby-curb instead of > net/https. ruby-curb is a libcurl binding, that is linked against > libcurl-gnutls by default on Debian. Well, apt-listbugs just passes a URL to the SOAP library... It's ruby-soap4r that loads 'net/https', when the use of SSL is requested (that is to say, when the URL is "https://bugs.debian.org:443/cgi-bin/soap.cgi"; instead of "http://bugs.debian.org:80/cgi-bin/soap.cgi";). Hence, I suppose it's ruby-soap4r that would have to use ruby-curb instead of net/https. Do you think that this could be done without too many complications? P.S.: thanks for your reply, Antonio! :-) -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
Attachment:
pgpCLJVzgmeHZ.pgp
Description: PGP signature