Bug#843018: ITP: node-braces -- Fast, comprehensive, bash-like brace expansion implemented in JavaScript

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-braces
  Version : 2.0.2
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/braces
* License : Expat
  Programming Lang: JavaScript
  Description : Fast, comprehensive, bash-like brace expansion
implemented in JavaScript. Complete support for the Bash 4.3 braces
specification, without sacrificing speed.

Bug#843017: add support for npm dist tarballs

[Paul Wise]

Control: retitle -1 fakeupstream: npmjs broken since switch from http to https
Control: user qa.debian@packages.debian.org
Control: usertags -1 fakeupstream

On Thu, 3 Nov 2016 12:20:30 +0530 Pirate Praveen wrote:

> Most npm modules tag their github repos, but many does not have tags.
> When an npm module's github repo is missing tags, npm2deb creates a
> watch file pointing to http://qa.debian.org/cgi-bin/fakeupstream.cgi

This is already supported but it appears to be broken since they
switched from http to https. I'll commit and deploy the fix.

https://anonscm.debian.org/viewvc/qa/trunk/cgi-bin/fakeupstream.cgi?view=markup#l369

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#828440: moonshot-gss-eap: FTBFS with openssl 1.1.0

[Sebastian Andrzej Siewior]

On 2016-11-01 17:41:27 [-0400], Sam Hartman wrote:
> Hi.
Hi,

> I'm sorry I didn't get a chance to respond to your other mail.
> upstream has dealt with moonshot-gss-eap and moonshot-ui and I plan to
> address the bugs there with a new upstream version.

You could point that out in the relevant bug report before someone
spends time trying to help you. It sounded like nobody has time for this
and now I learn that upstream already fixed it.

Sebastian

Bug#843019: ITP: node-expand-brackets -- Expand POSIX bracket expressions (character classes) in glob patterns

[Sruthi Chandran]

Package: wnpp
Severity: wishlist
Owner: Sruthi Chandran 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-expand-brackets
  Version : 2.1.3
  Upstream Author : Jon Schlinkert (https://github.com/jonschlinkert)
* URL : https://github.com/jonschlinkert/expand-brackets
* License : Expat
  Programming Lang: JavaScript
  Description : Expand POSIX bracket expressions (character classes)
in glob patterns

Bug#843020: frama-c: FTBFS with ocaml 4.03

[Ralf Treinen]

Source: frama-c
Version: 20151002+magnesium+dfsg-1
Severity: important

Hi.

frama-c magnesium fails to build with ocaml 4.03, which should be
uploaded to sid very soon:

File "src/plugins/wp/wpo.ml", line 1:
Error: The implementation src/plugins/wp/wpo.ml
   does not match the interface src/plugins/wp/wpo.cmi:
   ...
   In module Gmap:
   The value `union' is required but not provided
share/Makefile.generic:77: recipe for target 'src/plugins/wp/wpo.cmo' failed
make[1]: *** [src/plugins/wp/wpo.cmo] Error 2

Note that upstream has released a new version Aluminium-20160501,
which might solve the problem (I haven't checked, yet).

-Ralf.

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Paolo Greppi]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org

--- Please fill out the fields below. ---

   Package name: yarn
Version: 0.16.1
Upstream Author: Yarn Developers 
URL: https://github.com/yarnpkg/yarn
License: BSD-2-Clause
Description: Fast, reliable, and secure alternative for the npm
client, compatible with the npm registry.
.
Fast: Yarn caches every package it downloads so it never needs to again.
It also parallelizes operations to maximize resource utilization so
install times are faster than ever.
.
Reliable: Using a detailed, but concise, lockfile format, and a
deterministic algorithm for installs, Yarn is able to guarantee that an
install that worked on one system will work exactly the same way on any
other system.
.
Secure: Yarn uses checksums to verify the integrity of every installed
package before its code is executed.



signature.asc
Description: OpenPGP digital signature

Bug#842015: [pkg-gnupg-maint] Bug#842015: Bug#842015: Similar issue, no emacs

[Werner Koch]

On Thu,  3 Nov 2016 04:52, d...@fifthhorseman.net said:

> a bit of background:

Thanks for that good summary.

>  * pinentry-gnome3: d-bus, fallback to terminal if d-bus connectivity
>fails (this is actually somehow mixed at the moment; it's not clear
>whether pinentry should fall back to the terminal only if
>$DBUS_SESSION_BUS_ADDRESS is unset, or whether it should *also*
>fallback to the terminal if the prompting agent itself is
>unavailable; i lean toward the latter, but Werner has declined a
>patch that makes that happen)

I rejected the patch due to the way it worked.  A patch working similar
to the tty fallback would be okay.  Something like this:

--8<---cut here---start->8---
diff --git a/gnome3/pinentry-gnome3.c b/gnome3/pinentry-gnome3.c
index d6d7d16..e79e852 100644
--- a/gnome3/pinentry-gnome3.c
+++ b/gnome3/pinentry-gnome3.c
@@ -270,6 +270,11 @@ main (int argc, char *argv[])
" falling back to curses\n");
   pinentry_cmd_handler = curses_cmd_handler;
 }
+  else if (is_gcr_installed ())
+{
+  fprintf (stderr, "No GCR found, falling back to curses\n");
+  pinentry_cmd_handler = curses_cmd_handler;
+}
 #endif
--8<---cut here---end--->8---

I do not know how to test for GCR availability, though.


Shalom-Salam,

   Werner

> Of course, regular users shouldn't have to know about any of this, i'm
> just trying to clarify the inter-process communications for people who
> want to help resolve the issue.  Is this analysis missing anything?

I would like to implement a method to make it easier to show the problem
to the user.  For me it is easy to debug becuase I know how to use
watchgnupg but users only see the output of gpg (if at all) and not the
gpg-agent logs. 

This could be implemented by extending the PINENTRY_LAUNCHED
notification we already use between gpg and gpg-agent to print a
diagnostic and a status line with the type of the pinentry in use and a
couple of flags:

  [GNUPG:] PINENTRY_LAUNCHED 

 would be gtk/gnome/qt and flags can be used to indicate the
chosen fallback.  Requires some additions to the pinentry, though.

Would this be helpful?


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpJBtIIrf3hD.pgp
Description: PGP signature

Bug#843021: additional info

[Paolo Greppi]

Original announcement for yarn (2016-10-11):
https://code.facebook.com/posts/1840075619545360

Upstream provides a .deb package compatible with testing's nodejs package:
http://dl.yarnpkg.com/debian/pool/main/y/yarn/yarn_0.16.1-1_all.deb

There is a separate github repo for packaging:
https://github.com/yarnpkg/releases/tree/gh-pages/debian



signature.asc
Description: OpenPGP digital signature

Bug#843022: ITP: emperor -- new version

[Kerim Ölçer]

Subject: ITP: emperor -- new version
Package: wnpp
Owner: "Kerim ÖLÇER" 
Severity: wishlist

* Package name: emperor
  Version : 1.0.0beta5
  Upstream Author : Vazquez-Baeza Y, Pirrung M, Gonzalez A, Knight R.
* URL : https://github.com/biocore/emperor
* License : (MIT)
  Programming Lang: (Python, Javascript, etc.)
  Description : Emperor is a next-generation tool for the analysis and
visualization of large microbial ecology datasets; amongst many features
Emperor provides a modern user interface that will rapidly adjust to your
daily workflow.

Bug#772835: node-async: let's get it up to speed

[Julien Puydt]

Hi,

I'm part of the Debian Javascript Maintainers team, and I'm willing to 
help on this team-maintained package :

- closing bug #772835 after almost two years ;
- updating to latest upstream ;
- updating to latest Debian packaging standards.

If there is no objection, I'll start working on this in a week.

Cheers,

Snark on #debian-js

Bug#802710: musescore: Embeds Qt5's private headers without putting them in a namespace

[Antonio Ospite]

Package: musescore
Version: 2.0.3+dfsg1-2
Followup-For: Bug #802710

Dear Maintainer,

on my system musescore is blocking the update to the latest Qt5 packages
in unstable as it depends on qtbase-abi-5-6-1.

Is this bug the cause of it?

Thanks,
   Antonio

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

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

Versions of packages musescore depends on:
ii  desktop-file-utils   0.23-1
ii  libasound2   1.1.2-1
ii  libc62.24-5
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.2.0-10
ii  libportaudio219+svn20140130-1.1
ii  libpulse09.0-4
ii  libqt5core5a [qtbase-abi-5-6-1]  5.6.1+dfsg-3+b1
ii  libqt5gui5   5.6.1+dfsg-3+b1
ii  libqt5help5  5.6.1-4
ii  libqt5network5   5.6.1+dfsg-3+b1
ii  libqt5printsupport5  5.6.1+dfsg-3+b1
ii  libqt5qml5   5.6.1-11
ii  libqt5quick5 5.6.1-11
ii  libqt5sql5-sqlite5.6.1+dfsg-3+b1
ii  libqt5svg5   5.6.1-2
ii  libqt5webkit55.6.1+dfsg-5
ii  libqt5widgets5   5.6.1+dfsg-3+b1
ii  libqt5xml5   5.6.1+dfsg-3+b1
ii  libqt5xmlpatterns5   5.6.1-2
ii  libsndfile1  1.0.27-1
ii  libstdc++6   6.2.0-10
ii  libvorbisfile3   1.3.5-3
ii  musescore-common 2.0.3+dfsg1-2
ii  qml-module-qtquick-controls  5.6.1-3
ii  qml-module-qtquick-dialogs   5.6.1-3
ii  qml-module-qtquick-layouts   5.6.1-3
ii  qml-module-qtquick2  5.6.1-11
ii  shared-mime-info 1.7-1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-2+b3

Versions of packages musescore recommends:
ii  pulseaudio-utils  9.0-4

Versions of packages musescore suggests:
ii  fluid-soundfont-gm  3.1-5
pn  timgm6mb-soundfont  

-- no debconf information
-- 
Antonio Ospite
https://ao2.it
https://twitter.com/ao2it

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?

Bug#842987: redis: CVE-2016-2121: weak permissions on sensitive files

[Guido Günther]

Hi Salvatore,
On Wed, Nov 02, 2016 at 08:53:40PM +0100, Salvatore Bonaccorso wrote:
> Source: redis
> Version: 2:2.8.17-1
> Severity: important
> Tags: security
> 
> Hi
> 
> See
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1390588
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=1374700
> 
> This partially seems to hold as well for Debian, at least for the
> /var/lib/redis part for unstable. For jessie it looks e.g.
> /etc/resis/redis.conf and otherwould be world-readable as well.

I just checked wheezy

* /etc/redis/redis.conf: while it is world readable it does not contain
  a password by default. It would be better to have sane permissions by
  default on that file but we don't leak anything until somebody sets a
  password.

* /var/lib/redis: the directory is world readable but files in it are not:
rw-rw 1 redis redis 80100 Nov 3 08:56 /var/lib/redis/dump.rdb so
  they're protected by umask. Again I think it would be better to have
  tighter permissions but nothing is leaked by default (assuming this
  holds for all files created by redis in that dir).

So I decided to mark this no-dsa in wheezy. Please let me know if you
guys don't think that's appropriate.
Cheers,
 -- Guido

Bug#255572: ITP: cc65 -- Cross development suite for 65xxx processors, necesary for nesicide env

[Michael Stapelberg]

Hi László,

"László Böszörményi (GCS)"  writes:
> [1] https://ftp-master.debian.org/new/cc65_0~20160105-1.html

Thanks for your upload. Can you tell us what happened with it?
https://packages.debian.org/search?keywords=cc65&searchon=names&suite=all§ion=all
yields no results, so I’m assuming the upload was rejected…? On what
grounds, and what can we do to help (if anything)?

-- 
Best regards,
Michael

Bug#842987: redis: CVE-2016-2121: weak permissions on sensitive files

[Salvatore Bonaccorso]

Hi Guido,

On Thu, Nov 03, 2016 at 09:05:41AM +0100, Guido Günther wrote:
> Hi Salvatore,
> On Wed, Nov 02, 2016 at 08:53:40PM +0100, Salvatore Bonaccorso wrote:
> > Source: redis
> > Version: 2:2.8.17-1
> > Severity: important
> > Tags: security
> > 
> > Hi
> > 
> > See
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1390588
> > and
> > https://bugzilla.redhat.com/show_bug.cgi?id=1374700
> > 
> > This partially seems to hold as well for Debian, at least for the
> > /var/lib/redis part for unstable. For jessie it looks e.g.
> > /etc/resis/redis.conf and otherwould be world-readable as well.
> 
> I just checked wheezy
> 
> * /etc/redis/redis.conf: while it is world readable it does not contain
>   a password by default. It would be better to have sane permissions by
>   default on that file but we don't leak anything until somebody sets a
>   password.
> 
> * /var/lib/redis: the directory is world readable but files in it are not:
> rw-rw 1 redis redis 80100 Nov 3 08:56 /var/lib/redis/dump.rdb so
>   they're protected by umask. Again I think it would be better to have
>   tighter permissions but nothing is leaked by default (assuming this
>   holds for all files created by redis in that dir).
> 
> So I decided to mark this no-dsa in wheezy. Please let me know if you
> guys don't think that's appropriate.

Thanks for the analysis! Agreed, and think we will follow the same for
jessie as well.

Regards,
Salvatore

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Lars Wirzenius]

On Thu, Nov 03, 2016 at 08:36:21AM +0100, Paolo Greppi wrote:
>Package name: yarn
> URL: https://github.com/yarnpkg/yarn

My cmdtest package provides yarn, since the main tool it now provides
is yarn (a testing tool), not cmdtest. Perhaps your package could be
called yarnpkg?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#828240: asterisk: FTBFS with openssl 1.1.0

[Bernhard Schmidt]

Control: tags -1 help

Hi,

current state on this:

- There is no progress visible in the upstream bugtracker, I have also
  not found anything in other distros (Fedora etc.)

- switching to libssl1.0-dev does not work for now because the
  build-deps

libc-client2007e-dev
libpjproject-dev
libsnmp-dev

  depend on the conflicting libssl-dev. 

  libpjproject has already switched to libssl1.0-dev, so the dependency
  looks like a bug in d-devlibdeps. That could be easily overridden.

  libc-client2007e-dev has an open FTBFS against OpenSSL 1.1.0 anyway,
  but there is a patch in the BTS.

  Maybe one could just drop the libssl-dev dependency from
  libc-client2007e-dev and libsnmp-dev, as done for libpq-dev?

- Asterisk is doing some weird stuff with macros in
  
https://sources.debian.net/src/asterisk/1:13.11.2~dfsg-1/main/libasteriskssl.c/
  that causes the build against 1.1.0 to fail. This is beyond my C
  knowledge. I will gladly test and accept any patch for that.

Best Regards,
Bernhard


signature.asc
Description: Digital signature

Bug#841294: Overrule maintainer of "global" to package a new upstream version

[Philip Hands]

Ron  writes:

> Hi Marga,
>
> On Tue, Nov 01, 2016 at 11:32:49AM +0100, Margarita Manterola wrote:
>> > Philip Hands  writes:
>> > It seems like you are tempted to drop htags anyway now, so calling the
>> > version 6 package 'global' and adding the global5 package to give people
>> > an escape route seems like the right thing to do.
>> > 
>> > That also makes it much easier to detect when people cling to version 5,
>> > since there will only be intentional installations of that package.
>> 
>> I second this proposal by Phil.  It seems to me that this is the most 
>> reasonable
>> outcome, given the current situation. This means that global gets updated to 
>> the
>> latest version, with a NEWS message stating that htags functionality has been
>> removed and that users that care about htags should install global5 instead.
>> 
>> Ron, you haven't replied to this proposal yet. Can you state your opinion
>> regarding this?
>
> Did I mess up on the CC for that somehow?  Or was there something I
> didn't address about the question(s) of going this way in:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841294#135
>
> I can try to clarify that if there's a question in your mind that
> you don't think I touched on there.

The question that remains is what you actually intend to do.

You went into some detail about why the existing popcon figures should
not be relied upon, which is fair enough but seems not to take account
of the fact that my suggestion was for you to create a new global5
package which would not be automatically pulled in by anything (unless
the maintainers of reverse dependencies decide that it's better to
switch to depending upon global5, which should probably be
strongly discouraged).

The popcon figures for global would then still be contaminated with
whatever dragged it in in the first place, but the figures for global5
would tell you the extent to which the userbase of the global5-only
features actually exists.

Either there are real users for those features, which might persuade you
that the effort of backporting features to global5 is justified -- in
that case the exit strategy would be for the patched global5 to be the
final inheritor of the 'global' package (in stretch+1 say, replacing
the v6 package once you have the relevant feature parity).

Alternatively, if very few people install global5, you can publish an
update that reminds people that the package is going away, and asking
them to tell you why they might be upset about that, and then you either
get useful feedback, or you can remove the package with a clear
conscience.

I would think that this is a strategy that would allow you to act.

Perhaps you can explain why you apparently think doing nothing
indefinitely is better for our users.

I am aware that there are subtleties here that I may have missed, so
please don't assume that I'm intentionally ignoring what you think of as
the obvious flaws with this idea.

I really don't mind being treated as an ignoramus.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#842555: QA upload

[gustavo panizzo (gfa)]

I intend to do a QA upload for this package soon, if anybody wants to be
the real maintainer, ping me I can handover my improvements to you



-- 
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: https://keybase.io/gfa

Bug#773205: libatomic-ops-dev: FTBFS on mips64el

[Tobias Hansen]

Hi Ian,

the response on the upstream bug report looks like it could take a while
with the new release. With regard to the upcoming freeze, could you
please apply the patches so that the package can migrate to testing?

Best,
Tobias

On Tue, 1 Nov 2016 11:23:19 +1100 Ian Wienand  wrote:
> I'm sorry about this. I must have misread the history of that branch
> 
> My preference is to be in sync with upstream, so I have asked if we
> can get this in a 7.4.5 release [1]
> 
> If no response, or not possible, I'll add these back in
> 
> Thanks,
> 
> -i
> 
> [1] https://github.com/ivmai/libatomic_ops/issues/20
> 
> On Fri, Oct 28, 2016 at 8:31 PM, James Cowgill  wrote:
> > Control: found -1 7.4.4-1
> > Control: severity -1 serious
> >
> > Hi,
> >
> > In 7.4.4-1 the patches adding mips64el support were removed from the
> > package. While they've applied upstream in the 'master' branch not all
> > of them were applied to the 'release-7_4' branch and libatomic-ops FTBFS
> > on mips64el again.
> >
> > These have been applied to 7.4.4-1 (which is good):
> >  0002-Remove-inclusion-of-acquire_release_volatile.h-on-mi.patch
> >  0003-Minor-fix-of-code-alignment-in-mips-AO_compare_and_s.patch
> >
> > Please reapply these patches from 7.4.2-3:
> >  0001-Use-LLD-and-SCD-instructions-on-mips64.patch
> >  0004-Support-n32-ABI-for-mips64.patch
> >
> > Thanks,
> > James
> >
> 
> 

Bug#840207: dependency formats are not converted

[Pirate Praveen]

Control: severity -1 important

On Sun, 9 Oct 2016 20:36:06 +0530 Pirate Praveen  wrote:
> severity: grave
> justification: it breaks build

Only affects newly created packages



signature.asc
Description: OpenPGP digital signature

Bug#843023: switch libmdds-dev to Architecture: any

[Helmut Grohne]

Package: libmdds-dev
Version: 1.2.2-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap
Control: affects -1 + src:libetonyek src:libixion src:liborcus src:libreoffice

The affected packages cannot satisfy their cross Build-Depends, because
their (transitive) dependency on libmdds-dev is not satisfiable. In
general, Architecture: all packages can never satisfy cross build
dependencies unless marked Multi-Arch: foreign. In this case, such a
marking would be fatal, because libmdds-dev depends on libboost-dev and
exposes libboost-dev. If libmdds-dev were marked Multi-Arch: foreign, a
host architecture dependency on it would result in the build
architecture libboost-dev. Thus libmdds-dev should become Architecture:
any to transport any architecture constraints to libboost-dev.

Alternatively, if you have more knowledge as to why that dependency
exists and whether it really is needed. libmdds-dev can stay
Architecture: all after removing the dependency on libboost-dev and can
then be marked Multi-Arch: foreign.

I am attaching a patch for the former solution as the latter is not
necessarily correct. Please consider applying it.

Helmut
diff --minimal -Nru mdds-1.2.2/debian/changelog mdds-1.2.2/debian/changelog
--- mdds-1.2.2/debian/changelog 2016-09-10 17:46:53.0 +0200
+++ mdds-1.2.2/debian/changelog 2016-11-03 09:34:53.0 +0100
@@ -1,3 +1,10 @@
+mdds (1.2.2-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch libmdds-dev to Architecture: any. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 03 Nov 2016 09:33:38 +0100
+
 mdds (1.2.2-1) unstable; urgency=medium
 
   * [adc1995] New upstream version 1.2.2
diff --minimal -Nru mdds-1.2.2/debian/control mdds-1.2.2/debian/control
--- mdds-1.2.2/debian/control   2016-06-27 16:24:37.0 +0200
+++ mdds-1.2.2/debian/control   2016-11-03 09:33:25.0 +0100
@@ -9,7 +9,8 @@
 Homepage: https://gitlab.com/mdds/mdds
 
 Package: libmdds-dev
-Architecture: all
+Architecture: any
+Multi-Arch: same
 Depends: ${shlibs:Depends}, ${misc:Depends}, libboost-dev (>= 1.39)
 Description: Multi Dimension Data structure library -- headers
  A collection of multi-dimensional data structure and indexing algorithm.

Bug#843023: switch libmdds-dev to Architecture: any

[Rene Engelhard]

tag 843023 + wontfix
thanks

On Thu, Nov 03, 2016 at 09:45:34AM +0100, Helmut Grohne wrote:
> Alternatively, if you have more knowledge as to why that dependency
> exists and whether it really is needed. libmdds-dev can stay
> Architecture: all after removing the dependency on libboost-dev and can
> then be marked Multi-Arch: foreign.

Erm, what? Obviously this dependency exists because mdds uses boost headers?

$ grep boost /usr/include/mdds-1.2/mdds/*
grep: /usr/include/mdds-1.2/mdds/multi_type_vector: Is a directory
/usr/include/mdds-1.2/mdds/node.hpp:#include 
/usr/include/mdds-1.2/mdds/node.hpp:typedef ::boost::intrusive_ptr  
node_ptr;
/usr/include/mdds-1.2/mdds/point_quad_tree.hpp:typedef 
::boost::intrusive_ptr node_ptr;
/usr/include/mdds-1.2/mdds/quad_node.hpp:#include 

> I am attaching a patch for the former solution as the latter is not
> necessarily correct. Please consider applying it.

No. mdds is Architecture all and it doesn't contain arch-dep parts (just
contains headers). Marking it as any is wrong.

Regards,

Rene

Bug#842496: [PKG-Openstack-devel] Bug#842496: closed by Thomas Goirand (Re: neutron-fwaas-common: Missing /usr/bin/neutron-fwaas-l3-agent 'binary')

[Thomas Goirand]

On 11/02/2016 09:53 PM, Turbo Fredriksson wrote:
> On 1 Nov 2016, at 17:42, Debian Bug Tracking System  
> wrote:
>>
>>  * Remove the neutron-fwaas-l3-agent init script, as this package is
>> now just a plugin. Make the neutron-fwaas-l3-agent package a transition
>> package.
> 
> Ok, so this was done between the "1:9.0.0~b2-1” and "1:9.0.0~rc1-1” which is 
> (in) a RC
> release.
> 
> 
>!!! You CAN NOT do major changes like this in minor releases !!!
> 
> 
> Not without making it VERY CLEAR for the user that this HAD to be done (and a
> very good explanation of why!
> Such notice would be a warning, using debconf etc.
> 
> And you MUST provide an upgrade path! Just saying in a change log (which 
> isn’t for the user - _NO ONE_ reads them, it’s for you as an administrator) 
> isn’t
> NEARLY enough!!

I very much agree with the above, the only issue is enough time to put
these warning in place. Maybe some text in a NEWS or README.Debian file
could do the trick. I'm not so fan of adding debconf text for such a
warning.

> How do I now get my FWaaS working again?

Just configure Neutron. The doc from Red Hat seems to cover it well:

https://access.redhat.com/documentation/en/red-hat-enterprise-linux-openstack-platform/7/paged/networking-guide/chapter-16-configure-firewall-as-a-service-fwaas

Basically, you just use the "normal" neutron-l3-agent, and configure
neutron.conf with:

service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin

I hope this helps,
Cheers,

Thomas Goirand (zigo)

Bug#843024: libqpid-proton8-dev: missing Breaks+Replaces: libqpid-proton2-dev

[Andreas Beckmann]

Package: libqpid-proton8-dev
Version: 0.14.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libqpid-proton8-dev.
  Preparing to unpack .../1-libqpid-proton8-dev_0.14.0-2_amd64.deb ...
  Unpacking libqpid-proton8-dev (0.14.0-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-jJYeCl/1-libqpid-proton8-dev_0.14.0-2_amd64.deb 
(--unpack):
   trying to overwrite '/usr/include/proton/cid.h', which is also in package 
libqpid-proton2-dev 0.10-2
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-jJYeCl/1-libqpid-proton8-dev_0.14.0-2_amd64.deb


cheers,

Andreas


libqpid-proton2-dev=0.10-2_libqpid-proton8-dev=0.14.0-2.log.gz
Description: application/gzip

Bug#843025: metview: doesn't need to depend on zsh or ksh-variant shells

[Manolo Díaz]

Package: metview
Version: 4.7.0-1
Severity: normal

Dear Maintainer,

While this package depends on ksh | mksh | pdksh | zsh it seems to use
bash and any posix compliant shell, always provided by any sane debian
system.

$ dpkg -L metview | xargs  file | grep script
/usr/bin/metview:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/MarsOdbWrapper:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/MarsTiggeWrapper:  Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/compile:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/document_macros.pl:Perl script 
text executable
/usr/lib/x86_64-linux-gnu/metview/dump:  Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/generate_video:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/logrun:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/metview-mail:  Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/metview_create_user_dir:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/metview_help:  POSIX shell 
script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/metview_post_install_tests.sh: POSIX shell 
script, ASCII text executable, with very long lines
/usr/lib/x86_64-linux-gnu/metview/mv_compress:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_flexpart_run:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_flextra_prep:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_flextra_prep.mv:a 
/usr/bin/metview script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_flextra_run:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_grib_dump:  Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_mail:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_mars_catalog.py:Python script, 
ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_obstat: Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_odbsql: Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_rttov_run:  Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_scm_run:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_scm_vis.mv: a 
/usr/bin/metview  script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_uniquename: Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_vapor_gui:  Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mv_vapor_prep.mv:  a 
/usr/bin/magml script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mvrun: Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mvrun_c:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mvrun_lnx: Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/mvusage:   Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/select_mars_config:Bourne-Again 
shell script, ASCII text executable
/usr/lib/x86_64-linux-gnu/metview/set_mars_env:  Bourne-Again 
shell script, ASCII text executable


Please consider dropping those shell dependencies.

Best Regards,
Manolo Díaz



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

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

Versions of packages metview depends on:
pn  ksh | mksh | pdksh | zsh  
ii  libc6 2.24-5
ii  libcurl3-gnutls   7.50.1-1
ii  libemos0d 2:4.4.3-1
ii  libgcc1   1:6.2.0-10
ii  libgdbm3  1.8.3-14
ii  libgeotiff2   1.4.2-2+b1
ii  libgfortran3  6.2.0-10
ii  libgrib-api0  1.17.0-1
ii  libmagplus3v5 2.29.4-1
ii  libnetcdf-c++4

Bug#801498: rakudo: Native libraries and paths

[Tobias Leich]

> Looks like the NativeCall library ignores --libpath.

The library search path is a compile time option to moarvm too.

See:
MoarVM/build/setup.pm:128:ldrpath=> '-Wl,-rpath,"/@libdir@" 
-Wl,-rpath,"@prefix@/share/perl6/site/lib"',


Since there is no option yet to add stuff to it during configure, you've 
to edit build/setup.pm at line 128.

It might want to look like this now:

MoarVM/build/setup.pm:128:ldrpath=> '-Wl,-rpath,"/@libdir@" 
-Wl,-rpath,"@prefix@/share/perl6/site/lib" 
-Wl,-rpath,"/home/gregoa/.perl6/2015.09/lib"',


The proper fix would be that Linenoise installs the liblinenoise.so in a 
known directory. Though that might not be an easy one.

Bug#843027: libc++abi-dev: fails to upgrade from 'testing' - trying to overwrite /usr/include/c++/v1/cxxabi.h

[Andreas Beckmann]

Package: libc++abi-dev
Version: 3.9.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package libc++abi-dev:amd64.
  Preparing to unpack .../libc++abi-dev_3.9.0-2_amd64.deb ...
  Unpacking libc++abi-dev:amd64 (3.9.0-2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libc++abi-dev_3.9.0-2_amd64.deb (--unpack):
   trying to overwrite '/usr/include/c++/v1/cxxabi.h', which is also in package 
libc++-dev:amd64 3.5-2
  Processing triggers for libc-bin (2.19-18+deb8u6) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/libc++abi-dev_3.9.0-2_amd64.deb


cheers,

Andreas


libc++-dev=3.5-2_libc++abi-dev=3.9.0-2.log.gz
Description: application/gzip

Bug#843028: dovecot-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/aclocal/dovecot-pigeonhole.m4

[Andreas Beckmann]

Package: dovecot-dev
Version: 1:2.2.26.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package dovecot-dev.
  Preparing to unpack .../1-dovecot-dev_1%3a2.2.26.0-1_amd64.deb ...
  Unpacking dovecot-dev (1:2.2.26.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-cbXNE2/1-dovecot-dev_1%3a2.2.26.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/aclocal/dovecot-pigeonhole.m4', which is 
also in package dovecot-core 1:2.2.25-1
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-cbXNE2/1-dovecot-dev_1%3a2.2.26.0-1_amd64.deb


cheers,

Andreas


dovecot-core=1%2.2.25-1_dovecot-dev=1%2.2.26.0-1.log.gz
Description: application/gzip

Bug#843029: org-mode 9 is out

[Gijs Hillenius]

Package: org-mode
Version: 8.3.4-1
Severity: wishlist

Dear Maintainer,

Org 9.0 is out

http://orgmode.org/Changes.html

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

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

Versions of packages org-mode depends on:
ii  emacs24 24.5+1-7
ii  emacsen-common  2.0.8

Versions of packages org-mode recommends:
ii  texlive-generic-recommended  2016.20161008-1
ii  texlive-latex-recommended2016.20161008-1

Versions of packages org-mode suggests:
pn  ditaa  
pn  org-mode-doc   
ii  texlive-fonts-recommended  2016.20161008-1
ii  texlive-latex-extra2016.20161008-1

-- no debconf information

Bug#842994: [Pkg-zsh-devel] Bug#842994: zsh-syntax-highlighting: shell flooded with error messages

[raphael truc]

Hi,

Thanks for your reply
Indeed, I noticed I had aliased long time ago ! to sudo (which I forgot)

setopt gives :

autocd
autopushd
chaselinks
correct
correctall
extendedglob
globdots
histignoredups
histnofunctions
histreduceblanks
histverify
interactive
interactivecomments
markdirs
menucomplete
monitor
nullglob
pushdsilent
pushdtohome
sharehistory
shinstdin
zle


Raphael


2016-11-03 2:34 GMT+01:00 Daniel Shahaf :

> raphael wrote on Wed, Nov 02, 2016 at 23:02:43 +0100:
> > Package: zsh-syntax-highlighting
> > Version: 0.5.0-1
> > Severity: important
> >
> > Hi,
> >
> > Since last upgrade, after a few commands I get for every commands :
> > _zsh_highlight_main__type:35: no matches found: (( 1 ))
> > _zsh_highlight_highlighter_main_paint:490: no matches found: ((
> already_added ))
> >
>
> These lines are:
>
> if ! (( already_added )); then
>   if ! (( $+REPLY )); then
>
> Have you aliased «!» to anything?  Can you share the output of `setopt`
> (without arguments)?
>
> Or — instead of these two — could you provide a minimal zshrc that
> reproduces the problem?
>
> Thanks,
>
> Daniel
>

Bug#843030: snap-templates: fails to upgrade from 'testing' - trying to overwrite /usr/bin/snap-framework

[Andreas Beckmann]

Package: snap-templates
Version: 1.0.0.0-2
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'testing'.
It installed fine in 'testing', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package snap-templates.
  Preparing to unpack .../1-snap-templates_1.0.0.0-2_amd64.deb ...
  Unpacking snap-templates (1.0.0.0-2) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-GuJr0J/1-snap-templates_1.0.0.0-2_amd64.deb (--unpack):
   trying to overwrite '/usr/bin/snap-framework', which is also in package 
libghc-snap-dev 0.14.0.7-2
  dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-GuJr0J/1-snap-templates_1.0.0.0-2_amd64.deb


cheers,

Andreas


libghc-snap-dev=0.14.0.7-2_snap-templates=1.0.0.0-2.log.gz
Description: application/gzip

Bug#842963: Please provide 0.10 (future) in experimental

[Daniel Scharon]

On Wed, 2 Nov 2016 18:19:04 +0100 Victor Seva  wrote:
> On 11/02/2016 05:47 PM, W. Martin Borgert wrote:
> > Package: prosody
> > Version: 0.9.10-1
> > Severity: wishlist
> > 
> > https://hg.prosody.im/0.10 contains the next planned release of
> > prosody. It would be nice to have it already in Debian to get the
> > bugs out and align it with Debian and the prosody-modules package.
> > In experimental, not unstable, of course.

maybe as a separate package 'prosody-0.10' like upstream does?
http://packages.prosody.im/debian/pool/main/p/prosody-0.10/
that way an eventual upload to unstable could be possible as well.

> > AFAIK, some people already use 0.10 in production, e.g. yax.im.
> > 
> 
> Yes, I'll try to start working at 0.10 in the next days

great to hear!

Regards,
Dan



smime.p7s
Description: S/MIME cryptographic signature

Bug#843031: golang-github-nsf-termbox-go-dev: fails to upgrade from 'jessie' - trying to overwrite /usr/share/gocode/src/github.com/nsf/termbox-go/_demos/editbox.go

[Andreas Beckmann]

Package: golang-github-nsf-termbox-go-dev
Version: 0.0~git20160914-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'jessie'.
It installed fine in 'jessie', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package golang-github-nsf-termbox-go-dev.
  Preparing to unpack 
.../golang-github-nsf-termbox-go-dev_0.0~git20160914-1_all.deb ...
  Unpacking golang-github-nsf-termbox-go-dev (0.0~git20160914-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/golang-github-nsf-termbox-go-dev_0.0~git20160914-1_all.deb
 (--unpack):
   trying to overwrite 
'/usr/share/gocode/src/github.com/nsf/termbox-go/_demos/editbox.go', which is 
also in package golang-termbox-dev 0.0~git20140119-1
  Errors were encountered while processing:
   
/var/cache/apt/archives/golang-github-nsf-termbox-go-dev_0.0~git20160914-1_all.deb


cheers,

Andreas


golang-termbox-dev=0.0~git20140119-1_golang-github-nsf-termbox-go-dev=0.0~git20160914-1.log.gz
Description: application/gzip

Bug#831833: [Debian-med-packaging] Bug#831833: Tagged as fixed-upstream - do you intend to upload?

[Charles Plessy]

> On Wed, Nov 02, 2016 at 09:03:45PM +0900, Charles Plessy wrote:
> > 
> > I was hoping that Upstream would make a new release with the fix :(
> > 
> > So one would need to check if the following commit would be enough as a 
> > patch...
> > 
> > https://github.com/arq5x/bedtools2/commit/be2633d4951328264611e4cabc65e12fa8fef1cd

Hi again,

it turns out that the patch representing the commit be2633d fixing the issue
can not be applied alone; the package fails to build.

Then, I tried to look for other commits to apply in order to make the patched
package buildable, and I realised that first, there has been only 16 commits in
total since the last upstream release, and second, some of these commits do fix
other bugs, less severe, but real bugs.  None of them introduce novel
unreleased features.

So I am tempted to propose to distribute the current contents of Upstream's
master branch in Squeeze.  Technically, I can:

 - Just drop a big monolithic patch in debian/patches, or
 - drop the patches produced by `git format-patch v2.26.0, or
 - make a new tarball, version 2.26.0-19-g6bf23c4 (`git describe --tags`).

What do other people think about this ?

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Bug#843028: dovecot-dev: fails to upgrade from 'testing' - trying to overwrite /usr/share/aclocal/dovecot-pigeonhole.m4

[Andreas Beckmann]

Followup-For: Bug #843028
Control: affects -1 + dovecot-imapd dovecot-ldap dovecot-sieve

Hi,

more dovecot related file overwrite problems:

  Preparing to unpack .../1-dovecot-sieve_1%3a2.2.26.0-1_amd64.deb ...
  Unpacking dovecot-sieve (1:2.2.26.0-1) over (1:2.2.25-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-7oCUjf/1-dovecot-sieve_1%3a2.2.26.0-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so', 
which is also in package dovecot-imapd 1:2.2.25-1

  Preparing to unpack .../1-dovecot-ldap_1%3a2.2.26.0-1_amd64.deb ...
  Unpacking dovecot-ldap (1:2.2.26.0-1) over (1:2.2.25-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-hv2MZP/1-dovecot-ldap_1%3a2.2.26.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/dovecot/libdovecot-ldap.so.0.0.0', which is 
also in package dovecot-core 1:2.2.25-1


Andreas

Bug#841677: mysql-connector-python: CVE-2016-5598

[Guido Günther]

Hi,
On Sat, Oct 22, 2016 at 08:27:56AM +0200, Salvatore Bonaccorso wrote:
> Source: mysql-connector-python
> Version: 2.1.3-1
> Severity: grave
> Tags: security upstream
> 
> Hi,
> 
> the following vulnerability was published for mysql-connector-python.
> 
> CVE-2016-5598[0].
> 
> 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-2016-5598
> [1] 
> http://www.oracle.com/technetwork/security-advisory/cpuoct2016verbose-2881725.html#MSQL
> 
> Please adjust the affected versions in the BTS as needed.

While 2.1.4 has other changes the only change in 2.0.5 is the CVE
fix. It seems this is caused by format string expansion in
_format_params_dict. I've attached the diff between 2.0.4 → 2.0.5. I
think wheezy is affected since it uses pythons format expansion there
but I'd be glad about a second opinion.
Cheers,
 -- Guido
diff --git a/CHANGES.txt b/CHANGES.txt
index 7ee20de..fbdca18 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -3,11 +3,16 @@ MySQL Connector/Python 2.0 - Release Notes & Changes
 
 
 MySQL Connector/Python
-Copyright (c) 2009, 2015, Oracle and/or its affiliates. All rights reserved.
+Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved.
 
 Full release notes:
  http://dev.mysql.com/doc/relnotes/connector-python/en/
 
+
+v2.0.5
+==
+- BUG22529828: Fix potencial SQL injection
+
 v2.0.4
 ==
 
diff --git a/PKG-INFO b/PKG-INFO
index de8b3a5..46adcb2 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
 Metadata-Version: 1.0
 Name: mysql-connector-python
-Version: 2.0.4
+Version: 2.0.5
 Summary: MySQL driver written in Python
 Home-page: http://dev.mysql.com/doc/connector-python/en/index.html
 Author: Oracle and/or its affiliates
diff --git a/README.txt b/README.txt
index 2f88034..99be628 100644
--- a/README.txt
+++ b/README.txt
@@ -3,7 +3,7 @@ MySQL Connector/Python 2.0
 ==
 
 MySQL Connector/Python
-Copyright (c) 2009, 2015, Oracle and/or its affiliates. All rights reserved.
+Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved.
 
 License information can be found in the LICENSE.txt file.
 
@@ -28,7 +28,7 @@ doubt, this particular copy of the software is released
 under the version 2 of the GNU General Public License.
 MySQL Connector/Python is brought to you by Oracle.
 
-Copyright (c) 2011, 2015, Oracle and/or its affiliates. All rights reserved.
+Copyright (c) 2011, 2016, Oracle and/or its affiliates. All rights reserved.
 
 License information can be found in the LICENSE.txt file.
 
diff --git a/lib/mysql/connector/cursor.py b/lib/mysql/connector/cursor.py
index 3e6a2b4..b9bfd9a 100644
--- a/lib/mysql/connector/cursor.py
+++ b/lib/mysql/connector/cursor.py
@@ -1,5 +1,5 @@
 # MySQL Connector/Python - MySQL driver written in Python.
-# Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved.
+# Copyright (c) 2009, 2016, Oracle and/or its affiliates. All rights reserved.
 
 # MySQL Connector/Python is licensed under the terms of the GPLv2
 # , like most
@@ -29,6 +29,7 @@ import re
 import weakref
 
 from . import errors
+from .catch23 import PY2
 
 SQL_COMMENT = r"\/\*.*?\*\/"
 RE_SQL_COMMENT = re.compile(
@@ -42,6 +43,14 @@ RE_SQL_INSERT_STMT = re.compile(
 re.I | re.M | re.S)
 RE_SQL_INSERT_VALUES = re.compile(r'.*VALUES\s*(\(.*\)).*', re.I | re.M | re.S)
 RE_PY_PARAM = re.compile(b'(%s)')
+RE_PY_MAPPING_PARAM = re.compile(
+br'''
+%
+\((?P[^)]+)\)
+(?P[diouxXeEfFgGcrs%])
+''',
+re.X
+)
 RE_SQL_SPLIT_STMTS = re.compile(
 b''';(?=(?:[^"'`]*["'`][^"'`]*["'`])*[^"'`]*$)''')
 RE_SQL_FIND_PARAM = re.compile(
@@ -73,6 +82,35 @@ class _ParamSubstitutor(object):
 return len(self.params) - self.index
 
 
+def _bytestr_format_dict(bytestr, value_dict):
+"""
+>>> _bytestr_format_dict(b'%(a)s', {b'a': b'foobar'})
+b'foobar
+>>> _bytestr_format_dict(b'%%(a)s', {b'a': b'foobar'})
+b'%%(a)s'
+>>> _bytestr_format_dict(b'%%%(a)s', {b'a': b'foobar'})
+b'%%foobar'
+>>> _bytestr_format_dict(b'%(x)s %(y)s',
+...  {b'x': b'x=%(y)s', b'y': b'y=%(x)s'})
+b'x=%(y)s y=%(x)s'
+"""
+def replace(matchobj):
+value = None
+groups = matchobj.groupdict()
+if groups["conversion_type"] == b"%":
+value = b"%"
+if groups["conversion_type"] == b"s":
+key = groups["mapping_key"].encode("utf-8") \
+  if PY2 else groups["mapping_key"]
+value = value_dict[key]
+if value is None:
+raise ValueError("Unsupported conversion_type: {0}"
+ "".format(groups["conversion_type"]))
+return value.decode("utf-8") if PY2 else value
+

Bug#843032: qemu-user-static: Upgrade fails: unable to close /proc/sys/fs/binfmt_misc/register

[Toby Speight]

Package: qemu-user-static
Version: 1:2.7+dfsg-3

When I upgrade from the previous (working) version in 'testing', I get a
configure failure:

/
| # dpkg --configure -a
| Setting up qemu-user-static (1:2.7+dfsg-3) ...
| update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
Invalid argument
| update-binfmts: warning: unable to enable binary format qemu-mips
| update-binfmts: exiting due to previous errors
| dpkg: error processing package qemu-user-static (--configure):
|  subprocess installed post-installation script returned error exit status 2
\

Running 'update-binfmts' by hand causes similar complaints:

/
| # update-binfmts --enable
| update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
Invalid argument
| update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
Invalid argument
| update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
Invalid argument
| update-binfmts: exiting due to previous errors
\

I was able to work around this issue by hand-editing the postinst it to add
'|mips*' to the end of $omit (luckily, I don't need MIPS emulation on my
systems).

The one thing that stands out about the MIPS registration is that the magic
and mask are much longer than for other systems - is it possible that the
kernel can't handle such long patterns?  If so, can this be detected and
avoided?

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 3.16.7-ckt2-balti (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

qemu-user-static depends on no packages.

Versions of packages qemu-user-static recommends:
ii  binfmt-support  2.1.6-1

Versions of packages qemu-user-static suggests:
ii  sudo  1.8.17p1-2

-- no debconf information

Bug#842982: lua-sec update prevents ssl connections with prosody

[Adrien CLERC]

Reply-To: 842...@bugs.debian.org

This is the same as #842906.

Adrien

Bug#842454: [debian-mysql] Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Andreas Beckmann]

On Sat, 29 Oct 2016 22:23:07 +0300 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?=
 wrote:
> Thank you very much Helmut for this patch!
> 
> I've committed it in
> https://anonscm.debian.org/cgit/pkg-mysql/mysql.git/commit/?id=b3eb803a601ffc98aa7fe24b625edcd9ba1031e8
> 
> I'll wait for a few days if somebody wants to chip in on something and
> then upload mysql-defaults 1.0.1 to Debian unstable.

NACK for

-Architecture: all
+Architecture: any
+Multi-Arch: same

I think you rather want

Architecture: all
Multi-Arch: allowed


Andreas

Bug#842841: [pkg-cinnamon] Bug#842841: Bug#842841: cinnamon: Runing cinnamon --replace segfaults after recent update

[Maximiliano Curia]

¡Hola William!

El 2016-11-02 a las 17:32 -0400, William L. DeRieux IV escribió:
I'm running Cinnamon 3.0.7-2 everything was fine until a recent update. 
Now clicking on certain items on the cinnamon-panel causes a crash and 
when running cinnamon --replace from a tty causes a segmentation fault.



Can you try to narrow down the list of upgraded packaged that caused this?


The list of upgraded packages might be useful. You can obtain this information 
from the /var/log/dpkg.log* files.


Using snapshots.debian.org, you could downgrade the cinnamon packages and test 
this again to check if any of the recent changes in cinnamon causes the issue.


Happy hacking,
--
"Inside every large problem is a small problem struggling to get out."
-- Hoare's Law of Large Problems
Saludos /\/\ /\ >< `/


signature.asc
Description: PGP signature

Bug#842987: redis: CVE-2016-2121: weak permissions on sensitive files

[Chris Lamb]

Hi Salvatore & Guido,

> > So I decided to mark this no-dsa in wheezy. Please let me know if you
> > guys don't think that's appropriate.
> 
> Thanks for the analysis! Agreed, and think we will follow the same for
> jessie as well.

Thanks to both of you. I will keep this bug open and ensure everything
is fine in unstable and testing, mind you. :)


Regards,

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

Bug#833055: Packaging of mongoclient replacement library: mongocxx

[Raphael Hertzog]

Hello Apollon,

mongodb dropped the C++ client driver that it used to provide in
mongodb-dev in favor of https://github.com/mongodb/mongo-cxx-driver

Do you plan (or know someone who plans) to package this one?

Is there ane alternate client library that you recommend?

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#840575: [buildd-tools-devel] Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Wouter Verhelst]

On Fri, Oct 14, 2016 at 07:36:56AM +0200, Johannes Schauer wrote:
> Hi,
> 
> Quoting Daniel Kahn Gillmor (2016-10-13 00:31:28)
> > > On Wed, Oct 12, 2016 at 11:42:15PM +0200, Thomas Goirand wrote:
> > >> gpg: Invalid option "--pinentry-mode"
> > 
> > … it sounds like sbuild should at least have declared a versioned
> > dependency on gnupg (>= 2.1), when --pinentry-mode was introduced.
> 
> this is indeed a real bug. Thanks for reopening this so that I don't forget to
> handle this for my next upload.

This seems to have been fixed with that next upload. However, now it's
not installable in stable anymore:

Script started on Thu Nov  3 11:08:15 2016
root@debian-sbuild:~# apt install -t jessie-backports sbuild

Reading package lists... 0%

Reading package lists... 100%

Reading package lists... Done


Building dependency tree... 0%

Building dependency tree... 0%

Building dependency tree... 50%

Building dependency tree... 50%

Building dependency tree   


Reading state information... 0%

Reading state information... 0%

Reading state information... Done

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 sbuild : Depends: libsbuild-perl (= 0.72.0-2~bpo8+1) but 0.70.0-1~bpo8+1 is to 
be installed
E: Unable to correct problems, you have held broken packages.
root@debian-sbuild:~# apt install -t jessie-backports libsbuild-perl

Reading package lists... 0%

Reading package lists... 100%

Reading package lists... Done


Building dependency tree... 0%

Building dependency tree... 0%

Building dependency tree... 50%

Building dependency tree... 50%

Building dependency tree   


Reading state information... 0%

Reading state information... 0%

Reading state information... Done

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libsbuild-perl : Depends: gnupg (>= 2.1) but 1.4.18-7+deb8u3 is to be installed
E: Unable to correct problems, you have held broken packages.
root@debian-sbuild:~# apt-cache policy gnupg
gnupg:
  Installed: 1.4.18-7+deb8u3
  Candidate: 1.4.18-7+deb8u3
  Version table:
 *** 1.4.18-7+deb8u3 0
500 http://ftp.be.debian.org/debian/ jessie/main amd64 Packages
100 /var/lib/dpkg/status
 1.4.18-7+deb8u2 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
root@debian-sbuild:~# apt-cache policy gnupg2
gnupg2:
  Installed: (none)
  Candidate: 2.0.26-6+deb8u1
  Version table:
 2.0.26-6+deb8u1 0
500 http://ftp.be.debian.org/debian/ jessie/main amd64 Packages
root@debian-sbuild:~# exit

Script done on Thu Nov  3 11:08:41 2016

Regards,

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
   people in the world who think they really understand all of its rules,
   and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12

Bug#843032: qemu-user-static: Upgrade fails: unable to close /proc/sys/fs/binfmt_misc/register

[Michael Tokarev]

03.11.2016 12:46, Toby Speight wrote:
> Package: qemu-user-static
> Version: 1:2.7+dfsg-3
> 
> When I upgrade from the previous (working) version in 'testing', I get a
> configure failure:
> 
> /
> | # dpkg --configure -a
> | Setting up qemu-user-static (1:2.7+dfsg-3) ...
> | update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: 
> Invalid argument
> | update-binfmts: warning: unable to enable binary format qemu-mips
> | update-binfmts: exiting due to previous errors
> | dpkg: error processing package qemu-user-static (--configure):
> |  subprocess installed post-installation script returned error exit status 2
> \
[]

> I was able to work around this issue by hand-editing the postinst it to add
> '|mips*' to the end of $omit (luckily, I don't need MIPS emulation on my
> systems).
> 
> The one thing that stands out about the MIPS registration is that the magic
> and mask are much longer than for other systems - is it possible that the
> kernel can't handle such long patterns?  If so, can this be detected and
> avoided?

This change was introduced very recently, see #829243.  But it works fine
on my system.  I wonder if 3.16 kernel is unable to process that binfmt
while 4.1+ can handle it...  Oh well.

/mjt

Bug#833262: libval14: irssi started crashing when connecting to OFTC with SSL

[Raphaël Droz]

Same issue with Freenode for a couple of days:
* irssi 0.8.17-1+deb8u1 
* libval14 2.0-1.1


=> 0x75cb7217 : movQWORD PTR [rsp+0x8],rsi
   0x75cb721c : movQWORD PTR [rsp],rcx
   0x75cb7220 : jne0x75cb7258 

   0x75cb7222 : moveax,DWORD PTR [rsp+0x8]
   0x75cb7226 : subeax,DWORD PTR [rsp]
   0x75cb7229 : movrdx,QWORD PTR [rsp+0x218]
   0x75cb7231 : xorrdx,QWORD PTR fs:0x28
   0x75cb723a : jne0x75cb7329 

-
0x75cb7217 in label_bytes_cmp () from 
/usr/lib/x86_64-linux-gnu/libsres.so.14


$ bt

#0  0x75cb7217 in label_bytes_cmp () from 
/usr/lib/x86_64-linux-gnu/libsres.so.14
#1  0x75cb740e in labelcmp () from 
/usr/lib/x86_64-linux-gnu/libsres.so.14
#2  0x75cb74f4 in namecmp () from 
/usr/lib/x86_64-linux-gnu/libsres.so.14
#3  0x75eeab46 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#4  0x75ee8ba6 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#5  0x75ee9839 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6  0x75eea362 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#7  0x75eeaa07 in try_chase_query () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#8  0x75ee8aca in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#9  0x75ee9839 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#10 0x75eea362 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
[skip many]
#6771 0x75eeaa07 in try_chase_query () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6772 0x75ee8aca in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6773 0x75ee9839 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6774 0x75eea362 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6775 0x75eeaa07 in try_chase_query () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6776 0x75ee8aca in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6777 0x75ee9839 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6778 0x75eea362 in ?? () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6779 0x75eeaff0 in val_resolve_and_check () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6780 0x75ef07dd in val_getdaneinfo () from 
/usr/lib/x86_64-linux-gnu/libval-threads.so.14
#6781 0x0048ee16 in irssi_ssl_verify (ssl=0x10395f0, hostname=0x105be10 
"irc.freenode.net", port=0x1a29, cert=cert@entry=0x105f110, server=0x842840, 
ctx=) at network-openssl.c:218
#6782 0x0048f994 in irssi_ssl_handshake (handle=handle@entry=0x1036b80) 
at network-openssl.c:604
#6783 0x00485897 in server_connect_callback_init_ssl (server=0x842840, 
handle=0x1036b80) at servers.c:177
#6784 0x0047e223 in irssi_io_invoke (source=, 
condition=, data=) at misc.c:54
#6785 0x76bf8b6d in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6786 0x76bf8f48 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6787 0x76bf8ffc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6788 0x00416c34 in main (argc=, argv=0x7fffd9b8) at 
irssi.c:379

Bug#831552: fixed in witty 3.3.6+dfsg-1

[Paul Wise]

On Thu, 2016-11-03 at 10:02 +, Pau Garcia i Quiles wrote:

>    * Use as3compile to build WtSoundManager instead of mtasc (Closes: #831552)

While technically, this does close the bug, the intention was to get
upstream to port the Flash code to standard web technologies.

Would it be possible for you to talk to upstream about this?

Also, AFAICT, the WtSoundManager.swf file isn't used at all?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#843033: swftools: remove from Debian?

[Paul Wise]

Source: swftools
Severity: normal

Should swftools be removed from Debian as mtasc is too (#831553)?

The web ecosystem is moving away from Flash towards standard
web technologies, which can now replace most use of Flash.
Debian should encourage our upstreams to move towards standard
web technologies like HTML5 and JavaScript.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#833055: [pkg-uWSGI-devel] Any news on uwsgi bug fixes?

[Raphael Hertzog]

Hi,

On Wed, 28 Sep 2016, Jonas Smedegaard wrote:
> > > https://bugs.debian.org/833055 - B-D mongodb-dev is no longer built by 
> > > mongodb
> > 
> > The mongodb bug is believed fixed locally on my machine (not pushed to 
> > the public git yet).
> 
> Unfortunately that build didn't succeed :-(

What did you try to fix to mongodb bug? I see nothing relevant in git
and besides entirely disabling MongoDB support I don't see what you
could have tried given that the library is gone and that the replacement
library[1] is not packaged in Debian currently AFAIK. I filed an upstream
ticket[2] to get the ball rolling upstream.

[1] https://github.com/mongodb/mongo-cxx-driver
[2] https://github.com/unbit/uwsgi/issues/1396

> I am travelling till the end of the week, so most likely won't find time 
> to dive into this again before monday.

More than a month went by since that monday :-) Do you plan to work on
the package to bring it back into 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#580928: libirman-dev: irman timeouts when used with a serial to usb adapter

[Gianfranco Costamagna]

control: fixed -1 0.5.2-0.1
control: close -1

fixed in latest upload

G.

On Sun, 09 May 2010 23:35:56 +0200 Matthieu Bedouet  wrote:
> Package: libirman-dev
> Version: 0.4.4-2
> Severity: normal
> 
> 
> Hi,
> The IRMAN serial receiver does not work correctly when plugged behind a usb 
> adapter (PL2303).
> Most of the received input are dropped.
> 
> It works nicely when setting IR_POLL_TIMEOUT to 50ms in irman.h and 
> rebuilding the lirc package against it.
> 
> Upstream has made this change in its cvs.
> 
> Thanks
> 
> 
> PS: This bug has also been submitted to ubuntu as #342347, here is the 
> contents explaining the issue with more details:
> 
> When an irman serial device is used via a usb serial convertor the default 
> select timeout is not long enough to reliably receive transmitted codes. This 
> means that buttons on the remote often have to be pressed mulitple times to 
> have the desired effect.
> 
> It is shown by lircd when built with '--enable-debug' as:
> lircd: error reading code: "Connection timed out"
> 
> This has been fixed in upstream cvs: 
> http://lirc.cvs.sourceforge.net/viewvc/lirc/libirman/irman.h?r1=1.2&r2=1.3
> 
> Although this change was made upstream a while ago it does not appear to have 
> made it into a new release.
> http://lirc.cvs.sourceforge.net/viewvc/lirc/libirman/irman.h?view=log 
> indicates revision 1.2 of this file is the one in the 0.4.4 release currently 
> used in jaunty.
> 
> I have applied this patch to libirman-dev and rebuilt the lirc package to 
> relink with the static library and can confirm codes are now reliably 
> received.
> 
> 
> 
> 
> -- System Information:
> Debian Release: squeeze/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.34-rc6 (SMP w/4 CPU cores; PREEMPT)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages libirman-dev depends on:
> ii  libc6-dev 2.10.2-7   Embedded GNU C Library: 
> Developmen
> 
> libirman-dev recommends no packages.
> 
> libirman-dev suggests no packages.
> 
> -- no debconf information
> 
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#842879: [jidanni 126520274] ps dates wrong

[Craig Small]

On Thu, Nov 3, 2016 at 1:21 PM DreamHost Customer Support Team <
supp...@dreamhost.com> wrote:

> We use 'linux-vserver' on our VPS servers. Please note that one of the
> major disadvantages of the linux-vserver package is that many hardware
> related system calls, as well as /proc and /sys nodes are left
> unvirtualized.
>
> As these nodes and /proc filesystem entries are not correctly
> virtualized, calls to /proc will most likely result in an error, or
> erroneous results.
>
Ah ha, thankyou Erik. I did think it was something like this as we
sometimes get reports about containers giving odd results.
The curious thing seems to be that the /proc/stat system boot time is the
underlying host but the /proc/[pid]/stat process start time is the time
difference between when the VPS started and the process started; which
gives this error.

This isn't really procps' fault, but just a quirk of how /proc works in
this situation.

 - Craig

Bug#736124: ITP: Improved firmware for LEGO Mindstorms NXT bricks

[Petter Reinholdtsen]

The package is waiting in NEW now.  One of the ftpmasters asked to bring
up the license on Debian Legal, the thread starts at
https://lists.debian.org/debian-legal/2016/11/msg0.html >.

The plan is to maintain this package as part of the Debian LEGO team.
The package source is available from
https://anonscm.debian.org/cgit/debian-lego/nxt-firmware.git/ >.

-- 
Happy hacking
Petter Reinholdtsen

Bug#842233: eclipse subversive pluging issue

[Arturo Borrero Gonzalez]

On 27 October 2016 at 15:22, Emmanuel Bourg  wrote:
> Hi Arturo,
>
> Thank you for the report. Would you be able to generate a thread dump
> when eclipse is blocked (using jstack or visualvm) ? This would show us
> where the application is stuck exactly.
>

Hi,

here a thread dump from visualvm with the eclipse blocked trying to
add a new SVN repository location:

2016-11-03 11:43:34
Full thread dump OpenJDK 64-Bit Server VM (25.111-b14 mixed mode):

"RMI TCP Connection(3)-127.0.0.1" #48 daemon prio=9 os_prio=0
tid=0x7f6d2c2b3000 nid=0x1547 runnable [0x7f6ccce8d000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0xe97bd6f8> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$1/187646949.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- <0xe97baf88> (a
java.util.concurrent.ThreadPoolExecutor$Worker)

"RMI TCP Connection(2)-127.0.0.1" #47 daemon prio=9 os_prio=0
tid=0x7f6d2c29f000 nid=0x1546 runnable [0x7f6cccf8e000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0xe97c1ba0> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$1/187646949.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- <0xe97bb500> (a
java.util.concurrent.ThreadPoolExecutor$Worker)

"JMX server connection timeout 46" #46 daemon prio=9 os_prio=0
tid=0x7f6d280a9800 nid=0x1531 in Object.wait()
[0x7f6d26895000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at 
com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
- locked <0xe96ef430> (a [I)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- None

"RMI Scheduler(0)" #45 daemon prio=9 os_prio=0 tid=0x7f6d280a8000
nid=0x152f waiting on condition [0x7f6d35468000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xe9729a90> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExe

Bug#842233: eclipse subversive pluging issue

[Arturo Borrero Gonzalez]

I wonder if this is related to my networking configuration:


% ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast
state DOWN group default qlen 1000
link/ether 00:23:8b:f2:e4:5c brd ff:ff:ff:ff:ff:ff
3: wlan0:  mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether 00:25:56:a9:68:b3 brd ff:ff:ff:ff:ff:ff
inet 192.168.5.173/24 brd 192.168.5.255 scope global dynamic wlan0
   valid_lft 13763sec preferred_lft 13763sec
inet6 :::34:114:603a:7299:8762/64 scope global temporary dynamic
   valid_lft 86363sec preferred_lft 14363sec
inet6 :::34:225:56ff:fea9:68b3/64 scope global
mngtmpaddr noprefixroute dynamic
   valid_lft 86363sec preferred_lft 14363sec
inet6 fe80::225:56ff:fea9:68b3/64 scope link
   valid_lft forever preferred_lft forever

% ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN
mode DEFAULT group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0:  mtu 1500 qdisc pfifo_fast
state DOWN mode DEFAULT group default qlen 1000
link/ether 00:23:8b:f2:e4:5c brd ff:ff:ff:ff:ff:ff
3: wlan0:  mtu 1500 qdisc mq state UP
mode DORMANT group default qlen 1000
link/ether 00:25:56:a9:68:b3 brd ff:ff:ff:ff:ff:ff

Bug#843034: RM: subversion-tools [all] -- RoQA; obsolete arch:all package

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

subversion-tools is now an arch:any package:

subversion-tools | 1.8.10-2| unstable | all
subversion-tools | 1.9.4-1 | unstable | kfreebsd-i386
subversion-tools | 1.9.4-3 | unstable | hurd-i386
subversion-tools | 1.9.4-3+b1  | unstable | amd64, arm64, 
armel, armhf, i386, kfreebsd-amd64, mips, mips64el, mipsel, powerpc, ppc64el, 
s390x


Andreas

Bug#842233: eclipse subversive pluging issue

[Arturo Borrero Gonzalez]

More data,

after a while, this message was printed in a small alert window:


Get repository folder children operation failed.
svn: unknown host
svn: OPTIONS request failed on '/svn/3dqavy4pdncyk3jltjz'


No idea why. I can access the same SVN repository from other eclipses
in other machines (windows et all)

Bug#138409: dpkg-dev: please add support for .buildinfo files

[Chris Lamb]

Guillem,

> Control: tag 138409 pending

Firstly, this is really great to see; thanks to you (and everyone else)
for your work on this.

This is just a quick message to query whether the applied patch fixes
the "duplicate Installed-Build-Depends" issue that I raised a week or
so ago?

If not, am very happy to file a bug so it gets captured. No point
uploading with known issues, after all.


Regards,

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

Bug#812303: synergy: diff for NMU version 1.4.16-1.1

[Arturo Borrero Gonzalez]

On Mon, 24 Oct 2016 00:33:44 -0500 Joshua Honeycutt
 wrote:
> Control: tags 812303 + patch
> Control: tags 812303 + pending
>
> Dear maintainer,
>
> I've prepared an NMU for synergy (versioned as 1.4.16-1.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.
>
> Regards.

Hi,

ping me if you need sponsor for this upload.

best regards.

Bug#843037: python-testtools: New upstream 2.2.0 available

[Free Ekanayaka]

Package: python-testtools
Version: 1.8.0-4
Severity: normal

The 1.8.0 release is over a year old. In the meantime several bug
fixes and improvements have landed upstream and are available in
the 2.2.0 release, so we should upgrade the Debian package.

If you wish, I volunteer for co-maintainership or even simply an
ad-hoc NMU.

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

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

Versions of packages python-testtools depends on:
ii  python-extras 0.0.3-3
ii  python-linecache2 1.0.0-3
ii  python-mimeparse  0.1.4-1
ii  python-pbr1.10.0-1
ii  python-pkg-resources  28.0.0-1
ii  python-traceback2 1.4.0-4
ii  python-unittest2  1.1.0-6.1
pn  python:any

Versions of packages python-testtools recommends:
ii  python-fixtures  3.0.0-2

Versions of packages python-testtools suggests:
pn  python-testtools-doc  
pn  python-twisted

-- no debconf information

Bug#843036: python-flake8: FTBFS (failing tests)

[Santiago Vila]

Package: src:python-flake8
Version: 3.0.4+dfsg1-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --with python2,python3 --buildsystem=pybuild
   dh_testdir -i -O--buildsystem=pybuild
   dh_update_autotools_config -i -O--buildsystem=pybuild
   dh_auto_configure -i -O--buildsystem=pybuild
I: pybuild base:184: python2.7 setup.py config 
running config
I: pybuild base:184: python3.5 setup.py config 
running config
   dh_auto_build -i -O--buildsystem=pybuild
I: pybuild base:184: /usr/bin/python setup.py build 
running build
running build_py
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/processor.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/utils.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/__main__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/statistics.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/exceptions.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/style_guide.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/defaults.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/checker.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
copying src/flake8/__init__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/api
copying src/flake8/api/legacy.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/api
copying src/flake8/api/__init__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/api
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/formatting
copying src/flake8/formatting/base.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/formatting
copying src/flake8/formatting/default.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/formatting
copying src/flake8/formatting/__init__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/formatting
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/git.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/vcs.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/options.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/setuptools_command.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/cli.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/mercurial.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/__init__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
copying src/flake8/main/application.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/main
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/options
copying src/flake8/options/manager.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/options
copying src/flake8/options/config.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/options
copying src/flake8/options/aggregator.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/options
copying src/flake8/options/__init__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/options
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/plugins
copying src/flake8/plugins/manager.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/plugins
copying src/flake8/plugins/pyflakes.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/plugins
copying src/flake8/plugins/_trie.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/plugins
copying src/flake8/plugins/__init__.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/plugins
copying src/flake8/plugins/notifier.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_2.7/build/flake8/plugins
I: pybuild base:184: /usr/bin/python3 setup.py build 
running build
running build_py
creating 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_3.5/build/flake8
copying src/flake8/processor.py -> 
/<>/python-flake8-3.0.4+dfsg1/.pybuild/pythonX.Y_3.5/build/flake8
copying

Bug#842879: [jidanni 126520274] ps dates wrong

[積丹尼 Dan Jacobson]

Craig, I think the .../stat time is more random,
http://unix.stackexchange.com/questions/55924/timestamp-of-socket-in-proc-pid-fd

If it was just the difference between two known items then we could
subtract one from the other to find the answer.

OK I filed https://github.com/linux-vserver/util-vserver/issues/27 .

Bug#843038: elki: FTBFS (failing tests)

[Santiago Vila]

Package: src:elki
Version: 0.7.1-2
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=maven
   dh_testdir -i -O--buildsystem=maven
   dh_update_autotools_config -i -O--buildsystem=maven
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
# Remove unneded executable bits:
find elki addons data -type f -executable -exec chmod -x {} \+
dh_auto_configure -O--buildsystem=maven
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar': No 
such file or directory
find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar': No 
such file or directory
mh_patchpoms -pelki --debian-build --keep-pom-version 
--maven-repo=/<>/debian/maven-repo

[... snipped ...]

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec - in 
de.lmu.ifi.dbs.elki.evaluation.scores.ROCEvaluationTest
Running de.lmu.ifi.dbs.elki.evaluation.scores.AveragePrecisionEvaluationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
de.lmu.ifi.dbs.elki.evaluation.scores.AveragePrecisionEvaluationTest
Running de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec - in 
de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
Running de.lmu.ifi.dbs.elki.evaluation.paircounting.ClusterContingencyTableTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec - in 
de.lmu.ifi.dbs.elki.evaluation.paircounting.ClusterContingencyTableTest

Results :

Tests in error: 
  IntegerArrayQuickSortTest.testSorted:130 TestTimedOut test timed out after 
500...

Tests run: 348, Failures: 0, Errors: 1, Skipped: 1

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] ELKI Data Mining Framework - Parent Project  SUCCESS [  0.389 s]
[INFO] ELKI Data Mining Framework . FAILURE [02:01 min]
[INFO] ELKI Data Mining Framework - Batik Visualization ... SKIPPED
[INFO] ELKI Data Mining Framework - Tutorial Algorithms ... SKIPPED
[INFO] ELKI Data Mining Framework - LibSVM based extensions SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 02:02 min
[INFO] Finished at: 2016-11-02T00:48:31+01:00
[INFO] Final Memory: 14M/36M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on 
project elki: There are test failures.
[ERROR] 
[ERROR] Please refer to /<>/elki/target/surefire-reports for the 
individual test results.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn  -rf :elki
dh_auto_test: /usr/lib/jvm/java-8-openjdk-amd64/bin/java -noverify -cp 
/usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/jvm/java-8-openjdk-amd64/lib/tools.jar
 -Dmaven.home=/usr/share/maven 
-Dmaven.multiModuleProjectDirectory=/<> 
-Dclassworlds.conf=/etc/maven/m2-debian.conf 
-Dproperties.file.manual=/<>/debian/maven.properties 
org.codehaus.plexus.classworlds.launcher.Launcher 
-s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian 
-Dmaven.repo.local=/<>/debian/maven-repo test returned exit code 1
debian/rules:10: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


I attach two different build logs.

Apparently some test expect a certain task to be executed in a certain
time. This is usually not a good idea for a Debian source package,
because there is not any guarantee anywhere that the CPU performance
will remain constant during the package build. The same machine could
well be doing many other things in parallel.

Thanks.

elki_0.7.1-2_amd64-20161101T185439Z.gz
Description: application/gzip


elki_0.7.1-2_amd64-20161101T234307Z.gz
Description: application/gzip

Bug#843039: repmgr: depends on postgresql-9.5-repmgr which is no longer built

[Emilio Pozuelo Monfort]

Source: repmgr
Version: 3.2.1-1
Severity: serious

The new version of repmgr builds postgresql-9.6-repmgr for postgresql-9.6.
However repmgr still depends on postgresql-9.5-repmgr (or older). Please
make it depend on postgresql-9.6-repmgr now.

Thanks,
Emilio

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'experimental'), (650, 'testing'), (500, 
'unstable-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 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)

Bug#833841: kodi: Checks fail at TestSystemInfo.GetOsVersion when building package

[Balint Reczey]

Control: fixed -1 17.0~alpha3+dfsg1-1

Hi,

On Tue, 9 Aug 2016 13:02:39 +0200 Simon Frei  wrote:
> In the meantime I realised there is already a patch for the tests, so I 
> updated it such that it works in my case (see attached patch).

Thank you for the report and the patch.
The build is not failing now for failing tests thus I think we don't
need to patch this failing test out.

Cheers,
Balint

Bug#843039: repmgr: depends on postgresql-9.5-repmgr which is no longer built

[Marco Nenciarini]

Il 03/11/16 12:25, Emilio Pozuelo Monfort ha scritto:
> Source: repmgr
> Version: 3.2.1-1
> Severity: serious
> 
> The new version of repmgr builds postgresql-9.6-repmgr for postgresql-9.6.
> However repmgr still depends on postgresql-9.5-repmgr (or older). Please
> make it depend on postgresql-9.6-repmgr now.
> 

Thanks for the report. I'll upload a new version ASAP.

Regards,
Marco

-- 
Marco Nenciarini - mnen...@kcore.it
7C23 B804 3E65 D298 0A21  B6E2 589F 03F0 1BA5 5038



signature.asc
Description: OpenPGP digital signature

Bug#843040: libblosc1: Bitshuffle problems on bigendian architectures

[Antonio Valentino]

Package: libblosc1
Version: 1.11.1+ds1-2
Severity: important

Dear Maintainer,
it seems that the c-blosc library has some problems withthe bitshuffle filter 
on big-endian architectures.
The problem causes several test failures on the pytables package [1, 2,
3]
when tests are run on mips, s390x and other architectures (all bigendian
it seems).

The problem has been reported upstream [4, 5] and it is currently under
investigation.
If my understanding is correct a quick fix can be implememted by
pproperly setting build flags but please refer to the upstream [4] for
more details.

[1] https://tracker.debian.org/pkg/pytables
[2] https://buildd.debian.org/status/package.php?p=pytables
[3]
https://buildd.debian.org/status/fetch.php?pkg=pytables&arch=mips&ver=3.3.0-3&stamp=1478077059
[4] https://github.com/Blosc/c-blosc/issues/181
[5] https://github.com/PyTables/PyTables/issues/583


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

Kernel: Linux 4.8.0-27-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages libblosc1 depends on:
ii  libc6 2.24-5
ii  liblz4-1  0.0~r131-2
ii  libsnappy1v5  1.1.3-3
ii  zlib1g1:1.2.8.dfsg-2+b3

libblosc1 recommends no packages.

libblosc1 suggests no packages.

-- no debconf information

Bug#838051: kodi: Embedded libsquish library now available in debian

[Balint Reczey]

Control: notfound -1 17.0~alpha3+dfsg1-1
Control: found -1  16.1+dfsg1-2

Hi Wookey,

On Mon, 26 Sep 2016 11:46:50 +0200 =?UTF-8?B?QsOhbGludCBSw6ljemV5?=
 wrote:
> Hi Wookey,
> 
> 2016-09-25 0:49 GMT+02:00 Wookey :
> > On 2016-09-24 14:14 +0200, Bálint Réczey wrote:
> >> Control: tags -1 upstream fixed-upstream pending
> >> Control: notfound -1 17.0~alpha3+dfsg1-1
> >>
> >> Hi Wookey,

> >>
> >> 2016-09-17 2:26 GMT+02:00 Wookey :
> >
> >> > The changes have also been sent upstream and will hopefully appear
> >> > in libsquish 1.14 at some point.
> >
> > This has now happened, so I just uploaded 1.14. (no functional changes over 
> > 1.13-3)
> >
> >> Thank you for packaging libsquish.
> >> Kodi upstream dropped many embedded code copies recently including
> >> libsquish in 17.x.
> >> Experimental already has a kodi version without libsquish.
> >
> > You mean that it doesn't actually use it any more?
> 
> Yes, upstream stopped using it before the removal:
> 
> commit 7d9b190a0a87a23ad2108889b20840be9b759fb8
> Author: Stefan Saraev 
> Date:   Sun Feb 7 22:02:38 2016 +0200
> 
> [guilib] remove libsquish usage
> ---
>  xbmc/guilib/DDSImage.cpp | 86
> ++
>  xbmc/guilib/DDSImage.h   | 21 -
>  xbmc/guilib/Texture.cpp  | 41 
> ++---
>  xbmc/guilib/TextureBundleXBT.cpp |  5 ++---
>  4 files changed, 26 insertions(+), 127 deletions(-)

Kodi 17 is now in unstable, this bug can be closed.

Cheers,
Balint

Bug#842878: Asterisk crashes with pjproject 2.5.5

[Bernhard Schmidt]

Control: tags -1 confirmed

> >   == Begin MixMonitor Recording PJSIP/trunk-vitelity-in-
> > asterisk*CLI>
> > Disconnected from Asterisk server
> > Asterisk cleanly ending (0).
> > Executing last minute cleanups
> > 
> > That's all. Nothing in the log either.
> > 
> > After going back to pjproject 2.5.1~dfsg-4 everything works again.
> > 
> > Maybe asterisk just needs to be rebuilt against 2.5.5? I could try this 
> > later perhaps.
> 
> Thanks for the report. Unfortunately as of tonight rebuilding is not an
> option anymore, because it FTBFSes against OpenSSL 1.1.0 (see
> Bug#816042). I'm reassigning this to pjproject to prevent testing
> migration for now.

Confirmed. If you start Asterisk in the foreground you actually get an
assertion

asterisk: ../src/pj/os_core_unix.c:1254: pj_mutex_lock: Assertion
`mutex' failed.
Aborted

Haven't done any further debugging until now, since we can't build
asterisk.

Bernhard


signature.asc
Description: Digital signature

Bug#843041: pacemaker: CVE-2016-7035

[Salvatore Bonaccorso]

Source: pacemaker
Version: 1.1.15-2
Severity: grave
Tags: security upstream patch

Hi,

the following vulnerability was published for pacemaker. Setting RC
severity since I do not know how frequent such configrations are, but
should be fixed for stretch. Patch is at [1].

CVE-2016-7035[0]:
improper IPC guarding

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-2016-7035
[1] 
https://github.com/ClusterLabs/pacemaker/pull/1166/commits/5a20855d6054ebaae590c09262b328d957cc1fc2

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#831591: ffmpeg: kodi crash

[Balint Reczey]

Control: forwarded -1 https://github.com/xbmc/xbmc/pull/10846
Control: tags -1 upstream


Hi Andreas,

On Fri, 14 Oct 2016 01:27:47 +0200 Andreas Cadhalpun
 wrote:
...

> 
> Hi,
> 
> The relevant backtrace from the kodi_crashlog is:
> 
> Thread 1 (Thread 0x7f1b6bffe700 (LWP 16893)):
> #0  0x7f1ba92991c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> #1  0x7f1ba929a64a in __GI_abort () at abort.c:89
> #2  0x7f1ba92d4f4a in __libc_message (do_abort=do_abort@entry=2, 
> fmt=fmt@entry=0x7f1ba93cdb30 "*** Error in `%s': %s: 0x%s ***\n") at 
> ../sysdeps/posix/libc_fatal.c:175
> #3  0x7f1ba92da6b6 in malloc_printerr (action=3, str=0x7f1ba93ca909 
> "free(): invalid pointer", ptr=, ar_ptr=) at 
> malloc.c:5004
> #4  0x7f1ba92dae9e in _int_free (av=0x7f1ba9601b20 , 
> p=, have_lock=0) at malloc.c:3865
> #5  0x7f1baa6d4a9d in av_buffer_unref () from 
> /usr/lib/x86_64-linux-gnu/libavutil.so.55
> #6  0x7f1baa6e15d2 in av_frame_unref () from 
> /usr/lib/x86_64-linux-gnu/libavutil.so.55
> #7  0x7f1bab93cf10 in avcodec_decode_video2 () from 
> /usr/lib/x86_64-linux-gnu/libavcodec.so.57
> #8  0x0090b26c in CDVDDemuxFFmpeg::ParsePacket(AVPacket*) ()
> #9  0x0090d0c2 in CDVDDemuxFFmpeg::Read() ()
> #10 0x01079b53 in CDVDPlayer::ReadPacket(DemuxPacket*&, 
> CDemuxStream*&) ()
> #11 0x0107ecd7 in CDVDPlayer::Process() ()
> #12 0x012103ff in CThread::Action() ()
> #13 0x012106bf in CThread::staticThread(void*) ()
> #14 0x7f1bb23e5464 in start_thread (arg=0x7f1b6bffe700) at 
> pthread_create.c:333
> #15 0x7f1ba934d30d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> 
> Looking at the ParsePacket function reveals [1]:
> AVFrame picture;
> memset(&picture, 0, sizeof(AVFrame));
> picture.pts = picture.pkt_dts = picture.pkt_pts = 
> picture.best_effort_timestamp = AV_NOPTS_VALUE;
> picture.pkt_pos = -1;
> picture.key_frame = 1;
> picture.format = -1;
> 
> This is using non-public ABI, e.g. the size of AVFrame, while the 
> documentation
> explicitly says "sizeof(AVFrame) is not a part of the public ABI" [2].
> What's worse is that it doesn't use av_frame_alloc as required [3]:
> "AVFrame must be allocated using av_frame_alloc()."
> 
> The whole block quoted above should be replaced with:
> AVFrame *picture = av_frame_alloc().
> 
> Then the following code should use picture instead of &picture:
> avcodec_decode_video2(st->codec, picture, &got_picture, pkt);
> 
> And at the end it can be freed (instead of using av_frame_unref) with:
> av_frame_free(&picture);
> 
> In the experimental kodi branch there is another occurrence of this bug
> in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.

Thank you for the triaging and extensive description of the problem.
I have now forwarded the patch to upstream under your name since I did
not really add anything to the patch.

> 
> Best regards,
> Andreas
> 
> 
> 1: 
> https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git/tree/xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.cpp?id=8d5cf423001aa4e7f850c20b158b2811e637e607#n1665
> 2: 
> https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n174
> 3: 
> https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n154
> 
> 

Bug#842963: Please provide 0.10 (future) in experimental

[Matthew Wild]

On 3 November 2016 at 09:20, Daniel Scharon
 wrote:
> maybe as a separate package 'prosody-0.10' like upstream does?
> http://packages.prosody.im/debian/pool/main/p/prosody-0.10/
> that way an eventual upload to unstable could be possible as well.

With my upstream hat on, I'd prefer not having package name collisions
with our upstream repository. Our repository provides automated
nightly builds, and when people install 'prosody-0.10' that's what
they believe they are getting.

A prosody-0.10 package in Debian would require manual updates to keep
up with upstream, so people who thought they had the latest automated
build may actually have an outdated build. This would make user
support harder for us.

I'm not against packaging 0.10, however. We are aiming to release the
first beta this month.

Regards,
Matthew

Bug#831591: ffmpeg: kodi crash

[Bálint Réczey]

2016-11-03 12:54 GMT+01:00 Balint Reczey :
...
> On Fri, 14 Oct 2016 01:27:47 +0200 Andreas Cadhalpun
>  wrote:
> ...
>
>>
>> Hi,
>>
>> The relevant backtrace from the kodi_crashlog is:
...
>> In the experimental kodi branch there is another occurrence of this bug
>> in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.
>
> Thank you for the triaging and extensive description of the problem.
> I have now forwarded the patch to upstream under your name since I did
> not really add anything to the patch.


If someone having the test file could test latest kodi in unstable
that  would be geat.

Cheers,
Balint

Bug#843042: video-nouveau GUI freezes when playing video on chrome or firefox

[Jurison Murati]

Package: xserver-xorg-video-nouveau
Version: 1:1.0.13-1
Severity: important

Dear Maintainer,

While watching youtube in firefox or chrome the system totally freezes.
In meantime you can connect through ssh and restart it normally.

/var/log/messeges

Nov  3 10:39:57 PLUS kernel: [522977.731404] chrome[11320]: segfault at
0 ip 7f8ea3a52075 sp 7ffdab582240 error 4 in
nouveau_dri.so[7f8ea35e7000+8fc000]
Nov  3 10:45:15 PLUS kernel: [523295.464189] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:17 PLUS kernel: [523297.465205] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:19 PLUS kernel: [523299.465226] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:21 PLUS kernel: [523301.465256] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:23 PLUS kernel: [523303.465267] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:25 PLUS kernel: [523305.465274] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:27 PLUS kernel: [523307.465290] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:29 PLUS kernel: [523309.465311] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:31 PLUS kernel: [523311.465327] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:33 PLUS kernel: [523313.465340] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:35 PLUS kernel: [523315.465362] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:37 PLUS kernel: [523317.465374] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:45:45 PLUS kernel: [523325.460490] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:46:15 PLUS kernel: [523355.700624] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:46:32 PLUS kernel: [523372.700396] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:46:34 PLUS kernel: [523374.701537] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:46:51 PLUS kernel: [523391.700657] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:46:53 PLUS kernel: [523393.702036] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:47:10 PLUS kernel: [523410.700835] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:47:12 PLUS kernel: [523412.702229] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:47:29 PLUS kernel: [523429.700917] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:47:31 PLUS kernel: [523431.702166] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:47:48 PLUS kernel: [523448.700872] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!
Nov  3 10:47:50 PLUS kernel: [523450.702082] nouveau :01:00.0:
timeout at
/build/linux-hw0LPm/linux-4.7.8/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/nv41.c:79/nv41_vm_flush()!



-- Package-specific info:
X server symlink status:

lrwxrwxrwx 1 root root 13 Nov 15  2015 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Sep  6 15:09 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV41GL

Bug#843043: ITP: pd-py -- Python scripting objects for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-py
  Version : 0.2.0
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/py/
* License : GPL2+
  Programming Lang: C++/Python/Pd
  Description : Python scripting objects for Pure Data

 This object library provides full integration of the Python scripting language
 into the Pure Data (Pd) and Max/MSP real-time systems.
 .
  - py loads Python modules and allows to execute functions therein.
  - pyext uses Python classes to represent full-featured message objects.
 .
 Multithreading (‘detaching’) is supported for background operation.

I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#843038: elki: FTBFS (failing tests)

[Erich Schubert]

severity 843038 wishlist
thanks

Hi,
The test that failed is CPU sensitive.
Yes, it should probably be disabled, but does not any "serious" bug if it
fails on a heavily loaded machine.
In particular, the solution obviously is to just not run the test at all.
That is not really an improvement either...


On Thu, Nov 3, 2016 at 12:16 PM, Santiago Vila  wrote:

> Package: src:elki
> Version: 0.7.1-2
> Severity: serious
>
> Dear maintainer:
>
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
>
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --buildsystem=maven
>dh_testdir -i -O--buildsystem=maven
>dh_update_autotools_config -i -O--buildsystem=maven
>debian/rules override_dh_auto_configure
> make[1]: Entering directory '/<>'
> # Remove unneded executable bits:
> find elki addons data -type f -executable -exec chmod -x {} \+
> dh_auto_configure -O--buildsystem=maven
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compiler/*/*.jar':
> No such file or directory
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-compilers/*/*.jar':
> No such file or directory
> find: '/usr/share/maven-repo/org/codehaus/plexus/plexus-containers/*/*.jar':
> No such file or directory
> mh_patchpoms -pelki --debian-build --keep-pom-version
> --maven-repo=/<>/debian/maven-repo
>
> [... snipped ...]
>
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
> - in de.lmu.ifi.dbs.elki.evaluation.scores.ROCEvaluationTest
> Running de.lmu.ifi.dbs.elki.evaluation.scores.
> AveragePrecisionEvaluationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in de.lmu.ifi.dbs.elki.evaluation.scores.AveragePrecisionEvaluationTest
> Running de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.001 sec
> - in de.lmu.ifi.dbs.elki.evaluation.scores.MaximumF1EvaluationTest
> Running de.lmu.ifi.dbs.elki.evaluation.paircounting.
> ClusterContingencyTableTest
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec
> - in de.lmu.ifi.dbs.elki.evaluation.paircounting.
> ClusterContingencyTableTest
>
> Results :
>
> Tests in error:
>   IntegerArrayQuickSortTest.testSorted:130 TestTimedOut test timed out
> after 500...
>
> Tests run: 348, Failures: 0, Errors: 1, Skipped: 1
>
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] ELKI Data Mining Framework - Parent Project  SUCCESS [
> 0.389 s]
> [INFO] ELKI Data Mining Framework . FAILURE [02:01
> min]
> [INFO] ELKI Data Mining Framework - Batik Visualization ... SKIPPED
> [INFO] ELKI Data Mining Framework - Tutorial Algorithms ... SKIPPED
> [INFO] ELKI Data Mining Framework - LibSVM based extensions SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> 
> [INFO] Total time: 02:02 min
> [INFO] Finished at: 2016-11-02T00:48:31+01:00
> [INFO] Final Memory: 14M/36M
> [INFO] 
> 
> [ERROR] Failed to execute goal org.apache.maven.plugins:
> maven-surefire-plugin:2.17:test (default-test) on project elki: There are
> test failures.
> [ERROR]
> [ERROR] Please refer to /<>/elki/target/surefire-reports for
> the individual test results.
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/
> MojoFailureException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :elki
> dh_auto_test: /usr/lib/jvm/java-8-openjdk-amd64/bin/java -noverify -cp
> /usr/share/maven/boot/plexus-classworlds-2.x.jar:/usr/lib/
> jvm/java-8-openjdk-amd64/lib/tools.jar -Dmaven.home=/usr/share/maven
> -Dmaven.multiModuleProjectDirectory=/<>
> -Dclassworlds.conf=/etc/maven/m2-debian.conf -Dproperties.file.manual=/<<
> PKGBUILDDIR>>/debian/maven.properties 
> org.codehaus.plexus.classworlds.launcher.Launcher
> -s/etc/maven/settings-debian.xml -Ddebian.dir=/<>/debian
> -Dmaven.repo.local=/<>/debian/maven-repo test returned exit
> code 1
> debian/rules:10: recipe for target 'build-indep' failed
> make: *** [build-indep] Error 1
> dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
> 
> --

Bug#843044: ITP: pd-vasp -- VASP modular - Vector assembling signal processor for PD

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-vasp
  Version : 0.1.3
  Upstream Author : Thomas Grill 
* URL : https://github.com/g/vasp
* License : GPL-2+
  Programming Lang: C++/Pd
  Description : VASP modular - Vector assembling signal processor for PD

 VASP is a package for PD or Max/MSP consisting of a number of externals
 extending these systems with functions for non-realtime array-based audio data
 processing. VASP is capable of working in the background, therefore not
 influencing eventual dsp signal processing.

I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#843046: open-infrastructure-system-images: FTBFS with bash as /bin/sh

[Chris Lamb]

Source: open-infrastructure-system-images
Version: 20161101-lts1-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,

open-infrastructure-system-images fails to build from source in unstable/amd64 
when 
/bin/sh is set to bash:

  […]

 dh_auto_test
make -j9 test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20161103121624.MTC73aK81v.db.open-infrastructure-system-images/open-infrastructure-system-images-20161101-lts1'
  Checking for syntax errors.images/base-system/config/hooks/normal: 
images/base-system/config/hooks/normal: Is a directory
  Makefile:20: recipe for target 'test' failed
  make[1]: *** [test] Error 126
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20161103121624.MTC73aK81v.db.open-infrastructure-system-images/open-infrastructure-system-images-20161101-lts1'
  dh_auto_test: make -j9 test returned exit code 2
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

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

Bug#843047: ITP: pd-pool -- Hierarchical data storage for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-pool
  Version : 0.2.1
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/pool
* License : GPL-2+
  Programming Lang: C++/Pd
  Description : Hierarchical data storage for Pure Data

 Pool can store and retrieve key/value pairs, where a key can be any atom and
 the value can be any list of atoms. Pool can manage folders, a folder name can
 be any atom. Pool objects can be named and then share their data space.
 Clipboard operations are possible in a pool or among several pools. File
 operations can load/save data from disk.

I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#843045: open-infrastructure-system-images: FTBFS with bash as /bin/sh

[Chris Lamb]

Source: open-infrastructure-system-images
Version: 20161101-lts1-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,

open-infrastructure-system-images fails to build from source in unstable/amd64 
when 
/bin/sh is set to bash:

  […]

 dh_auto_test
make -j9 test
  make[1]: Entering directory 
'/home/lamby/temp/cdt.20161103121624.MTC73aK81v.db.open-infrastructure-system-images/open-infrastructure-system-images-20161101-lts1'
  Checking for syntax errors.images/base-system/config/hooks/normal: 
images/base-system/config/hooks/normal: Is a directory
  Makefile:20: recipe for target 'test' failed
  make[1]: *** [test] Error 126
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20161103121624.MTC73aK81v.db.open-infrastructure-system-images/open-infrastructure-system-images-20161101-lts1'
  dh_auto_test: make -j9 test returned exit code 2
  debian/rules:4: recipe for target 'build' failed
  make: *** [build] Error 2

  […]

The full build log is attached.


Regards,

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


open-infrastructure-system-images.20161101-lts1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#843048: ITP: pd-xsample -- extended sample objects for Pure Data

[IOhannes m zmoelnig]

Package: wnpp
Severity: wishlist
Owner: IOhannes m zmoelnig 

* Package name: pd-xsample
  Version : 0.3.1
  Upstream Author : Thomas Grill 
* URL : http://g.org/research/software/xsample/
* License : GPL-2+
  Programming Lang: C++/Pd
  Description : extended sample objects for Pure Data

 This is a collection of efficient buffer-based sampling objects for Pure Data
 (Pd) and Max.
 There's the variable-speed interpolating player [xgroove~], the index-driven
 [xplay~] and the sample-accurate recorder [xrecord~]


I intend to maintain the package under the pkg-multimedia-maintainers umbrella
as part of the pd-externals packaging effort.

Bug#842960: [git-buildpackage/master] Build-depend on libdistro-info-perl

[Guido Günther]

tag 842960 pending
thanks

Date:   Thu Nov 3 13:17:33 2016 +0100
Author: Guido Günther 
Commit ID: 924f8098ac69ffea5e546afa7372451cd6c35352
Commit URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff;h=924f8098ac69ffea5e546afa7372451cd6c35352
Patch URL: 
https://git.sigxcpu.org/cgit/git-buildpackage/;a=commitdiff_plain;h=924f8098ac69ffea5e546afa7372451cd6c35352

Build-depend on libdistro-info-perl

This silences the testsuite and unbreaks the build on Ubuntu

Closes: #842960

A snapshot build including this change will be available at
http://honk.sigxcpu.org:8001/job/git-buildpackage/
  

Bug#843021: RFP: yarn -- a fast, reliable, and secure package manager for Node.js

[Paolo Greppi]

On 03/11/2016 09:10, Lars Wirzenius wrote:
> On Thu, Nov 03, 2016 at 08:36:21AM +0100, Paolo Greppi wrote:
>>Package name: yarn
>> URL: https://github.com/yarnpkg/yarn
> 
> My cmdtest package provides yarn, since the main tool it now provides
> is yarn (a testing tool), not cmdtest. Perhaps your package could be
> called yarnpkg?

cmdtest provides yarn since this commit:
http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad

A package search for yarn currently returns no match.
https://packages.debian.org/search?keywords=yarn

The real issue here is that both cmdtest and the proposed package
install a yarn binary.

The conflict could be addressed in several ways:

1. as you suggest, renaming this package and the binary it installs to
yarnpkg

2. keeping the package name yarn but renaming the binary to yarnpkg

3. renaming the executable yarn in cmdtest to yarn-something-else, and
have cmdtest provide yarn-something-else

4. ignoring the conflict and setting the Conflict flags in both packages
(https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts)

... but I am not sure if all are feasible.

This looks similar to what happened with nodejs / node.
To avoid a package naming conflict with the old package node
(https://packages.qa.debian.org/n/node.html), node entered Debian as nodejs.
To avoid a binary conflict, also the binary was renamed nodejs from node.
People who do not use the old node package and like to invoke node as
node rather than nodejs can install the node-legacy package.

Similar to node/nodejs, for 1 and 2 there could be a
yarn-legacy/yarnpkg-legacy package for those who do not use cmdtest and
like to invoke yarn as yarn rather than yarnpkg.
For 3, there could be a cmdtest-legacy package for those who do not use
yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn
rather than yarn-something-else.

While technically flawless, in retrospect the way the nodejs conflict
was solved is not a success story in terms of expanding the Debian user
base (which is the main reason for having these trendy packages in).

At the moment we are confusing the newbies who come to Debian for
JavaScript development.
It would be easier if they could apt-get install node/yarn and then just
type node/yarn to use them.
For comparison, on macOS they can do brew install node/yarn and then
type node/yarn.

For node this may be possible sometime in the future as the old node
package is transitioning to ax25-node and the binary has also been
renamed /usr/sbin/ax25-node.

Finally, I looked at the popcon installed numbers - for what it's worth
and in relative terms.

- node (now ax25-node) peaked at ~1100

- cmdtest has ~50

- about 15% of those who install nodejs (~14000) also install
nodejs-legacy (~2000)

- npm (which is the main alternative to yarn as a nodejs package
manager) has ~6000

- for yarn/yarnpkg it's difficult to predict now, but probably it will
end up in the range 0-6000, high or low depending how much traction it
will get.

In conclusion, I leave it to those who know more what is the best thing
to do !




signature.asc
Description: OpenPGP digital signature

Bug#841522: RM: arcboot [mips] -- ROM; Lack of architecture support in stretch

[Andreas Beckmann]

Control: reopen -1
Control: retitle -1 RM: arcboot -- ROM; Lack of architecture support in stretch

this should have been a source-removal as well ...


Andreas

Bug#842682: mp3splt: depending libmp3splt version not available yet (0.7.3 vs 0.9.2)

[Jan Luca Naumann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Sorry, forgot to add a description in the message before: The bug
should be closed in version 2.6.2-0.1

Best regards,
Jan

On Mon, 31 Oct 2016 11:39:10 +0100 der_...@opentrash.com wrote:
> Package: mp3spltVersion: 2.4.2-2mp3splt in sid depends on version
> of libmp3splt0 (<<0.7.3~) that is not longer available in sid
> (0.9.2-0.1):#LANG=C apt install -s mp3spltReading package lists...
> DoneBuilding dependency tree  
> Reading state information... DoneSome packages could not be
> installed. This may mean that you haverequested an impossible
> situation or if you are using the unstabledistribution that some
> required packages have not yet been createdor been moved out of
> Incoming.The following information may help to resolve the
> situation:The following packages have unmet
> dependencies: mp3splt : Depends: libmp3splt0 (< 0.7.3~) but
> 0.9.2-0.1 is to be installedE: Unable to correct problems, you have
> held broken packages.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJYGy/DAAoJEH4R1/EZ+XG7wWsQAI8cYe23AZWj4OZw5enNZ/yp
BHqJcJAsOuiEZMfEsYmlO6lUuAD3HZ0rnacvVfSoa4ewmbdPdNAvg5gqNLlNSZdp
rkryIRf6PNgDy6YRoSJSgWiWcRdxmB5JAaknfD6nnDtjzE+vda2vsO3eITTjCyt8
hhXekb2wVj/OTUQUpcTJWM0aaAsIim/LbnOI40UfaFiVkutkT4ME0COZJIVVONcT
IdLTfrpDIjhA5N7UvrQMrT4E0cQn/Icmj8eezSEA6/fLlSk5E6TeGEYpXXcdLWEv
/46h0ZIGcHA5hDE+2VLIWCnHDh+DKWRco0Xwck1jaQ3d1pGjtdnUcAihXP5/GOwZ
0zbRUNUkuqk4VpfhSP4hO1B3rdPeYi74RBOnYbZ0Lm62ab22smvUVYexQXenEGLn
a7OOuplhYSc1X2HOTG04gkmN5GpyQnlR+v2B5NzFEVbLkM9JBMvUwG58h4+GsABl
Mk/6kaYsD3ANPywhxBsR37Y1pISebYvdE+6U3CYXZCN69r7I2/R8YGrYpXl1Y8NM
KlgrYpLnzBCBXl7N9wWxM8X7oMgQttv86LYhzQK8kK6lZFJM9qDREi7HAz0ZPMgk
HyrMxSawfSTAoiRFPz6GgJcOwnQUrci8dC9EDfBRESneK9r3ZbP41SqZttC3tRrZ
RieLMUIRrBNqfP1a7QR0
=Nz8q
-END PGP SIGNATURE-

Bug#840575: [buildd-tools-devel] Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Thomas Goirand]

On 11/03/2016 11:10 AM, Wouter Verhelst wrote:
> The following packages have unmet dependencies:
>  sbuild : Depends: libsbuild-perl (= 0.72.0-2~bpo8+1) but 0.70.0-1~bpo8+1 is 
> to be installed
> E: Unable to correct problems, you have held broken packages.
> root@debian-sbuild:~# apt install -t jessie-backports libsbuild-perl
> The following packages have unmet dependencies:
>  libsbuild-perl : Depends: gnupg (>= 2.1) but 1.4.18-7+deb8u3 is to be 
> installed

Hi there!

Indeed, sbuild in backports is not not installable.

dkg, you had the intention to upload gnupg 2.1 to backports. Is there
anything that's holding it?

Lucas, could you upload a version of sbuild to BPO without this hard
requirement, and maybe with the fix I suggested for the keygen thing?
While not the definitive solution, this would fix it in the mean time.

Cheers,

Thomas Goirand (zigo)

Bug#843049: battery-stats: battery-graph throws syntax error with non-empty battery-log

[Sebastien Delafond]

Package: battery-stats
Version: 0.5.1-1
Severity: normal

Running battery-graph:

~ # bash -x /usr/bin/battery-graph
+ set -e
+ prefix=/usr
+ libdir=/usr/share/battery-stats
++ getopt -o f:s:t:d:TAg:D --long 
from:,since:,to:,duration:,text,norate,title:,geometry:,display:,libdir: -n 
battery-graph --
+ TEMP=' --'
++ date +%s --date=now
+ now=1478161748
+ from=0
+ to=0
+ duration=0
+ default_duration=10800
+ text=false
+ SWITCH_RATE=true
+ title='Battery Graph'
+ eval set -- ' --'
++ set -- --
+ true
+ case "$1" in
+ shift
+ break
+ '[' -z :0.0 ']'
+ '[' 0 -eq 0 ']'
+ '[' 0 -eq 0 ']'
+ '[' 0 -eq 0 ']'
+ duration=10800
+ to=1478161748
+ case "${from}:${duration}:${to}" in
+ from=1478150948
++ TZ=UTC
++ date +%s --date=1/1/2000
++ TZ=UTC
++ date +%s --date=1/1/1970
+ adjustment=946684800
++ date -u --date=12:00 +%s
++ date --date=12:00 +%s
+ utc_adjust=3600
+ adjustment=946681200
+ from2000=531469748
+ to2000=531480548
++ mktemp
+ TMPFILENAME=/tmp/tmp.UctS6HSC9N
+ battery-log
++ tail -n 1 /tmp/tmp.UctS6HSC9N
++ awk '{ print $1 }'
+ TIME_LAST_RECORD=1478161742
++ awk 'BEGIN {last_status=-1} { if ($3!=last_status && $3==1) {tchange = $1} 
last_status=$3 } END {print (tchange)}' /tmp/tmp.UctS6HSC9N
+ TIME_LAST_DISCHARGE_BEGIN=
+ '[' '!' 1478161742 ']'
++ awk 'BEGIN {last_status=-1} { if ($3!=last_status && $3==2) {tchange = $1} 
last_status=$3 }  END { if (tchange>) {print (tchange)} 
else {print 1478161742} }' /tmp/tmp.UctS6HSC9N
awk: cmd. line:1: BEGIN {last_status=-1} { if ($3!=last_status && $3==2) 
{tchange = $1} last_status=$3 }END { if (tchange>) {print (tchange)} 
awk: cmd. line:1:   
  ^ syntax error
awk: cmd. line:2:   else {print 1478161742} }
awk: cmd. line:2:   ^ syntax error
+ TIME_LAST_DISCHARGE_END=

battery-log isn't empty, as shown by cat'ing the temporary file created
by the battery-graph run above:

~ !1 # cat /tmp/tmp.UctS6HSC9N
1478160697 60.64 2 2016/11/03 09:11:37 -
1478161141 60.64 2 2016/11/03 09:19:01 -
1478161201 60.64 2 2016/11/03 09:20:01 -
1478161261 60.64 2 2016/11/03 09:21:01 -
1478161321 60.64 2 2016/11/03 09:22:01 -
1478161381 60.64 2 2016/11/03 09:23:01 -
1478161441 60.64 2 2016/11/03 09:24:01 -
1478161501 60.64 2 2016/11/03 09:25:01 -
1478161561 60.64 2 2016/11/03 09:26:01 -
1478161621 60.64 2 2016/11/03 09:27:02 -
1478161682 60.64 2 2016/11/03 09:28:02 -
1478161742 60.64 2 2016/11/03 09:29:02 -

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages battery-stats depends on:
pn  gnuplot
ii  gzip   1.6-5
pn  libacpi0   
pn  libapm1
ii  libc6  2.23-4
ii  logrotate  3.8.7-2

battery-stats recommends no packages.

battery-stats suggests no packages.

Bug#842233: eclipse subversive pluging issue

[Arturo Borrero Gonzalez]

I managed to add the SVN repository.

But it doesn't work, I can't do any operation with it, neither open it
or checkout, given eclipse will block.

The reports above were using openjdk. I tried with the oracle-jdk
which presents the same behaviour, and here the results:

2016-11-03 13:39:12
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.112-b15 mixed mode):

"RMI TCP Connection(2)-127.0.0.1" #49 daemon prio=9 os_prio=0
tid=0x7f32c00e7000 nid=0x369d runnable [0x7f3293bd4000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0xf8ae7610> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$2/2074636523.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- <0xf8aab9f0> (a
java.util.concurrent.ThreadPoolExecutor$Worker)

"JMX server connection timeout 48" #48 daemon prio=9 os_prio=0
tid=0x7f32d9396000 nid=0x369b in Object.wait()
[0x7f329160b000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at 
com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
- locked <0xfb745bd0> (a [I)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- None

"RMI Scheduler(0)" #47 daemon prio=9 os_prio=0 tid=0x7f32d897a000
nid=0x3699 waiting on condition [0x7f3282c97000]
   java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xfb74c860> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
- None

"RMI TCP Connection(1)-127.0.0.1" #46 daemon prio=9 os_prio=0
tid=0x7f32c00e5800 nid=0x3698 runnable [0x7f3282b95000]
   java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:170)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0xfb767cc8> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(FilterInputStream.java:83)
at 
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:550)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$2/2074636523.run(Unknown
Source)
at java.security.AccessController.doPrivileged(Native Method)
at 
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
at 
java.util.concurrent.ThreadPoolE

Bug#732320: java-package: for jdk provide alternative to bin/java rather than jre/bin/java

[Jan Vansteenkiste]

On Mon, 16 Dec 2013 18:26:04 +0100 Niels Thykier  wrote:

> Dear Maintainer,
> when creating a deb package from the JDK there should be a (and probably
> the default one) pointing to bin/java (and all other tools) rather than
> jre/bin/java.
> firstly, a JDK is usually installed to be used as JDK not a JRE (else one
> would use the JRE to begin with). secondly, Eclipse/ANT continually
> complaints about the java exec not being from an JDK, preventing the use
> of the same JRE as Eclipse uses and thus a several features requiring ANT
> to use the same java as Eclipse does.

On the other hand, jre packages do NOT include the path to .../jre/bin/java.

debian-8:/etc/alternatives# update-alternatives --list java
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
/usr/lib/jvm/oracle-java8-jdk-amd64/jre/bin/java
/usr/lib/jvm/oracle-java8-jre-amd64/bin/java
/usr/lib/jvm/oracle-java8-server-jre-amd64/bin/java

I quickly backported 0.62 to jessie to create these.
ii  java-package   0.62~bpo8+1
all  Utility for creating Java Debian packages


This also makes automation around these packages difficult.






signature.asc
Description: OpenPGP digital signature

Bug#843038: elki: FTBFS (failing tests)

[Santiago Vila]

On Thu, Nov 03, 2016 at 01:12:38PM +0100, Erich Schubert wrote:
> severity 843038 wishlist
> thanks
> 
> Hi,
> The test that failed is CPU sensitive.
> Yes, it should probably be disabled, but does not any "serious" bug if it
> fails on a heavily loaded machine.
>
> In particular, the solution obviously is to just not run the test at all.
> That is not really an improvement either...

The reason I reported this as serious is release policy:

https://release.debian.org/stretch/rc_policy.txt

which says that packages must autobuild without failure.

The common interpretation for this is that packages must *always* autobuild,
not just "most of the time" and not just randomly.

If you do not consider this to be RC, that's fine, but that's why the
sarge-ignore tag exists.

Thanks.

Bug#843050: Fails to start when cache directory is missing

[martin f krafft]

Package: apache2-utils
Version: 2.4.23-5
Severity: important
File: /usr/bin/htcacheclean

Nov  3 13:49:49 albatross systemd[1]: Starting Disk Cache Cleaning Daemon for 
Apache HTTP Server...
Nov  3 13:49:49 albatross htcacheclean[4246]: htcacheclean error: Could not set 
filepath to '/var/cache/apache2/mod_cache_disk': No such file or directory

By the filesystem hierarchy standard, nothing in /var/cache must be
taken for granted. This means that the tool either needs to fail
gracefully, or create the missing directory/file.

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

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

Versions of packages apache2-utils depends on:
ii  libapr1  1.5.2-4
ii  libaprutil1  1.5.4-2
ii  libc62.24-5
ii  libssl1.0.2  1.0.2j-3

apache2-utils recommends no packages.

apache2-utils suggests no packages.

-- no debconf information


-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#843051: release.debian.org: boost1.62 transition

[Dimitri John Ledkov]

Package: release.debian.org
Severity: normal

Hello,

boost-defaults has already been accepted to effectively start the
boost1.62 transition. Quite speedy NEW queue processing there.

smr and I, debate taking boost1.62 transition because it is a relatively
small jump; and there are openssl fixes. (boost doesn't directly link
against openssl, but the exposed templates do use openssl, thus boost is
entagled transitively into openssl transition for packages that use
relevant boost templates).

The rebuild results look ok:
http://people.canonical.com/~ubuntu-archive/transitions/html/boost1.62.html

Whilst this is Ubuntu transition tracker, many results are transferable,
as it covers 6 out 10 release architecutres. There are a few packages in
Ubuntu that are not in Debian Testing, thus I expect binNMUs to behave
better in Debian. And I commit to fixing outstanding packages to the
best of my ability to complete this transition swiftly.

Ben transition tracker I used is as follows:

title = "Boost 1.62";

is_affected = .depends ~ /libboost[a-z-.]*1\.6[012]/;
is_good = .depends ~ /libboost[a-z-.]*1\.62/;
is_bad = .depends ~ /libboost[a-z-.]*1\.6[01]/;

Adjust to taste.

Regards,

Dimitri.

Bug#842911: [Pkg-libvirt-maintainers] Bug#842911: please reconsider dropping libvirt-bin

[Riku Voipio]

On Wed, Nov 02, 2016 at 09:23:53PM +0100, Guido Günther wrote:
> On Wed, Nov 02, 2016 at 09:36:21AM +, Riku Voipio wrote:
> > libvirt-bin is still referred to in many places, for example in openstack
> > devstack. The replacement -clients and -daemon-system packages are not yet
> > available in the latest ubuntu LTS. This leads to some inconvinient
> > "if ubuntu then else if debian newer than then" checks if we want to 
> > support both.
 
> It's simple as:
> 
> Depends: libvirt-daemon-system | libvirt-bin, libvirt-clients | 
> libvirt-bin

> so I'd rather not readd the transitional package. I don't want to make
> people's lifes harder than necessary though so if you think it's more
> complex please explain.

That is indeed simple for packages, but devstack case we install packages
from shellscript:

https://github.com/openstack-dev/devstack/blob/1c13be860ba3662bf6c633fc37668f7feacdd3e5/lib/nova_plugins/functions-libvirt#L27

The workaround is probably to add an "if debian && newer than jessie, install
these instead" but it's not exactly pretty. Then again installer scripts often
aren't.

Riku

Bug#840575: [buildd-tools-devel] Bug#840575: sbuild bpo: uses non-available option gnupg --pinentry-mode

[Luca Falavigna]

2016-11-03 13:41 GMT+01:00 Thomas Goirand :
> Indeed, sbuild in backports is not not installable.

Indeed, I normally test all my packages, and I did this time too...
but I didn't realize I already had gnupg2 installed on stable (private
copy) and I trusted the last line of piuparts log without looking at
what was written a few lines above. Sorry for the mess.

> dkg, you had the intention to upload gnupg 2.1 to backports. Is there
> anything that's holding it?
>
> Lucas, could you upload a version of sbuild to BPO without this hard
> requirement, and maybe with the fix I suggested for the keygen thing?
> While not the definitive solution, this would fix it in the mean time.

If Daniel is willing to upload gnupg2, that would be cool! Otherwise
I'll try to see which other alternatives we have.

-- 
Cheers,
Luca

Bug#842496: [PKG-Openstack-devel] Bug#842496: Bug#842496: closed by Thomas Goirand (Re: neutron-fwaas-common: Missing /usr/bin/neutron-fwaas-l3-agent 'binary')

[Turbo Fredriksson]

On 3 Nov 2016, at 09:03, Thomas Goirand  wrote:

> I very much agree with the above, the only issue is enough time to put
> these warning in place. Maybe some text in a NEWS or README.Debian file
> could do the trick. I'm not so fan of adding debconf text for such a
> warning.

You need to TAKE the time! You can’t upload a package without testing (as in, 
does it work ‘from
scratch’ _AND_ (!!) does the upgrade from _at least_ the previous version work 
without any problem)
it properly and when you notice (or know!) of something that will affect users, 
then documenting that
properly (in a place where they’ll actually LOOK! :) needs to be done.

In a case like this, where the effect was MAJOR (basically, the whole network 
stopped working
because there was no L3 agent!), a debconf warning MUST be issued!!

It might just be something short like:

  The FWaaS binary have been removed because I don’t like you. Please read 
/usr/share/bla/bla
  for more information.

:)


Just imagine that people are actually using this in production and that their 
livelihood depends on this
working 24/7/365 and ANY disruption (other than the ‘normal’ restart of a 
service) can have dyer consequences.

Or in another way: What would YOU think/do if someone just shot your whole 
system to pieces??!

> Just configure Neutron. The doc from Red Hat seems to cover it well:
> 
> https://access.redhat.com/documentation/en/red-hat-enterprise-linux-openstack-platform/7/paged/networking-guide/chapter-16-configure-firewall-as-a-service-fwaas
> 
> Basically, you just use the "normal" neutron-l3-agent, and configure
> neutron.conf with:
> 
> service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin

Ok, thanx. I’ll try that.

Bug#843052: libterm-filter-perl: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:libterm-filter-perl
Version: 0.03-1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep
dh: Compatibility levels before 9 are deprecated (level 8 in use)
   dh_testdir -i
   dh_update_autotools_config -i
   dh_auto_configure -i
dh_auto_configure: Compatibility levels before 9 are deprecated (level 8 in use)
perl -I. Makefile.PL INSTALLDIRS=vendor
Checking if your kit is complete...
Looks good
Generating a Unix-style Makefile
Writing Makefile for Term::Filter
Writing MYMETA.yml and MYMETA.json
   dh_auto_build -i
dh_auto_build: Compatibility levels before 9 are deprecated (level 8 in use)
make -j1
make[1]: Entering directory '/<>'
cp lib/Term/Filter.pm blib/lib/Term/Filter.pm
cp lib/Term/Filter/Callback.pm blib/lib/Term/Filter/Callback.pm
Manifying 2 pod documents
make[1]: Leaving directory '/<>'
   dh_auto_test -i
dh_auto_test: Compatibility levels before 9 are deprecated (level 8 in use)
make -j1 test TEST_VERBOSE=1
make[1]: Entering directory '/<>'
PERL_DL_NONLAZY=1 PERL_USE_UNSAFE_INC=1 "/usr/bin/perl" 
"-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef 
*Test::Harness::Switches; test_harness(1, 'blib/lib', 'blib/arch')" t/*.t
t/00-compile.t  
1..2
ok 1 - Term::Filter loaded ok
ok 2 - Term::Filter::Callback loaded ok
ok
t/basic.t . 
ok 1
ok 2
ok 3
1..3
ok
t/callbacks.t . 
ok 1 - setup callback got a Term::Filter::Callback object
ok 2 - munge_input and munge_output got the right arguments
ok 3 - cleanup got the right arguments
1..3
ok
t/extra-pty.t . 
ok 1
ok 2
ok 3
ok 4
ok 5
ok 6
1..6
ok
t/release-eol.t ... skipped: these tests are for release candidate 
testing
t/release-no-tabs.t ... skipped: these tests are for release candidate 
testing
t/release-pod-coverage.t .. skipped: these tests are for release candidate 
testing
t/release-pod-syntax.t  skipped: these tests are for release candidate 
testing
t/requires-tty.t .. 
ok 1 - requires a terminal
ok 2 - requires a terminal
1..2
ok

#   Failed test 'munge_input and munge_output got the right arguments'
#   at t/role.t line 79.
#   'MUNGE_INPUT: My::Term::Filter=HASH(0x23a3110) 
(My::Term::Filter): fOo
# 
# MUNGE_OUTPUT: My::Term::Filter=HASH(0x23a3110) (My::Term::Filter): FOO

# 
# foo

# MUNGE_OUTPUT: My::Term::Filter=HASH(0x23a3110) (My::Term::Filter): FOO
# fooMUNGE_OUTPUT: My::Term::Filter=HASH(0x23a3110) (My::Term::Filter): 

# 
# 

# '
# doesn't match '(?^sx:
# ^
# MUNGE_INPUT: \s My\:\:Term\:\:Filter\=HASH\(0x23a3110\) \s 
\(My::Term::Filter\): \s fOo\n
# \n
# (?:
# MUNGE_OUTPUT: \s My\:\:Term\:\:Filter\=HASH\(0x23a3110\) \s 
\(My::Term::Filter\): \s FOO(?^:\x0d\x0a)
# \n
# foo(?^:\x0d\x0a)
# MUNGE_OUTPUT: \s My\:\:Term\:\:Filter\=HASH\(0x23a3110\) \s 
\(My::Term::Filter\): \s FOO(?^:\x0d\x0a)
# \n
# foo(?^:\x0d\x0a)
# |
# MUNGE_OUTPUT: \s My\:\:Term\:\:Filter\=HASH\(0x23a3110\) \s 
\(My::Term::Filter\): \s FOO(?^:\x0d\x0a) FOO(?^:\x0d\x0a)
# \n
# foo(?^:\x0d\x0a)
# foo(?^:\x0d\x0a)
# )
# $
# )'
# Looks like you failed 1 test of 3.
t/role.t .. 
ok 1 - setup callback got a My::Term::Filter object
not ok 2 - munge_input and munge_output got the right arguments
ok 3 - cleanup got the right arguments
1..3
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/3 subtests 

Test Summary Report
---
t/role.t(Wstat: 256 Tests: 3 Failed: 1)
  Failed test:  2
  Non-zero exit status: 1
Files=10, Tests=19, 16 wallclock secs ( 0.05 usr  0.01 sys +  2.60 cusr  0.23 
csys =  2.89 CPU)
Result: FAIL
Failed 1/10 test programs. 1/19 subtests failed.
Makefile:849: recipe for target 'test_dynamic' failed
make[1]: *** [test_dynamic] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 test TEST_VERBOSE=1 returned exit code 2
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


I'm attaching eight different build logs.

Thanks.

libterm-filter-perl.build.tar.gz
Description: application/gzip

Bug#843053: frog does not start

[Rahiel Kasim]

Package: frog
Version: 0.13.5-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

After installing the frog package, and executing frog on the command-line, I'm
greeted with the following error:

frog: symbol lookup error: /usr/lib/libfrog.so.1: undefined symbol: 
_ZNK5folia24AbstractStructureElement3strERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

and the program exits.


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

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

Versions of packages frog depends on:
ii  libc62.24-5
ii  libfolia41.4-1
ii  libfrog1 0.13.5-1
ii  libgcc1  1:6.2.0-10
ii  libgomp1 6.2.0-10
ii  libicu57 57.1-4
ii  libmbt1  3.2.16-1
ii  libstdc++6   6.2.0-10
ii  libticcutils2v5  0.14-1
ii  libtimbl46.4.8-1
ii  libucto2 0.9.3-1
ii  libxml2  2.9.4+dfsg1-2

Versions of packages frog recommends:
ii  ucto  0.9.3-1

frog suggests no packages.

-- no debconf information

Bug#842454: [debian-mysql] Bug#842454: default-libmysqlclient-dev is unsatisfiable for cross builds

[Helmut Grohne]

On Thu, Nov 03, 2016 at 11:05:16AM +0100, Andreas Beckmann wrote:
> I think you rather want
> 
> Architecture: all
> Multi-Arch: allowed

Sadly that's neither correct nor possible. M-A:allowed is not permitted
on Arch:all packages.

And even if it was allowed, it would be wrong. Consider source package
foo, which wants to link the mysql client library. If it Build-Depends:
default-libmysqlclient-dev, then its dependency is cross-unsatisfiable,
because no package provides default-libmysqlclient-dev for non-native
architectures. If it Build-Depends: default-libmysqlclient-dev:any, it
gets the build architecture library when it wanted the host architecture
library.

What you propose is so deeply wrong. Please use the original patch.

Helmut

Bug#842879: get start date from local VPS, not underlying actual computer

[Corey Wright]

no problem with linux-vserver here:

root@host:~# uname -r
3.10.104-vs2.3.6.9+1-amd64
root@host:~# uptime
 07:45:45 up 10 days,  7:57, 11 users,  load average: 0.54, 0.56, 0.65
root@host:~# vserver test start
Starting enhanced syslogd: rsyslogd.
Starting periodic command scheduler: crond.
root@host:~# vserver test enter
test:/# sleep 4& ps -eo pid,cmd,start_time,bsdstart,start,lstart,stime|grep 
sleep|grep -v grep 
[1] 6243
 6243 sleep 4 07:46  07:46 07:46:41 Thu Nov  3 07:46:41 
2016 07:46
test:/# date   
Thu Nov  3 07:46:54 CDT 2016
[1]+  Donesleep 4
test:/# ps aux|perl -awnle 'print $F[8]'|sort|uniq -c
  6 07:46  
  4 07:47  
  1 START  

corey
--
undefi...@pobox.com

Bug#842879: get start date from local VPS, not underlying actual computer

[積丹尼 Dan Jacobson]

Corey, what if you are the littlest of the little guys, not root?

Should I give you guys my password so you can go in and find what is
wrong?

Or are there any tests you would like me to run and send you the output of?

Bug#842994: [Pkg-zsh-devel] Bug#842994: Bug#842994: zsh-syntax-highlighting: shell flooded with error messages

[Daniel Shahaf]

Control: severity -1 normal
Control: forwarded -1 
https://github.com/zsh-users/zsh-syntax-highlighting/issues/252

raphael truc wrote on Thu, Nov 03, 2016 at 10:27:35 +0100:
> Indeed, I noticed I had aliased long time ago ! to sudo (which I forgot)

This is an artifact of using `source zsh-syntax-highlighting.zsh` to
load zsh-syntax-highlighting; using `autoload -U` would avoid aliases
in the calling scope being applied.  There already is an upstream issue
for that: https://github.com/zsh-users/zsh-syntax-highlighting/issues/252

Given that your alias changes the meaning of a shell syntax construct,
it would break _any_ plugin that's run by `source` [which is most of
them], not just z-sy-h.  Hence I'm demoting the severity.

I'm afraid the upstream fix is not entirely trivial, it is not scheduled
yet.  In the meantime, the workarounds available to you are either to
move the «!» inside the parentheses, or to define the alias _after_
loading z-sy-h.

Cheers,

Daniel

Bug#842879: get start date from local VPS, not underlying actual computer

[積丹尼 Dan Jacobson]

https://en.wikipedia.org/wiki/Linux-VServer#Disadvantages says
/proc is left unvirtualized.