Bug#847369: Error: Cannot find module 'requirejs' (missing package.json)

[GCS]

Hi Pirate,

On Wed, Dec 7, 2016 at 4:57 PM, Pirate Praveen <prav...@debian.org> wrote:
> The error I get when trying to use it from grunt-contrib-requirejs
> (available in
> git+ssh://git.debian.org/git/pkg-javascript/node-grunt-contrib-requirejs.git)
> is given below
>
> node-grunt-contrib-requirejs$ grunt --verbose
> Initializing
> Command-line options: --verbose
>
> Reading "Gruntfile.js" Gruntfile...OK
>
> Registering Gruntfile tasks.
> Initializing config...OK
>
> Registering "tasks" tasks.
> Loading "requirejs.js" tasks...ERROR
>>> Error: Cannot find module 'requirejs'
 Package is upadted and this is fixed.

> Also consider using pkg-javascript alioth repo for this package (there
> is a repo there, but it is outdated), so we can fix these kind of issues
> faster.
 Thanks, will consider it. I try to act fast, package is going to be
uploaded soon.

Regards,
Laszlo/GCS

Bug#828564: sx: FTBFS with openssl 1.1.0

[GCS]

Hi Sebastian,

On Mon, Dec 5, 2016 at 10:20 PM, Sebastian Andrzej Siewior
<sebast...@breakpoint.cc> wrote:
> On 2016-10-09 11:38:37 [+0300], Török Edwin wrote:
>> Patches to build with both OpenSSL 1.0.x, and 1.1.0 are available in the 
>> upstream git repository:
>> https://gitweb.skylable.com/gitweb/?p=sx.git;a=commitdiff;h=5acd940e97aa1f2bd1b3fdd41f4c98a5783fcb44
>> https://gitweb.skylable.com/gitweb/?p=sx.git;a=commitdiff;h=0dcacbab63325a83668d000dc8ed7da3bf0e4f7d
>> https://gitweb.skylable.com/gitweb/?p=sx.git;a=commitdiff;h=86e06686a5fe10fd823dff805f8439a791290c5b
>>
>> They apply on top of SX 2.2.
>
> Okay. What do we do here? Any idea Laszlo?
> I could try to cherry-pick the three patches into the currect 2.0 but I
> can't look at them because the git server seems to be down at the moment.
 I'm a bit confused to be honest. Upstream has a note that SX support
(or the entire SX) is closed down.
Edwin, does it mean that SX is no longer developed?

> Upstream asked about packaging 2.3 which makes sense (I think) but there
> is something regarding the update path If I read this correctly. And 2.3
> works with openssl 1.1 but needs to go via NEW due to libsxclient4 and I
> hope this "transition" is okay because libsxclient3 has no rdeps.
 I've packaged SX 2.3 and it looks fine - the upgrade path needs
testing. I had a plan to do it in a virtual machine (don't want to
hurt my real data), but then I didn't have time. Now I'm on holidays
for three days - I may need to go home sooner, but I can share the
packaging then.

Regards,
Laszlo/GCS

Bug#845687: [Pkg-protobuf-devel] Bug#845687: protobuf: FTBFS on ppc64el: testMergeFrom segmentation fault

[GCS]

Hi,

On Fri, Nov 25, 2016 at 9:34 PM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
> Source: protobuf
> Version: 3.0.0-8
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> The latest ppc64el build of protobuf failed:
[...]
> Could you please take a look?
 There are two problems and the first have a proposed patch. It seems
to be working, but the 'testMergeFrom' Python 3 check seem to still
fail sometimes, sometimes working at least on armel. I'll post more as
I know more details.

May you have a local ppc64el machine? What happens if you try the
build say three - four times?

Thanks,
Laszlo/GCS

Bug#828550: socat: FTBFS with openssl 1.1.0

[GCS]

Hi,

On Thu, Nov 24, 2016 at 9:12 PM, Gerhard Rieger
<gerh...@dest-unreach.org> wrote:
> find attached the adapted patch to socat-2.0.0-b9. Please check if it
> works for you!
 Any plans for a stable tagged 2.0.0 release? I still have 1.7.3.1 for
the next stable Debian release with the adopted patch, attached. The
only notable change that if OpenSSL 1.1+ is used for compilation, I
have to print that egd is not supported by the OpenSSL version - you
protected the function only, but not its call.

Thanks,
Laszlo/GCS
Description: fix build with OpenSSL 1.1.0+
 Makes compilation work with both OpenSSL 1.0 and 1.1 versions.
Bug-Debian: https://bugs.debian.org/828550
Origin: Sebastian Andrzej Siewior <sebast...@breakpoint.cc>
Author: Gerhard Rieger <gerh...@dest-unreach.org>
Last-Update: 2016-11-24

---

--- socat-1.7.3.1.orig/CHANGES
+++ socat-1.7.3.1/CHANGES
@@ -1,3 +1,8 @@
+porting:
+	Changes to make socat compile with OpenSSL 1.1. 
+	Thanks to Sebastian Andrzej Siewior e.a. from the Debian team for
+	providing the base patch.
+	Debian Bug#828550
 
 ### V 1.7.3.1:
 
--- socat-1.7.3.1.orig/config.h.in
+++ socat-1.7.3.1/config.h.in
@@ -447,6 +447,15 @@
 #undef HAVE_DTLSv1_client_method
 #undef HAVE_DTLSv1_server_method
 
+/* Define if you have the OpenSSL RAND_egd function */
+#undef HAVE_RAND_egd
+
+/* Define if you have the OpenSSL DH_set0_pqg function */
+#undef HAVE_DH_set0_pqg
+
+/* Define if you have the OpenSSL ASN1_STRING_get0_data function */
+#undef HAVE_ASN1_STRING_get0_data
+
 /* Define if you have the flock function */
 #undef HAVE_FLOCK
 
--- socat-1.7.3.1.orig/configure.in
+++ socat-1.7.3.1/configure.in
@@ -1450,6 +1450,9 @@ AC_CHECK_FUNC(TLSv1_2_client_method, AC_
 AC_CHECK_FUNC(TLSv1_2_server_method, AC_DEFINE(HAVE_TLSv1_2_server_method), AC_CHECK_LIB(crypt, TLSv1_2_server_method, [LIBS=-lcrypt $LIBS]))
 AC_CHECK_FUNC(DTLSv1_client_method, AC_DEFINE(HAVE_DTLSv1_client_method), AC_CHECK_LIB(crypt, DTLSv1_client_method, [LIBS=-lcrypt $LIBS]))
 AC_CHECK_FUNC(DTLSv1_server_method, AC_DEFINE(HAVE_DTLSv1_server_method), AC_CHECK_LIB(crypt, DTLSv1_server_method, [LIBS=-lcrypt $LIBS]))
+AC_CHECK_FUNC(RAND_egd, AC_DEFINE(HAVE_RAND_egd), AC_CHECK_LIB(crypt, RAND_egd, [LIBS=-lcrypt $LIBS]))
+AC_CHECK_FUNC(DH_set0_pqg, AC_DEFINE(HAVE_DH_set0_pqg), AC_CHECK_LIB(crypt, DH_set0_pqg, [LIBS=-lcrypt $LIBS]))
+AC_CHECK_FUNC(ASN1_STRING_get0_data, AC_DEFINE(HAVE_ASN1_STRING_get0_data), AC_CHECK_LIB(crypt, ASN1_STRING_get0_data, [LIBS=-lcrypt $LIBS]))
 
 dnl Run time checks
 
--- socat-1.7.3.1.orig/sslcls.c
+++ socat-1.7.3.1/sslcls.c
@@ -331,6 +331,7 @@ void sycSSL_free(SSL *ssl) {
return;
 }
 
+#ifndef OPENSSL_NO_EGD
 int sycRAND_egd(const char *path) {
int result;
Debug1("RAND_egd(\"%s\")", path);
@@ -338,6 +339,7 @@ int sycRAND_egd(const char *path) {
Debug1("RAND_egd() -> %d", result);
return result;
 }
+#endif
 
 DH *sycPEM_read_bio_DHparams(BIO *bp, DH **x, pem_password_cb *cb, void *u) {
DH *result;
--- socat-1.7.3.1.orig/xio-openssl.c
+++ socat-1.7.3.1/xio-openssl.c
@@ -878,7 +878,11 @@ int
}
 
if (opt_egd) {
+#ifndef OPENSSL_NO_EGD
   sycRAND_egd(opt_egd);
+#else
+  Debug("RAND_egd() is not available by OpenSSL");
+#endif
}
 
if (opt_pseudo) {
@@ -936,35 +936,48 @@ int
 	 0x02,
   };
   DH *dh;
+  BIGNUM *p = NULL, *g = NULL;
   unsigned long err;
 
-  if ((dh = DH_new()) == NULL) {
-	 while (err = ERR_get_error()) {
-	Warn1("DH_new(): %s",
-		   ERR_error_string(err, NULL));
-	 }
-	 Error("DH_new() failed");
-  } else {
-	 dh->p = BN_bin2bn(dh2048_p, sizeof(dh2048_p), NULL);
-	 dh->g = BN_bin2bn(dh2048_g, sizeof(dh2048_g), NULL);
-	 if ((dh->p == NULL) || (dh->g == NULL)) {
-	while (err = ERR_get_error()) {
-	   Warn1("BN_bin2bn(): %s",
-		 ERR_error_string(err, NULL));
-	}
-	Error("BN_bin2bn() failed");
-	 } else {
-	if (sycSSL_CTX_set_tmp_dh(*ctx, dh) <= 0) {
-	   while (err = ERR_get_error()) {
-		  Warn3("SSL_CTX_set_tmp_dh(%p, %p): %s", *ctx, dh,
-			ERR_error_string(err, NULL));
-	   }
-	   Error2("SSL_CTX_set_tmp_dh(%p, %p) failed", *ctx, dh);
-	}
-	/*! OPENSSL_free(dh->p,g)? doc does not tell so */
-	 }
-	 DH_free(dh);
-  }
+  dh = DH_new();
+  p = BN_bin2bn(dh2048_p, sizeof(dh2048_p), NULL);
+  g = BN_bin2bn(dh2048_g, sizeof(dh2048_g), NULL);
+  if (!dh || !p || !g) {
+ if (dh)
+DH_free(dh);
+ if (p)
+BN_free(p);
+ if (g)
+BN_free(g);
+ while (err = ERR_get_error()) {
+Warn1("dh2048 setup(): %s",
+  ERR_error_string(err, NULL));
+ }
+ Error("dh2048 setup failed");
+ goto cont_out;
+  }
+#if !HAVE_DH_set0_pqg
+  dh->p = p;
+  dh->g = g;

Bug#844479: zeromq3: zeromq 4.2.0 breaks tango

[GCS]

Hi Picca, Luca,

On Wed, Nov 23, 2016 at 3:25 PM, PICCA Frederic-Emmanuel
<frederic-emmanuel.pi...@synchrotron-soleil.fr> wrote:
>> This is very unfortunate, but as explained on the mailing list, this
>> behaviour was an unintentional internal side effect. I didn't quite
>> realise it was there, and so most other devs.
>
> I understand, I just wanted to point that the synchrotron community invest a 
> lot of efforts in order
> to provide a tango stack into Debian Stretch.
 As I understand (and remember) tango uses internal structures of
zeromq. Am I right? If so, can it be rewritten in a way to be more
zeromq version independent?

> It would a big fail for use if Debian stretch were released without tango.
 I would like to keep it, even if popcon score seems to be low.

>> How much work would it be to change tango to avoid relying on aligned
>> internal recv buffers?
>
> I spoke with the tango upstream, and they told me that this change is not 
> that trivial.
> This is unfortunate that it is so late in the release cycle of Debian.
> I think that they will not have the time to do this change before the 5 
> febuary.
 But it's not the first time when they are asked not to use internal
zeromq structures - not the first time tango has problems after a
zeromq update[1].

> I will keep you informed if something moves from their part.
 Please do.

> BUT I beg the zeromq3 maintainer to stick with 4.1.5 for Stetch.
 It's a bit hard to be equitable, which hand to bite: have an old
zeromq version maybe without security support or lose tango from
Stretch. :(

Regards,
Laszlo/GCS
[1] https://bugs.debian.org/743508

Bug#828550: socat: FTBFS with openssl 1.1.0

[GCS]

Hi Gerhard,

On Sat, Nov 5, 2016 at 9:46 PM, Gerhard Rieger <gerh...@dest-unreach.org> wrote:
> sorry for not replying so long, this was due to private issues I have.
> I intend to test for the new functions in autoconf and have the
> preprocessor conditionals check for these results instead of
> OPENSSL_VERSION_NUMBER.
 This is just a friendly ping if you have time for this issue or
should I use the other patch from Sebastian?

Kind regards,
Laszlo/GCS

Bug#843380: libgvc6 fail to install on stretch

[GCS]

Control: tags -1 +unreproducible
Control: tags -1 +moreinfo

On Sun, Nov 6, 2016 at 11:18 AM, Samuele Battarra <batta...@libero.it> wrote:
> Package: libgvc6
> Version: 2.38.0-16
> Severity: grave
> Justification: renders package unusable
[...]
> when I try to install graphviz I got this error:
[...]
> Warning: Could not load "/usr/lib/graphviz/libgvplugin_gd.so.6" - file not 
> found
> Segmentation fault
> dpkg: errore nell'elaborare il pacchetto libgvc6 (--configure):
>  il sottoprocesso installato script di post-installation ha restituito lo 
> stato di errore 139
>  Configurazione di libgvpr2 (2.38.0-16)...
>  dpkg: problemi con le dipendenze impediscono la configurazione di graphviz:
>   graphviz dipende da libgvc6; comunque:
> Il pacchetto libgvc6 non è ancora configurato.
 Strange, I can't reproduce it on the same architecture you have:
# dpkg --purge graphviz libxdot4 libpathplan4 libgvc6-plugins-gtk
libgvc6 libcgraph6 libcdt5 libgvpr2
# apt-get install graphviz
Setting up graphviz (2.38.0-16) ...
Processing triggers for libc-bin (2.24-5) ...
#

What happens if you issue 'apt-get -f install'?
Also, the file is in place after install:
$ ls -l /usr/lib/graphviz/libgvplugin_gd.so.6
/usr/lib/graphviz/libgvplugin_gd.so.6 -> libgvplugin_gd.so.6.0.0
$ ls -l /usr/lib/graphviz/libgvplugin_gd.so.6.0.0
-rw-r--r-- 1 root root 47240 Oct 20 17:43
/usr/lib/graphviz/libgvplugin_gd.so.6.0.0
It's also part of the package:
$ dpkg -S /usr/lib/graphviz/libgvplugin_gd.so.6
libgvc6: /usr/lib/graphviz/libgvplugin_gd.so.6

What's the output of:
$ ls -l /usr/lib/graphviz/libgvplugin_gd.so*
on your system?

I'm interested why do you get segmentation fault error during apt-get.

Regards,
Laszlo/GCS

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[GCS]

On Thu, Nov 3, 2016 at 11:16 PM, Sebastian Andrzej Siewior
<sebast...@breakpoint.cc> wrote:
> On 2016-11-03 22:02:23 [+0100], László Böszörményi (GCS) wrote:
>>  Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
>> ten with -j8 and it was working correctly. What's the result / current
>> problem at your end?
>
> As you see in [0]:
 OK, it remained the same then. May you try the work in progress
update[1]? I'm off for sleeping. :-/

Thanks,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/fetchmail_6.3.26-3.dsc

Bug#828299: fetchmail: FTBFS with openssl 1.1.0

[GCS]

On Thu, Nov 3, 2016 at 8:48 PM, Sebastian Andrzej Siewior
<sebast...@breakpoint.cc> wrote:
> On 2016-11-03 07:45:16 [+0100], Andreas Henriksson wrote:
> fetchmail builds against openssl 1.1.0. So we are good here.
> fetchmail fails to build with -j4.
> What do we do now? I retitled the bug. Can you reproduce this on your
> end?
 Nope. Tried in a loop of ten with -j2, other ten with -j4 and another
ten with -j8 and it was working correctly. What's the result / current
problem at your end?

Laszlo/GCS

Bug#828550: socat: FTBFS with openssl 1.1.0

[GCS]

On Thu, Nov 3, 2016 at 8:42 PM, Sandro Tosi <mo...@debian.org> wrote:
> On Mon, 5 Sep 2016 10:53:05 +0200 Gerhard Rieger
> <gerh...@dest-unreach.org> wrote:
>> Thank you, I will check!
>
> hey Gerhard, do you have a plan to look at this soon (now that openssl
> 1.1.0 bugs are RC)? thanks!
 Anything wrong with Sebastian Andrzej Siewior's patch? I plan to use
if no one objects.

Laszlo/GCS

Bug#841443: hmqv.h is missing: refered to by /usr/include/cryptopp/eccrypto.h

[GCS]

Hi Alexandre,

On Thu, Oct 20, 2016 at 8:46 PM, Alexandre Viau <av...@debian.org> wrote:
> It looks like hmqv.h is missing. It is refered by the following file:
>  - /usr/include/cryptopp/eccrypto.h
>
> The prevents the program I am working on to build.
 Working on the fix. May you share the program that you want to build?
I would like to be sure there's no more headers I might have missed to
install.

Thanks,
Laszlo/GCS

Bug#839138: Ceph maintainership status

[GCS]

Hi,

On Mon, Oct 17, 2016 at 8:34 PM, Adrian Bunk <b...@stusta.de> wrote:
> The current status of the Ceph packages [1] does not look good.
>
> src:ceph has 3 RC bugs, from "maintainer address bounces"
> to "crashes since the latest NMU".
 I think (hope) that even if the sender get back a mail that the list
is moderated, someone may check the queue and allow mails to the
mailing list after moderation (killing spam).

> If you still intend to maintain Ceph, do the emails from the BTS
> actually reach you? If not, a list at Alioth might be a better option.
 OK, I don't remember any Ceph bugreport - but I no longer closely
monitor the packaging.

> It would also be OK if you would state that there is noone left active
> among the Ceph Maintainers, and that I can orphan the package for
> finding new maintainers.
 I've hardware issues for long and can't use it - even worse, my
computer died some days ago as the motherboard has a short circuit on
it somewhere. I'm on the way to get an other, used computer which may
be used for Ceph as well. Still, I don't want to promise I can shake
up the packaging - even if it seems I'll need a stable distributed
filesystem in the future.

I'd a discussion with Dmitry and if I understood correctly, he no
longer wants to be a close contributor - but I let him speak about his
intentions.

Regards,
Laszlo/GCS

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[GCS]

Control: tags -1 +confirmed

Hi Lucas,

On Sun, Oct 9, 2016 at 9:06 PM, Lucas Nussbaum <lu...@debian.org> wrote:
> in the bug report, I wrote:
>> If the failure looks somehow time/timezone related:
 Sure, but tried in my unclean chroot, in an up-to-date+clean pbuilder
tree and on porterboxes. Then did a sourceful upload and it was
working everywhere, seems tzdata pulled in some other way.

> Did you try with tzdata not installed in the chroot?
 Just purged it and yes, confirm your findings.

> I can reproduce the failure with tzdata not installed. If I install tzdata, it
> builds fine. The package probably needs a build-depends on tzdata (and maybe a
> depends as well).
 Needs checking, now I don't think it needs a depends on tzdata.

Regards,
Laszlo/GCS

Bug#839418: libdbi-drivers: FTBFS: make[4]: *** [dbd_mysql/c98.html] Aborted

[GCS]

Control: tags -1 +unreproducible
Control: tags -1 +moreinfo
Control: severity -1 important

Hi Lucas,

On Sat, Oct 1, 2016 at 4:29 PM, Lucas Nussbaum <lu...@debian.org> wrote:
> Source: libdbi-drivers
> Version: 0.9.0-4
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161001 qa-ftbfs
> Justification: FTBFS on amd64
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
 Again, this is unreproducible. Tried several ways, please give me
more information how can I check this issue.

Thanks,
Laszlo/GCS

Bug#839454: [Syslog-ng-maintainers] Bug#839454: syslog-ng-incubator: FTBFS: dh_auto_test: make -j1 check VERBOSE=1 returned exit code 2

[GCS]

Control: tags -1 +unreproducible
Control: tags -1 +moreinfo
Control: severity -1 important

Hi Lucas,

On Sat, Oct 1, 2016 at 4:20 PM, Lucas Nussbaum <lu...@debian.org> wrote:
> Source: syslog-ng-incubator
> Version: 0.5.0-1
[...]
> Usertags: qa-ftbfs-20161001 qa-ftbfs
> Justification: FTBFS on amd64
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
 I've tried to reproduce it in a non-clean chroot, with an up-to-date
pbuilder and on an amd64 porterbox but couldn't. Just did a sourceful
upload (nothing related to this issue) and it was built on several
architectures including amd64.
It seems the FTBFS was a transient one or may you give me more
information about your setup, etc?

Regards,
Laszlo/GCS

Bug#837280: Dependency problem

[GCS]

Hi Michal,

On Tue, Sep 20, 2016 at 2:27 PM, Michal Čihař <mic...@cihar.com> wrote:
> this build failure is caused by mismatching versions of libpq-dev
> and postgresql used in the build.
>
> This is still problem in current sid:
>
> postgresql is 9.5 while libpq-dev is 9.6
>
> Possible ways to address it:
>
> - make postgresql packaging consistent
>
> - do not use pg_config to figure out binary path
>
> - Build-Depend on specific version (postgresql-9.6)
>
> As the last choice is least intrusive, I will probably NMU it  unless
> there will be some objections. See attached diff.
 Please don't get me wrong, but I still don't have any idea why did
you want to NMU this (in a bad way) when the root cause was the first
point: "make postgresql packaging consistent". The PSQL team was doing
a transition from the 9.5 to the 9.6 version - it's finished yesterday
and all packages are 9.6 now. This means libdbi-drivers builds fine
again.

Closing this bugreport,
Laszlo/GCS

Bug#825800: graphicsmagick: CVE-2016-5118

[GCS]

On Tue, Sep 20, 2016 at 9:56 AM, Stephan Großberndt
<s.grossber...@sidebysite.de> wrote:
> in the meantime its graphicsmagick 1.3.25-2 on Debian Stretch, but Jessie -
> which is the current stable release - still has 12 security issues going
> back to 2015:
 Yes, I consider this my fault. The other part is that there are way
to many fixes to integrate to 1.3.20 and I have other things to do as
well.

> Do you think 1.3.25-2 might be the used for a stable update?
 Upgrade to a newer version in stable is not easy and I can remember
one, maybe two cases when it was allowed.
In this case I'm not sure it should be the path.

Regards,
Laszlo/GCS

Bug#837280: Dependency problem

[GCS]

Hi Michal,

On Tue, Sep 20, 2016 at 2:27 PM, Michal Čihař <mic...@cihar.com> wrote:
> this build failure is caused by mismatching versions of libpq-dev
> and postgresql used in the build.
 I know, should have contacted the PostgreSQL team already.

> This is still problem in current sid:
>
> postgresql is 9.5 while libpq-dev is 9.6
>
> Possible ways to address it:
>
> - make postgresql packaging consistent
 This should be done as it may break other packages as well. Maybe
those are not yet uncovered.

> - do not use pg_config to figure out binary path
 If you know any other way, please let me know.

> - Build-Depend on specific version (postgresql-9.6)
 This mean I'll have to do a libdbi-drivers upload for every
PostgreSQL version change - just changing -9.6 to -9.7 and so on. This
package is not specific to any PSQL release and should be totally
unrelated to its current version number.

> As the last choice is least intrusive, I will probably NMU it  unless
> there will be some objections. See attached diff.
 Can be, but the worst solution as you can see above. Let me ask what
the PostgreSQL maintainers say.

Regards,
Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[GCS]

On Fri, Sep 16, 2016 at 3:38 PM, Bob Friesenhahn
<bfrie...@simple.dallas.tx.us> wrote:
> On Fri, 16 Sep 2016, László Böszörményi wrote:
>> On Fri, Sep 16, 2016 at 11:56 AM, Niko Tyni <nt...@debian.org> wrote:
>>> I've bisected it to
>>> https://sourceforge.net/p/graphicsmagick/code/ci/4ee2a87a67e064f3a094ee30b40a7a9bba1eb727/
>>>  Use clock_gettime() to obtain elapsed time.
>>
>> Indeed, confirmed that reverting this commit fixed the compilation on
>> ppc64el.
>> Thanks for your work, I was too slow doing it. :(
>
> This is all very strange.  I am not seeing a problem with the source code.
> I thought that the crash was happening at line 301 of log.c (at
> LockSemaphoreInfo()), and the first use of the timer APIs is at line 318 of
> log.c so this new code should not even be invoked yet.
 GCC generate bad assembly code on ppc64el for your code, not because
your source has any problem.

> Are you able to easily change the optimization of semaphore.c or log.c
> (maybe by injecting an optimization pragma into the code)?
 Yes, just done. Tested on ppc64el, now it compiles correctly.
Currently testing on amd64 and uploading the fixed package version
soon.

Cheers,
Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[GCS]

On Fri, Sep 16, 2016 at 11:56 AM, Niko Tyni <nt...@debian.org> wrote:
> On Tue, Sep 13, 2016 at 10:48:42PM -0500, Bob Friesenhahn wrote:
>> It may be necessary to prove where the problem is occuring by manually
>> overwriting updated files in the magick directory with those from the
>> previous working version until the problem goes away (assuming that it
>> does).
>
> I've bisected it to
>
>  
> https://sourceforge.net/p/graphicsmagick/code/ci/4ee2a87a67e064f3a094ee30b40a7a9bba1eb727/
>
>  Use clock_gettime() to obtain elapsed time.
 Indeed, confirmed that reverting this commit fixed the compilation on ppc64el.
Thanks for your work, I was too slow doing it. :(

> - it also goes away if LockSemaphoreInfo() in magick/semaphore.c is
>   optimized with -O0, which seems weird
 Do you mean that this alone is enough to fix this issue?

> I haven't found the exact optimization that's triggering it yet,
> and I haven't looked at the code GCC generates.
 It seems to be a GCC code defect, as you noted that even GCC 5 fails
to generate a working code.
I think I'll use the -O0 compilation workaround, don't want to further
delay the Perl transition.

Thanks again,
Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[GCS]

Hi Bob, Niko,

On Tue, Sep 13, 2016 at 11:15 PM, Bob Friesenhahn
<bfrie...@simple.dallas.tx.us> wrote:
> On Tue, 13 Sep 2016, László Böszörményi wrote:
>> On Tue, Sep 13, 2016 at 10:42 PM, Niko Tyni <nt...@debian.org> wrote:
>>> This package is failing to build on ppc64el, but built successfully
>>> in the past.
>> This is known and working with upstream to find the root cause.
> A backtrace from a core dump is needed.
 I'm not that good with gdb, but as a first shot this may give you more idea.
-- cut --
Core was generated by `/usr/bin/perl t/zlib/write.t '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000bffc8 in ?? ()
[...]
(gdb) thread apply all bt

Thread 1 (Thread 0x3fffb7ff65b0 (LWP 3923)):
#0  0x000bffc8 in ?? ()
#1  0x000bffcb in ?? ()
#2  0x3fffb796b320 in InitializeLogInfo () at magick/log.c:301
#3  0x3fffb796c62c in InitializeMagick (path=0x3fffb7bf0708
"Graphics::Magick") at magick/magick.c:1117
#4  0x3fffb7bf0074 in boot_Graphics__Magick (my_perl=0x10210010,
cv=) at Magick.xs:2064
#5  0x100e1960 in Perl_pp_entersub (my_perl=0x10210010) at pp_hot.c:3272
#6  0x100d8d88 in Perl_runops_standard (my_perl=0x10210010) at run.c:41
#7  0x10046f18 in Perl_call_sv (my_perl=0x10210010,
sv=0x1023ab78, flags=13) at perl.c:2779
#8  0x10049c3c in Perl_call_list (my_perl=0x10210010,
oldscope=, paramList=0x10213248) at perl.c:4995
#9  0x1001e3e0 in S_process_special_blocks
(my_perl=0x10210010, floor=39, fullname=0x1023c100 "BEGIN",
gv=0x1023a980, cv=0x1023ab78) at op.c:8916
#10 0x1003e028 in Perl_newATTRSUB_x (my_perl=0x10210010,
floor=39, o=, proto=, attrs=,
block=, o_is_gv=false) at op.c:8845
#11 0x100422b0 in Perl_utilize (my_perl=0x10210010,
aver=, floor=, version=,
idop=,
arg=) at op.c:6069
#12 0x1007f784 in Perl_yyparse (my_perl=0x10210010,
gramtype=) at perly.y:351
#13 0x1004ee1c in S_parse_body (xsinit=0x1001d490 ,
env=0x0, my_perl=0x10210010) at perl.c:2306
#14 perl_parse (my_perl=0x10210010, xsinit=0x1001d490 ,
argc=, argv=, env=0x0) at perl.c:1626
#15 0x1001d178 in main (argc=, argv=, env=) at perlmain.c:114
-- cut --

As Perl debug and libc6 debug symbols installed, I don't know which
library / executable may contain points #0 and #1. Maybe log.c itself?
At least the mentioned line in #2 is:
LockSemaphoreInfo(log_semaphore);

> There were no functions added or removed between 1.3.24 and 1.3.25 and not
> interfaces were changed.  If 1.3.24 still builds on the build machine, then
> it is possible to test by replacing individual source files in 1.3.25 with
> files from 1.3.24 and seeing when the problem goes away.  Since all tests
> are failing, the problematic code would need to be used in initialization,
> or somehow always encountered. Perhaps magick/utility.c would be a good
> starting point.
 Yes, 1.3.24 builds fine in the same environment. As previously noted
the broken change happened before 08th of August and it's not the
MAGICK_CACHE_LINE_SIZE value.

Cheers,
Laszlo/GCS

Bug#837719: graphicsmagick: FTBFS on ppc64el: PerlMagick test failures

[GCS]

On Tue, Sep 13, 2016 at 10:42 PM, Niko Tyni <nt...@debian.org> wrote:
> This package is failing to build on ppc64el, but built successfully
> in the past. As seen at
>  https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=ppc64el
> it regressed with 1.3.24+hg20160808-1, and the version currently in
> sid is still failing. It looks like this is preventing migration to testing.
 This is known and working with upstream to find the root cause.

> The list of toolchain package versions in the build logs suggests that
> the regression might be due to the switch to GCC 6.
 Definitely not. A code change in GraphicsMagick triggers it. I could
tighten it down, but don't know the exact cause yet.

Regards,
Laszlo/GCS

Bug#796298: tcplay: FTBFS: CMake Error at CMakeLists.txt:30 (message): Could not find the devmapper library

[GCS]

Hi Michael,

On Wed, Sep 7, 2016 at 12:36 AM, Michael Prokop <m...@debian.org> wrote:
> * László Böszörményi [Wed Aug 26, 2015 at 07:28:02AM +0200]:
>> On Fri, Aug 21, 2015 at 10:10 AM, Chris Lamb <la...@debian.org> wrote:
>> > From a cursory glance, devmapper.pc specifies Requires.Private librt,
>> > which doesn't have a  librt.pc (which is likely correct as it's meant to
>> > be linked statically? I'll leave it to you).
>
>>  You are right in the sense that without 'Requires.private:' the
>> devmapper library is found correctly. On the other hand I don't think
>> static linking is mandatory as libdevmapper.so.* exists and is under
>> /lib (no need to have /usr mounted, can be used in emergency shells as
>> well). Can be a cmake issue? Will investigate further.
>
> Any news here, László? I'm asking because this is an RC bug and
> therefore preventing tcplay to enter Debian/stretch.
 Last checked by me in May and couldn't make it compile as far as I
can remember.

> This issue was also reported towards upstream:
>   https://github.com/bwalex/tc-play/issues/50
 This is a very different one.

> I was trying to reproduce it, though couldn't:
>
> | -- Checking for module 'devmapper'
> | --   Found devmapper, version 1.02.133
>
> Instead if fails with:
[...]
> when compiling against current Debian/unstable. It looks like that's
> an issue of static vs dynamic library linking. When replacing:
>
>   set (CFLAGS_COMMON "-std=c99 -fPIE ${CFLAGS_LINUX} ${CFLAGS_WARN} 
> ${CFLAGS_VER}")
>
> in CMakeLists.txt with (so adding the '-fPIC' option there):
>
>   set (CFLAGS_COMMON "-std=c99 -fPIE -fPIC ${CFLAGS_LINUX} ${CFLAGS_WARN} 
> ${CFLAGS_VER}")
>
> it indeed compiles for me.
 Indeed, this fixes the current issue.

> Can you please take care of an according fixed package upload?
 Sure, it's in its way.

Thanks for the heads-up,
Laszlo/GCS

Bug#835983:

[GCS]

Control: severity -1 important

Hi Raphaël,

On Mon, Sep 5, 2016 at 12:13 PM, Raphael Hertzog <hert...@debian.org> wrote:
> did you see #835983 that I filed a few days ago? I did not offer an NMU
> because I know that you are usually quite reactive...
 Yes, from time to time I get mails on my mobile phone. This means I
can read those at least, but not able to answer those.

I'm not sure that the 'we need this in Kali' justifies the severity,
but sure needs to be solved. The breaks/replaces was added by Jonathan
Wiltshire[1].
Please note that python-pypdf is noted unmaintained[2]:
-- cut --
This page is no longer updated. I've stopped maintaining pyPdf [...]
-- cut --
The fork it refers to as continued development is disappeared. As
such, python-pypdf is not touched for more than six years[3] and it's
Python 2 only which may be deprecated somewhen soon. As I know, Ubuntu
doesn't ship it anymore for example. In the contrary, PyPDF2 has
Python 3 support, constantly updated and supported[4].
I think it would be better to update your software for PyPDF2 support.

> If the package had been part of the python-modules team, I would have
> fixed it by myself but for some reason you are the sole maintainer.
> If you need an NMU to help you, let me know.
 I'm going to upload a new package revision soon.

Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/p/pypdf2/news/20141010T113501Z.html
[2] http://pybrary.net/pyPdf/
[3] https://github.com/mfenniak/pyPdf/commits/trunk
[4] https://github.com/mstamy2/PyPDF2/commits/master

Bug#835669: wxsqlite3: FTBFS when built with dpkg-buildpackage -A (samples/minimal: not found)

[GCS]

On Sun, Aug 28, 2016 at 12:41 PM, Santiago Vila <sanv...@unex.es> wrote:
> On Sun, Aug 28, 2016 at 08:56:27AM +, Santiago Vila wrote:
>> please consider uploading the package in source-only form, [...]
>
> FWIW: Soruce-only uploads are done with "dpkg-buildpackage -S".
>
> You don't need any special tools or uploading to a special queue.
 I do know how to prepare it. What I don't know if it's a mandatory or
not to do source-only uploads.

Thanks,
Laszlo/GCS

Bug#782005: ovirt-guest-agent spu

[GCS]

On Wed, Aug 24, 2016 at 12:56 PM, Milan Zamazal <mzama...@redhat.com> wrote:
> "László Böszörményi (GCS)" <g...@debian.org> writes:
>> Please use the following: dget -x
>> http://www.barcikacomp.hu/gcs/ovirt-guest-agent_1.0.10.2.dfsg-2+deb8u1.dsc
[...]
> - With systemd, there is the same permission problem as in unstable with
>   /var/log/ovirt-guest-agent.  If I fix the directory owner then it
>   works for me.  Probably worth to add that fix to stable as well?
 Sure, proposed patch is updated. Will ask for PU in this afternoon.

Laszlo/GCS

Bug#782005: ovirt-guest-agent spu

[GCS]

On Mon, Aug 22, 2016 at 4:45 PM, Milan Zamazal <mzama...@redhat.com> wrote:
> László Böszörményi (GCS) <g...@debian.org> writes:
>> [1] dget -x 
>> http://http.debian.net/debian/pool/main/o/ovirt-guest-agent/ovirt-guest-agent_1.0.10.2.dfsg-2.dsc
>
> Is the URL correct?  This is the package from February 2015, isn't it?
 Indeed, I've pasted a wrong URL and didn't recognize. Please use the following:
dget -x 
http://www.barcikacomp.hu/gcs/ovirt-guest-agent_1.0.10.2.dfsg-2+deb8u1.dsc
Now double checked.

Thanks,
Laszlo/GCS

Bug#782005: ovirt-guest-agent spu

[GCS]

Hi,

On Wed, Jul 13, 2016 at 4:03 PM, Alexis HAUSER
<alexis.hau...@telecom-bretagne.eu> wrote:
> Is it possible for you to add the fixes for the 2 bugs mentioned on #811481 
> in stable-proposed-updates ?
 May you have time to check if the proposed update[1] work for you?

Thanks,
Laszlo/GCS
[1] dget -x 
http://http.debian.net/debian/pool/main/o/ovirt-guest-agent/ovirt-guest-agent_1.0.10.2.dfsg-2.dsc

Bug#832908: mongodb: CVE-2016-6494: world-readable .dbshell history file

[GCS]

On Sat, Jul 30, 2016 at 4:50 AM, kpcyrd <kpc...@rxv.cc> wrote:
> So, upstream just closed the issue I created with 'Works as Designed'
> blaming the default umask for the bug and that specifying file
> permissions for files created by mongodb is not something mongodb should
> do.
>
> https://jira.mongodb.org/browse/SERVER-25335#comment-1342085
>
> The bug is locked, what do I do now?
 You mean what to do with upstream? I guess nothing. Probably I can
fix this myself.
While this is a real issue, I somewhat agree with upstream. Being a
system administrator for long time, I know as others should know:
- don't run sensitive services on a machine which can be accessed by
untrusted users,
- even on your regular box set your $HOME to 0700 and your umask to 0077.
In short, always expect the worst case and be prepared.

Regards,
Laszlo/GCS

Bug#831677: [Syslog-ng-maintainers] Bug#831677: syslog-ng: breaks reverse-dependencies

[GCS]

Control: affects -1 - syslog-ng-incubator
Control: reassign -1 syslog-ng-incubator
Control: retitle -1 Should be updated for syslog-ng 3.7.0+

Hi Gianfranco,

On Mon, Jul 18, 2016 at 2:19 PM, Gianfranco Costamagna
<locutusofb...@debian.org> wrote:
> Source: syslog-ng
> Severity: serious
> Version: 3.7.3-1
> Affects: syslog-ng-incubator
 Actually the situation is vica - versa. As the package name suggests,
syslog-ng-incubator is a place where upstream tries experimental
modules. It is expected to break from time to time and needs more
frequent updates.

> Hi, while trying to rebuild syslog-ng-incubator on top of the new syslog-ng I 
> discovered it is actually FTBFS
> I tried to patch the source, because seems that stats.h has been moved into 
> stats/stats.h
>
> the problem is that seems syslog-ng introducing some more backward 
> incompatible changes, according to the new log
 Some modules merged to syslog-ng and left -incubator; on the other
hand some other experimental modules started to appear in the new
syslog-ng-incubator release. It means -incubator needs an update to
its 0.5.0 version at least. I've just uploaded it - as it will enter
the NEW queue, it needs some days to be accepted. But then everything
will be back to normal.

Thanks for your report,
Laszlo/GCS

Bug#811606: FTBFS with GCC 6: multiple errors

[GCS]

Hi Apollon,

On Thu, Jun 30, 2016 at 6:11 PM, Apollon Oikonomopoulos
<apoi...@debian.org> wrote:
> I think MongoDB 2.4 in unstable is already dead enough[1] that we should
> drop it before it gets a chance to build against GCC 6 in a couple of
> months. The attached patch fixes the FTBFS for the 2.6 package in
> experimental by disabling the newly-introduced warnings and patching
> (some) C++11 compatibility, but then again 2.6 will also be EOL by
> October[1].
 Yes, 2.6 has not too many time left. Still I think as a _first step_
it should be the next upload target. Reasons:
- proven, Ubuntu uses 2.6.11 from experimental without problems,
- easier and safer upgrade from the previous, 2.4 release.
I attach a debdiff for it, which builds with GCC 5.x and 6.y as well.
Please check it if you may have time. I plan to upload it in a week
timeline, maybe sooner if I don't find any problems with it.

> Note that most (if not all) of these warnings seem to be fixed in the
> 3.2 branch which IMHO should be the target version for Stretch.
 For the final Stretch release yes, 3.2 or 3.4 should be in the archives.

> I started a discussion with Làszlo quite a while ago regarding an
> updated MongoDB package, but didn't have the time to finish it, so I'd
> be happy to join you as well :)
 I'm always open to continue that with you. Sorry for the slow
response, I had big network problems at DebConf.
This is not the last place where I say thanks to Martin F. Krafft and
Jeffrey Walton for hardware donations, Wouter Verhelst and Gustavo
Panizzo for installer related helping. I owe you guys! While my
hardware problems don't end here, it's highly softened.

Thanks,
Laszlo/GCS
diff -Nur mongodb-2.6.11/debian/changelog mongodb-2.6.12/debian/changelog
--- mongodb-2.6.11/debian/changelog	2016-03-15 14:33:09.0 +
+++ mongodb-2.6.12/debian/changelog	2016-07-12 20:17:34.0 +
@@ -1,3 +1,16 @@
+mongodb (1:2.6.12-1) unstable; urgency=low
+
+  * New upstream release.
+  * Update Standards-Version to 3.9.8 .
+  * Upload to unstable.
+
+  [ Apollon Oikonomopoulos <apoi...@debian.org> ]
+  * Fix building with GCC 6 (closes: #811606):
+- disabling the newly-introduced warnings,
+- patching (some) C++11 compatibility.
+
+ -- Laszlo Boszormenyi (GCS) <g...@debian.org>  Tue, 12 Jul 2016 16:20:17 +
+
 mongodb (1:2.6.11-1) experimental; urgency=medium
 
   * New upstream release (closes: #748490).
diff -Nur mongodb-2.6.11/debian/control mongodb-2.6.12/debian/control
--- mongodb-2.6.11/debian/control	2016-03-15 11:16:17.0 +
+++ mongodb-2.6.12/debian/control	2016-07-12 18:03:26.0 +
@@ -23,7 +23,7 @@
  libv8-dev (>= 3.12) [!arm64 !ppc64el],
  python-pymongo,
  scons
-Standards-Version: 3.9.7
+Standards-Version: 3.9.8
 Vcs-Git: https://anonscm.debian.org/git/collab-maint/mongodb.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/mongodb.git/
 Homepage: https://www.mongodb.org
diff -Nur mongodb-2.6.11/debian/patches/fix-gcc-6-ftbfs.patch mongodb-2.6.12/debian/patches/fix-gcc-6-ftbfs.patch
--- mongodb-2.6.11/debian/patches/fix-gcc-6-ftbfs.patch	1970-01-01 00:00:00.0 +
+++ mongodb-2.6.12/debian/patches/fix-gcc-6-ftbfs.patch	2016-07-12 18:02:36.0 +
@@ -0,0 +1,67 @@
+Index: mongodb-2.6.11/SConstruct
+===
+--- mongodb-2.6.11.orig/SConstruct
 mongodb-2.6.11/SConstruct
+@@ -858,6 +858,10 @@ if nix:
+  "-Wno-unused-variable",
+  "-Wno-maybe-uninitialized",
+  "-Wno-unknown-pragmas",
++			 "-Wno-misleading-indentation",
++			 "-Wno-deprecated-declarations",
++			 "-Wno-nonnull-compare",
++			 "-Wno-error=overflow",
+  "-Winvalid-pch"] )
+ # env.Append( " -Wconversion" ) TODO: this doesn't really work yet
+ if linux or darwin:
+Index: mongodb-2.6.11/src/mongo/db/exec/working_set.cpp
+===
+--- mongodb-2.6.11.orig/src/mongo/db/exec/working_set.cpp
 mongodb-2.6.11/src/mongo/db/exec/working_set.cpp
+@@ -119,7 +119,7 @@ namespace mongo {
+ }
+ 
+ bool WorkingSetMember::hasComputed(const WorkingSetComputedDataType type) const {
+-return _computed[type];
++return _computed[type].get();
+ }
+ 
+ const WorkingSetComputedData* WorkingSetMember::getComputed(const WorkingSetComputedDataType type) const {
+Index: mongodb-2.6.11/src/mongo/db/pipeline/document_source_sort.cpp
+===
+--- mongodb-2.6.11.orig/src/mongo/db/pipeline/document_source_sort.cpp
 mongodb-2.6.11/src/mongo/db/pipeline/document_source_sort.cpp
+@@ -99,7 +99,7 @@ namespace mongo {
+ bool DocumentSourceSort::coalesce(const intrusive_

Bug#825800: graphicsmagick: CVE-2016-5118

[GCS]

Hi Carsten,

On Tue, Jul 5, 2016 at 1:13 PM, Carsten Leonhardt <l...@debian.org> wrote:
> maybe it would be possible to use 1.3.24 for a stable update? I think
> the current situation with the unpatched graphicsmagick in stable is
> quite unacceptable.
 I agree, graphicsmagick needs to be updated as soon as possible. I've
identified all fixes that need backporting for Jessie, but those over
one hundred. I had a quick mail with upstream that one fix caused
regression, but as I know, it's fixed since then.

I don't think 1.3.24 would be an easy target for Jessie. Maybe apply
the first set of patches, release it as a DSA, then add the others, a
new DSA... But it's also not the best idea.
I include the Security Team to this discussion, what they say about this.

Regards,
Laszlo/GCS

Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized

[GCS]

On Sun, Jul 3, 2016 at 1:46 PM, Christian Kastner <c...@debian.org> wrote:
> On 2016-07-03 12:30, László Böszörményi (GCS) wrote:
>> In that clean chroot, may you rebuild -13 from source? Then install
>> it still in that chroot and see the output of 'dot'.
>
> You were right: with a rebuilt -13, jpeg is no longer present in
> 'device', either:
 Checked the build logs and -13 was built with libjpeg-turbo 1.4.2 and
-14 with 1.5.0 which is a new upstream release and rearranged at least
one pkg-config file. Tried to downgrade libjpeg-turbo 1.4.2 and
rebuilt -13, but the jpeg is still missing from 'devices'. Give me
some days to further look into it until I have a network setup which
likes me. Now it's hard. :(

Laszlo/GCS

Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized

[GCS]

On Sun, Jul 3, 2016 at 10:52 AM, Christian Kastner <c...@debian.org> wrote:
> On 2016-07-03 09:26, László Böszörményi (GCS) wrote:
>>  Was it part of the 'Format' output? Do you still see advertised jpeg
>> support via 'loadimage' when you issue 'dot -v notexist'?
>
> Relevant output from -13:
> device  :  canon cmap cmapx cmapx_np dot eps fig gd gd2 gif gv imap 
> imap_np ismap jpe jpeg jpg pdf pic plain plain-ext png pov ps ps2 svg svgz tk 
> vml vmlz vrml wbmp x11 xdot xdot1.2 xdot1.4 xlib
> loadimage   :  (lib) eps gd gd2 gif jpe jpeg jpg png ps svg xbm
 Aha! It should be part both of 'device' and 'loadimage'.

> I downloaded them from snapshot.debian.org. Yesterday, I just downgraded
> the package, but today I used a clean chroot.
>
> $ for package in graphviz libcdt5 libcgraph6 libgvc6 libxdot4 libvgpr2; \
> do \
> debsnap --destdir . -a amd64 $package 2.38.0-13; \
> done
 In that clean chroot, may you rebuild -13 from source? Then install
it still in that chroot and see the output of 'dot'.

>>  Can be. I've the sources for -13 and -14 locally and I've rebuilt -13
>> in a mostly clean chroot. After downgrading to it, I still get the
>> 'jpeg' format not recognized error. This strengthens me in that it's
>> not a problem in graphviz itself, but an underlying library. Maybe
>> related to the Jasper (JPEG2000 support) removal[1]?
>
> Strange. As I said, above test against was done against a clean -13
> chroot.
 The rebuild mentioned above would help if it's really some library is
missing that previously compiled statically to 'dot' or not.

Thanks,
Laszlo/GCS

Bug#827806: pyevolve: FTBFS: Program terminated with status: 1. stderr follows: Format: "jpeg" not recognized

[GCS]

Hi Christian,

On Sat, Jul 2, 2016 at 10:05 PM, Christian Kastner <c...@debian.org> wrote:
> On 2016-07-02 22:03, Christian Kastner wrote:
>> Support for jpeg seems to have disappeared in graphviz 2.38.0-14:
>>
>> $ dot -Tjpeg
>> Format: "jpeg" not recognized. Use one of: canon cmap cmapx cmapx_np dot 
>> eps fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 
>> svg svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
 Was it part of the 'Format' output? Do you still see advertised jpeg
support via 'loadimage' when you issue 'dot -v notexist'?

>> With 2.38.0-13, everything is still fine.
 Do you still have it in your apt cache or how did you get the
binaries? I may try to test those during DebConf'16, but please note
I've serious network problems. I got an USB WiFi card for my laptop,
which is said to work correctly in a desktop machine. But in my
laptop, after a minute (maybe less) it fails to connect to anything.
Nothing related in the logs. If I renew my IP (ifdown / ifup), I get
an other minute of network. This kills me and makes even simple
internet browsing hard. :(

> This is probably related to #827675.
 Can be. I've the sources for -13 and -14 locally and I've rebuilt -13
in a mostly clean chroot. After downgrading to it, I still get the
'jpeg' format not recognized error. This strengthens me in that it's
not a problem in graphviz itself, but an underlying library. Maybe
related to the Jasper (JPEG2000 support) removal[1]?

Cheers,
Laszlo/GCS
[1] 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=jasper-rm;users=j...@debian.org

Bug#812041: thrift-compiler: diff for NMU version 0.9.1-2.1

[GCS]

Hi Tony,

On Fri, Jul 1, 2016 at 6:42 AM, tony mancill <tmanc...@debian.org> wrote:
> I've prepared an NMU for thrift-compiler (versioned as 0.9.1-2.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer or if you would like me to dcut the upload.
 Sure, I should have fixed it before. Your update seems fine. I'm at
DebConf16 with a bad enough link; also I travel without my GnuPG key.
I can't do an update myself for the next ten days and even I don't
have any more fixes to add. Go ahead with your NMU as you wish.

> Also, I would be interested in collaborating on an update to a newer
> version of the thrift compiler.  Please let me know if you are amenable
> to that.
 Did you try the experimental package version from 'thrift' source? It
has a self-test issue on several architectures, but otherwise should
be fine and up-to-date.

Cheers,
Laszlo/GCS

Bug#813247: python*-greenlet*: unhandled symlink to directory conversion: /usr/share/doc/PACKAGE

[GCS]

Hi Andreas,

On Sat, Jan 30, 2016 at 11:01 PM, Andreas Beckmann <a...@debian.org> wrote:
> an upgrade test with piuparts revealed that your package installs files
> over existing symlinks and possibly overwrites files owned by other
> packages. This usually means an old version of the package shipped a
> symlink but that was later replaced by a real (and non-empty)
> directory. This kind of overwriting another package's files cannot be
> detected by dpkg.
>
> This was observed on the following upgrade paths:
>
>   jessie -> sid
 I've fixed it, but not 101% sure in the result. I couldn't even run
my local piuparts jessie -> sid upgrade test as:
# piuparts --skip-logrotatefiles-test --warn-on-others --no-eatmydata
--scriptsdir /etc/piuparts/scripts --allow-database
--warn-on-leftovers-after-purge  --mirror
'http://ftp.de.debian.org/debian main' --tmpdir /mnt/1/piuparts --arch
amd64 -b [PATH]/jessie-amd64-base.tgz -d stable -d sid --apt
python-greenlet-dbg=0.4.9-2
It fails that can't find 0.4.9-2 version of python-greenlet-dbg.
May you check the proposed package update[1]?

Thanks in advance,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/python-greenlet_0.4.10-1.dsc

Bug#821676: graphviz: Disable PHP bindings

[GCS]

Hi Ondřej,

On Fri, Jun 10, 2016 at 7:54 AM, Ondřej Surý <ond...@sury.org> wrote:
> could you please apply attached patch that disable PHP bindings. It
> doesn't look like swig is going to be updated any time soon and graphviz
> is one of the last packages preventing src:php5 removal from testing.
 I had a false hope upstream will do the update; as the
bugreport[1][2] states: "I've done most of the PHP backend work
recently, but this is not something I'm likely to have time to work on
in the near future." But it seems things don't improve, will do the
upload to disable the PHP5 bindings in the afternoon.

Thanks for the heads-up,
Laszlo/GCS
[1] http://www.graphviz.org/mantisbt/view.php?id=2584
[2] https://github.com/swig/swig/issues/571

Bug#825800: graphicsmagick: CVE-2016-5118 on jessie

[GCS]

Hi Stephan,

On Mon, Jun 6, 2016 at 1:43 PM, Stephan Großberndt
<s.grossber...@sidebysite.de> wrote:
> what is the reason there is no fix for graphicsmagick CVE-2016-5118 on
> jessie? this is the current stable debian distribution, wheezy and sid have
> released fixes but none for jessie?
 I don't want to comment on the Wheezy update. I need time with the
Jessie one, it's my fault; even if it's part of the number of fixes
need to be backported. Please see the Sid changelog[1].

> Is graphicsmagick no longer supported by debian?
 As you noted above, Sid + Wheezy already updated; so it is supported.

Regards,
Laszlo/GCS
[1] https://packages.qa.debian.org/g/graphicsmagick/news/20160530T232158Z.html

Bug#823702: Should qpid-cpp be removed?

[GCS]

Hi Moritz,

On Sat, May 7, 2016 at 11:00 PM, Moritz Muehlenhoff <j...@debian.org> wrote:
> Source: qpid-cpp
> Severity: serious
>
> It hasn't seen an upload for more than two years, has unfixed open
> security issues for more than 1.5 years and the version in sid
> is totally outdated.
 Agreed.

> Please reassign this to ftp.debian.org for removal or update the package.
 Already working on the update, but I need time with it. A week, maybe
more. :( The new version contains new binary packages while removed
others.

Thanks for the heads-up,
Laszlo/GCS

Bug#822866: new vips lets nip2 fail to build

[GCS]

Control: tags -1 + confirmed pending

Hi Matthias,

On Thu, Apr 28, 2016 at 4:30 PM, Matthias Klose <d...@debian.org> wrote:
> 8.2-1 breaks the nip2 build, apparently not having a new dependency in the
> -dev package:
 Thanks for watching over my shoulders. Upstream is going to release
VIPS 8.3.1 with bugfixes in the next few days. I'll update the
dependencies with that upload.

Regards,
Laszlo/GCS

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[GCS]

On Sun, Apr 10, 2016 at 2:14 PM, gregor herrmann <gre...@debian.org> wrote:
> On Sat, 02 Apr 2016 12:02:51 +0300, Niko Tyni wrote:
>> As noticed by the ci.debian.net test setup, this package
>> currently fails its test suite, making it fail to build.
>>
>>  
>> https://ci.debian.net/packages/libd/libdatabase-dumptruck-perl/unstable/amd64/
[...]
>> This was broken by the recent sqlite3_3.12.0-1 upgrade in unstable.
>> The libdbd-sqlite3-perl test suite is still passing, though.
>>
>> I don't see anything clearly fitting in the SQLite 3.12 release notes at
>>  http://sqlite.org/releaselog/3_12_0.html
>> so maybe it's a regression?
>>
>> Needs further investigation, but cc'ing the sqlite3 maintainer as a heads-up.
>
> Still the same failure with today's upload of sqlite3 3.12.1-1.
 Please retest with the just uploaded sqlite3 3.12.2-1 package
version. Works now on my box, but waiting for your confirmation.

Regards,
Laszlo/GCS

Bug#821079: syslog-ng json-c transition

[GCS]

Control: severity -1 wishlist
Control: tags -1 wontfix

Hi Ondřej,

I'm sure and even tested that syslog-ng won't hold back the json-c
transition - only need to be binNMUed.
Upstream just took extra care on portability. The code in question[1]
emulates the missing json_tokener_error_desc() with
json_tokener_errors[] if the json-c library is an old version (#ifndef
JSON_C_VERSION).

As this helps backporting, I don't see a reason to remove this piece of code.

Regards,
Laszlo/GCS
[1] 
https://sources.debian.net/src/syslog-ng/3.5.6-2.1/modules/json/jsonparser.c/#L168

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[GCS]

On Wed, Apr 13, 2016 at 11:32 AM, Tobias Frost <t...@frost.de> wrote:
> Am 13. April 2016 10:33:28 MESZ, schrieb "László Böszörményi (GCS)"
> <g...@debian.org>:
>> On Wed, Apr 13, 2016 at 9:39 AM, Tobias Frost <t...@debian.org> wrote:
>>>  As I'd like to push things (especially the libpng1.6 transition)
>>> forward, I will NMU if successful.
>>
>>  If possible, please send a patch instead. I can do a normal upload fast.
>
> I just applied both patches from the BTs.
 OK, I see. Ping me when you finished your tests and those didn't
failed. I'm going to eat sooner or later, but will do the upload as
soon as I can.

Thanks for your time,
Laszlo/GCS

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[GCS]

Hi Tobias,

On Wed, Apr 13, 2016 at 9:39 AM, Tobias Frost <t...@debian.org> wrote:
> Package: vice
> Followup-For: Bug #725629
>
> I'm currently rebuilding vice in a loop on fischer.debian.org with both 
> patches applied and it looks quite good so far.
>
> As I'd like to push things (especially the libpng1.6 transition) forward, I 
> will NMU if successful.
 If possible, please send a patch instead. I can do a normal upload fast.

Cheers,
Laszlo/GCS

Bug#725629: vice: racy build

[GCS]

On Mon, Apr 11, 2016 at 8:40 PM, Steven Chamberlain <ste...@pyro.eu.org> wrote:
> Tobias Frost wrote:
> I notice there is already a patch for this called
> kfreebsd_no_machine_cpufunc.h.patch
> although, you still had it applied for that build:
 That's correct and previously it worked. Please see that 2.4.26 built
on kfreebsd-i386 and on kfreebsd-amd64 already. Only when it was
binNMUed failed on kfreebsd-i386.

> It patches vice-2.3.dfsg/configure.proto (what is that?) and not
> configure.ac;  and I imagine the latter one is being used now.
 Please see Makefile.am:
-- cut --
$(top_srcdir)/configure.ac: $(top_srcdir)/configure.proto
$(am__cd) $(srcdir) && $(SHELL) autogen.sh
-- cut --

As such, for configure.ac autogen.sh is used, which contains this:
-- cut --
if test x"$configure_needs_ac" = "xyes"; then
sed s/AM_CONFIG_HEADER/AC_CONFIG_HEADERS/g
configure.ac
else
cp configure.proto configure.ac
fi
-- cut --

This means configure.proto just copied over configure.ac or 'sed' is
used for substitution to generate configure.ac from the former. This
means any patching of configure.ac will be lost and thus not needed.
The patch is used to prevent the header error, on kFreeBSD
architectures it has an empty case (skip that header); on other
architectures it looks for that cpufunc.h header:
-- cut --
-AC_CHECK_HEADERS(unistd.h sys/io.h machine/pio.h machine/cpufunc.h)
+AC_CHECK_HEADERS(unistd.h sys/io.h machine/pio.h)
+case "$host_os" in
+  *kfreebsd*)
+;;
+  *)
+AC_CHECK_HEADERS(machine/cpufunc.h)
+;;
+esac
-- cut --

Still seems to be the correct way for me.

Regards,
Laszlo/GCS

Bug#725629: vice: racy build

[GCS]

On Mon, Apr 11, 2016 at 6:47 PM, Tobias Frost <t...@debian.org> wrote:
> Good and bad new...
> Anbes patch seems to work; but vice fails later.
> Tried 2 times, same result.
> (I saw this (or a similar) build error also yesterday, so I think it is
> not related to the patch)
>
> snippet:
>
> /usr/include/i386-kfreebsd-gnu/machine/cpufunc.h:42:2: error: #error
> "This header must not be used in combination with ."
>  #error "This header must not be used in combination with ."
>   ^
 Easy to test; what happens if you compile the vanilla package without
Andreas' patch?

Laszlo/GCS

Bug#804297: graphviz: dot on mipsel fails with emit.c:3873: bezier_bb: Assertion `bz.size > 0' failed

[GCS]

On Mon, Apr 11, 2016 at 10:37 AM, Hector Oron <zu...@debian.org> wrote:
> Compiling graphviz with -fno-ipa-sra helps and makes the issue go away.
>
> The other option would be to disable graphs.
>
> While GCC upstream decides, I would prefer to build graphviz with 
> -fno-ipa-sra,
> at least for mips/mipsel architectures. Would that be fine with graphviz
> maintainer? Failing that we should fallback to disable graphs in wayland
> package and many others which might need and have already done so.
 I can compile with -fno-ipa-sra and this is not a problem. Will do it
in the afternoon.

Thanks for the tip,
Laszlo/GCS

Bug#725629: vice: racy build

[GCS]

On Mon, Apr 11, 2016 at 9:15 AM, Andreas Beckmann <a...@debian.org> wrote:
> [ this analysis is has been superseded by bug #820658 I filed against make ]
 Yeah, just read that. Do you think anything will happen on the side
of make? Especially as below you can be right that filesystem
timestamp resolution is the real problem.

> The (intersting part of the) diff between
>
> [GOOD] 
> https://buildd.debian.org/status/fetch.php?pkg=vice=kfreebsd-i386=2.4.dfsg%2B2.4.26-1=1458846545
> [BAD]  
> https://buildd.debian.org/status/fetch.php?pkg=vice=kfreebsd-i386=2.4.dfsg%2B2.4.26-1%2Bb1=1460088757
>
> starts with
>
> @@ -2959,12 +2990,6 @@
> | sed -e '$s/\\$//')  POTFILES-t \
>   chmod a-w POTFILES-t \
>   mv POTFILES-t POTFILES )
> -cd .. \
> -   CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= \
> -   /bin/sh ./config.status
> -config.status: creating po/Makefile.in
> -config.status: executing depfiles commands
> -config.status: executing default-1 commands
>  make[2]: 'intl2po' is up to date.
>  make[2]: Leaving directory '/«BUILDDIR»/vice-2.4.dfsg+2.4.26/po'
>  /usr/bin/make trans-update -C po/
>
> So po/POTFILES has been updated, but po/Makefile has not been regenerated, 
> causing the future breakage due to an empty POTFILES variable.
> For some reason make thinks that po/Makefile does not need to be regenerated.
 Then maybe an old timestamp on Makefile would help it?

> Of course I could not reproduce that problem :-)
 Don't worry, me neither nor upstream could do it. :-/

> But I'd suggest the following for further debugging:
> * drop try-to-fix-possible-race-condition.patch
> * collect some timestamps:
 OK, but as you suspect this may build next time and so on, then it
will just break again. Well, maybe the 'ls' calls will make it work,
due to the extra time it needs to execute those. But then I can add
'sleep 1' between the 'make' calls.

> I don't think we have here a "race condition" by some kind of parallelism.
> I would more suspect a filesystem time resolution problem. Maybe even a bug 
> in make itself.
> IIRC the file systems used by kfreebsd and hurd only have second resolution, 
> while (most) Linux filesystems have (up to) nanosecond resolution.
 That would explain why the breakage happens way too often on Hurd and
kFreeBSD machines.

Thanks,
Laszlo/GCS

Bug#725629: vice: racy build

[GCS]

On Sun, Apr 10, 2016 at 8:51 AM, Tobias Frost <t...@debian.org> wrote:
> Happened again :(
... and again. Strange that it happens mostly on kFreeBSD, on Hurd
from time to time, but rarely on other architectures.

Laszlo/GCS

Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure

[GCS]

On Sun, Apr 10, 2016 at 2:04 PM, gregor herrmann <gre...@debian.org> wrote:
> On Sat, 02 Apr 2016 12:10:20 +0300, Niko Tyni wrote:
>> As noticed by the ci.debian.net test setup, this package
>> currently fails its test suite, making it fail to build.
> It builds again for me after today's upload of sqlite3 3.12.1-1.
 Confirmed, compiles normally on amd64. You can close this bug as you
are the package maintainer.

Laszlo/GCS

Bug#725629: vice: racy build

[GCS]

On Sun, Apr 10, 2016 at 8:51 AM, Tobias Frost <t...@debian.org> wrote:
> Happened again :(
 I'm out of ideas. :( Tried to reproduce it many-many times locally
without success. Upstream gave a possible idea and possible fix - then
I do step by step compilation of that part. It still fails randomly
even if it's rare.
May you have information on the kFreeBSD-386 buildd? CPU and memory,
but its average load may be enough alone.

Laszlo/GCS

Bug#820225: libsqlite3-0: Segmentation fault (core dumped)

[GCS]

Hi Chris,

On Wed, Apr 6, 2016 at 11:47 PM, Chris Lamb <ch...@chris-lamb.co.uk> wrote:
>> libsqlite3-0: Segmentation fault (core dumped)
>
> Backtrace attached.
 In the log the entry points are missing, ie:
#0  0x7f5fda58df46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7f5fda58df46 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f5fd75f9125 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#2  0x7f5fd763e9fa in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#3  0x7f5fd76400e9 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#4  0x7f5fd7642714 in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
#5  0x7f5fd7669b5b in ?? () from /usr/lib/x86_64-linux-gnu/libsqlite3.so.0

Do you have libsqlite3-0-dbg installed?

Regards,
Laszlo/GCS

Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure

[GCS]

On Wed, Apr 6, 2016 at 1:37 PM, Niko Tyni <nt...@debian.org> wrote:
> On Wed, Apr 06, 2016 at 01:07:17PM +0200, László Böszörményi wrote:
>>  It seems it'll stay. Please read the opinion of the main SQLite3 
>> developer[1]:
>> "This could easily be considered a bug fix rather than a regression."
>> There are examples in his mail which demonstrate why a type of view is
>> unambiguous and should not be depend on. Hence they chose to return an
>> empty string for these queries.
>
> OTOH there's this trunk commit from yesterday:
>  http://www.sqlite.org/src/info/fb555c3c2af7f5e6
>
> which looks like it's trying to restore the older behaviour?
 Nope, it seems to implement the proposal I've mentioned in my last
email[1] just like commit log states: "Carry table column types
through into VIEW definitions, where possible."
If you read the diff you mentioned, it seems to confirm this. See the
right side addition (in green) of src/build.c:
In case 'pTable->pCheck' (maybe an abbreviation of parameter check)
returns true, then the parameters used as arguments for the VIEW (ie,
it's in the form: "CREATE VIEW name(arglist) AS"):
'The names of the columns in the table are taken from
arglist which is stored in pTable->pCheck.  The pCheck field
normally holds CHECK constraints on an ordinary table, but for
a VIEW it holds the list of column names.'
Then it parses the list with sqlite3ColumnsFromExprList() and if it
doesn't have errors (pParse->nErr==0) it adds the types with
sqlite3SelectAddColumnTypeAndCollation().

If the mentioned check returns false then it seems no type added
there. But later it's checked for a type (maybe in case of simple
columns and no action defined columns): zType = columnType() and if(
zType... ).
Then if the check succeeds, the type gets used:
memcpy(>zName[n+1], zType,...) (copying the type)
pCol->colFlags |= COLFLAG_HASTYPE; (flagging that it has a known type)

But I don't know the SQLite3 source, just read what it seems to be.

Laszlo/GCS
[1] http://article.gmane.org/gmane.comp.db.sqlite.general/100898

Bug#819787: libdbix-class-schema-loader-perl: FTBFS: t/10_01sqlite_common.t failure

[GCS]

On Wed, Apr 6, 2016 at 11:53 AM, Niko Tyni <nt...@debian.org> wrote:
> On Sat, Apr 02, 2016 at 12:10:20PM +0300, Niko Tyni wrote:
>> Package: libdbix-class-schema-loader-perl
>> Version: 0.07045-1
>> Severity: serious
>> User: debian-p...@lists.debian.org
>> Usertags: autopkgtest
>> X-Debbugs-Cc: sqli...@packages.debian.org
[...]
>>not ok 301 - columns for views are introspected
[...]
> This is due to a change in 'PRAGMA table_info' behaviour in 3.12.0. The
> "type" column in PRAGMA table_info() is now a blank string when the
> target object is a view.
[...]
> There's a thread about this at
>  http://thread.gmane.org/gmane.comp.db.sqlite.general/100856
> but it doesn't seem quite clear yet if this is an accidental regression
> or something that will stay.
 It seems it'll stay. Please read the opinion of the main SQLite3 developer[1]:
"This could easily be considered a bug fix rather than a regression."
There are examples in his mail which demonstrate why a type of view is
unambiguous and should not be depend on. Hence they chose to return an
empty string for these queries.
Of course, there's at least one proposed solution[2] for these cases.

Laszlo/GCS
[1] http://article.gmane.org/gmane.comp.db.sqlite.general/100860
[2] http://article.gmane.org/gmane.comp.db.sqlite.general/100898

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[GCS]

Control: forwarded -1
http://sqlite.1065341.n5.nabble.com/sqlite3-column-decltype-change-td88530.html

On Wed, Apr 6, 2016 at 8:46 AM, Niko Tyni <nt...@debian.org> wrote:
> On Wed, Apr 06, 2016 at 08:36:51AM +0200, László Böszörményi (GCS) wrote:
>>  I still don't know, but will post here what upstream says about this.
>> I've reported this issue[1], but the mailing list is private (online
>> bug reporting is not possible). :( All I know they've read it.
[...]
> There's a public archive of the sqlite-users list on gmane.org,
> here's a link to the relevant thread there FWIW:
>
>  http://thread.gmane.org/gmane.comp.db.sqlite.general/100862
 Aha! Found an even better archive, setting forwarded accordingly.

Laszlo/GCS

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[GCS]

On Sat, Apr 2, 2016 at 9:40 PM, Niko Tyni <nt...@debian.org> wrote:
> The root cause is that sqlite3_column_decltype() quotes its output in
> 3.12.0, where previously it didn't.
[...]
> So is this an intentional change or a regression?
 I still don't know, but will post here what upstream says about this.
I've reported this issue[1], but the mailing list is private (online
bug reporting is not possible). :( All I know they've read it.

Laszlo/GCS
[1] 
http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2016-April/065842.html

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[GCS]

On Sat, Apr 2, 2016 at 9:40 PM, Niko Tyni <nt...@debian.org> wrote:
> On Sat, Apr 02, 2016 at 12:10:31PM +0200, László Böszörményi wrote:
>> Its first parameter is the function the call and the second is the
>> expected result[1]. If I use sqlite3 3.11.1, then the function returns
>> an array, but not [666]. With sqlite3 3.12.0 it returns the expected
>> [666].
>
> The root cause is that sqlite3_column_decltype() quotes its output in
> 3.12.0, where previously it didn't.
[...]
> So is this an intentional change or a regression?
 I'm not its maintainer, but will ask upstream. The only change I've
found states[1]:
"The sqlite3_column_decltype() routine should return NULL, not an
empty string, if the column has no declared type."

Thanks for the test cases,
Laszlo/GCS
[1] http://www.sqlite.org/src/info/605eba4a756e7185

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[GCS]

On Sat, Apr 2, 2016 at 11:40 AM, Niko Tyni <nt...@debian.org> wrote:
> On Sat, Apr 02, 2016 at 11:20:02AM +0200, László Böszörményi (GCS) wrote:
>> I think libdatabase-dumptruck-perl upstream should be noted about this
>> issue. May check it locally, but please don't take my word on it.
>
> Thanks. I'll try to investigate this and the
> libdbix-class-schema-loader-perl issue myself further later, will keep
> you posted. And sure, upstream certainly needs to be notified too.
 OK. Did some local testing. First, libdatabase-dumptruck-perl doesn't
build depend on sqlite3 directly, but transitively via
libdbd-sqlite3-perl. Just a binNMU of the latter doesn't help. While
downgrading sqlite3 to 3.11.1 works, there's a strange going on with
the Perl test suite - with is_deeply() to be exact.
The failing line is in t/dumptruck.t:
is_deeply ($dt3->get_var('array_of_the_beast'), [666],
'Array variable retrieved');
Its first parameter is the function the call and the second is the
expected result[1]. If I use sqlite3 3.11.1, then the function returns
an array, but not [666]. With sqlite3 3.12.0 it returns the expected
[666].
As such I don't see why the test suite equals in the former an array
with [666]; then in the latter fails to make [666] equal to [666]. If
someone knows Perl better, please make some lights here. Maybe some
pointer vs value thing happens here.

Regards,
Laszlo/GCS
[1] http://sqa.fyicenter.com/Perl_Test_Tutorial/63_is_deeply_.html

Bug#819782: libdatabase-dump-perl: FTBFS: t/dumptruck.t failure

[GCS]

Hi Niko,

On Sat, Apr 2, 2016 at 11:02 AM, Niko Tyni <nt...@debian.org> wrote:
> Package: libdatabase-dumptruck-perl
> Version: 1.2-2
[...]
> As noticed by the ci.debian.net test setup, this package
> currently fails its test suite, making it fail to build.
>
>  
> https://ci.debian.net/packages/libd/libdatabase-dumptruck-perl/unstable/amd64/
>
>   #   Failed test 'Array variable retrieved'
>   #   at t/dumptruck.t line 133.
>   # Structures begin differing at:
>   #  $got = '[666]'
>   # $expected = ARRAY(0x29fbef8)
>   # Looks like you failed 1 test of 43.
[...]
> I don't see anything clearly fitting in the SQLite 3.12 release notes at
>  http://sqlite.org/releaselog/3_12_0.html
> so maybe it's a regression?
>
> Needs further investigation, but cc'ing the sqlite3 maintainer as a heads-up.
 I think the reason can be two things, quoting SQLite3 upstream:
- The SQLITE_DEFAULT_PAGE_SIZE is increased from 1024 to 4096.
- The SQLITE_DEFAULT_CACHE_SIZE is changed from 2000 to -2000 so the
same amount of cache memory is used by default.

There's a detailed description[1] on these, but upstream emphasize:
"Not a Compatibility Break" / "The only thing that is changing is some
default settings. This should result in a performance increase for
many applications.".
I think libdatabase-dumptruck-perl upstream should be noted about this
issue. May check it locally, but please don't take my word on it.

Regards,
Laszlo/GCS
[1] http://sqlite.org/pgszchng2016.html

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[GCS]

Hi Julian,

On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor
<jtaylor.deb...@googlemail.com> wrote:
> On 20.03.2016 11:11, László Böszörményi (GCS) wrote:
>>  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
>> new upstream version of pyzmq (15.2) for two months. It seems to be
>> security related according to the release log[1]:
>> - FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
>> - workaround overflow bug in libzmq preventing receiving messages
>> larger than MAX_INT
[...]
> The latest version does unfortunately not fix the problem. It is also
> not security related, it just could not send large data due to bugs in zmq.
> I guess a good approach would be to bisect zmq to see what they changed
> to cause it.
 Just a friendly ping; could you test the latest Git master if that
fixes the hang and/or could you ask upstream for advice? Should I do
it? It seems it constantly get fixes that may be relevant.

Cheers,
Laszlo/GCS

Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Thu, Mar 24, 2016 at 11:54 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On 21/03/16 19:59, Luca Boccassi wrote:
>> Given the change of the -dev package name here, should I roll back and b-d 
>> again on libzmq3-dev? I don't mind doing another upload if it's the right 
>> thing.
>
> Yes that'd be fine, but there's no rush.
 I still would be happier with libzmq5-dev to keep it consistent with
the library name. Sure, once zeromq is removed, it can be libzmq-dev -
I do not see a reason to switch back to libzmq3-dev meanwhile.

Cheers,
Laszlo/GCS

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Sun, Mar 20, 2016 at 12:27 PM, Julian Taylor
<jtaylor.deb...@googlemail.com> wrote:
> On 20.03.2016 11:11, László Böszörményi (GCS) wrote:
>> On Sun, Mar 20, 2016 at 10:56 AM, Emilio Pozuelo Monfort
>> <po...@debian.org> wrote:
>>> Got a chance to look at this?
>>  Sorry, my life was chaotic. Yes and no, checked it. First, there's a
>> new upstream version of pyzmq (15.2) for two months. It seems to be
>> security related according to the release log[1]:
[...]
> The latest version does unfortunately not fix the problem. It is also
> not security related, it just could not send large data due to bugs in zmq.
> I guess a good approach would be to bisect zmq to see what they changed
> to cause it.
 Still any reason not to update it for Sid? Can you try Git master
branch for building? That contains several fixes.
While the same company develops ZeroMQ and the Python bindings as
well, do you have contact with their Python team? It may worth to ask
them, they may know what's the cause of the hang is.

Regards,
Laszlo/GCS

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Sun, Mar 20, 2016 at 10:56 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On Tue, 15 Mar 2016 23:37:26 +0100
> =?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= <g...@debian.org> wrote:
>> On Tue, Mar 15, 2016 at 11:24 PM, Julian Taylor
>> <jtaylor.deb...@googlemail.com> wrote:
>> > On 15.03.2016 22:48, László Böszörményi (GCS) wrote:
>>  While I was checking the failing build logs, I see:
>> build/temp.linux-armv7l-2.7/scratch/tmp/timer_createOfMQXG.o: In
>> function `main':
>> timer_createOfMQXG.c:(.text+0x14): undefined reference to `timer_create'
>> collect2: error: ld returned 1 exit status
>>
>> It's not just the implicit declaration, but a linker error later. I
>> can be wrong, but it seems it _may_ cause the test hang as there's no
>> timer to look for / to wait its expiration. Sorry if it happens in
>> normal logs as well; will check it tomorrow morning as it's almost
>> midnight here. :(
 Checked, it happens in normal build logs as well.

> Got a chance to look at this?
 Sorry, my life was chaotic. Yes and no, checked it. First, there's a
new upstream version of pyzmq (15.2) for two months. It seems to be
security related according to the release log[1]:
- FIX: unicode/bytes bug in password prompt in zmq.ssh on Python 3
- workaround overflow bug in libzmq preventing receiving messages
larger than MAX_INT

My computer is old and has problems; even the archive version hangs
during self-tests. Still, it may help if Julian update the package to
the latest version. With my Python Modules team member hat on, should
I do it myself?
Just for the record, upstream Git tree has even more fixes that not
yet released as a new version.

Regards,
Laszlo/GCS
[1] https://pyzmq.readthedocs.org/en/latest/changelog.html

Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?

[GCS]

Hi,

On Fri, Jan 8, 2016 at 2:16 PM, Yves-Alexis Perez <cor...@debian.org> wrote:
> I'm reporting against linux-patch-grsecurity2 package but actually I
> think it should be reassigned to ftp.debian.org soon. This package is
> severely obsolete, and is somehow deprecated by the fact that a
> linux-grsec source package now exists, and builds binaries for i386 and
> amd64 (with more architectures certainly possible).
 It seems linux-grsec will remain i386 and amd64 only. But more
important that's not suitable for a stable release. Filed by its
maintainer, Yves-Alexis. The patch itself can be updated more easily
with point releases and users may compile and test their updated
kernels before using it. For me this gives more trust in the package,
even if it needs more attention from time to time.

> I can certainly let you request the removal, or will handle it myself at
> one point, unless you really want to keep it and have it updated.
 Sure, I've failed big to keep it up-to-date. But I would like to keep
this fresh in the archive. Hope upstream will release testing kernels
every now and then.

Regards,
Laszlo/GCS

Bug#810349: linux-patch-grsecurity2: removal of linux-patch-grsecurity2?

[GCS]

On Thu, Mar 17, 2016 at 1:43 PM, Yves-Alexis Perez <cor...@debian.org> wrote:
> On jeu., 2016-03-17 at 10:20 +0100, László Böszörményi (GCS) wrote:
>>  It seems linux-grsec will remain i386 and amd64 only.
>
> There's no reason to, actually. It's just that right now I don't have a way to
> test on other architectures, so I prefer keeping it that way. But if someone
> steps to to maintain it I'm all open.
 Ah, OK. That makes sense.

>>  But more
>> important that's not suitable for a stable release. Filed by its
>> maintainer, Yves-Alexis.
>
> Well, uploading new Linux major version to stable looks indeed not trivial,
> (thus my filing of #810506), but ultimately it's the RT's call.
 I mean can you remain in sync with kernel updates (security updates
only) in stable?

>>  The patch itself can be updated more easily
>> with point releases and users may compile and test their updated
>> kernels before using it. For me this gives more trust in the package,
>> even if it needs more attention from time to time.
>
> Well, I'm not sure how much sense that make. Do you intend to ship in stable a
> patch completely unrelated to the current kernel and just follow the test
> kernel and ship it pristine?
 It's better to write in detail about my point of view. With the patch
only I would target more experienced users that can and do compile
their kernels. The plan is to have two kind of patches shipped in the
package. One tracking the stable release kernel as close as possible
(security updates only). The second is to add the latest test patch
say, every six months. This can give users a time to follow upstream
kernel development while have the up-to-date testing patch on top of
it. OK, they will need to compile and use their own kernels - but this
also gives more flexibility to them as they can choose which feature
of grsecurity to enable + use.
With a packaged binary kernel you don't have the freedom to choose the
options and harder to get it included in a stable release. Especially
if it's maintained and tested by multiple maintainers to support
several architectures and not just i386 and amd64.

>> > I can certainly let you request the removal, or will handle it myself at
>> > one point, unless you really want to keep it and have it updated.
>>  Sure, I've failed big to keep it up-to-date. But I would like to keep
>> this fresh in the archive. Hope upstream will release testing kernels
>> every now and then.
>
> I'm not sure what you mean here.
 I would like to keep Sid updated and provide updated patches for
stable kernel packages. For this I need upstream to release testing
patches in a timely manner. But as mentioned above, I think six months
updates may be enough for advanced users. You get new features while
not compile a new kernel every second day. This seems to be a good
balance.

Hope this is more clear now.
Laszlo/GCS

Bug#818265: Bug#818187: Bug#818265: Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Tue, Mar 15, 2016 at 11:24 PM, Julian Taylor
<jtaylor.deb...@googlemail.com> wrote:
> On 15.03.2016 22:48, László Böszörményi (GCS) wrote:
>>  This is known to pyzmq upstream[1] for about three years. It happens
>> on Ubuntu, Red Hat, CentOS and with ZeroMQ 4.0.x as well. While
>> timer_create() [4] is in librt, the standard GNU C library, it seems
>> pyzmq miss to link with it on the failing architectures.
[...]
> Are you saying linking against -lrt will fix the tests deadlocking?
>
> I don't quite see the relation between the hanging tests and the linked
> issues.
> The implicit declaration errors have always been there I think but only
> in a configure check so harmless (until now?).
 While I was checking the failing build logs, I see:
build/temp.linux-armv7l-2.7/scratch/tmp/timer_createOfMQXG.o: In
function `main':
timer_createOfMQXG.c:(.text+0x14): undefined reference to `timer_create'
collect2: error: ld returned 1 exit status

It's not just the implicit declaration, but a linker error later. I
can be wrong, but it seems it _may_ cause the test hang as there's no
timer to look for / to wait its expiration. Sorry if it happens in
normal logs as well; will check it tomorrow morning as it's almost
midnight here. :(

Laszlo/GCS

Bug#818318: git: CVE-2016-2324 and CVE-2016-2315 (currently unpublished) server and client RCE, fixed in 2.7.1

[GCS]

On Tue, Mar 15, 2016 at 10:13 PM, Ximin Luo <infini...@debian.org> wrote:
> http://seclists.org/oss-sec/2016/q1/645
>
> Please upload 2.7.1 ASAP.
 Just for the record, it should be 2.7.3 due to an integer overflow
fix[1] (no CVE). On the other hand, CVE-2016-2315 is already fixed in
Stretch and Sid[2] with the 2.7.0 version.

Laszlo/GCS
[1] https://github.com/git/git/commit/13e0b0d3dc76353632dcb0bc63cdf03426154317
[2] https://security-tracker.debian.org/tracker/CVE-2016-2315

Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Tue, Mar 15, 2016 at 10:26 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On 14/03/16 22:03, Emilio Pozuelo Monfort wrote:
>> Looks good. No problem and thanks for reacting that fast!
>
> I scheduled the binNMUs last night and things are going well. The only issue
> seems to be pyzmq, see #818265.
 This is known to pyzmq upstream[1] for about three years. It happens
on Ubuntu, Red Hat, CentOS and with ZeroMQ 4.0.x as well. While
timer_create() [4] is in librt, the standard GNU C library, it seems
pyzmq miss to link with it on the failing architectures. User reports
says that 'pip install pyzmq --install-option="--zmq=/usr/lib"' forces
the linking. I don't know how pass it to setup.py (not using pip
directly) and the path should be multiarch aware for us.

Hope this helps,
Laszlo/GCS
[1] https://github.com/zeromq/pyzmq/issues/391
[2] https://github.com/zeromq/pyzmq/issues/468
[3] https://github.com/zeromq/pyzmq/issues/658
[4] http://man7.org/linux/man-pages/man2/timer_create.2.html

Bug#818222: libzeromq-perl: uses old libzmq1, should switch to libzmq5

[GCS]

On Mon, Mar 14, 2016 at 10:17 PM, gregor herrmann <gre...@debian.org> wrote:
> On Mon, 14 Mar 2016 20:46:06 +0100, Emilio Pozuelo Monfort wrote:
>> Yes. Bumping this to RC so we don't release stretch with it, and opening
>> bugs for the rdeps.
>
> Changing the build dep from libzmq-dev to libzmq5-dev is not enough
> it seems:
[...]
 This is expected. Please note that zeromq is 2.x, while zeromq3 went
through 3.x -> 4.0.x -> 4.1.x evolution.
Please ask your upstream to port the code to the latest (4.1) zeromq version.

Regards,
Laszlo/GCS

Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Mon, Mar 14, 2016 at 8:58 PM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> Renaming a -dev package because the soname changed is bad. The only reason
> to do it in this case is so that things don't look "odd".
 The main reason the soname is in the -dev package name is that the
simple 'libzmq-dev' is part of the zeromq package. But yes, it could
have remain as libzmq3-dev even if it looks inconsistent with libzm5.

> What I think should happen here is:
>
> The package is renamed back to libzmq3-dev, so rdeps can be binNMUed.
>
> A provides can be added for the packages that changed, since their
> build-deps are not versioned. After libzmq5-dev is decrufted, they will be
> fine.
>
> Then the transition can complete.
>
> How does that sound?
 I see and agree. Attached the next upload just to be sure. Please ACK
it and I'll upload it.

Sorry for the extra round,
Laszlo/GCS
diff -Nru zeromq3-4.1.4/debian/changelog zeromq3-4.1.4/debian/changelog
--- zeromq3-4.1.4/debian/changelog	2016-03-02 18:38:45.0 +0100
+++ zeromq3-4.1.4/debian/changelog	2016-03-14 21:42:34.0 +0100
@@ -1,3 +1,10 @@
+zeromq3 (4.1.4-7) unstable; urgency=medium
+
+  * Switch back libzmq5-dev package name to libzmq3-dev for the transition
+(closes: #818187).
+
+ -- Laszlo Boszormenyi (GCS) <g...@debian.org>  Mon, 14 Mar 2016 20:48:59 +0100
+
 zeromq3 (4.1.4-6) unstable; urgency=low
 
   * Fix FTBFS with GCC 6 (closes: #812049).
diff -Nru zeromq3-4.1.4/debian/control zeromq3-4.1.4/debian/control
--- zeromq3-4.1.4/debian/control	2016-02-29 19:53:30.0 +0100
+++ zeromq3-4.1.4/debian/control	2016-03-14 21:39:08.0 +0100
@@ -27,12 +27,13 @@
  .
  This package contains the libzmq shared library.
 
-Package: libzmq5-dev
+Package: libzmq3-dev
 Architecture: any
 Section: libdevel
 Depends: libzmq5 (= ${binary:Version}), ${misc:Depends}
-Conflicts: libzmq-dev, libzmq3-dev
-Replaces: libzmq3-dev
+Conflicts: libzmq-dev, libzmq5-dev
+Replaces: libzmq5-dev
+Provides: libzmq5-dev
 Multi-Arch: same
 Description: lightweight messaging kernel (development files)
  ØMQ is a library which extends the standard socket interfaces with features
diff -Nru zeromq3-4.1.4/debian/libzmq3-dev.install zeromq3-4.1.4/debian/libzmq3-dev.install
--- zeromq3-4.1.4/debian/libzmq3-dev.install	1970-01-01 01:00:00.0 +0100
+++ zeromq3-4.1.4/debian/libzmq3-dev.install	2014-03-16 14:02:31.0 +0100
@@ -0,0 +1,5 @@
+usr/include/*
+usr/lib/*/libzmq.a
+usr/lib/*/libzmq.so
+usr/lib/*/pkgconfig/libzmq.pc
+debian/zmq.hpp usr/include
diff -Nru zeromq3-4.1.4/debian/libzmq3-dev.manpages zeromq3-4.1.4/debian/libzmq3-dev.manpages
--- zeromq3-4.1.4/debian/libzmq3-dev.manpages	1970-01-01 01:00:00.0 +0100
+++ zeromq3-4.1.4/debian/libzmq3-dev.manpages	2014-03-16 14:02:31.0 +0100
@@ -0,0 +1,2 @@
+debian/tmp/usr/share/man/man3/*
+debian/tmp/usr/share/man/man7/*
diff -Nru zeromq3-4.1.4/debian/libzmq5-dev.install zeromq3-4.1.4/debian/libzmq5-dev.install
--- zeromq3-4.1.4/debian/libzmq5-dev.install	2014-03-16 14:02:31.0 +0100
+++ zeromq3-4.1.4/debian/libzmq5-dev.install	1970-01-01 01:00:00.0 +0100
@@ -1,5 +0,0 @@
-usr/include/*
-usr/lib/*/libzmq.a
-usr/lib/*/libzmq.so
-usr/lib/*/pkgconfig/libzmq.pc
-debian/zmq.hpp usr/include
diff -Nru zeromq3-4.1.4/debian/libzmq5-dev.manpages zeromq3-4.1.4/debian/libzmq5-dev.manpages
--- zeromq3-4.1.4/debian/libzmq5-dev.manpages	2014-03-16 14:02:31.0 +0100
+++ zeromq3-4.1.4/debian/libzmq5-dev.manpages	1970-01-01 01:00:00.0 +0100
@@ -1,2 +0,0 @@
-debian/tmp/usr/share/man/man3/*
-debian/tmp/usr/share/man/man7/*

Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Mon, Mar 14, 2016 at 8:13 PM, Matthias Klose <d...@debian.org> wrote:
> On 14.03.2016 20:04, László Böszörményi (GCS) wrote:
>>   I've noted all depending package maintainers back then. Yes, didn't
>> prevent the testing migration of zeromq3. But some maintainers did the
>> migration to libzmq5-dev (uwsgi, czmq and jzmq comes to my mind);
>> changing it back to libzmq3-dev would cause more problems with these
>> packages.
>
> that's why libzmq3-dev now provides libzmq5-dev.
 I see vice-versa. It should remain libzmq5-dev due to the soname and
provide libzmq3-dev for binNMUs.

Laszlo/GCS

Bug#818187: zeromq3 migrated without any transition being done

[GCS]

On Mon, Mar 14, 2016 at 7:41 PM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On Mon, 14 Mar 2016 19:24:38 +0100 Matthias Klose <d...@debian.org> wrote:
>> zeromq3 migrated to testing without any transition being done, leaving the
>> cruft
>> packages libzmq3 and libzmq3-dev in the archive. Now every b-d on
>> libzmq3-dev
>> would need to be replaced with libzmq5-dev, or better rename libzmq5-dev
>> back to
>> libzmq3-dev, so depending packages can be binNMUed for the transition.
 I've noted all depending package maintainers back then. Yes, didn't
prevent the testing migration of zeromq3. But some maintainers did the
migration to libzmq5-dev (uwsgi, czmq and jzmq comes to my mind);
changing it back to libzmq3-dev would cause more problems with these
packages.

> Yes, please.
 Previously you asked for filing serious bugs against packages that
not transitioned yet. Does it still stand?

Regards,
Laszlo/GCS

Bug#725629: vice: sometimes FTBFS: error while opening "src/arch/win32/res.rc.po.c" for reading: No such file or directory

[GCS]

On Tue, Mar 8, 2016 at 11:08 AM, Graham Inggs <gin...@debian.org> wrote:
> This problem still occurs from time to time.
 While it's rare, it happens from time to time. :-( Even upstream
couldn't reliably reproduce it and hence no real solution exist to
prevent this. Now I try an other way, forcing the sequence it should
be built.

Regards,
Laszlo/GCS

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

[GCS]

On Thu, Mar 10, 2016 at 4:47 AM, Aaron M. Ucko <u...@debian.org> wrote:
> "László Böszörményi (GCS)" <g...@debian.org> writes:
>> Then I have to update the changelog closing the bugreport and rebuild
>> the package.  :)
>
> I do see how that could get a little frustrating.  It's too bad there's
> no lightweight way for you to publicly indicate awareness of a build
> failure short of filing a report yourself.
 I can send you an email in advance.

>>  No problem, next time I should wait more on you to file the bugreport.
>
> You know, you could also perform more sanity checks *before*
> uploading... ;-)
 My machine is so old that I'm happy it works and compiles packages
once in a reasonable time. But sure, there's ccache and I should have
realized documentation is built in the indep targets only - that
buildds don't execute.
It was degrading when I've patched a problem in an upstream source and
started compiling. While it was going, I've sent the patch upstream.
Some time later I got the answer, he patched the source, compiled and
tested the issue which is fine now. My box was still compiling that
source... :-/ I will be able to buy a new one this summer or autumn.
You are still right, I should do more sanity checks before uploading.

Offtopic: as I know, DebConf'17 will be close to you. Any plans to attend it?

Regards,
Laszlo/GCS

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

[GCS]

On Wed, Mar 9, 2016 at 11:30 PM, Aaron M. Ucko <u...@debian.org> wrote:
> "László Böszörményi (GCS)" <g...@debian.org> writes:
> I prefer to follow this whole procedure fairly frequently so that I
> don't have too many reports to file at any one time.
 OK, it just doesn't let the maintainer fix the issue. When I'm about
to upload the fixed package, I get a bugreport from you. Then I have
to update the changelog closing the bugreport and rebuild the package.
:)

> Sorry for the noise.
 No problem, next time I should wait more on you to file the bugreport.

Thanks for watching. Cheers,
Laszlo/GCS

Bug#817274: python-gevent: FTBFS: can't read debian/python-gevent-doc/...

[GCS]

On Wed, Mar 9, 2016 at 5:49 PM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
> Builds of python-gevent covering only its architecture-dependent
> binary packages (as on the autobuilders, or with dpkg-buildpackage -B)
> have been failing:
>
>   sed -i 's|http.*/btn_donateCC_LG.gif||' \
>   debian/python-gevent-doc/usr/share/doc/python-gevent-doc/html/sfc.html
>   sed: can't read 
> debian/python-gevent-doc/usr/share/doc/python-gevent-doc/html/sfc.html: No 
> such file or directory
[...]
> Please conditionalize this command appropriately.
 Yes, seen that and upload is pending.
While not a real issue, but is there any reason why you fire
bugreports immediately?

Cheers,
Laszlo/GCS

Bug#815942: jzmq: FTBFS: missing header inclusion

[Laszlo Boszormenyi (GCS)]

Source: jzmq
Version: 3.1.0-8
Severity: serious
Tags: patch
Usertags: ftbfs
Justification: FTBFS and holds back zeromq3 transition

Hi Jan,

jzmq currently FTBFS and the zeromq3 transition is just part of it.
You need to update the build dependencies and change libzmq3-dev to
libzmq5-dev. The other is a missing include in src/main/c++/Event.cpp.
zmq.hpp needs to be included for the zmq_event_t struct definition.
The attached patch as an addition to the packaging fixes this issue.

Please add this patch for jzmq to keep the transition going.
Thanks,
Laszlo/GCSDescription: add missing header of zmq.hpp
 jzmq uses structs defined in zmq.hpp
Author: Laszlo Boszormenyi (GCS) <g...@debian.org>
Last-Update: 2016-02-25

---

--- jzmq-3.1.0.orig/src/main/c++/Event.cpp
+++ jzmq-3.1.0/src/main/c++/Event.cpp
@@ -2,6 +2,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "jzmq.hpp"
 #include "util.hpp"

Bug#815736: graphicsmagick: FTBFS: debian/rules:138: recipe for target 'check-stamp' failed

[GCS]

Hi Chris,

On Wed, Feb 24, 2016 at 9:49 AM, Chris Lamb <la...@debian.org> wrote:
> graphicsmagick fails to build from source in unstable/amd64:
 Previously something automatically pulled in gsfonts, maybe
ghostscript itself. If you have time, you may check building all
packages that have ghostscript as build dependency.
Anyway, uploading the updated graphicsmagick package soon.

Thanks for the heads-up,
Laszlo/GCS

Bug#815685: libxs: update for libpgm 5.2 transition

[Laszlo Boszormenyi (GCS)]

Source: libxs
Version: 1.2.0-1.1
Severity: serious
Tags: patch
Justification: FTBFS and holds back libpgm transition

The package is FTBFS now, as it looks for the previous soname of
libpgm. The fix is simple, change configure.in to look for the 5.2
soname. For clarity, patch is attached. It's tested and works as
expected.Description: look for libpgm 5.2
 Simply update the version number to look for in configure.in
Author: Laszlo Boszormenyi (GCS) <g...@debian.org>
Forwarded: no
Last-Update: 2016-02-23

---

--- libxs-1.2.0.orig/configure.ac
+++ libxs-1.2.0/configure.ac
@@ -473,7 +473,7 @@ AS_IF([test "x$with_pgm_ext" != "xno"],
 # Build with system openpgm
 AS_IF([test "x$with_system_pgm_ext" != "xno"], [
 m4_ifdef([PKG_CHECK_MODULES], [
-PKG_CHECK_MODULES([OpenPGM], [openpgm-5.1 >= 5.1])
+PKG_CHECK_MODULES([OpenPGM], [openpgm-5.2 >= 5.2])
 AC_DEFINE([XS_HAVE_OPENPGM], [1], [Have OpenPGM extension])
 LIBXS_EXTRA_CXXFLAGS="$OpenPGM_CFLAGS $LIBXS_EXTRA_CXXFLAGS"
 ],

Bug#815494: zeromq3: FTBFS, with test suite errors

[GCS]

On Sun, Feb 21, 2016 at 10:52 PM, Aaron M. Ucko <a...@alum.mit.edu> wrote:
> Source: zeromq3
> Version: 4.0.5+dfsg-3+b1
 You meant 4.1.4, right? It started with 4.1.x (4.1.2?) to be more
precise in experimental.

> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
>
> Builds of zeromq3 failed for many architectures with test suite
> errors,
[...]
> Could you please take a look?
 Already done as I monitor buildd results. The strange thing is that
in my pbuilder chroots the build always succeeded. It seems buildds
have some restriction that make tests fail, to be aborted to be exact.
I've already disabled some, but then other ones failed.
At the moment I have a plan to run those, but make the fails non
fatal. Then upstream may know something about the reason.

Cheers,
Laszlo/GCS

Bug#813756: libsodium: FTBFS on non-x86: missing crypto_aead_aes256gcm_*

[GCS]

On Fri, Feb 5, 2016 at 1:17 AM, Aaron M. Ucko  wrote:
> Source: libsodium
> Version: 1.0.8-3
> Severity: serious
> Justification: fails to build from source
>
> Builds of libsodium for non-x86 architectures all failed due to missing
> nearly all crypto_aead_aes256gcm_* symbols (with the exception of
> crypto_aead_aes256gcm_is_available).  Could you please conditionalize
> these symbols accordingly, on (arch=any-amd64|arch=any-i386|arch=any-x32)?
 Strange, because -2 was built correctly on all arch for experimental.
-4 with the fix was uploaded hours before your bugreport, but not yet
scheduled for building. Strange.

Bug#813756: libsodium: FTBFS on non-x86: missing crypto_aead_aes256gcm_*

[GCS]

On Fri, Feb 5, 2016 at 1:44 AM, Aaron M. Ucko <u...@debian.org> wrote:
> "László Böszörményi (GCS)" <g...@debian.org> writes:
>>  Strange, because -2 was built correctly on all arch for experimental.
>
> Huh.
 Do you know what may be the difference between Sid and experimental
which causes such difference?

>> -4 with the fix was uploaded hours before your bugreport, but not yet
>> scheduled for building. Strange.
>
> So I see.  Thanks for the quick fix; sorry for overlooking it.
 No problem, I think it was too quick and missed some symbol changes. :(
I should buy buy an ARM based board at least for local testing. I've a
qemu based build root but on my old machine it's way too slow for
small tests even. :(

Bug#813756: libsodium: FTBFS on non-x86: missing crypto_aead_aes256gcm_*

[GCS]

On Fri, Feb 5, 2016 at 2:05 AM, Aaron M. Ucko <u...@debian.org> wrote:
> "László Böszörményi (GCS)" <g...@debian.org> writes:
>> I should buy buy an ARM based board at least for local testing. I've a
>> qemu based build root but on my old machine it's way too slow for
>> small tests even. :(
>
> You can also use one of the porterboxes, which allow self-service build
> dependency installation in temporary private chroot areas.
 Should check - now my SSH keys are not accepted for porterboxes,
needs investigating. Did my local check for i386, amd64 and ARM64 for
-5 and uploading immediately.

Sorry for the noise.
Laszlo/GCS

Bug#812935: openjdk-7-jdk: Missing openjdk-7_7u95-2.6.4-1 build on amd64 for Debian unstable

[GCS]

Control: tag -1 -security

Hi Ben,

On Wed, Jan 27, 2016 at 11:43 PM, Ben Caradoc-Davies <b...@transient.nz> wrote:
> Package: openjdk-7-jdk
> Version: 7u91-2.6.3-3
> Severity: serious
> Tags: security
> Justification: fails to build from source (but built successfully in the past)
>
> the openjdk-7_7u95-2.6.4-1 build on amd64 for Debian unstable has been missing
> for a week, despite being shown as green on maintainer QA pages, and being
> announced today in "[SECURITY] [DSA 3458-1] openjdk-7 security update" on
> <debian-security-annou...@lists.debian.org>.
 Please note the following things.
We (the Security Team) support stable and old-stable releases
(currently Jessie and Wheezy). The old-oldstable (Squeeze) release is
in the hands of the LTS team. Sid (and experimental) support provided
by the maintainer(s) him/herself.
We send out DSA mails for the mentioned two releases, when those are
built and available.
The QA pages show that the maintainer prepared and uploaded an updated
package. The auto build tasks start only after this and of course may
fail on some architectures.

> The build is "Maybe-Successful"
> https://buildd.debian.org/status/logs.php?arch=amd64=openjdk-7=7u95-2.6.4-1
>
> but there are some errors:
> https://buildd.debian.org/status/fetch.php?pkg=openjdk-7=amd64=7u95-2.6.4-1=1453417092
 If you check previous build logs, then you can see this is 'expected'
- some self-tests are failing in the build chroot. Please check the
bottom of the build log, you can see that debs are built, files are
correctly installed into those. As such, the result line show:
'Status: successful'.
I've checked and the built package is uploaded to the pool, but
somehow doesn't installed into it. I send a Cc to the buildd admins
who may check what's the further status. Admins: please close this bug
when the package is accepted to the pool.

Thanks for your mail,
Laszlo/GCS

Bug#797961: How to proceed?

[GCS]

Control: severity -1 important

On Sun, Jan 17, 2016 at 12:14 AM, Andreas Hilboll <andrea...@posteo.de> wrote:
> I would very much appreciate if this package would return into testing.
 Yes, this bug doesn't make ecryptfs-utils fail for everyone.

> Christan has suggested that the problem is not even with ecryptfs-utils but
> rather with cryptsetup.
 I'm busy with other things, but I do hope that I can reproduce this
next week or so. Then I can do tests and debugging.

Cheers,
Laszlo/GCS

Bug#811433: Not a fix, but a workaround

[GCS]

On Wed, Jan 20, 2016 at 2:20 AM, Scott Kitterman <deb...@kitterman.com> wrote:
> As discussed with the release team, I'm going to upload the attached NMU to at
> least get python-greenlet-doc installable again.
 Was it rejected? Hours passed and it doesn't show up in the QA pages.
Uploading my version with other fixes and changes.

Laszlo/GCS

Bug#805119: Acknowledgement (dar: Corrupted archives with dar ≥ 2.5.0)

[GCS]

Hi Peter,

On Mon, Nov 16, 2015 at 6:41 AM, Peter Colberg <pe...@colberg.org> wrote:
> This bug has been fixed in upstream commit 92cdf9c, which will be
> included in version 2.5.2 to be released soon. I raised the severity
> level to grave since the bug may result in data loss.
 Such archives still can be extracted if you use the
'--sequential-read' switch. Still, going to upload a package version
with the fix included.

Laszlo/GCS

Bug#804604: [pkg-fetchmail-maint] Bug#804604: fetchmail: FTBFS: undefined reference to `SSLv3_client_method'

[GCS]

Hi Peter,

On Sun, Nov 15, 2015 at 6:00 AM, peter green <plugw...@p10link.net> wrote:
>> socket.o: In function `SSLOpen':
>> /fetchmail-6.3.26/socket.c:917: undefined reference to
>> `SSLv3_client_method'
>> collect2: error: ld returned 1 exit status
>> Makefile:699: recipe for target 'fetchmail' failed
>> make[3]: *** [fetchmail] Error 1
>
>
> I just fixed this in raspbian, debdiff at
> http://debdiffs.raspbian.org/main/f/fetchmail/fetchmail_6.3.26-1%2brpi1.debdiff
 Thanks, but it seems a quick and dirty solution; it doesn't offer any
alternative to SSLv3. If you can, please test my proposed package[1]
(offers TLSv1.2 support) and report back.

Kind regards,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/fetchmail_6.3.26-2.dsc

Bug#797961: ecryptfs-utils: encrypted swap fails

[GCS]

On Fri, Sep 4, 2015 at 1:24 AM, Richard Jasmin <frazzledj...@gmail.com> wrote:
> one has to rely on ecryptfs.
>
> sudo ecryptfs-setup-swap
>
> to get encrypted swap in the first place.
 Does it work now on your machine?

> When using it we are presented with another problem.
>
> On boot swap fails to properly encrypt.You get a nice "system service
> cryptswapper" is busy (time remaining) notice, which does nothing but timeout.
 What does '/sbin/cryptdisks_start cryptswap1' outputs on your system
when swap doesn't work?

> Swap either never gets its random key, never gets written to disk, or never
> bothers to properly mount itself.
 Can you check it's not active at all, 'free -m' shows it's not available?

> Unfortunately I cannot tell you which happens as all I can tell is that swap
> never gets mounted.There are no /dev/mapper entries for swap, even though 
> there
> SHOULD BE.
 Can you do 'blkid /dev/[your swap partition' and its output matches
the one set in '/etc/crypttab'?

> I do not know yet how repeatable this issue is.This is the first occurrence
> since swap has been encrypted.
 Do you have experience if it works sometimes when you reboot or
constantly fails?

Thanks,
Laszlo/GCS

Bug#771341: fixed segfaults in sqlite3_value_type

[GCS]

fixed 771341 3.8.11.1-1
thanks

On Sun, Oct 25, 2015 at 5:25 PM, László Böszörményi (GCS)
<g...@debian.org> wrote:
> Package: libsqlite3-0
> Version: 3.8.11.1-1
 Set source package name for fixed version.

Bug#798888: ntfs-3g: pretends to be a library in a broken way

[GCS]

Hi,

On Sun, Sep 13, 2015 at 10:14 PM, Jonathan Wiltshire <j...@debian.org> wrote:
> ntfs-3g ships shared objects in a non-private location and these are used
> by other packages. ntfs-3g does not have a proper shared library package.
>
> Currently ntfs-3g advertises its ABI through a virtual package. This makes it
> difficult to detect breakage in other packages when that ABI changes.
>
> Upstream appears to want to bump ABI regularly.
 There's a new upstream version which starts an other transition.
Created a separate library package with the actual SONAME naming.
Tested that partclone and testdisk build fine with it and both picks
up the correct (real) dependency (binNMUs will be fine).
The libraries will be co-installable and I don't use conflicts with
the old ones to help smooth transitions.

Before I do the upload[1], I'm open for any critics.

Regards,
Laszlo/GCS
[1] dget -x http://www.barcikacomp.hu/gcs/ntfs-3g_2015.3.14AR.2-1.dsc

Bug#771341: segfaults in sqlite3_value_type while using from Python

[GCS]

On Mon, Mar 16, 2015 at 3:10 PM, Marc F. Clemente <m...@mclemente.net> wrote:
> One is an Intel i7.  Four others are xen virtual machines running on an Intel 
> Xeon.
 On which computers do you get the segfaults? Can you try recent
SQLite3 package uploads, especially 3.9.1?
Do you have a minimal installation maybe where the crash happens?

Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

Hi Niels, Bob, others,

On Fri, Sep 25, 2015 at 8:34 AM, Niels Thykier <ni...@thykier.net> wrote:
> Thanks for getting it uploaded to NEW.
>
> I have prodded the FTP masters about fast tracking and will try to
> finish the resulting transition as fast as possible. :)
 Now it's accepted, built fine on almost all architectures and the
tracker seems to be correct.
It fails on mipsel[1] with:
-- cut --
Magick: abort due to signal 11 (SIGSEGV) "Segmentation Fault"...
/«PKGBUILDDIR»/scripts/tap-functions.shi: line 58:  2290 Aborted
  ( "$@" )
EXEC: ./rwfile -stdio -filespec out_truecolor_stdio_%d
/«PKGBUILDDIR»/tests/input_truecolor.miff PCDS
not ok 244 - PCDS truecolor (stdio)
FAIL: tests/rwfile.tap 244 - PCDS truecolor (stdio)
-- cut --

It was failed previously a few times as well, but a rescheduled build
solved it. To be honest the reasons were: signal 01 (SIGBUS) "Bus
Error"
But I suspect the cause may be the same, please reschedule the build
of graphicsmagick on mipsel.

The build is strange on mips just for the record. Sometimes (just like
in the past) it builds in a hour. Nowadays it's over twelve hours
sometimes, but it seems to be at lease six hours[2].
Bob, how may I help you to find the root cause of the slow building on
mips at least?

Thanks,
Laszlo/GCS
[1] 
https://buildd.debian.org/status/fetch.php?pkg=graphicsmagick=mipsel=1.3.21-4=1443407301
[2] https://buildd.debian.org/status/logs.php?pkg=graphicsmagick=mips

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Thu, Sep 24, 2015 at 1:38 PM, Jakub Wilk <jw...@debian.org> wrote:
> Conflicts/replaces on "libgraphicsmagick3" in necessary because of
> /usr/{lib,share}/GraphicsMagick-1.3.21/ directories. :-/ Fortunately, can
> make the new package co-installable with the jessie version by making
> conflict/replaces versioned:
>
> Conflicts: libgraphicsmagick3 (>= 1.3.21)
> Replaces: libgraphicsmagick3 (>= 1.3.21)
 +1

>> +++ graphicsmagick-1.3.21/debian/graphicsmagick.install 2015-09-22
>> 21:55:12.0 +0200
>> @@ -1,2 +1,3 @@
>> usr/bin/gm
>> usr/share/doc/graphicsmagick/www
>> +usr/share/man/man1/gm.1
>
> I don't understand what why this change is needed. It's not documented in
> the changelog.
 A quick check showed the manpage is not installed otherwise, need check.

>> +++ graphicsmagick-1.3.21/debian/libgraphicsmagick++1-dev.links 2015-09-23
>> 00:40:01.0 +0200
>> @@ -1 +1,2 @@
>> usr/share/doc/graphicsmagick/www/images
>> usr/share/doc/libgraphicsmagick++1-dev/images
>> +usr/lib/libGraphicsMagick++-Q16.so.11.0.0
>> usr/lib/libGraphicsMagick++-Q16.so
>
> I don't think these symlinks are useful.
> If upstream build system doesn't create them, then we shouldn't either.
 I was afraid that other packages may use it to detect the QD support
of the library if not now, but in the close future. But sure, if
upstream doesn't create this then why should I be such pedantic.

>> -   dh_shlibdeps -a -L libgraphicsmagick3 \
>> -   -l debian/libgraphicsmagick3/usr/lib
>> +   dh_shlibdeps -a -L libgraphicsmagick-q16-3 \
>> +   -l debian/libgraphicsmagick-q16-3/usr/lib
>
> These days -l and -L shouldn't be needed.
 OK.

Thanks! Will act when I get back home.
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Wed, Sep 23, 2015 at 8:30 PM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> On Tue, 22 Sep 2015 21:58:46 +0200 <g...@debian.org> wrote:
>>  You make me wonder. Would it worth to have packages with different
>> quantum depth support in parallel? I mean I would compile / install
>> the package twice; first for QD=16 and then QD=32 to different paths
>> so I can ship the libraries parallel for any given release.
>
> Please fix the aforementioned bug as it's blocking the GCC5 transition, and
> worry about compiling things twice and providing multiple libraries later.
 It was just a question for future upstream releases. Life is easier -
my slowness is due to IRL things, just got back home recently and need
to get up early in the morning. But working on the fix / update and
going to upload it soon.

Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Fri, Sep 25, 2015 at 12:41 AM, Emilio Pozuelo Monfort
<po...@debian.org> wrote:
> Yeah, sorry if that came out too harsh. I just meant to say that fixing the RC
> bug should take priority as this is blocking other transitions. It's good that
> you're looking at it, so no worries.
 It was a bit harsh, but no problem. I guess we all have enough things
to do. The updated package is now in NEW, hopefully will be accepted
to the archives soon.

Kind regards,
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Tue, Sep 22, 2015 at 8:10 PM, Julien Cristau <jcris...@debian.org> wrote:
> On Tue, Sep 22, 2015 at 19:40:42 +0200, László Böszörményi (GCS) wrote:
>>  Yes, I know that. Still the packages can be tracked during a
>> transition via the package name if those were compiled against the
>> quantum-depth change or not. I have to change the package name anyway,
>> I can't just change the SONAME. Then I don't see the mandatory to
>> change the SONAME, the package name change will make it distinct of
>> the quantum-depth difference.
> Please do change the SONAMEs when you change the package names for this,
> especially if upstream provide an option to do so.
 OK, updated the package[1] if any of you would like to review it - no
other change for now. It's getting late, will upload the package
tomorrow.

Cheers,
Laszlo/GCS
[1] http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Tue, Sep 22, 2015 at 7:17 PM, Jakub Wilk <jw...@debian.org> wrote:
> * László Böszörményi (GCS) <g...@debian.org>, 2015-09-22, 08:25:
>>
>> [2] dget -x http://www.barcikacomp.hu/gcs/graphicsmagick_1.3.21-4.dsc
>
> You changed the package name, but not the SONAME. That doesn't sound right.
 Yes, I know that. Still the packages can be tracked during a
transition via the package name if those were compiled against the
quantum-depth change or not. I have to change the package name anyway,
I can't just change the SONAME. Then I don't see the mandatory to
change the SONAME, the package name change will make it distinct of
the quantum-depth difference.

> Changing the SONAME should be a matter of passing
> --enable-quantum-library-names to configure, as suggested by Bob Friesenhahn
> in #795102.
 Will re-read that mail from Bob.

> Also, now might be a good moment to move libGraphicsMagickWand to a seperate
> binary package.
 Do you know any package which needs only that library (ie does it
worth to be a separate one)?

Regards,
Laszlo/GCS

Bug#796310: libgraphicsmagick3: --with-quantum-depth=16 breaks ABI

[GCS]

On Tue, Sep 22, 2015 at 8:27 PM, Bob Friesenhahn
<bfrie...@simple.dallas.tx.us> wrote:
> If there are two packages with different quantum depth, then they should be
> able to co-exist without conflict.  Likewise, the existing package should be
> able to co-exist with new packages which are distinguished via quantum depth
> so that existing software continues to work.
 You make me wonder. Would it worth to have packages with different
quantum depth support in parallel? I mean I would compile / install
the package twice; first for QD=16 and then QD=32 to different paths
so I can ship the libraries parallel for any given release.

> Dependent applications should be re-compiled and re-linked against the new
> packages so they stop using the old library.
 Does it mean that run-time loading is not possible? A dependent
package would ask which one (16/32) you would like and then load the
library that provides the specified QD to process the images.

Regards,
Laszlo/GCS