[Pkg-ganeti-devel] GHC and GMP via FFI don't play well together (#751886)

[Apollon Oikonomopoulos]

Hi,

On 23:11 Sat 05 Jul     , Joachim Breitner wrote:
> Hi,
> 
> Am Donnerstag, den 03.07.2014, 10:42 +0300 schrieb Apollon Oikonomopoulos:
> > > But in any case I don’t see this being fixed on the GHC side until 7.10
> > > (at the earliest, if people help with Erik’s effort and this makes it
> > > into the compiler). Maybe we should consider your first option (linking
> > > tls against OpenSSL), after a license analysis of the packages we
> > > include in Debian. Would you see if that compiles and works for you? And
> > > what about libcurl4-nss-dev?
> > 
> > Linking haskell-curl against the OpenSSL variant of cURL works and SSL 
> > is stable again. Unfortunately, the NSS variant does not work, it fails 
> > to load the CA certificate from a cert + key PEM file, and I can assume 
> > this will not be the only issue. Note that in main only 6 packages are 
> > linked against the NSS variant of libcurl, as opposed to 63 using 
> > OpenSSL and 293 using GnuTLS.
> > 
> > I would really like to see two variants for libghc-curl-dev (OpenSSL + 
> > GnuTLS), but libcurl's packaging makes this difficult; we would either 
> > have to use two identical source packages with different B-Ds, or 
> > "manually" alter the linker path and provide the libcurl.so symlinks 
> > during build (which is an ugly hack of course).
> 
> what’s the point in having a GnuTLS variant if it does not work
> properly?

Well, for single-threaded programs using only the blocking curl API, it 
should work, but there's a lot of "if's" there, so I guess you're right.

> 
> According to
> 
> $ cat /var/lib/apt/lists/http.debian.net_debian_dists_sid_main_source_Sources |grep-dctrl -F Build-Depends libghc-curl-dev -s Package
> 
> only
>         Package: ganeti
>         Package: haskell-download-curl
>         Package: haskell-hxt-curl
>         Package: haskell-scrobble
>         Package: hoauth
> are affected. Of these, all but ganeti are BSD licensed, so there should
> be no problem using gnutls-openssl here.
> 
> This leaves ganeti. Which I guess is too important to just leave behind
> when switching to gnutls-openssl. (CC’ing the ganeti maintainers, just
> to make sure they are aware of this problem.)

Currently I am the main ganeti maintainer; I have already talked about 
this with upstream, there is a good chance they will add an OpenSSL 
exception.

> Sorry, but I feel stuck here.

No problem, thanks for your time and interest!

Greetings,
Apollon