Bug#797994: synfig: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: synfig
Version: 1.0-1
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of synfig, std::string appears in functions in public
headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libsynfig0v5).
The actual SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, please avoid doing this unless the new upstream version
is very low-risk: the libstdc++ transition has stalled development in
unstable for long enough already.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of synfig:

* boost has already been renamed
* etl seems to be header-only so does not need a transition
* libmagick++ has already been renamed
* libmlt++ is not believed to need a transition (but please check)

so I think this sub-transition may be ready.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

Control: severity 766884 serious

Please don't change the severity level and no ping-pong game please.

On Thu, Sep 3, 2015 at 3:47 PM, Raphael Hertzog  wrote:
> Control: severity 766884 important
>
> Hi Aron,
>
> please keep me in copy as I'm not subscribed to
> debian-xml-sgml-p...@lists.alioth.debian.org... I just discovered your
> reply by chance.
>
> On Mon, 31 Aug 2015, Aron Xu wrote:
>> Let's reopen #766884 for tracking, it's not really fixed, but just
>> avoided. Unfortunately #781232 is opened. I would like to block this
>> version to testing as it's not the proper way of fixing the problem
>> (but it is indeed the most straightforward way of avoiding it).
>
> Why don't you want to let this version in testing?
>
> The release team has made it clear that they prefer to have the same
> version in unstable and in testing... and the version in unstable is not
> worse than the version in testing.
>

It's not a reason that you just revert back to an older version
because it's easy to do so. If you want to make it the same version,
choose the harder but more correct way as libxml2 is not a trivial
package with low impact.

>> The proper way of working this bug around would be bisecting and
>> patching which is quite time consuming. I haven't yet managed to get
>> it done and help is welcomed, but if no one step up I'll do it
>> eventually (or cross finger for finding a proper fix, :D).
>
> Someone already did this that in the upstream bug tracker:
> https://bugzilla.gnome.org/show_bug.cgi?id=737840
>
> So if you want you can try to revert this commit:
> https://git.gnome.org/browse/libxml2/commit/?id=a16eb968075a82ec33b2c1e77db8909a35b44620
>
> But Daniel Veillard made it clear that this commit
> was not at fault, it was only making the problem visible:
> https://bugzilla.gnome.org/show_bug.cgi?id=737840#c2
>
> So yes, maybe switching to 1.9.2 and reverting this
> one would be better until a proper fix is available.
>

Yep.

> But this bug should not prevent the migration of the package to testing
> since the package in sid does not exhibit the problem currently. So
> I'm reducing its severity to important in particular since you do not seem
> to want to close it until a proper fix is available upstream.
>

I don't want to close it, nor I want make this version to testing, so
please don't lower the severity, as said above.

> I just added another commit on request of Julien Cristau.  Whatever you
> decide, you need to make a new upload so that the "icu" migration can be
> completed in unstable.
>

Thanks for that, :)

Cheers,
Aron

> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
>
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get/

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> severity 766884 serious
Bug #766884 [libxml2] libxml2: "validity error : ID ... already defined" errors 
with xmllint --noent
Bug #796031 [libxml2] publican: FTBFS: validity:513 in Test_DB5_Book.xml on 
line 11: ID We_Need_Feedback already defined
Ignoring request to change severity of Bug 766884 to the same value.
Ignoring request to change severity of Bug 796031 to the same value.

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
781232: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781232
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#766884: libxml2 broken in sid for months already

[Debian Bug Tracking System]

Processing control commands:

> severity 766884 serious
Bug #766884 [libxml2] libxml2: "validity error : ID ... already defined" errors 
with xmllint --noent
Bug #796031 [libxml2] publican: FTBFS: validity:513 in Test_DB5_Book.xml on 
line 11: ID We_Need_Feedback already defined
Severity set to 'serious' from 'important'
Severity set to 'serious' from 'important'

-- 
766884: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766884
796031: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796031
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hello,

On Fri, 04 Sep 2015, Aron Xu wrote:
> It's not a reason that you just revert back to an older version
> because it's easy to do so. If you want to make it the same version,
> choose the harder but more correct way as libxml2 is not a trivial
> package with low impact.

Hey, don't give me lessons. I'm not the libxml2 maintainer who left
#766884 unattended since october last year...

And I announced my plans in the bug report and I had no response from
you until a few days ago.

I did not pick an easy solution, mind you, I spent multiple hours to
prepare the upload as I had to re-introduce patches that you did
push through via a testing-proposed-updades upload.

I did that because I believe that this was the correct course of action
given the lack of proper fix upsream, not because it was an easy solution.

Adding a single patch to revert the change that triggered the bug would
have been easier and in retrospect, it's probably what I should have done.
But even then it's just hiding the bug under the carpet. The real bug
is still waiting to be fixed...

> > But this bug should not prevent the migration of the package to testing
> > since the package in sid does not exhibit the problem currently. So
> > I'm reducing its severity to important in particular since you do not seem
> > to want to close it until a proper fix is available upstream.
> 
> I don't want to close it, nor I want make this version to testing, so
> please don't lower the severity, as said above.

Why don't you want this version into testing?

That doesn't forbid you to push 2.9.2 with the problematic commit reverted
later on. And have this one reach testing too.

Anything that is in unstable should go into testing, otherwise you should
use experimental.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#797992: octave: ABI transition needed for libstdc++ v5

[Simon McVittie]

On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:
> Looking at the C++ library build-dependencies of octave, it is
> waiting for hdf5 (#791067) but everything else seems to be ready.

Looking more closely at this, hdf5 has both a C and a C++ API,
and octave appears to only use the C. If this is correct, then it does
not need to wait for hdf5 after all.

Regards,
S

Bug#797917: Actually this bug makes clang not so useful

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Danny,

> If we could make those "Dual-ABI compile flags" the default on 
> gcc-compiled libraries, clang upstream should have enough time 
> implementing [abi:cxx11] and remain usable in Debian.


gcc had the dual ABI enabled.

but it got disable in the experimental/unstable uploads:
https://packages.qa.debian.org/g/gcc-5/news/20150616T170514Z.html

I guess clang is not useful for cxx11 projects until llvm folks finds
a way to make it use the new ABI.

sorry, but I don't see how to fix this, for sure enabling again the
dual ABI in gcc (not even sure if it will work), is a no-go, because
I'm pretty sure it will trigger another painful transition.

I'm sorry but we should live with this, until llvm folks implemtents
the new code.

Sylvestre, doko, what is your opinion?

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV6WL+AAoJEPNPCXROn13ZLSwP/jKdByzGcE69N6tMFqRcnrfE
cX4HsZl/ctH+s2++Gf/ViHTOJT96Zearw8IQ3+Z8582YMjw+240fxaRsGJfX4CFr
7zjA9sd3Otk+hailJm67qh6zW58Jw5v/izG5mGQUf6wA4ZSVZ9yqNVOE/9fKuI1x
2lyAt3KELt6wIjgZgjLkwCqndiP8JTpERqNHn+1D2G3FjDAfppWQfiScUu6WfBsC
WPGFl6BzfUWKoXBjBfhcpDEO4HbQ7RUz5AoNK55YVjemU1oy+gqWwXC2alUA6jVt
QOEeq00/iDVptH1E2UCYraUp6bd8ebKlxmWOhmQfW1ubQRTrYFlFM9Fs5SBLnqoT
GnsUHaW/GbPTY+eRtbI3WUiAwsDCdhDAVL3ROXmGN/quPZwYp7YsdB3U70sOd3H+
Kj/PXT/w8FpVeK4ak1LrQB6xCxeG49KPHFJ1KYD04OCsVHugtTdzy1WzRbbHvofV
MPdbbAFGAbI9MGux81+w0HSfZKbkK2DyXjYG4IfYMUpczlyL/4gN4VVJabVB3LNP
6tApQjJf3OivtJBESMUuWwf3TXziUce/GpUvulCVGcEsHJWYiJy7aU22/rl0ZGDw
CceAM6gjNI14XU+ejTF6Xcs2obVK3VPbleHeDG5jNN86F9P4Osy3clYZLMAJwRks
ai/12PvO7FQpYeAb89or
=L2mz
-END PGP SIGNATURE-

Processed: Re: Bug#797976: spice: CVE-2015-3247: memory corruption in worker_update_monitors_config()

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #797976 [src:spice] spice: CVE-2015-3247: memory corruption in 
worker_update_monitors_config()
Ignoring request to alter tags of bug #797976 to the same tags previously set

-- 
797976: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797976
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797976: spice: CVE-2015-3247: memory corruption in worker_update_monitors_config()

[Salvatore Bonaccorso]

Control: tags -1 + patch

Hi,

Attached is the debdiff prepared for a jessie-security upload.

Regards,
Salvatore
diff -Nru spice-0.12.5/debian/changelog spice-0.12.5/debian/changelog
--- spice-0.12.5/debian/changelog   2014-05-23 17:56:48.0 +0200
+++ spice-0.12.5/debian/changelog   2015-09-04 09:35:09.0 +0200
@@ -1,3 +1,12 @@
+spice (0.12.5-1+deb8u1) jessie-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Add CVE-2015-3247.patch patch.
+CVE-2015-3247: memory corruption in worker_update_monitors_config().
+(Closes: #797976)
+
+ -- Salvatore Bonaccorso   Fri, 04 Sep 2015 09:34:00 +0200
+
 spice (0.12.5-1) unstable; urgency=medium
 
   * new upstream release.  Can now build without celt!
diff -Nru spice-0.12.5/debian/patches/CVE-2015-3247.patch 
spice-0.12.5/debian/patches/CVE-2015-3247.patch
--- spice-0.12.5/debian/patches/CVE-2015-3247.patch 1970-01-01 
01:00:00.0 +0100
+++ spice-0.12.5/debian/patches/CVE-2015-3247.patch 2015-09-04 
09:35:09.0 +0200
@@ -0,0 +1,115 @@
+From 524eef10c6c6c2f3f30be28c56b8f96adc7901f0 Mon Sep 17 00:00:00 2001
+From: Frediano Ziglio 
+Date: Tue, 9 Jun 2015 08:50:46 +0100
+Subject: [PATCH] Avoid race conditions reading monitor configs from guest
+
+For security reasons do not assume guest do not change structures it
+pass to Qemu.
+Guest could change count field while Qemu is copying QXLMonitorsConfig
+structure leading to heap corruption.
+This patch avoid it reading count only once.
+
+Signed-off-by: Frediano Ziglio 
+---
+ server/red_worker.c | 46 --
+ 1 file changed, 32 insertions(+), 14 deletions(-)
+
+--- a/server/red_worker.c
 b/server/red_worker.c
+@@ -11051,7 +11051,8 @@ static inline void red_monitors_config_i
+ }
+ 
+ static void worker_update_monitors_config(RedWorker *worker,
+-  QXLMonitorsConfig 
*dev_monitors_config)
++  QXLMonitorsConfig 
*dev_monitors_config,
++  uint16_t count, uint16_t 
max_allowed)
+ {
+ int heads_size;
+ MonitorsConfig *monitors_config;
+@@ -11060,22 +11061,22 @@ static void worker_update_monitors_confi
+ monitors_config_decref(worker->monitors_config);
+ 
+ spice_debug("monitors config %d(%d)",
+-dev_monitors_config->count,
+-dev_monitors_config->max_allowed);
+-for (i = 0; i < dev_monitors_config->count; i++) {
++count,
++max_allowed);
++for (i = 0; i < count; i++) {
+ spice_debug("+%d+%d %dx%d",
+ dev_monitors_config->heads[i].x,
+ dev_monitors_config->heads[i].y,
+ dev_monitors_config->heads[i].width,
+ dev_monitors_config->heads[i].height);
+ }
+-heads_size = dev_monitors_config->count * sizeof(QXLHead);
++heads_size = count * sizeof(QXLHead);
+ worker->monitors_config = monitors_config =
+ spice_malloc(sizeof(*monitors_config) + heads_size);
+ monitors_config->refs = 1;
+ monitors_config->worker = worker;
+-monitors_config->count = dev_monitors_config->count;
+-monitors_config->max_allowed = dev_monitors_config->max_allowed;
++monitors_config->count = count;
++monitors_config->max_allowed = max_allowed;
+ memcpy(monitors_config->heads, dev_monitors_config->heads, heads_size);
+ }
+ 
+@@ -11459,33 +11460,50 @@ void handle_dev_display_migrate(void *op
+ red_migrate_display(worker, rcc);
+ }
+ 
++static inline uint32_t qxl_monitors_config_size(uint32_t heads)
++{
++return sizeof(QXLMonitorsConfig) + sizeof(QXLHead) * heads;
++}
++
+ static void handle_dev_monitors_config_async(void *opaque, void *payload)
+ {
+ RedWorkerMessageMonitorsConfigAsync *msg = payload;
+ RedWorker *worker = opaque;
+-int min_size = sizeof(QXLMonitorsConfig) + sizeof(QXLHead);
+ int error;
++uint16_t count, max_allowed;
+ QXLMonitorsConfig *dev_monitors_config =
+ (QXLMonitorsConfig*)get_virt(>mem_slots, msg->monitors_config,
+- min_size, msg->group_id, );
++ qxl_monitors_config_size(1),
++ msg->group_id, );
+ 
+ if (error) {
+ /* TODO: raise guest bug (requires added QXL interface) */
+ return;
+ }
+ worker->driver_cap_monitors_config = 1;
+-if (dev_monitors_config->count == 0) {
++count = dev_monitors_config->count;
++max_allowed = dev_monitors_config->max_allowed;
++if (count == 0) {
+ spice_warning("ignoring an empty monitors config message from 
driver");
+ return;
+ }
+-if (dev_monitors_config->count > dev_monitors_config->max_allowed) {
++if (count > max_allowed) {
+ spice_warning("ignoring malformed 

Processed: octave: ABI transition needed for libstdc++ v5

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 791067
Bug #797992 [src:octave] octave: ABI transition needed for libstdc++ v5
797992 was not blocked by any bugs.
797992 was not blocking any bugs.
Added blocking bug(s) of 797992: 791067

-- 
797992: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: found 795429 in 1.2.1-7

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 795429 1.2.1-7
Bug #795429 [src:openslp-dfsg] CVE-2015-5177
Marked as found in versions openslp-dfsg/1.2.1-7.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
795429: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795429
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#798008: yaml-cpp: library transition needed with GCC 5 as default

[Debian Bug Tracking System]

Processing control commands:

> tags 798008 + patch pending
Bug #798008 [src:yaml-cpp] yaml-cpp: library transition needed with GCC 5 as 
default
Added tag(s) pending and patch.

-- 
798008: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798008
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797978: marked as done ([Reproducible-builds] All Recommends of diffoscope lost with upload of version 32?)

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 09:21:10 +
with message-id 
and subject line Bug#797978: fixed in diffoscope 33
has caused the Debian Bug report #797978,
regarding [Reproducible-builds] All Recommends of diffoscope lost with upload 
of version 32?
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
797978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797978
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: diffoscope
Version: 32
Severity: serious
Control: submitter -1 Axel Beckert 
x-debbugs-cc: Axel Beckert 

On Fri, Sep 04, 2015 at 08:42:43AM +0200, Axel Beckert wrote:
> it seems that the Recommends of diffoscope are generated dynamically
> and all lost with the upload of version 32. Is this on purpose? If
> not, feel free to open a bug report in my name with this mail.

Pretty sure it is not.

Also, setting as sev:serious since this breaks our CI (everything will
be binary diffed!), etc.

Thanks for reporting!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
Source: diffoscope
Source-Version: 33

We believe that the bug you reported is fixed in the latest version of
diffoscope, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 797...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Jérémy Bobbio  (supplier of updated diffoscope package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 04 Sep 2015 10:20:45 +0200
Source: diffoscope
Binary: diffoscope debbindiff
Architecture: source all
Version: 33
Distribution: unstable
Urgency: medium
Maintainer: Reproducible builds folks 

Changed-By: Jérémy Bobbio 
Description:
 debbindiff - transitional package
 diffoscope - in-depth comparison of files, archives, and directories
Closes: 797978
Changes:
 diffoscope (33) unstable; urgency=medium
 .
   * Fix path to diffoscope used to generate Recommends. (Closes: #797978)
Checksums-Sha1:
 c4584232acd402ff07652e1ffa84e54704e6ac42 1945 diffoscope_33.dsc
 73ec9c6bd48f43a0633fb0047f45530e830b5a9d 256412 diffoscope_33.tar.gz
 cf2312da390f697c0ba6bc29728a47ddb71a5b20 8894 debbindiff_33_all.deb
 52ccdc726fb6024e3cbe03c4cfc6cc53c3ac7556 40456 diffoscope_33_all.deb
Checksums-Sha256:
 35fac6e63034e4cb267ce16c587e25e01db4b99731fe480a61bdb550c5b7c9d5 1945 
diffoscope_33.dsc
 73285f4baf6683f00b1a112ac02223e983c1d9d75e1f47e05a47c5694c68a8df 256412 
diffoscope_33.tar.gz
 dd4d5fc5e8481bfb0c4caf5e1777fff584c32b44353b313b42893aee9846e3df 8894 
debbindiff_33_all.deb
 c074c754cc52497c5d318e59353a9b469530f5ff3380174072cfbfb180b472a1 40456 
diffoscope_33_all.deb
Files:
 3789c40fecfce1df2558340dd5577c40 1945 devel optional diffoscope_33.dsc
 4e4df80a8668d26ed46312df04a625e4 256412 devel optional diffoscope_33.tar.gz
 00ee53756d25daa7d94d054a7e65ec32 8894 oldlibs extra debbindiff_33_all.deb
 2a36f00bfc34825e144627b27af6de5d 40456 devel optional diffoscope_33_all.deb

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJV6VV3AAoJEEAsIlA9Nuk2DqkP/jSSeL1+Xp3TffiPPH/TQdmT
GZa6iQV5bYam3whx72CpGcQ2s7HJqViVZtzA7SOZAqCXc+NAsJEj0fUUQfWDjGax
U/j9Ugqr2xF0eq0kI1b+Ev0jbd4ry8UgdPBdTCT73ZTYdO2v2G1VHZL3+v6hTmFk
9h3IPTs4ZE57qVNBxrDPM8buc9Nw4Z9IYzuzxkklrJ7IItd5lfNQSnvIuFtWhNAs
908u9fteFRra4nLb4vEAjfuoVRNA7Y9rMNHho6jjnk4BSchPUQX43Uv1qssFO/d5
ZlVI+d0AF9JAE/CAJZa+UkEeJ1/1LpTU66DSHF0xSGvpQobsqAofbwYGwQNwzap7
J4XnqcjZe/UQ5CkuOFa351tFbiQyrLtAVEVJ1K1y00/Si5xrwWPnmXFp8iUvVYps
xtPXJc5ID3K57qyejUD68WlAUS9d2XKk/8Q57OF4Ny4hg3O8OSR7cvNFHo9u17Zp
34PtBfmNokmYHubeQPzQ4h0TFyTIkP5mupnhtYaHYfyET1vXeRyNOd2cBj9mAwr0
4QWI/MRgrWCH7TOUDfUcPG0MytRogikn5gDn02eOJ8qq74VRc3fdRuzW6SV8/itO

Bug#798008: yaml-cpp: library transition needed with GCC 5 as default

[Simon McVittie]

Control: tags 798008 + patch pending

On Fri, 04 Sep 2015 at 14:18:50 +0200, Julien Cristau wrote:
>Then reassign the issue to release.debian.org and
>properly tag it as a transition issue

This was already done,  (but I thought
you'd stopped wanting people to do this and started wanting people to
just upload and close the bug in any case).

There's a patch from a maintainer on that bug, which I have built locally
and build-tested with librime. It's ready for sponsored upload, unless you
want me to hold off because of the previous ABI break in
.

Please let me know whether I should upload or do something else.

S

Bug#798010: ipython3: malicious dynamic python3 interpreter lookup via "/usr/bin/env python3" in main executable

[Tobias Megies]

Package: ipython3
Version: 2.3.0-2
Severity: serious
Justification: Debian Python Policy 2.4.2: Interpreter Location

Dear Maintainer,

the main executable /usr/bin/ipython3 has shebang line 1 "#!/usr/bin/env
python3" and thus uses the first python3 interpreter found in $PATH doing a
dynamic lookup at execution time.
If a local user-space Python environment is coming first in $PATH it will thus
yield the Python3 IPython prompt from user space and not from the system
python. This will result in very puzzling situation and clearly is in violation
of the Debian Python Policy which demands the hardcoded system python binary in
shebang.

See Debian Python Policy 2.4.2 Interpreter location:
https://www.debian.org/doc/packaging-manuals/python-policy/ch-
python.html#s-interpreter_loc

=== quote start
The preferred specification for the Python interpreter is /usr/bin/python or
/usr/bin/pythonX.Y. This ensures that a Debian installation of python is used
and all dependencies on additional python modules are met.
Maintainers should not override the Debian Python interpreter using
/usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
bypasses Debian's dependency checking and makes the package vulnerable to
incomplete local installations of python.
=== quote end


best regards,
Tobias Megies



-- System Information:
Debian Release: 8.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages ipython3 depends on:
ii  python3-decorator  3.4.0-2
ii  python3-pkg-resources  5.5.1-1
ii  python3-simplegeneric  0.8.1-1
pn  python3:any

ipython3 recommends no packages.

Versions of packages ipython3 suggests:
pn  ipython3-notebook   
pn  ipython3-qtconsole  
pn  python3-zmq 

-- no debconf information

Bug#797992: octave: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: octave
Version: 4.0.0-3
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
Control: block -1 by 791067

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of octave, std::string appears in functions in
installed headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the affected library
packages, adding a v5 suffix (liboctave3v5). The actual SONAME should
not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, please avoid doing this unless the new upstream version
is extremely low-risk: this transition has been going on for 1 month
already, and anything that drags it out further is bad for Debian.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.
When hdf5 starts its transition, please give octave a versioned
build-dependency on the version of libhdf5-dev corresponding to
the rename.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Bug#797540: marked as done (wmgtemp: FTBFS: undefined reference to `list_cons')

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 10:52:10 +
with message-id 
and subject line Bug#797540: fixed in wmgtemp 1.1-3
has caused the Debian Bug report #797540,
regarding wmgtemp: FTBFS: undefined reference to `list_cons'
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
797540: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797540
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: wmgtemp
Version: 1.1-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
Tags: patch

Dear Maintainer,

wmgtemp fails to build from source in unstable/amd64 due to GCC 5.

A patch is attached.

  [..]

  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong
  -Wformat -Werror=format-security -c wmgeneral/wmgeneral.c -o
  wmgeneral/wmgeneral.o
  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong
  -Wformat -Werror=format-security -c wmgeneral/misc.c -o
  wmgeneral/misc.o
  In file included from wmgeneral/misc.c:24:0:
  wmgeneral/list.h:57:13: warning: inline function 'list_free' declared
  but never defined
   INLINE void list_free(LinkedList* list);
   ^
  wmgeneral/list.h:55:19: warning: inline function 'list_find' declared
  but never defined
   INLINE LinkedList*list_find(LinkedList* list, void* elem);
 ^
  wmgeneral/list.h:53:13: warning: inline function 'list_mapcar'
  declared but never defined
   INLINE void list_mapcar(LinkedList* list, void(*function)(void*));
   ^
  wmgeneral/list.h:51:20: warning: inline function 'list_remove_elem'
  declared but never defined
   INLINE LinkedList *list_remove_elem(LinkedList* list, void* elem);
  ^
  wmgeneral/list.h:49:13: warning: inline function 'list_remove_head'
  declared but never defined
   INLINE void list_remove_head(LinkedList** list);
   ^
  wmgeneral/list.h:47:14: warning: inline function 'list_nth' declared
  but never defined
   INLINE void* list_nth(int index, LinkedList* list);
^
  wmgeneral/list.h:45:12: warning: inline function 'list_length'
  declared but never defined
   INLINE int list_length(LinkedList* list);
  ^
  wmgeneral/list.h:43:20: warning: inline function 'list_cons' declared
  but never defined
   INLINE LinkedList* list_cons(void* head, LinkedList* tail);
  ^
  gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong
  -Wformat -Werror=format-security -c wmgeneral/list.c -o
  wmgeneral/list.o
  gcc wmgtemp.o ./wmgeneral/wmgeneral.o ./wmgeneral/misc.o
  ./wmgeneral/list.o -Wl,-z,relro -o wmgtemp -lXpm -lXext -lX11
  -lsensors
  ./wmgeneral/misc.o: In function `parse_command':
  /tmp/buildd/wmgtemp-1.1/src/wmgeneral/misc.c:122: undefined reference
  to `list_cons'
  /tmp/buildd/wmgtemp-1.1/src/wmgeneral/misc.c:126: undefined reference
  to `list_length'
  /tmp/buildd/wmgtemp-1.1/src/wmgeneral/misc.c:131: undefined reference
  to `list_remove_head'
  collect2: error: ld returned 1 exit status
  Makefile:19: recipe for target 'wmgtemp' failed
  make[3]: *** [wmgtemp] Error 1
  make[3]: Leaving directory '/tmp/buildd/wmgtemp-1.1/src'
  Makefile:6: recipe for target 'all' failed
  make[2]: *** [all] Error 2
  make[2]: Leaving directory '/tmp/buildd/wmgtemp-1.1'
  dh_auto_build: make -j1 CFLAGS=-g -O2 -fstack-protector-strong
  -Wformat -Werror=format-security LDFLAGS=-Wl,-z,relro returned exit
  code 2
  debian/rules:7: recipe for target 'override_dh_auto_build' failed
  make[1]: *** [override_dh_auto_build] Error 2
  make[1]: Leaving directory '/tmp/buildd/wmgtemp-1.1'
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

  [..]

The full build log is attached or can be viewed here:


https://reproducible.debian.net/logs/unstable/amd64/wmgtemp_1.1-2.build1.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/src/wmgeneral/list.h b/src/wmgeneral/list.h
index af0f22c..d4fe297 100644
--- a/src/wmgeneral/list.h
+++ b/src/wmgeneral/list.h
@@ -29,7 +29,7 @@ Boston, MA 02111-1307, USA.  */
 #ifndef __LIST_H_
 #define __LIST_H_
 
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__) && (__GNUC__ < 5)
 # define INLINE inline
 #else
 # define INLINE
I: using fakeroot in 

Bug#795520: marked as done (golang-uuid: FTBFS: uuid_test.go:315: NodeInterface "" after SetInteface)

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 11:00:15 +
with message-id 
and subject line Bug#795520: fixed in golang-github-pborman-uuid 
0.0+git20150824.0.cccd189-1
has caused the Debian Bug report #795520,
regarding golang-uuid: FTBFS: uuid_test.go:315: NodeInterface "" after 
SetInteface
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795520: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795520
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: golang-uuid
Version: 0.0~hg20140512-1
Severity: serious
Justification: fails to build from source

Dear Maintainer,

golang-uuid fails to build from source on unstable/amd64:

  [..]
  === RUN TestNodeID
  --- FAIL: TestNodeID (0.00s)
uuid_test.go:315: NodeInterface "" after SetInteface
  === RUN TestDCE
  --- PASS: TestDCE (0.00s)
  === RUN TestBadRand
  --- PASS: TestBadRand (0.00s)
  FAIL
  exit status 1
  FAILcode.google.com/p/go-uuid/uuid  0.012s
  dh_auto_test: go test -v code.google.com/p/go-uuid/uuid returned exit
  code 1
  debian/rules:9: recipe for target 'build' failed
  make: *** [build] Error 1
  dpkg-buildpackage: error: debian/rules build gave error exit status 2

The full build log is attached or can be viewed here:

  
https://reproducible.debian.net/rbuild/unstable/amd64/golang-uuid_0.0~hg20140512-1.rbuild.log.gz


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
Starting to build golang-uuid/unstable on 2015-07-25 06:45
The jenkins build log is/was available at 
https://jenkins.debian.net/job/reproducible_builder_gamma/57384/console
Reading package lists...
Building dependency tree...
Reading state information...
NOTICE: 'golang-uuid' packaging is maintained in the 'Git' version control 
system at:
git://anonscm.debian.org/pkg-go/packages/golang-uuid.git
Need to get 12.9 kB of source archives.
Get:1 http://ftp.de.debian.org/debian/ unstable/main golang-uuid 
0.0~hg20140512-1 (dsc) [1979 B]
Get:2 http://ftp.de.debian.org/debian/ unstable/main golang-uuid 
0.0~hg20140512-1 (tar) [8931 B]
Get:3 http://ftp.de.debian.org/debian/ unstable/main golang-uuid 
0.0~hg20140512-1 (diff) [1972 B]
Fetched 12.9 kB in 0s (180 kB/s)
Download complete and in download only mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 3.0 (quilt)
Source: golang-uuid
Binary: golang-uuid-dev
Architecture: all
Version: 0.0~hg20140512-1
Maintainer: Sergio Schvezov 
Homepage: https://code.google.com/p/go-uuid/
Standards-Version: 3.9.5
Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=pkg-go/packages/golang-uuid.git;a=summary
Vcs-Git: git://anonscm.debian.org/pkg-go/packages/golang-uuid.git
Build-Depends: debhelper (>= 9), dh-golang, golang-go
Package-List: 
 golang-uuid-dev deb devel extra arch=all
Checksums-Sha1: 
 af5dd201b634d19a9ebc20500fbd06e77290c5d0 8931 
golang-uuid_0.0~hg20140512.orig.tar.gz
 15df9bf2309098e243b57adc56a1563ea00d8b0b 1972 
golang-uuid_0.0~hg20140512-1.debian.tar.xz
Checksums-Sha256: 
 97003e8cd5a083cf119b7fad007aa5254040c25c989b512ecc18100c90a3dd03 8931 
golang-uuid_0.0~hg20140512.orig.tar.gz
 e5187668e9369c5008835eade312e8d0e7692b5e09fc0697731aa86f749af33d 1972 
golang-uuid_0.0~hg20140512-1.debian.tar.xz
Files: 
 6e38e643cbe392c82daf4f9b17b5de52 8931 golang-uuid_0.0~hg20140512.orig.tar.gz
 8247c7bcc54ee3f8c2c6dc252f4b4db4 1972 
golang-uuid_0.0~hg20140512-1.debian.tar.xz

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJTdSKmAAoJEE5xYO1KyO4dRxAQAKlKY12y3ASKMh4SqUpoZBaH
YEPuv9F7bagoksUbbWqZigrtVbGkOGYZQbLDBV25+NIexfQoio55iMGUxDDpjZpT
mZSFIk1lfM/dQpQPXXIbKbuoDrSEy9g6kWyeUoxt4fDhxShdaQ5ix0x1H57YE6ME
wEKsjYB6zQiToDINZOjsHY2ZuOfcWPUUSW1cweoV+NOgVbmF7Fn5yDjpvJ395NB8
iyraXelOWbpzAis5ryqstWli/+4U08frJ4ctYFpqunxezv23AvbVvL7OISQbL92o
kK0JqLpUK2vYXjOFzbQgpHzAPt8rhCTXwQlj4CAnoiz5wY9JtlePNFcSKx7vPvdA
cVj7W5LmG+9AszJ/eK7ql6LN3buA64/3rD5NLiuQg2r/+DSEcdFN3cS21qQ3SaR3
+YZkTNqu2qAP2sAbL9uxBu8j78gg/8DTxnvxxaXWhQWyOTFMtJWi4yjCaPc1DCdq
B+OCVoC5rOfc/VwxThsVsprRpeg4bJ2GgAtbnSwAm/Q3kyjFuNhuHXXgZmTIX7uk
QFXs+y6D2x0gatXSBaTSxP2gYEaf8Wef5NJrRiH67KhS8YuF232bXvuwxiGFC9ua
aZlleYSScqbrqtNUxdgnHBaDJ62HiD1OBn20jX4SGgG0eTSb4siSQb0EzPvi59og
UYmihu9B7NzvOypJd7l8
=a4Cv
-END PGP SIGNATURE-
+ sudo timeout -k 12.1h 12h /usr/bin/ionice -c 3 /usr/bin/nice 
/usr/sbin/pbuilder --build --configfile 
/srv/reproducible-results/tmp.bToWa9OKaI/pbuilderrc_F0cp --debbuildopts -b 
--basetgz /var/cache/pbuilder/unstable-reproducible-base.tgz --buildresult b1 
--logfile b1/build.log 

Bug#797992: [Pkg-octave-devel] Bug#797992: octave: ABI transition needed for libstdc++ v5

[Rafael Laboissiere]

* Simon McVittie  [2015-09-04 10:16]:


On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:

Looking at the C++ library build-dependencies of octave, it is
waiting for hdf5 (#791067) but everything else seems to be ready.


Looking more closely at this, hdf5 has both a C and a C++ API, 
and octave appears to only use the C. If this is correct, then it does 
not need to wait for hdf5 after all.


The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
a rebuild really necessary?


Rafael

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> On Fri, 04 Sep 2015, Aron Xu wrote:
> > I don't want to close it, nor I want make this version to testing, so
> > please don't lower the severity, as said above.
> 
> Why don't you want this version into testing?

I'm not the maintainer, but I think that it is probably cleaner to
have testing version = stable version until this bug is fixed (it
would be different if testing had already diverged from stable).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Processed: fixed 795429 in 1.2.1-7.8+deb6u1

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> fixed 795429 1.2.1-7.8+deb6u1
Bug #795429 [src:openslp-dfsg] CVE-2015-5177
Marked as fixed in versions openslp-dfsg/1.2.1-7.8+deb6u1.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
795429: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795429
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#795681: marked as done (python-oslo.i18n: FTBFS under some locales (eg. fr_CH.UTF-8))

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 11:20:55 +
with message-id 
and subject line Bug#795681: fixed in python-oslo.i18n 2.5.0-1
has caused the Debian Bug report #795681,
regarding python-oslo.i18n: FTBFS under some locales (eg. fr_CH.UTF-8)
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795681
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-oslo.i18n
Version: 1.5.0-2
Severity: serious
Justification: fails to build from source

Dear Maintainer,

python-oslo.i18n fails to build from source on unstable/amd64 under
some locales (eg. LANG=fr_CH.UTF-8):

  [..]
  
  ==
  FAIL:
  oslo_i18n.tests.test_fixture.PrefixLazyTranslationTest.test_default
  oslo_i18n.tests.test_fixture.PrefixLazyTranslationTest.test_default
  --
  _StringException: Traceback (most recent call last):
File "oslo_i18n/tests/test_fixture.py", line 103, in test_default
  self.assertEqual(expected_msg, _translate.translate(msg1))
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
338, in assertEqual
  self.assertThat(observed, matcher, message)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
423, in assertThat
  raise mismatch_error
  MismatchError: 'oslo.i18n/en_US: fake msg1' != u'oslo.i18n/fr_CH: fake
  msg1'
  Traceback (most recent call last):
  _StringException: Empty attachments:
stderr
stdout
  
  Traceback (most recent call last):
File "oslo_i18n/tests/test_fixture.py", line 103, in test_default
  self.assertEqual(expected_msg, _translate.translate(msg1))
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
338, in assertEqual
  self.assertThat(observed, matcher, message)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
423, in assertThat
  raise mismatch_error
  MismatchError: 'oslo.i18n/en_US: fake msg1' != u'oslo.i18n/fr_CH: fake
  msg1'
  
  Traceback (most recent call last):
  _StringException: Empty attachments:
stderr
stdout
  
  Traceback (most recent call last):
File "oslo_i18n/tests/test_fixture.py", line 103, in test_default
  self.assertEqual(expected_msg, _translate.translate(msg1))
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
338, in assertEqual
  self.assertThat(observed, matcher, message)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
423, in assertThat
  raise mismatch_error
  MismatchError: 'oslo.i18n/en_US: fake msg1' != u'oslo.i18n/fr_CH: fake
  msg1'
  
  
  ==
  FAIL:
  oslo_i18n.tests.test_fixture.PrefixLazyTranslationTest.test_extra_lang
  oslo_i18n.tests.test_fixture.PrefixLazyTranslationTest.test_extra_lang
  --
  _StringException: Traceback (most recent call last):
File "oslo_i18n/tests/test_fixture.py", line 121, in test_extra_lang
  self.assertEqual(expected_msg_en_US, _translate.translate(msg1))
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
338, in assertEqual
  self.assertThat(observed, matcher, message)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
423, in assertThat
  raise mismatch_error
  MismatchError: 'oslo.i18n/en_US: fake msg1' != u'oslo.i18n/fr_CH: fake
  msg1'
  Traceback (most recent call last):
  _StringException: Empty attachments:
stderr
stdout
  
  Traceback (most recent call last):
File "oslo_i18n/tests/test_fixture.py", line 121, in test_extra_lang
  self.assertEqual(expected_msg_en_US, _translate.translate(msg1))
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
338, in assertEqual
  self.assertThat(observed, matcher, message)
File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line
423, in assertThat
  raise mismatch_error
  MismatchError: 'oslo.i18n/en_US: fake msg1' != u'oslo.i18n/fr_CH: fake
  msg1'
  
  Traceback (most recent call last):
  _StringException: Empty attachments:
stderr
stdout
  
  Traceback (most recent call last):
File "oslo_i18n/tests/test_fixture.py", line 121, in test_extra_lang
  self.assertEqual(expected_msg_en_US, _translate.translate(msg1))
File 

Bug#798008: yaml-cpp: library transition needed with GCC 5 as default

[Julien Cristau]

Source: yaml-cpp
Version: 0.5.2-1
Severity: serious
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Hi,

your library exposes std::string or std::list in its public API, and
therefore the library package needs to be renamed.

Cheers,
Julien

The following is a form letter:

Background [1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 are using the new ABI.  Libraries built
from this source package export some of the new __cxx11 or B5cxx11 symbols, and
dropping other symbols.  If these symbols are part of the API of the library,
then this rebuild with g++-5 will trigger a transition for the library.

What is needed:

 - Rebuild the library using g++/g++-5. Note that most likely all C++
   libraries within the build dependencies need a rebuild too. You can
   find the log for a rebuild in
 https://people.debian.org/~doko/logs/gcc5-20150813/
   Search for "BEGIN GCC CXX11" in the log.

 - Decide if the symbols matching __cxx11 or B5cxx11 are part of the
   library API, and are used by the reverse dependencies of the
   library.

 - If there are no symbols matching __cxx11 or B5cxx11 in the symbols
   forming the library API, you should close this issue with a short
   explanation.
 
 - If there are no reverse dependencies, it should be the package
   maintainers decision if a transition is needed.  However this might
   break software which is not in the Debian archive, and built
   against these packages.

 - If a library transition is needed, please prepare for the change.
   Rename the library package, append "v5" to the name of the package
   (e.g. libfoo2 -> libfoo2v5). Such a change can be avoided, if you
   have a soversion bump and you upload this version instead of the
   renamed package.  Prepare a patch and attach it to this issue (mark
   this issue with patch), so that it is possible to NMU such a
   package. We'll probably have more than hundred transitions
   triggered. Then reassign the issue to release.debian.org and
   properly tag it as a transition issue, by sending an email to
   cont...@bugs.debian.org:
   
 user release.debian@packages.debian.org
 usertag  + transition
 block  by 790756
 reassign  release.debian.org
   
 - If unsure if a transition is needed, please tag the issue with help
   to ask for feedback from other Debian developers.

The libstdc++6 transition will be a large one, and it will come with a
lot of pain.  Please help it by preparing the follow-up transitions.

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition



signature.asc
Description: Digital signature

Bug#798010: [Python-modules-team] Bug#798010: ipython3: malicious dynamic python3 interpreter lookup via "/usr/bin/env python3" in main executable

[Scott Kitterman]

On Friday, September 04, 2015 02:30:47 PM Tobias Megies wrote:
> Package: ipython3
> Version: 2.3.0-2
> Severity: serious
> Justification: Debian Python Policy 2.4.2: Interpreter Location
> 
> Dear Maintainer,
> 
> the main executable /usr/bin/ipython3 has shebang line 1 "#!/usr/bin/env
> python3" and thus uses the first python3 interpreter found in $PATH doing a
> dynamic lookup at execution time.
> If a local user-space Python environment is coming first in $PATH it will
> thus yield the Python3 IPython prompt from user space and not from the
> system python. This will result in very puzzling situation and clearly is
> in violation of the Debian Python Policy which demands the hardcoded system
> python binary in shebang.
> 
> See Debian Python Policy 2.4.2 Interpreter location:
> https://www.debian.org/doc/packaging-manuals/python-policy/ch-> 
> python.html#s-interpreter_loc
> 
> === quote start
> The preferred specification for the Python interpreter is /usr/bin/python or
> /usr/bin/pythonX.Y. This ensures that a Debian installation of python is
> used and all dependencies on additional python modules are met.
> Maintainers should not override the Debian Python interpreter using
> /usr/bin/env python or /usr/bin/env pythonX.Y. This is not advisable as it
> bypasses Debian's dependency checking and makes the package vulnerable to
> incomplete local installations of python.
> === quote end

First, Python policy is not Debian policy, so violating it doesn't 
automatically make a serious bug.  Second, the policy says preferred and 
should quite deliberately as the /usr/bin/env approach is quite common in the 
Python world and we do not want to force maintainers to patch large numbers of 
packages to avoid it.

Scott K

signature.asc
Description: This is a digitally signed message part.

Processed: severity of 798010 is minor

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 798010 minor
Bug #798010 [ipython3] ipython3: malicious dynamic python3 interpreter lookup 
via "/usr/bin/env python3" in main executable
Severity set to 'minor' from 'serious'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
798010: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798010
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797227: segfault - gst_memory_unmap, libgstreamer

[Agustin Martin]

On Wed, Sep 02, 2015 at 12:18:28PM +0300, Sebastian Dröge wrote:
> On Mi, 2015-09-02 at 17:32 +0900, Changwoo Ryu wrote:
> > Yes, I just have tested the patch on faad plugin at the GNOME 
> > bugzilla 748571. And it fixes the problem.
> 
> Thanks for testing, 

Hi,

Also tested here with a personal package rebuild including that fix.
Problem seems fixed with it.

> question is if I should upload a new package with
> the fix to unstable or we just wait until 1.6.0 is released... which
> should happen in the next week or two.

I'd upload a new package with the fix. Even if upstream releases soon, new
package may need some extra work and delay the fix even more.

By the way, iceweasel's http://bugs.debian.org/788708 seems to be the same
problem.

Regards,

-- 
Agustin

Bug#797992: [Pkg-octave-devel] Bug#797992: Bug#797992: octave: ABI transition needed for libstdc++ v5

[Sébastien Villemot]

Le vendredi 04 septembre 2015 à 12:57 +0200, Rafael Laboissiere a
écrit :
> * Simon McVittie  [2015-09-04 10:16]:
> 
> > On Fri, 04 Sep 2015 at 10:00:04 +0100, Simon McVittie wrote:
> >> Looking at the C++ library build-dependencies of octave, it is
> >> waiting for hdf5 (#791067) but everything else seems to be ready.
> >
> > Looking more closely at this, hdf5 has both a C and a C++ API, 
> > and octave appears to only use the C. If this is correct, then it does 
> > not need to wait for hdf5 after all.
> 
> The liboctave3 package, version 4.0.0-3 in both unstable and testing, 
> depends on libstdc++6 >= 5.2.  This package does not exist in stable.  Is 
> a rebuild really necessary?

I confirm that the problem described by Simon is real, and that a
transition is needed.

For example, using octave (4.0.0-3) and octave-optim (1.4.1-1) from
unstable, one gets:

octave:1> numhessian
error: 
/usr/lib/x86_64-linux-gnu/octave/packages/optim-1.4.1/x86_64-pc-linux-gnu-api-v50+/numhessian.oct:
 failed to load: 
/usr/lib/x86_64-linux-gnu/octave/packages/optim-1.4.1/x86_64-pc-linux-gnu-api-v50+/numhessian.oct:
 undefined symbol: _ZNK5ArrayISsE17resize_fill_valueEv

The problematic symbol is:

$ c++filt _ZNK5ArrayISsE17resize_fill_valueEv
Array >::resize_fill_value() const

It has indeed to do with std::string.

Simon: I should take care of uploading a fixed octave package this
week-end (provided that HDF5 is indeed not a blocker). But feel free to
NMU if I don't act quickly enough.

-- 
 .''`.Sébastien Villemot
: :' :Debian Developer
`. `' http://sebastien.villemot.name
  `-  GPG Key: 4096R/381A7594

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Agustin Martin]

On Mon, Aug 31, 2015 at 08:29:19AM -0700, Josh Triplett wrote:
> On Fri, 21 Aug 2015 10:43:56 +0100 Tim-Philipp =?ISO-8859-1?Q?M=FCller?= 
>  wrote:
> > This looks at first glance like some GStreamer element(s) could not be
> > created, such as appsink, maybe others too; possibly because the
> > required GStreamer plugins are not installed. Combined with insufficient
> > error handling.
> > 
> > I note that this bug was reported against an iceweasel version that uses
> > the old and unmaintained GStreamer 0.10.x.
> > 
> > The current iceweasel version uses GStreamer 1.x, and I can't reproduce
> > this problem with 38.2.0esr-1 either.
> 
> I can reproduce this problem with 38.2.1esr-1 in unstable as well as
> 40.0.3-1 in experimental.  Vising any page embedding video (including
> YouTube or Twitter) crashes Iceweasel as soon as the video would start
> to play.
> 
> I have gstreamer1.0-plugins-base 1.4.5-2,
> gstreamer1.0-plugins-{good,bad,ugly} 1.4.5-2+b2, and gstreamer1.0-libav
> 1.4.5-3.

Hi,

This may well be the same gstreamer1.0-plugins-bad problem reported in
http://bugs.debian.org/797227.

-- 
Agustin

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 788708 gst-plugins-bad1.0 1.4.5-2
Bug #788708 [iceweasel] iceweasel: GStreamer causes segmentation fault
Bug reassigned from package 'iceweasel' to 'gst-plugins-bad1.0'.
No longer marked as found in versions iceweasel/40.0.3-3, 
iceweasel/38.2.1esr-1, and 38.0.1-2~bpo70+1.
Ignoring request to alter fixed versions of bug #788708 to the same values 
previously set
Bug #788708 [gst-plugins-bad1.0] iceweasel: GStreamer causes segmentation fault
There is no source info for the package 'gst-plugins-bad1.0' at version 
'1.4.5-2' with architecture ''
Unable to make a source version for version '1.4.5-2'
Marked as found in versions 1.4.5-2.
>
End of message, stopping processing here.

Please contact me if you need assistance.
-- 
788708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788708
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Fabio Natali]

On 04/09/15 14:30, Agustin Martin wrote:
[...]
> This may well be the same gstreamer1.0-plugins-bad problem reported in
> http://bugs.debian.org/797227.

Hi,

I can confirm that removing gstreamer1.0-plugins-bad solves the issue
here. (Btw, upgrading to the 1.5.90-1 version from Experimental didn't
help.)

Thanks a lot Agustin!

Fabio

-- 
Fabio Natali
http://fabionatali.com

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Diederik de Haas]

On Friday 04 September 2015 15:53:23 Guillaume Dupuy wrote:
> Le 04/09/2015 15:30, Agustin Martin a écrit :
> > Hi, This may well be the same gstreamer1.0-plugins-bad problem
> > reported in http://bugs.debian.org/797227.
> 
> Indeed, updating gstreamer1.0-plugins-bad to the experimental version
> solved this problem

Same here. Thank you very much :)


signature.asc
Description: This is a digitally signed message part.

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Simon McVittie]

On Mon, 24 Aug 2015 at 11:24:19 +0100, Daniel Glassey wrote:
> A new version of the library (1.7.5) is imminent and will require a
> transition anyway. So we'll start planning the transition to libsword12.

Please do the v5 transition anyway; the wider libstdc++ transition has
eaten a month so far, and we would really like it to be over. The
release team are more likely to kick packages out of testing than waiting
for a new SONAME. As I think I mentioned at the Debian-UK BBQ,
there are ~ 300 transitions involving ~ 3000 packages at the moment,
so the people dealing with them would really prefer to see conservative,
minimal-risk changes.

If you had 1.7.5 already staged in experimental, it had already built
on all architectures, and you had test-built its rdeps successfully,
then going directly to libsword12 might be OK; but that doesn't
appear to be the case. The libsword12 transition can still happen in the
usual way (with a transition slot and so on) after the libstdc++ horror
has finished; there aren't many packages involved, so it should be an
easy one under normal circumstances.

Vaguely related to this, a ftp team member noted that there are open
RM bugs for bibledit-gtk and xiphos, which seem to be in the same
general area (bible study), and might get processed soon. If these
are of interest to you, please reply to the removal bugs and either
say "yes, this should be removed from unstable", or say what the plan
is for fixing the issues that led to the bug.

S

Bug#796305: python-oauthlib: FTBFS: plugin distutils failed with: exit code=1:

[Daniele Tricoli]

Hello Chris,

On Thursday 03 September 2015 13:55:06 Chris Lamb wrote:
> Yes, just send a new email as follows (or reply and modify this one):
> 
>   To: 796305-d...@bugs.debian.org
>   Subject: Re: python-oauthlib: FTBFS: plugin distutils failed with:
>   exit code=1:
> 
>   Version: 1.0.3-1
> 
>   (whatever you want here)

Many thanks, I did it once but I wanted to be sure!

I'm closing this with a separate email.

Regards,

-- 
 Daniele Tricoli 'eriol'
 https://mornie.org

signature.asc
Description: This is a digitally signed message part.

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Fabio Natali]

On Fri, 4 Sep 2015 15:53:23 +0200 Guillaume Dupuy  wrote:
[...]
> Indeed, updating gstreamer1.0-plugins-bad to the experimental version
> solved this problem

I was wrong and Guillaume right: updating to the Experimental version
worked here too.

Thanks! f

-- 
Fabio Natali
http://fabionatali.com

Bug#788708: iceweasel: GStreamer causes segmentation fault

[Guillaume Dupuy]

Le 04/09/2015 15:30, Agustin Martin a écrit :
Hi, This may well be the same gstreamer1.0-plugins-bad problem 
reported in http://bugs.debian.org/797227. 
Indeed, updating gstreamer1.0-plugins-bad to the experimental version 
solved this problem

Bug#797438: marked as done (ekiga: FTBFS with g++-5: error: 'cout' is not a member of 'std')

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 13:33:58 +
with message-id 
and subject line Bug#797438: fixed in ekiga 4.0.1-6
has caused the Debian Bug report #797438,
regarding ekiga: FTBFS with g++-5: error: 'cout' is not a member of 'std'
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
797438: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797438
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: ekiga
Version: 4.0.1-5
Severity: serious
Justification: fails to build from source (but built successfully in the past)

I've just sponsored an upload of ptlib to do the libstdc++ transition,
and test-built its reverse dependencies. opal and h323plus were successful,
but ekiga failed to build:

../../plugins/loudmouth/loudmouth-dialect.cpp: In member function 'void 
LM::Dialect::on_open_group_chat_submitted(bool, Ekiga::Form&)':
../../plugins/loudmouth/loudmouth-dialect.cpp:153:3: error: 'cout' is not a 
member of 'std'
   std::cout << "Should enter the room '" << name << "' with pseudonym '" << 
pseudo << "'" << std::endl;
   ^
Makefile:641: recipe for target '../../plugins/loudmouth/loudmouth-dialect.lo' 
failed

Full log attached.

I think this is probably because it doesn't include all the headers it
should, but in previous versions of libstdc++, the header that declares
std::cout happened to be pulled in by a header that this file does include
and so the build succeeded.

The ptlib upload is in NEW but should hopefully be processed
reasonably soon. I'm uploading source and an amd64 build to
 if you need them before then.

S


ekiga_4.0.1-5+b0+smcv1_amd64-20150830-1609.build.gz
Description: application/gzip
--- End Message ---
--- Begin Message ---
Source: ekiga
Source-Version: 4.0.1-6

We believe that the bug you reported is fixed in the latest version of
ekiga, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 797...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Eugen Dedu  (supplier of updated ekiga package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 04 Sep 2015 13:35:19 +0200
Source: ekiga
Binary: ekiga ekiga-dbg ekiga-plugin-evolution
Architecture: source amd64
Version: 4.0.1-6
Distribution: unstable
Urgency: low
Maintainer: Kilian Krause 
Changed-By: Eugen Dedu 
Description:
 ekiga  - H.323 and SIP compatible VoIP client
 ekiga-dbg  - H.323 and SIP compatible VoIP client - debug symbols
 ekiga-plugin-evolution - H.323 and SIP compatible VoIP client - evolution 
plugin
Closes: 797438
Changes:
 ekiga (4.0.1-6) unstable; urgency=low
 .
   [ Josselin Mouette ]
   * Remove Debian menu entry.
 .
   [ Eugen Dedu ]
   * Fix FTBS with GCC 5 by disabling experimental XMPP, as per upstream
 recommendation (Closes: #797438)
Checksums-Sha1:
 8bf32a3223659eb5c8633e77336f6084af2957d8 2495 ekiga_4.0.1-6.dsc
 451bfd6ebdd3acbe36d1991076074574d79f2cfe 14340 ekiga_4.0.1-6.debian.tar.xz
 d845ee102d88f47ec8c2d75e72ed0ccecd885dbb 16555932 ekiga-dbg_4.0.1-6_amd64.deb
 4d64a6bbc918e000cdf67c1391c70702eef9cb4f 55696 
ekiga-plugin-evolution_4.0.1-6_amd64.deb
 ffdbfbcfc8ddc74fbb1543b9073cbe47faa154c2 7832764 ekiga_4.0.1-6_amd64.deb
Checksums-Sha256:
 8b94dfb3cfc13c3984af67c580a8fd22a418fcd1528651d3e3786ee365377c54 2495 
ekiga_4.0.1-6.dsc
 57ac66b3d755dfc2c5d2a0892c5e61a7fc24b208b47171001b096818ab0a8421 14340 
ekiga_4.0.1-6.debian.tar.xz
 078fd4554e420b9229f3f3a1b23d0bd12a8fd5badb8ae3afaefc4e48bd36d3c1 16555932 
ekiga-dbg_4.0.1-6_amd64.deb
 fd53d5ac5a099e0e7c3f3ce1136f380a9063c3a2bc92a94321bd9928fbda0fbe 55696 
ekiga-plugin-evolution_4.0.1-6_amd64.deb
 acf438aa8c05c6a12c594a665e772cee0354b2f3bcaad36bdc20157a285b84ca 7832764 
ekiga_4.0.1-6_amd64.deb
Files:
 15e941c3dc8cc1c5c9647a17d84b6fb5 2495 gnome optional ekiga_4.0.1-6.dsc
 e73c7db4e3e3118bdb0fa940738476e6 14340 gnome optional 
ekiga_4.0.1-6.debian.tar.xz
 4365b4061d4ba7a60954ee42e209ac9d 16555932 debug extra 
ekiga-dbg_4.0.1-6_amd64.deb
 05b0bd2d2411363ee24d6e3191801a63 55696 gnome extra 

Bug#796305: marked as done (python-oauthlib: FTBFS: plugin distutils failed with: exit code=1:)

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 16:38:37 +0200
with message-id <1479863.q2pdaigKQ5@mornie>
and subject line Re: python-oauthlib: FTBFS: plugin distutils failed with: exit 
code=1:
has caused the Debian Bug report #796305,
regarding python-oauthlib: FTBFS: plugin distutils failed with: exit code=1:
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
796305: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796305
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: python-oauthlib
Version: 1.0.0-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

python-oauthlib fails to build from source on unstable/amd64:

  [..]
  File
  
"/home/lamby/temp/cdt.20150821100530.99BeiMwkaU/python-oauthlib-1.0.0/.pybuild/pythonX.Y_2.7/build/oauthlib/oauth2/rfc6749/clients/web_application.py",
  line 72, in
  
oauthlib.oauth2.rfc6749.clients.web_application.WebApplicationClient.prepare_request_uri
  Failed example:
  client.prepare_request_uri('https://example.com',
  redirect_uri='https://a.b/callback')
  Expected:
  
'https://example.com?client_id=your_id_type=code_uri=https%3A%2F%2Fa.b%2Fcallback'
  Got:
  
u'https://example.com?response_type=code_id=your_id_uri=https%3A%2F%2Fa.b%2Fcallback'
  --
  File
  
"/home/lamby/temp/cdt.20150821100530.99BeiMwkaU/python-oauthlib-1.0.0/.pybuild/pythonX.Y_2.7/build/oauthlib/oauth2/rfc6749/clients/web_application.py",
  line 74, in
  
oauthlib.oauth2.rfc6749.clients.web_application.WebApplicationClient.prepare_request_uri
  Failed example:
  client.prepare_request_uri('https://example.com',
  scope=['profile', 'pictures'])
  Expected:
  
'https://example.com?client_id=your_id_type=code=profile+pictures'
  Got:
  
u'https://example.com?response_type=code_id=your_id=profile+pictures'
  --
  File
  
"/home/lamby/temp/cdt.20150821100530.99BeiMwkaU/python-oauthlib-1.0.0/.pybuild/pythonX.Y_2.7/build/oauthlib/oauth2/rfc6749/clients/web_application.py",
  line 76, in
  
oauthlib.oauth2.rfc6749.clients.web_application.WebApplicationClient.prepare_request_uri
  Failed example:
  client.prepare_request_uri('https://example.com', foo='bar')
  Expected:
  'https://example.com?client_id=your_id_type=code=bar'
  Got:
  u'https://example.com?response_type=code_id=your_id=bar'
  
  
  --
  Ran 11 tests in 0.430s
  
  FAILED (errors=1, failures=10)
  E: pybuild pybuild:262: test: plugin distutils failed with: exit
  code=1: cd
  
/home/lamby/temp/cdt.20150821100530.99BeiMwkaU/python-oauthlib-1.0.0/.pybuild/pythonX.Y_2.7/build;
  python2.7 -m nose --with-doctest 
  dh_auto_test: pybuild --test --test-nose -i python{version} -p 2.7
  --dir . returned exit code 13
  debian/rules:8: recipe for target 'build' failed
  make: *** [build] Error 25

  [..]

The full build log is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
 dpkg-buildpackage -rfakeroot -D -us -uc -b
dpkg-buildpackage: source package python-oauthlib
dpkg-buildpackage: source version 1.0.0-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Daniele Tricoli 
 dpkg-source --before-build python-oauthlib-1.0.0
dpkg-buildpackage: host architecture amd64
 fakeroot debian/rules clean
dh clean --with python2,python3 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:170: python2.7 setup.py clean 
running clean
removing 
'/home/lamby/temp/cdt.20150821100530.99BeiMwkaU/python-oauthlib-1.0.0/.pybuild/pythonX.Y_2.7/build'
 (and everything under it)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-2.7' does not exist -- can't clean it
I: pybuild base:170: python3.4 setup.py clean 
running clean
removing 
'/home/lamby/temp/cdt.20150821100530.99BeiMwkaU/python-oauthlib-1.0.0/.pybuild/pythonX.Y_3.4/build'
 (and everything under it)
/usr/lib/python3.4/imp.py:32: PendingDeprecationWarning: the imp module is 
deprecated in favour of importlib; see the module's documentation for 
alternative uses
  PendingDeprecationWarning)
'build/bdist.linux-x86_64' does not exist -- can't clean it
'build/scripts-3.4' does not exist -- can't 

Bug#796711: [Pkg-crosswire-devel] Bug#796711: Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

On Fri, Sep 04, 2015 at 11:21:03AM -0400, Roberto C. Sánchez wrote:
> Daniel,
> 
> I've been meaning to help out with this for some time, but I have been
> extrememly busy the last few months.  Let me at least help by making the
> upload.  Can you point me to the source package?

Thanks Roberto, I've moved discussion about this to the bibledit-gtk bug 
#790200.

Regards,
Daniel


signature.asc
Description: Digital signature

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Julien Cristau]

On Fri, Sep  4, 2015 at 15:52:58 +0100, Daniel Glassey wrote:

> On Fri, Sep 04, 2015 at 02:48:45PM +0100, Simon McVittie wrote:
> > Vaguely related to this, a ftp team member noted that there are open
> > RM bugs for bibledit-gtk and xiphos, which seem to be in the same
> > general area (bible study), and might get processed soon. If these
> > are of interest to you, please reply to the removal bugs and either
> > say "yes, this should be removed from unstable", or say what the plan
> > is for fixing the issues that led to the bug.
> 
> I haven't worked out who I should contact yet but I uploaded a new version of 
> bibledit-gtk earlier in the week that 
> had been in experimental (bibledit-gtk_4.8-1). I uploaded the source as well 
> by mistake with bibledit-gtk_4.8-2. I 
> got a mail saying it had been uploaded but didn't get an ACCEPT email. After 
> I realised that I made some more changes 
> and uploaded bibledit-gtk_4.8-3 binary only which was to close the removal 
> bug and had the same thing happen.
> 

20150901000442|process-upload|dak|bibledit-gtk_4.8-2_amd64.changes|Error while 
loading changes: No valid signature found. (GPG exited with status code 0)
gpg: Signature made Mon Aug 31 23:00:14 2015 UTC using RSA key ID AF060C5A
gpg: Good signature from "Daniel Glassey "
gpg: aka "Daniel Glassey "
gpg: aka "Daniel Glassey "
gpg: WARNING: Using untrusted key!

jcristau@franck:~$ gpg --no-default-keyring --keyring 
/srv/keyring.debian.org/keyrings/debian-keyring.gpg --list-key AF060C5A
pub   4096R/AF060C5A 2013-08-08 [expired: 2015-07-27]

Your key's expiration date needs an update in the debian keyring.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#795287: marked as done (evolution-data-server: Cannot connect to gmail account any longer)

[Debian Bug Tracking System]

Your message dated Fri, 4 Sep 2015 16:41:37 +0100
with message-id <20150904154137.ga4...@perpetual.pseudorandom.co.uk>
and subject line Re: Bug#795287: evolution-data-server: Cannot connect to gmail 
account any longer
has caused the Debian Bug report #795287,
regarding evolution-data-server: Cannot connect to gmail account any longer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
795287: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795287
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: evolution-data-server
Version: 3.16.3-1.1
Severity: serious
Tags: sid stretch

Hi,

With the latest debian packages, 3.16.3-1.1 evo cannot any longer
connect to Contacts and the gmail account:

Failed to connect to 'Contacts'
Cannot find a corresponding account in the org.gnome.OnlineAccounts
service from which to obtain a password for 'a...@gmail.com'

Failed to connect account 'a...@gmail.com'
The reported error was "Source 'a...@gmail.com' doesn't support prompt
for credentials.

This problem has been found in archlinux already:
https://bugs.archlinux.org/task/45394 and reported to work OK with
3.16.4, so please package that version or the latest version 3.16.5 in
sid.

Communicating on the evolution ML gave the following answer (quoting
Milan Crha):

> > The only hit by googling is https://bugs.archlinux.org/task/45394
> 
> Aah, it references even the fix (kind of), and reports 3.16.4 has it
> fixed. They are right, the fix doesn't correct already broken account,
> it "only" avoids breakage of newly created accounts, thus the recreate
> of the account is needed.

> It also makes more sense to me now. I suppose you didn't use GOA at
> all, you entered your GMail account directly in the Evolution and
> ticked at the end of the New Account Wizard to create also the
> Contacts and possibly Calendars.
> 
> Just go to Edit->Preferences->Mail Accounts and delete the GMail
> account there. Then create it again, but do not let it create the
> Contacts. The Contacts require OAuth2 authentication, which evolution
> currently supports only through GOA.
> 
> I do not think the roundtrip of adding the new account will be of any
> help if you'll still use the 3.16.3 though, as that will break the
> newly created account again.

and in a later mail:
> The actual bug was about adding GOA information into accounts which
> had nothing to do with GOA, then resulting into the issue with the
> password you face.
--- End Message ---
--- Begin Message ---
Version: 3.16.5-1
Control: found 795287 3.16.3-1

On Wed, 12 Aug 2015 at 18:40:03 +0200, Svante Signell wrote:
> This problem has been found in archlinux already:
> https://bugs.archlinux.org/task/45394 and reported to work OK with
> 3.16.4, so please package that version or the latest version 3.16.5 in
> sid.

Believed to be fixed in 3.16.4 as per the report. Please reopen
if this is not the case. Note that, if I'm reading the upstream reports
correctly, accounts created with 3.16.3 are known to be broken even
after upgrading, so please do not reopen unless an account created
with 3.16.5 or later has this issue.

Also marking it as "found" in 3.16.3-1, since upstream acknowledge this
bug as present in 3.16.3. At the moment, the BTS thinks this bug was
specifically introduced by my NMU 3.16.3-1.1, which seems highly unlikely
and is getting in the way of the libstdc++ transition; if you reopen it,
we'll still want newer versions to migrate.

S--- End Message ---

Bug#797043: Bug#797079: wheezy-pu: package mozilla-noscript/2.6.8.19-1~deb7u2

[Kalle Olavi Niemitalo]

David Prévot  writes in Bug#797079:

> Uploaded (with the improved changelog and metadata suggested by Kalle),
> thanks.

I installed xul-ext-noscript 2.6.8.19-1~deb7u2 from
wheezy-proposed-updates, and it works OK.

However, I see the patch now has the following line:

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42=upstream/2.6.8.42_rc1

That URL is a bit misleading because the diff is neither from
upstream/2.6.8.42 to upstream/2.6.8.42_rc1 nor vice versa;
it's instead from the parent commit (upstream/2.6.8.41) to
upstream/2.6.8.42_rc1.  When the query string of the URL contains
multiple "h" fields, cgit uses only the last one:

http://git.zx2c4.com/cgit/tree/cgit.c?h=v0.11.2#n300

A shorter URL would thus work just as well:

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42_rc1

Or if you wanted to specify the older version explicitly,
you'd use "id2":

Origin: backport, 
http://anonscm.debian.org/cgit/pkg-mozext/noscript.git/diff/components/noscriptService.js?h=upstream/2.6.8.42_rc1=upstream/2.6.8.41

It's totally not worth making a new upload but I wanted to
mention it in case more backports are needed later.

Processed: your mail

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 796356 serious
Bug #796356 [python-urllib3] python-urllib3: broken when python-future is 
installed, fix available upstream
Severity set to 'serious' from 'normal'
> merge 796356 797070
Bug #796356 [python-urllib3] python-urllib3: broken when python-future is 
installed, fix available upstream
Bug #797070 [python-urllib3] [python-urllib3] Break python-requests and 
transitively vim-youcompleteme
Added tag(s) pending.
Merged 796356 797070
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
796356: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796356
797070: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797070
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#796711: [Pkg-crosswire-devel] Bug#796711: Bug#796711: sword: library transition is needed with GCC 5 as default

[Roberto C . Sánchez]

Daniel,

I've been meaning to help out with this for some time, but I have been
extrememly busy the last few months.  Let me at least help by making the
upload.  Can you point me to the source package?

Regards,

-Roberto

On Fri, Sep 04, 2015 at 05:07:50PM +0200, Julien Cristau wrote:
> On Fri, Sep  4, 2015 at 15:52:58 +0100, Daniel Glassey wrote:
> 
> > On Fri, Sep 04, 2015 at 02:48:45PM +0100, Simon McVittie wrote:
> > > Vaguely related to this, a ftp team member noted that there are open
> > > RM bugs for bibledit-gtk and xiphos, which seem to be in the same
> > > general area (bible study), and might get processed soon. If these
> > > are of interest to you, please reply to the removal bugs and either
> > > say "yes, this should be removed from unstable", or say what the plan
> > > is for fixing the issues that led to the bug.
> > 
> > I haven't worked out who I should contact yet but I uploaded a new version 
> > of bibledit-gtk earlier in the week that 
> > had been in experimental (bibledit-gtk_4.8-1). I uploaded the source as 
> > well by mistake with bibledit-gtk_4.8-2. I 
> > got a mail saying it had been uploaded but didn't get an ACCEPT email. 
> > After I realised that I made some more changes 
> > and uploaded bibledit-gtk_4.8-3 binary only which was to close the removal 
> > bug and had the same thing happen.
> > 
> 
> 20150901000442|process-upload|dak|bibledit-gtk_4.8-2_amd64.changes|Error 
> while loading changes: No valid signature found. (GPG exited with status code 
> 0)
> gpg: Signature made Mon Aug 31 23:00:14 2015 UTC using RSA key ID AF060C5A
> gpg: Good signature from "Daniel Glassey "
> gpg: aka "Daniel Glassey "
> gpg: aka "Daniel Glassey "
> gpg: WARNING: Using untrusted key!
> 
> jcristau@franck:~$ gpg --no-default-keyring --keyring 
> /srv/keyring.debian.org/keyrings/debian-keyring.gpg --list-key AF060C5A
> pub   4096R/AF060C5A 2013-08-08 [expired: 2015-07-27]
> 
> Your key's expiration date needs an update in the debian keyring.
> 
> Cheers,
> Julien



> ___
> Pkg-crosswire-devel mailing list
> pkg-crosswire-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-crosswire-devel


-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Bug#795287: evolution-data-server: Cannot connect to gmail account any longer

[Iain Lane]

Hi,

On Wed, Aug 12, 2015 at 06:40:03PM +0200, Svante Signell wrote:
> […]
> This problem has been found in archlinux already:
> https://bugs.archlinux.org/task/45394 and reported to work OK with
> 3.16.4, so please package that version or the latest version 3.16.5 in
> sid.

We have .5 now. Can you try it and see if it really does fix the bug
please?

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]


signature.asc
Description: Digital signature

Bug#797744: [Debichem-devel] Bug#797744: gromacs: shared library in a package that is not renamed with its SONAME

[Nicholas Breen]

On Wed, Sep 02, 2015 at 09:15:58AM +0100, Simon McVittie wrote:
> Source: gromacs
> Version: 5.0.6-1
> Severity: serious
> Justification: Policy 8.1
> 
> The gromacs binary package contains a public shared library
> (libgromacs.so.0), and votca-csg depends on it.
> 
> Policy §8.1 says:
> 
> > The run-time shared library must be placed in a package whose name
> > changes whenever the SONAME of the shared library changes.

Yeah, that's a leftover from before votca entered the archive, and gromacs fell
under the "Shared libraries that are internal to a particular package" wording,
making it exempt from section 8.

I'll see if I can split it for 5.1, but it'll be at least three weeks until I
can get to working on that.  On the plus side, maybe the C++ transitions will
have settled down a little by then.


-- 
Nicholas Breen
nbr...@debian.org

Processed: bug 797284 is forwarded to https://sourceforge.net/p/tango-cs/bugs/735/

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> forwarded 797284 https://sourceforge.net/p/tango-cs/bugs/735/
Bug #797284 [src:pytango] pytango ftbfs in unstable
Set Bug forwarded-to-address to 'https://sourceforge.net/p/tango-cs/bugs/735/'.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
797284: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797284
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

On Fri, Sep 04, 2015 at 05:07:50PM +0200, Julien Cristau wrote:
> On Fri, Sep  4, 2015 at 15:52:58 +0100, Daniel Glassey wrote:
> 
> > On Fri, Sep 04, 2015 at 02:48:45PM +0100, Simon McVittie wrote:
> > > Vaguely related to this, a ftp team member noted that there are open
> > > RM bugs for bibledit-gtk and xiphos, which seem to be in the same
> > > general area (bible study), and might get processed soon. If these
> > > are of interest to you, please reply to the removal bugs and either
> > > say "yes, this should be removed from unstable", or say what the plan
> > > is for fixing the issues that led to the bug.
> > 
> > I haven't worked out who I should contact yet but I uploaded a new version 
> > of bibledit-gtk earlier in the week that 
> > had been in experimental (bibledit-gtk_4.8-1). I uploaded the source as 
> > well by mistake with bibledit-gtk_4.8-2. I 
> > got a mail saying it had been uploaded but didn't get an ACCEPT email. 
> > After I realised that I made some more changes 
> > and uploaded bibledit-gtk_4.8-3 binary only which was to close the removal 
> > bug and had the same thing happen.
> > 
> 
> 20150901000442|process-upload|dak|bibledit-gtk_4.8-2_amd64.changes|Error 
> while loading changes: No valid signature found. (GPG exited with status code 
> 0)
> gpg: Signature made Mon Aug 31 23:00:14 2015 UTC using RSA key ID AF060C5A
> gpg: Good signature from "Daniel Glassey "
> gpg: aka "Daniel Glassey "
> gpg: aka "Daniel Glassey "
> gpg: WARNING: Using untrusted key!
> 
> jcristau@franck:~$ gpg --no-default-keyring --keyring 
> /srv/keyring.debian.org/keyrings/debian-keyring.gpg --list-key AF060C5A
> pub   4096R/AF060C5A 2013-08-08 [expired: 2015-07-27]
> 
> Your key's expiration date needs an update in the debian keyring.

Ah, of course. I updated the expiry and sent it to the debian keyserver last 
weekend so I'll email those RM bugs and 
prepare the transition patch and wait til the keyring is updated before doing 
any more uploads.

Thanks,
Daniel



signature.asc
Description: Digital signature

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Daniel Glassey]

On Fri, Sep 04, 2015 at 02:48:45PM +0100, Simon McVittie wrote:
> On Mon, 24 Aug 2015 at 11:24:19 +0100, Daniel Glassey wrote:
> > A new version of the library (1.7.5) is imminent and will require a
> > transition anyway. So we'll start planning the transition to libsword12.
> 
> Please do the v5 transition anyway; 
[good reasons]

Hi Simon, Funnily enough as 1.7.5 wasn't as imminent as I thought I'd started 
preparing the transition so I should 
get that done either later today or at the weekend.

> Vaguely related to this, a ftp team member noted that there are open
> RM bugs for bibledit-gtk and xiphos, which seem to be in the same
> general area (bible study), and might get processed soon. If these
> are of interest to you, please reply to the removal bugs and either
> say "yes, this should be removed from unstable", or say what the plan
> is for fixing the issues that led to the bug.

I haven't worked out who I should contact yet but I uploaded a new version of 
bibledit-gtk earlier in the week that 
had been in experimental (bibledit-gtk_4.8-1). I uploaded the source as well by 
mistake with bibledit-gtk_4.8-2. I 
got a mail saying it had been uploaded but didn't get an ACCEPT email. After I 
realised that I made some more changes 
and uploaded bibledit-gtk_4.8-3 binary only which was to close the removal bug 
and had the same thing happen.

Regards,
Daniel


signature.asc
Description: Digital signature

Processed: retitle 796917 to RM: snappy1.0.3-java -- ROM; obsolete, duplicate

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 796917 RM: snappy1.0.3-java -- ROM; obsolete, duplicate
Bug #796917 [ftp.debian.org] ROM: Please remove snappy1.0.3-java from unstable 
and testing
Changed Bug title to 'RM: snappy1.0.3-java -- ROM; obsolete, duplicate' from 
'ROM: Please remove snappy1.0.3-java from unstable and testing'
> retitle 753854 RM: clinia -- ROM; RC buggy, unmaintained, libgee2 removal
Bug #753854 [ftp.debian.org] ROM: clinia - please remove from Debian
Changed Bug title to 'RM: clinia -- ROM; RC buggy, unmaintained, libgee2 
removal' from 'ROM: clinia - please remove from Debian'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
753854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753854
796917: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796917
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#796711: [Pkg-crosswire-devel] Bug#796711: sword: library transition is needed with GCC 5 as default

[Simon McVittie]

On 04/09/15 15:52, Daniel Glassey wrote:
> On Fri, Sep 04, 2015 at 02:48:45PM +0100, Simon McVittie wrote:
>> Vaguely related to this, a ftp team member noted that there are open
>> RM bugs for bibledit-gtk and xiphos, which seem to be in the same
>> general area (bible study), and might get processed soon. If these
>> are of interest to you, please reply to the removal bugs and either
>> say "yes, this should be removed from unstable", or say what the plan
>> is for fixing the issues that led to the bug.
> 
> I haven't worked out who I should contact yet

https://bugs.debian.org/ftp.debian.org

and more specifically

https://bugs.debian.org/797564
https://bugs.debian.org/797568

which I see you have contacted already. That was the right thing to do.

> I uploaded the source as well by mistake with bibledit-gtk_4.8-2.

All uploads of new versions to Debian need source code; it's kind of the
point :-)

Redundantly uploading the orig.tar.gz even though it is in the archive
already (due to using e.g. debuild -sa) is harmless, apart from wasting
a bit of bandwidth.

> After I realised that I made some more changes 
> and uploaded bibledit-gtk_4.8-3 binary only

Binary-only uploads of a version whose source is not in the archive
would be rejected. Do you mean "diff only"?

> which was to close the removal bug

Closing removal bugs (and other bugs in pseudo-packages) via packages'
changelogs doesn't seem right in any case. If a removal request seems
wrong, send mail to its bug address explaining why it shouldn't be
removed, as you already did; and if you're really sure your reasons are
good, close it by using the -done address (but there's no need to do
that for those two removal bugs, because Scott already did).

S

Bug#797233: libsndio-dev and libroar-dev: error when trying to install together

[Peter Piwowarski]

Once again, I believe it's probably best for libroar-dev to simply ship 
libroarsndio without the libsndio.so symlink, so packages that really 
want it and not libsndio can simply use -lroarsndio. (apologies for 
missing this link earlier!)

Bug#748737: [request-tracker-maintainers] Bug#748737: Bug#748737: rt4-extension-assettracker: fails to upgrade from wheezy

[Jerome Charaoui]

> On Thu, Oct 02, 2014 at 07:27:05AM +, Chris Caldwell wrote:
> > Looks like the upstream's an orphaned project (no commits for 6 months) and 
> > won't be updated for RT 4.2.

Although it's true that upstream seems to have abandoned the project,
work had already begun to update the plugin to 4.2, see branch
3.2/support-4.2 [1]


> > Is this a good place to suggest Best Practical's own RT::Extension::Assets 
> > (http://bestpractical.com/assets) as a candidate for packaging?

The recommended pratice is to submit an RFP [2].


> It's as good as any. Unfortunately I think it is now too late to get
> a new package into jessie. One interesting question is if there is
> any sane data migration strategy between the two: that might affect
> the immediate value of packaging RT::Extension::Assets.

To my knowledge there is no migration path between the two. I think
Debian users of this extension would be best served at this time by
packaging the 4.2 branch and publishing it in the experimental archive.
I've been using it for a bit and although there are a couple of bugs, it
works well enough that the data is still useable, which IMHO is an
acceptable temporary option before BestPractical or someone else decides
to write code to migrate data between the two extensions.

Thanks,

-- Jerome



[1]
https://github.com/AssetTracker/rt-extension-assettracker/tree/3.2/support-rt-4.2
[2] https://wiki.debian.org/RFP



signature.asc
Description: OpenPGP digital signature

Bug#793260: [Pkg-ime-devel] Bug#793260: Bug#793260: marisa: change of type in system_error might break with GCC-5

[Mitsuya Shibata]

Hi, Guo

2015-09-03 2:35 GMT+09:00 Guo Yixuan :
> Actually, after rebuilding with 5.2, there's only one symbol with cxx11 ABI
> substring:
>U typeinfo for std::ios_base::failure[abi:cxx11]
>

Thank you for your investigation. I confirmed not rename package or soname.

1. marisa only use std::ios_base::failure in reader.cc/writer.cc
2. This just catch the exception, and throw an original exception (by
MARISA_THROW).
3. This original exception (Exception class) inherit std::exception
(not std::system_error).
4. marisa::Exception receive "std:ios_base::failure" as an error string.
5. Software link libmarisa will catch marisa::Exception only.

It seems that software which link libmarisa does not affect gcc5 transition.
I will upload package bumped up version to mentors,
and will send request for sponsorship.

Regards,
-- 
Mitsuya Shibata
mty.shib...@gmail.com

Processed: Re: Bug#797289: libxml-easyobj-perl: FTBFS: Can't locate object method "getXMLDecl" via package "XML::DOM::Element"

[Debian Bug Tracking System]

Processing control commands:

> tag -1 sid stretch
Bug #797289 [src:libxml-easyobj-perl] libxml-easyobj-perl: FTBFS: Can't locate 
object method "getXMLDecl" via package "XML::DOM::Element"
Added tag(s) sid and stretch.

-- 
797289: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797289
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#766884: libxml2 broken in sid for months already

[Raphael Hertzog]

Hi,

On Fri, 04 Sep 2015, Vincent Lefevre wrote:
> On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> > On Fri, 04 Sep 2015, Aron Xu wrote:
> > > I don't want to close it, nor I want make this version to testing, so
> > > please don't lower the severity, as said above.
> > 
> > Why don't you want this version into testing?
> 
> I'm not the maintainer, but I think that it is probably cleaner to
> have testing version = stable version until this bug is fixed (it
> would be different if testing had already diverged from stable).

"I think it's cleaner" is a bit light in arguments.

The stable and testing versions have 3 open security issues.
The unstable one has none. 

https://security-tracker.debian.org/tracker/source-package/libxml2

And for the rest, both versions are almost identical:
$ debdiff libxml2_2.9.1+dfsg1-5.dsc libxml2_2.9.2+really2.9.1+dfsg1-0.1.dsc 
|diffstat
 changelog   |   46 
++
 control |9 
 libxml2.symbols |8 
 patches/0056-Stop-parsing-on-entities-boundaries-errors.patch   |   28 
+
 patches/0057-Cleanup-conditional-section-error-handling.patch   |   45 
++
 patches/0058-Fix-upstream-bug-299127.patch  |   99 
+
 patches/0059-CVE-2015-1819-Enforce-the-reader-to-run-in-constant-.patch |  172 
++
 patches/series  |4 
 rules   |4 
 9 files changed, 405 insertions(+), 10 deletions(-)

So why would you want to keep a version that fixes 3 security issues out of
testing?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Bug#798049: scantailor FTBFS in current Sid

[Daniel Stender]

Package: scantailor
Version: 0.9.11.1-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Like reproducible builds test building revealed, Scantailor currently FTBFS in 
Sid.

I'll get into this, soon.

DS

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

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

Versions of packages scantailor depends on:
ii  dpkg 1.18.2
ii  libc62.19-19
ii  libgcc1  1:5.1.1-14
ii  libjpeg62-turbo  1:1.4.1-2
ii  libpng12-0   1.2.50-2+b2
ii  libqt4-xml   4:4.8.7+dfsg-1
ii  libqtcore4   4:4.8.7+dfsg-1
ii  libqtgui44:4.8.7+dfsg-1
ii  libstdc++6   5.1.1-14
ii  libtiff5 4.0.3-13
ii  libxrender1  1:0.9.8-1+b1

scantailor recommends no packages.

scantailor suggests no packages.

-- no debconf information

Processed: Re: Bug#797135: gnome-software downloads updates automatically by default

[Debian Bug Tracking System]

Processing control commands:

> severity 797135 important
Bug #797135 [src:gnome-software] gnome-software downloads updates automatically 
by default
Severity set to 'important' from 'critical'

-- 
797135: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797135
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797135: gnome-software downloads updates automatically by default

[Matthias Klumpp]

Control: severity 797135 important

Reducing severity - this issue is not making the package or other system
components unusable, and it is also not making the package unfit for
release.
So, an "important" priority is more justified for this.

Bug#797284: pytango ftbfs in unstable

[PICCA Frederic-Emmanuel]

Ok, with the new tango,I get another symbols problem

ImportError: /«PKGBUILDDIR»/build/lib.linux-i686-2.7/PyTango/_PyTango.so: 
undefined symbol: _ZN5Tango17ranges_type2constIsE3strE

Tango::ranges_type2const::str

so once again a problem with a string ???

Bug#793260: marked as done (marisa: change of type in system_error might break with GCC-5)

[Debian Bug Tracking System]

Your message dated Fri, 4 Sep 2015 21:59:26 +0200
with message-id <20150904195926.gn3...@betterave.cristau.org>
and subject line Re: Bug#793260: [Pkg-ime-devel] Bug#793260: Bug#793260: 
marisa: change of type in system_error might break with GCC-5
has caused the Debian Bug report #793260,
regarding marisa: change of type in system_error might break with GCC-5
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
793260: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793260
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: src:marisa
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: gcc-pr66145

GCC PR libstdc++/66145 is a regression in GCC 5 which won't be fixed
upstream in time for the GCC defaults change.  The work around is to
rebuild the affected packages after GCC 5 is the default compiler.
Please look at the code and decide, if the package is affected. If
not, please just close the issue.  If it's a real issue, I'll add
the packages affected to libstdc++6's Breaks attributes, with the
version of the package at the time of the defaults change.

See 
https://wiki.debian.org/GCC5#libstdc.2B-.2B-_c.2B-.2B-11_incompatibilities_.284.9_and_5.29
for further information.

To build with GCC 5,install the gcc, g++, gfortran, ... packages
from experimental (apt-get -t experimental install g++).
--- End Message ---
--- Begin Message ---
On Sat, Sep  5, 2015 at 04:47:46 +0900, Mitsuya Shibata wrote:

> Hi, Guo
> 
> 2015-09-03 2:35 GMT+09:00 Guo Yixuan :
> > Actually, after rebuilding with 5.2, there's only one symbol with cxx11 ABI
> > substring:
> >U typeinfo for std::ios_base::failure[abi:cxx11]
> >
> 
> Thank you for your investigation. I confirmed not rename package or soname.
> 
> 1. marisa only use std::ios_base::failure in reader.cc/writer.cc
> 2. This just catch the exception, and throw an original exception (by
> MARISA_THROW).
> 3. This original exception (Exception class) inherit std::exception
> (not std::system_error).
> 4. marisa::Exception receive "std:ios_base::failure" as an error string.
> 5. Software link libmarisa will catch marisa::Exception only.
> 
> It seems that software which link libmarisa does not affect gcc5 transition.
> I will upload package bumped up version to mentors,
> and will send request for sponsorship.
> 
If a rebuild is all that's needed, then no source upload should be done.
I'll schedule rebuilds on all architectures.

Cheers,
Julien


signature.asc
Description: Digital signature
--- End Message ---

Bug#798050: qtermwidget: FTBFS: symbols not as expected

[Aaron M. Ucko]

Source: qtermwidget
Version: 0.6.0-1
Severity: serious
Justification: fails to build from source

Automated builds of qtermwidget on Linux have been failing because the
set of (mangled) symbol names wasn't quite as expected, as detailed at
https://buildd.debian.org/status/logs.php?pkg=qtermwidget=0.6.0-1 .
(The kFreeBSD builds failed due to a totally unrelated issue, which
I'll report separately.)

There are actually two problems (which perhaps deserve separate reports):

* On 32-bit architectures such as i386, a number of symbols have
  different names; I suspect most of these discrepancies stem from
  differences in size_t's ultimate type (unsigned int on 32-bit
  platforms, unsigned long on 64-bit ones).  Please account for these
  differences, either directly or with the help of
  pkgkde-symbolshelper et al. from pkg-kde-tools.

* Even on 64-bit architectures such as arm64,
  QList::operator+=(QList const&)@Base is missing.
  I suspect the issue here to be that some build dependency changed
  while qtermwidget was in NEW, so I used severity serious because an
  amd64 rebuild could well encounter the same error.  That said, all
  symbols from Qt headers are presumably internal implementation
  details; I see no way to blacklist them altogether when processing
  the .symbols file, but you can at least mark them as optional to
  indicate that it's no big deal if any wind up disappearing.  (A
  better solution would be to hide these symbols via a linker script,
  but I don't know how feasible that would be.)

Could you please take a look?

Thanks!

Bug#797289: libxml-easyobj-perl: FTBFS: Can't locate object method "getXMLDecl" via package "XML::DOM::Element"

[Niko Tyni]

Control: tag -1 sid stretch

On Sat, Aug 29, 2015 at 10:38:43AM +0100, Dominic Hargreaves wrote:
> Source: libxml-easyobj-perl
> Version: 1.12-3
> Severity: serious
> Justification: FTBFS
> 
> This package FTBFS in a clean sid chroot:
> 
> Can't locate object method "getXMLDecl" via package "XML::DOM::Element" at 
> /usr/
> share/perl5/XML/DOM.pm line 1221.
> t/write.t . 

This was apparently broken by libxml-dom-perl 1.44-2, which added 
debian/patches/output_encoding.patch . Now that the patch was
integrated upstream in XML-DOM-1.45, it's probably failing upstream
too. 

Not sure if XML::EasyObj is doing something nasty or if
printing out XML::DOM::Element objects is broken for everybody...
-- 
Niko Tyni   nt...@debian.org

Processed: retitle 753854 to RM: clinica -- ROM; RC buggy, unmaintained, libgee2 removal

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 753854 RM: clinica -- ROM; RC buggy, unmaintained, libgee2 removal
Bug #753854 [ftp.debian.org] RM: clinica -- ROM
Changed Bug title to 'RM: clinica -- ROM; RC buggy, unmaintained, libgee2 
removal' from 'RM: clinica -- ROM'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
753854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: retitle 753854 to RM: clinica -- ROM

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 753854 RM: clinica -- ROM
Bug #753854 [ftp.debian.org] RM: clinia -- ROM; RC buggy, unmaintained, libgee2 
removal
Changed Bug title to 'RM: clinica -- ROM' from 'RM: clinia -- ROM; RC buggy, 
unmaintained, libgee2 removal'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
753854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#794332: [Pkg-sssd-devel] Bug#794332: sssd-common: deletes conffile owned by sssd: /etc/logrotate.d/sssd

[Timo Aaltonen]

On 01.08.2015 17:19, Andreas Beckmann wrote:
> Package: sssd-common
> Version: 1.12.5-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + sssd
> 
> Hi,
> 
> during a test with piuparts I noticed your package deletes an
> (obsolete) conffile owned another package.
> The chosen approach is wrong since it does not update dpkg's
> database.
> 
> debsums reports modification of the following files,
> from the attached log (scroll to the bottom...):
> 
> 2m6.8s ERROR: FAIL: debsums reports modifications inside the chroot:
>   debsums: missing file /etc/logrotate.d/sssd (from sssd package)
> 
> The correct approach should be (but I didn't test this):
> * drop manual cleanup from sssd-common maintainer scripts
> * add debian/sssd.maintscript containing
> = 8< =
> rm_conffile /etc/logrotate.d/sssd 1.12.5-3~
> = >8 =

I've done that now, thanks. What options did you use, as the piuparts my
sbuild runs didn't show an error like that, instead it complains about
systemd files.


-- 
t

Bug#793588: marked as done (FTBFS: ERROR: dependency ‘foreach’ is not available for package ‘gam’)

[Debian Bug Tracking System]

Your message dated Sat, 5 Sep 2015 00:47:57 -0400
with message-id 

and subject line Fwd: r-cran-gam_1.12-2_amd64.changes ACCEPTED into unstable
has caused the Debian Bug report #793588,
regarding FTBFS: ERROR: dependency ‘foreach’ is not available for package ‘gam’
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
793588: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793588
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: r-cran-gam
Version: 1.12-1
Severity: serious
Tags: sid
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs

Dear Maintainer,

The package fails to build:

dh_installdirs  usr/lib/R/site-library
echo "R:Depends=r-base-core (>= 3.2.1-4), r-api-3" >> 
debian/r-cran-gam.substvars
if test -f /usr/bin/xvfb-run; then  \
MAKEFLAGS="LDFLAGS=-Wl,-z,relro" xvfb-run -a
\
R CMD INSTALL -l 
/r-cran-gam-1.12/debian/r-cran-gam/usr/lib/R/site-library --clean \
 .  \
"--built-timestamp=\"Tue, 14 Jul 2015 20:03:17 
-0400\"" \
;   \
else\
MAKEFLAGS="LDFLAGS=-Wl,-z,relro" R CMD INSTALL -l 
/r-cran-gam-1.12/debian/r-cran-gam/usr/lib/R/site-library \
--clean  .  \
"--built-timestamp=\"Tue, 14 Jul 2015 20:03:17 
-0400\"" \
;   \
fi
ERROR: dependency ‘foreach’ is not available for package ‘gam’
* removing ‘/r-cran-gam-1.12/debian/r-cran-gam/usr/lib/R/site-library/gam’
/usr/share/R/debian/r-cran.mk:98: recipe for target 'R_any_arch' failed


Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/r-cran-gam.html

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.19.0-23-generic (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--- End Message ---
--- Begin Message ---
Version: 1.12-2

Oops, typo in change log.

-- Forwarded message --
From: "Debian FTP Masters" 
Date: Sep 4, 2015 12:34 PM
Subject: r-cran-gam_1.12-2_amd64.changes ACCEPTED into unstable
To: "Chris Lawrence" 
Cc:

>
>
> Accepted:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Fri, 04 Sep 2015 11:58:41 -0400
> Source: r-cran-gam
> Binary: r-cran-gam
> Architecture: source amd64
> Version: 1.12-2
> Distribution: unstable
> Urgency: medium
> Maintainer: Chris Lawrence 
> Changed-By: Chris Lawrence 
> Description:
>  r-cran-gam - Generalized Additive Models for R
> Changes:
>  r-cran-gam (1.12-2) unstable; urgency=medium
>  .
>* Include dependency on r-cran-foreach. (Closes# 793588)
> Checksums-Sha1:
>  a4624e081636f4c3a66c7f657235522c0e0f6d21 1776 r-cran-gam_1.12-2.dsc
>  a7b4455d2591d8b36d4d7f216eea42b3ea606309 2392
r-cran-gam_1.12-2.debian.tar.xz
>  7281e81e114cec842022696b6ea56e29ec62e265 203596
r-cran-gam_1.12-2_amd64.deb
> Checksums-Sha256:
>  f496f8e46db0bb3b5c5e012fc2e4398275e0497383ef909f047ebdca0e410564 1776
r-cran-gam_1.12-2.dsc
>  69dc8fa1e0f9f13a9ba5c4286c8bf65b2327c48d782fba0804d2052152b432ed 2392
r-cran-gam_1.12-2.debian.tar.xz
>  11fbc2ba4be07389f2d733b0ad505e2fc1d215f6347b557a80f46cc9d5d1c0df 203596
r-cran-gam_1.12-2_amd64.deb
> Files:
>  e48482f98c3587b37e86850a33b2d46a 1776 gnu-r optional
r-cran-gam_1.12-2.dsc
>  e76ef2f588bb5627711e3227e6c987d7 2392 gnu-r optional
r-cran-gam_1.12-2.debian.tar.xz
>  06245a44578c65193e5f4768737cc907 203596 gnu-r optional
r-cran-gam_1.12-2_amd64.deb
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBCAAGBQJV6cX4AAoJEMn8Qbj5jGbPxM8P/irZMtznGq3wR7ZtbxLiJPZd
> qw1PASQhR+cAf6EJgveuhki1pkd1yT2YjcK6hYUbG15nJ+5L2CXmrmFq58p/RIkQ
> 2V69HfY0FgU+WuG7Euzg3JtHluEtQUT4+NYVP+utHEzfJt/yD9hkxVkF/HG1HxU4
> 4SgyvFzvdy8Yp9QBwU3pq7Sb1/oQXTOh6tjsEUZDOHNX5JU60ZKukIJ6GpLXQ9ff
> l1WyUT7saUaR1MgA18SOnkT83zm6K22WkYmzsxOd7RP0s2Vl2dLUQ1K8acDnvSu4
> 9ujB0S14KfpHPbRen/NgWbOU2hBm0VfB1/gZQm7aUsABIIfL/qZJs4FesasB7ITu
> 

Bug#796917: marked as done (RM: snappy1.0.3-java -- ROM; obsolete, duplicate)

[Debian Bug Tracking System]

Your message dated Sat, 05 Sep 2015 04:27:54 +
with message-id 
and subject line Bug#796917: Removed package(s) from unstable
has caused the Debian Bug report #796917,
regarding RM: snappy1.0.3-java -- ROM; obsolete, duplicate
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
796917: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796917
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: snappy1.0.3-java
Version: 1.0.3-rc3~dfsg-5
Severity: serious

libsnappy1 is being replaced by libsnappy1v5.  Your arch:all package has
a hardcoded dependency on the former (how does that even work?).

Cheers,
Julien


signature.asc
Description: Digital signature
--- End Message ---
--- Begin Message ---
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

libsnappy1.0.3-java | 1.0.3-rc3~dfsg-5 | all
snappy1.0.3-java | 1.0.3-rc3~dfsg-5 | source

--- Reason ---
ROM; obsolete, duplicate
--

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors until the next
dinstall run at the earliest.

Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.

We try to close bugs which have been reported against this package
automatically. But please check all old bugs, if they were closed
correctly or should have been re-assigned to another package.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 796...@bugs.debian.org.

The full log for this bug can be viewed at https://bugs.debian.org/796917

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)--- End Message ---

Bug#787877: marked as done (clinica: FTBFS with valac 0.28)

[Debian Bug Tracking System]

Your message dated Sat, 05 Sep 2015 04:26:36 +
with message-id 
and subject line Bug#753854: Removed package(s) from unstable
has caused the Debian Bug report #787877,
regarding clinica: FTBFS with valac 0.28
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
787877: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787877
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: clinica
Version: 0.3.0-1
Severity: important
User: pkg-vala-maintain...@lists.alioth.debian.org
Usertags: vala-0.28

Hi,

We plan to make vala 0.28 the default vala compiler soon. It's
currently in the process of being uploaded to experimental.

Your package clinica declares a build dependency on valac.

During a rebuild with this new version, clinica failed to build. The
build logs can be found at
https://people.debian.org/~biebl/buildlogs-vala-0.28/clinica

Please prepare your package to build successfully with vala 0.28.
Once vala 0.28 is uploaded to unstable, this bug will be bumped to
serious.

If you have further questions, please don't hesitate to ask.

Thanks!

Michael, on behalf of the Debian Vala team. 
--- End Message ---
--- Begin Message ---
Version: 0.3.0-1+rm

Dear submitter,

as the package clinica has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/753854

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)--- End Message ---

Bug#753854: marked as done (RM: clinica -- ROM; RC buggy, unmaintained, libgee2 removal)

[Debian Bug Tracking System]

Your message dated Sat, 05 Sep 2015 04:26:30 +
with message-id 
and subject line Bug#753854: Removed package(s) from unstable
has caused the Debian Bug report #753854,
regarding RM: clinica -- ROM; RC buggy, unmaintained, libgee2 removal
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
753854: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753854
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: clinica
Severity: important
User: pkg-vala-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgee-0.6

src:clinica builds a binary which depends on libgee2 (libgee-dev),
which is deprecated in favor of libgee-0.8-2 (libgee-0.8-dev). Please
test your package against the new libgee and update to it.

Thanks, Emilio 
--- End Message ---
--- Begin Message ---
We believe that the bug you reported is now fixed; the following
package(s) have been removed from unstable:

   clinica |0.3.0-1 | source, amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x
clinica-common |0.3.0-1 | all
clinica-dev |0.3.0-1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x
clinica-plugins |0.3.0-1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x
gir1.2-clinica-0.3 |0.3.0-1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x
libclinica0 |0.3.0-1 | amd64, arm64, armel, armhf, hurd-i386, i386, 
kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, ppc64el, s390x

--- Reason ---
ROM; RC buggy, unmaintained, libgee2 removal
--

Note that the package(s) have simply been removed from the tag
database and may (or may not) still be in the pool; this is not a bug.
The package(s) will be physically removed automatically when no suite
references them (and in the case of source, when no binary references
it).  Please also remember that the changes have been done on the
master archive and will not propagate to any mirrors until the next
dinstall run at the earliest.

Packages are usually not removed from testing by hand. Testing tracks
unstable and will automatically remove packages which were removed
from unstable when removing them from testing causes no dependency
problems. The release team can force a removal from testing if it is
really needed, please contact them if this should be the case.

We try to close bugs which have been reported against this package
automatically. But please check all old bugs, if they were closed
correctly or should have been re-assigned to another package.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 753...@bugs.debian.org.

The full log for this bug can be viewed at https://bugs.debian.org/753854

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmas...@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)--- End Message ---

Bug#797855: spice-gtk:spice-common/common/generated_* not reliably generated from source

[Chris Lamb]

Hi Liang,

> Your pbuild have a custom script called D01_modify_environment, Can you
> show me the content ?

Well, you can see a more comprehensive list of variations between the
two build logs I linked here:

 https://reproducible.debian.net/reproducible.html#variation

.. but as previously mentioned that's a distraction I could reproduce
simply by changing from Europe/London to Etc/GMT-14.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#797744: [Debichem-devel] Bug#797744: Bug#797744: gromacs: shared library in a package that is not renamed with its SONAME

[Christoph Junghans]

Hi Nicholas,

if you bump gromacs to 5.1, please add the following patch

to votca-csg-1.2.4

votca-csg-1.3 is on the way, but with the switch from google code to
github things got delayed a little bit.

Thanks,

Christoph


2015-09-04 10:12 GMT-06:00 Nicholas Breen :
> On Wed, Sep 02, 2015 at 09:15:58AM +0100, Simon McVittie wrote:
>> Source: gromacs
>> Version: 5.0.6-1
>> Severity: serious
>> Justification: Policy 8.1
>>
>> The gromacs binary package contains a public shared library
>> (libgromacs.so.0), and votca-csg depends on it.
>>
>> Policy §8.1 says:
>>
>> > The run-time shared library must be placed in a package whose name
>> > changes whenever the SONAME of the shared library changes.
>
> Yeah, that's a leftover from before votca entered the archive, and gromacs 
> fell
> under the "Shared libraries that are internal to a particular package" 
> wording,
> making it exempt from section 8.
>
> I'll see if I can split it for 5.1, but it'll be at least three weeks until I
> can get to working on that.  On the plus side, maybe the C++ transitions will
> have settled down a little by then.
>
>
> --
> Nicholas Breen
> nbr...@debian.org
>
> ___
> Debichem-devel mailing list
> debichem-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debichem-devel



-- 
Christoph Junghans
Web: http://www.compphys.de

Bug#788708: marked as done (iceweasel: GStreamer causes segmentation fault)

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 15:23:22 +
with message-id 
and subject line Bug#788708: fixed in gst-plugins-bad1.0 1.4.5-3
has caused the Debian Bug report #788708,
regarding iceweasel: GStreamer causes segmentation fault
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
788708: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788708
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: iceweasel
Version: 38.0.1-2~bpo70+1
Severity: grave
Justification: renders package unusable

Visiting http://www.babyhalbstark.ch/POPnROLL/SO_KLINGTS.html causes Iceweasel
to crash, printing these messages (when run in gdb):

(iceweasel:746): GStreamer-CRITICAL **: gst_bin_get_by_name: assertion
`GST_IS_BIN (bin)' failed
(iceweasel:746): GStreamer-CRITICAL **: gst_bin_get_by_name: assertion
`GST_IS_BIN (bin)' failed
(iceweasel:746): GLib-GObject-CRITICAL **: g_object_set: assertion `G_IS_OBJECT
(object)' failed
** (iceweasel:746): CRITICAL **: gst_app_sink_set_callbacks: assertion
`GST_IS_APP_SINK (appsink)' failed
** (iceweasel:746): CRITICAL **: gst_app_sink_set_callbacks: assertion
`GST_IS_APP_SINK (appsink)' failed
(iceweasel:746): GStreamer-CRITICAL **: gst_element_get_static_pad: assertion
`GST_IS_ELEMENT (element)' failed
(iceweasel:746): GStreamer-CRITICAL **: gst_pad_add_event_probe_full: assertion
`GST_IS_PAD (pad)' failed
(iceweasel:746): GStreamer-CRITICAL **: gst_pad_set_bufferalloc_function:
assertion `GST_IS_PAD (pad)' failed
Program received signal SIGSEGV, Segmentation fault.
0x7fffc2d62e60 in gst_pad_set_element_private () from /usr/lib/x86_64
-linux-gnu/libgstreamer-0.10.so.0



-- Package-specific info:

-- Extensions information
Name: Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: Dictionary Switcher
Location: ${PROFILE_EXTENSIONS}/dictionary-switc...@design-noir.de
Status: enabled

Name: Element Hiding Helper für Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/elemhidehel...@adblockplus.org
Package: xul-ext-adblock-plus-element-hiding-helper
Status: enabled

Name: Flash Video Downloader
Location: ${PROFILE_EXTENSIONS}/artur.dubo...@gmail.com.xpi
Status: user-disabled

Name: Flashblock
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{3d7eb24f-2740-49df-8937-200b1cc08f8a}
Package: xul-ext-flashblock
Status: app-disabled

Name: Hide Find Bar
Location: ${PROFILE_EXTENSIONS}/hidefind...@jaredmcateer.com.xpi
Status: enabled

Name: Hide Tab Bar With One Tab
Location: ${PROFILE_EXTENSIONS}/{e5bbc237-c99b-4ced-a061-0be27703295f}.xpi
Status: enabled

Name: Quick Translator
Location: ${PROFILE_EXTENSIONS}/{5C655500-E712-41e7-9349-CE462F844B19}.xpi
Status: enabled

Name: Restore Open_External
Location: ${PROFILE_EXTENSIONS}/open_exter...@restored.fn
Status: enabled

Name: Webmail Ad Blocker
Location: ${PROFILE_EXTENSIONS}/gmailno...@mywebber.com
Status: enabled

-- Plugins information
Name: IcedTea-Web Plugin (using IcedTea-Web 1.4 (1.4-3~deb7u2))
Location: /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/IcedTeaPlugin.so
Package: icedtea-6-plugin:amd64
Status: enabled


-- Addons package information
ii  icedtea-6-plug 1.4-3~deb7u2 amd64web browser plugin based on OpenJ
ii  iceweasel  38.0.1-2~bpo amd64Web browser based on Firefox
ii  xul-ext-adbloc 2.1-1+deb7u1 all  Advertisement blocking extension 
ii  xul-ext-adbloc 1.2.2-1  all  extension for Adblock Plus meant 
ii  xul-ext-flashb 1.5.17-1~deb all  Mozilla extension to block Adobe 

-- System Information:
Debian Release: jessie/sid
  APT prefers oldstable
  APT policy: (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages iceweasel depends on:
ii  debianutils   4.3.2
ii  fontconfig2.9.0-7.1
ii  libasound21.0.25-4
ii  libatk1.0-0   2.4.0-2
ii  libc6 2.13-38+deb7u8
ii  libcairo2 1.12.2-3
ii  libdbus-1-3   1.6.8-1+deb7u6
ii  libdbus-glib-1-2  0.100.2-1
ii  libevent-2.0-5

Bug#797227: marked as done (segfault - gst_memory_unmap, libgstreamer)

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 15:23:22 +
with message-id 
and subject line Bug#797227: fixed in gst-plugins-bad1.0 1.4.5-3
has caused the Debian Bug report #797227,
regarding segfault - gst_memory_unmap, libgstreamer
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
797227: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797227
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: iceweasel
Version: 38.2.1esr-1
Severity: grave

The latest iceweasel update causes it to segfault shortly after loading
it.

Tested with safemode in gdb as outlined by reportbug.

Backtrace:

#0  0x7fff9a3a8ff0 in gst_memory_unmap () from /usr/lib/x86_64
-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#1  0x7fff9a37ef76 in gst_buffer_unmap () from /usr/lib/x86_64
-linux-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#2  0x7fff83841294 in ?? () from /usr/lib/x86_64-linux
-gnu/gstreamer-1.0/libgstfaad.so
No symbol table info available.
#3  0x7fff9034be04 in ?? () from /usr/lib/x86_64-linux
-gnu/libgstaudio-1.0.so.0
No symbol table info available.
#4  0x7fff9034f18f in ?? () from /usr/lib/x86_64-linux
-gnu/libgstaudio-1.0.so.0
No symbol table info available.
#5  0x7fff9a3ade1f in ?? () from /usr/lib/x86_64-linux
-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#6  0x7fff99ef2564 in gst_base_parse_push_frame () from
/usr/lib/x86_64-linux-gnu/libgstbase-1.0.so.0
No symbol table info available.
#7  0x7fff99ef3132 in ?? () from /usr/lib/x86_64-linux
-gnu/libgstbase-1.0.so.0
No symbol table info available.
#8  0x7fff9a3ade1f in ?? () from /usr/lib/x86_64-linux
-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#9  0x7fff8feccb4c in ?? () from /usr/lib/x86_64-linux
-gnu/gstreamer-1.0/libgstcoreelements.so
No symbol table info available.
#10 0x7fff9a3dbb61 in ?? () from /usr/lib/x86_64-linux
-gnu/libgstreamer-1.0.so.0
No symbol table info available.
#11 0x7fffee6a92e8 in ?? () from /lib/x86_64-linux-gnu/libglib
-2.0.so.0
No symbol table info available.
#12 0x7fffee6a8955 in ?? () from /lib/x86_64-linux-gnu/libglib
-2.0.so.0
No symbol table info available.
#13 0x77bc70a4 in start_thread (arg=0x7fff86c69700) at
pthread_create.c:309
__res = 
pd = 0x7fff86c69700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735454549760, 
-7064389635352992634, 0, 140737354125408, 140737193347328,
140735454549760, 7064233029594866822, 7064406699172390022},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev
= 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#14 0x7707c07d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.


-- Package-specific info:

-- Extensions information
Name: Default theme
Location: /usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474
-a285-3208198ce6fd}
Package: iceweasel
Status: enabled

Name: English (GB) Language Pack locale
Location: /usr/lib/iceweasel/browser/extensions/langpack-en
-g...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-en-gb
Status: enabled

Name: HTTPS-Everywhere
Location: ${PROFILE_EXTENSIONS}/https-everywhere-...@eff.org
Status: enabled

Name: NoScript
Location: ${PROFILE_EXTENSIONS}/{73a6fe31-595d-460b-a920
-fcc0f8843232}.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4
-b86292ed211d}.xpi
Status: user-disabled

-- Plugins information
Name: Gnome Shell Integration
Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
Package: gnome-shell
Status: enabled

Name: iTunes Application Detector
Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection
-plugin.so
Package: rhythmbox-plugins
Status: disabled


-- Addons package information
ii  gnome-shell3.16.3-1 amd64graphical shell for the
GNOME des
ii  iceweasel  38.2.1esr-1  amd64Web browser based on
Firefox
ii  iceweasel-l10n 1:38.2.1esr- all  English (United Kingdom)
language
ii  rhythmbox-plug 3.2.1-1  amd64plugins for rhythmbox
music playe

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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

Versions 

Bug#766884: libxml2 broken in sid for months already

[Vincent Lefevre]

On 2015-09-04 21:36:53 +0200, Raphael Hertzog wrote:
> On Fri, 04 Sep 2015, Vincent Lefevre wrote:
> > On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> > > On Fri, 04 Sep 2015, Aron Xu wrote:
> > > > I don't want to close it, nor I want make this version to testing, so
> > > > please don't lower the severity, as said above.
> > > 
> > > Why don't you want this version into testing?
> > 
> > I'm not the maintainer, but I think that it is probably cleaner to
> > have testing version = stable version until this bug is fixed (it
> > would be different if testing had already diverged from stable).
> 
> "I think it's cleaner" is a bit light in arguments.
> 
> The stable and testing versions have 3 open security issues.
> The unstable one has none. 

My argument is that:

1. stable must not have security issues, i.e. all security issues
   should be fixed ASAP. AFAIK, security issues in stable are
   generally fixed before unstable.

2. Given (1), if testing version = stable version, it is as easy to
   fix testing.

On the other hand, is it really necessary to have unstable migrate
to testing right now?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Processed: unblock 797992 with 791067

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> unblock 797992 with 791067
Bug #797992 [src:octave] octave: ABI transition needed for libstdc++ v5
797992 was blocked by: 791067
797992 was not blocking any bugs.
Removed blocking bug(s) of 797992: 791067
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
797992: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#766884: Bug#781232: Bug#766884: libxml2 broken in sid for months already

[Aron Xu]

On Saturday, September 5, 2015, Raphael Hertzog  wrote:

> Hi,
>
> On Fri, 04 Sep 2015, Vincent Lefevre wrote:
> > On 2015-09-04 13:59:02 +0200, Raphael Hertzog wrote:
> > > On Fri, 04 Sep 2015, Aron Xu wrote:
> > > > I don't want to close it, nor I want make this version to testing, so
> > > > please don't lower the severity, as said above.
> > >
> > > Why don't you want this version into testing?
> >
> > I'm not the maintainer, but I think that it is probably cleaner to
> > have testing version = stable version until this bug is fixed (it
> > would be different if testing had already diverged from stable).
>
> "I think it's cleaner" is a bit light in arguments.
>
> The stable and testing versions have 3 open security issues.
> The unstable one has none.
>
> https://security-tracker.debian.org/tracker/source-package/libxml2
>
>
Then please help fix stable instead of rushing in unstable.

Cheers,
Aron


>

Bug#797992: [pkg-octave/master] Rename liboctave3 to liboctave3v5 for g++-5 transition.

[Sébastien Villemot]

tag 797992 pending
thanks

Date: Sat Sep 5 00:00:59 2015 +0200
Author: Sébastien Villemot 
Commit ID: a54064f8b00b0f2a49271bc8f89f7e3ee13549c2
Commit URL: 
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff;h=a54064f8b00b0f2a49271bc8f89f7e3ee13549c2
Patch URL: 
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff_plain;h=a54064f8b00b0f2a49271bc8f89f7e3ee13549c2

Rename liboctave3 to liboctave3v5 for g++-5 transition.

Closes: #797992
  

Processed: [pkg-octave/master] Rename liboctave3 to liboctave3v5 for g++-5 transition.

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 797992 pending
Bug #797992 [src:octave] octave: ABI transition needed for libstdc++ v5
Added tag(s) pending.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
797992: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797992
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#798059: turbojson: FTBFS: ImportError: from peak.rules import abstract, around, when

[Chris West (Faux)]

Source: turbojson
Version: 1.3.2-2.1
Severity: serious
Justification: fails to build from source
Tags: sid
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

The package fails to build:

...

Get:34 http://urika:3142/ftp.debian.org/debian/ sid/main python-nose all 
1.3.6-1 [132 kB]
Get:35 http://urika:3142/ftp.debian.org/debian/ sid/main 
python-peak.util.decorators all 1.8-3 [22.9 kB]
Get:36 http://urika:3142/ftp.debian.org/debian/ sid/main python-peak.util all 
20110909-1 [69.1 kB]
Get:37 http://urika:3142/ftp.debian.org/debian/ sid/main python-peak.rules all 
0.5a1+r2707-1 [116 kB]
Get:38 http://urika:3142/ftp.debian.org/debian/ sid/main python-pysqlite2 amd64 
2.7.0-1 [35.0 kB]

...

==
ERROR: Failure: ImportError (No module named rules)
--
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/nose/loader.py", line 420, in 
loadTestsFromName
addr.filename, addr.module)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 47, in 
importFromPath
return self.importFromDir(dir_path, fqname)
  File "/usr/lib/python2.7/dist-packages/nose/importer.py", line 94, in 
importFromDir
mod = load_module(part_fqname, fh, filename, desc)
  File "/turbojson-1.3.2/turbojson/__init__.py", line 3, in 
from turbojson.jsonsupport import JsonSupport
  File "/turbojson-1.3.2/turbojson/jsonsupport.py", line 3, in 
from turbojson.jsonify import GenericJSON
  File "/turbojson-1.3.2/turbojson/jsonify.py", line 6, in 
from peak.rules import abstract, around, when
ImportError: No module named rules

--
Ran 1 test in 0.006s

FAILED (errors=1)
debian/rules:8: recipe for target 'override_dh_auto_test' failed

-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Bug#798058: neo: FTBFS: TestPyNNNumpyIO_Signals: Files have different sizes

[Chris West (Faux)]

Source: neo
Version: 0.3.3-1
Severity: serious
Justification: fails to build from source
Tags: sid stretch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

The package fails to build:

==
FAIL: test_write_segment (neo.test.iotest.test_pynnio.TestPyNNNumpyIO_Signals)
--
Traceback (most recent call last):
  File "/neo-0.3.3/neo/test/iotest/test_pynnio.py", line 60, in 
test_write_segment
assert_file_contents_equal(self.test_file, write_test_file)
  File "/neo-0.3.3/neo/test/tools.py", line 77, in assert_file_contents_equal
assert file_digest(a) == file_digest(b), generate_error_message(a, b)
AssertionError: Files have different sizes: a:8674 b: 9094

FAILED (SKIP=170, failures=1)

Full build log:
https://reproducible.debian.net/rb-pkg/unstable/amd64/neo.html

-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Processed: found 797233 in libroar-dev/1.0~beta11-4

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 797233 libroar-dev/1.0~beta11-4
Bug #797233 {Done: Patrick Matthäi } [libroar-dev] 
libsndio-dev and libroar-dev: error when trying to install together
The source libroar-dev and version 1.0~beta11-4 do not appear to match any 
binary packages
Marked as found in versions libroar-dev/1.0~beta11-4 and reopened.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
797233: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797233
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797233: libsndio-dev and libroar-dev: error when trying to install together

[Ralf Treinen]

Sorry, this isn't fixed yet, there also is a file conflict on libsndio.so:

Selecting previously unselected package libroar-dev.
Preparing to unpack .../libroar-dev_1.0~beta11-4_amd64.deb ...
Unpacking libroar-dev (1.0~beta11-4) ...
Selecting previously unselected package libsndio6.0:amd64.
Preparing to unpack .../libsndio6.0_0.0.10-1_amd64.deb ...
Unpacking libsndio6.0:amd64 (0.0.10-1) ...
Selecting previously unselected package libsndio-dev:amd64.
Preparing to unpack .../libsndio-dev_0.0.10-1_amd64.deb ...
Unpacking libsndio-dev:amd64 (0.0.10-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libsndio-dev_0.0.10-1_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libsndio.so', which is also in 
package libroar-dev 1.0~beta11-4
Processing triggers for man-db (2.7.2-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/libsndio-dev_0.0.10-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/x86_64-linux-gnu/libsndio.so

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.
MAILEND

Bug#794852: codeblocks: non DFSG file in the source package

[Vincent Cheng]

Pinging this bug to delay autoremoval from testing; codeblocks is
already fixed in unstable, but testing migration is delayed due to
gcc-5 transition.

Regards,
Vincent

Bug#797981: magics++: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: magics++
Version: 2.24.7-5
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of magigs++, std::string appears in functions that are
explicitly exported, so it seems very likely that a transition is needed.
The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libmagplus3v5).
The SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. Please avoid doing this unless the new upstream version
is very low-risk.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of magics++:

* hdf5 is a C++ library, but magics++ does not appear to use the C++ part
  libhdf5-cpp-8 so that can perhaps be ignored
* netcdf has already been renamed
* libterralib has already been renamed
* boost has already been renamed via the 1.55 -> 1.58 transition
* Qt does not need renaming

so I think magics++ is ready to start its sub-transition in unstable.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Bug#797983: mathic: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: mathic
Version: 1.0~git20130827-2
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of mathic, std::string appears in functions in public
headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libmathic0v5).
The SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. Please avoid doing this unless the new upstream version
is very low-risk.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of mathic, the C++ libraries
are gtest, which is header-only, and memtailor, which does not appear
to need a transition. So this sub-transition is ready to start.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Bug#796456: mina2: FTBFS: AprLibrary.java: error: unreported exception Throwable

[Emmanuel Bourg]

control: tags -1 pending

I'm preparing an update to the version 2.0.9 that will solve this issue.

Processed: Re: Bug#796456: mina2: FTBFS: AprLibrary.java: error: unreported exception Throwable

[Debian Bug Tracking System]

Processing control commands:

> tags -1 pending
Bug #796456 [src:mina2] mina2: FTBFS: AprLibrary.java: error: unreported 
exception Throwable
Added tag(s) pending.

-- 
796456: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796456
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797936: libsimgearscene3.4.0: Fixed

[Lucio Crusca]

Package: libsimgearscene3.4.0
Followup-For: Bug #797936

Fixed in latest update. Thanks.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (998, 'unstable'), (994, 'testing'), (990, 'stable'), (500, 
'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libsimgearscene3.4.0 depends on:
ii  libc6 2.19-19
ii  libexpat1 2.1.0-7
ii  libgcc1   1:5.2.1-16
ii  libgl1-mesa-glx [libgl1]  10.6.5-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libopenal11:1.16.0-3
ii  libopenscenegraph100v53.2.1-7
ii  libopenthreads20  3.2.1-7
ii  libsimgearcore3.4.0   3.4.0-2+b1
ii  libstdc++65.2.1-16
ii  zlib1g1:1.2.8.dfsg-2+b1

libsimgearscene3.4.0 recommends no packages.

libsimgearscene3.4.0 suggests no packages.

-- no debconf information

Bug#797936: marked as done (flightgear: Crash on startup: symbol lookup error)

[Debian Bug Tracking System]

Your message dated Fri, 04 Sep 2015 07:55:13 +0100
with message-id <55e94051.8040...@zoho.com>
and subject line Re: [pkg-fgfs-crew] Bug#797936: libsimgearscene3.4.0: Fixed
has caused the Debian Bug report #797936,
regarding flightgear: Crash on startup: symbol lookup error
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
797936: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797936
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: flightgear
Version: 3.4.0-1
Severity: important

Flightgear does not launch.

$ fgo

Avvio di /usr/games/fgfs con le opzioni seguenti:
--atlas=socket,out,5,localhost,5501,udp
--aircraft=Cub
--airport=LIMC
--fg-root=/usr/share/games/flightgear
--fg-scenery=/home/lucio/flightgear/Scenery



/usr/games/fgfs: symbol lookup error: 
/usr/lib/x86_64-linux-gnu/libSimGearScene.so.3.4.0: undefined symbol: 
_ZN5osgDB16ReadFileCallback11openArchiveERKSsNS_12ReaderWriter13ArchiveStatusEjPKNS_7OptionsE

$ fgrun
fgrun: symbol lookup error: /usr/lib/x86_64-linux-gnu/libSimGearScene.so.3.4.0: 
undefined symbol: 
_ZN5osgDB16ReadFileCallback11openArchiveERKSsNS_12ReaderWriter13ArchiveStatusEjPKNS_7OptionsE

$ fgfs
fgfs: symbol lookup error: /usr/lib/x86_64-linux-gnu/libSimGearScene.so.3.4.0: 
undefined symbol: 
_ZN5osgDB16ReadFileCallback11openArchiveERKSsNS_12ReaderWriter13ArchiveStatusEjPKNS_7OptionsE


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (998, 'unstable'), (994, 'testing'), (990, 'stable'), (500, 
'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages flightgear depends on:
ii  flightgear-data-all   3.4.0+dfsg-1
ii  freeglut3 2.8.1-2
ii  libc6 2.19-19
ii  libdbus-1-3   1.8.20-1
ii  libflite1 1.4-release-12
ii  libgcc1   1:5.2.1-15
ii  libgl1-mesa-glx [libgl1]  10.6.5-1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgsm1   1.0.13-4
ii  libhtsengine1 1.08-1
ii  libice6   2:1.0.9-1+b1
ii  libopenal11:1.16.0-3
ii  libopenscenegraph100  3.2.1-6+b3
ii  libopenthreads20  3.2.1-7
ii  libplib1  1.8.5-7
ii  libpng12-01.2.50-2+b2
ii  libsimgearcore3.4.0   3.4.0-2
ii  libsimgearscene3.4.0  3.4.0-2
ii  libsm62:1.2.2-1+b1
ii  libspeex1 1.2~rc1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libsqlite3-0  3.8.11.1-1
ii  libstdc++65.2.1-15
ii  libudev1  225-1
ii  libx11-6  2:1.6.3-1
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.4-1+b2
ii  libxmu6   2:1.1.2-1
ii  zlib1g1:1.2.8.dfsg-2+b1

flightgear recommends no packages.

flightgear suggests no packages.

-- no debconf information
--- End Message ---
--- Begin Message ---

Version: 3.4.0-2+b1

We didn't do anything, but someone recompiled simgear+flightgear (hence 
the +b1 suffix), so it evidently was a gcc5 transition issue.--- End Message ---

Bug#797976: spice: CVE-2015-3247: memory corruption in worker_update_monitors_config()

[Salvatore Bonaccorso]

Source: spice
Version: 0.12.5-1
Severity: grave
Tags: security patch upstream

Hi,

the following vulnerability was published for spice.

CVE-2015-3247[0]:
memory corruption in worker_update_monitors_config()

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-3247
[1] 
https://git.centos.org/blob/rpms!spice.git/11e32f6dd156a3c4847da29d989837437e973ccc/SOURCES!0038-Avoid-race-conditions-reading-monitor-configs-from-g.patch

Regards,
Salvatore

Bug#797978: [Reproducible-builds] All Recommends of diffoscope lost with upload of version 32?

[Mattia Rizzolo]

Package: diffoscope
Version: 32
Severity: serious
Control: submitter -1 Axel Beckert 
x-debbugs-cc: Axel Beckert 

On Fri, Sep 04, 2015 at 08:42:43AM +0200, Axel Beckert wrote:
> it seems that the Recommends of diffoscope are generated dynamically
> and all lost with the upload of version 32. Is this on purpose? If
> not, feel free to open a bug report in my name with this mail.

Pretty sure it is not.

Also, setting as sev:serious since this breaks our CI (everything will
be binary diffed!), etc.

Thanks for reporting!

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: Digital signature

Processed: Re: [Reproducible-builds] All Recommends of diffoscope lost with upload of version 32?

[Debian Bug Tracking System]

Processing control commands:

> submitter -1 Axel Beckert 
Bug #797978 [diffoscope] [Reproducible-builds] All Recommends of diffoscope 
lost with upload of version 32?
Changed Bug submitter to 'Axel Beckert ' from 'Mattia Rizzolo 
'

-- 
797978: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797978
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#797984: nordugrid-arc: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: nordugrid-arc
Version: 5.0.2-1
Severity: serious
Justification: breaks ABI without a package rename
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of nordugrid-arc, std::string appears in functions in
installed headers, so it seems very likely that a transition is needed.
The transition normally consists of renaming the affected library
packages, adding a v5 suffix.  The SONAME should not be changed when
doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, please avoid doing this unless the new upstream version
is extremely low-risk: this transition has been going on for 1 month
already, and anything that drags it out further is bad for Debian.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the C++ library build-dependencies of nordugrid-arc:

* glibmm, cppunit and canl-c++ have already been renamed
* libdb++ is not believed to need a transition

so I think nordugrid-arc is ready to start its transition now.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Processed: Re: Bug#791283: siscone: library transition may be needed when GCC 5 is the default

[Debian Bug Tracking System]

Processing control commands:

> reopen 791283
Bug #791283 {Done: Mehdi Dogguy } [src:siscone] siscone: 
library transition may be needed when GCC 5 is the default
Bug reopened
Ignoring request to alter fixed versions of bug #791283 to the same values 
previously set

-- 
791283: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791283
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#791283: siscone: library transition may be needed when GCC 5 is the default

[Simon McVittie]

Control: reopen 791283

On Thu, 13 Aug 2015 at 00:55:11 +, Mehdi Dogguy wrote:
> In fact, it has no reverse dependencies. So the renaming is not required.

siscone does have a reverse dependency in unstable, namely fastjet
(which needs a transition of its own; it makes rivet FTBFS).

Regards,
S

Bug#797966: syncevolution-common: uninstallable due to libsynthesis0 dependency

[Tino Mettler]

On Fri, Sep 04, 2015 at 03:04:20 +0200, gregor herrmann wrote:
> Package: syncevolution-common
> Version: 1.4.99.4-3
> Severity: serious
> 
> syncevolution-common is uninstallable in sid due to the hardcoded
> dependency on libsynthesis0; and libsynthesis0 is gone as it got
> renamed to libsynthesis0v5 in the ongoing libdstdc++6 transition.
> 
> Cheers,
> gregor

Hi Gregor,

thanks for your notice. I'll try to submit a fixed syncevolution
package to my sponsor within the next few days.

Regards,
Tino



signature.asc
Description: Digital signature

Bug#797989: fastjet: ABI transition needed for libstdc++ v5

[Simon McVittie]

Source: fastjet
Version: 3.0.6+dfsg-1
Severity: serious
Justification: causes rivet to FTBFS
Tags: sid stretch confirmed
User: debian-...@lists.debian.org
Usertags: libstdc++-cxx11
Control: block -1 by 791283

Background[1]: libstdc++6 introduces a new ABI to conform to the
C++11 standard, but keeps the old ABI to not break existing binaries.
Packages which are built with g++-5 from experimental (not the one
from testing/unstable) are using the new ABI.  Libraries built from
this source package export some of the new __cxx11 or B5cxx11 symbols,
dropping other symbols.  If these symbols are part of the API of
the library, then this rebuild with g++-5 will trigger a transition
for the library.

In the case of fastjet, the rivet source package FTBFS when built
against a version of yaml-cpp that starts *its* transition,
so I can confirm that a transition is definitely needed.
The transition normally consists of renaming the
affected library packages, adding a v5 suffix (libfastjet0v5, etc.).
The SONAME should not be changed when doing this.

If an upgrade to a new upstream SONAME is already planned, and that
SONAME has never been available in Debian compiled with g++-4, then an
alternative way to carry out the transition would be to bump the
SONAME. However, the libstdc++ transition has been going on for a
month already, and anything that makes it take longer is bad for Debian,
so introducing new upstream code is not desired at this stage.

These follow-up transitions for libstdc++ are not going through exactly
the normal transition procedure, because many entangled transitions are
going on at the same time, and the usual ordered transition procedure
does not scale that far. When all the C++ libraries on which this library
depends have started their transitions in unstable if required, this
library should do the same, closing this bug; the release team will deal
with binNMUs as needed.

Looking at the build-dependencies of fastjet, siscone needs a
library transition first; in fastjet, please add versioned Build-Depends
on the version of siscone where #791283 has been fixed.

The package might be NMU'd if there is no maintainer response. The
release team have declared a 2 day NMU delay[2] for packages involved
in the libstdc++ transition, in order to get unstable back to a usable
state in a finite time.

Regards,
S

[1] https://wiki.debian.org/GCC5#libstdc.2B-.2B-_ABI_transition
[2] https://lists.debian.org/debian-devel-announce/2015/08/msg0.html

Processed: fastjet: ABI transition needed for libstdc++ v5

[Debian Bug Tracking System]

Processing control commands:

> block -1 by 791283
Bug #797989 [src:fastjet] fastjet: ABI transition needed for libstdc++ v5
797989 was not blocked by any bugs.
797989 was not blocking any bugs.
Added blocking bug(s) of 797989: 791283

-- 
797989: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797989
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Please enable module xdebug

[Debian Bug Tracking System]

Processing control commands:

> block 796408 by -1
Bug #796408 [src:php-codecoverage] php-codecoverage: FTBFS: 
PHP_CodeCoverage_Exception: No code coverage driver available
796408 was not blocked by any bugs.
796408 was not blocking any bugs.
Added blocking bug(s) of 796408: 797991
> affects -1 php-codecoverage
Bug #797991 [php5-xdebug] Please enable module xdebug
Added indication that 797991 affects php-codecoverage

-- 
796408: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796408
797991: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797991
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems