Bug#1068415: nghttp2: CVE-2024-28182: Reading unbounded number of HTTP/2 CONTINUATION frames to cause excessive CPU usage

[Tomasz Buchert]

On 04/04/24 21:36, Salvatore Bonaccorso wrote:
> Source: nghttp2
> Version: 1.60.0-1
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi,
> 
> The following vulnerability was published for nghttp2.
> 
> CVE-2024-28182[0]:
> | nghttp2 is an implementation of the Hypertext Transfer Protocol
> | version 2 in C. The nghttp2 library prior to version 1.61.0 keeps
> | reading the unbounded number of HTTP/2 CONTINUATION frames even
> | after a stream is reset to keep HPACK context in sync.  This causes
> | excessive CPU usage to decode HPACK stream. nghttp2 v1.61.0
> | mitigates this vulnerability by limiting the number of CONTINUATION
> | frames it accepts per stream. There is no workaround for this
> | vulnerability.
> 
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2024-28182
> https://www.cve.org/CVERecord?id=CVE-2024-28182
> [1] https://github.com/nghttp2/nghttp2/security/advisories/GHSA-x6x3-gv8h-m57q
> 
> Please adjust the affected versions in the BTS as needed.
> 
> Regards,
> Salvatore

As the first measure I uploaded 1.61.0-1 to unstable with urgency=high.

Looking into older versions and appropriately patching them will take more time.

Tomasz

Bug#982882: stellarium FTBFS on armel and mipsel

[Tomasz Buchert]

On 15/02/21 20:54, Paul Gevers wrote:
> Source: stellarium
> Version: 0.20.4-1
> Severity: serious
> Tags: ftbfs
>
> [...]

Seems like it is
https://github.com/Stellarium/stellarium/issues/1131. This has been
solved with https://bugreports.qt.io/browse/QTBUG-87010.

Surprisingly, the fix is not in qtbase-opensource-src-5.15.2+dfsg. I'm
not sure why, it seems like the fix was intended to land there.

I think I can work around this by probably removing parallelism in the
build process. I'll see if that works.


signature.asc
Description: PGP signature

Bug#963648: closing 963648

[Tomasz Buchert]

close 963648 1.41.0-3
thanks

Bug#937051: mininet: Python2 removal in sid/bullseye

[Tomasz Buchert]

Thanks,
upstream claims that mininet is python3-compatible in master [1].

I'll try to make the package stop using python2.

[1] https://github.com/mininet/mininet/issues/898


signature.asc
Description: PGP signature

Bug#918931: fasm: FTBFS because it build-depends on itself and the current version lacks /usr/bin/fasm

[Tomasz Buchert]

On 10/01/19 22:00, Santiago Vila wrote:
> tags 918931 + patch
> thanks
>
> Hi. This is a hack but I think it should work.
> (Rebootstrapping anything is always hacky after all).
>
> [...]

I've just sent a version reboostrapping itself. After that I will make
sure to upload it again.

Thanks,
Tomasz


signature.asc
Description: PGP signature

Bug#918936: fasm: Does not trap for errors in debian/rules

[Tomasz Buchert]

On 10/01/19 18:05, Santiago Vila wrote:
> ...

Oh, and fasm cannot be built by anything else than fasm as it is its
own dialect of assembler.


signature.asc
Description: PGP signature

Bug#918936: fasm: Does not trap for errors in debian/rules

[Tomasz Buchert]

On 10/01/19 18:05, Santiago Vila wrote:
> Package: src:fasm
> Version: 1.73.06-1
> Severity: serious
> Tags: patch
>
> Dear maintainer:
>
> Commands in a Makefile should be chained with "&&" so that the first
> thing which fails makes the whole process to stop.
>
> This is Policy 4.6, "error trapping in makefiles", and it's usually considered
> a serious issue:
>
> https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles
>
> Proposed patch below.
>
> Unfortunately, the patch will not make the package to build again and
> it needs to be "bootstrapped" again (my theory is that the package was 
> misbuilt
> the last time because of this, but I'm not completely sure).
>
> Would not be possible to build the program using the standard assembler?
> I would do that if possible, that way we could eliminate the
> build-dependency on itself.
>
> Thanks.
>
> --- a/debian/rules
> +++ b/debian/rules
> @@ -8,7 +8,7 @@ include /usr/share/dpkg/default.mk
>
>  override_dh_install:
>   mkdir -p debian/tmp
> - (cd source/libc; fasm fasm.asm; gcc $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) 
> -m32 fasm.o -o fasm)
> + cd source/libc && fasm fasm.asm && gcc $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) 
> -m32 fasm.o -o fasm
>
>  override_dh_clean:
>   dh_clean

Oh... I removed dh_install from the override in
https://salsa.debian.org/debian/fasm/commit/390c9ea515e788c5bf422fa3b5ba99a64f3caf5f.
Stupid me!

Ok, let's reboostrap the whole thing.


signature.asc
Description: PGP signature

Bug#868409: verbiste: Please drop the (build-)dependency against gnome-vfs

[Tomasz Buchert]

On 27/07/18 13:04, Nicholas D Steeves wrote:
> [...]

Hey all,
sorry for extremely long lag in fixing this...

Anyway, I went with Nicholas' suggestion and added verbiste-gtk,
whereas verbiste-gnome is now transitional. Feel free to review it:
https://salsa.debian.org/debian/verbiste

As for verbiste-el, I've created https://bugs.debian.org/905290. I'd
actually ask for help with this, I'm pretty bad at emacs
packaging. Pull requests are welcome! :D

Tomasz


signature.asc
Description: PGP signature

Bug#901952: new info

[Tomasz Buchert]

Control: reassign 901952 tar 1.30+dfsg-1

On 26/06/18 20:23, Tomasz Buchert wrote:
> On 20/06/18 21:18, Hans-Christoph Steiner wrote:
> >
> > [...]
>
> This seems to be a regression caused by tar.
>
> I can successfully checkout the tarball, but with the version tar_1.29b-2.
> When I install tar_1.30+dfsg-1, I cannot checkout anymore.
>
> I guess we'll need to find the real cause in tar then.

I believe I have a repro case extracted from this bug report showing
that #897653 was not actually fixed. It can be downloaded from:
http://ivyzdokx5queplps.onion/repro.tar.xz

It has a number of files generated with tar 1.30, with all
combinations of reproducibility related flags and none of them
reproduces the tarball produced by the version 1.29.

I'm reassigning this to tar.


signature.asc
Description: PGP signature

Bug#901952: new info

[Tomasz Buchert]

On 20/06/18 21:18, Hans-Christoph Steiner wrote:
>
> [...]

This seems to be a regression caused by tar.

I can successfully checkout the tarball, but with the version tar_1.29b-2.
When I install tar_1.30+dfsg-1, I cannot checkout anymore.

I guess we'll need to find the real cause in tar then.


signature.asc
Description: PGP signature

Bug#881328: mininet requires missing ovs-controller

[Tomasz Buchert]

On 30/11/17 09:26, Santiago R.R. wrote:
> Control: tags -1 + patch fixed-upstream
>
> On Fri, 10 Nov 2017 12:15:39 +0100 "Santiago R.R."  
> wrote:
>
> It seems I am wrong about this.

The bug was only happening if you would have
openvswitch-testcontroller installed. The reason is that mininet fails
to detect the path of the test controller. The patch you provided fixes
the issue.
>
> Cheers,
>
>   -- Santiago
>
> P.S. Question for openvswitch maintainers: does it make sense to include
> back /usr/bin/ovs-testcontroller in the -testcontroller package?

Thanks, I've added the patch and will upload the package later today.

Cheers,
Tomasz

Bug#870831: Broken symbols file creates broken dependencies

[Tomasz Buchert]

On 05/08/17 18:04, Stefan Fritsch wrote:
> Package: libbrotli0.6.0
> Version: 0.6.0-2~exp0
> Severity: serious
>
> I have tried to build apache2's mod_brotli with libbrotli0.6.0 /
> libbrotli-dev from experimental  But the resulting packages gets a
> dependency on the non-existing libbrotli0 (>= 0.6.0). I think the reason
> for this is that /var/lib/dpkg/info/libbrotli0.6.0:amd64.symbols
> contains
>
> libbrotlidec.so.0.6.0 libbrotli0 #MINVER#
>
> This should be libbrotli0.6.0 instead of libbrotli0.

Thank you, Stefan, I've upload a new experimental package at version
1.0.0, and with you fix. I think it is correct now, however I think
that the upstream SOVERSION is too granular and asked them to rethink
this. I'm relatively confident that polished brotli packages will
enter unstable in 2-3 weeks.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#872960: Actualy...

[Tomasz Buchert]

On 19/09/17 01:14, Tomasz Buchert wrote:
> [...]

I'm downgrading the priority once again. I fixed the FTBFS for now,
this bug will addressed soon (or if it cannot be addressed, synapse
will be dropped from Debian).

Tomasz


signature.asc
Description: PGP signature

Bug#872960: Re

[Tomasz Buchert]

As this is somewhat non-standard setup, I downgraded the severity to
"important".


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

Hey,

On 06/05/17 14:43, Dirk Eddelbuettel wrote:
>
> On 6 May 2017 at 20:43, Tomasz Buchert wrote:
> | On 06/05/17 19:23, Tomasz Buchert wrote:
> | > [...]
> |
> | Ok, I confirm that dlopen() is required to properly resolve some
> | symbols later: I can only assume that openmpi does some magic
> | there. Here are 2 solutions I came up with:
> |
> |   1. Just like in #741297: add another dlopen() call to the chain (see
> |  attached simple-but-wrong.debdiff)
>
> Right. That is the obvious one.
>
> |   2. Figure out what is the libmpi to load. I attach a proof-of-concept 
> that uses dl_iterate_phdr
> |  to find this out (see attached findlibmpi.debdiff).
>
> That's for upstream. I would encourage you to send that to Hao Yu explaining
> the issue. Other distro may end up with the same sonames.

But there is also the issue at hand: this RC bug. It should be fine to
patch it temporarily at least to let the package be in stable, no?

> | I've tested both approaches and they work for me.
> |
> | Btw, it would be good to add a smoke test to verify that loading from
> | R works, so that we can detect it just after build.
>
> It already does. At the end of each 'R CMD INSTALL foo' run (which what we do
> here to) the new library is loaded.
>
> But as we build, the libopenmpi-dev package is present, and then it passes
> (see my earlier messages based on poking around in a Debian unstable session
> in a Docker container).

Right, makes sense. What about https://ci.debian.net/?

> Thanks much for the patch, this really help. And I do appreciate that you
> tested it. This matters.
>
> Now, if I may: Going forward, you may want to think keeping a little bit of
> the attitude out of your posts.  Nobody asked about your personal opinions
> regarding the build system, or judgement about certain patches (which, after
> all, were also initially wrong on your end).

Nothing I wrote was intended as a personal opinion (isn't format 1.0
objectively worse than 3.0? wasn't the add-another-dlopen fix bound to
fail in the future?), but I understand that it could be read like
that. I'm sorry if I offended you.

And my patch was wrong, you caught me red-handed and I stand corrected.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

On 06/05/17 19:23, Tomasz Buchert wrote:
> [...]

Ok, I confirm that dlopen() is required to properly resolve some
symbols later: I can only assume that openmpi does some magic
there. Here are 2 solutions I came up with:

  1. Just like in #741297: add another dlopen() call to the chain (see
 attached simple-but-wrong.debdiff)

  2. Figure out what is the libmpi to load. I attach a proof-of-concept that 
uses dl_iterate_phdr
 to find this out (see attached findlibmpi.debdiff).

I've tested both approaches and they work for me.

Btw, it would be good to add a smoke test to verify that loading from
R works, so that we can detect it just after build.

Let me know what you think.
Tomasz
only in patch2:
unchanged:
--- rmpi-0.6-6.orig/src/Rmpi.c
+++ rmpi-0.6-6/src/Rmpi.c
@@ -74,7 +74,8 @@
 
 #ifndef __APPLE__
 #ifdef OPENMPI
-if (!dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
+   if (!dlopen("libmpi.so.20", RTLD_GLOBAL | RTLD_LAZY) 
+&& !dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
&& !dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
&& !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)) {
 Rprintf("%s\n",dlerror());
only in patch2:
unchanged:
--- rmpi-0.6-6.orig/src/Rmpi.c
+++ rmpi-0.6-6/src/Rmpi.c
@@ -15,10 +15,13 @@
  *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
 
+#define _GNU_SOURCE 
 #include "Rmpi.h"
 
 #ifdef OPENMPI
 #include 
+#include 
+#include 
 #endif
 
 static MPI_Comm*comm;
@@ -57,6 +60,15 @@
return AsInt(i);
 }
 
+static int 
  
+dl_iter_cb(struct dl_phdr_info *info, size_t size, void *data) 

+{  
  
+  if (strstr(info->dlpi_name, "libmpi.so") != NULL) {  
  
+*((char**)data) = strdup(info->dlpi_name); 
  
+  }
  
+  return 0;
  
+}
+
 SEXP mpi_initialize(){
int i,flag;
MPI_Initialized();
@@ -74,12 +86,19 @@
 
 #ifndef __APPLE__
 #ifdef OPENMPI
-if (!dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
-   && !dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
-   && !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)) {
+   char* mpiso = NULL;
+   dl_iterate_phdr(dl_iter_cb, );
+   if (mpiso == NULL) {
+   Rprintf("No openmpi linked.\n");
+   return AsInt(0);
+   }
+
+if (!dlopen(mpiso, RTLD_GLOBAL | RTLD_LAZY)) {
+   free(mpiso);
 Rprintf("%s\n",dlerror());
 return AsInt(0);
 }
+   free(mpiso);
 #endif
 #endif
 


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

On 06/05/17 11:58, Dirk Eddelbuettel wrote:
>
> Hi Tomasz,
>
> [...]
>
> While true for us, it is not always true for Rmpi on other system so upstream
> for Rmpi added this.  I haven't heard from him a while.
>
> But I do recall that we needed this for some other braindeadness with the
> multiple shared library -- I distinctly remember fighting this for many
> months.  The problem, really, is the need for RTLD_GLOBAL | RTLD_LAZY in
> order follow symbols into the other libraries which OpenMPI decides to split
> this over.
>
>dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY)
>

Although I don't get it, I'll try to verify that it does not break anything.

> What version 1.0?  There never was one for Rmpi.

Version 1.0 of the packaging system (orig + diff => 
https://manpages.debian.org/jessie/dpkg-dev/dpkg-source.1.en.html#SOURCE_PACKAGE_FORMATS).

>
> Dirk
>

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#861748: r-cran-rmpi: Loading library fails

[Tomasz Buchert]

On 03/05/17 17:54, Ralf Stubner wrote:
> [...]

Hi all,
this is really another iteration of #741297.


Honestly, I believe that the whole test of openmpi "existence" using
dlopen is unnecessary. This code is only executed if we have compiled
against openmpi, so why do we have to double-check that it is in the
system?  I propose to completely drop the dlopen test.

I attach a patch that does exactly that. I tried to prepare NMU, but
had a hard time with version 1.0 of this package :(.

Cheers,
Tomasz
From d4d39b7f09cfc0d2746702b417bebf0bf421b947 Mon Sep 17 00:00:00 2001
From: Tomasz Buchert <tom...@buchert.pl>
Date: Sat, 6 May 2017 17:13:41 +0200
Subject: [PATCH] Fix for #861748.

---
 ...ent-the-use-of-dlopen-for-libmpi.so-files.patch | 36 ++
 debian/patches/series  |  1 +
 2 files changed, 37 insertions(+)
 create mode 100644 debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
 create mode 100644 debian/patches/series

diff --git a/debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch b/debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
new file mode 100644
index 000..3630980
--- /dev/null
+++ b/debian/patches/0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
@@ -0,0 +1,36 @@
+From: Tomasz Buchert <tom...@buchert.pl>
+Date: Sat, 6 May 2017 17:08:38 +0200
+Subject: Comment the use of dlopen() for libmpi.so files.
+
+dlopen is used only to runtime check that rmpi is running against
+openmpi. But this code is only compiled in when openmpi is the mpi
+runtime in the system. Hence, the test is useless.
+
+The reason why it causes the import to fail is that the version of
+openmpi in stretch has changed the .so file numbering from "so.1" to
+"so.20". The previous "fix" in https://bugs.debian.org/741297 clearly
+just pushes the problem only in the future.
+---
+ src/Rmpi.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/src/Rmpi.c b/src/Rmpi.c
+index ce9a718..91c9145 100644
+--- a/src/Rmpi.c
 b/src/Rmpi.c
+@@ -74,12 +74,15 @@ if (flag)
+ 
+ #ifndef __APPLE__
+ #ifdef OPENMPI
++	/*
++	// This test is not necessary in Debian.
+ if (!dlopen("libmpi.so.1", RTLD_GLOBAL | RTLD_LAZY) 
+ 	&& !dlopen("libmpi.so.0", RTLD_GLOBAL | RTLD_LAZY)
+ 	&& !dlopen("libmpi.so", RTLD_GLOBAL | RTLD_LAZY)) {
+ Rprintf("%s\n",dlerror());
+ return AsInt(0);
+ }
++	*/
+ #endif
+ #endif
+ 
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..560da9e
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-Comment-the-use-of-dlopen-for-libmpi.so-files.patch
-- 
2.11.0



signature.asc
Description: PGP signature

Bug#861870: Requesting unblock

[Tomasz Buchert]

On 06/05/17 11:12, Balasankar C wrote:
> Hi Tomasz,
>
> GitLab package co-maintainer here. We will be uploading the fix to unstable 
> and
> requesting an unblock, hopefully by Monday. In the mean time, there is already
> an unblock request open[0] for the latest version in unstable, 
> 8.13.11+dfsg1-5.
>
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861293
>
> Regards,
> Balasankar C

Hi,
in this case I'm going to close my request in #861914, and let you
take care of it.

Tomasz


signature.asc
Description: PGP signature

Bug#851877: fails every time

[Tomasz Buchert]

On 04/05/17 04:47, Adam Borowski wrote:
> [...]

I cannot reproduce these failures. I've built in my stretch sbuild
around 15 times, and succedeed every time.

I use:
gbp buildpackage --git-builder='sbuild --source-only-changes -v -As 
--build-dep-resolver=apt --dist=stretch -j4' "$@"

Tomasz


signature.asc
Description: PGP signature

Bug#861870: gitlab: CVE-2017-8778

[Tomasz Buchert]

On 05/05/17 20:46, Tomasz Buchert wrote:
> On 05/05/17 06:19, Salvatore Bonaccorso wrote:
> > [...]
>
> Hi Salvatore,
> the fix for this issue seems to be here:
> https://gitlab.com/winniehell/gitlab-ce/commit/dd944bf14f4a0fd555db32d5833325fa459d9565
>
> I'll try to apply it to stretch's gitlab.
> Tomasz

Interestingly, the CVE has been fixed for unstable just an hour ago or so:
https://anonscm.debian.org/cgit/pkg-ruby-extras/gitlab.git/commit/?id=7241318db49ec356f31dac96345a4ff730d313f0

I've reapplied this for the stretch version and I attach the
debdiff. I'm going to request an unblock for this.

For some reason I couldn't push my branch to 
ssh://git.debian.org/git/pkg-ruby-extras/gitlab.git.
Probably I should become ruby-extras team member or something. For this reason 
I also attach
the commits from my branch.

Cheers,
Tomasz
diff -Nru gitlab-8.13.11+dfsg1/debian/changelog gitlab-8.13.11+dfsg1/debian/changelog
--- gitlab-8.13.11+dfsg1/debian/changelog	2017-04-21 12:32:25.0 +0200
+++ gitlab-8.13.11+dfsg1/debian/changelog	2017-05-05 21:23:50.0 +0200
@@ -1,3 +1,9 @@
+gitlab (8.13.11+dfsg1-4) testing-proposed-updates; urgency=medium
+
+  * Fix CVE-2017-8778
+
+ -- Tomasz Buchert <tom...@debian.org>  Fri, 05 May 2017 21:23:50 +0200
+
 gitlab (8.13.11+dfsg1-3) unstable; urgency=medium
 
   * Quote variable in test -n (Thanks to Benjamin Drung)
diff -Nru gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch
--- gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch	1970-01-01 01:00:00.0 +0100
+++ gitlab-8.13.11+dfsg1/debian/patches/cve-2017-8778.patch	2017-05-05 21:14:50.0 +0200
@@ -0,0 +1,99 @@
+From: Debian Ruby Extras Maintainers
+ <pkg-ruby-extras-maintain...@lists.alioth.debian.org>
+Date: Fri, 5 May 2017 21:00:42 +0200
+Subject: cve-2017-8778
+
+---
+ app/uploaders/file_uploader.rb  |  2 +-
+ app/uploaders/uploader_helper.rb|  8 
+ spec/controllers/uploads_controller_spec.rb | 22 ++
+ spec/factories/notes.rb |  6 +-
+ 4 files changed, 36 insertions(+), 2 deletions(-)
+
+diff --git a/app/uploaders/file_uploader.rb b/app/uploaders/file_uploader.rb
+index 3ac6030..407606a 100644
+--- a/app/uploaders/file_uploader.rb
 b/app/uploaders/file_uploader.rb
+@@ -36,7 +36,7 @@ class FileUploader < CarrierWave::Uploader::Base
+ escaped_filename = filename.gsub("]", "\\]")
+ 
+ markdown = "[#{escaped_filename}](#{self.secure_url})"
+-markdown.prepend("!") if image_or_video?
++markdown.prepend("!") if image_or_video? || dangerous?
+ 
+ {
+   alt:  filename,
+diff --git a/app/uploaders/uploader_helper.rb b/app/uploaders/uploader_helper.rb
+index b10ad71..5a9c0b7 100644
+--- a/app/uploaders/uploader_helper.rb
 b/app/uploaders/uploader_helper.rb
+@@ -7,11 +7,19 @@ module UploaderHelper
+   # on IE >= 9.
+   # http://archive.sublimevideo.info/20150912/docs.sublimevideo.net/troubleshooting.html
+   VIDEO_EXT = %w[mp4 m4v mov webm ogv]
++  # These extension types can contain dangerous code and should only be embedded inline with
++  # proper filtering. They should always be tagged as "Content-Disposition: attachment", not "inline".
++  DANGEROUS_EXT = %w[svg]
++
+ 
+   def image?
+ extension_match?(IMAGE_EXT)
+   end
+ 
++  def dangerous?
++extension_match?(DANGEROUS_EXT)
++  end
++
+   def video?
+ extension_match?(VIDEO_EXT)
+   end
+diff --git a/spec/controllers/uploads_controller_spec.rb b/spec/controllers/uploads_controller_spec.rb
+index 69124ab..8ea9c71 100644
+--- a/spec/controllers/uploads_controller_spec.rb
 b/spec/controllers/uploads_controller_spec.rb
+@@ -4,6 +4,28 @@ describe UploadsController do
+   let!(:user) { create(:user, avatar: fixture_file_upload(Rails.root + "spec/fixtures/dk.png", "image/png")) }
+ 
+   describe "GET show" do
++context 'Content-Disposition security measures' do
++  let(:project) { create(:empty_project, :public) }
++
++  context 'for PNG files' do
++it 'returns Content-Disposition: inline' do
++  note = create(:note, :with_attachment, project: project)
++  get :show, model: 'note', mounted_as: 'attachment', id: note.id, filename: 'image.png'
++
++  expect(response['Content-Disposition']).to start_with('inline;')
++end
++  end
++
++  context 'for SVG files' do
++it 'returns Content-Disposition: attachment' do
++  note = create(:note, :with_svg_attachment, project: project)
++  get :show, model: 'note', mounted_as: 'attachment', id: note.id, filename: 'image.svg'
++
++  expect(response['Content-Disposition']).to start_with('attachment;')
++end
++  end
++end
++
+ context "when viewing a user avatar&q

Bug#861870: gitlab: CVE-2017-8778

[Tomasz Buchert]

On 05/05/17 06:19, Salvatore Bonaccorso wrote:
> [...]

Hi Salvatore,
the fix for this issue seems to be here:
https://gitlab.com/winniehell/gitlab-ce/commit/dd944bf14f4a0fd555db32d5833325fa459d9565

I'll try to apply it to stretch's gitlab.
Tomasz


signature.asc
Description: PGP signature

Bug#860446: gravit segmentation violation

[Tomasz Buchert]

tags 860446 + reproducible
severity 860446 normal
thanks

On 21/04/17 01:16, Tim Retout wrote:
> retitle 860446 gravit: Segmentation violation on start (on i386?)
> tags 860446 moreinfo
> thanks
>
> For what it's worth, gravit starts for me on amd64, with intel graphics.
>
> The last call in the ltrace output is glClear... my guess is that this
> may be related to graphics drivers, if it's not architecture specific?
>
> Nils: can I check which graphics drivers you are using, in case it is
> relevant?  Meanwhile someone should try running gravit on another i386
> system...
>
> --
> Tim Retout 

I cannot reproduce this in a i386 chroot. I managed to pass my Intel GPU
inside with systemd-nspawn and everything seems to work.

I'm marking this as unreproducible and lower priority.

Tomasz


signature.asc
Description: PGP signature

Bug#857546: profanity: Server certificates are not verified

[Tomasz Buchert]

On 12/03/17 13:53, Wolfgang Wiedmeyer wrote:
> Package: profanity
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Dear Maintainer,
>
> Profanity is not built against libmesode[1]. Libmesode is a fork of
> libstrophe that allows to validate the certificate chain. Upstream bug
> #280 provides more information[2]. Libmesode doesn't seem to be packaged
> yet in Debian.
>
> If Profanity does not verify the xmpp server's certificate using
> Debian's store of known CA certificates, users' passwords, text messages
> and other sensitive information can be intercepted.
>
> Best regards,
> Wolfgang
>

Hi Wolfgang,

it seems unlikely that we will be able to fix this for stretch. This
would require a new package upload and this is already a
no-go. Personally I think that forking libstrophe in the first place
was not a great idea, but I may lack some context.

I don't know what will be the best to proceed. Maybe we can clearly
specify in the manpage/--help/during-the-first-run that profanity does
not verify cert chains and the user is responsible for providing a safe
channel, via SSH tunnel or similar, for example?

Tomasz


signature.asc
Description: PGP signature

Bug#855930: Bug#853119: Request to take a look at #855930

[Tomasz Buchert]

On 26/02/17 23:49, Vincent Danjean wrote:
> [...]
>
> And, for more info:
> $ mkdir p
> $ HOME=p lualatex lualatex-example.tex
> This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)
> [...]
> luaotfload | db : Font names database not found, generating new one.
> luaotfload | db : This can take several minutes; please be patient.(compiling 
> luc: /var/li
> b/texmf/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(compiling luc: 
> p/
> .texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc)(sa
> ve: 
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.l
> ua)(save: 
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-reg
> ular.luc)))
> [...]
> $ find p
> p
> p/.texlive2016
> p/.texlive2016/texmf-var
> p/.texlive2016/texmf-var/luatex-cache
> p/.texlive2016/texmf-var/luatex-cache/generic
> p/.texlive2016/texmf-var/luatex-cache/generic/names
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.luc
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-names.lua.gz
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-names.luc
> p/.texlive2016/texmf-var/luatex-cache/generic/names/luaotfload-lookup-cache.lua
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.luc
> p/.texlive2016/texmf-var/luatex-cache/generic/fonts/otl/lmroman10-regular.lua
> $
>
> So lulaatex seems to really use the HOME directory.
>
>   Regards,
> Vincent
>

Wow, a really nice find!

Tomasz


signature.asc
Description: PGP signature

Bug#855925: sugar-irc-activity: diff for NMU version 8-1.3

[Tomasz Buchert]

My mistake again! I included a wrong e-mail in the last upload
changelog.  Here is the right debdiff. Will upload to DELAYED/3
as soon as dcut does its job.diff -Nru sugar-irc-activity-8/debian/changelog sugar-irc-activity-8/debian/changelog
--- sugar-irc-activity-8/debian/changelog	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/changelog	2017-02-26 18:09:56.0 +0100
@@ -1,3 +1,10 @@
+sugar-irc-activity (8-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove broken deps (Closes: #855925)
+
+ -- Tomasz Buchert <tom...@debian.org>  Sun, 26 Feb 2017 18:09:56 +0100
+
 sugar-irc-activity (8-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sugar-irc-activity-8/debian/control sugar-irc-activity-8/debian/control
--- sugar-irc-activity-8/debian/control	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/control	2017-02-26 18:09:56.0 +0100
@@ -11,8 +11,8 @@
  debhelper (>= 6),
  cdbs (>= 0.4.67~),
  python (>= 2.6.6-3~),
- python-sugar-0.88 | python-sugar,
- python-sugar-toolkit-0.88 | python-sugar-toolkit,
+ python-sugar,
+ python-sugar-toolkit,
  unzip
 Standards-Version: 3.9.1.0
 Vcs-Git: git://git.debian.org/collab-maint/sugar-irc-activity.git
@@ -31,9 +31,9 @@
  Sugar has since grown into a more widely usable low-resource desktop
  environment for kids.
  .
- This Activity allows you to contact other Sugar users and enthusiasts 
- on the internet and chat with them. It uses a system called Internet 
+ This Activity allows you to contact other Sugar users and enthusiasts
+ on the internet and chat with them. It uses a system called Internet
  Relay Chat, or IRC for short. There are several IRC channels for Sugar
- users and developers. It defaults to a "room" called #sugar, but you 
- can also enter other rooms by typing /join #room where room is the  
+ users and developers. It defaults to a "room" called #sugar, but you
+ can also enter other rooms by typing /join #room where room is the
  name of the room you wish to join.

Bug#855925: sugar-irc-activity: diff for NMU version 8-1.3

[Tomasz Buchert]

Control: tags 855925 + patch
Control: tags 855925 + pending

Dear maintainer,

I've prepared an NMU for sugar-irc-activity (versioned as 8-1.3) and
uploaded it to DELAYED/3. Please feel free to tell me if I
should delay it longer.

For the context of the fix, please see https://bugs.debian.org/855932.

Regards,
Tomasz
diff -Nru sugar-irc-activity-8/debian/changelog sugar-irc-activity-8/debian/changelog
--- sugar-irc-activity-8/debian/changelog	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/changelog	2017-02-26 18:09:56.0 +0100
@@ -1,3 +1,10 @@
+sugar-irc-activity (8-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove broken deps (Closes: #855925)
+
+ -- Tomasz Buchert <tom...@buchert.pl>  Sun, 26 Feb 2017 18:09:56 +0100
+
 sugar-irc-activity (8-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sugar-irc-activity-8/debian/control sugar-irc-activity-8/debian/control
--- sugar-irc-activity-8/debian/control	2013-07-09 20:07:25.0 +0200
+++ sugar-irc-activity-8/debian/control	2017-02-26 18:09:56.0 +0100
@@ -11,8 +11,8 @@
  debhelper (>= 6),
  cdbs (>= 0.4.67~),
  python (>= 2.6.6-3~),
- python-sugar-0.88 | python-sugar,
- python-sugar-toolkit-0.88 | python-sugar-toolkit,
+ python-sugar,
+ python-sugar-toolkit,
  unzip
 Standards-Version: 3.9.1.0
 Vcs-Git: git://git.debian.org/collab-maint/sugar-irc-activity.git
@@ -31,9 +31,9 @@
  Sugar has since grown into a more widely usable low-resource desktop
  environment for kids.
  .
- This Activity allows you to contact other Sugar users and enthusiasts 
- on the internet and chat with them. It uses a system called Internet 
+ This Activity allows you to contact other Sugar users and enthusiasts
+ on the internet and chat with them. It uses a system called Internet
  Relay Chat, or IRC for short. There are several IRC channels for Sugar
- users and developers. It defaults to a "room" called #sugar, but you 
- can also enter other rooms by typing /join #room where room is the  
+ users and developers. It defaults to a "room" called #sugar, but you
+ can also enter other rooms by typing /join #room where room is the
  name of the room you wish to join.

Bug#855932: sugar-physics-activity: diff for NMU version 7+dfsg-1.3

[Tomasz Buchert]

Oh my, actually due to me building the package in stretch sbuild, it
got rejected during the upload. So now I've uploaded it to the
unstable, DELAYED/3. \o/

Tomasz


signature.asc
Description: PGP signature

Bug#855932: sugar-physics-activity: diff for NMU version 7+dfsg-1.3

[Tomasz Buchert]

Control: tags 855932 + patch
Control: tags 855932 + pending

Dear maintainer,

I've prepared an NMU for sugar-physics-activity (versioned as 7+dfsg-1.3) and
*wanted* to upload it to DELAYED/3, but since I've put it after the .changes 
file,
it got uploaded immediately. Sorry for that...

I'll ask the release team to unblock this.

Regards,
Tomasz
diff -Nru sugar-physics-activity-7+dfsg/debian/changelog sugar-physics-activity-7+dfsg/debian/changelog
--- sugar-physics-activity-7+dfsg/debian/changelog	2013-07-09 20:21:10.0 +0200
+++ sugar-physics-activity-7+dfsg/debian/changelog	2017-02-26 17:27:37.0 +0100
@@ -1,3 +1,10 @@
+sugar-physics-activity (7+dfsg-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/control: remove non-existing alternatives (Closes: #855932)
+
+ -- Tomasz Buchert <tom...@debian.org>  Sun, 26 Feb 2017 17:27:37 +0100
+
 sugar-physics-activity (7+dfsg-1.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru sugar-physics-activity-7+dfsg/debian/control sugar-physics-activity-7+dfsg/debian/control
--- sugar-physics-activity-7+dfsg/debian/control	2013-07-09 20:21:10.0 +0200
+++ sugar-physics-activity-7+dfsg/debian/control	2017-02-26 17:26:45.0 +0100
@@ -8,8 +8,8 @@
  debhelper (>= 7.0.1),
  cdbs (>= 0.4.90~),
  python (>= 2.6.6-3~),
- python-sugar-0.88 | python-sugar,
- python-sugar-toolkit-0.88 | python-sugar-toolkit,
+ python-sugar,
+ python-sugar-toolkit,
  unzip
 Standards-Version: 3.9.1
 Homepage: http://wiki.sugarlabs.org/go/Activities/Physics

Bug#855932: sugar-physics-activity: FTBFS: unsatisfiable build-dependencies: python-sugar-0.88, python-sugar-toolkit-0.88

[Tomasz Buchert]

On 26/02/17 17:02, Sascha Steinbiss wrote:
> [...]

I can reproduce this with my sbuild config. Note that according to
"man sbuild" the default dep-resolver is "apt" which always takes the
first alternative. I can build successfully with
"--build-dep-resolver=aptitude", just like Sascha did.

The best solution is to simply remove the first alternative that is
causing troubles and we are good to go. Let me prepare an NMU.

Tomasz


signature.asc
Description: PGP signature

Bug#853119: Request to take a look at #855930

[Tomasz Buchert]

On 26/02/17 10:25, Norbert Preining wrote:
> On Sun, 26 Feb 2017, Norbert Preining wrote:
> > I will try to run it in a clean cowbuilder with only the build-deps
> > installed and see what might be the reason.

Thanks for looking into it.
Let's also move the discussion to #855930 :).

> Just done this, too, worked without a hinch:
> 'lualatex' '--interaction' 'errorstopmode' '--jobname' 'lualatex-example' 
> '\RequirePackage[extension=.pdf]{texdepends}\input{lualatex-example.tex}'
> [...]

However, if you build w sbuild, this seems to fail. Can it be some
failure in how tex packages are installed? Sbuild may create a very
minimal environment that exposes this problem.

> One idea: is /var writable???

I'm afraid I don't understand this. Can you elaborate?

> Norbert

Thanks,
Tomasz


signature.asc
Description: PGP signature

Bug#854735: profanity: diff for NMU version 0.4.7-1.1

[Tomasz Buchert]

Package: profanity
Version: 0.4.7-1
Severity: normal
Tags: patch pending

Dear maintainer and release team,

I've prepared an NMU for profanity (versioned as 0.4.7-1.1).
As a newer version is already in unstable, this targets
"testing-proposed-updates".

Regards,
Tomaszdiff -Nru profanity-0.4.7/debian/changelog profanity-0.4.7/debian/changelog
--- profanity-0.4.7/debian/changelog	2015-09-26 16:47:33.0 +0200
+++ profanity-0.4.7/debian/changelog	2017-02-25 18:29:37.0 +0100
@@ -1,3 +1,10 @@
+profanity (0.4.7-1.1) testing-proposed-updates; urgency=medium
+
+  * Non-maintainer upload
+  * Fix CVE-2017-5592
+
+ -- Tomasz Buchert <tom...@debian.org>  Sat, 25 Feb 2017 18:29:37 +0100
+
 profanity (0.4.7-1) unstable; urgency=medium
 
   * Imported Upstream version 0.4.7
@@ -43,4 +50,3 @@
   * Initial release (Closes: #745872)
 
  -- Dariusz Dwornikowski <dariusz.dwornikow...@cs.put.poznan.pl>  Wed, 27 Aug 2014 12:34:59 +0200
-
diff -Nru profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch
--- profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch	1970-01-01 01:00:00.0 +0100
+++ profanity-0.4.7/debian/patches/0002-Import-the-patch-fixing-CVE-2017-5592.patch	2017-02-25 18:29:37.0 +0100
@@ -0,0 +1,41 @@
+From: Tomasz Buchert <tom...@buchert.pl>
+Date: Sat, 25 Feb 2017 17:01:33 +0100
+Subject: Import the patch fixing CVE-2017-5592.
+
+The patch was provided by the upstream author.
+---
+ src/xmpp/message.c   | 7 +++
+ tests/functionaltests/test_carbons.c | 2 +-
+ 2 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/src/xmpp/message.c b/src/xmpp/message.c
+index 5581521..f6bb864 100644
+--- a/src/xmpp/message.c
 b/src/xmpp/message.c
+@@ -687,6 +687,13 @@ _handle_carbons(xmpp_stanza_t * const stanza)
+ return FALSE;
+ }
+ 
++Jid *my_jid = jid_create(jabber_get_fulljid());
++const char *const stanza_from = xmpp_stanza_get_attribute(stanza, STANZA_ATTR_FROM);
++if (g_strcmp0(my_jid->barejid, stanza_from) != 0) {
++log_warning("Invalid carbon received, from: %s", stanza_from);
++return TRUE;
++}
++
+ char *name = xmpp_stanza_get_name(carbons);
+ if ((g_strcmp0(name, "received") == 0) || (g_strcmp0(name, "sent")) == 0) {
+ xmpp_stanza_t *forwarded = xmpp_stanza_get_child_by_ns(carbons, STANZA_NS_FORWARD);
+diff --git a/tests/functionaltests/test_carbons.c b/tests/functionaltests/test_carbons.c
+index 96639d6..3bbe65d 100644
+--- a/tests/functionaltests/test_carbons.c
 b/tests/functionaltests/test_carbons.c
+@@ -70,7 +70,7 @@ receive_carbon(void **state)
+ prof_output_exact("unencrypted");
+ 
+ stbbr_send(
+-""
++""
+ ""
+ ""
+ ""
diff -Nru profanity-0.4.7/debian/patches/fix_spelling_error profanity-0.4.7/debian/patches/fix_spelling_error
--- profanity-0.4.7/debian/patches/fix_spelling_error	2015-09-26 16:47:33.0 +0200
+++ profanity-0.4.7/debian/patches/fix_spelling_error	2017-02-25 18:29:37.0 +0100
@@ -1,10 +1,16 @@
-Author: Dariusz Dwornikowski <dariusz.dwornikow...@cs.put.poznan.pl> 
+From: Dariusz Dwornikowski <dariusz.dwornikow...@cs.put.poznan.pl>
+Date: Sat, 25 Feb 2017 17:03:17 +0100
 Subject: Fix spelling errors
-Last-Update: 2015-09-25
-Forwarded: not-needed
+
+---
+ src/xmpp/iq.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/xmpp/iq.c b/src/xmpp/iq.c
+index 496e9ca..6466eb5 100644
 --- a/src/xmpp/iq.c
 +++ b/src/xmpp/iq.c
-@@ -861,13 +861,13 @@
+@@ -861,13 +861,13 @@ _version_result_handler(xmpp_conn_t * const conn, xmpp_stanza_t * const stanza,
  
  xmpp_stanza_t *query = xmpp_stanza_get_child_by_name(stanza, STANZA_NAME_QUERY);
  if (query == NULL) {
diff -Nru profanity-0.4.7/debian/patches/series profanity-0.4.7/debian/patches/series
--- profanity-0.4.7/debian/patches/series	2015-09-26 16:47:33.0 +0200
+++ profanity-0.4.7/debian/patches/series	2017-02-25 18:29:37.0 +0100
@@ -1 +1,2 @@
 fix_spelling_error
+0002-Import-the-patch-fixing-CVE-2017-5592.patch

Bug#854735: :D

[Tomasz Buchert]

Also, by signing this message I ack that the previous message was from
me.

Tomasz


signature.asc
Description: PGP signature

Bug#853119: Request to take a look at #855930

[Tomasz Buchert]

Hi Norbert,
can I ask you to take a look at https://bugs.debian.org/855930, to see
if it is some variation of the problem in this bug?

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#854735: CVE-2017-5592

[Tomasz Buchert]

On 10/02/17 00:05, Moritz Muehlenhoff wrote:
> Package: profanity
> Severity: grave
> Tags: security
>
> Please see http://seclists.org/oss-sec/2017/q1/373
>
> Cheers,
> Moritz

I've applied a patch provided by the upstream author in
https://anonscm.debian.org/git/collab-maint/profanity.git/commit/?h=cve-2017-5592,
and contacted him to make sure that I did it correctly.

Will create an NMU when confirmed.

Tomasz


signature.asc
Description: PGP signature

Bug#855920: Marking as unreproducible

[Tomasz Buchert]

tags 855920 +unreproducible
thanks

I've run the build 10 times and it succeeded every time. The original
report is probably due to some flakinesss. Marking as unreproducible.


signature.asc
Description: PGP signature

Bug#855930: latex-make: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[Tomasz Buchert]

Initial investigation points to something similar to 
https://bugs.debian.org/853119.
Investigating further.


signature.asc
Description: PGP signature

Bug#850352: pristine-tar: perl errors, badly broken

[Tomasz Buchert]

> gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not found at 
> '../tarballs'

I cannot reproduce your problem.

I was able to successfully checkout texlive-bin_2016.20160513.41080.orig.tar.xz 
from
the textlive-bin repository using pristine-tar manually:

pristine-tar checkout ../texlive-bin_2016.20160513.41080.orig.tar.xz

and also via "gbp buildpackage -us -uc -rfakeroot" (I attach logs up to 
pristine-tar
invocation obtained with --git-verbose passed to gbp).

Please run gbp with --git-verbose and let me take a look.

Tomasz
gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: /bin/true [] []
gbp:debug: ['git', 'status', '--porcelain']
gbp:debug: ['git', 'symbolic-ref', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/master']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'HEAD']
gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'log', '--pretty=format:%H', '--grep=pristine-tar .* 
texlive-bin_2016.20160513.41080\\.orig.tar\\.', 'pristine-tar', '--']
gbp:debug: Found pristine-tar commit at 
'f89512d166e36a1d726b47f8fd891c4490e96b78'
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 
'f89512d166e36a1d726b47f8fd891c4490e96b78^0']
gbp:debug: ['git', 'show', 
'--pretty=format:%an%x00%ae%x00%ad%x00%cn%x00%ce%x00%cd%x00%s%x00%f%x00%b%x00', 
'-z', '--date=raw', '--no-renames', '--name-status', 
'f89512d166e36a1d726b47f8fd891c4490e96b78']
gbp:debug: Determined compression type 'xz'
gbp:debug: Looking for orig tarballs 
'texlive-bin_2016.20160513.41080.orig.tar.xz' at '../tarballs'
gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not found at 
'../tarballs'
gbp:debug: ['git', 'show-ref', 'refs/heads/pristine-tar']
gbp:debug: /usr/bin/pristine-tar [] ['checkout', 
'/tmp/xxx/texlive-bin_2016.20160513.41080.orig.tar.xz']


signature.asc
Description: PGP signature

Bug#850352: pristine-tar: perl errors, badly broken

[Tomasz Buchert]

On 06/01/17 11:48, Norbert Preining wrote:
> Package: pristine-tar
> Version: 1.37
> Severity: grave
> Justification: renders package unusable
> 
> HI all,
> 
> pristine-tar is somehow broken, to put it friendly:
> $ gbp buildpackage -us -uc -rfakeroot
> gbp:info: Tarballs 'texlive-bin_2016.20160513.41080.orig.tar.xz' not found at 
> '../tarballs'
> gbp:error: Pristine-tar couldn't checkout 
> "texlive-bin_2016.20160513.41080.orig.tar.xz": Use of uninitialized value 
> $tarball in -e at /usr/bin/pristine-tar line 441.
> Use of uninitialized value $_[0] in substitution (s///) at 
> /usr/share/perl/5.24/File/Basename.pm line 180.
> fileparse(): need a valid pathname at /usr/bin/pristine-tar line 450.
> pristine-tar: failed to generate tarball
> $
> 
> But the files are in the pristine-tar branch
> $ git checkout pristine-tar
> $ ls texlive-bin_2016.20160513.41080*
> texlive-bin_2016.20160513.41080.orig.tar.xz.delta  
> texlive-bin_2016.20160513.41080.orig.tar.xz.id
> $
> 
> Thanks

Hi Norbert,
I assume the repo in question is 
https://anonscm.debian.org/cgit/debian-tex/texlive-bin.git.
I'm in the process of getting it and will try myself. But a few questions 
before:

  * can you run with -d/-v to get executed commands?
  * when did you notice the problem? the last upload was made in september so I 
wonder
how come we only see it now

In the meantime, I'll try to reproduce myself.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#838974: Gentle ping

[Tomasz Buchert]

Hey,
any news on this? The missing python-3to2 package, caused
python-guess-language to be removed.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#828800: verbiste: FTBFS in testing (Only can be included directly)

[Tomasz Buchert]

On 26/11/16 20:49, Sébastien Villemot wrote:
> Control: tags -1 + patch pending
> 
> Le jeudi 24 novembre 2016 à 11:30 +0100, Sébastien Villemot a écrit :
> > Le mardi 28 juin 2016 à 02:46 +0200, Tomasz Buchert a écrit :
> > > On 27/06/16 23:52, Santiago Vila wrote:
> > > > Package: src:verbiste
> > > > Version: 0.1.43-1
> > > > User: reproducible-bui...@lists.alioth.debian.org
> > > > Usertags: ftbfs
> > > > Severity: serious
> > > > 
> > > > Dear maintainer:
> > > > 
> > > > This package currently fails to build in stretch:
> > > This bug is related to gtk2 vs. gtk3 API. I'll work on it during
> > > debconf.
> > 
> > Any news on this? There is not much time left to fix it if we want
> > verbiste to be part of stretch (it has been removed from testing, and
> > it
> > must be back there before Jan 5).
> > 
> > If you think this is the right solution, I can do an NMU where the
> > MATE
> > applet is removed.
> 
> I have uploaded to DELAYED/5 a NMU that fixes this issue, by removing
> the MATE applet. The debdiff is attached. Don't hesitate to tell me if
> you disagree with this NMU.
> 
> Best,
> 

Hi Sébastien,
thank you for this patch. However, as there was a new version of verbiste
published, I've just uploaded the new package with your patch. I'm not sure
you have to remove the package from DELAYED, but please try :).

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#835586: pristine-tar: fails to extract tarball

[Tomasz Buchert]

On 27/08/16 09:33, Mattia Rizzolo wrote:
> package: pristine-tar
> version: 1.35
> severity: grave
> 
> dunno what or why (and I don't understand the error message), but with
> the git repo at alioth.debian.org:/git/pkg-javascript/node-esprima.git
> 
> mattia@chase ..l/RFS/0_DONE/node-esprima/node-esprima (git)-[master] % 
> pristine-tar checkout ../node-esprima_2.7.3+ds.orig.tar.gz
> xdelta: warning: expected uncompressed from file 
> (/tmp/pristine-tar.AwVesN57Wr/node-esprima_2.7.3+ds.orig.tar.gz.tmp.gz)
> xdelta: expected from file 
> (/tmp/pristine-tar.AwVesN57Wr/node-esprima_2.7.3+ds.orig.tar.gz.tmp.gz) of 
> uncompressed length 299006 bytes
> xdelta patch failed! at /usr/share/perl5/Pristine/Tar/DeltaTools.pm line 28.
> pristine-tar: command failed: pristine-gz --no-verbose --no-debug --no-keep 
> gengz /tmp/pristine-tar.DO5NFbnidj/wrapper 
> /tmp/pristine-tar.19oVOimtvi/node-esprima_2.7.3+ds.orig.tar.gz.tmp
> pristine-tar: failed to generate tarball
> 
> root@chase ~ # apt install pristine-tar=1.34
> ...
> dpkg: warning: downgrading pristine-tar from 1.35 to 1.34
> ...
> 
> mattia@chase ..l/RFS/0_DONE/node-esprima/node-esprima (git)-[master] % 
> pristine-tar checkout ../node-esprima_2.7.3+ds.orig.tar.gz
> pristine-tar: successfully generated ../node-esprima_2.7.3+ds.orig.tar.gz

Hi Mattia,
I found the culprit, thanks for reporting, the new version is being uploaded as 
we speak.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#828800: dropping severity to give me some more time

[Tomasz Buchert]

On 26/07/16 09:07, Julien Cristau wrote:
> Control: severity -1 serious
> 
> On Tue, Jul 26, 2016 at 09:00:50 +0200, Tomasz Buchert wrote:
> 
> > severity 828800 normal
> > thanks
> > 
> > I'm dropping this severity to give me more time to resolve it.
> > 
> Eh, no, FTBFS is serious, just because you didn't have time to fix it
> yet doesn't make it less of an issue.
> 
> Cheers,
> Julien

Hi Julien,
I indeed had my doubts.

This bug is trivial to fix by dropping one of the binary packages. It
seems a bit dramatic to remove the whole source package, because I
need to fix only one binary package (and I didn't have time to do
that).

Tomasz


signature.asc
Description: PGP signature

Bug#828800: dropping severity to give me some more time

[Tomasz Buchert]

severity 828800 normal
thanks

I'm dropping this severity to give me more time to resolve it.

Tomasz


signature.asc
Description: PGP signature

Bug#828800: verbiste: FTBFS in testing (Only can be included directly)

[Tomasz Buchert]

On 27/06/16 23:52, Santiago Vila wrote:
> Package: src:verbiste
> Version: 0.1.43-1
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> Severity: serious
> 
> Dear maintainer:
> 
> This package currently fails to build in stretch:

Hi Santiago,
correct. I was investigating this recently.

> 
> 
> [...]
> In file included from ../../src/gtk/main-window.h:26:0,
>  from panel-applet.cpp:23:
> /usr/include/gtk-3.0/gtk/gtkentry.h:34:2: error: #error "Only  can 
> be included directly."
>  #error "Only  can be included directly."
>   ^
> 
> 
> I discovered this by checking for "dpkg-buildpackage -A", but it also
> fails without -A, as shown here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/verbiste.html
> 
> Note 1: The build log from reproducible builds for unstable matches
> the error I got in testing. The build log from reproducible builds for
> testing is completely different, but that would be another bug, not
> this one.
> 
> Note 2: In case this is a bug in a header file (i.e. a -dev package),
> please use "affects" after "reassign", so that this bug is still shown
> in the web page for verbiste (this should help people to avoid filing
> duplicate bugs).
> 
> Thanks.
> 

This bug is related to gtk2 vs. gtk3 API. I'll work on it during debconf.

Tomasz


signature.asc
Description: PGP signature

Bug#815742: verbiste: why verbiste is removed from testing ???

[Tomasz Buchert]

On 24/03/16 20:05, gpe92 wrote:
> Package: verbiste
> Followup-For: Bug #815742
> 
> Dear Maintainer,

Hi gpe92,

> Why did you removed verbiste from testing due to this bug which is
> resolved ???

Well, it was *autoremoved*, I didn't do anything. I also was mostly
offline for the last two weeks and so I couldn't react.

That said, it seems that the reason of the removal is that 0.1.42-3 didn't
migrate to testing for a weird reason that is that there is a build
missing on amd64. It stopped the migration which would replaced the buggy
version in testing.

It never happened to me before, I don't know why this build is missing.
I shall contact responsible people.

However, I've just uploaded a new version (0.1.43-1) which will hopefully
build everywhere and migrate accordingly to testing in 5 days.

Cheers,
Tomasz

> 
> BR.
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing-updates
>   APT policy: (500, 'testing-updates'), (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages verbiste depends on:
> ii  libc62.22-3
> ii  libgcc1  1:5.3.1-12
> ii  libstdc++6   5.3.1-12
> ii  libverbiste-0.1-0v5  0.1.42-2
> ii  libxml2  2.9.3+dfsg1-1
> 
> verbiste recommends no packages.
> 
> verbiste suggests no packages.
> 
> -- no debconf information
> 


signature.asc
Description: PGP signature

Bug#817233: ODP: Bug#817233: CVE-2016-1968

[Tomasz Buchert]

Hi guys,
I'm out of town and cannot work on this. NMUs welcome. :D

Tomasz


Wysłane z telefonu Samsung

Salvatore Bonaccorso  pisze:

null

Bug#815742: verbiste: diff for NMU version 0.1.42-2.1

[Tomasz Buchert]

On 03/03/16 08:23, Raúl Benencia wrote:
> Hi Tomasz,
> 
> On Thu, Mar 03, 2016 at 10:42:32AM +0100, Tomasz Buchert wrote:
> > thank you very much for this! Can you explain what the problem is? I
> > didn't have time to work on this recently. I'll upload the new version soon.
> 
> I'm glad to help! The patch it's pretty simple. The following test started
> failing recently:
> 
>   test "`echo asseoir | $(LU) ./french-conjugator | grep asseyerai,`" = 
> "assiérai, asseyerai, assoirai"
> 
> So, why did it started failing just now and no before? I did some research
> and the guilty turned out to be an update in the grep package, as it
> slightly changed its behaviour. With the new update, grep will detect the
> input as binary if it's in a different locale than the one it's currently
> running in. When this happens, grep will just output "binary file matches"
> instead of the line that matches the pattern, provoking a failure in the
> test.
> 
> Now, if you see the build log, the environment variable LU expands to
> LIBDATADIR=../../data LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8. That means, that
> no matter what, french-conjugator will produce its stdout with that
> encoding. So grep have to use the same encoding, and that's why I set up
> those variables in the override. Now, we can't assume that the encoding is
> installed on the build machine, so that's why I generate the locale. Piece
> of cake!
> 
> Cheers,
> Rul

Wow, this is surpring how they changed grep! Ok, I'm uploading this.

Tomasz


signature.asc
Description: PGP signature

Bug#815742: verbiste: diff for NMU version 0.1.42-2.1

[Tomasz Buchert]

On 02/03/16 08:05, Raúl Benencia wrote:
> Control: tags 815742 + patch
> Control: tags 815742 + pending
> 
> Dear Tomasz,
> 
> I've prepared an NMU for verbiste (versioned as 0.1.42-2.1). As I don't
> have privileges to upload it to DELAYED, I've uploaded it to the mentors
> repository.
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/verbiste
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> http://mentors.debian.net/debian/pool/main/v/verbiste/verbiste_0.1.42-2.1.dsc
> 
> Regards,
> Rul

Hi Raúl,
thank you very much for this! Can you explain what the problem is? I
didn't have time to work on this recently. I'll upload the new version soon.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#814366: verbiste: commande introuvable

[Tomasz Buchert]

On 10/02/16 21:52, KroaX wrote:
> Package: verbiste
> Version: 0.1.42-2
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> après installation du paquet verbiste depuis l'installateur de paquets 
> synaptic, 
> point d'entrée dans le menu des applications de kde, la barre de recherche du 
> même
> menu ne trouve pas l'application.
> l'installation ne renvoie aucun message d'erreur.
> la lecture des informations d'installation du paquet parle cependant de 
> paquets python-gtk2
> et python-glade2 qui seraient manquants.
> l'installation de ces derniers ne résoud pas le problème.
> 
> dans un terminal, la commande verbiste renvoie commande introuvable.

Dear KroaX,
c'est mieux si tu écris en anglais; sinon les autres auront plus
de difficulté à comprendre ton problème.

Anyway, the problem here is that you must install verbiste-gnome which
provides the graphical verbiste application. I agree that this is not
the best name for the package, but this is historical.

We may consider changing this for the stretch release,
but for now I close this bug.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#814339: nghttp2: missing build-dependency on python-sphinxcontrib.rubydomain

[Tomasz Buchert]

Control: serverity -1 normal

On 10/02/16 15:48, Benjamin Sonntag wrote:
> Package: nghttp2
> Version: 1.7.0-1
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear Maintainer,
> 
> Trying to compile nghttp2 from stretch source on a jessie server, I found a 
> missing build-dependency for nghttp2 in stretch:
> Your package has a
>  Build-Depends-Indep: python-sphinx
> line, but is missing a
>  Build-Depends-Indep: python-sphinxcontrib.rubydomain

Hi Benjamin,

unfortunately you cannot (generally speaking) expect to be able to
build new versions of nghttp2 on jessie.  The first thing to notice is
that python-sphinxcontrib.rubydomain is not available there at all, so
your fix will not work there. On the other hand, the package builds
completely fine in testing and unstable.

I'm therefore changing the severity to normal, but I'm not closing
this bug yet. I want to understand what you want to achieve. Could you
elaborate? If you don't care about docs you may use:

   debuild -G -us -uc

(you will have to remove libspdylay-dev from Build-Depends too).

At some point I was considering backporting nghttp2 to jessie-backports.
If there is interest, I can do it.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#803568: [Debian-astro-maintainers] Bug#803568: stellarium: FTBFS: StelSkyCultureMgr.hpp:47:1: error: expected class-name before '{' token

[Tomasz Buchert]

On 31/10/15 19:16, Alexander Wolf wrote:
> [...]

Hi guys,
sorry, but I didn't get the notification for this bug.
I'll try to upload 0.14.0 today.

Tomasz


signature.asc
Description: PGP signature

Bug#802354: Help needed: Bug#802354: python-matplotlib-venn: FTBFS: AttributeError: can't set attribute

[Tomasz Buchert]

On 22/10/15 20:49, Andreas Tille wrote:
> Hi,
>
> I have no idea why this package now fails to build but was building
> before.  No helpful response from debian-python list so far.  I opened
> an issue at Github but upstream needs time to reproduce and I hope that
> this might be a know issue to others here on this list.
>
> Any hint would be welcome
>
>  Andreas.
>

Hi Andreas,
this is due to [1]. It seems that 'test_args' is a property.
I didn't dig very deep, but the attached patch seems to fix this.

Cheers,
Tomasz

[1] 
https://bitbucket.org/pypa/setuptools/commits/cf565b66b855dd4df189b679206f9fb113681737
From: Tomasz Buchert <tom...@buchert.pl>
Date: Fri, 23 Oct 2015 01:37:33 +0200
Subject: test

---
 setup.py | 4 
 1 file changed, 4 deletions(-)

diff --git a/setup.py b/setup.py
index 2e57cf8..8d04c3a 100644
--- a/setup.py
+++ b/setup.py
@@ -16,10 +16,6 @@ from setuptools.command.test import test as TestCommand
 
 
 class PyTest(TestCommand):
-def finalize_options(self):
-TestCommand.finalize_options(self)
-self.test_args = []
-self.test_suite = True
 
 def run_tests(self):
 import sys


signature.asc
Description: PGP signature

Bug#798598: NMU version

[Tomasz Buchert]

I'll only add that I've made a mistake of not resetting the NMU suffix
to 0.1 with the new upstream version. It would be nice to have lintian
report this.

Tomasz


signature.asc
Description: Digital signature

Bug#798598: nghttp2: Hangs in init script upon package upgrade, causing the package manager to not continue

[Tomasz Buchert]

The trivial fix has been merged upstream:
https://github.com/tatsuhiro-t/nghttp2/pull/350

Expect a new upload soon.
Tomasz


signature.asc
Description: Digital signature

Bug#798598: nghttp2: Hangs in init script upon package upgrade, causing the package manager to not continue

[Tomasz Buchert]

On 10/09/15 23:32, Axel Beckert wrote:
> Package: nghttp2
> Severity: grave
> Version: 1.3.0-0.2
>
> Upgrading nghttp2 from 0.6.7-1+b1 to 1.3.0-0.2 hangs in the package's
> maintainer script indefinitely when starting the service:
>

Hi Axel,

> Setting up nghttp2 (1.3.0-0.2) ...
> Installing new version of config file /etc/logrotate.d/nghttpx ...
> Installing new version of config file /etc/nghttpx/nghttpx.conf ...
> 10/Sep/2015:09:33:24 +0200 PID9544 [NOTICE] Listening on 127.0.0.1, port 3000
>
> Ctrl-C doesn't help at that point.

Ouch!
I think that DEAMON_ARGS misses '-D' switch to start as a daemon.
I'll debug it during the weekend.

> (And yes, the system is running sysvinit as init system. libnghttp2-5
> was still installed afterwards as it had lost its autoinstalled flag
> somewhen.)

For me, both sysv and systemd should work :).

Thanks for this bug report!
Tomasz


signature.asc
Description: Digital signature

Bug#794729: [u...@debian.org: Bug#794729: libdivsufsort-dev: missing dependency on libdivsufsort3]

[Tomasz Buchert]

On 06/08/15 09:20, Fabian Klötzl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 On 06.08.2015 08:32, Andreas Tille wrote:
  Hi Fabian,
 
  I hope you read the mailing list
  debian-med-packag...@lists.alioth.debian.org or at least have
  subscribed this package in the Debian Package Tracker.  If not
  please do either of one to receive the bug reports of your
  package.

 Done.

  BTW, using d-shlibs would prevent such kind of problems.  You can
  find an example usage for instance here:
 
  git://anonscm.debian.org/debian-med/libmems.git

 Ok, I will have a look at it.

Hi,
I didn't know about d-shlibs! Nice. In my packaging branch [1] I
attack multi-arch by patching upstream. I don't know yet which
solution I like the most. I'll leave it to Fabian.

(wrt libmems = shouldn't you declare Multi-Arch: same + Pre-Depends?)


 Also, I included Thomasz in the conversation, as he is also interested
 in packaging libdivsufsort and has already committed some patches
 (which may or may not already fix the issue).

My packaging branch has also this bug + section problem (but my
parallel collab-maint repo is ok :D ). I've pushed two more commits to
packaging-merge.


 Fabian


Cheers,
Tomasz

[1] 
http://anonscm.debian.org/cgit/debian-med/libdivsufsort.git/log/?h=packaging-merge


signature.asc
Description: Digital signature

Bug#793010: pax-utils: FTBFS on mipsel: FAIL: lddtree.py.list

[Tomasz Buchert]

Let's give the upstream authors 1-2 days to respond.

Tomasz


signature.asc
Description: Digital signature

Bug#793010: pax-utils: FTBFS on mipsel: FAIL: lddtree.py.list

[Tomasz Buchert]

On 28/07/15 11:53, Arturo Borrero Gonzalez wrote:
 On 27 July 2015 at 16:44, Tomasz Buchert tom...@debian.org wrote:
  On 24/07/15 14:49, Tomasz Buchert wrote:
  [...]
 
* you should confirm that python-pyelftools ignore dynamic linker
  configuration (I suspect this is true); it would be good to
  extract a minimal Python program using pyelftools that shows this
 
 
  I take it back, maybe pyelftools do not parse ld.so.conf, but lddtree.py
  in pax-utils *does* parse it. It must be something else then.
 

 Ok,

 Could you please point me to the upstream bug tracker?

 --
 Arturo Borrero González


I'm not sure there is such a thing, but the upstream authors have been
very reponsive. Btw, I may have found the problem, I attach a patch,
which has been sent to upstream authors. It passes all tests, but may
break something that I'm ignorant about.

Tomasz
From d2d08a5c7e5b82f426d16a5d241fb2780bff884a Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tom...@debian.org
Date: Tue, 28 Jul 2015 13:09:27 +0200
Subject: [PATCH] Don't add interpreter into libs cache.

There is not guarantee that the path of interpreter is in ld.so.conf
paths, so it is incorrect to prepopulate it in the libs cache.

Another problem solved here is the order of files included via globs in
/etc/ld.so.conf. These files should be ordered alphabetically (see
glob(3) used by ldconfig), but it was not the case in lddtree.py.
---
 lddtree.py | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/lddtree.py b/lddtree.py
index 9330295..d76bee4 100755
--- a/lddtree.py
+++ b/lddtree.py
@@ -233,7 +233,7 @@ def ParseLdSoConf(ldso_conf, root='/', debug=False, _first=True):
   else:
 line = os.path.dirname(ldso_conf) + '/' + line
   dbg(debug, '%s  glob: %s' % (dbg_pfx, line))
-  for path in glob.glob(line):
+  for path in sorted(glob.glob(line)):
 paths += ParseLdSoConf(path, root=root, debug=debug, _first=False)
 else:
   paths += [normpath(root + line)]
@@ -282,7 +282,6 @@ def LoadLdpaths(root='/', prefix='', debug=False):
   # Load up /etc/ld.so.conf.
   ldpaths['conf'] = ParseLdSoConf(root + prefix + '/etc/ld.so.conf', root=root,
   debug=debug)
-
   return ldpaths
 
 
@@ -402,11 +401,12 @@ def ParseELF(path, root='/', prefix='', ldpaths={'conf':[], 'env':[], 'interp':[
 dbg(debug, '  interp   =', interp)
 ret['interp'] = normpath(root + interp)
 real_interp = readlink(ret['interp'], root, prefixed=True)
-ret['libs'][os.path.basename(interp)] = {
-'path': ret['interp'],
-'realpath': real_interp,
-'needed': [],
-}
+
+# ret['libs'][os.path.basename(interp)] = {
+# 'path': ret['interp'],
+# 'realpath': real_interp,
+# 'needed': [],
+# }
 # XXX: Could read it and scan for /lib paths.
 # If the interp is a symlink, lets follow it on the assumption that it
 # is in this path purely for ABI reasons, and the distro is using a
-- 
2.4.6



signature.asc
Description: Digital signature

Bug#793010: pax-utils: FTBFS on mipsel: FAIL: lddtree.py.list

[Tomasz Buchert]

On 24/07/15 14:49, Tomasz Buchert wrote:
 [...]

   * you should confirm that python-pyelftools ignore dynamic linker
 configuration (I suspect this is true); it would be good to
 extract a minimal Python program using pyelftools that shows this


I take it back, maybe pyelftools do not parse ld.so.conf, but lddtree.py
in pax-utils *does* parse it. It must be something else then.

Tomasz


signature.asc
Description: Digital signature

Bug#793010: pax-utils: FTBFS on mipsel: FAIL: lddtree.py.list

[Tomasz Buchert]

On 23/07/15 20:07, Arturo Borrero Gonzalez wrote:
 On 20 July 2015 at 15:08, Tomasz Buchert tom...@debian.org wrote:
 
  Well, upstream is already working on this. In fact, the test above
  passes in the new version (which I've just pushed to collab-maint),
  but the next one fails. You may try to pinpoint the problem, but it is
  very likely the fact that python-pyelftools do not follow /etc/ld.conf
  configuration.
 

 Well, then how would you recommend me to approach a fix?
 Perhaps opening an issue in python-pyelftools upstream would do the trick.

 --
 Arturo Borrero González


Hi Arturo,
if you are interested in tackling this, I would proceed like this

  * you should confirm that python-pyelftools ignore dynamic linker
configuration (I suspect this is true); it would be good to
extract a minimal Python program using pyelftools that shows this

  * if it is true, then a bug report is justified; however, the
upstream may consider this to be be due to Debian multi-arch, and
be reluctant to fix it

I don't have much time for this bug right now, and although it is RC,
I don't see it as such. If required, the test suite may be turned off.

Cheers,
Tomasz


signature.asc
Description: Digital signature

Bug#793010: pax-utils: FTBFS on mipsel: FAIL: lddtree.py.list

[Tomasz Buchert]

On 20/07/15 14:44, Arturo Borrero Gonzalez wrote:
 Package: pax-utils
 Severity: serious
 Justification: fails to build from source (but built successfully in the past)

 Dear maintainer,

 as you can see at buildd [0], pax-utils FTBFS on mipsel.

 The final part of the log is:

 [...]
 ../dotest.cmp
 FAIL: lddtree.py.list
 --- lddtree.py.list   2015-07-19 20:27:49.035987607 +
 +++ lddtree.sh.list   2015-07-19 20:27:48.667985305 +
 @@ -4,4 +4,4 @@
  /lib/mipsel-linux-gnu/libtinfo.so.5
  /lib/mipsel-linux-gnu/libdl.so.2
  /lib/mipsel-linux-gnu/libc.so.6
 -/lib/ld.so.1
 +/lib/mipsel-linux-gnu/ld.so.1
 make[4]: *** [cmp.check] Error 1
 Makefile:4: recipe for target 'cmp.check' failed
 make[3]: *** [lddtree_check_] Error 2
 make[4]: Leaving directory '/«PKGBUILDDIR»/tests/lddtree'
 Makefile:8: recipe for target 'lddtree_check_' failed
 make[2]: *** [check] Error 2
 make[3]: Leaving directory '/«PKGBUILDDIR»/tests'
 Makefile:4: recipe for target 'check' failed
 make[1]: *** [check-hook] Error 2
 make[2]: Leaving directory '/«PKGBUILDDIR»/tests'
 Makefile:2219: recipe for target 'check-hook' failed
 make[1]: Leaving directory '/«PKGBUILDDIR»'
 dh_auto_test: make -j1 check returned exit code 2
 make: *** [build-arch] Error 2
 debian/rules:21: recipe for target 'build-arch' failed
 dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

 So it seems a test is failing.

 Just want to let you know I'm working towards a fix.


Well, upstream is already working on this. In fact, the test above
passes in the new version (which I've just pushed to collab-maint),
but the next one fails. You may try to pinpoint the problem, but it is
very likely the fact that python-pyelftools do not follow /etc/ld.conf
configuration.

Tomasz


signature.asc
Description: Digital signature

Bug#786715: stellarium: Uses private copies of external headers

[Tomasz Buchert]

Update:
here is a change in the upstream repo:
https://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/7669

So, at least for now, they chose 2). However the author notes that the
code still refers to private Qt code, which means that the problem is not
really solved properly. He also seems to lean toward quazip as a long-term
solution.

Tomasz


signature.asc
Description: Digital signature

Bug#786715: stellarium: Uses private copies of external headers

[Tomasz Buchert]

Hi,
thanks for the report. The upstream is already looking at this.
I'll also mention a relevant bug: https://bugreports.qt.io/browse/QTBUG-3897

Tomasz


signature.asc
Description: Digital signature

Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file

[Tomasz Buchert]

On 17/03/15 08:09, Tomasz Buchert wrote:
 Hi,
 [...]

It turns out that the version 0.1.41-2 had *no* symbols file and for
all I know, it wouldn't build on some archs just as 0.1.41-3. I
decided to drop symbols file altogether since making it work with all
architecture/g++/STL details is madness. This is not a big issue
because libverbiste is used only by verbiste. If one day another
package will use libverbiste (unlikely), I will reconsider symbols
file, but for now, it just doesn't make sense to manage it.

I'm uploading a new package as I write this.

Tomasz


signature.asc
Description: Digital signature

Bug#781858: apt: dangling pointer crash

[Tomasz Buchert]

Hi David,
ok, I get it. A rather unfortunate decision with this API, since now
it is basically impossible to have a dynamic mode name (well, it is
doable but one has to manage memory outside the class itself).

+1 for your patch, anyway. :)

Tomasz


signature.asc
Description: Digital signature

Bug#781858: apt: dangling pointer crash

[Tomasz Buchert]

This should do the trick.

Tomasz
From 9b568120c6e5a0e6361271de0440b4974a0bb7df Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tom...@debian.org
Date: Mon, 6 Apr 2015 14:38:45 +0200
Subject: [PATCH] Fix Mode use

---
 apt-pkg/acquire-item.cc | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/apt-pkg/acquire-item.cc b/apt-pkg/acquire-item.cc
index 253cbda..c5ad097 100644
--- a/apt-pkg/acquire-item.cc
+++ b/apt-pkg/acquire-item.cc
@@ -50,6 +50,14 @@
 
 using namespace std;
 
+static const char *xstrdup(const char *s)
+{
+   char* c = strdup(s);
+   if (!c)
+  abort();
+   return c;
+}
+
 // Acquire::Item::Item - Constructor	/*{{{*/
 // -
 /* */
@@ -66,6 +74,8 @@ pkgAcquire::Item::Item(pkgAcquire *Owner) : Owner(Owner), FileSize(0),
 /* */
 pkgAcquire::Item::~Item()
 {
+   if (Mode != NULL)
+  free((void*)Mode);
Owner-Remove(this);
 }
 	/*}}}*/
@@ -756,7 +766,7 @@ void pkgAcqIndexDiffs::Done(string Message,unsigned long long Size,string Md5Has
   Local = true;
   Desc.URI = rred: + FinalFile;
   QueueURI(Desc);
-  Mode = rred;
+  Mode = xstrdup(rred);
   return;
} 
 
@@ -874,7 +884,7 @@ void pkgAcqIndexMergeDiffs::Done(string Message,unsigned long long Size,string M
   Local = true;
   Desc.URI = rred: + FinalFile;
   QueueURI(Desc);
-  Mode = rred;
+  Mode = xstrdup(rred);
   return;
}
// success in download/apply all diffs, clean up
@@ -1128,7 +1138,7 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
   DestFile += .decomp;
   Desc.URI = copy: + FileName;
   QueueURI(Desc);
-  Mode = copy;
+  Mode = xstrdup(copy);
   return;
}
 
@@ -1194,8 +1204,7 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
Desc.URI = decompProg + : + FileName;
QueueURI(Desc);
 
-   // FIXME: this points to a c++ string that goes out of scope
-   Mode = decompProg.c_str();
+   Mode = xstrdup(decompProg.c_str());
 }
 	/*}}}*/
 // AcqIndexTrans::pkgAcqIndexTrans - Constructor			/*{{{*/
@@ -1470,7 +1479,7 @@ void pkgAcqMetaIndex::Done(string Message,unsigned long long Size,string Hash,	/
  AuthPass = true;
  Desc.URI = gpgv: + SigFile;
  QueueURI(Desc);
- Mode = gpgv;
+ Mode = xstrdup(gpgv);
 	 return;
   }
}
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#781858: apt: dangling pointer crash

[Tomasz Buchert]

On 06/04/15 14:04, Chris Bainbridge wrote:
 [...]

 In which case using strdup to create a new string for each assignment
 will leak memory?


:D Of course! I focused so much on not breaking API  ABI, that I forgot
about it. Stupid me! Another patch attached.

Tomasz
From c45e7f6a2065a5127dcff9f9b5f12db95d9437a3 Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tom...@debian.org
Date: Mon, 6 Apr 2015 15:38:13 +0200
Subject: [PATCH] Fix Mode use

---
 apt-pkg/acquire-item.cc | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/apt-pkg/acquire-item.cc b/apt-pkg/acquire-item.cc
index 253cbda..2ff088d 100644
--- a/apt-pkg/acquire-item.cc
+++ b/apt-pkg/acquire-item.cc
@@ -50,6 +50,26 @@
 
 using namespace std;
 
+// xstrdup - Duplicate a C string	/*{{{*/
+// -
+/* Makes a copy of str and stores it in a pointer pointed by pdst.
+   The previous value (if exists) is freed. If src is NULL then
+   the previous value is only freed (so it works like free on *pdst). */
+static void xstrdup(const char **pdst, const char *src)
+{
+   const char *dst = *pdst;
+   if (dst)
+  free((void *)dst);
+   dst = NULL;
+   if (src) {
+  dst = strdup(src);
+  if (!dst)
+ abort();
+   }
+   *pdst = dst;
+}
+
+	/*}}}*/
 // Acquire::Item::Item - Constructor	/*{{{*/
 // -
 /* */
@@ -66,6 +86,7 @@ pkgAcquire::Item::Item(pkgAcquire *Owner) : Owner(Owner), FileSize(0),
 /* */
 pkgAcquire::Item::~Item()
 {
+   xstrdup(Mode, NULL);
Owner-Remove(this);
 }
 	/*}}}*/
@@ -756,7 +777,7 @@ void pkgAcqIndexDiffs::Done(string Message,unsigned long long Size,string Md5Has
   Local = true;
   Desc.URI = rred: + FinalFile;
   QueueURI(Desc);
-  Mode = rred;
+  xstrdup(Mode, rred);
   return;
} 
 
@@ -874,7 +895,7 @@ void pkgAcqIndexMergeDiffs::Done(string Message,unsigned long long Size,string M
   Local = true;
   Desc.URI = rred: + FinalFile;
   QueueURI(Desc);
-  Mode = rred;
+  xstrdup(Mode, rred);
   return;
}
// success in download/apply all diffs, clean up
@@ -1128,7 +1149,7 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
   DestFile += .decomp;
   Desc.URI = copy: + FileName;
   QueueURI(Desc);
-  Mode = copy;
+  xstrdup(Mode, copy);
   return;
}
 
@@ -1194,8 +1215,7 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
Desc.URI = decompProg + : + FileName;
QueueURI(Desc);
 
-   // FIXME: this points to a c++ string that goes out of scope
-   Mode = decompProg.c_str();
+   xstrdup(Mode, decompProg.c_str());
 }
 	/*}}}*/
 // AcqIndexTrans::pkgAcqIndexTrans - Constructor			/*{{{*/
@@ -1470,7 +1490,7 @@ void pkgAcqMetaIndex::Done(string Message,unsigned long long Size,string Hash,	/
  AuthPass = true;
  Desc.URI = gpgv: + SigFile;
  QueueURI(Desc);
- Mode = gpgv;
+ xstrdup(Mode, gpgv);
 	 return;
   }
}
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#781858: apt: dangling pointer crash

[Tomasz Buchert]

On 06/04/15 14:04, Chris Bainbridge wrote:
 [...]

 In which case using strdup to create a new string for each assignment
 will leak memory?

:D Of course! I focused so much on not breaking ABI  API that I forgot
about this... Another try is attached.

Tomasz
From c45e7f6a2065a5127dcff9f9b5f12db95d9437a3 Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tom...@debian.org
Date: Mon, 6 Apr 2015 15:38:13 +0200
Subject: [PATCH] Fix Mode use

---
 apt-pkg/acquire-item.cc | 32 ++--
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/apt-pkg/acquire-item.cc b/apt-pkg/acquire-item.cc
index 253cbda..2ff088d 100644
--- a/apt-pkg/acquire-item.cc
+++ b/apt-pkg/acquire-item.cc
@@ -50,6 +50,26 @@
 
 using namespace std;
 
+// xstrdup - Duplicate a C string	/*{{{*/
+// -
+/* Makes a copy of str and stores it in a pointer pointed by pdst.
+   The previous value (if exists) is freed. If src is NULL then
+   the previous value is only freed (so it works like free on *pdst). */
+static void xstrdup(const char **pdst, const char *src)
+{
+   const char *dst = *pdst;
+   if (dst)
+  free((void *)dst);
+   dst = NULL;
+   if (src) {
+  dst = strdup(src);
+  if (!dst)
+ abort();
+   }
+   *pdst = dst;
+}
+
+	/*}}}*/
 // Acquire::Item::Item - Constructor	/*{{{*/
 // -
 /* */
@@ -66,6 +86,7 @@ pkgAcquire::Item::Item(pkgAcquire *Owner) : Owner(Owner), FileSize(0),
 /* */
 pkgAcquire::Item::~Item()
 {
+   xstrdup(Mode, NULL);
Owner-Remove(this);
 }
 	/*}}}*/
@@ -756,7 +777,7 @@ void pkgAcqIndexDiffs::Done(string Message,unsigned long long Size,string Md5Has
   Local = true;
   Desc.URI = rred: + FinalFile;
   QueueURI(Desc);
-  Mode = rred;
+  xstrdup(Mode, rred);
   return;
} 
 
@@ -874,7 +895,7 @@ void pkgAcqIndexMergeDiffs::Done(string Message,unsigned long long Size,string M
   Local = true;
   Desc.URI = rred: + FinalFile;
   QueueURI(Desc);
-  Mode = rred;
+  xstrdup(Mode, rred);
   return;
}
// success in download/apply all diffs, clean up
@@ -1128,7 +1149,7 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
   DestFile += .decomp;
   Desc.URI = copy: + FileName;
   QueueURI(Desc);
-  Mode = copy;
+  xstrdup(Mode, copy);
   return;
}
 
@@ -1194,8 +1215,7 @@ void pkgAcqIndex::Done(string Message,unsigned long long Size,string Hash,
Desc.URI = decompProg + : + FileName;
QueueURI(Desc);
 
-   // FIXME: this points to a c++ string that goes out of scope
-   Mode = decompProg.c_str();
+   xstrdup(Mode, decompProg.c_str());
 }
 	/*}}}*/
 // AcqIndexTrans::pkgAcqIndexTrans - Constructor			/*{{{*/
@@ -1470,7 +1490,7 @@ void pkgAcqMetaIndex::Done(string Message,unsigned long long Size,string Hash,	/
  AuthPass = true;
  Desc.URI = gpgv: + SigFile;
  QueueURI(Desc);
- Mode = gpgv;
+ xstrdup(Mode, gpgv);
 	 return;
   }
}
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#781710: nodejs FTBFS in jessie. test-crypto-stream.js fails (again)

[Tomasz Buchert]

Control: tags -1 reproducible

On 01/04/15 23:47, peter green wrote:
 Package: nodejs
 Severity: serious
 Version: 0.10.29~dfsg-1.1

 nodejs is failing to build with failure of the test test-crypto-stream.js
  [...]

It happens on x64 as well.

Tomasz


signature.asc
Description: Digital signature

Bug#781710: nodejs FTBFS in jessie. test-crypto-stream.js fails (again)

[Tomasz Buchert]

On 06/04/15 16:34, Jérémy Lal wrote:
 Hello,
 [...]

Hi,
consider this patch. The actual error string is:

   TypeError: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad 
decrypt

In the patch I hook into human readable part, not into the hexadecimal
error code. I don't know how the test passed before! The test expected
 error code...

Tomasz
From d153634ea8daddf0f7b1074202357a0f3c8e309a Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tom...@debian.org
Date: Mon, 6 Apr 2015 17:20:46 +0200
Subject: [PATCH] Fix crypto-stream test

---
 test/simple/test-crypto-stream.js | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/simple/test-crypto-stream.js b/test/simple/test-crypto-stream.js
index 402761e..e434aad 100644
--- a/test/simple/test-crypto-stream.js
+++ b/test/simple/test-crypto-stream.js
@@ -70,7 +70,7 @@ var key = new Buffer('48fb56eb10ffeb13fc0ef551bbca3b1b', 'hex'),
 
 cipher.pipe(decipher)
   .on('error', common.mustCall(function end(err) {
-assert(/::/.test(err));
+assert(/EVP_DecryptFinal_ex:bad decrypt/.test(err));
   }));
 
 cipher.end('Papaya!');  // Should not cause an unhandled exception.
-- 
2.1.4



signature.asc
Description: Digital signature

Bug#781710: nodejs FTBFS in jessie. test-crypto-stream.js fails (again)

[Tomasz Buchert]

Eh, it was fixed upstream:
https://github.com/joyent/node/blob/master/test/simple/test-crypto-stream.js

Tomasz


signature.asc
Description: Digital signature

Bug#778646: Multiple issues

[Tomasz Buchert]

Hi,
there is 1.12 available (but the patch above solves
the problem as well).

Tomasz


signature.asc
Description: Digital signature

Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file

[Tomasz Buchert]

Hi,
Guillem in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780489
noticed that some symbols indeed changed from unsigned long to
unsigned int.  It is because size_t resolves to unsigned int instead
of unsigned long as before.  So it is rather a toolchain change that
makes size_t defined in a different way.

The funny thing is that on i386 for example, unsigned long  unsinged
int is the same thing, but it still mangles differently :).

I think that the right solution is to get rid of size_t from public
libverbiste API (replace it with unsigned long) and shield ourselves
from changes like that. I'll work on that.


Now, I also built 0.1.14-2 on testing i386 and it built fine (with
debuild -us -uc), but when I tried *exactly the same package* from git
on testing i386 (but with git-buildpackage), it fails with symbols
problem. It seems that in both cases size_t resolves to a different type!
It's rather strange.

Cheers,
Tomasz


signature.asc
Description: Digital signature

Bug#778646: Multiple issues

[Tomasz Buchert]

Hi all,
Moritz - did you take a look at my patch? I'd really like to have a
second opinion on that since it is fairly large for an NMU.

I attach NMU patch. Shall I upload it to DELAYED/5 or something like
that?

Cheers,
Tomasz
diff -Nru potrace-1.11/debian/changelog potrace-1.11/debian/changelog
--- potrace-1.11/debian/changelog	2015-03-17 08:16:28.0 +0100
+++ potrace-1.11/debian/changelog	2015-03-17 08:19:09.0 +0100
@@ -1,3 +1,10 @@
+potrace (1.11-2.1) testing; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix multiple integer overflows (Closes: #778646)
+
+ -- Tomasz Buchert tom...@debian.org  Tue, 17 Mar 2015 08:11:24 +0100
+
 potrace (1.11-2) unstable; urgency=low
 
   * Uses dh-autoreconf instead of autotools-dev (Closes: #732923)
diff -Nru potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch
--- potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch	1970-01-01 01:00:00.0 +0100
+++ potrace-1.11/debian/patches/0002-Fix-multiple-integer-overflows.patch	2015-03-17 08:19:09.0 +0100
@@ -0,0 +1,172 @@
+From: Tomasz Buchert tom...@debian.org
+Date: Sun, 1 Mar 2015 20:27:29 +0100
+Subject: Fix multiple integer overflows.
+
+Dimensions of a BMP file are signed, 4-byte integers. Therefore the size
+of the image may be bigger than range of (int). This is fixed in
+bitmap.h, by casting all offsets to unsigned long long int (and fixing
+another possible overflow in bm_new).
+
+In bitmap_io.c we make sure that width and height of the image are
+non-negative and in (int) range, because other functions require it.
+
+Moreover, we make sure that allocations do not overflow the range of
+size_t by having a wrapper (safe_malloc) that tests whether the
+allocation size fits in size_t.
+---
+ src/bitmap.h| 35 +++
+ src/bitmap_io.c | 30 +++---
+ 2 files changed, 54 insertions(+), 11 deletions(-)
+
+diff --git a/src/bitmap.h b/src/bitmap.h
+index 1ce13d6..7110926 100644
+--- a/src/bitmap.h
 b/src/bitmap.h
+@@ -7,6 +7,7 @@
+ 
+ #include string.h
+ #include stdlib.h
++#include errno.h
+ 
+ /* The bitmap type is defined in potracelib.h */
+ #include potracelib.h
+@@ -27,7 +28,10 @@
+ /* macros for accessing pixel at index (x,y). U* macros omit the
+bounds check. */
+ 
+-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
++typedef unsigned long long int ulli;
++
++#define bm_allocsize(bm) ((ulli)(bm)-dy * (ulli)(bm)-h)
++#define bm_scanline(bm, y) ((bm)-map + ((ulli)(y))*(ulli)(bm)-dy)
+ #define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
+ #define bm_mask(x) (BM_HIBIT  ((x)  (BM_WORDBITS-1)))
+ #define bm_range(x, a) ((int)(x) = 0  (int)(x)  (a))
+@@ -43,6 +47,16 @@
+ #define BM_INV(bm, x, y) (bm_safe(bm, x, y) ? BM_UINV(bm, x, y) : 0)
+ #define BM_PUT(bm, x, y, b) (bm_safe(bm, x, y) ? BM_UPUT(bm, x, y, b) : 0)
+ 
++/* allocates memory safely */
++static inline void* safe_malloc(ulli size) {
++  size_t maxsize = (size_t)-1;
++  if (size  maxsize) {
++errno = ENOMEM;
++return NULL;
++  }
++  return malloc((size_t)size);
++}
++
+ /* free the given bitmap. Leaves errno untouched. */
+ static inline void bm_free(potrace_bitmap_t *bm) {
+   if (bm) {
+@@ -54,16 +68,21 @@ static inline void bm_free(potrace_bitmap_t *bm) {
+ /* return new un-initialized bitmap. NULL with errno on error */
+ static inline potrace_bitmap_t *bm_new(int w, int h) {
+   potrace_bitmap_t *bm;
+-  int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
++  int dy;
++
++  if (w % BM_WORDBITS == 0)
++dy = w / BM_WORDBITS;
++  else
++dy = (w / BM_WORDBITS) + 1;
+ 
+-  bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
++  bm = (potrace_bitmap_t *)safe_malloc(sizeof(potrace_bitmap_t));
+   if (!bm) {
+ return NULL;
+   }
+   bm-w = w;
+   bm-h = h;
+   bm-dy = dy;
+-  bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
++  bm-map = (potrace_word *)safe_malloc(bm_allocsize(bm) * BM_WORDSIZE);
+   if (!bm-map) {
+ free(bm);
+ return NULL;
+@@ -73,7 +92,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
+ 
+ /* clear the given bitmap. Set all bits to c. */
+ static inline void bm_clear(potrace_bitmap_t *bm, int c) {
+-  memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
++  memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
+ }
+ 
+ /* duplicate the given bitmap. Return NULL on error with errno set. */
+@@ -82,14 +101,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
+   if (!bm1) {
+ return NULL;
+   }
+-  memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
++  memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
+   return bm1;
+ }
+ 
+ /* invert the given bitmap. */
+ static inline void bm_invert(potrace_bitmap_t *bm) {
+-  int i;
+-  for (i = 0; i  bm-dy * bm-h; i++) {
++  ulli i;
++  for (i = 0; i  bm_allocsize(bm); i++) {
+ bm-map[i] ^= BM_ALLBITS

Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file

[Tomasz Buchert]

On 16/03/15 15:49, John Paul Adrian Glaubitz wrote:
 Source: verbiste
 Version: 0.1.41-3
 Severity: serious
 Justification: FTBFS on release architecture leaves package out-of-date
 
 Hello!
 
 Your package currently fails to build on various (release) architectures since
 the symbols file is outdated and needs to be updated using the diff output
 generated during the failed builds.

Hi John,
I don't think it is the case. It seems to me (although I may be wrong) that 
dpkg-gensymbols
does not demangle C++ symbols properly. I reported a bug yesterday:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780489

 
 Please see the available build logs [1] and use this information to update the
 symbols file for all architectures. Please do also remember to have a look at
 the builds logs for the port architectures [2] as well to fix these as well.

I'd appreciate if you'd take a look at the bug report I mentioned
above.

 
 Thanks,
 Adrian

Cheers,
Tomasz

 
  [1] https://buildd.debian.org/status/package.php?p=verbistesuite=sid
  [2] http://buildd.debian-ports.org/status/package.php?p=verbistesuite=sid
 


signature.asc
Description: Digital signature

Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file

[Tomasz Buchert]

Control: block -1 by 780489

On 16/03/15 16:24, John Paul Adrian Glaubitz wrote:
 Hi Tomasz!
 
 On 03/16/2015 04:14 PM, Tomasz Buchert wrote:
  I don't think it is the case. It seems to me (although I may be
  wrong) that dpkg-gensymbols does not demangle C++ symbols properly.
  I reported a bug yesterday: 
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780489
 
 Indeed, you could be right. I just checked the build log for
 verbiste_0.1.41-2 on sh4, for example, and the buildd was, indeed, using
 dpkg_1.17.23 that time while it was using 1.17.24 for the last build.

That's a great observation, however I get the problem with 1.17.24
on i386. dpkg-gensymbols does not demangle a few symbols and I don't
know why (I'd have to dig dpkg-gensymbols, but I have no time right now).

 
  Please see the available build logs [1] and use this information
  to update the symbols file for all architectures. Please do also
  remember to have a look at the builds logs for the port
  architectures [2] as well to fix these as well.
  
  I'd appreciate if you'd take a look at the bug report I mentioned 
  above.
 
 I could just do a manual build with a downgraded version of dpkg on one
 of the buildds. I wasn't really expecting this to be a bug in dpkg as we
 usually see this kind of FTBFS due to outdated symbols files. Feel free
 to reassign and merge the bug report to dpkg.

I also don't think it will change anything, but it is still rather mysterious
why these symbols do not demangle on some archs.
I'll leave your report open, but I'll mark it blocked by my previous report,
since we should understand this anyway.

 
 Thanks for the heads up!

You're welcome!

 
 Adrian

Tomasz


signature.asc
Description: Digital signature

Bug#778646: Multiple issues

[Tomasz Buchert]

Hi again (!),

I figured out that this will not work on architectures where
sizeof(long int) != 8 and/or sizeof(size_t) != 8, i386 for example.

The *next* patch makes sure that numbers passed to malloc() are not
overflowing size_t, and also uses *unsigned long long int* everywhere
which is guaranteed to be at least 64bit. Tested on both amd64 and
i386.

Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 1 Mar 2015 20:27:29 +0100
Subject: Fix multiple integer overflows.

Dimensions of a BMP file are signed, 4-byte integers. Therefore the size
of the image may be bigger than range of (int). This is fixed in
bitmap.h, by casting all offsets to unsigned long long int (and fixing
another possible overflow in bm_new).

In bitmap_io.c we make sure that width and height of the image are
non-negative and in (int) range, because other functions require it.

Moreover, we make sure that allocations do not overflow the range of
size_t by having a wrapper (safe_malloc) that tests whether the
allocation size fits in size_t.
---
 src/bitmap.h| 35 +++
 src/bitmap_io.c | 30 +++---
 2 files changed, 54 insertions(+), 11 deletions(-)

diff --git a/src/bitmap.h b/src/bitmap.h
index 1ce13d6..7110926 100644
--- a/src/bitmap.h
+++ b/src/bitmap.h
@@ -7,6 +7,7 @@
 
 #include string.h
 #include stdlib.h
+#include errno.h
 
 /* The bitmap type is defined in potracelib.h */
 #include potracelib.h
@@ -27,7 +28,10 @@
 /* macros for accessing pixel at index (x,y). U* macros omit the
bounds check. */
 
-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
+typedef unsigned long long int ulli;
+
+#define bm_allocsize(bm) ((ulli)(bm)-dy * (ulli)(bm)-h)
+#define bm_scanline(bm, y) ((bm)-map + ((ulli)(y))*(ulli)(bm)-dy)
 #define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
 #define bm_mask(x) (BM_HIBIT  ((x)  (BM_WORDBITS-1)))
 #define bm_range(x, a) ((int)(x) = 0  (int)(x)  (a))
@@ -43,6 +47,16 @@
 #define BM_INV(bm, x, y) (bm_safe(bm, x, y) ? BM_UINV(bm, x, y) : 0)
 #define BM_PUT(bm, x, y, b) (bm_safe(bm, x, y) ? BM_UPUT(bm, x, y, b) : 0)
 
+/* allocates memory safely */
+static inline void* safe_malloc(ulli size) {
+  size_t maxsize = (size_t)-1;
+  if (size  maxsize) {
+errno = ENOMEM;
+return NULL;
+  }
+  return malloc((size_t)size);
+}
+
 /* free the given bitmap. Leaves errno untouched. */
 static inline void bm_free(potrace_bitmap_t *bm) {
   if (bm) {
@@ -54,16 +68,21 @@ static inline void bm_free(potrace_bitmap_t *bm) {
 /* return new un-initialized bitmap. NULL with errno on error */
 static inline potrace_bitmap_t *bm_new(int w, int h) {
   potrace_bitmap_t *bm;
-  int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
+  int dy;
+
+  if (w % BM_WORDBITS == 0)
+dy = w / BM_WORDBITS;
+  else
+dy = (w / BM_WORDBITS) + 1;
 
-  bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
+  bm = (potrace_bitmap_t *)safe_malloc(sizeof(potrace_bitmap_t));
   if (!bm) {
 return NULL;
   }
   bm-w = w;
   bm-h = h;
   bm-dy = dy;
-  bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
+  bm-map = (potrace_word *)safe_malloc(bm_allocsize(bm) * BM_WORDSIZE);
   if (!bm-map) {
 free(bm);
 return NULL;
@@ -73,7 +92,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
 
 /* clear the given bitmap. Set all bits to c. */
 static inline void bm_clear(potrace_bitmap_t *bm, int c) {
-  memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
+  memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
 }
 
 /* duplicate the given bitmap. Return NULL on error with errno set. */
@@ -82,14 +101,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
   if (!bm1) {
 return NULL;
   }
-  memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
+  memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
   return bm1;
 }
 
 /* invert the given bitmap. */
 static inline void bm_invert(potrace_bitmap_t *bm) {
-  int i;
-  for (i = 0; i  bm-dy * bm-h; i++) {
+  ulli i;
+  for (i = 0; i  bm_allocsize(bm); i++) {
 bm-map[i] ^= BM_ALLBITS;
   }
 }
diff --git a/src/bitmap_io.c b/src/bitmap_io.c
index 6cfecb1..ea2d188 100644
--- a/src/bitmap_io.c
+++ b/src/bitmap_io.c
@@ -381,6 +381,16 @@ static int bmp_readint(FILE *f, int n, unsigned int *p) {
   return 0;
 }
 
+/* converts unsigned to signed using 32 bits */
+static int unsigned_to_signed32(unsigned int x) {
+  unsigned int sign = 0x8000U;
+  unsigned int mask = 0xU;
+  if (sign  x)
+return -(int)(x ^ mask) - 1;
+  else
+return (int)x;
+}
+
 /* reset padding boundary */
 static void bmp_pad_reset(void) {
   bmp_count = 0;
@@ -478,12 +488,25 @@ static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp) {
   TRY(bmp_readint(f, 4, bmpinfo.BlueMask));
   TRY(bmp_readint(f, 4, bmpinfo.AlphaMask));
 }
-if ((signed int)bmpinfo.h  0) {
-  bmpinfo.h = -bmpinfo.h;
+int maxdim = 0x7ffe; /* 2^31 - 2 */
+int

Bug#778646: Multiple issues

[Tomasz Buchert]

Hi again,
here is slightly better patch.

Cheers,
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 1 Mar 2015 20:27:29 +0100
Subject: Fix multiple integer overflows.

Dimensions of a BMP file are signed, 4-byte integers. Therefore
the size of the image may be bigger than range of (int). This is fixed
in bitmap.h, by casting all offsets to long int (and fixing
another possible overflow in bm_new).
In bitmap_io.c we make sure that width and height of the image
are non-negative and in (int) range, because other functions require it.
---
 src/bitmap.h| 20 +---
 src/bitmap_io.c | 27 +--
 2 files changed, 38 insertions(+), 9 deletions(-)

diff --git a/src/bitmap.h b/src/bitmap.h
index 1ce13d6..878aa9a 100644
--- a/src/bitmap.h
+++ b/src/bitmap.h
@@ -27,7 +27,8 @@
 /* macros for accessing pixel at index (x,y). U* macros omit the
bounds check. */
 
-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
+#define bm_allocsize(bm) ((long int)(bm)-dy * (long int)(bm)-h)
+#define bm_scanline(bm, y) ((bm)-map + ((long int)(y))*(long int)(bm)-dy)
 #define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
 #define bm_mask(x) (BM_HIBIT  ((x)  (BM_WORDBITS-1)))
 #define bm_range(x, a) ((int)(x) = 0  (int)(x)  (a))
@@ -54,7 +55,12 @@ static inline void bm_free(potrace_bitmap_t *bm) {
 /* return new un-initialized bitmap. NULL with errno on error */
 static inline potrace_bitmap_t *bm_new(int w, int h) {
   potrace_bitmap_t *bm;
-  int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
+  int dy;
+
+  if (w % BM_WORDBITS == 0)
+dy = w / BM_WORDBITS;
+  else
+dy = (w / BM_WORDBITS) + 1;
 
   bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
   if (!bm) {
@@ -63,7 +69,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
   bm-w = w;
   bm-h = h;
   bm-dy = dy;
-  bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
+  bm-map = (potrace_word *) malloc(bm_allocsize(bm) * BM_WORDSIZE);
   if (!bm-map) {
 free(bm);
 return NULL;
@@ -73,7 +79,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
 
 /* clear the given bitmap. Set all bits to c. */
 static inline void bm_clear(potrace_bitmap_t *bm, int c) {
-  memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
+  memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
 }
 
 /* duplicate the given bitmap. Return NULL on error with errno set. */
@@ -82,14 +88,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
   if (!bm1) {
 return NULL;
   }
-  memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
+  memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
   return bm1;
 }
 
 /* invert the given bitmap. */
 static inline void bm_invert(potrace_bitmap_t *bm) {
-  int i;
-  for (i = 0; i  bm-dy * bm-h; i++) {
+  long int i;
+  for (i = 0; i  bm_allocsize(bm); i++) {
 bm-map[i] ^= BM_ALLBITS;
   }
 }
diff --git a/src/bitmap_io.c b/src/bitmap_io.c
index 6cfecb1..3635ec3 100644
--- a/src/bitmap_io.c
+++ b/src/bitmap_io.c
@@ -381,6 +381,16 @@ static int bmp_readint(FILE *f, int n, unsigned int *p) {
   return 0;
 }
 
+/* converts unsigned to signed using 32 bits */
+static int unsigned_to_signed32(unsigned int x) {
+  unsigned int sign = 0x8000U;
+  unsigned int mask = 0xU;
+  if (sign  x)
+return -(int)(x ^ mask) - 1;
+  else
+return (int)x;
+}
+
 /* reset padding boundary */
 static void bmp_pad_reset(void) {
   bmp_count = 0;
@@ -478,12 +488,25 @@ static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp) {
   TRY(bmp_readint(f, 4, bmpinfo.BlueMask));
   TRY(bmp_readint(f, 4, bmpinfo.AlphaMask));
 }
-if ((signed int)bmpinfo.h  0) {
-  bmpinfo.h = -bmpinfo.h;
+int maxdim = 0x7ffe; /* 2^31 - 2 */
+int sign_h = unsigned_to_signed32(bmpinfo.h);
+int sign_w = unsigned_to_signed32(bmpinfo.w);
+if (sign_w  0 || sign_w  maxdim) {
+  bm_read_error = incorrect bmp width;
+  goto format_error;
+}
+if (sign_h  -maxdim || sign_h  maxdim) {
+  bm_read_error = incorrect bmp height;
+  goto format_error;
+}
+if (sign_h  0) {
+  bmpinfo.h = (unsigned int)(-sign_h);
   bmpinfo.topdown = 1;
 } else {
   bmpinfo.topdown = 0;
 }
+/* now we know that bmpinfo.{w,h} are non-negative ints
+   that fit in int type (cf. bm_new)) */
   } else if (bmpinfo.InfoSize == 12) {
 /* old OS/2 format */
 bmpinfo.ctbits = 24; /* sample size in color table */

Bug#778646: Multiple issues

[Tomasz Buchert]

On 17/02/15 22:02, Moritz Muehlenhoff wrote:
 Package: potrace
 Version: 1.11-2
 Severity: grave
 Tags: security
 
 Hi,
 please see https://bugzilla.redhat.com/show_bug.cgi?id=955808
 Could you report this upstream?
 
 A CVE ID has been requested, but not yet assigned:
 http://www.openwall.com/lists/oss-security/2015/02/06/12
 
 Cheers,
 Moritz
 
 

Hi Moritz,
here is my analysis of the problem in a form of a patch.

tl;dr; - (a) casting from unsigned int to int is tricky
  (b) product of two ints may overflow

It fixes all the cases attached in the RedHat's bugzilla, but
a review of the code by another person is advised.

Cheers,
Tomasz
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Sun, 1 Mar 2015 20:27:29 +0100
Subject: Fix multiple integer overflows.

Dimensions of a BMP file are signed, 4-byte integers. Therefore
the size of the image may be bigger than range of (int). This is fixed
in bitmap.h, by casting all offsets to long int (and fixing
another possible overflow in bm_new).
In bitmap_io.c we make sure that width and height of the image
are non-negative and in (int) range, because other functions require it.
---
 src/bitmap.h| 20 +---
 src/bitmap_io.c | 29 +++--
 2 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/src/bitmap.h b/src/bitmap.h
index 1ce13d6..878aa9a 100644
--- a/src/bitmap.h
+++ b/src/bitmap.h
@@ -27,7 +27,8 @@
 /* macros for accessing pixel at index (x,y). U* macros omit the
bounds check. */
 
-#define bm_scanline(bm, y) ((bm)-map + (y)*(bm)-dy)
+#define bm_allocsize(bm) ((long int)(bm)-dy * (long int)(bm)-h)
+#define bm_scanline(bm, y) ((bm)-map + ((long int)(y))*(long int)(bm)-dy)
 #define bm_index(bm, x, y) (bm_scanline(bm, y)[(x)/BM_WORDBITS])
 #define bm_mask(x) (BM_HIBIT  ((x)  (BM_WORDBITS-1)))
 #define bm_range(x, a) ((int)(x) = 0  (int)(x)  (a))
@@ -54,7 +55,12 @@ static inline void bm_free(potrace_bitmap_t *bm) {
 /* return new un-initialized bitmap. NULL with errno on error */
 static inline potrace_bitmap_t *bm_new(int w, int h) {
   potrace_bitmap_t *bm;
-  int dy = (w + BM_WORDBITS - 1) / BM_WORDBITS;
+  int dy;
+
+  if (w % BM_WORDBITS == 0)
+dy = w / BM_WORDBITS;
+  else
+dy = (w / BM_WORDBITS) + 1;
 
   bm = (potrace_bitmap_t *) malloc(sizeof(potrace_bitmap_t));
   if (!bm) {
@@ -63,7 +69,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
   bm-w = w;
   bm-h = h;
   bm-dy = dy;
-  bm-map = (potrace_word *) malloc(dy * h * BM_WORDSIZE);
+  bm-map = (potrace_word *) malloc(bm_allocsize(bm) * BM_WORDSIZE);
   if (!bm-map) {
 free(bm);
 return NULL;
@@ -73,7 +79,7 @@ static inline potrace_bitmap_t *bm_new(int w, int h) {
 
 /* clear the given bitmap. Set all bits to c. */
 static inline void bm_clear(potrace_bitmap_t *bm, int c) {
-  memset(bm-map, c ? -1 : 0, bm-dy * bm-h * BM_WORDSIZE);
+  memset(bm-map, c ? -1 : 0, bm_allocsize(bm) * BM_WORDSIZE);
 }
 
 /* duplicate the given bitmap. Return NULL on error with errno set. */
@@ -82,14 +88,14 @@ static inline potrace_bitmap_t *bm_dup(const potrace_bitmap_t *bm) {
   if (!bm1) {
 return NULL;
   }
-  memcpy(bm1-map, bm-map, bm-dy * bm-h * BM_WORDSIZE);
+  memcpy(bm1-map, bm-map, bm_allocsize(bm) * BM_WORDSIZE);
   return bm1;
 }
 
 /* invert the given bitmap. */
 static inline void bm_invert(potrace_bitmap_t *bm) {
-  int i;
-  for (i = 0; i  bm-dy * bm-h; i++) {
+  long int i;
+  for (i = 0; i  bm_allocsize(bm); i++) {
 bm-map[i] ^= BM_ALLBITS;
   }
 }
diff --git a/src/bitmap_io.c b/src/bitmap_io.c
index 6cfecb1..635540c 100644
--- a/src/bitmap_io.c
+++ b/src/bitmap_io.c
@@ -381,6 +381,18 @@ static int bmp_readint(FILE *f, int n, unsigned int *p) {
   return 0;
 }
 
+/* converts unsigned to signed */
+static int unsigned_to_signed(int bits, unsigned int x) {
+  unsigned int mask = ((unsigned int)1)  (bits - 1);
+  int minint = ((int)-1)  (bits - 1);
+  if (mask == x)
+return minint;
+  else if (mask  x)
+return -((int)(~x) + 1);
+  else
+return (int)x;
+}
+
 /* reset padding boundary */
 static void bmp_pad_reset(void) {
   bmp_count = 0;
@@ -478,12 +490,25 @@ static int bm_readbody_bmp(FILE *f, double threshold, potrace_bitmap_t **bmp) {
   TRY(bmp_readint(f, 4, bmpinfo.BlueMask));
   TRY(bmp_readint(f, 4, bmpinfo.AlphaMask));
 }
-if ((signed int)bmpinfo.h  0) {
-  bmpinfo.h = -bmpinfo.h;
+int maxdim = 0x7ffe; /* 2^31 - 2 */
+int sign_h = unsigned_to_signed(32, bmpinfo.h);
+int sign_w = unsigned_to_signed(32, bmpinfo.w);
+if (sign_w  0 || sign_w  maxdim) {
+  bm_read_error = incorrect bmp width;
+  goto format_error;
+}
+if (sign_h  -maxdim || sign_h  maxdim) {
+  bm_read_error = incorrect bmp height;
+  goto format_error;
+}
+if (sign_h  0) {
+  bmpinfo.h = (unsigned int)(-sign_h);
   bmpinfo.topdown = 1;
 } else {
   bmpinfo.topdown = 0;
 }
+/* now we know that bmpinfo.{w,h} are non-negative ints

Bug#778674: apt-p2p: fails to start (throws exception)

[Tomasz Buchert]

Package: apt-p2p
Version: 0.1.7
Severity: grave
Justification: renders package unusable

Hi,
I wanted to test apt-p2p and noticed that it won't even start:

[ ~ ] $ sudo apt-p2p 
[sudo] password for toma: 
2015-02-18 11:47:31+0100 [-] Log opened.
2015-02-18 11:47:31+0100 [-] Loading config files: '/etc/apt-p2p/apt-p2p.conf', 
'/root/.apt-p2p/apt-p2p.conf', ''
2015-02-18 11:47:31+0100 [-] Successfully loaded config files: 
'/etc/apt-p2p/apt-p2p.conf'
2015-02-18 11:47:31+0100 [-] Starting application with uid/gid 141/65534
2015-02-18 11:47:31+0100 [-] Starting main application server
2015-02-18 11:47:31+0100 [-] Traceback (most recent call last):
2015-02-18 11:47:31+0100 [-]   File /usr/sbin/apt-p2p, line 73, in module
2015-02-18 11:47:31+0100 [-] from apt_p2p.apt_p2p import AptP2P
2015-02-18 11:47:31+0100 [-]   File 
/usr/lib/python2.7/dist-packages/apt_p2p/apt_p2p.py, line 19, in module
2015-02-18 11:47:31+0100 [-] from MirrorManager import MirrorManager
2015-02-18 11:47:31+0100 [-]   File 
/usr/lib/python2.7/dist-packages/apt_p2p/MirrorManager.py, line 16, in 
module
2015-02-18 11:47:31+0100 [-] from AptPackages import AptPackages
2015-02-18 11:47:31+0100 [-]   File 
/usr/lib/python2.7/dist-packages/apt_p2p/AptPackages.py, line 40, in module
2015-02-18 11:47:31+0100 [-] from apt.progress.old import OpProgress
2015-02-18 11:47:31+0100 [-] ImportError: No module named old

Just letting you know and putting it under RC.

Tomasz

-- System Information:
Debian Release: 8.0
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages apt-p2p depends on:
ii  adduser  3.113+nmu3
ii  python   2.7.8-3
ii  python-apt   0.9.3.11
ii  python-debian0.1.25
ii  python-pysqlite2 2.6.3-3
ii  python-twisted-web2  8.1.0-3
pn  python:any   none

apt-p2p recommends no packages.

apt-p2p suggests no packages.

-- 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#778375: apt-transport-https: segfaults

[Tomasz Buchert]

On 15/02/15 23:55, Tomasz Buchert wrote:

 [...]

(@Julian: sorry for not CCing you before)

Hi again,
I couldn't fall asleep, so there you go:

The tricky HTTPS server returns this line: HTTP/1.1 302. Note that
there is no explanation for the status code 302 (it should be
Found). Anyway, this is fine, the code seems to be prepared for
that case: elements is set to 3 in server.cc:128.

However, Owner is NULL (I don't know why, I don't know the code, but
it is) so Owner-Debug fails in server.cc:132.

The attached patch checks whether Owner is NULL before dereferencing
it. This fixes this problem for me, but somebody who knows what Owner
is should make sure that it makes sense.  Feel free to adjust the
patch to your needs, it's in public domain.

Cheers,
Tomasz
From 3afccaefccc9045d5d1236f09d4cc90cc721c8ef Mon Sep 17 00:00:00 2001
From: Tomasz Buchert tomasz.buch...@inria.fr
Date: Mon, 16 Feb 2015 00:57:29 +0100
Subject: [PATCH] simple fix

---
 methods/server.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/methods/server.cc b/methods/server.cc
index cb0341d..e321e02 100644
--- a/methods/server.cc
+++ b/methods/server.cc
@@ -129,7 +129,7 @@ bool ServerState::HeaderLine(string Line)
 	 if (elements == 3)
 	 {
 	Code[0] = '\0';
-	if (Owner-Debug == true)
+	if (Owner != NULL  Owner-Debug == true)
 	   clog  HTTP server doesn't give Reason-Phrase for   Result  std::endl;
 	 }
 	 else if (elements != 4)
-- 
2.1.4

Bug#778375: apt-transport-https: segfaults

[Tomasz Buchert]

On 14/02/15 10:44, Kurt Roeckx wrote:
 Package: apt-transport-https
 Version: 1.0.9.6
 Severity: serious

 Hi,

 When I try to download something over https apt just segfaults:
 https[7809]: segfault at 69 ip 7f523b8cbb03 sp 7fff432589e0 error 4 
 in https[7f523b8c+12000]


 Kurt


Hi Kurt,
I cannot reproduce it:

$ LC_ALL=C sudo apt-get install cowsay
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  cowsay
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 20.0 kB of archives.
After this operation, 92.2 kB of additional disk space will be used.
Get:1 https://ftp-stud.hs-esslingen.de/debian/ testing/main cowsay all 
3.03+dfsg1-10 [20.0 kB]
Fetched 20.0 kB in 0s (65.9 kB/s)
[... other standard things ...]

Cheers,
Tomasz


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

Bug#778375: apt-transport-https: segfaults

[Tomasz Buchert]

On 15/02/15 23:16, Tomasz Buchert wrote:
 [...]

 Okay, I get a segfault too now:
 [  153.995036] https[2667]: segfault at 69 ip 7f41539d7b03 sp 
 7fffa171dbb0 error 4 in https[7f41539cc000+12000]

 Tomasz


Hi again,
I've recompiled apt-transport-https with debugging symbols and
derandomized positions of code sections (via echo 0 | sudo tee
/proc/sys/kernel/randomize_va_space).  I got this:

[  510.536222] https[2990]: segfault at 69 ip fb03 sp 
7fffdbf0 error 4 in https[4000+12000]

and then, via gdb:

(gdb) list *0xfb03
0xfb03 is in ServerState::HeaderLine(std::string) 
(/tmp/apt-1.0.9.6/methods/server.cc:120).
115// Parse off any trailing spaces between the : and the next word.
116string::size_type Pos2 = Pos;
117while (Pos2  Line.length()  isspace(Line[Pos2]) != 0)
118   Pos2++;
119
120string Tag = string(Line,0,Pos);
121string Val = string(Line,Pos2);
122
123if (stringcasecmp(Tag.c_str(),Tag.c_str()+4,HTTP) == 0)
124{

So there is an issue with parsing of HTTP headers or something like
that around server.cc:120.  Unfortunately, I don't have much time to
dig more at the moment. Hope this helps.

Tomasz


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

Bug#778375: apt-transport-https: segfaults

[Tomasz Buchert]

On 15/02/15 22:22, Kurt Roeckx wrote:
 [...]

 Can you try adding this to your sources.list?
 deb https://dl.bintray.com/sbt/debian /

 And then apt-get install -d sbt


 Kurt


Okay, I get a segfault too now:
[  153.995036] https[2667]: segfault at 69 ip 7f41539d7b03 sp 
7fffa171dbb0 error 4 in https[7f41539cc000+12000]

Tomasz


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

Bug#741451: Bugfix

[Tomasz Buchert]

On 23/12/14 16:00, Jay Berkenbilt wrote:

 Thanks, Tomasz, for preparing the NMU and Balint for uploading! I've
 tweaked the DEP-3 stuff in the patch a little and changed its name, and
 am preparing a regular, non-NMU upload which I will upload momentarily.
 I've given Tomasz credit for the fix. Sorry for not being more on top of
 it. Your good efforts made my job trivial. Thanks!

 I have also submitted an unblock request to the release team.

 --
 Jay Berkenbilt q...@debian.org

Great! :D

Merry Christmas!
Tomasz


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

Bug#741451: Bugfix

[Tomasz Buchert]

On 22/12/14 18:08, Tomasz Buchert wrote:
 On 19/12/14 22:05, Balint Reczey wrote:
  Hi Jay,
 
  [...]
 
  Cheers,
  Balint
 

 Hi guys,
 I didn't notice that upstream made a fix based on what I found.  I'll
 try to prepare an NMU right now.

 Tomasz


Here is a NMU. Feel free to adapt it if you
feel like it.

Tomasz
diff -Nru tiff-4.0.3/debian/changelog tiff-4.0.3/debian/changelog
--- tiff-4.0.3/debian/changelog	2014-06-29 23:32:44.0 +0200
+++ tiff-4.0.3/debian/changelog	2014-12-22 18:51:23.0 +0100
@@ -1,3 +1,10 @@
+tiff (4.0.3-10.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Don't crash on JPEG = non-JPEG conversion (Closes: #741451)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr  Tue, 28 Oct 2014 18:11:18 +0100
+
 tiff (4.0.3-10) unstable; urgency=medium
 
   * Remove libtiff4-dev, completing the tiff transition. Packages that
diff -Nru tiff-4.0.3/debian/patches/bug-741451.patch tiff-4.0.3/debian/patches/bug-741451.patch
--- tiff-4.0.3/debian/patches/bug-741451.patch	1970-01-01 01:00:00.0 +0100
+++ tiff-4.0.3/debian/patches/bug-741451.patch	2014-12-22 19:09:35.0 +0100
@@ -0,0 +1,36 @@
+Description: fix for Debian bug #741451
+ tiffcp crashes when converting JPEG-encoded TIFF to a different
+ encoding (like none or lzw). For example this will probably fail:
+ .
+tiffcp -c none jpeg_encoded_file.tif output.tif
+ .
+ The reason is that when the input file contains JPEG data,
+ the tiffcp code forces conversion to RGB space. However,
+ the output normally inherits YCbCr subsampling parameters
+ from the input, which leads to a smaller working buffer
+ than necessary. The buffer is subsequently overrun inside
+ cpStripToTile() (called from writeBufferToContigTiles).
+ Note that the resulting TIFF file would be scrambled even
+ if tiffcp wouldn't crash, since the output file would contain
+ RGB data intepreted as subsampled YCbCr values.
+ .
+ This patch fixes the problem by forcing RGB space on the output
+ TIF if the input is JPEG-encoded and output is *not* JPEG-encoded.
+ Fixed upstream: http://bugzilla.maptools.org/show_bug.cgi?id=2480
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+
+--- a/tools/tiffcp.c
 b/tools/tiffcp.c
+@@ -629,6 +629,12 @@
+ 		TIFFSetField(out, TIFFTAG_PHOTOMETRIC,
+ 		samplesperpixel == 1 ?
+ 		PHOTOMETRIC_LOGL : PHOTOMETRIC_LOGLUV);
++	else if (input_compression == COMPRESSION_JPEG 
++		samplesperpixel == 3) {
++		/* RGB conversion was forced above
++		   hence the output will be of the same type */
++		TIFFSetField(out, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB);
++	}
+ 	else
+ 		CopyTag(TIFFTAG_PHOTOMETRIC, 1, TIFF_SHORT);
+ 	if (fillorder != 0)
diff -Nru tiff-4.0.3/debian/patches/series tiff-4.0.3/debian/patches/series
--- tiff-4.0.3/debian/patches/series	2014-06-29 23:32:44.0 +0200
+++ tiff-4.0.3/debian/patches/series	2014-12-22 18:51:23.0 +0100
@@ -6,3 +6,4 @@
 CVE-2013-4232.patch
 CVE-2013-4244.patch
 CVE-2013-4243.patch
+bug-741451.patch

Bug#741451: Bugfix

[Tomasz Buchert]

On 19/12/14 22:05, Balint Reczey wrote:
 Hi Jay,

 [...]

 Cheers,
 Balint


Hi guys,
I didn't notice that upstream made a fix based on what I found.  I'll
try to prepare an NMU right now.

Tomasz


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

Bug#718596: [Pkg-bluetooth-maintainers] Bug#718596: (no subject)

[Tomasz Buchert]

On 03/12/14 08:47, Habib Seifzadeh wrote:
 Dear Nobuhiro,

 Thanks a lot,

 Bluez-obexd solved the problem. Both send and receive works perfectly,

 Cheers,
 Habib


 On 12/03/2014 04:19 AM, Nobuhiro Iwamatsu wrote:
 Hi,
 
 obexd is already obsolete. Also different because API can not be used
 in GNOME, KDE and other.
 Please use the bluez-obexd instead.
 
 Best regards,
Nobuhiro

Hi guys,
I confirm that today, after upgrade of my packages, I can
transfer files from/to my phone using gnome-bluetooth.
It means, I guess, that you can close (or maybe donwgrade) this bug.

Thanks
Tomasz


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

Bug#768615: #768615: ruby-pygments.rb: FTBFS in jessie: ERROR: Test ruby2.1 failed

[Tomasz Buchert]

On 24/11/14 14:21, Christian Hofstaedtler wrote:
 Tobias, Tomasz,

 Thank you for working on this.

 Feel free to reschedule the NMU to an earlier date (e.g. immediate).

 Best,
 --
  ,''`.  Christian Hofstaedtler z...@debian.org
 : :' :  Debian Developer
 `. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
   `-


Hi Christian,
I think I made a mistake in this NMU, the changelog uploads
it to unstable, but I think it should be testing instead (on the other
hand you may unblock transition unstable = testing if I'm correct).

Cheers,
Tomasz


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

Bug#768690: latex-mk: FTBFS in jessie: build-dependency not installable: tgif

[Tomasz Buchert]

On 22/11/14 20:28, Tobias Frost wrote:
 Control: tags -1 pending

 Uploaded to DELAYED/5

 Thanks Thomasz!

 --
 tobi



I think that my NMU is wrong since it uploads into unstable, but
it should be testing instead. Sorry for trouble, I attach a
modified NMU.

Tomasz
diff -Nru latex-mk-2.1/debian/changelog latex-mk-2.1/debian/changelog
--- latex-mk-2.1/debian/changelog	2014-04-25 16:45:24.0 +0200
+++ latex-mk-2.1/debian/changelog	2014-11-22 18:15:40.0 +0100
@@ -1,3 +1,10 @@
+latex-mk (2.1-1.3) testing; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable support and dependency on tgif (Closes: #768690)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr  Sat, 22 Nov 2014 18:14:45 +0100
+
 latex-mk (2.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru latex-mk-2.1/debian/control latex-mk-2.1/debian/control
--- latex-mk-2.1/debian/control	2014-04-25 16:44:02.0 +0200
+++ latex-mk-2.1/debian/control	2014-11-22 18:14:34.0 +0100
@@ -6,7 +6,7 @@
 Build-Depends-Indep: texlive-base, texlive-latex-base, texlive-latex-extra,
  texlive-latex-recommended, texlive-fonts-recommended, texinfo, xsltproc,
  docbook-xsl, graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig, csh, autoconf
+ ghostscript, transfig, csh, autoconf
 Standards-Version: 3.9.2
 Homepage: http://latex-mk.sourceforge.net/
 
@@ -15,7 +15,7 @@
 Depends: ${misc:Depends}
 Recommends: make, texlive-latex-recommended, texlive-base
 Suggests: graphicsmagick-imagemagick-compat, gv, hevea, latex2rtf, cups-bsd,
- ghostscript, tgif, transfig
+ ghostscript, transfig
 Description: tool for managing LaTeX projects
  LaTeX-Mk is a collection of Makefile fragments and shell scripts for
  managing small to large sized LaTeX projects. The typical LaTeX-Mk
diff -Nru latex-mk-2.1/debian/patches/disable-tgif.patch latex-mk-2.1/debian/patches/disable-tgif.patch
--- latex-mk-2.1/debian/patches/disable-tgif.patch	1970-01-01 01:00:00.0 +0100
+++ latex-mk-2.1/debian/patches/disable-tgif.patch	2014-11-22 18:57:09.0 +0100
@@ -0,0 +1,28 @@
+Description: Disables build dependency on tgif
+ tgif was removed from testing for various reasons.
+ First, its dependencies are not in testing (see https://bugs.debian.org/699301)
+ and then its own status is ambiguous (see https://bugs.debian.org/668249).
+ This patch disables tgif-related functionality by showing error
+ message if the user wants to use it.
+ .
+ latex-mk (2.1-1.3) unstable; urgency=medium
+ .
+   * Non-maintainer upload.
+   * Disable support and dependency on tgif (Closes: #768690)
+Author: Tomasz Buchert tomasz.buch...@inria.fr
+Bug-Debian: https://bugs.debian.org/768690
+
+--- a/latex.mk.in.in
 b/latex.mk.in.in
+@@ -432,9 +432,11 @@
+ # pull in tgif.[g]mk if needed
+ 
+ BMK:.if defined(_USE_TGIF_MK)
++BMK:.error Support for tgif files is not available, see https://bugs.debian.org/768690
+ BMK:.include ${LATEX_MK_DIR}/tgif.mk
+ BMK:.endif
+ GMK:ifdef _USE_TGIF_MK
++GMK:$(error Support for tgif files is not available, see https://bugs.debian.org/768690)
+ GMK:include ${LATEX_MK_DIR}/tgif.gmk
+ GMK:endif
+ 
diff -Nru latex-mk-2.1/debian/patches/series latex-mk-2.1/debian/patches/series
--- latex-mk-2.1/debian/patches/series	2011-06-22 04:36:52.0 +0200
+++ latex-mk-2.1/debian/patches/series	2014-11-22 18:17:49.0 +0100
@@ -2,3 +2,4 @@
 use-fancyhdr.patch
 new-nomencl.patch
 use-gunzip-instead-of-gzcat.patch
+disable-tgif.patch

Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange

[Tomasz Buchert]

Good idea,
feel free to change the patch. I won't be able to do it
before the evening.

Tomasz

On 25/11/14 20:51, Yaroslav Halchenko wrote:

 On Wed, 26 Nov 2014, Tomasz Buchert wrote:
  + import pandas as _
  +-return True
  ++return hasattr(_, DateRange)

 imho this is way too aggressive and would cause skipping all pandas
 related tests (DateRange dependent or not)

  + except ImportError:
  + return False
  +
  +Index: statsmodels-0.4.2/statsmodels/tsa/base/tests/test_datetools.py
  +===
  +--- statsmodels-0.4.2.orig/statsmodels/tsa/base/tests/test_datetools.py
   statsmodels-0.4.2/statsmodels/tsa/base/tests/test_datetools.py
  +@@ -3,6 +3,7 @@ import numpy.testing as npt
  + from statsmodels.tsa.base.datetools import (_date_from_idx,
  + _idx_from_dates, date_parser, date_range_str, 
  dates_from_str,
  + dates_from_range, _infer_freq, _freq_to_pandas)
  ++import nose
  +
  + def test_date_from_idx():
  + d1 = datetime(2008, 12, 31)
  +@@ -15,6 +16,7 @@ def test_date_from_idx():
  + npt.assert_equal(_date_from_idx(d1, idx, 'M'), datetime(2010, 3, 31))
  +
  + def test_idx_from_date():
  ++raise nose.SkipTest(Skipped because of missing DateRange)

 if you are introducing these changes, why not to make

 def skip_if_no_daterange():
 try:
 import pandas as _
 if not hasaattr(_, DateRange):
 raise nose.SkipTest(Skipped because...)
 except ImportError:
 raise nose.SkipTest(Skipped because no pandas...)

 and just call that one?



 --
 Yaroslav O. Halchenko, Ph.D.
 http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
 Research Scientist,Psychological and Brain Sciences Dept.
 Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
 Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
 WWW:   http://www.linkedin.com/in/yarik


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

Bug#768673: NMU patch

[Tomasz Buchert]

Hi,
I attach my NMU debdiff that fixes this issue.
Feel free to change the changelog and upload it
in a standard way.

Cheers,
Tomasz
diff -Nru ruby-httpclient-2.3.3/debian/changelog ruby-httpclient-2.3.3/debian/changelog
--- ruby-httpclient-2.3.3/debian/changelog	2014-06-27 03:03:36.0 +0200
+++ ruby-httpclient-2.3.3/debian/changelog	2014-11-26 12:00:23.0 +0100
@@ -1,3 +1,10 @@
+ruby-httpclient (2.3.3-3.1) testing; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix default SSL configuration (Closes: #768673)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr  Wed, 26 Nov 2014 18:59:26 +0100
+
 ruby-httpclient (2.3.3-3) unstable; urgency=medium
 
   * fix-port-allocation-in-tests.patch: fix port allocation for servers
diff -Nru ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch
--- ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch	1970-01-01 01:00:00.0 +0100
+++ ruby-httpclient-2.3.3/debian/patches/0003-fix-ssl-config.patch	2014-11-26 11:57:16.0 +0100
@@ -0,0 +1,64 @@
+Description: Change default SSL configuration
+ The POODLE attack (https://en.wikipedia.org/wiki/POODLE) deprecated the use
+ of SSLv3 protocol. We change the default configuration to autodetection
+ and try to explicitly disable SSLv2 and SSLv3, preferring TLS protocol suites
+ instead.
+ This patch is a minimal adaptation of a commit in the project's upstream:
+ https://github.com/nahi/httpclient/commit/90d5c791c941c72521784dc4ea8eed60987800da
+
+--- a/lib/httpclient/ssl_config.rb
 b/lib/httpclient/ssl_config.rb
+@@ -34,7 +34,13 @@
+   class SSLConfig
+ include OpenSSL if SSLEnabled
+ 
+-# String name of OpenSSL's SSL version method name: SSLv2, SSLv23 or SSLv3
++# Which TLS protocol version (also called method) will be used. Defaults
++# to :auto which means that OpenSSL decides (In my tests this resulted 
++# with always the highest available protocol being used).
++# String name of OpenSSL's SSL version method name: TLSv1_2, TLSv1_1, TLSv1,
++# SSLv2, SSLv23, SSLv3 or :auto (and nil) to allow version negotiation (default).
++# See {OpenSSL::SSL::SSLContext::METHODS} for a list of available versions
++# in your specific Ruby environment.
+ attr_reader :ssl_version
+ # OpenSSL::X509::Certificate:: certificate for SSL client authenticateion.
+ # nil by default. (no client authenticateion)
+@@ -83,8 +89,13 @@
+   @verify_callback = nil
+   @dest = nil
+   @timeout = nil
+-  @ssl_version = SSLv3
+-  @options = defined?(SSL::OP_ALL) ? SSL::OP_ALL | SSL::OP_NO_SSLv2 : nil
++  @ssl_version = :auto
++  # Follow ruby-ossl's definition
++  @options = OpenSSL::SSL::OP_ALL
++  @options = ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
++  @options |= OpenSSL::SSL::OP_NO_COMPRESSION if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
++  @options |= OpenSSL::SSL::OP_NO_SSLv2 if defined?(OpenSSL::SSL::OP_NO_SSLv2)
++  @options |= OpenSSL::SSL::OP_NO_SSLv3 if defined?(OpenSSL::SSL::OP_NO_SSLv3)
+   # OpenSSL 0.9.8 default: ALL:!ADH:!LOW:!EXP:!MD5:+SSLv2:@STRENGTH
+   @ciphers = ALL:!aNULL:!eNULL:!SSLv2 # OpenSSL 1.0.0 default
+   @cacerts_loaded = false
+@@ -283,7 +294,7 @@
+   ctx.timeout = @timeout
+   ctx.options = @options
+   ctx.ciphers = @ciphers
+-  ctx.ssl_version = @ssl_version
++  ctx.ssl_version = @ssl_version unless @ssl_version == :auto
+ end
+ 
+ # post connection check proc for ruby  1.8.5.
+--- a/test/test_ssl.rb
 b/test/test_ssl.rb
+@@ -33,7 +33,10 @@
+ assert_equal(OpenSSL::SSL::VERIFY_PEER | OpenSSL::SSL::VERIFY_FAIL_IF_NO_PEER_CERT, cfg.verify_mode)
+ assert_nil(cfg.verify_callback)
+ assert_nil(cfg.timeout)
+-assert_equal(OpenSSL::SSL::OP_ALL | OpenSSL::SSL::OP_NO_SSLv2, cfg.options)
++expected_options = OpenSSL::SSL::OP_ALL | OpenSSL::SSL::OP_NO_SSLv2 | OpenSSL::SSL::OP_NO_SSLv3
++expected_options = ~OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS if defined?(OpenSSL::SSL::OP_DONT_INSERT_EMPTY_FRAGMENTS)
++expected_options |= OpenSSL::SSL::OP_NO_COMPRESSION if defined?(OpenSSL::SSL::OP_NO_COMPRESSION)
++assert_equal(expected_options, cfg.options)
+ assert_equal(ALL:!aNULL:!eNULL:!SSLv2, cfg.ciphers)
+ assert_instance_of(OpenSSL::X509::Store, cfg.cert_store)
+   end
diff -Nru ruby-httpclient-2.3.3/debian/patches/series ruby-httpclient-2.3.3/debian/patches/series
--- ruby-httpclient-2.3.3/debian/patches/series	2014-06-27 00:41:13.0 +0200
+++ ruby-httpclient-2.3.3/debian/patches/series	2014-11-26 11:49:41.0 +0100
@@ -1,2 +1,3 @@
 0001-Remove-Hash-element-order-dependency.patch
 fix-port-allocation-in-tests.patch
+0003-fix-ssl-config.patch

Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange

[Tomasz Buchert]

Hi,
this patch is even more concise. It builds
properly on amd64 and i386 (at least).

Cheers,
Tomasz
diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog
--- statsmodels-0.4.2/debian/changelog	2012-06-29 23:26:49.0 +0200
+++ statsmodels-0.4.2/debian/changelog	2014-11-26 22:38:12.0 +0100
@@ -1,3 +1,10 @@
+statsmodels (0.4.2-1.1) testing; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes various problems with build process (Closes: #768695)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr  Wed, 26 Nov 2014 22:38:48 +0100
+
 statsmodels (0.4.2-1) unstable; urgency=low
 
   * Fresh upstream release addressing FTBFS across big-endian architectures.
diff -Nru statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch
--- statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch	1970-01-01 01:00:00.0 +0100
+++ statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch	2014-11-26 22:38:12.0 +0100
@@ -0,0 +1,14 @@
+Description: Fix building of docs
+ See https://github.com/matplotlib/matplotlib/issues/2967 for more info.
+
+--- a/docs/source/conf.py
 b/docs/source/conf.py
+@@ -33,7 +33,7 @@
+   'matplotlib.sphinxext.plot_directive',
+   'matplotlib.sphinxext.only_directives',
+   'ipython_console_highlighting',
+-  'ipython_directive',
++  'IPython.sphinxext.ipython_directive',
+   'numpy_ext.numpydoc']
+ 
+ # plot_directive is broken on old matplotlib
diff -Nru statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch
--- statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch	1970-01-01 01:00:00.0 +0100
+++ statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch	2014-11-26 22:59:46.0 +0100
@@ -0,0 +1,165 @@
+Description: Fix various testsuite problems
+ The testsuite depends on version-specific functionality
+ of various dependencies like numpy or scipy. This patch fixes
+ problems caused by versions in jessie release of these dependencies.
+ .
+ statsmodels/tools/tools.py:
+   = unexisting attribute in numpy object
+ statsmodels/sandbox/distributions/tests/testtransf.py:
+ statsmodels/tsa/filters/tests/test_filters.py:
+   = scipy interface incompatibilities
+ statsmodels/tsa/base/tests/test_datetools.py:
+   = DateRange class is not present in jessie pandas
+ statsmodels/sandbox/distributions/extras.py:
+   = a mistake fixed in newer releases of statsmodels
+ statsmodels/sandbox/tests/test_gam.py:
+   = incompatible scipy interface for rvs method
+ statsmodels/discrete/tests/test_discrete.py:
+   = failures due to differences between architectures, see
+  https://github.com/statsmodels/statsmodels/commit/ca701e7a
+
+--- a/statsmodels/tools/tools.py
 b/statsmodels/tools/tools.py
+@@ -231,7 +231,7 @@
+ 
+ def _series_add_constant(data, prepend):
+ const = np.ones_like(data)
+-const.name = 'const'
++# const.name = 'const'
+ if not prepend:
+ results = DataFrame([data, const]).T
+ results.columns = [data.name, 'const']
+--- a/statsmodels/sandbox/distributions/tests/testtransf.py
 b/statsmodels/sandbox/distributions/tests/testtransf.py
+@@ -88,8 +88,8 @@
+ (absnormalg, stats.halfnorm),
+ (absnormalg, stats.foldnorm(1e-5)),  #try frozen
+ #(negsquarenormalg, 1-stats.chi2),  # won't work as distribution
+-(squaretg(10), stats.f(1, 10))]  #try both frozen
+-
++#(squaretg(10), stats.f(1, 10))]  #try both frozen
++]
+ 
+ l,s = 0.0, 1.0
+ self.ppfq = [0.1,0.5,0.9]
+--- a/statsmodels/tsa/vector_ar/tests/test_svar.py
 b/statsmodels/tsa/vector_ar/tests/test_svar.py
+@@ -8,6 +8,7 @@
+ from results import results_svar
+ import numpy as np
+ import numpy.testing as npt
++import nose
+ 
+ DECIMAL_6 = 6
+ DECIMAL_5 = 5
+@@ -29,4 +30,5 @@
+ def test_A(self):
+ assert_almost_equal(self.res1.A, self.res2.A, DECIMAL_4)
+ def test_B(self):
++raise nose.SkipTest(This test is fixed in newer versions)
+ assert_almost_equal(self.res1.B, self.res2.B, DECIMAL_4)
+--- a/statsmodels/tsa/vector_ar/tests/test_var.py
 b/statsmodels/tsa/vector_ar/tests/test_var.py
+@@ -494,6 +494,7 @@
+ resultspath = basepath + '/tsa/vector_ar/tests/results/'
+ 
+ def get_lutkepohl_data(name='e2'):
++raise nose.SkipTest(Skipped because of missing DateRange)
+ lut_data = basepath + '/tsa/vector_ar/data/'
+ path = lut_data + '%s.dat' % name
+ 
+--- a/statsmodels/tsa/base/tests/test_datetools.py
 b/statsmodels/tsa/base/tests/test_datetools.py
+@@ -3,6 +3,7 @@
+ from statsmodels.tsa.base.datetools import (_date_from_idx,
+ _idx_from_dates, date_parser, date_range_str, dates_from_str,
+ dates_from_range, _infer_freq, _freq_to_pandas)
++import nose
+ 
+ def

Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange

[Tomasz Buchert]

On 25/11/14 10:57, Michael Banck wrote:
 On Sun, Nov 23, 2014 at 07:13:07PM +0100, Michael Banck wrote:
  Hi have uploaded the attached debdiff targetted at
  testing-proposed-updates to DELAYED/3-day.  See also the
  pre-approval/unblock bug for relesae.debian.org, #770730.

 Unfortunately, it FTBFS on i386 still, there are a couple of test suite
 failures:

 https://buildd.debian.org/status/fetch.php?pkg=statsmodelsarch=i386ver=0.4.2-1.1stamp=1416885423



 Michael

Oh no. This is a bit weird, though - these failures are only due to
some precision problems. One would think that operations on i386 and
amd64 would follow IEEE 754 and give the same result.

The testsuite is really, really fragile! I'll take a look later today.

Cheers,
Tomasz


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

Bug#768695: Bug #768695: statsmodels: FTBFS in jessie: ImportError: cannot import name DateRange

[Tomasz Buchert]

On 25/11/14 16:23, Yaroslav Halchenko wrote:

 On Tue, 25 Nov 2014, Tomasz Buchert wrote:
Hi have uploaded the attached debdiff targetted at
testing-proposed-updates to DELAYED/3-day.  See also the
pre-approval/unblock bug for relesae.debian.org, #770730.
   Unfortunately, it FTBFS on i386 still, there are a couple of test suite
   failures:
   https://buildd.debian.org/status/fetch.php?pkg=statsmodelsarch=i386ver=0.4.2-1.1stamp=1416885423
   Michael

  Oh no. This is a bit weird, though - these failures are only due to
  some precision problems. One would think that operations on i386 and
  amd64 would follow IEEE 754 and give the same result.

  The testsuite is really, really fragile! I'll take a look later today.

 Thanks in advance for your help
 In sid we have a better version I believe, but it fell through the
 freeze (for those failing tests never migrated to jessie in time)
 --
 Yaroslav O. Halchenko, Ph.D.
 http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
 Research Scientist,Psychological and Brain Sciences Dept.
 Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
 Phone: +1 (603) 646-9834   Fax: +1 (603) 646-1419
 WWW:   http://www.linkedin.com/in/yarik

Hi,
here is a new NMU with one more patch inside.  See its description for
more info. As a plus I've simplified and merged 2 older patches.

Tomasz
diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog
--- statsmodels-0.4.2/debian/changelog	2012-06-29 17:26:49.0 -0400
+++ statsmodels-0.4.2/debian/changelog	2014-11-25 20:00:04.0 -0500
@@ -1,3 +1,10 @@
+statsmodels (0.4.2-1.1) testing; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes various problems with build process (Closes: #768695)
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr  Wed, 26 Nov 2014 01:38:48 +0100
+
 statsmodels (0.4.2-1) unstable; urgency=low
 
   * Fresh upstream release addressing FTBFS across big-endian architectures.
diff -Nru statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch
--- statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch	1969-12-31 19:00:00.0 -0500
+++ statsmodels-0.4.2/debian/patches/0001-sphinx-ipython.patch	2014-11-25 19:59:40.0 -0500
@@ -0,0 +1,14 @@
+Description: Fix building of docs
+ See https://github.com/matplotlib/matplotlib/issues/2967 for more info.
+
+--- a/docs/source/conf.py
 b/docs/source/conf.py
+@@ -33,7 +33,7 @@
+   'matplotlib.sphinxext.plot_directive',
+   'matplotlib.sphinxext.only_directives',
+   'ipython_console_highlighting',
+-  'ipython_directive',
++  'IPython.sphinxext.ipython_directive',
+   'numpy_ext.numpydoc']
+ 
+ # plot_directive is broken on old matplotlib
diff -Nru statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch
--- statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch	1969-12-31 19:00:00.0 -0500
+++ statsmodels-0.4.2/debian/patches/0002-testsuite-fixes.patch	2014-11-25 20:15:10.0 -0500
@@ -0,0 +1,169 @@
+Description: Fix various testsuite problems
+ The testsuite depends on version-specific functionality
+ of various dependencies like numpy, scipy. This patches fixes
+ problems caused by versions in jessie release of these dependencies.
+ .
+ statsmodels/tools/tools.py:
+ = unexisting attribute in numpy object
+ statsmodels/sandbox/distributions/tests/testtransf.py:
+ statsmodels/tsa/filters/tests/test_filters.py:
+ = scipy interface incompatibilities
+ statsmodels/tsa/base/tests/test_datetools.py:
+ = DateRange class is not present in jessie pandas
+ statsmodels/sandbox/distributions/extras.py:
+ = a mistake fixed in newer releases of statsmodels
+ statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py
+ = incompatible scipy interface for rvs method
+
+Index: statsmodels-0.4.2/statsmodels/tools/tools.py
+===
+--- statsmodels-0.4.2.orig/statsmodels/tools/tools.py
 statsmodels-0.4.2/statsmodels/tools/tools.py
+@@ -231,7 +231,7 @@ def categorical(data, col=None, dictname
+ 
+ def _series_add_constant(data, prepend):
+ const = np.ones_like(data)
+-const.name = 'const'
++# const.name = 'const'
+ if not prepend:
+ results = DataFrame([data, const]).T
+ results.columns = [data.name, 'const']
+Index: statsmodels-0.4.2/statsmodels/sandbox/distributions/tests/testtransf.py
+===
+--- statsmodels-0.4.2.orig/statsmodels/sandbox/distributions/tests/testtransf.py
 statsmodels-0.4.2/statsmodels/sandbox/distributions/tests/testtransf.py
+@@ -88,8 +88,8 @@ class Test_Transf2(object):
+ (absnormalg, stats.halfnorm),
+ (absnormalg

Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE

[Tomasz Buchert]

On 23/11/14 03:03, Adam Borowski wrote:
 On Sun, Nov 23, 2014 at 02:07:42AM +0100, Christian Kastner wrote:
  On 2014-11-23 01:16, Adam Borowski wrote:
   On Sat, Nov 22, 2014 at 09:09:55PM +0100, Tomasz Buchert wrote:
   On 10/11/14 10:56, Christian Kastner wrote:
   I cannot confirm this bug in both cases I've tried:
  
 * amd64 (Linux 3.14-2-amd64 #1 SMP Debian 3.14.15-2 (2014-08-09) 
   x86_64 GNU/Linux)
 * amrhf (Linux 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 
   2014 armv7l GNU/Linux)
  
   My tests:
   armhf 3.8.13.28: FTBFS
 
  Was this either a Debian or a vanilla kernel? I ask because 3.8 kernels
  are often vendor-provided variants of certain ARM devices.

 I have heard myths of ARM devices that can run upstream kernels, but I have
 yet to see one :p.  This one is git://github.com/hardkernel/linux, a pretty
 well behaved one as vendor kernels go.

Guys, I went crazy and tested this assertion. I've upgraded the vendor
arm kernel to the testing kernel and guess what - it didn't boot...
(I'll have to fix it when I'm back home)

That said, one of the Debian developers built it for me on armhf
3.16.3 (slightly newer than the testing kernel) and it went fine.  If
you still think that it may not work in jessie, you could ask for
rebuild (https://release.debian.org/wanna-build.txt).  If not, you
could downgrade the severity to unblock keyutils for the jessie
release (I'm not sure if tagging with +sid will stop it being RC).

Tomasz


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

Bug#768905: FTBFS: fails test CHECK INVALID KEY TYPE

[Tomasz Buchert]

On 23/11/14 12:55, Christian Kastner wrote:
 (Tomasz, apparently I forgot to CC you on this mail yesterday, sorry)

 On 2014-11-23 02:55, Christian Kastner wrote:
  On 2014-11-23 01:16, Adam Borowski wrote:
  amd64 vanilla 3.16.7: builds ok
  amd64 vanilla 3.17.3: FTBFS
 
  I can confirm that is issue exists with 3.17.
 
  The syscall is returning ENOKEY where until 3.16 it was returning EPERM.

 I am now quite certain that the issue is being caused by this kernel
 commit in 3.17:

 Commit: a4e3b8d79a5c6d40f4a9703abf7fe3abcc6c3b8d
 KEYS: special dot prefixed keyring name bug fix

 The thing is, I'm not sure whether this needs to be fixed in keyutils,
 or in the kernel. I now contacted upstream about this. Depending on the
 answer, I'll either fix keyutils, or reassign to src:linux.

 Either way, I tagged this sid as it can only appear with a kernel that
 will not be part of Jessie. So that should solve the RC problem, no?

 Thank you for all your work, guys!

 Christian

My pleasure!
I think that this bug is not RC anymore - it is not listed
here: 
https://udd.debian.org/bugs/bugs/bugs/bugs/?release=jessie_and_sidpatch=ignmerged=igndone=ignfnewerval=7rc=1sortby=idsorto=ascctags=1ctags=1cdeferred=1#results
Good luck with 3.17 :D - if you need help, let me know.

Tomasz


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

Bug#770085: Grave severity

[Tomasz Buchert]

On 23/11/14 15:04, Benjamin Drung wrote:
 Am Samstag, den 22.11.2014, 12:12 +0100 schrieb Tomasz Buchert:
  On 22/11/14 11:32, Tomasz Buchert wrote:
   On 20/11/14 11:54, Tomasz Buchert wrote:
   [...]
   Here is a NMU debdiff for this bug.
   The Debian patches for Python3 support broke Python2 package.
   It's a story about naming the entry function for a module
   module which is slightly different in both version of Python.
  
   Note that there is a newer upstream version of pyhunspell.
   If you look for more minimal patch, I can make for you,
   since gbp pq renamed the original patches.
  
   Tomasz
 
  Sorry for too overloaded debdiff. Here is a concise one.

 Thanks for your patch. I have included it and added a smoke test that
 would have caught this bug. I also updated the watch file to point to
 the new upstream. Once jessie is released, the new upstream release
 should be packaged.

 --
 Benjamin Drung
 Debian  Ubuntu Developer


Thanks Benjamin,
you can package it even now, it will simply stay in unstable.

Tomasz


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

Bug#768695: NMU patch

[Tomasz Buchert]

Hi,
I attach a NMU patch which solves the bug at least on AMD64.
Please build in jessie environment.

Cheers,
Tomasz
diff -Nru statsmodels-0.4.2/debian/changelog statsmodels-0.4.2/debian/changelog
--- statsmodels-0.4.2/debian/changelog	2012-06-29 23:26:49.0 +0200
+++ statsmodels-0.4.2/debian/changelog	2014-11-23 17:55:26.0 +0100
@@ -1,3 +1,10 @@
+statsmodels (0.4.2-1.1) testing; urgency=medium
+
+  * Non-maintainer upload.
+  * Fixes various problems with build process
+
+ -- Tomasz Buchert tomasz.buch...@inria.fr  Sun, 23 Nov 2014 17:46:48 +0100
+
 statsmodels (0.4.2-1) unstable; urgency=low
 
   * Fresh upstream release addressing FTBFS across big-endian architectures.
diff -Nru statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch
--- statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch	1970-01-01 01:00:00.0 +0100
+++ statsmodels-0.4.2/debian/patches/scipy-rvs-interface.patch	2014-11-23 17:57:08.0 +0100
@@ -0,0 +1,128 @@
+Description: remove tests that use uncompatible scipy interface
+ The tests use an rvs method which has an incompatible
+ interface. We remove these failing tests altogother.
+
+--- statsmodels-0.4.2.orig/statsmodels/sandbox/tests/test_gam.py
 statsmodels-0.4.2/statsmodels/sandbox/tests/test_gam.py
+@@ -187,121 +187,3 @@ class TestAdditiveModel(BaseAM, CheckAM)
+ const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers])
+ #print const, slopes
+ res1.params = np.array([const] + slopes)
+-
+-
+-class BaseGAM(BaseAM, CheckGAM):
+-
+-def init(self):
+-nobs = self.nobs
+-y_true, x, exog = self.y_true, self.x, self.exog
+-if not hasattr(self, 'scale'):
+-scale = 1
+-else:
+-scale = self.scale
+-
+-f = self.family
+-
+-self.mu_true = mu_true = f.link.inverse(y_true)
+-
+-np.random.seed(8765993)
+-#y_obs = np.asarray([stats.poisson.rvs(p) for p in mu], float)
+-y_obs = self.rvs(mu_true, scale=scale, size=nobs) #this should work
+-m = GAM(y_obs, x, family=f)  #TODO: y_obs is twice __init__ and fit
+-m.fit(y_obs, maxiter=100)
+-res_gam = m.results
+-self.res_gam = res_gam   #attached for debugging
+-self.mod_gam = m   #attached for debugging
+-
+-res_glm = GLM(y_obs, exog, family=f).fit()
+-
+-#Note: there still are some naming inconsistencies
+-self.res1 = res1 = Dummy() #for gam model
+-#res2 = Dummy() #for benchmark
+-self.res2 = res2 = res_glm  #reuse existing glm results, will add additional
+-
+-#eta in GLM terminology
+-res2.y_pred = res_glm.model.predict(res_glm.params, exog, linear=True)
+-res1.y_pred = res_gam.predict(x)
+-res1.y_predshort = res_gam.predict(x[:10]) #, linear=True)
+-
+-#mu
+-res2.mu_pred = res_glm.model.predict(res_glm.params, exog, linear=False)
+-res1.mu_pred = res_gam.mu
+-
+-#parameters
+-slopes = [i for ss in m.smoothers for i in ss.params[1:]]
+-const = res_gam.alpha + sum([ss.params[1] for ss in m.smoothers])
+-res1.params = np.array([const] + slopes)
+-
+-
+-class TestGAMPoisson(BaseGAM):
+-
+-def __init__(self):
+-super(self.__class__, self).__init__() #initialize DGP
+-
+-self.family =  family.Poisson()
+-self.rvs = stats.poisson.rvs
+-
+-self.init()
+-
+-class TestGAMBinomial(BaseGAM):
+-
+-def __init__(self):
+-super(self.__class__, self).__init__() #initialize DGP
+-
+-self.family =  family.Binomial()
+-self.rvs = stats.bernoulli.rvs
+-
+-self.init()
+-
+-class _estGAMGaussianLogLink(BaseGAM):
+-#test failure, but maybe precision issue, not far off
+-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))
+-#0.80409736263199649
+-# np.mean(np.abs(tt.res2.mu_pred - tt.mu_true))/tt.mu_true.mean()
+-#0.023258245077813208
+-# np.mean((tt.res2.mu_pred - tt.mu_true)**2)/tt.mu_true.mean()
+-#0.022989403735692578
+-
+-def __init__(self):
+-super(self.__class__, self).__init__() #initialize DGP
+-
+-self.family =  family.Gaussian(links.log)
+-self.rvs = stats.norm.rvs
+-self.scale = 5
+-
+-self.init()
+-
+-
+-class TestGAMGamma(BaseGAM):
+-
+-def __init__(self):
+-super(self.__class__, self).__init__() #initialize DGP
+-
+-self.family =  family.Gamma(links.log)
+-self.rvs = stats.gamma.rvs
+-
+-self.init()
+-
+-class _estGAMNegativeBinomial(BaseGAM):
+-#rvs generation doesn't work, nbinom needs 2 parameters
+-
+-def __init__(self):
+-super(self.__class__, self).__init__() #initialize DGP
+-
+-self.family =  family.NegativeBinomial()
+-self.rvs = stats.nbinom.rvs
+-
+-self.init()
+-
+-if __name__ == '__main__':
+-t1 = TestAdditiveModel()
+-t1