Bug#927471: curl: Regression that fails to exhaust socket data

[Alessandro Ghedini]

On Sat, Apr 20, 2019 at 01:39:36PM +0200, Guillem Jover wrote:
> Source: curl
> Source-Version: 7.64.0-2
> Severity: serious
> Control: affects -1 rtorrent
> 
> Hi!

Hello,

> I've started noticing rtorrent busy-looping at some points after
> finishing a torrent. stracing and gdb'ing the process it was doing
> that in its main loop, spamming on gettimeofday() and epoll_wait().
> 
> Checking the rtorrent dependencies I've not seen much suspicious
> updated recently, except for curl. I checked then the upstream bug
> trackers and noticed quite many instances of "100% cpu usage" reports,
> such as . And that
> one points to old and new curl issue. The last instance of it appears
> to have been fixed with 
> in 7.64.1.
> 
> So I think curl should be either upgraded to that release, or the
> relevant commits cherry-picked.

I prepared an update for the curl package with the two upstream patches applied
(38d8e1b and 4015fae), and uploaded the result for amd64 at:
https://people.debian.org/~ghedo/libcurl4_7.64.0-3_amd64.deb

Guillem, could you try this version of the package and see if it fixes the
issue for you? Once that's confirmed I'll upload to sid and ask for unblock.

Cheers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Sat, Feb 24, 2018 at 12:50:41PM +, Alessandro Ghedini wrote:
> On Wed, Feb 21, 2018 at 11:14:24AM -0800, Steve Langasek wrote:
> > Hi again,
> > 
> > On Tue, Feb 20, 2018 at 06:16:34PM -0800, Steve Langasek wrote:
> > > So, despite Julien's valid objection that core library conflicts cause
> > > dist-upgrades to be more brittle, I think the right answer here is:
> > 
> > > - keep all sonames as-is.
> > > - rename libcurl3 to libcurl4.
> > > - leave the package names of the other variants as-is.
> > > - *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
> > >   elsewhere outside the Debian ecosystem, fix the symbol versions for
> > >   libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that 
> > > CURL_FOO_4
> > >   is used as the preferred name and CURL_FOO_3 is for compatibility only.
> > >   (This is only worth doing if this increases binary compatibility;
> > >   otherwise it's better to maintain bidirectional binary compatibility for
> > >   Debian-built binaries.)
> > > - change the symbol versions for libcurl4 to CURL_OPENSSL_4.
> > 
> > > I would be willing to prepare a patch that implements this.
> > 
> > I've done this now and raised an MP:
> > 
> >   https://salsa.debian.org/debian/curl/merge_requests/3
> > 
> > (I'm assuming there is no point in CURL_FOO_4 symbol version for
> > libcurl-gnutls and libcurl-nss, because these sonames come from a
> > Debian-specific patch and therefore there's no upstream binary compatibility
> > to be concerned about.)
> > 
> > Thoughts on this?
> > 
> > In terms of ABI changes, this appears to be a strict subset of what
> > Alessandro had proposed and would be binary-compatible for libcurl.so.4; so
> > at minimum, we will probably adopt this change in Ubuntu and proceed with
> > the transition ASAP there, even if Debian later decides to change the ABI
> > for gnutls and nss variants also.
> 
> I'm fine with going ahead with just the libcurl3 -> libcurl4 transition for
> now.
> 
> Julien: is this something that the Release Team would be ok with? As Steve
> pinted out before, libcurl3 has significantly lower usage than lubcurl3-gnutls
> so impact should be somewhat more limited.
> 
> I'd like to go ahead and upload Steve's patch to experimental (which means NEW
> queue) soon, and then request the transition.

Quick update, with a slight delay I went ahead and uploaded Steve's changes to
experimental as curl 7.58.0-3, which got accepted in record time, so I also
requested the transition https://bugs.debian.org/891872

Thanks a lot to everyone involved for the help with this.

Cheers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Wed, Feb 21, 2018 at 11:14:24AM -0800, Steve Langasek wrote:
> Hi again,
> 
> On Tue, Feb 20, 2018 at 06:16:34PM -0800, Steve Langasek wrote:
> > So, despite Julien's valid objection that core library conflicts cause
> > dist-upgrades to be more brittle, I think the right answer here is:
> 
> > - keep all sonames as-is.
> > - rename libcurl3 to libcurl4.
> > - leave the package names of the other variants as-is.
> > - *if* libcurl-gnutls.so.4 and libcurl-nss.so.4 sonames are known to exist
> >   elsewhere outside the Debian ecosystem, fix the symbol versions for
> >   libcurl3-gnutls and libcurl3-nss to use symbol aliases, so that CURL_FOO_4
> >   is used as the preferred name and CURL_FOO_3 is for compatibility only.
> >   (This is only worth doing if this increases binary compatibility;
> >   otherwise it's better to maintain bidirectional binary compatibility for
> >   Debian-built binaries.)
> > - change the symbol versions for libcurl4 to CURL_OPENSSL_4.
> 
> > I would be willing to prepare a patch that implements this.
> 
> I've done this now and raised an MP:
> 
>   https://salsa.debian.org/debian/curl/merge_requests/3
> 
> (I'm assuming there is no point in CURL_FOO_4 symbol version for
> libcurl-gnutls and libcurl-nss, because these sonames come from a
> Debian-specific patch and therefore there's no upstream binary compatibility
> to be concerned about.)
> 
> Thoughts on this?
> 
> In terms of ABI changes, this appears to be a strict subset of what
> Alessandro had proposed and would be binary-compatible for libcurl.so.4; so
> at minimum, we will probably adopt this change in Ubuntu and proceed with
> the transition ASAP there, even if Debian later decides to change the ABI
> for gnutls and nss variants also.

I'm fine with going ahead with just the libcurl3 -> libcurl4 transition for
now.

Julien: is this something that the Release Team would be ok with? As Steve
pinted out before, libcurl3 has significantly lower usage than lubcurl3-gnutls
so impact should be somewhat more limited.

I'd like to go ahead and upload Steve's patch to experimental (which means NEW
queue) soon, and then request the transition.

Cheers


signature.asc
Description: PGP signature

Bug#858398: curl: Please migrate to openssl1.1 in Buster

[Alessandro Ghedini]

On Sun, Dec 17, 2017 at 11:16:29PM +0200, Adrian Bunk wrote:
> On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote:
> > Hi,
> > 
> > just innocent bystander here with an observation:
> > 
> > These two options:
> > 
> > a)
> > > I do agree it's the correct solution though, and it would be a good 
> > > opportunity
> > > to finally sync SONAME with upstream
> > 
> > b)
> > > Because of 1 I think we should change the package name (and SONAME) for
> > > libcurl3.  I don't think 2 is appropriate.
> > 
> > are mutually exclusive, so even if we rename the share library packages
> > to libcurl4*, they would have to conflict with libcurl3* because they
> > would contain same files.
> > 
> > And the SONAME is already libcurl.so.4 (at least on stretch):
> > 
> > $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl-gnutls.so.4
> >   SONAME   libcurl.so.4
> >   SONAME   libcurl.so.4
> >   SONAME   libcurl.so.4
> > 
> > So in this case, unfortunately, bumping the SONAME is actually something
> > different than changing package name to match to SONAME of the library. 
> >...
> 
> Similar to all the v5 postfixed packages in Debian for C++ ABI changes 
> in GCC 5, what matter here is actually not the SONAME but the package
> name and that the new package conflicts with the old package.
> 
> This is sufficient to fix the issue for all packages using curl.
> 
> And different from breaks on specific packages, it will also force an
> upgrade of packages from backports.
> 
> Non-packaged software is a different topic, but the whole OpenSSL 
> situation in stretch is already a mess for that.
> 
> This whole transition looks pretty straightforward to me,
> please let me know if there is anything where I could help.

Following Adrian's comment, I prepated a patch that:

 * Renames *all* lincurl3* packages to libcurl4* (with Conflicts+Replaces)
 * Removes the hacks for old SONAME and updates symbols (as Ondrej correctly
   pointed out, the SONAME doesn't actually change as ww already ship a
   "libcurl.so.4", but the lib symlinks and the symbols do)
 * Makes the OpenSSL libcurl build against OpenSSL 1.1

I think this satisfies all the requirements for the OpenSSL migration, as well
as finally cleaning up the mess from the last botched transition as an added
bonus.

Thoughts?

The patch is at https://salsa.debian.org/debian/curl/merge_requests/2

Cheers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Sat, Dec 02, 2017 at 06:09:39PM +0100, Julien Cristau wrote:
> On Thu, Nov 23, 2017 at 15:49:26 +, Ian Jackson wrote:
> > Reasons I am aware that it *might* be a bad idea are:
> > 
> > 1. libcurl exposes parts of the openssl ABI, via
> >CURLOPT_SSL_CTX_FUNCTION, and this would be an implicit ABI break
> >without libcurl soname change.  This is not good, but it seems like
> >the alternative would be to diverge our soname from everyone else's
> >for the same libcurl.
> > 
> > 2. For the reason just mentioned, it might be a good idea to put in a
> >Breaks against old versions of packages using
> >CURLOPT_SSL_CTX_FUNCTION.  However, (a) I am not sure if this is
> >actually necessary (b) in any case I don't have a good list of all
> >the appropriate versions (c) maybe this would need coordination.
> > 
> > 3. This might be an implicit a "transition" (in the Debian release
> >management sense) which I would be mishandling, or starting without
> >permission, or something.
> > 
> Because of 1 I think we should change the package name (and SONAME) for
> libcurl3.  I don't think 2 is appropriate.

Following discussion on the ticket (#858398) it was suggested to follow the
strategy used for the GCC 5 C++ ABI transition, that is, rename the libcurl
package and add Conflicts+Replaces for teh old package.

Due to the fact that the previous transition (libcurl3 -> libcurl4) was
partially reverted (in 2007 according to the changelog), I'd also like to
taeke this opportunity to finally complete that as well, so I made a patch
to not only rename libcurl3 -> libcurl4, but also (libcurl3-gnutls,
libcurl3-nss) -> (libcurl4-gnutls, libcurl4-nss), and remove the hacks needed
to keep compatibility with the previous ABI.

Thoughts?

The patch is at https://salsa.debian.org/debian/curl/merge_requests/2

CHeers


signature.asc
Description: PGP signature

Bug#858398: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Thu, Nov 23, 2017 at 07:10:51PM +, Ian Jackson wrote:
> Adrian Bunk writes ("Re: Proposed (lib)curl switch to openssl 1.1"):
> > What I suggest above would be a transition that should be coordinated
> > with the release team like other transitions.
> 
> I'm not 100% opposed to doing this as a normal library transition with
> a soname change.  I don't feel I understand the tradeoffs well.

Well, one downside is that doing a full blown transition is likely to take
more work and time to see it completed. Unfortunately I don't have the time
required and can't commit to doing this myself.

I do agree it's the correct solution though, and it would be a good opportunity
to finally sync SONAME with upstream (last time a transition of libcurl was
attempted some 10 years or so ago, it was halted for reasons now lost in the
mists of time, so we have been stuck carrying some hacks to pretend we are
still using the old SONAME, see e.g. [0] [1]).

Cheers

[0] 
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/patches/03_keep_symbols_compat.patch
[1] 
https://anonscm.debian.org/cgit/collab-maint/curl.git/tree/debian/libcurl3.links


signature.asc
Description: PGP signature

Bug#845278: closed by Arturo Borrero Gonzalez <art...@debian.org> (Bug#845278: fixed in iptables 1.6.0+snapshot20161117-3)

[Alessandro Ghedini]

On Tue, Nov 22, 2016 at 09:06:05AM +, Debian Bug Tracking System wrote:
>  iptables (1.6.0+snapshot20161117-3) unstable; urgency=medium
>  .
>* [21fdc57] libxtables12: breaks and replaces libxtables11 (Closes:
>  #845278)

This isn't actually fixed, "<<" doesn't mean what you think it means. It only
applies to version that are strctly lower than 1.6.0+snapshot20161117-1, not
lower or equal. The upgrade is still broken.

Cheers

Bug#842311: node-grunt-cli: uninstallable due to wrong dependency

[Alessandro Ghedini]

Package: node-grunt-cli
Version: 1.2.0-1
Severity: grave
Justification: renders package unusable

Hello,

when trying to install the package I get:

  The following packages have unmet dependencies:
   node-grunt-cli : Depends: node-findup-sync (>= 0.3.0) but 0.1.3-1 is to be 
installed
  E: Unable to correct problems, you have held broken packages.

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature

Bug#836456: AttributeError: 'file' object has no attribute 'readable'

[Alessandro Ghedini]

Package: dput
Version: 0.10.2
Severity: grave
Justification: renders package unusable

Hello,

every time I try to upload something I get the following:

>  % dput local-desktop_0.83_amd64.changes
> Trying to upload package to ghedini.me
> Checking signature on .changes
> Traceback (most recent call last):
>   File "/usr/bin/dput", line 11, in 
> load_entry_point('dput==0.10.2', 'console_scripts', 'execute-dput')()
>   File "/usr/share/dput/dput/dput.py", line 1053, in main
> config, check_only, check_version, unsigned_upload, debug)
>   File "/usr/share/dput/dput/dput.py", line 415, in verify_files
> config, check_only, unsigned_upload, binary_upload, debug)
>   File "/usr/share/dput/dput/dput.py", line 313, in verify_signature
> check_signature(changes_file)
>   File "/usr/share/dput/dput/dput.py", line 248, in check_signature
> gnupg_stdout = dputhelper.make_text_stream(gnupg_subprocess.stdout)
>   File "/usr/share/dput/dput/helper/dputhelper.py", line 188, in 
> make_text_stream
> result = io.TextIOWrapper(stream, encoding=encoding)
> AttributeError: 'file' object has no attribute 'readable'
> gpg: Signature made Sat 03 Sep 2016 12:33:10 BST
> gpg:        using RSA key 6F0CCBE021624728
> gpg:issuer "gh...@debian.org"
> gpg: Good signature from "Alessandro Ghedini <alessan...@ghedini.me>" 
> [unknown]
> gpg: aka "Alessandro Ghedini <alex...@cpan.org>" [unknown]
> gpg: aka "Alessandro Ghedini <gh...@debian.org>" [unknown]

then dput dies and the pckage does not get uploaded.

Cheers

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dput depends on:
ii  gnupg 2.1.15-2
ii  python-debian 0.1.29
ii  python-pkg-resources  26.1.1-1
pn  python:any

dput recommends no packages.

Versions of packages dput suggests:
pn  lintian 
pn  mini-dinstall   
ii  openssh-client  1:7.3p1-1
pn  rsync   

-- no debconf information


signature.asc
Description: PGP signature

Bug#830273: curl: accesses the internet during build

[Alessandro Ghedini]

On Sat, Aug 20, 2016 at 11:50:56am +0100, Chris Lamb wrote:
> found 830273 7.50.1-1
> thanks
> 
> Alas,
> 
>   00:00:00.00 IP 370637f7189a.58723 > 10.0.1.1.domain: 48987+ A? 
> 1216.256.2.127. (32)
>   00:00:00.73 IP 370637f7189a.58723 > 10.0.1.1.domain: 25462+ ? 
> 1216.256.2.127. (32)
>   00:00:00.016656 IP 10.0.1.1.domain > 370637f7189a.58723: 25462 NXDomain* 
> 0/0/0 (32)
>   00:00:00.017927 IP 10.0.1.1.domain > 370637f7189a.58723: 48987 NXDomain* 
> 0/0/0 (32)
>   00:00:00.018115 IP 370637f7189a.52668 > 10.0.1.1.domain: 12746+ A? 
> 1216.256.2.127.chris-lamb.co.uk. (49)
>   00:00:00.018273 IP 370637f7189a.52668 > 10.0.1.1.domain: 22321+ ? 
> 1216.256.2.127.chris-lamb.co.uk. (49)
>   00:00:00.048244 IP 10.0.1.1.domain > 370637f7189a.52668: 12746 NXDomain* 
> 0/0/0 (49)
>   00:00:00.050825 IP 10.0.1.1.domain > 370637f7189a.52668: 22321 NXDomain* 
> 0/0/0 (49)
>   00:08:27.786810 IP 370637f7189a.46161 > 10.0.1.1.domain: 11686+ A? 
> 1216.256.2.127. (32)
>   00:08:27.786863 IP 370637f7189a.46161 > 10.0.1.1.domain: 44570+ ? 
> 1216.256.2.127. (32)
> 
>   [..]
> 
> The full build log (including tcpdump output) is attached.

Possible patch attached, could you please test it?

Thanks
From dcb559a161960ff387d2b1552ec4c81b54db4554 Mon Sep 17 00:00:00 2001
From: Alessandro Ghedini <alessan...@ghedini.me>
Date: Sun, 28 Aug 2016 14:45:15 +0100
Subject: [PATCH 1/2] Disable more network tests

Closes: #830273
---
 debian/patches/10_disable-network-tests.patch | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/debian/patches/10_disable-network-tests.patch b/debian/patches/10_disable-network-tests.patch
index 119df54..9bc4cd2 100644
--- a/debian/patches/10_disable-network-tests.patch
+++ b/debian/patches/10_disable-network-tests.patch
@@ -37,3 +37,13 @@ Last-Update: 2016-08-03
  
  
  
+--- a/tests/data/test237
 b/tests/data/test237
+@@ -2,6 +2,7 @@
+ 
+ 
+ FTP
++non-existing host
+ 
+ 
+ 
-- 
2.9.3



signature.asc
Description: PGP signature

Bug#797470: libval14: val_dane_check: usage DANE-TA(2) may bypass cert validation entirely

[Alessandro Ghedini]

On Mon, Aug 31, 2015 at 10:53:21am +0200, Ondřej Surý wrote:
> Hi security team and Thomas,
> 
> I propose following patch for libval14 in stable:
> 
> Index: validator/libval/val_dane.c
> ===
> --- validator/libval/val_dane.c (revision 8325)
> +++ validator/libval/val_dane.c (working copy)
> @@ -766,23 +766,6 @@
>  break;
>  
>  case DANE_USE_TA_ASSERTION: /*2*/ {
> -SSL_CTX *ctx = SSL_get_SSL_CTX(con);
> -X509_STORE *store;
> -*do_pathval = 0;
> -if (store = X509_STORE_new()) {
> -X509 *tlsa_cert = NULL;
> -c = dane_cur->data;
> -tlsa_cert = d2i_X509(NULL, (const unsigned char
> **), 
> - dane_cur->datalen);
> -X509_STORE_add_cert(store, tlsa_cert);
> -SSL_CTX_set_cert_store(ctx, store);
> -if (SSL_get_verify_result(con) == X509_V_OK) {
> -val_log(context, LOG_INFO, "DANE:
> val_dane_match() success");
> -rv = VAL_DANE_NOERROR;
> -goto done;
> -}
> -}
> -
>  val_log(context, LOG_NOTICE, 
>  "DANE: val_dane_check() for usage %d failed",
>  dane_cur->usage);
> 
> 
> It will just make the DANE validation fail when 2 usage scenario is
> encountered.

I noticed that you applied this patch in unstable closing #797470, but then you
reopened it. Does that mean that the patch is not enough?

> Unfortunately the code in 2.1 has diverted too much (API change), so we
> are not able to use the (possibly fixed) code from there.
> 
> I will also file a bug for irssi and kamailo to drop the libval usage
> and remove the dnsval library from the Debian unless I have a strong
> promise from upstream that they will take care of the library.

It would maybe make sense to drop dnsval from jessie as well (though both irssi
and kamailio would need to be updated there too). Could you try to contact the
Release Team and see what they think about this?

Thanks


signature.asc
Description: Digital signature

Bug#795958: lynx-cur: certificate revocation checking is buggy

[Alessandro Ghedini]

On Tue, Aug 18, 2015 at 01:32:19pm +0200, Vincent Lefevre wrote:
 Package: lynx-cur
 Version: 2.8.9dev6-3
 Severity: serious
 Tags: security
 
 If I run
 
   lynx https://www.vinc17.net:4434/
 
 I get
 
   SSL error:The certificate is NOT trusted. The certificate chain is revoked.
   -Continue? (n) 
 
 as expected. But If I set up a test server with the same certificate
 with:
 
   openssl s_server -CAfile old.crt -key old.key -cert old.crt -www

Try adding the -status option here.

I think the problem is that both lynx and curl only support OCSP stapling,
while firefox also does full-blown OCSP. So, if you don't enable OCSP stapling
in s_server (with the -status option), lynx and curl won't receive any response,
while firefox will also try to contact the CA's OCSP server and receive a
response from that.

It's more like lack of a feature than an actual bug (hardly RC material though,
IMO).

Hope this helps.

Cheers


signature.asc
Description: Digital signature

Bug#794851: CVE-2015-0851: shibboleth-sp2 needs to be rebuilt against new xmltooling

[Alessandro Ghedini]

Control: found -1 opensaml2/2.4.3-4
Control: fixed -1 opensaml2/2.4.3-4+deb7u1
Control: fixed -1 opensaml2/2.5.3-2+deb8u1

On Fri, Aug 07, 2015 at 12:36:18pm +0200, Sergio Gelato wrote:
 Package: opensaml2
 Version: 2.5.3-2
 Severity: serious
 Tags: security
 
 The upstream security advisory for CVE-2015-0851 (see #793855) states
 in part: Correcting this bug requires that the OpenSAML library be
 rebuilt against the corrected version of the XMLTooling-C library,
 which is normally assured by obtaining updates to both.

Yes, sorry for the delay. I just released fixed opensaml2 packages for wheezy
and jessie security.

Given that unstable is still vulnerable (since a fixed xmltooling version
hasn't been uploaded yet), I'll leave this open for now.

Cheers


signature.asc
Description: Digital signature

Bug#787960: libcurl3-gnutls: breaks bti

[Alessandro Ghedini]

On dom, giu 07, 2015 at 01:44:36 +0200, Vincent Lefevre wrote:
 On 2015-06-07 11:40:56 +0200, Alessandro Ghedini wrote:
  I can't reproduce any of this. Can you please run the command above
  with the -v option and post the output?
 
 xvii:~ curl -v https://www.vinc17.net/
 *   Trying 92.243.22.117...
 * Connected to www.vinc17.net (92.243.22.117) port 443 (#0)
 * found 180 certificates in /etc/ssl/certs/ca-certificates.crt

Ok, nevermind, that looks ok. Looking at your original report again, I noticed
the following:

 Versions of packages libcurl3-gnutls depends on:
  [...]
  ii  libgnutls-deb0-28  3.3.14-2

Essentially you have installed an older version of libgnutls-deb0-28 (the
current one is 3.3.15-5). I think the problem is that the older libgnutls uses
a different version of nettle (libnettle.so.4) than the one libcurl3-gnutls
uses (libnettle.so.6), and they somehow interfere with each other since nettle
doesn't use symbols versioning.

Could you update libgnutls-deb0-28 and see what happens? In any case it doesn't
look like a libcurl bug, although maybe the versioned depends on libgnutls could
be strengthened (it's currently calculated automatically by dpkg-shlibdeps).

Cheers


signature.asc
Description: Digital signature

Bug#787960: libcurl3-gnutls: breaks bti

[Alessandro Ghedini]

On dom, giu 07, 2015 at 12:21:15 +0200, Vincent Lefevre wrote:
 Control: retitle -1 no longer works with https - breaks bti and curl
 
 On 2015-06-07 00:16:15 +0200, Vincent Lefevre wrote:
  After the upgrade to libcurl3-gnutls 7.42.1-2+b1, bti no longer works
  at all. For instance:
 [...]
 
 It also breaks curl:
 
 $ curl https://www.vinc17.net/
 curl: (60) server certificate verification failed. CAfile: 
 /etc/ssl/certs/ca-certificates.crt CRLfile: none
 More details here: http://curl.haxx.se/docs/sslcerts.html

I can't reproduce any of this. Can you please run the command above with the
-v option and post the output? Also, what's the content of the file
/etc/ssl/certs/ca-certificates.crt?

Cheers


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:43:37PM +0200, Alessandro Ghedini wrote:
 On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
  On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
   On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
Version: 6:11.3-1

On 2015-05-14 20:41:15, Arne Wichmann wrote:
 Package: libavcodec56
 Version: 6:11.3-2
 Severity: grave
 Tags: security
 Justification: user security hole
 
 Hi, as far as I can see this has not yet been reported or fixed:
 
 CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c 
 in
 FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, 
 allow
 remote attackers to cause a denial of service (use-after-free) or 
 possibly
 have unspecified other impact via crafted Vorbis I data [1]
 
 I marked this as grave as the impact is unclear and might include 
 arbitrary
 code execution. Feel free do downgrade if this can be ruled out.
 
 (Actually I would like to have a look at the test case to check a bit 
 more
 thoroughly, but AFAICS I would need to talk to google for this.)
 
 [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
   
 https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html

A similar commit to the one maintained in this mailing list post was 
applied to
11.3. So closing with that version.
   
   Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
   patch at
   all, and the commit message doesn't even mention the bug fix. How can you 
   be so
   sure that the bug is fixed?
  
  I might have read the commit wrong. Do you have a sample for this CVE?
 
 Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
 it, I'll keep you posted.

I got the reproducer from ffmpeg and it seems that libav in sid isn't affected
like Sebastian said. So yeah, this bug should stay closed. I don't know if the
patch linked above is what fixed the issue though.

Cheers


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Sat, May 16, 2015 at 03:07:57PM +0200, Sebastian Ramacher wrote:
 On 2015-05-15 15:22:28, Alessandro Ghedini wrote:
  On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
   Version: 6:11.3-1
   
   On 2015-05-14 20:41:15, Arne Wichmann wrote:
Package: libavcodec56
Version: 6:11.3-2
Severity: grave
Tags: security
Justification: user security hole

Hi, as far as I can see this has not yet been reported or fixed:

CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
remote attackers to cause a denial of service (use-after-free) or 
possibly
have unspecified other impact via crafted Vorbis I data [1]

I marked this as grave as the impact is unclear and might include 
arbitrary
code execution. Feel free do downgrade if this can be ruled out.

(Actually I would like to have a look at the test case to check a bit 
more
thoroughly, but AFAICS I would need to talk to google for this.)

[1] https://security-tracker.debian.org/tracker/CVE-2014-7937
  https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
   
   A similar commit to the one maintained in this mailing list post was 
   applied to
   11.3. So closing with that version.
  
  Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg 
  patch at
  all, and the commit message doesn't even mention the bug fix. How can you 
  be so
  sure that the bug is fixed?
 
 I might have read the commit wrong. Do you have a sample for this CVE?

Unfortunately the reproducer isn't public. I contacted ffmpeg-security about
it, I'll keep you posted.

Cheers


signature.asc
Description: Digital signature

Bug#785326: libavcodec56: CVE-2014-7937 - Multiple off-by-one errors in libavcodec/vorbisdec.c

[Alessandro Ghedini]

On Fri, May 15, 2015 at 11:05:17AM +0200, Sebastian Ramacher wrote:
 Version: 6:11.3-1
 
 On 2015-05-14 20:41:15, Arne Wichmann wrote:
  Package: libavcodec56
  Version: 6:11.3-2
  Severity: grave
  Tags: security
  Justification: user security hole
  
  Hi, as far as I can see this has not yet been reported or fixed:
  
  CVE-2014-7937 : Multiple off-by-one errors in libavcodec/vorbisdec.c in
  FFmpeg before 2.4.2, as used in Google Chrome before 40.0.2214.91, allow
  remote attackers to cause a denial of service (use-after-free) or possibly
  have unspecified other impact via crafted Vorbis I data [1]
  
  I marked this as grave as the impact is unclear and might include arbitrary
  code execution. Feel free do downgrade if this can be ruled out.
  
  (Actually I would like to have a look at the test case to check a bit more
  thoroughly, but AFAICS I would need to talk to google for this.)
  
  [1] https://security-tracker.debian.org/tracker/CVE-2014-7937
https://lists.libav.org/pipermail/libav-devel/2015-January/066433.html
 
 A similar commit to the one maintained in this mailing list post was applied 
 to
 11.3. So closing with that version.

Do you mean the patch at [0]? Honestly it doesn't look like the ffmpeg patch at
all, and the commit message doesn't even mention the bug fix. How can you be so
sure that the bug is fixed?

Cheers

[0] 
https://github.com/libav/libav/commit/0025f7408a0fab2cab4a950064e4784a67463994


signature.asc
Description: Digital signature

Bug#779201: kfreebsd-{8,9}: CVE-2015-1414: DoS via IGMP packet

[Alessandro Ghedini]

On Sun, May 10, 2015 at 09:12:43PM +0100, Steven Chamberlain wrote:
 Dear Security Team,
 
 This bug was reopened because the original fix from upstream was found
 to be incomplete.
 
 Please may I upload to wheezy-security with the attached debdiff,
 replacing the CVE-2015-1414 patch with the new one, and also patching
 CVE-2015-2923 (Debian Bug #782735).

Looks good, go ahead and upload.

Thanks


signature.asc
Description: Digital signature

Bug#763148: Prevent migration to jessie

[Alessandro Ghedini]

On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
  Since there are concerns on shipping both libav and ffmpeg, we won't allow
  ffmpeg unless it is chosen to be the default and there is a clear transition
  plan, so that we can switch from one to the other. Only then will the block 
  hint
  be removed.
 There are no technical reasons for not having both in testing an I see
 this the only fair solution. There are no name- nor symbol collision
 between the packages. They co-exist perfectly on my systems, too.

There is at least one reason that I can think of. Assuming the decision to keep
either libav or ffmpeg (not both) stands, if ffmpeg is allowed to migrate and
other packages start depending on it, and if before the stretch release ffmpeg
is deemed not release ready (e.g. if libav is chosen), then more work will be
required to untangle the dependencies and have ffmpeg removed from testing.

Cheers


signature.asc
Description: Digital signature

Bug#763148: Prevent migration to jessie

[Alessandro Ghedini]

On Wed, Apr 29, 2015 at 03:28:40PM +0200, Andreas Cadhalpun wrote:
 Hi Alessandro,
 
 On 29.04.2015 14:58, Alessandro Ghedini wrote:
  On mer, apr 29, 2015 at 02:29:43 +0200, Bálint Réczey wrote:
  Since there are concerns on shipping both libav and ffmpeg, we won't allow
  ffmpeg unless it is chosen to be the default and there is a clear 
  transition
  plan, so that we can switch from one to the other. Only then will the 
  block hint
  be removed.
  There are no technical reasons for not having both in testing an I see
  this the only fair solution. There are no name- nor symbol collision
  between the packages. They co-exist perfectly on my systems, too.
  
  There is at least one reason that I can think of. Assuming the decision to 
  keep
  either libav or ffmpeg (not both) stands,
 
 Great to hear that this is only an assumption and no definitive statement!
 
  if ffmpeg is allowed to migrate and
  other packages start depending on it,
 
 Packages already depend on FFmpeg, simply because they don't work with Libav:

Yes, but they won't migrate to testing either.

  and if before the stretch release ffmpeg
  is deemed not release ready (e.g. if libav is chosen), then more work will 
  be
  required to untangle the dependencies and have ffmpeg removed from testing.
 
 If a preliminary decision is made in e.g. one years time, maintainers would 
 have
 plenty of time to adapt.

The decision has to be taken *now*, not in one year.

Last year, just before the freeze, we (the multimedia team) sort of held a vote
to decide this, but it went in favour of libav. IIRC the reason people voted in
favour of libav was that we were too close to the freeze to do anything.

Now would be the time to start that discussion again. So, instead of wasting
energies arguing against the migration block, I suggest you be the one to
restart that discussion, given that you are the maintainer of ffmpeg.

Cheers


signature.asc
Description: Digital signature

Bug#783258: flac: FTBFS due to missing symbols

[Alessandro Ghedini]

On sab, apr 25, 2015 at 02:16:52 +0200, Fabian Greffrath wrote:
 Control: tags -1 + help
 
 Hi Sebastian,
 
 Am Freitag, den 24.04.2015, 21:27 +0200 schrieb Sebastian Ramacher: 
  | - _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0
  | + _ZN4FLAC7Decoder4File13read_callbackEPhPj@Base 1.3.1-1
  | +#MISSING: 1.3.1-1# _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0
 
 WTF is wrong with C++ symbols files? The symbols are all there, they
 differ just in name by their last character.

C++ symbols get mangled to arch-specific names. To make the *.symbols file work
you need to use the c++ symbols pattern with the demangled C++ symbol names.

E.g. instead of:

  _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base 1.3.0

use:

  (c++)FLAC::Decoder::File::read_callback(unsigned char*, unsigned 
long*)@Base 1.3.0

The demangling can be done using c++filt as follows (not sure if there's an
automatic way to convert a whole symbols file):

  % echo _ZN4FLAC7Decoder4File13read_callbackEPhPm@Base | c++filt
  FLAC::Decoder::File::read_callback(unsigned char*, unsigned long*)@Base

Alternatively you could use the regex symbols pattern, but I don't think it's
the recommended way.

See dpkg-gensymbols(1) for more info.

Cheers


signature.asc
Description: Digital signature

Bug#782160: squeeze update of chrony + wheezy update of chrony

[Alessandro Ghedini]

Hi Joachim,

 Raphael Hertzog wrote on 2015-04-10 21:33:
 
  If that workflow is a burden to you, feel free to just prepare an
  updated source package and send it to debian-...@lists.debian.org
  (via a debdiff, or with an URL pointing to the the source package,
  or even with a pointer to your packaging repository), and the members
  of the LTS team will take care of the rest. Indicate clearly whether you
  have tested the updated package or not.
 
 I would be very pleased, if someone of the LTS team could sponsor 
 my both packages:
 
 for squeeze-security: chrony 1.24-3+squeeze2
 see here:  http://www.joonet.de/sources/chrony/squeeze-security/
 Both architectures were produced with pbuilder in a clean environment.
 The deb files were not tested!
 
 for wheezy-security:  chrony 1.24-3.1+deb7u3
 see here: http://www.joonet.de/sources/chrony/wheezy-security/
 Both architectures were produced with pbuilder in a clean environment.
 The deb file for amd64 were tested, but not for i386.
 
 For your information:
 In the debian directory I have added a directory applied with
 all applied patches to the sources, because both packages still
 have source format 1.0. Only the three patches 11, 12, 13 are
 new.
 
 Changes since the last uploads:
 
   * With the following security bugfixes (See: #782160):
 - Fix CVE-2015-1853: Protect authenticated symmetric NTP
  associations against DoS attacks.
 - Fix CVE-2015-1821: Fix access configuration with subnet
  size indivisible by 4.
 - Fix CVE-2015-1822: Fix initialization of reply slots for
  authenticated commands.

The wheezy update looks good, though in the future I'd avoid adding unnecessary
changes to the package (the debian/applied/ directory in this case) since it
makes reviewing the update harder.

Anyway, thanks for preparing the updated packages, I'll take care of the wheezy
DSA in a bit.

Cheers


signature.asc
Description: Digital signature

Bug#778266: Directory traversal

[Alessandro Ghedini]

Control: tags -1 fixed-upstream patch

On gio, feb 12, 2015 at 11:30:41 +0100, Moritz Muehlenhoff wrote:
 Source: libarchive
 Severity: grave
 Tags: security
 
 Hi,
 please see http://www.openwall.com/lists/oss-security/2015/01/16/7
 for details.

This was fixed upstream, see [0].

Cheers

[0] 
https://github.com/libarchive/libarchive/commit/59357157706d47c365b2227739e17daba3607526


signature.asc
Description: Digital signature

Bug#770648: hiredis: FTBFS: Test failure

[Alessandro Ghedini]

On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
 Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:
  Alrighty, talking this over with Alessandro he made the case that we
  should keep tests that don't rely on external network connections. See
  e.g. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753944 which
  makes the case for a loopback interface in pbuilder.
 
  
  Tobi, to that effect I modified your patch to keep the tests that work
  fine with localhost  thus pass in pbuilder.
 
 I'm ok with everything that fixes this bug :)
 
 Note that the above pbuilder bug is not closed yet;

pbuilder does create a loopback interface with USENETWORK=no, but, according
to that bug report, it still has problems... which makes me wonder, what if this
FTBFS is actually caused by a bug in pbuilder?

 also buildds using AFAIK a sbuilder setup. 
 https://wiki.debian.org/buildd explicitly says not to expect *any*
 network interface to be available. 

The part about missing a loopback was actually removed from that page years ago
[0]. Not to mention that disabling valuable and working (at least on the Debian
buildds) tests over a matter of policy (and a confusing one at that) seems
silly to me.

All buildds provide at least a loopback interface or hiredis (and many other
packages) would have never been able to build in the past. And pbuilder somehow
screws this up.

 A test-upload to expermental maybe could give some hint if your patch is
 enough?

I don't see how an upload would be useful in this case. hiredis is not failing
to build on the buildds, and a new upload (even without patch) would only
confirm that.

  Also, I feel like the serious severity is overstating the issue
  given that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed
  out the periodic rebuilds would have revealed this issue otherwise.
 
  
  If there are no objections I'd like to propose we adjust the severity
  of this bug to normal  leave the fix for this particular bug until
  after the Jessie freeze.
 
 Here I can reprodcue the FTBFS locally with pbuilder 0.215+nmu3, so
 I disagree. It maybe has not been detected *yet*?

What does this yet even mean? Except inside pbuilder, hiredis builds fine [1].
The fact that it fails *only* inside pbuilder (and the fact that hiredis is not
the only package in this situation) suggests that this is indeed a pbuilder bug.
I really don't see how this is release critical in any way on the part of the
hiredis package.

Cheers

[0] https://wiki.debian.org/buildd?action=diffrev1=11rev2=12
[1] https://buildd.debian.org/status/package.php?p=hiredissuite=unstable


signature.asc
Description: Digital signature

Bug#770648: hiredis: FTBFS: Test failure

[Alessandro Ghedini]

On Sun, Nov 30, 2014 at 07:17:46PM +0100, gregor herrmann wrote:
 On Sun, 30 Nov 2014 17:36:04 +0100, Alessandro Ghedini wrote:
 
  On dom, nov 30, 2014 at 03:06:55 +0100, Tobias Frost wrote:
   Am Sonntag, den 30.11.2014, 00:21 -0800 schrieb Tom Lee:
 
Also, I feel like the serious severity is overstating the issue
given that 0.11.0-4 builds fine in buildd/sbuild. Alessandro pointed
out the periodic rebuilds would have revealed this issue otherwise.
   

If there are no objections I'd like to propose we adjust the severity
of this bug to normal  leave the fix for this particular bug until
after the Jessie freeze.
   
   Here I can reprodcue the FTBFS locally with pbuilder 0.215+nmu3, so
   I disagree. It maybe has not been detected *yet*?
  
  What does this yet even mean? Except inside pbuilder, hiredis builds fine 
  [1].
  The fact that it fails *only* inside pbuilder (and the fact that hiredis is 
  not
  the only package in this situation) suggests that this is indeed a pbuilder 
  bug.
  I really don't see how this is release critical in any way on the part of 
  the
  hiredis package.
 
 While I tend to agree in general, here's an additional data point:
 I rebuilt 0.11.0-4 in my sid amd64 cowbuilder chroot, which has
 USENETWORK=yes (due to #753944) but firewalls off everything except
 localhost during build. And in this environment I see a test failure:

Ok, so I think the whole problem is that /etc/resolv.conf lists non-local name
servers, but the build environment can't actually reach them (because of
USENETWORK=no or the firewall).

This is, I think, the exact same problem as #759799 (which is btw severity:
important). If the consensus is that this should be fixed in the affected
packages (e.g. by disabling the tests), I'm all for it, but I really think that
the effort should go into fixing pbuilder, since who knows how many packages
are actually affected by this.

A simple and stupid solution would be to turn off DNS name lookups completely
inside the build environment if USENETWORK=no (e.g. by fiddling with
/etc/nsswitch.conf), but I'm not sure if that's really applicable to pbuilder.

 Not sure what the best way forward is; adding a test for Temporary
 failure in name resolution might be an option (and works
 unsurprisingly):
 
 #v+
 --- a/test.c  
 +++ b/test.c
 @@ -286,7 +286,8 @@
  c = redisConnect((char*)idontexist.local, 6379);
  test_cond(c-err == REDIS_ERR_OTHER 
  (strcmp(c-errstr,Name or service not known) == 0 ||
 - strcmp(c-errstr,Can't resolve: idontexist.local) == 0));
 + strcmp(c-errstr,Can't resolve: idontexist.local) == 0 ||
 + strcmp(c-errstr,Temporary failure in name resolution) == 0));
  redisFree(c);
  
  /*test(Returns error when the port is not open: );
 #v-
 
 But maybe there are better ways to fix this.

That would make the test kinda useless, but I guess it's no worse than disabling
it completely.

Cheers


signature.asc
Description: Digital signature

Bug#771169: curl: relocation error, missing symbol

[Alessandro Ghedini]

Control: reassign -1 openssl
Control: forcemerge 768476 -1

On gio, nov 27, 2014 at 11:34:30 +0100, Salvo Tomaselli wrote:
 Package: curl
 Version: 7.38.0-3
 Severity: grave
 Justification: renders package unusable
 
 Dear Maintainer,
 
 curl won't start
 
 curl: relocation error: /usr/lib/x86_64-linux-gnu/libcurl.so.4: symbol 
 SSLv3_client_method, version OPENSSL_1.0.0 not defined in file 
 libssl.so.1.0.0 with link time reference

No a curl bug, please install libssl1.0.0 from unstable.

Cheers


signature.asc
Description: Digital signature

Bug#749500: rakudo: not installable in sid

[Alessandro Ghedini]

On ven, ago 29, 2014 at 11:17:18 +0200, Dominique Dumont wrote:
 
 Ack. I'm going to relax the vesrioned dependency on nqp. I don't think that a 
 strict dependency is necessary.

Actually, it is. rakudo needs to use at runtime the specific nqp build used to
build rakudo itself. If you update the nqp package (or just rebuilt it without
any change) without rebuilding rakudo too, rakudo stops working and spews a
bunch of Missing or wrong version of dependency ... errors. Hence the =
dependency to make sure nqp and rakudo migrated to testing at the same time.

You can actually test this by forcibly installing rakudo 2014.07-1 with nqp
2014.07-2 (dpkg -i rakudo_2014.07-1_amd64.deb --force-depends) and then run
perl6.

I don't know if anything changed, but IIRC the upstream developers had no plan
on fixing this (in fact they didn't really consider it a bug at all, although
they agreed it was annoying). One of the many joys of maintaining rakudo :/

I should have probably left a note about this somewhere but I didn't think about
it at the time, sorry about that.

Cheers


signature.asc
Description: Digital signature

Bug#747680: FTBFS: error: redefinition of 'struct Lilv::UI'

[Alessandro Ghedini]

Control: reassing -1 liblilv-dev
Control: retitle -1 liblilv-dev: error: redefinition of 'struct Lilv::UI' in 
C++ header
Control: tags -1 pending
Control: affects -1 ecasound

On dom, mag 11, 2014 at 02:09:28 +0200, Christian Hofstaedtler wrote:
 Source: ecasound
 Version: 2.9.1-4
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Dear Maintainer,
 
 during a rebuild of ruby-related packages, your package failed to build
 with these errors:

Sorry for the delay, I somehow missed the report.

 In file included from audiofx_lv2.h:11:0,
  from eca-object-factory.cpp:51:
 /usr/include/lilv-0/lilv/lilvmm.hpp:173:8: error: redefinition of 'struct 
 Lilv::UI'
  struct UI {
 ^
 /usr/include/lilv-0/lilv/lilvmm.hpp:152:8: error: previous definition of 
 'struct Lilv::UI'
  struct UI {
 ^
 /usr/include/lilv-0/lilv/lilvmm.hpp:190:8: error: redefinition of 'struct 
 Lilv::UIs'
  struct UIs {
 ^
 /usr/include/lilv-0/lilv/lilvmm.hpp:169:8: error: previous definition of 
 'struct Lilv::UIs'
  struct UIs {
 ^
 [..]
 Makefile:1282: recipe for target 'eca-object-factory.lo' failed
 [..]
 debian/rules:16: recipe for target 'override_dh_auto_build' failed
 make[1]: Leaving directory '/«PKGBUILDDIR»'
 make: *** [build] Error 2
 debian/rules:10: recipe for target 'build' failed
 dpkg-buildpackage: error: debian/rules build gave error exit status 2

This looks like a bug in lilv. In the lilvmm.hpp header the structs UI and UIs
are repeated. It seems that a misapplied patch (that should have been removed)
is the cause. I'm working on a fix right now.

Cheers


signature.asc
Description: Digital signature

Bug#746138: perlbrew: FTBFS: Tests failures

[Alessandro Ghedini]

Control: tags -1 confirmed fixed-upstream pending

On dom, apr 27, 2014 at 02:49:41 +0200, David Suárez wrote:
 Source: perlbrew
 Version: 0.66-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20140426 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part (hopefully):
 
  t/installation-perlbrew.t .. ok
  t/installation.t ... ok
  t/installation2.t .. ok
  t/installation3.t .. ok
  t/unit-files-are-the-same.t  ok
  
  Test Summary Report
  ---
  t/command-env.t  (Wstat: 256 Tests: 2 Failed: 1)
Failed test:  2
Non-zero exit status: 1
  Files=44, Tests=384, 16 wallclock secs ( 0.23 usr  0.24 sys +  9.69 cusr  
  6.14 csys = 16.30 CPU)
  Result: FAIL
  Failed 1/44 test programs. 1/384 subtests failed.
  make[1]: *** [test_dynamic] Error 255
  dh_auto_test: make -j1 test returned exit code 2

Here's a more useful snippet:

 #   Failed test 'env command, when invoked with a perl installation name with 
 lib name, displays local::lib-related environment variables that should be 
 set to use the given perl.'
 #   at t/command-env.t line 56.
 # STDOUT is:
 # export PERL5LIB=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita/lib/perl5
 # export PERLBREW_LIB=nobita
 # export 
 PERLBREW_MANPATH=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita/man:/tmp/lU3XUGRbbf/perls/perl-5.14.1/man
 # export 
 PERLBREW_PATH=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita/bin:/tmp/lU3XUGRbbf/bin:/tmp/lU3XUGRbbf/perls/perl-5.14.1/bin
 # export PERLBREW_PERL=perl-5.14.1
 # export PERLBREW_ROOT=/tmp/lU3XUGRbbf
 # export PERLBREW_VERSION=0.66
 # export PERL_LOCAL_LIB_ROOT=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita
 # export PERL_MB_OPT=--install_base 
 /tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita
 # export PERL_MM_OPT=INSTALL_BASE=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita
 # 
 # not:
 # export PERL5LIB=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita/lib/perl5
 # export PERLBREW_LIB=nobita
 # export 
 PERLBREW_MANPATH=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita/man:/tmp/lU3XUGRbbf/perls/perl-5.14.1/man
 # export 
 PERLBREW_PATH=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita/bin:/tmp/lU3XUGRbbf/bin:/tmp/lU3XUGRbbf/perls/perl-5.14.1/bin
 # export PERLBREW_PERL=perl-5.14.1
 # export PERLBREW_ROOT=/tmp/lU3XUGRbbf
 # export PERLBREW_VERSION=0.66
 # export PERL_LOCAL_LIB_ROOT=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita
 # export PERL_MB_OPT=--install_base /tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita
 # export PERL_MM_OPT=INSTALL_BASE=/tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita
 # 
 # as expected
 # Looks like you failed 1 test of 2.
 t/command-env.t  
 Dubious, test returned 1 (wstat 256, 0x100)
 Failed 1/2 subtests 

The offending line seems to be the PERM_MB_OPT one.

Expected:

 # export PERL_MB_OPT=--install_base /tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita

Got:

 # export PERL_MB_OPT=--install_base 
 /tmp/sGeSG_zRYR/libs/perl-5.14.1@nobita

This seems to be fixed in the UNRELEASED version currently sitting in git, so
I'm going to uplaod it.

Cheers


signature.asc
Description: Digital signature

Bug#742728: curl: CVE-2014-0138 CVE-2014-0139

[Alessandro Ghedini]

On mer, mar 26, 2014 at 06:50:41 +0100, Salvatore Bonaccorso wrote:
 Package: curl
 Version: 7.21.0-1
 Severity: grave
 Tags: security upstream fixed-upstream
 
 Hi Alessandro,
 
 For having this referenced also in the Debian BTS, the following
 vulnerabilities were published for curl.
 
 CVE-2014-0138[0]:
 libcurl wrong re-use of connections
 
 CVE-2014-0139[1]:
 libcurl IP address wildcard certificate validation

Here are the (old)stable debdiffs (better late than nothing, I guess... I had
troubles adapting the patches for the older releases :/).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
diff -Nru curl-7.21.0/debian/changelog curl-7.21.0/debian/changelog
--- curl-7.21.0/debian/changelog	2014-01-29 19:17:17.0 +0100
+++ curl-7.21.0/debian/changelog	2014-04-09 19:48:14.0 +0200
@@ -1,3 +1,15 @@
+curl (7.21.0-2.1+squeeze8) squeeze-security; urgency=medium
+
+  * Fix multiple security issues (Closes: #742728):
+- Fix connection re-use when using different log-in credentials
+  as per CVE-2014-0138
+  http://curl.haxx.se/docs/adv_20140326A.html
+- Reject IP address wildcard matches as per CVE-2014-0139
+  http://curl.haxx.se/docs/adv_20140326B.html
+  * Set urgency=high accordingly
+
+ -- Alessandro Ghedini gh...@debian.org  Wed, 09 Apr 2014 19:47:38 +0200
+
 curl (7.21.0-2.1+squeeze7) squeeze-security; urgency=high
 
   * Fix re-use of wrong HTTP NTLM connection as per CVE-2014-0015
diff -Nru curl-7.21.0/debian/patches/CVE-2014-0138.patch curl-7.21.0/debian/patches/CVE-2014-0138.patch
--- curl-7.21.0/debian/patches/CVE-2014-0138.patch	1970-01-01 01:00:00.0 +0100
+++ curl-7.21.0/debian/patches/CVE-2014-0138.patch	2014-04-09 19:48:14.0 +0200
@@ -0,0 +1,58 @@
+Description: Fix connection re-use when using different log-in credentials
+ In addition to FTP, other connection based protocols such as IMAP, POP3,
+ SMTP, SCP, SFTP and LDAP require a new connection when different log-in
+ credentials are specified. Fixed the detection logic to include these
+ other protocols.
+Origin: upstream, http://curl.haxx.se/libcurl-bad-reuse.patch
+Forwarded: not-needed
+Author: Steve Holme steve_ho...@hotmail.com
+Last-Update: 2014-04-09
+
+--- a/lib/http.c
 b/lib/http.c
+@@ -162,7 +162,7 @@
+   ZERO_NULL,/* perform_getsock */
+   ZERO_NULL,/* disconnect */
+   PORT_HTTPS,   /* defport */
+-  PROT_HTTP | PROT_HTTPS | PROT_SSL /* protocol */
++  PROT_HTTP | PROT_HTTPS | PROT_SSL | PROTOPT_CREDSPERREQUEST/* protocol */
+ };
+ #endif
+ 
+--- a/lib/url.c
 b/lib/url.c
+@@ -2986,11 +2986,11 @@
+ continue;
+   }
+ }
+-if((needle-protocol  PROT_FTP) ||
++if((!(needle-protocol  PROTOPT_CREDSPERREQUEST)) ||
+((needle-protocol  PROT_HTTP) 
+ (data-state.authhost.want  CURLAUTH_NTLM))) {
+-  /* This is FTP or HTTP+NTLM, verify that we're using the same name
+- and password as well */
++  /* This protocol requires credentials per connection or is HTTP+NTLM,
++ so verify that we're using the same name and password as well */
+   if(!strequal(needle-user, check-user) ||
+  !strequal(needle-passwd, check-passwd)) {
+ /* one of them was different */
+--- a/lib/urldata.h
 b/lib/urldata.h
+@@ -721,6 +721,8 @@
+ #define PROT_EXTMASK 0xff
+ 
+ #define PROT_SSL (129) /* protocol requires SSL */
++#define PROTOPT_CREDSPERREQUEST (130) /* requires login creditials per request
++   as opposed to per connection */
+ 
+ /* these ones need action before socket close */
+ #define PROT_CLOSEACTION (PROT_FTP | PROT_IMAP | PROT_POP3)
+--- a/tests/data/DISABLED
 b/tests/data/DISABLED
+@@ -2,5 +2,6 @@
+ # test cases are run by runtests.pl. Just add the plain test case numbers, one
+ # per line.
+ # Lines starting with '#' letters are treated as comments.
++519
+ 563
+ 564
diff -Nru curl-7.21.0/debian/patches/CVE-2014-0139.patch curl-7.21.0/debian/patches/CVE-2014-0139.patch
--- curl-7.21.0/debian/patches/CVE-2014-0139.patch	1970-01-01 01:00:00.0 +0100
+++ curl-7.21.0/debian/patches/CVE-2014-0139.patch	2014-04-09 19:48:14.0 +0200
@@ -0,0 +1,40 @@
+Description: Reject IP address wildcard matches
+ There are server certificates used with IP address in the CN field, but
+ we MUST not allow wildcard certs for hostnames given as IP addresses
+ only. Therefore we must make Curl_cert_hostcheck() fail such attempts.
+Origin: upstream, http://curl.haxx.se/libcurl-reject-cert-ip-wildcards.patch
+Forwarded: not-needed
+Author: Daniel Stenberg dan...@haxx.se
+Last-Update: 2014-04-09
+
+--- a/lib/ssluse.c
 b/lib/ssluse.c
+@@ -53,6 +53,7 @@
+ #include select.h
+ #include sslgen.h
+ #include rawstr.h
++#include inet_pton.h
+ 
+ #define _MPRINTF_REPLACE /* use the internal

Bug#742728: curl: CVE-2014-0138 CVE-2014-0139

[Alessandro Ghedini]

On gio, apr 10, 2014 at 12:47:39 +0200, Moritz Muehlenhoff wrote:
 On Thu, Apr 10, 2014 at 12:01:03PM +0200, Alessandro Ghedini wrote:
  On mer, mar 26, 2014 at 06:50:41 +0100, Salvatore Bonaccorso wrote:
   Package: curl
   Version: 7.21.0-1
   Severity: grave
   Tags: security upstream fixed-upstream
   
   Hi Alessandro,
   
   For having this referenced also in the Debian BTS, the following
   vulnerabilities were published for curl.
   
   CVE-2014-0138[0]:
   libcurl wrong re-use of connections
   
   CVE-2014-0139[1]:
   libcurl IP address wildcard certificate validation
  
  Here are the (old)stable debdiffs (better late than nothing, I guess... I 
  had
  troubles adapting the patches for the older releases :/).
 
 If this now passes the test suite, please upload.

Well, it passes the test suite only because the broken test was disabled, but it
can't be helped (the alternative would be enabling the fork() support in the
server used for testing, but that may introduce more breakage). SUSE has done
the same thing (in fact the SUSE maintainer suggested this) and upstream says
it should be safe (in fact, the fact that the disabled test freezes is probably
a good sign, since it means that the patch does what it's supposed to).

Anyway, uploaded.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#743102: [Pkg-haskell-maintainers] Bug#743102: haskell-zeromq3-haskell: FTBFS: Base.hsc:12:2: error: #error *** INVALID 0MQ VERSION (must be 3.x) ***

[Alessandro Ghedini]

On Sun, Mar 30, 2014 at 08:36:13PM +0200, Joachim Breitner wrote:
 Dear Alessandro,
 
 
 Am Sonntag, den 30.03.2014, 18:46 +0200 schrieb David Suárez:
  Source: haskell-zeromq3-haskell
  Version: 0.4-1
  Severity: serious
  Tags: jessie sid
  User: debian...@lists.debian.org
  Usertags: qa-ftbfs-20140329 qa-ftbfs
  Justification: FTBFS on amd64
 
 
 your recent upload of zeromq3 broke the Haskell bindings; the bindings
 expect to be built against zeromq3, but you have uploaded version 4 –
 with a package name with 3 inside?
 
 Is there a reason why this has not become zeromq4? What exactly is the
 relation between the version number and number in the package name?

The source package is called 3 only because I could not rename it to just
zeromq, since that name is still used. The idea being that zeromq should be
removed as soon as nothing uses it anymore, and zeromq3 renamed to zeromq.

As for the 3 in the binary packages (libzmq3, libzmq3-dev, ...), that simply
reflects the library SONAME as per Debian policy. Having a zeromq4 source
package would not have changed anything, since its binary package would still
have to be named libzmq3.

In your case the check should be #if ZMQ_VERSION_MAJOR  3, since 4.x is
backwards-compatible with 3.x.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#741568: lack of symbol versioning and gnutls mismatch results in problem

[Alessandro Ghedini]

On Thu, Mar 13, 2014 at 10:42:23PM -0400, Daniel Kahn Gillmor wrote:
 On 03/13/2014 09:44 PM, Clint Adams wrote:
  On Fri, Mar 14, 2014 at 01:11:16AM +0100, Alessandro Ghedini wrote:
  Well, nope. libgnutls28 still links against libgmp10 which is still LGPL3+.
  Unless I'm missing something that would make git (GPL2only) 
  unredistributable.
  So no, that's not actually possible (again, unless I'm missing something).
  
  As far as I'm concerned, git should change its license irrespective of any
  gmp compromise.
 
 i'd love to see git sort out more sensible licensing too, but libgmp
 *is* actually in the process of a transition to dual-licensed LGPL3+ and
 GPL2+:

As I said in my email, I'm already aware of this, but as long as that hasn't
reached Debian we still have to deal with the problem. You may ask the gmp
maintainer to merge those changes in Debian though. That would help.

 This should suffice for git, afaict.  GMPLib hasn't rolled a release
 that includes this change yet, but they do apparently plan a release in
 early 2014.  I'd love to see gnutls26 just go away in debian when this
 transition happens, but it seems silly to block on it.

Avoid making git unredistributable doesn't sound that silly to me (having
these kind of problems in the first place kind of is though).

There's also the chance that switching to libgnutls28 would break packages that
directly or indirectly depend on libgnutls26 (that is, the inverse of the
libapache2-mod-gnutls problem).

 If libcurl-gnutls really has licensing concerns about moving to
 libgnutls28, and that causing problems for GPLv2 code that links against
 this version of libcurl, one possibility is to introduce
 libcurl4-gnutls28 -- there are already 3 TLS-library flavors of libcur,
 what is one more? :P

That's not going to happen. If anything libgnutls-dev and libgnutls28-dev can't
be installed at the same time, and just because curl's packaging is already a
mess doesn't mean it's ok to make it even more messier.

On the bright side, I was looking into reducing the libcurl flavors to just the
libnss one, but that's not yet possible, as long as #726116 doesn't get fixed.

  Also, I don't see how this is a critical bug in curl. If your concern is
  libapache2-mod-gnutls why not just switch it back to libgnutls26?
  
  That's a question for the libapache2-mod-gnutls maintainer.
 
 GnuTLS 2.12.x (SONAME 26) is not supported by upstream any longer (has
 not been for years) and GnuTLS 3.x (SONAME 28) has significant
 improvements in terms of protocol version and algorithm availability
 (e.g. AES-GCM, the only known cipher mode that resists all known attacks
 is not available in 2.12.x) and useful configuration options (e.g.
 priority string improvements).
 
 There is no good reason i can see for libapache2-mod-gnutls to prefer
 the older version with less robust algorithm availability and weaker
 configuration options.

Well, making it work, i.e. fix #741557, and avoid having it removed from
testing sounds like a pretty good reason to me. Granted, it's really not that
much of a good solution, but it would hopefully be only temporary.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#741568: lack of symbol versioning and gnutls mismatch results in problem

[Alessandro Ghedini]

On gio, mar 13, 2014 at 10:54:10 +, Clint Adams wrote:
 Package: libcurl4-gnutls-dev
 Version: 7.35.0-1
 Severity: critical
 Control: block 741557 by -1
 
 On Thu, Mar 13, 2014 at 06:25:14PM -0400, Daniel Kahn Gillmor wrote:
  I agree with the suggestion that libcurl3-gnutls (or libcurl4-gnutls?
  that's the stated build-dep for libmsv) should switch to
  libgnutls28-dev.  perhaps that's worth making a separate bug report.

Well, nope. libgnutls28 still links against libgmp10 which is still LGPL3+.
Unless I'm missing something that would make git (GPL2only) unredistributable.
So no, that's not actually possible (again, unless I'm missing something).

Now, I've got tired of the debian-devel discussion on the subject pretty early
so I haven't followed it till the end, but I was told that gmp upstream has
changed the license to LGPL3+ || GPL2 or something like that. But AFAICT that
has not yet gotten into Debian.

Also, I don't see how this is a critical bug in curl. If your concern is
libapache2-mod-gnutls why not just switch it back to libgnutls26?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#736616: Bug#637757: libaudio-ecasound-perl: FTBFS on mips

[Alessandro Ghedini]

On lun, gen 27, 2014 at 08:48:10 +0200, Damyan Ivanov wrote:
 -=| Alessandro Ghedini, 26.01.2014 13:51:58 +0100 |=-
   The trace ends with:
   
   -8--
   [...]
   -8--
  
  This unfortunately doesn't seem to be very helpful since it doesn't show the
  error (which actually happens in the middle of the clock_gettime()s). In any
  case I don't think it would add much anyway.
 
 I attach the trace (compressed) just in case.

Turns out that the trace was, in fact, quite useful, it's just that I missed the
most important part:

 9068  ... poll resumed )  = 0 (Timeout)

So, yeah, I have a patch that seems to work and I'm now waiting for upstream's
comments on it.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#736616: Bug#637757: libaudio-ecasound-perl: FTBFS on mips

[Alessandro Ghedini]

On Sat, Jan 25, 2014 at 05:55:29PM +0200, Damyan Ivanov wrote:
 Control: clone -1 -2
 Control: reassign -2 libecasoundc1/2.9.1-1
 Control: retitle -2 libecasoundc1: int-cmd-list command fails on mips
 Control: block -1 by -2
 
 Dear ecasound maintainers,
 
 It appears there is a problem with ecasound/libecasoundc1 on mips, 
 which causes failures in the test suite of libaudio-ecasound-perl, 
 making it FTBFS.
 
 I was able to isolate the problem using the following C program:

The problem seems to be that eci_init() fails, so a better test case would be:

#include stdio.h

#include libecasoundc/ecasoundc.h

int main(int argc, char *argv[]) {
eci_init();

if (eci_ready() == 0) {
puts(fail);
return 1;
}

return 0;
}

 The trace ends with:
 
 -8--
 [...]
 -8--

This unfortunately doesn't seem to be very helpful since it doesn't show the
error (which actually happens in the middle of the clock_gettime()s). In any
case I don't think it would add much anyway.

Anyway, the problem seems to be in the eci_impl_read_return_value() function,
called by eci_init_r(). In particular, the last check fails, but I'm not quite
sure what it's supposed to test. I'll forward this upstream.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#734521: pyzmq: FTBFS for s390x: test_timeout AssertionError

[Alessandro Ghedini]

On mar, gen 07, 2014 at 09:10:35 +0100, Julian Taylor wrote:
 On 07.01.2014 21:02, Aaron M. Ucko wrote:
  Source: pyzmq
  Version: 14.0.1-1
  Severity: serious
  Justification: fails to build from source (but built successfully in the 
  past)
  
  The s390x build of pyzmq failed with an AssertionError when trying to
  run the unit test under Python 2.7:
  
Traceback (most recent call last):
  File zmq/tests/test_poll.py, line 176, in test_timeout
self.assertTrue(toc-tic  0.1)
AssertionError: False is not true
  
  Could you please take a look?  You can find the full log at
  https://buildd.debian.org/status/fetch.php?pkg=pyzmqarch=s390xver=14.0.1-1stamp=1389093313
  
  Thanks!
  
 
 caused by a minimum polling timeout of 0.5 seconds due to a bug in
 zeromqs timing src/clock.cpp:123  zmq::clock_t::rdtsc()
 
 still investigating a fix.

Looking at the code:

 #elif defined(__s390__)
 uint64_t tsc;
 asm(\tstck\t%0\n : =Q (tsc) : : cc);
 tsc = 12;   /* convert to microseconds just to be 
 consistent */
 return(tsc);

Maybe the check needs to be #elif defined(__s390__) || defined(__s390__)? If
that's the case, feel free to reassign to libzmq3.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#733632: mpv: FTBFS on mips/mipsel/powerpc/sparc: undefined reference to `__sync_add_and_fetch_8'

[Alessandro Ghedini]

On lun, dic 30, 2013 at 03:22:38 +0100, Aurelien Jarno wrote:
 Package: mpv
 Version: 0.3.0-1
 Severity: serious
 Tags: upstream patch
 Justification: fails to build from source (but built successfully in the past)
 
 mpv fails to build from source on mips/mipsel/powerpc/sparc with the
 following error message:
 
 | [243/243] linking - build/mpv
 | common/msg.c.10.o: In function `mp_msg_update_msglevels':
 | /«PKGBUILDDIR»/build/../common/msg.c:243: undefined reference to 
 `__sync_add_and_fetch_8'
 | collect2: error: ld returned 1 exit status
 | Waf: Leaving directory `/«PKGBUILDDIR»/build'
 | Build failed

Yeah, I'm already working on a patch (which would use __atomic built-ins
directly) with upstream.

 --- mpv-0.3.0/debian/control
 +++ mpv-0.3.0/debian/control
 @@ -45,7 +45,8 @@
   pkg-config,
   python,
   python-docutils,
 - yasm
 + yasm,
 + gcc-4.8

I'd rather build-depends on gcc-4.8 (and use it directly) only where it's
needed ([powerpc, sparc]), since e.g. ia64 (and all the other *64) will work
just fine with the default 4.6.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#728757: valgrind: Valgrind won't start, complains about being unable to set up function redirection

[Alessandro Ghedini]

Control: severity -1 normal

On mar, nov 05, 2013 at 09:08:30 +0100, Peter Allin wrote:
 Package: valgrind
 Version: 1:3.7.0-6
 Severity: grave
 Justification: renders package unusable
 
 Dear Maintainer,
 
 When I try to run Valgrind it refuses to run, and exits with an error
 message about being unable to redirect a function.
 
 [...]
 
 I do have the libc6-dbg package installed:
 
  dpkg -l |  grep libc6
 [...]
 ii  libc6-amd64

This seems to be the culprit. valgrind seems to get confused by the loader
installed by that package.

I can't think of any reason as to why, on a multi-arched amd64 system, you'd
want to install the libc6-amd64:i386 package along with libc6:amd64 though, and
to be honest I'm not even sure this actually qualifies as valgrind bug.

Also, trying to remove that package I somehow fucked up the chroot I was working
on, so be careful if you want to get rid of it.

 I am reporting this as grave given that it renders the package unusable,
 and I have can't think of anything that makes my rather fresh installation
 unique in any way.

I downgraded it to normal as it only affects your particular setup.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#720409: valgrind: FTBFS on armel (SIGILL)

[Alessandro Ghedini]

Control: tags -1 pending

On Wed, Aug 21, 2013 at 03:36:25PM +0200, Julien Cristau wrote:
 Source: valgrind
 Version: 1:3.8.1-4
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Hi,
 
 Debian's armel port targets armv5.  valgrind uses -march=armv7-a, which
 breaks on older arm hosts:
 https://buildd.debian.org/status/fetch.php?pkg=valgrindarch=armelver=1%3A3.8.1-4%2Bb1stamp=1377079753

To wrap things up, I'm gonna disable valgrind's armel build soon (also see [0]).

Cheers

[0] http://lists.debian.org/debian-arm/2013/10/msg00077.html

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#724336: [Pkg-parrot-devel] Bug#724336: parrot: FTBFS: step auto::icu failed: no result returned at Configure.pl line 97.

[Alessandro Ghedini]

Control: tags -1 confirmed upstream patch

On lun, set 23, 2013 at 11:03:35 +0300, Damyan Ivanov wrote:
 Package: src:parrot
 Version: 5.0.0-1
 Severity: serious
 Justification: FTBFS
 
 Parrot fails to build in a current sid pbuilder chroot on amd64:
 
 During configuration the following steps failed:
 53:  auto::icu
 You should diagnose and fix these errors before calling 'make'
 make: *** [configure-stamp] Error 1
 dpkg-buildpackage: error: debian/rules build gave error exit status 2

Seems to be caused by the parrot's build system that can't handle multi-arch
include paths.

I prepared a patch (see attached) which seems to fix the problem... but it's
kinda ugly. Allison, can you please have a look at it?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
From 4dd2897db56197b2287af1f7395c1823e39cbf4c Mon Sep 17 00:00:00 2001
From: Alessandro Ghedini alessan...@ghedini.me
Date: Tue, 24 Sep 2013 11:17:56 +0200
Subject: [PATCH] Fix ICU headers autodetect

Closes: #724336
---
 debian/patches/04_fix_icu_autodetect.patch | 44 ++
 debian/patches/series  |  1 +
 debian/rules   |  3 ++
 3 files changed, 48 insertions(+)
 create mode 100644 debian/patches/04_fix_icu_autodetect.patch

diff --git a/debian/patches/04_fix_icu_autodetect.patch b/debian/patches/04_fix_icu_autodetect.patch
new file mode 100644
index 000..c64ee6e
--- /dev/null
+++ b/debian/patches/04_fix_icu_autodetect.patch
@@ -0,0 +1,44 @@
+Description: Force ICU autodetect even if 'icuheaders' is set
+Origin: vendor
+Bug-Debian: http://bugs.debian.org/724336
+Forwarded: not-needed
+Author: Alessandro Ghedini gh...@debian.org
+Last-Update: 2013-09-24
+
+--- a/config/auto/icu.pm
 b/config/auto/icu.pm
+@@ -94,9 +94,7 @@
+ return 1;
+ }
+ 
+-my $autodetect  =   ( ! defined($icushared)  )
+-
+-( ! defined($icuheaders) );
++my $autodetect  =   ( ! defined($icushared)  );
+ 
+ my $without = 0;
+ ($icuconfig, $autodetect, $without) = $self-_handle_autodetect(
+@@ -288,12 +286,17 @@
+ $conf-debug(For icushared, found $icushared and $arg-{without}\n);
+ 
+ # location of header files
+-$conf-debug(Trying $arg-{icuconfig} with '--prefix'\n);
+-$icuheaders = capture_output($arg-{icuconfig} --prefix);
+-chomp($icuheaders);
+-$conf-debug(icuheaders:  captured $icuheaders\n);
+-($icuheaders, $arg-{without}) =
+-$self-_handle_icuheaders($conf, $icuheaders, $arg-{without});
++if ( ! $icuheaders ) {
++$conf-debug(Trying $arg-{icuconfig} with '--prefix'\n);
++$icuheaders = capture_output($arg-{icuconfig} --prefix);
++chomp($icuheaders);
++$conf-debug(icuheaders:  captured $icuheaders\n);
++($icuheaders, $arg-{without}) =
++$self-_handle_icuheaders($conf, $icuheaders, $arg-{without});
++} else {
++($icuheaders, $arg-{without}) = ($icuheaders, 0);
++}
++
+ $conf-debug(For icuheaders, found $icuheaders and $arg-{without}\n);
+ }
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8ba7038..7d904e6 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 02_fix_perl_interpreter_path.patch
 03_fix_nqp_man.patch
+04_fix_icu_autodetect.patch
diff --git a/debian/rules b/debian/rules
index df71ebc..b7bf939 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,8 @@ LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
 VERSION = $(shell cat VERSION)
 SOVERSION = $(VERSION)
 
+DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+
 CONTROL_FILES = \
   debian/control.in \
   debian/parrot.install.in \
@@ -29,6 +31,7 @@ configure-stamp: debian-control-stamp $(QUILT_STAMPFN)
 	dh_testdir
 	perl Configure.pl --ccflags=$(CFLAGS) --ldflags=$(LDFLAGS)	\
 		--prefix=/usr --mandir=/usr/share/man --disable-rpath	\
+		--icuheaders=/usr/include/$(DEB_HOST_MULTIARCH)		\
 		--without-libffi --without-gmp --without-opengl		\
 		--without-pcre --without-zlib
 	touch configure-stamp
-- 
1.8.4.rc3



signature.asc
Description: Digital signature

Bug#720409: Carrying valgrind for armel not neccesary anymore

[Alessandro Ghedini]

On gio, ago 22, 2013 at 11:08:47 +0300, Riku Voipio wrote:
 Hi,

Hi,

sorry for the delay.

 With multiarch it should be be possible to install armhf version of
 valgrind on armel systems with ARMv7. I don't think keeping armel
 version of valgrind is strictly neccesary anymore.

Is this actually possible? I mean, doesn't the hf (hard float) part in armhf
make armhf packages incompatible with armel hardware (even if ARMv7 and using
multiarch)?

In any case I'm not against removing valgrind from armel, if it's of any help
for the openmpi transition.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#720409: valgrind: FTBFS on armel (SIGILL)

[Alessandro Ghedini]

On Wed, Aug 21, 2013 at 03:36:25PM +0200, Julien Cristau wrote:
 Source: valgrind
 Version: 1:3.8.1-4
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)
 
 Hi,
 
 Debian's armel port targets armv5.  valgrind uses -march=armv7-a, which
 breaks on older arm hosts:

Altough it does use -march=armv7-a, valgrind is supposed to be built in
cross-compiling mode (with ./configure --host=...) for exactly that reason. In
fact it built with no problems on ancina in the past (e.g. version 1:3.8.1-4)
and I can't reproduce the failure on the porterboxes.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#709817: libavcodec54: uninstallable due to Depends on libx264-129

[Alessandro Ghedini]

Package: libavcodec54
Version: 6:9.6-1
Severity: grave
Justification: renders package unusable

Hi,

when trying to install libavcodec54 from experimental:

 The following packages have unmet dependencies:
  libavcodec54 : Depends: libx264-129 which is a virtual package.

This causes e.g. mplayer2 from experimental to FTBFS.

Cheers

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.8-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#704841: FTBFS on kfreebsd-xxx, s390 and s390x

[Alessandro Ghedini]

severity 704841 important
severity 704842 important
kthxbye

On sab, apr 06, 2013 at 06:47:26 +0200, Picca Frédéric-Emmanuel wrote:
 Package: zeromq3
 Severity: serious
 
 Hello, it seems that zeromq3 failt to build due to the test suite.

Hi,

I just uploaded a new version that makes these failures non-fatal, since they
don't really affect the usability of zeromq3 (e.g. the kfreebsd failures are
probably caused by the buildd choking with too many threads).

I'm downgrading the severity of the bugs to important, until I find a nicer way
of fixing them.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#707438: valgrind: FTBFS: x86_64-linux-gnu-gcc: error: unrecognized command line option '-V'

[Alessandro Ghedini]

tags 707438 pending
kthxbye

On gio, mag 09, 2013 at 10:18:58 +0200, Lucas Nussbaum wrote:
 Source: valgrind
 Version: 1:3.8.1-2
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20130509 qa-ftbfs
 Justification: FTBFS on amd64
 
 Hi,
 
 During a rebuild of all packages in sid, your package failed to build on
 amd64.

Fixed in git just now.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#705274: curl: CVE-2013-1944: libcurl cookie domain tailmatch

[Alessandro Ghedini]

On sab, apr 13, 2013 at 11:17:06 +0200, Salvatore Bonaccorso wrote:
 Hi
 
 In case somebody wondered why this was not uploaded as recommended by
 the dev-ref for NMU to a delayed queue: Alessandro asked if somone
 else can handle the uploads for CVE-213-1944.

Hi Salvatore,

thank you very much for handling this in my absence.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#700002: curl: CVE-2013-0249

[Alessandro Ghedini]

tags 72 patch
kthxbye

On Thu, Feb 7, 2013 at 9:33 AM, Moritz Muehlenhoff j...@inutil.org wrote:
 Package: curl
 Severity: grave
 Tags: security
 Justification: user security hole

 http://curl.haxx.se/docs/adv_20130206.html

 Remember we're in freeze, so please upload only the minimal security fix.

The patch is available at http://curl.haxx.se/curl-sasl.patch

I'll be able to prepare the uploads only on saturday evening/sunday, so if you
want to do an NMU for wheezy earlier than that please go ahead.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#696681: falconpl: possible security issue due to misuse of the libcurl API

[Alessandro Ghedini]

Package: falconpl
Severity: serious
Tags: security

Hi,

I recently discovered that falconpl is using the libcurl API in a way that may
not be what the original author intended. In particular I'm referring to the
fact that the CURLOPT_SSL_VERIFYHOST option is treated as it was a boolean value
while in fact it isn't (it may take three different values):

  case CURLOPT_SSL_VERIFYHOST:
  case CURLOPT_SSL_SESSIONID_CACHE:
   {
 long bVal = i_data-isTrue() ? 1 : 0;
 ret = curl_easy_setopt( curl, iOpt, bVal );
   }
   break;

(from the file modules/native/curl/src/curl_ext.cpp)

Setting the value to 0 disables the host checks, but setting it to 1 does
not enable them (well, not all of them) and this may lead to security issues.
The correct value to enable all the security checks is 2.

From the libcurl documentation:

 When CURLOPT_SSL_VERIFYHOST is 2, that certificate must indicate that the
 server is the server to which you meant to connect, or the connection fails.
 
 Curl considers the server the intended one when the Common Name field or a
 Subject Alternate Name field in the certificate matches the host name in the
 URL to which you told Curl to connect.
 
 When the value is 1, the certificate must contain a Common Name field, but it
 doesn't matter what name it says. (This is not ordinarily a useful setting).
 
 When the value is 0, the connection succeeds regardless of the names in the
 certificate.

After discussing this with the security team, it was decided that it would be
best if this was fixed before the Wheezy release.

Note that this should be fixed anyway, since as of curl v7.28.1 (which has been
uploaded to experimental) the value 1 is not a valid value anymore and libcurl
will return an error.

A possible fix should be discussed with the falconpl upstream first.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#694999: cityhash: CVE-2012-6051

[Alessandro Ghedini]

On Tue, Dec 04, 2012 at 10:45:45PM +0100, Moritz Muehlenhoff wrote:
 On Mon, Dec 03, 2012 at 12:00:18PM +0100, Alessandro Ghedini wrote:
  I opened a ticket upstream but it doesn't appear to be fixed. It's not 
  clear if
  Debian is affected though: the CVE was published 6 days after the 1.1.0 
  release
  which partially reworked the hashing algorithms, but Debian currently has 
  only
  the one-year-old 1.0.3 version (the sid version was reverted to 1.0.3
  yesterday), which may not be affected.
  
  Though, if 1.0.3 is affected and if 1.1.0 is the fix (or if the fix is 
  based on
  it) I don't think it would be suitable for a wheezy upload, since the 
  reworked
  algorithms are not retrocompatible (see #694916).
 
 Given that there are no rdeps in Wheezy and cityhash hasn't been part of a 
 release it would make more sense to start with the reworked 1.1.0 version?
 Even if it's late in the freeze.

I'd be ok with a removal from wheezy too. Still no news from upstream though.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#675895: [Pkg-parrot-devel] Bug#675895: parrot: FTBFS in sid: (.text+0x20): undefined reference to `main'

[Alessandro Ghedini]

On Wed, Dec 05, 2012 at 03:13:16PM +0100, Salvatore Bonaccorso wrote:
 Control: reassign 675895 icu 4.8.1.1-7
 Control: fixed 675895 4.8.1.1-8
 Control: affects 675895 + parrot
 
 Hi Alessandro and Jay
 
 On Tue, Jun 05, 2012 at 02:22:07PM -0400, Jay Berkenbilt wrote:
  Alessandro Ghedini al3x...@gmail.com wrote:
  
   Apparently it's icu-config --ldlfags (called by Parrot's build system) 
   who
   brings in the PIE options (along with all the other hardening build 
   flags).
   Using --ldflags-libsonly should do (I'm working on it).
  
   The fact that icu-config passes all those build flags doesn't sound quite 
   right
   though and may cause other packages to FTBFS. Jay, what do you think?
  
  Yes, this is a bug in ICU.  I'll switch it back to using
  hardening-wrapper.  This came in when I changed from that to
  dpkg-buildoptions.  There are odd things with icu's build system
 
 I was going trough the list in [1], so the bugs 'affecting wheezy, but not
 sid'. With the above I tried to reassign and marking correct version
 so that this should not show up.

Thanks.

 I have builded the current version in wheezy (4.0.0-3) both in wheezy
 and unstable (which both have icu 4.8.1.1-10.

Yeah, I had marked it as fixed in icu/4.8.1.1-8 without reassigning, but it
seems that it doesn't work like that.

 But it looks there is another FTBFS on ia64[2].

Yup, that's #689177, which is sid-only.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#694999: cityhash: CVE-2012-6051

[Alessandro Ghedini]

forwarded 694999 http://code.google.com/p/cityhash/issues/detail?id=10
kthxbye

On Mon, Dec 03, 2012 at 08:22:47AM +0100, Moritz Muehlenhoff wrote:
 Package: cityhash
 Severity: grave
 Tags: security
 Justification: user security hole
 
 Hi,

Hi,

 please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-6051
 
 I'm not sure if/when this was fixed upstream, so better contact upstream.

I opened a ticket upstream but it doesn't appear to be fixed. It's not clear if
Debian is affected though: the CVE was published 6 days after the 1.1.0 release
which partially reworked the hashing algorithms, but Debian currently has only
the one-year-old 1.0.3 version (the sid version was reverted to 1.0.3
yesterday), which may not be affected.

Though, if 1.0.3 is affected and if 1.1.0 is the fix (or if the fix is based on
it) I don't think it would be suitable for a wheezy upload, since the reworked
algorithms are not retrocompatible (see #694916).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#694999: cityhash: CVE-2012-6051

[Alessandro Ghedini]

On Mon, Dec 03, 2012 at 12:00:18PM +0100, Alessandro Ghedini wrote:
 On Mon, Dec 03, 2012 at 08:22:47AM +0100, Moritz Muehlenhoff wrote:
  I'm not sure if/when this was fixed upstream, so better contact upstream.
 
 the CVE was published 6 days after the 1.1.0 release

After 6 days... and a month.

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#694916: libcityhash0: incompatible algorithm must bump shlib

[Alessandro Ghedini]

On dom, dic 02, 2012 at 01:04:47 -0800, Chip Salzenberg wrote:
 CityHash 1.1 is not the same algorithm as 1.0!  Upgrading from 1.0.3 to 1.1
 breaks any code that uses it.
 
 I think cityhash11 and cityhash103 should be separate binary packages
 entirely.
 
 At the very least, the shlib version must be bumped, so if you build 1.1 you
 make libcityhash1.  There may be some neat symbol versioning thing you can
 do too, but I'll not speculate.

Changing SONAME or doing symbols versioning is upstream's responsibility and
I'd prefer to not do any of them specifically for Debian.

I'll contact upstream to discuss this problem, but for now I'm going to revert
the Debian package to the 1.0.3 upstream release. Sorry for the inconvenience.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#689177: parrot: ftbfs on ia64

[Alessandro Ghedini]

On dom, nov 11, 2012 at 11:50:26 +0100, intrigeri wrote:
 Did this happen?

I don't think so. Though, given the new failures in 4.6.0-1, I wanted to try to
get some more information about it from the porterbox and try what happens with
the new upstream version before contacting the ia64 people. But I've been quite
busy lately and hadn't got the chance to do it yet (also being it in unstable
only during the freeze it does not have a very high priority right now).

 As far as can see, parrot is currently RC-buggy in testing (#675895)

AFAICT that bug shouldn't apply anymore since icu has been fixed in 4.8.1.1-8
to not pass hardening flags. In fact I cannot reproduce the FTBFS on a wheezy
chroot. I think it can be set as fixed by icu/4.8.1.1-8.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#689177: wrong bug -.-

[Alessandro Ghedini]

notfixed 689177 icu/4.8.1.1-8
kthxbye

Wrong bug number, sorry for the noise.


signature.asc
Description: Digital signature

Bug#689177: parrot: ftbfs on ia64

[Alessandro Ghedini]

On 09/29, Jonathan Duke Leto wrote:
 Howdy Julien,
 
 Thanks for the bug report! We have seen something like this from the
 debian build machines before, but previous reporters could not
 reproduce it when compiling by hand. It seems to only happen on ia64
 and looks like some kind of memory corruption.
 
 Is this an intermittent occurrence, or can you reproduce this reliably?

With parrot 4.6.0 the failure now looks like this:

 ./parrot-nqp --target=pir 
 --output=compilers/opsc/gen/Ops/Compiler/Actions.pir 
 compilers/opsc/src/Ops/Compiler/Actions.pm
 make[1]: *** [compilers/opsc/gen/Ops/Compiler/Actions.pir] Segmentation fault
 make[1]: Leaving directory 
 `/build/buildd-parrot_4.6.0-1-ia64-ezTxz0/parrot-4.6.0'
 make: *** [build-arch-stamp] Error 2

Which happens just a couple of commands before the original failure.

Also, this failure happens quite randomly when using parrot-nqp. I tried to
build parrot 2 times on the Debian's ia64 porterbox, the first time segfaulted
with:

 ./parrot-nqp --target=pir 
 --output=compilers/opsc/gen/Ops/Compiler/Grammar.pir 
 compilers/opsc/src/Ops/Compiler/Grammar.pm
 make[1]: *** [compilers/opsc/gen/Ops/Compiler/Grammar.pir] Segmentation fault
 make[1]: Leaving directory `/home/ghedo/parrot-4.6.0'
 make: *** [build-arch-stamp] Error 2

the second time with:

 ./parrot-nqp --target=pir runtime/parrot/library/YAML/Tiny.pm  
 runtime/parrot/library/YAML/Tiny.pir
 Segmentation fault
 make[1]: *** [runtime/parrot/library/YAML/Tiny.pir] Error 139
 make[1]: Leaving directory `/home/ghedo/parrot-4.6.0'
 make: *** [build-arch-stamp] Error 2

I still can't reproduce the original failure.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#639565:

[Alessandro Ghedini]

On Mon, Sep 17, 2012 at 05:30:44PM +0200, gregor herrmann wrote:
 On Sun, 16 Sep 2012 20:19:56 +0200, Alessandro Ghedini wrote:
 
 Ciao Alessandro,
 
 thanks alot for taking the time to shed some light here!

No problem

   Directly depending on libcurl3* packages is of no use: either the 
   application
   links to a libcurl flavour, in which case it would already Depends on a 
   suitable
   libcurl3 package, or it doesn't and it wouldn't pick up the library even 
   if
   installed 
 
 Makes sense ... But liboauth does link (and therefore depend on) one
 of the curl libs, unless forced to do otherwise.

My comment was about the do not build-depends on libcurl4*-dev and manually
depend on a libcurl3* solution exposed above, which wouldn't work.

 What I've done now, since I'm more interested in #650138 actually :)

I think I see the problem: the NSS libcurl flavour needs a proper NSS
certificate database (just like any other application using NSS, e.g. chromium
and firefox generate their own databases), otherwise the SSL/TLS support is
mostly broken (i.e. the certificate checks always fail, see #655628).

Now I'm not really into OAuth nor Twitter-like things, but I guess that Twitter
and Identi.ca provide an HTTPS end-point for their OAuth APIs... HTTPS requires
SSL/TLS certificate checking by default... I guess you see where this is going.

I think liboauth use of NSS does not involve certificate checking but libcurl's,
unless otherwise told, does. But they are independent.

From liboauth 0.9.4-3 changelog:

  * Sync from Ubuntu:
 [ Mathieu Trudel-Lapierre ]
   * debian/control: liboauth-dev really needs libcurl4-nss-dev, not
 libcurl4-gnutls-dev (nss is required in the .pc file)
 (closes: #646485, #639565)
   [ Sjoerd Simons ]
   * collab-main team update
   * debian/control: Swith build-depend to libcurl4-nss-dev from
 libcurl4-gnutls-dev. oauth itself uses nss for SSL

That probably explains why liboauth and in turn bti stopped working from that
version.

So, to recap, IMO liboauth and bti (well, I'm not really sure about bti... but
that doesn't hurt) should build-depend on libcurl4-gnutls-dev, which would fix
#650138, and liboauth-dev should depend on libcurl4-gnutls-dev | libcurl4-dev,
which would fix #639565 (as exposed in the submission email).

libcurl3* runtime independence is not possible unless leaving libcurl's symbols
unresolved (as explained a few emails ago). But I don't quite see why one would
want the independence in the first place. To quote Tsukasa Hamano: The depends
is force developper to link with gnutls, I'm not quite sure what he meant, but
the developer (using liboauth) is not forced to link againt anything, liboauth
is, but it doesn't affect the developer using it. And when using a static 
liboauth
(i.e. what the Requires.private in oauth.pc and the liboauth-dev Depends are
for) one can choose any libcurl. If really needed, one can rebuild liboauth from
source, in which case libcurl4-gnutls-dev | libcurl4-dev in its build-depend
would help.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#639565:

[Alessandro Ghedini]

On Mon, Sep 17, 2012 at 07:49:43PM +0200, gregor herrmann wrote:
  From liboauth 0.9.4-3 changelog:
  
* Sync from Ubuntu:
   [ Mathieu Trudel-Lapierre ]
 * debian/control: liboauth-dev really needs libcurl4-nss-dev, not
   libcurl4-gnutls-dev (nss is required in the .pc file)
   (closes: #646485, #639565)
 [ Sjoerd Simons ]
 * collab-main team update
 * debian/control: Swith build-depend to libcurl4-nss-dev from
   libcurl4-gnutls-dev. oauth itself uses nss for SSL
  
  That probably explains why liboauth and in turn bti stopped working from 
  that
  version.
 
 So this should be libcurl4-*-dev (and not -nss-) for the HTTPS
 communication, and libnss3-dev for the OAuth hash things, right? (And
 the fix for #646485 would have been to just add libnss3-dev, and not
 to switch the curl flavour.)

Yep. Note that -openssl- is not really a good choice either because of the
possible OpenSSL licensing issues, which makes -gnutls- pretty much the only
choice.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#639565:

[Alessandro Ghedini]

On Sun, Sep 16, 2012 at 04:17:36PM +0200, gregor herrmann wrote:
 When I extend the patch I indeed get the expected Depends for
 liboauth0 [0]. But also:
 
 dpkg-shlibdeps: warning: symbol curl_slist_free_all used by 
 debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none of 
 the libraries
 dpkg-shlibdeps: warning: symbol curl_slist_append used by 
 debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none of 
 the libraries
 dpkg-shlibdeps: warning: symbol curl_easy_cleanup used by 
 debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none of 
 the libraries
 dpkg-shlibdeps: warning: symbol curl_easy_init used by 
 debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none of 
 the libraries
 dpkg-shlibdeps: warning: symbol curl_easy_setopt used by 
 debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none of 
 the libraries
 dpkg-shlibdeps: warning: symbol curl_easy_perform used by 
 debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none of 
 the libraries
 
 So not linking to any curl lib doesn't look right ...

That could be done, as long as all the applications linking directly or
indirectly to liboauth link to a suitable libcurl too (i.e. leaving all the
libcurl symbols unresolved in liboauth). AFAICT this is currently not enforced
since e.g. oauth.pc only lists libcurl as Requires.private.

Directly depending on libcurl3* packages is of no use: either the application
links to a libcurl flavour, in which case it would already Depends on a suitable
libcurl3 package, or it doesn't and it wouldn't pick up the library even if
installed (unless forcibly loaded e.g. via LD_LOAD_LIBRARY, but that's not a
real solution).

Also note that libcurl3* libraries are not interchangeable, since they have
different SONAMEs and symbols versioning (i.e. once you link against one of
them at compile time, you have to use the same to resolve libcurl symbols at
load time).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#639565:

[Alessandro Ghedini]

On Sun, Sep 16, 2012 at 07:41:57PM +0200, Alessandro Ghedini wrote:
 On Sun, Sep 16, 2012 at 04:17:36PM +0200, gregor herrmann wrote:
  When I extend the patch I indeed get the expected Depends for
  liboauth0 [0]. But also:
  
  dpkg-shlibdeps: warning: symbol curl_slist_free_all used by 
  debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none 
  of the libraries
  dpkg-shlibdeps: warning: symbol curl_slist_append used by 
  debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none 
  of the libraries
  dpkg-shlibdeps: warning: symbol curl_easy_cleanup used by 
  debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none 
  of the libraries
  dpkg-shlibdeps: warning: symbol curl_easy_init used by 
  debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none 
  of the libraries
  dpkg-shlibdeps: warning: symbol curl_easy_setopt used by 
  debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none 
  of the libraries
  dpkg-shlibdeps: warning: symbol curl_easy_perform used by 
  debian/liboauth0/usr/lib/x86_64-linux-gnu/liboauth.so.0.8.1 found in none 
  of the libraries
  
  So not linking to any curl lib doesn't look right ...
 
 That could be done, as long as all the applications linking directly or
 indirectly to liboauth link to a suitable libcurl too (i.e. leaving all the
 libcurl symbols unresolved in liboauth). AFAICT this is currently not enforced
 since e.g. oauth.pc only lists libcurl as Requires.private.
 
 Directly depending on libcurl3* packages is of no use: either the application
 links to a libcurl flavour, in which case it would already Depends on a 
 suitable
 libcurl3 package, or it doesn't and it wouldn't pick up the library even if
 installed (unless forcibly loaded e.g. via LD_LOAD_LIBRARY, but that's not a
 real solution).
 
 Also note that libcurl3* libraries are not interchangeable, since they have
 different SONAMEs and symbols versioning (i.e. once you link against one of
 them at compile time, you have to use the same to resolve libcurl symbols at
 load time).

To wrap this up: having Depends: ..., libcurl4-gnutls-dev | libcurl4-dev, ...
in liboauth-dev IMO is the simplest and most effective solution to the problem
exposed (libcurl4*-dev conflicts).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#672657: Not suitable for weezy

[Alessandro Ghedini]

On Wed, Jul 04, 2012 at 09:40:51PM +0200, Julien Cristau wrote:
 On Wed, Jul  4, 2012 at 10:58:30 +0200, Alessandro Ghedini wrote:
 
  On Sat, May 12, 2012 at 07:26:17PM +0200, Enrico Tassi wrote:
   Package: luajit
   Version: 2.0.0~beta9+dfsg-2
   Severity: grave
   Tags: upstream
   
   In accordance with the upstream, luajit will not be part of weezy, but 
   rather
   be made available via backports.
  
  Sooo, how is ulatencyd affected? It just lists libluajit-5.1-dev as an
  alternative build dependency of liblua5.1-0-dev (to let people rebuild the
  packages with luajit support without problems) but does not actually use 
  it. I
  don't see this as a problem, am I wrong?
  
 No, that looks fine.

Ok, closing (the correct bug) then.

Thanks

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#672657: Not suitable for weezy

[Alessandro Ghedini]

On Sat, May 12, 2012 at 07:26:17PM +0200, Enrico Tassi wrote:
 Package: luajit
 Version: 2.0.0~beta9+dfsg-2
 Severity: grave
 Tags: upstream
 
 In accordance with the upstream, luajit will not be part of weezy, but rather
 be made available via backports.

Sooo, how is ulatencyd affected? It just lists libluajit-5.1-dev as an
alternative build dependency of liblua5.1-0-dev (to let people rebuild the
packages with luajit support without problems) but does not actually use it. I
don't see this as a problem, am I wrong?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#679447: libcoro-perl often segfaults

[Alessandro Ghedini]

On Fri, Jun 29, 2012 at 06:31:52AM +0400, Dmitry E. Oboukhov wrote:
 found 679447 6.070-1+b1
 thanks
 
 
  I can't reproduce crashes in 6.070-1+b1 :)
 
 sorry for mistake. 6.070-1+b1 crashes, too

Still, I can't reproduce it. The example code you provided doesn't segfault
(with $n = 100, bigger than that my pc freezes), and Corona works fine too.

On amd64 it seems to work fine. Could you please provide a more specific
procedure to reproduce the issue? That is, how are you getting failures so 
reliably?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#679447: libcoro-perl often segfaults

[Alessandro Ghedini]

On Thu, Jun 28, 2012 at 10:51:28PM +0400, Dmitry E. Oboukhov wrote:
 Package: libcoro-perl
 Severity: grave
 Version: 6.080

What version is that supposed to be? I suppose 6.080-2, and yes, it was a
mistake. Everything should be fixed in 6.080-3. Would you mind testing it just
to be sure? (you can find the new package at incoming.debian.org).

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#675895: [Pkg-parrot-devel] Bug#675895: parrot: FTBFS in sid: (.text+0x20): undefined reference to `main'

[Alessandro Ghedini]

tags 675895 confirmed
kthxbye

[ CC-ing icu's maintainer ]

On Mon, Jun 04, 2012 at 02:59:22AM +0200, Samuel Thibault wrote:
 Hello,

Hi,

 parrot currently FTBFS in sid:
 
 /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/Scrt1.o: In 
 function `_start':
 (.text+0x20): undefined reference to `main'
 
 It looks like it's the spurious -fPIE -pie options which come in the
 way, see attached full log.

Apparently it's icu-config --ldlfags (called by Parrot's build system) who
brings in the PIE options (along with all the other hardening build flags).
Using --ldflags-libsonly should do (I'm working on it).

The fact that icu-config passes all those build flags doesn't sound quite right
though and may cause other packages to FTBFS. Jay, what do you think?

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#668692: nqp: FTBFS on 32-bit architectures: two bigint tests fail

[Alessandro Ghedini]

forwarded 668692 https://github.com/perl6/nqp/issues/28
tags 668692 confirmed upstream
kthxbye

On Fri, Apr 13, 2012 at 09:48:01PM -0400, Aaron M. Ucko wrote:
 Source: nqp
 Version: 0.1~2012.01-1
 Severity: serious
 Justification: fails to build from source
 
 Builds of nqp on 32-bit architectures have been failing with the error
 
 Test Summary Report
 ---
 t/nqp/60-bigint.t (Wstat: 0 Tests: 31 Failed: 2)
   Failed tests:  27-28
 
 This appears to be the same as https://github.com/perl6/nqp/issues/28 ,
 which indicates that the tests in question concern round-tripping,
 which may well be sensitive to word size:
 
 https://github.com/perl6/nqp/tree/2012.01/t/nqp/60-bigint.t#L78
 
 Could you please take a look?

I suppose that those two tests could be disabled for now. I'll talk with
upstream about them though.

Thanks

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#666885: Untrusted signature on unstable

[Alessandro Ghedini]

tags 666885 moreinfo
kthxbye

On Mon, Apr 02, 2012 at 08:04:06AM +0100, Klaus Ethgen wrote:
 Package: libcurl3-gnutls
 Version: 7.21.0-2.1+squeeze2
 Severity: serious
 Tags: squeeze
 
 The curent security update has a nontrusted signature. So there is no
 evidence that this package is safe.

What do you mean with untrusted signature? Did you refer to the key that was
used to upload the package?

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#666885: Untrusted signature on unstable

[Alessandro Ghedini]

On Mon, Apr 02, 2012 at 11:45:12AM +0100, Klaus Ethgen wrote:
 Am Mo den  2. Apr 2012 um 10:58 schrieb Alessandro Ghedini:
  tags 666885 moreinfo
  kthxbye
  
  On Mon, Apr 02, 2012 at 08:04:06AM +0100, Klaus Ethgen wrote:
   Package: libcurl3-gnutls
   Version: 7.21.0-2.1+squeeze2
   Severity: serious
   Tags: squeeze
   
   The curent security update has a nontrusted signature. So there is no
   evidence that this package is safe.
  
  What do you mean with untrusted signature? Did you refer to the key that 
  was
  used to upload the package?
 
 Seems to be...
 
~ apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
   curl (7.21.0-2.1+squeeze1 = 7.21.0-2.1+squeeze2)
   libcurl3 (7.21.0-2.1+squeeze1 = 7.21.0-2.1+squeeze2)
   libcurl3-gnutls (7.21.0-2.1+squeeze1 = 7.21.0-2.1+squeeze2)
3 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 780 kB of archives.
After this operation, 12.3 kB disk space will be freed.
Do you want to continue [Y/n]?
WARNING: The following packages cannot be authenticated!
  libcurl3 curl libcurl3-gnutls
Install these packages without verification [y/N]?

I cannot reproduce this. On a just-updated squeeze clean chroot (6.0.4):

  root@PC-Ale:/# apt-get install libcurl3-gnutls
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  The following NEW packages will be installed:
libcurl3-gnutls
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 266 kB of archives.
  After this operation, 532 kB of additional disk space will be used.
  Get:1 http://security.debian.org/ squeeze/updates/main libcurl3-gnutls amd64 
7.21.0-2.1+squeeze2 [266 kB]
  Fetched 266 kB in 0s (552 kB/s)
  debconf: delaying package configuration, since apt-utils is not installed
  Selecting previously deselected package libcurl3-gnutls.
  (Reading database ... 12952 files and directories currently installed.)
  Unpacking libcurl3-gnutls (from 
.../libcurl3-gnutls_7.21.0-2.1+squeeze2_amd64.deb) ...
  Setting up libcurl3-gnutls (7.21.0-2.1+squeeze2) ...

Same for curl and libcurl3.

Does this happen only with curl packages? When was the last time you did an
apt upgrade (except this one, of course)?

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

On Sat, Mar 31, 2012 at 07:12:36PM +0200, Florian Weimer wrote:
 * Alessandro Ghedini:
 
  Anyway, you can upload to security-master when ready.  You must build
  the package with specifying the -sa flag, on a squeeze system.
 
  Ok, thank you.
 
 Thanks for uploading.  I'm a bit confused--is this an interoperability
 issue introduced by DSA-2398-1?

Yes, the fix for the CVE-2011-3389 related issue broke backwards compatibility
with older SSL implementations.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

On Wed, Mar 28, 2012 at 10:51:53PM +0200, Florian Weimer wrote:
 * Alessandro Ghedini:
 
  We should fix this through stable-security. Please send a debdiff once
  the fix has been testing in unstable for a few days.
 
  Attached is the debdiff for stable-security.
 
 Looks good.
 
  If everything's ok I will upload it (I'm a DD since a few hours) in
  a few days, once the sid version has been tested more.
 
 Do you really think this option will actually be used in practice,
 except if there's a failure?

Well... not really. I'm doing some tests on my own though.

 Anyway, you can upload to security-master when ready.  You must build
 the package with specifying the -sa flag, on a squeeze system.

Ok, thank you.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

On Sun, Feb 12, 2012 at 08:23:02PM +0100, Moritz Mühlenhoff wrote:
 On Sat, Feb 11, 2012 at 02:04:01PM +0100, Alessandro Ghedini wrote:
  On Fri, Feb 10, 2012 at 08:23:24PM +0100, Kurt Roeckx wrote:
   On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote:
On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
 Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
 would be fine if I had the option to turn it on.  In that case
 it's my decision to ignore the security consequences.

This has been fixed upstream now (commits 2a699bc6 and 62d15f15).
   
   Do you plan to upload this to stable-proposed-updates?
  
  Yep, once curl 7.25.0 is released and uploaded to unstable (as Julian said 
  I'll prepare another upload for security).
 
 We should fix this through stable-security. Please send a debdiff once
 the fix has been testing in unstable for a few days.

Attached is the debdiff for stable-security. If everything's ok I will upload
it (I'm a DD since a few hours) in a few days, once the sid version has been
tested more.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
diff -Nru curl-7.21.0/debian/changelog curl-7.21.0/debian/changelog
--- curl-7.21.0/debian/changelog2012-01-24 20:52:47.0 +0100
+++ curl-7.21.0/debian/changelog2012-03-24 15:02:23.0 +0100
@@ -1,3 +1,10 @@
+curl (7.21.0-2.1+squeeze2) stable-security; urgency=low
+
+  * Non-maintainer upload
+  * Add --ssl-allow-beast and CURLOPT_SSL_OPTIONS (Closes: #658276)
+
+ -- Alessandro Ghedini al3x...@gmail.com  Sat, 24 Mar 2012 15:01:45 +0100
+
 curl (7.21.0-2.1+squeeze1) stable-security; urgency=high
 
   * Non-maintainer upload
diff -Nru curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added 
curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added
--- curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added1970-01-01 
01:00:00.0 +0100
+++ curl-7.21.0/debian/patches/CURLOPT_SSL_OPTIONS_added2012-03-24 
15:32:56.0 +0100
@@ -0,0 +1,158 @@
+From 2a699bc6e94b8223d900e8880ad628aebf17ab6d Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg dan...@haxx.se
+Date: Mon, 6 Feb 2012 22:12:06 +0100
+Subject: [PATCH 1/2] CURLOPT_SSL_OPTIONS: added
+
+Allow an appliction to set libcurl specific SSL options. The first and
+only options supported right now is CURLSSLOPT_ALLOW_BEAST.
+
+It will make libcurl to disable any work-arounds the underlying SSL
+library may have to address a known security flaw in the SSL3 and TLS1.0
+protocol versions.
+
+This is a reaction to us unconditionally removing that behavior after
+this security advisory:
+
+http://curl.haxx.se/docs/adv_20120124B.html
+
+... it did however cause a lot of programs to fail because of old
+servers not liking this work-around. Now programs can opt to decrease
+the security in order to interoperate with old servers better.
+---
+ docs/libcurl/curl_easy_setopt.3  |   10 ++
+ docs/libcurl/symbols-in-versions |2 ++
+ include/curl/curl.h  |   12 
+ lib/ssluse.c |5 -
+ lib/url.c|   15 ++-
+ lib/urldata.h|2 ++
+ 6 files changed, 40 insertions(+), 6 deletions(-)
+
+--- a/docs/libcurl/curl_easy_setopt.3
 b/docs/libcurl/curl_easy_setopt.3
+@@ -1964,6 +1964,16 @@
+ cache. While nothing ever should get hurt by attempting to reuse SSL
+ session-IDs, there seem to be broken SSL implementations in the wild that may
+ require you to disable this in order for you to succeed. (Added in 7.16.0)
++.IP CURLOPT_SSL_OPTIONS
++Pass a long with a bitmask to tell libcurl about specific SSL behaviors.
++
++CURLSSLOPT_ALLOW_BEAST is the only supported bit and by setting this the user
++will tell libcurl to not attempt to use any work-arounds for a security flaw
++in the SSL3 and TLS1.0 protocols.  If this option isn't used or this bit is
++set to 0, the SSL layer libcurl uses may use a work-around for this flaw
++although it might cause interoperability problems with some (older) SSL
++implementations. WARNING: avoiding this work-around loosens the security, and
++by setting this option to 1 you ask for exactly that. (Added in 7.25.0)
+ .IP CURLOPT_KRBLEVEL
+ Pass a char * as parameter. Set the kerberos security level for FTP; this also
+ enables kerberos awareness.  This is a string, \'clear', \'safe',
+--- a/docs/libcurl/symbols-in-versions
 b/docs/libcurl/symbols-in-versions
+@@ -368,6 +368,7 @@
+ CURLOPT_SSL_CIPHER_LIST 7.9
+ CURLOPT_SSL_CTX_DATA7.10.6
+ CURLOPT_SSL_CTX_FUNCTION7.10.6
++CURLOPT_SSL_OPTIONS 7.25.0
+ CURLOPT_SSL_SESSIONID_CACHE 7.16.0
+ CURLOPT_SSL_VERIFYHOST  7.8.1
+ CURLOPT_SSL_VERIFYPEER  7.4.2
+@@ -430,6 +431,7 @@
+ CURLSSH_AUTH_NONE   7.16.1
+ CURLSSH_AUTH_PASSWORD   7.16.1
+ CURLSSH_AUTH_PUBLICKEY  7.16.1
++CURLSSLOPT_ALLOW_BEAST  7.25.0

Bug#664900: libio-socket-ssl-perl: FTBFS, failing test

[Alessandro Ghedini]

On Sat, Mar 24, 2012 at 12:45:18PM +0100, Salvatore Bonaccorso wrote:
 
 Hi Alessandro
 
 On Wed, Mar 21, 2012 at 11:39:20PM +0100, Alessandro Ghedini wrote:
  On Wed, Mar 21, 2012 at 11:19:47PM +0100, Alessandro Ghedini wrote:
   On Wed, Mar 21, 2012 at 10:26:37PM +0100, Salvatore Bonaccorso wrote:
On Wed, Mar 21, 2012 at 09:02:54PM +0100, Salvatore Bonaccorso wrote:
  t/dhe.t 
  Failed 2/3 subtests
   
In fact this one does not fail in a wheezy build with 1.42-1+b1.
   
Okay to reassign this to libnet-ssleay-perl and add a affects
libio-socket-ssl-perl?
  
   I think it is an openssl-related thing. I can reproduce the failure
   with the latest libssl1.0.0 in sid (1.0.1-2) but not with the version
   1.0.0h-1 and below.
  
  Also, having a look at the t/dhe.t file I read:
  
   # openssl 1.0.1(beta2) complains about the rsa key too small, unless
   # we explicitly set version to tlsv1 or sslv3
   # unfortunatly the workaround fails for older openssl versions :(
  
  I think that the version check below that comment is the cause:
  removing it (but leaving the SSL_version = 'tlsv1') solves the
  problem for me with libssl 1.0.1 (but would probably break with older
  versions).
  
  Given that OPENSSL_VERSION_NUMBER is a macro, maybe simply rebuilding
  libnet-ssleay-perl against the new libssl would solve the issue?
 
 I looked into this now, and yes you should be right. When recompiling
 libnet-ssleay-perl against new openssl the issue dissapears then. 
 
 We still have [1] open, but upstream RT contains discussion on
 resolving that.
 
  [1] http://bugs.debian.org/661566

Also, I've tried to build libio-socket-ssl-perl removing the
Net::SSLeay version test from t/dhe.t as I did before but using OpenSSL
1.0.0h this time, and everything works fine (despite what the comment
in the test says). IMO we should be ok patching the test and uploading
the package without waiting a rebuild of Net::SSLeay (I'll push a patch
soon).

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

Hi Kurt,

curl 7.25.0 was released yesterday and I'm now working on updating the
Debian package. A problem come up though with the --ssl-enable-beast
new option of curl (which should fix the bug that you have reported)
and the new version of openssl. If I build curl against the current
version 1.0.1-2 (uploaded a few days ago) of libssl the option has no
effect with the URL you posted above and curl fails with the error:

curl: (35) error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
unexpected message

(the 35 means that the error happened in the SSL handshake).

But if I build with a slightly older libssl (1.0.0h-1) the option works
as expected and if the option is not used at all the error is the same
that you reported (Empty reply from server).

Now, since you did the openssl uploads, do you know of any change in
openssl that may have caused this problem and if there's anything that
can be done on the curl's side to fix it?

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

On Fri, Mar 23, 2012 at 07:02:34PM +0100, Kurt Roeckx wrote:
 On Fri, Mar 23, 2012 at 06:38:40PM +0100, Alessandro Ghedini wrote:
  Hi Kurt,
  
  curl 7.25.0 was released yesterday and I'm now working on updating the
  Debian package. A problem come up though with the --ssl-enable-beast
  new option of curl (which should fix the bug that you have reported)
  and the new version of openssl. If I build curl against the current
  version 1.0.1-2 (uploaded a few days ago) of libssl the option has no
  effect with the URL you posted above and curl fails with the error:
  
  curl: (35) error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert 
  unexpected message
  
  (the 35 means that the error happened in the SSL handshake).
  
  But if I build with a slightly older libssl (1.0.0h-1) the option works
  as expected and if the option is not used at all the error is the same
  that you reported (Empty reply from server).
  
  Now, since you did the openssl uploads, do you know of any change in
  openssl that may have caused this problem and if there's anything that
  can be done on the curl's side to fix it?
 
 So I see:
 openssl s_client -connect www.eboekhuis.nl:443
 CONNECTED(0003)
 140090768766632:error:140773F2:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 
 alert unexpected message:s23_clnt.c:708:
 ---
 no peer certificate available
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 7 bytes and written 324 bytes
 ---
 New, (NONE), Cipher is (NONE)
 Secure Renegotiation IS NOT supported
 Compression: NONE
 Expansion: NONE
 ---
 
 But it works when I use:
 openssl s_client -no_tls1_2 -no_tls1_1 -connect www.eboekhuis.nl:443
 
 
 Tls1.1 and 1.2 support is new since openssl 1.0.1.
 
 I'm not sure what to do about this.  I can at least let them know that that 
 is an issue too.
 But maybe I should contact upstream openssl so they can take a look too that 
 it's not a bug
 in openssl.

Indeed, explicitly setting TLSv1 (--tlsv1 option in curl) works. I was afraid
this was a new bug in curl's OpenSSL code but apparently it's not (or at least
it is not as grave as I thought). I'll go on with the curl uploads then.

Thanks

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#664900: libio-socket-ssl-perl: FTBFS, failing test

[Alessandro Ghedini]

On Wed, Mar 21, 2012 at 10:26:37PM +0100, Salvatore Bonaccorso wrote:
 On Wed, Mar 21, 2012 at 09:02:54PM +0100, Salvatore Bonaccorso wrote:
   t/dhe.t 
   Failed 2/3 subtests

 In fact this one does not fail in a wheezy build with 1.42-1+b1.

 Okay to reassign this to libnet-ssleay-perl and add a affects
 libio-socket-ssl-perl?

I think it is an openssl-related thing. I can reproduce the failure
with the latest libssl1.0.0 in sid (1.0.1-2) but not with the version
1.0.0h-1 and below.

Cheers

--
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#664900: libio-socket-ssl-perl: FTBFS, failing test

[Alessandro Ghedini]

On Wed, Mar 21, 2012 at 11:19:47PM +0100, Alessandro Ghedini wrote:
 On Wed, Mar 21, 2012 at 10:26:37PM +0100, Salvatore Bonaccorso wrote:
  On Wed, Mar 21, 2012 at 09:02:54PM +0100, Salvatore Bonaccorso wrote:
t/dhe.t 
Failed 2/3 subtests
 
  In fact this one does not fail in a wheezy build with 1.42-1+b1.
 
  Okay to reassign this to libnet-ssleay-perl and add a affects
  libio-socket-ssl-perl?

 I think it is an openssl-related thing. I can reproduce the failure
 with the latest libssl1.0.0 in sid (1.0.1-2) but not with the version
 1.0.0h-1 and below.

Also, having a look at the t/dhe.t file I read:

 # openssl 1.0.1(beta2) complains about the rsa key too small, unless
 # we explicitly set version to tlsv1 or sslv3
 # unfortunatly the workaround fails for older openssl versions :(

I think that the version check below that comment is the cause:
removing it (but leaving the SSL_version = 'tlsv1') solves the
problem for me with libssl 1.0.1 (but would probably break with older
versions).

Given that OPENSSL_VERSION_NUMBER is a macro, maybe simply rebuilding
libnet-ssleay-perl against the new libssl would solve the issue?

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#664056: libxml-atom-microformats-perl: FTBFS: Test suite failures

[Alessandro Ghedini]

On Fri, Mar 16, 2012 at 09:39:11PM +0100, Salvatore Bonaccorso wrote:
 Hi
 
 Okay, so I did this, unpacked the source, builded, clean, build and it
 succeeds. Build log is attached.

Does this mean that we are ok without the override? If yes I'll remove it
ASAP.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#664056: libxml-atom-microformats-perl: FTBFS: Test suite failures

[Alessandro Ghedini]

tags 664056 pending
kthxbye

On Sat, Mar 17, 2012 at 02:19:39PM +0100, Salvatore Bonaccorso wrote:
 Hi Alessandro
 
 On Sat, Mar 17, 2012 at 12:02:01PM +0100, Alessandro Ghedini wrote:
  On Fri, Mar 16, 2012 at 09:39:11PM +0100, Salvatore Bonaccorso wrote:
   Hi
   
   Okay, so I did this, unpacked the source, builded, clean, build and it
   succeeds. Build log is attached.
  
  Does this mean that we are ok without the override? If yes I'll remove it
  ASAP.
 
 Yes, this should be fine! Thanks for your work, Alessandro.

Ok, done. I've also updated libxml-atom-microformats-perl to build depend
on the new version.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#664056: libxml-atom-microformats-perl: FTBFS: Test suite failures

[Alessandro Ghedini]

forwarded 664056 https://rt.cpan.org/Public/Bug/Display.html?id=75505
kthxbye

On Fri, Mar 16, 2012 at 12:09:32AM +0100, Florian Schlichting wrote:
 reassign 664056 libxml-libxml-perl 1.93+dfsg-1
 retitle 664056 libxml-libxml-perl (= 1.93+dfsg-1) has issues overloading != 
 on XML::LibXML::Element
 thanks
 
 This is actually a bug in libxml-libxml-perl before 1.94, see
 https://rt.cpan.org/Public/Bug/Display.html?id=75505
 
 I've built libxml-libxml-perl 1.95+dfsg-1 and was able to confirm that
 the test in libxml-atom-microformats-perl no longer fails.
 
 My suggestion for the build-twice-in-a-row issue with
 libxml-libxml-perl, lacking substantial EE::MM knowledge, would be to
 manually anticipate what EU::MM helpfully bails out on, like so:
 
 override_dh_auto_clean:
rm -f Makefile
perl Makefile.PL
dh_auto_clean
 
 works for me :-)

Looks a bit ugly but works :)

Missing any better solution I've committed it (testing now).

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#661566: libnet-ssleay-perl: Segfault when lniked into an Apache/mod_ssl/mod_perl process

[Alessandro Ghedini]

tags 661566 confirmed
kthxbye

On Mon, Feb 27, 2012 at 06:57:13PM -0800, Ivan Kohler wrote:
 Package: libnet-ssleay-perl
 Version: 1.45-1
 Severity: important
 
 Apache segfaults when this module is included in a mod_perl application and
 mod_ssl is enabled.  I am using the prefork MPM.
 
 To reproduce:
 a2enmod ssl
 a2enmod perl
 echo PerlModule Net::SSLeay /etc/apache2/conf.d/sslbug.conf
 service apache2 restart
 
 1.43-1 is also broken in this regard.
 1.42-1+b1 works.

I can reproduce the bug in a Sid chroot with the above procedure, but I'm 
no Apache expert so I can't really tell what's going on.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#649060: libtokyocabinet-perl: FTBFS on mipsel

[Alessandro Ghedini]

On Thu, Mar 01, 2012 at 11:17:40PM +0100, Salvatore Bonaccorso wrote:
 Hi wb-team!
 
 libtokyocabinet-perl had a build failure on mipsel [1].
 
  [1] http://bugs.debian.org/649060
 
 Bug [2] was now fixed in src:tokyocabinet, which caused already there
 the bus error failure. Could you thus re-schedule a build for
 libtokyocabinet-perl?
 
  [2] http://bugs.debian.org/659554
 
 dw libtokyocabinet-perl_1.34-1 . mipsel . -m 'libtokyocabinet-dev (= 
 1.4.37-9)'

Looks like it has been re-built [0]. Should we close this bug now?

Cheers

[0] https://buildd.debian.org/status/package.php?p=libtokyocabinet-perl

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

On Fri, Feb 10, 2012 at 08:23:24PM +0100, Kurt Roeckx wrote:
 On Fri, Feb 10, 2012 at 10:15:44AM +0100, Alessandro Ghedini wrote:
  On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
   Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
   would be fine if I had the option to turn it on.  In that case
   it's my decision to ignore the security consequences.
  
  This has been fixed upstream now (commits 2a699bc6 and 62d15f15).
 
 Do you plan to upload this to stable-proposed-updates?

Yep, once curl 7.25.0 is released and uploaded to unstable (as Julian said 
I'll prepare another upload for security).

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

tags 658276 fixed-upstream
kthxbye

On Sat, Feb 04, 2012 at 10:45:59PM +0100, Kurt Roeckx wrote:
 On Sat, Feb 04, 2012 at 10:11:31PM +0100, Alessandro Ghedini wrote:
  
  AFAIU, the problem is that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option is 
  meant to keep compatibility with some older and broken SSL implementations 
  that don't support empty fragments, but it also re-introduces a security 
  issue.
  
  That's why such option was disabled in curl 7.24.0 (and backported to 
  stable-security). It was a mistake on the curl developers side to enable it
  in the first place (it was done by accident because of the not-so-clear 
  OpenSSL documentation, according to upstream).
  
  I understand that this may cause problems (the incompatibility didn't show 
  up in my tests with live SSL servers though), but leaving a security issue 
  open *by default* is not a better solution IMO.
  
  Maybe an option, for both libcurl and curl, to explicitly enable the
  SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would do the trick? 
  
  Alternative solutions/opinions would be welcome, if you happen to have any.
 
 Having SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS disabled by default
 would be fine if I had the option to turn it on.  In that case
 it's my decision to ignore the security consequences.

This has been fixed upstream now (commits 2a699bc6 and 62d15f15).

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#658276: libcurl3: Doesn't work for all sites anymore

[Alessandro Ghedini]

retitle 658276 libcurl3: No more compatible with older SSL implementations
forwarded 658276 http://curl.haxx.se/mail/lib-2012-02/0001.html
kthxbye

On Wed, Feb 01, 2012 at 07:27:06PM +0100, Kurt Roeckx wrote:
 Package: libcurl3
 Version: 7.21.0-2.1+squeeze1, 7.24.0-1
 Severity: grave
 
 Hi,

Hi,

 After the upgrade from 7.21.0-2 or 7.23.1-3 some sites stop to
 work while others continue to work.

 My guess is that this is related to the CVE-2011-3389 change.
 If my memory is any good, the reason why openssl still does
 something with that option is because not all implementations
 work without it.  I think I at least saw a blog post about
 the state of that issue a few months ago.

AFAIU, the problem is that the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS option is 
meant to keep compatibility with some older and broken SSL implementations 
that don't support empty fragments, but it also re-introduces a security 
issue.

That's why such option was disabled in curl 7.24.0 (and backported to 
stable-security). It was a mistake on the curl developers side to enable it
in the first place (it was done by accident because of the not-so-clear 
OpenSSL documentation, according to upstream).

I understand that this may cause problems (the incompatibility didn't show 
up in my tests with live SSL servers though), but leaving a security issue 
open *by default* is not a better solution IMO.

Maybe an option, for both libcurl and curl, to explicitly enable the
SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS would do the trick? 

Alternative solutions/opinions would be welcome, if you happen to have any.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651619: curl: dependencies insufficient, application fails to load

[Alessandro Ghedini]

tags 651619 pending
kthxbye

On Sat, Dec 10, 2011 at 06:30:17PM +0100, Alessandro Ghedini wrote:
 For reasons I do not know the shlibs version of the libcurl3 package was 
 overridden by one of the previous maintainers of the package and hasn't 
 been updated for long. I will look into this (I'll probably remove the 
 overrides at this point or just bump them FWIW).

Actually, the shlibs overrides *are* needed, it's just that they have not 
been updated since curl 7.16.something.

I've bumped them now for all the lib packages, the upload should follow 
soon.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651619: curl: dependencies insufficient, application fails to load

[Alessandro Ghedini]

On Sun, Dec 11, 2011 at 05:07:43PM +0100, Luk Claes wrote:
 On 12/11/2011 04:53 PM, Alessandro Ghedini wrote:
  On Sat, Dec 10, 2011 at 06:30:17PM +0100, Alessandro Ghedini wrote:
  For reasons I do not know the shlibs version of the libcurl3 package was 
  overridden by one of the previous maintainers of the package and hasn't 
  been updated for long. I will look into this (I'll probably remove the 
  overrides at this point or just bump them FWIW).
  
  Actually, the shlibs overrides *are* needed, it's just that they have not 
  been updated since curl 7.16.something.
  
  I've bumped them now for all the lib packages, the upload should follow 
  soon.
 
 Did you have a look at the difference between symbols of the 7.16
 version and the latest one adding new symbols? 

IIRC there were some symbols introduced somewhere between 7.16 and 7.21.1, 
and others in 7.23.0 (note that they are not listed in the upstream
cheangelog). So basically 7.23.1 is both the latest upstream and the latest 
that introduced new symbols in Debian (we didn't have 7.23.0).

 Hmm, shouldn't we use symbol files so dependencies only get bumped when
 there are actually new symbols and only when they get used?

I was thinking the same today. The tricky part is that dpkg-gensymbols 
will only generate *.symbols files with version 7.23.1 (or whatever is the
latest package version when it is run) for all the symbols (unless versions 
are specified manually for the single symbols) making it not much effective 
as of now (also, libcurl3-nss must have 7.23.1 anyway because of the change
in the 7.23.1-1 upload). 

On the other hand, once properly done, it would most probably avoid mistakes
like the one that caused this bug report, since the process will be mostly 
automatically executed by dpkg-gensymbols.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651619: curl: dependencies insufficient, application fails to load

[Alessandro Ghedini]

On Sun, Dec 11, 2011 at 07:19:09PM +0100, Luk Claes wrote:
 On 12/11/2011 06:46 PM, Alessandro Ghedini wrote:
  On Sun, Dec 11, 2011 at 05:07:43PM +0100, Luk Claes wrote:
  Hmm, shouldn't we use symbol files so dependencies only get bumped when
  there are actually new symbols and only when they get used?
  
  I was thinking the same today. The tricky part is that dpkg-gensymbols 
  will only generate *.symbols files with version 7.23.1 (or whatever is the
  latest package version when it is run) for all the symbols (unless versions 
  are specified manually for the single symbols) making it not much effective 
  as of now (also, libcurl3-nss must have 7.23.1 anyway because of the change
  in the 7.23.1-1 upload). 
  
  On the other hand, once properly done, it would most probably avoid mistakes
  like the one that caused this bug report, since the process will be mostly 
  automatically executed by dpkg-gensymbols.
 
 Right, so it seems it's a good time to start?

Well, yes. It will require some time if done properly though (also, I cannot
allocate much time for this before wednesday). Would uploading 7.23.1-3 as
it is now and 7.23.1-4 with the *.symbols when it'll be ready make sense?

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#651619: curl: dependencies insufficient, application fails to load

[Alessandro Ghedini]

On Sat, Dec 10, 2011 at 11:06:56AM -0500, Sam Hartman wrote:
 package: curl
 severity: grave
 version: 7.23.1-2
 
 curl: relocation error: curl: symbol curl_dostrdup, version CURL_OPENSSL_3 
 not d
 efined in file libcurl.so.4 with link time reference  
  
 
 I have libcurl3 Version: 7.21.3-1
 
 Upgrading libcurl3 fixes things, but the shlibs and/or explicit
 dependency are clearly wrong.

For reasons I do not know the shlibs version of the libcurl3 package was 
overridden by one of the previous maintainers of the package and hasn't 
been updated for long. I will look into this (I'll probably remove the 
overrides at this point or just bump them FWIW).

Thanks for the report.

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#650800: hiredis: FTBFS on mipsel: rm: cannot remove `/tmp/redis.sock': No such file or directory

[Alessandro Ghedini]

tags 650800 pending
kthxbye

On Sat, Dec 03, 2011 at 11:08:44AM +0100, Jakub Wilk wrote:
 Source: hiredis
 Version: 0.10.1-3
 Severity: serious
 Justification: fails to build from source
 User: debian-m...@lists.debian.org
 Usertags: mipsel
 
 hiredis FTBFS on mipsel:
 | ALL TESTS PASSED
 | make[2]: Leaving directory 
 `/build/buildd-hiredis_0.10.1-3-mipsel-0zxEz6/hiredis-0.10.1'
 | kill `cat /tmp/redis.pid`
 | rm /tmp/redis.pid
 | rm /tmp/redis.sock
 | rm: cannot remove `/tmp/redis.sock': No such file or directory
 | make[1]: *** [override_dh_auto_test] Error 1
 
 Full build log:
 https://buildd.debian.org/status/fetch.php?pkg=hiredisarch=mipselver=0.10.1-3stamp=1322841081

Ah thanks. Should be fixed in git now.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#650498: libcurl3-nss breaks bti 031-4: version `CURL_3' not found

[Alessandro Ghedini]

tags 650498 pending
kthxbye

On Wed, Nov 30, 2011 at 10:16:04AM +0100, Vincent Lefevre wrote:
 Package: libcurl3-nss
 Version: 7.23.1-1
 Severity: grave
 Justification: renders package unusable
 
 bti 031-4 depends on libcurl3-nss (= 7.16.2-1) and was working with it,
 but after the upgrade of libcurl3-nss to 7.23.1-1, I get the following
 error from bti:
 
 bti: /usr/lib/x86_64-linux-gnu/libcurl-nss.so.4: version `CURL_3' not found 
 (required by bti)
 
 It seems that libcurl3-nss made an ABI incompatible change, without the
 necessary in the dependency system...

I have enabled symbols versioning for the libcurl NSS flavour in the 
latest upload of curl and missed the other necessary changes to make it
work flawlessly. Sorry for the inconvenience :/

I reverted the change for now, a new version should be uploaded soon.

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#649927: beets: missing Depends on python-pkg-resources

[Alessandro Ghedini]

Package: beets
Version: 1.0~b10+dfsg-1
Severity: grave
Justification: renders package unusable

Hi,

running beet I always get:

  % beet
  Traceback (most recent call last):
File /usr/bin/beet, line 5, in module
  from pkg_resources import load_entry_point
  ImportError: No module named pkg_resources

and then it exits. Installing python-pkg-resources resolves the problem,
therefore I think it should be added to the beets Depends.

Cheers

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to it_IT.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages beets depends on:
ii  libjs-backbone   0.5.3-2  
ii  libjs-jquery 1.7-1
ii  libjs-underscore 1.1.6-2  
ii  python   2.7.2-9  
ii  python-munkres   1.0.5.4-2
ii  python-musicbrainz2  0.7.4-1  
ii  python-mutagen   1.20-1   
ii  python-unidecode 0.04.9-1 

beets recommends no packages.

Versions of packages beets suggests:
ii  python-flasknone   
ii  python-gst0.10  0.10.22-1

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#637757: With last rebuild on mips build is fine

[Alessandro Ghedini]

On Wed, Nov 16, 2011 at 09:36:33PM +0100, Salvatore Bonaccorso wrote:
 Hi
 
 With the last build attempt (rebuild for the perl 5.12 to 5.14
 transition) the build went fine [1].
 
  [1] 
 https://buildd.debian.org/status/logs.php?pkg=libaudio-ecasound-perlarch=mips
 
 Maybe we can lower the severity, but still why does it sometime's
 fail? (Always but once on corelli).

There have been quite some changes in the ecasound package itself. They 
happened just before the libaudio-ecasound-perl v1.01-2 upload. I think 
that's why it used to build on corelli but now it doesn't anymore.

It's just a wild guess though, maybe contacting the mips people may shed
some light on this.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#642662: foo-yc20: FTBFS: src/../gen/yc20-dsp-standalone.cpp:34:21: fatal error: gui/GUI.h: No such file or directory

[Alessandro Ghedini]

tags 642662 pending
kthxbye

On Sat, Sep 24, 2011 at 04:44:30PM +0200, berta...@ptitcanardnoir.org wrote:
 Hi,

Hi,

 During a rebuild of all packages in sid, your package failed to build on
 amd64.
 
 Relevant part:
  g++ src/faust-dsp-standalone.cpp -O3 -mtune=native -march=native 
  -mfpmath=sse -ffast-math -ftree-vectorize  -fPIC -DVERSION=1.3.0 -Isrc/ 
  -Iinclude/ -DPREFIX=/usr -Wall -c -o src/faust-dsp-standalone.o
  In file included from src/faust-dsp-standalone.cpp:31:0:
  src/../gen/yc20-dsp-standalone.cpp:34:21: fatal error: gui/GUI.h: No such 
  file or directory
  compilation terminated.
  make[2]: *** [src/faust-dsp-standalone.o] Error 1

I've added a patch that fixes the FTBS [0]. I only need someone from the
pkg-multimedia team to upload the fixed version.

Alessio (or someone else), could you please have a look?

Cheers

[0] 
http://anonscm.debian.org/gitweb/?p=pkg-multimedia/foo-yc20.git;a=blob;f=debian/patches/0003-include-faust-dir.patch;h=fd7c02f45cfecc3458b091896a1288cfe7f79a6c;hb=HEAD

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#634198: hiredis: FTBFS (kfreebsd): Testsuite failures

[Alessandro Ghedini]

Hi,

sorry for the late reply, I've been on holiday for the past couple of weeks.

On Sun, Jul 17, 2011 at 06:52:30PM +0200, Christoph Egger wrote:
 Your package failed to build on the kfreebsd-* buildds:
 
 #44 Can handle nested multi bulk replies: PASSED
 #45 Returns I/O error when the connection is lost: PASSED
 #46 Returns I/O error on socket timeout: PASSED
 #47 Throughput:
   (1000x PING: 0.038s)
   (1000x LRANGE with 500 elements: 0.210s)
   (1x PING (pipelined): 0.014s)
   (1x LRANGE with 500 elements (pipelined): 1.922s)
 *** 1 TESTS FAILED ***
 make[2]: *** [test] Error 1
 make[2]: Leaving directory 
 `/build/buildd-hiredis_0.10.1-2-kfreebsd-amd64-a6Qsiq/hiredis-0.10.1'
 dh_auto_test: make -j1 test returned exit code 2
 make[1]: *** [override_dh_auto_test] Error 29
 make[1]: Leaving directory 
 `/build/buildd-hiredis_0.10.1-2-kfreebsd-amd64-a6Qsiq/hiredis-0.10.1'
 make: *** [build] Error 2
 
 Full build log at
 https://buildd.debian.org/status/fetch.php?pkg=hiredisarch=kfreebsd-i386ver=0.10.1-2stamp=1309770541

Thanks for reporting, I think I'll disable that test in the next upload, if
I won't find any better solution.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#633764: starman: failing tests

[Alessandro Ghedini]

On Wed, Jul 13, 2011 at 03:33:39PM +0200, Salvatore Bonaccorso wrote:
 starman FTBFS due to test failures:

Weird, it builds fine here (sid pbuilder on amd64).

Could you please try the version on SVN (0.2013-1)? It should have
relaxed the t/harakiri.t test, maybe fixing the problem (I didn't 
experienced FTBS at the time hence that version didn't get uploaded).

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#624847: pulseaudio does not build anymore with xcb-util 0.3.8

[Alessandro Ghedini]

Arnaud,

I think libxcb-atom1-dev would be better replaced by libxcb-util0-dev,
which completely replaces libxcb-atom1-dev, instead of libxcb1-dev, am I 
wrong?

Anyway, is there any news on the NMU? Please note that the bug makes many 
of the binary packages built from this version of pulseaudio, uninstallable,
as reported by #629394.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#627229: libaudio-ecasound-perl: Ecasound.xs:5:23: fatal error: ecasoundc.h: No such file or directory

[Alessandro Ghedini]

On Thu, May 19, 2011 at 11:54:32AM +0200, gregor herrmann wrote:
 On Thu, 19 May 2011 11:43:00 +0200, Alessandro Ghedini wrote:
 
   The reason seems to bit a re-organization of the ecasound soure
   package:
   http://packages.qa.debian.org/e/ecasound/news/20110517T221719Z.html
   And it fails to build:
   https://buildd.debian.org/status/package.php?p=ecasound
   I guess we have to wait for a fixed ecasound package and then change
   the build dependency ...
  We had some problems with the new version of ecasound (it failed many 
  builds). A new version that should have fixed all the issues has been 
  uploaded yesterday evening (it's in NEW now).
 
 Ah, good to know.
 Can you keep an eye on the -perl package (or just ping the bug
 report) when the new ecasound is ready?

ecasound 2.8.0-3 is in sid now. I've updated the libaudio-ecasound-perl 
package and I'll push to svn as soon as alioth gets back online.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#627229: libaudio-ecasound-perl: Ecasound.xs:5:23: fatal error: ecasoundc.h: No such file or directory

[Alessandro Ghedini]

On Wed, May 18, 2011 at 11:50:18PM +0200, gregor herrmann wrote:
 On Wed, 18 May 2011 22:54:45 +0200, Salvatore Bonaccorso wrote:
 
  libaudio-ecasound-perl FTBFS in unstable due to:
 
 Builds for me in cowbuilder but only because it sorts out the
 dependencies somehow:
 
 The following packages have unmet dependencies:
   libecasoundc2.2-dev: Depends: libecasoundc-dev which is a virtual package.
   ecasound: Depends: python-ecasound2.2 (= 2.7.0-1.1) but it is not going to 
 be installed.
 The following actions will resolve these dependencies:
 
  Install the following packages:
 1) libecasoundc2.2-dev [2.7.0-1.1+b1 (unstable)]
 2) libncurses5-dev [5.9-1 (unstable)]   
 3) libreadline-dev [6.2-1 (unstable)]   
 4) libreadline6-dev [6.2-1 (unstable)]  
 5) python-ecasound2.2 [2.7.0-1.1 (unstable)]
 6) python-support [1.0.13 (unstable)]   
 
 
 I assume sbuild fails here.
 
 The reason seems to bit a re-organization of the ecasound soure
 package:
 http://packages.qa.debian.org/e/ecasound/news/20110517T221719Z.html
 
 And it fails to build:
 https://buildd.debian.org/status/package.php?p=ecasound
 
 I guess we have to wait for a fixed ecasound package and then change
 the build dependency ...

We had some problems with the new version of ecasound (it failed many 
builds). A new version that should have fixed all the issues has been 
uploaded yesterday evening (it's in NEW now).

In the future libaudio-ecasound-perl should build depend on 
libecasoundc-dev instead of libecasoundc2.2-dev.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org