Bug#774744: ITP: obs -- Open Broadcast Software

[Carl Fürstenberg]

Hello,

Back in February, I got som IRL issues, and frankly forgot about this; I've
no issue with having it under the multimedia team umbrella; I've uploaded
the code I made back then to https://github.com/azatoth/obs-studio and
rebased it only latest release; feel free to move it to DMT:s git repo if
you want to use this base.

Regards,

Carl

On 14 December 2015 at 20:50, Sebastian Ramacher 
wrote:

> Hi Carl
>
> On 2015-01-07 02:57:45, Carl Fürstenberg wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Carl Fürstenberg" 
> >
> > * Package name: obs
> >   Version : 0.7.2
> >   Upstream Author : Hugh Bailey 
> > * URL : https://obsproject.com/
> > * License : GPL
> >   Programming Lang: C, C++
> >   Description : Open Broadcast Software
> >
> > a rewrite of what was formerly known as "Open Broadcaster Software",
> > software originally designed for recording and streaming live
> > video content, efficiently.
>
> Thanks for packaging obs. What's the current status? Please let me know if
> you
> need any help with the package. I'd be happy to help. Since it would fit
> under
> the Multimedia Team umbrella, would you be interested in maintaining it
> within
> the team?
>
> Cheers
> --
> Sebastian Ramacher
>



-- 
Carl Fürstenberg

Bug#807943: game-data-packager: cannot make packages of large games

[Simon McVittie]

Control: tags 807943 unreproducible

On 14/12/15 16:13, Alam Arias wrote:
> ran the command:
> 
> game-data-packager --no-install --compress --verbose --debug doom3 Doom\ 3/ 
> 2>&1 | tee gdp.log
> 
> but the command failed, dpkg-deb return 'dpkg-deb: error: ar member size 
> 10892738560 too large'

g-d-p on your system is somehow trying to produce a .deb of around 10
gigabytes. I wonder how? doom3-data is "only" 1.5 gigabytes here, and
because g-d-p checksums every file, you shouldn't see any difference,
apart from small optional documentation files appearing or disappearing:

smcv@perpetual:~/tmp% ar tv doom3-data_43_all.deb
rw-r--r-- 0/0  4 Dec 14 23:18 2015 debian-binary
rw-r--r-- 0/0910 Dec 14 23:18 2015 control.tar.gz
rw-r--r-- 0/0 1556121600 Dec 14 23:18 2015 data.tar
smcv@perpetual:~/tmp% dpkg --fsys-tarfile doom3-data_43_all.deb | tar -tvf-
drwxr-xr-x root/root 0 2015-12-14 23:18 ./
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/share/
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/share/games/
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/share/games/doom3/
drwxr-xr-x root/root 0 2015-12-14 23:18
./usr/share/games/doom3/base/
-rw-r--r-- root/root192031 2015-10-22 23:51
./usr/share/games/doom3/base/pak007.pk4
-rw-r--r-- root/root 229649726 2015-10-22 23:08
./usr/share/games/doom3/base/pak001.pk4
-rw-r--r-- root/root 12243 2015-10-22 23:52
./usr/share/games/doom3/base/pak008.pk4
-rw-r--r-- root/root 317590154 2015-10-22 23:51
./usr/share/games/doom3/base/pak003.pk4
-rw-r--r-- root/root 353159257 2015-10-22 23:06
./usr/share/games/doom3/base/pak000.pk4
-rw-r--r-- root/root 416937674 2015-10-22 23:22
./usr/share/games/doom3/base/pak002.pk4
-rw-r--r-- root/root 237752384 2015-10-22 23:52
./usr/share/games/doom3/base/pak004.pk4
-rw-r--r-- root/root552334 2015-10-22 23:52
./usr/share/games/doom3/base/pak005.pk4
-rw-r--r-- root/root218751 2015-10-22 23:52
./usr/share/games/doom3/base/pak006.pk4
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/share/lintian/
drwxr-xr-x root/root 0 2015-12-14 23:18
./usr/share/lintian/overrides/
-rw-r--r-- root/root68 2015-12-14 23:18
./usr/share/lintian/overrides/doom3-data
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/share/doc/
drwxr-xr-x root/root 0 2015-12-14 23:18 ./usr/share/doc/doom3-data/
-rw-r--r-- root/root 17811 2015-10-22 23:52
./usr/share/doc/doom3-data/license.txt
-rw-r--r-- root/root  1142 2015-12-14 23:18
./usr/share/doc/doom3-data/copyright
-rw-r--r-- root/root 12070 2015-12-14 23:18
./usr/share/doc/doom3-data/changelog.gz

Similarly, your Quake 4 ends up at 20 gigabytes, which is weird, because
I get less than 3:

smcv@perpetual:~/tmp% ar tv quake4-data_1.4.2+43_all.deb
rw-r--r-- 0/0  4 Dec 14 23:27 2015 debian-binary
rw-r--r-- 0/0   8344 Dec 14 23:27 2015 control.tar.gz
rw-r--r-- 0/0 2866452480 Dec 14 23:27 2015 data.tar

> dpkg -l dpkg:
> ii  dpkg   1.17.25

Was this done on the correct system? You mentioned 1.18.3 on your other
bug report, and 1.17.25 is stable's version of dpkg, whereas the rest of
your packages seem to be from testing/unstable.

S

Bug#721976: Roots trusted for email but not TLS

[Andrew Ayer]

Hi Michael,

Have you given any more thought to a redesign of ca-certificates that
separates the email certificates from the TLS certificates?  I suspect
that the vast majority of packages that depend on ca-certificates use
it for TLS server auth, and yet there are currently 21 roots in the NSS
store that are trusted for email but distrusted for TLS server auth:

 1  AC Ra\xC3\xADz Certic\xC3\xA1mara S.A. 
 2  ComSign CA 
 3  Equifax Secure CA  (1024-bit)
 4  Equifax Secure Global eBusiness CA  (1024-bit)
 5  Equifax Secure eBusiness CA 1  (1024-bit)
 6  NetLock Business  (1024-bit)
 7  NetLock Express  (1024-bit)
 8  NetLock Qualified 
 9  S-TRUST Authentication and Encryption Root CA 2005 PN 
10  S-TRUST Universal Root CA 
11  Sonera Class 1 Root CA 
12  SwissSign Platinum CA - G2 
13  TC TrustCenter Class 3 CA II 
14  UTN USERFirst Email Root CA 
15  Verisign Class 1 Public Primary Certification Authority  (1024-bit)
16  Verisign Class 1 Public Primary Certification Authority - G2  (1024-bit)
17  Verisign Class 1 Public Primary Certification Authority - G3 
18  Verisign Class 2 Public Primary Certification Authority - G2  (1024-bit)
19  Verisign Class 2 Public Primary Certification Authority - G3 
20  Verisign Class 3 Public Primary Certification Authority  (1024-bit) 
(non-BR-compliant)
21  Verisign Class 3 Public Primary Certification Authority - G2  (1024-bit)

Ten of these are 1024-bit RSA roots.  Over the past year, Mozilla has
been removing the TLS trust bit from 1024-bit roots, and at long last
the NSS root store no longer contains any 1024-bit roots trusted for
TLS. Unfortunately, Debian applications continue to trust them for TLS.
This reduces the security of TLS authentication down to the cost of
factoring just one of these 1024-bit roots.  It would be great to bring
the security level of Debian's root store up to 2048 bits for TLS.

In addition, the "Verisign Class 3 Public Primary Certification
Authority" root (owned by Symantec) is still trusted despite its TLS
trust bit being removed in NSS.  As of December 1, 2015, this root is
being used to issue certificates that don't comply with the Baseline
Requirements:


https://googleonlinesecurity.blogspot.com/2015/12/proactive-measures-in-digital.html

As such, this root should be distrusted ASAP.

As always, let me know if you could use any help.  I'm going to start
looking through the reverse depends for ca-certificates to identify
packages that might be relying on roots for email authentication.

Thanks,
Andrew

Bug#807976: appstream puts garbage on aptitude screen

[Matthias Klumpp]

2015-12-15 1:01 GMT+01:00 Vincent Lefevre :
> Package: appstream
> Version: 0.9.0-1
> Severity: normal
>
> In aptitude (curses UI), when I do an update ('u'), I get the
> following message:
>
>   AppStream cache update completed successfully.
>
> and the aptitude screen is not correctly redrawn (probably because
> aptitude doesn't expect a message).

Hmm, not sure what to do here: I left the generator print a message
about the cache on purpose, so we can see that people have AppStream
enabled and spot bugs or performance issues with it easily, especially
since AppStream is new to Debian.
So, I could make AppStream quiet here, effectively hiding that it is
active from all users, or aptitude could be changed to not break the
UI if additional messages appear.
IMHO the latter should be done regardless of whether AppStream shows
messages or not, since basically anything can insert messages there,
so this could break more often in future.

Cheers,
Matthias

Bug#806239: Updating ca-certificates through stable-updates

[Michael Shuler]

On 12/14/2015 06:22 PM, Andrew Ayer wrote:
> I'm curious why the 2.6 update wasn't included with the 20151204
> release.

Thanks.

Thijs and/or Raphael. Please, hold until some additional changes can be
committed to include 2.6.

NSS released 2.6 while working on 2.5, essentially, Andrew.

-- 
Michael

Bug#796294: tgif: diff for NMU version 1:4.2.5-1.3

[Carlo Segre]

This is fine.  I am not sure when I will get to updating the package.

Carlo

On Mon, 14 Dec 2015, Mattia Rizzolo wrote:


Control: tags 796294 + patch
Control: tags 796294 + pending

Dear maintainer,

I've prepared an NMU for tgif (versioned as 1:4.2.5-1.3) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards.




--
Carlo U. Segre -- Duchossois Leadership Professor of Physics
Director, Center for Synchrotron Radiation Research and Instrumentation
Illinois Institute of Technology
Voice: 312.567.3498Fax: 312.567.3494
se...@iit.edu   http://phys.iit.edu/~segre   se...@debian.org

Bug#796294: tgif: diff for NMU version 1:4.2.5-1.3

[Mattia Rizzolo]

On Mon, Dec 14, 2015 at 06:13:26PM -0600, Carlo Segre wrote:
> This is fine.  I am not sure when I will get to updating the package.

Oh, this is cool, thanks :)

Then I rescheduled the NMU to a 0-day.

Thank for being so well-disposed!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#787925: RM: python-uniconvertor -- RoQA; unmaintained, RC buggy

[Mattia Rizzolo]

control: tag -1 - moreinfo

On Tue, Jun 23, 2015 at 09:04:21AM +0200, Luca Falavigna wrote:
> Not ready yet:
> 
> # Broken Depends:
> tgif: tgif

I uploaded today a tgif removing the dep, python-uniconvertor can go
away as soon as it is built and dak gets rid of the old version.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#807875: tracker.d.o can show the whole description where it's supposed to show only the short

[Mattia Rizzolo]

On Mon, Dec 14, 2015 at 05:25:10PM +0100, Raphael Hertzog wrote:
> On Mon, 14 Dec 2015, Mattia Rizzolo wrote:
> > Could be that the original importer had a bug that's got fixed meanwhile
> > and the description got fixed by my NMU yesterday?  (just
> 
> Oh, yes, definitely. Thanks for the explanation. So closing the bug now.

BTW, attached another example with syslog-summary, I'm going to NMU it,
I'll hold it off till tomorrow so you can have a look at it, if you
want.


-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#805634: tbl: please test fixed package for jessie (Re: Bug#805634: jessie-pu: torbrowser-launcher/0.2.2-2~deb8u1

[Holger Levsen]

Hi Adam,

On Montag, 14. Dezember 2015, Adam D. Barratt wrote:
> Other than intrigeri's query r.e. AppArmor, was there any useful
> feedback from that?

there was no other feedback, no.


cheers,
Holger


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

Bug#807984: xfce4-sensors-plugin: Sensors plugin crashes when using hard disk monitoring with setuid hddtemp

[oldtechaa]

Package: xfce4-sensors-plugin
Version: 1.2.5-2
Severity: normal

Dear Maintainer,

The xfce sensors plugin crashes and leaves the panel when hard disk monitoring
is enabled on Jessie. In order to use hard disk monitoring, I obviously had to
setuid hddtemp. I know the setuid hddtemp issue has been corrected in the newer
version, but I have reasons not to update, and I don't know if that would fix
the problem. I can post a log (that doesn't tell much) if you like, and can
give the information about the hard disks I'm using. Without hard disk sensors
displaying, it works fine.



-- System Information:
Debian Release: 8.2
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-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 xfce4-sensors-plugin depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u1
ii  libcairo21.14.0-2.1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u2
ii  libglib2.0-0 2.42.1-1
ii  libgtk2.0-0  2.24.25-3
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsensors4  1:3.3.5-2
ii  libxfce4ui-1-0   4.10.0-6
ii  libxfce4util64.10.1-2
ii  xfce4-panel  4.10.1-1

Versions of packages xfce4-sensors-plugin recommends:
ii  hddtemp 0.3-beta15-52
ii  lm-sensors  1:3.3.5-2

Versions of packages xfce4-sensors-plugin suggests:
pn  xsensors  

-- no debconf information

Bug#807977: ITP: libtabixpp -- C++ wrapper to tabix indexer

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: libtabixpp
  Version : 1.0.0 
  Upstream Author : Erik Garrison 
* URL : https://github.com/ekg/tabixpp
* License : MIT
  Programming Lang: C++
  Description : C++ wrapper to tabix indexer

Tabix indexes files where some columns indicate sequence coordinates: name
(usually a chromosome), start and stop. The input data file must be position
sorted and compressed by bgzip. After indexing, tabix is able to quickly 
retrieve data lines by chromosomal coordinates.
This package provides a C++ wrapper to the tabix indexer.

This is packaged as a dependency for REAPR and will be maintained the Debian
Med packaging team.

Bug#807843: imms: FTBFS against audacious 3.6

[Sebastian Ramacher]

Control: tags -1 + patch

On 2015-12-13 18:54:25, Sebastian Ramacher wrote:
> Source: imms
> Version: 3.1.0~svn301-3.1
> Severity: important
> 
> imms FTBFS against audacious-dev 3.6.2-1 (currently in NEW):
> | checking for audacious... no
> | checking for dbus_glib... yes
> | checking audacious/plugin.h usability... no
> | checking audacious/plugin.h presence... no
> | checking for audacious/plugin.h... no
> | configure: error: Not building audacious plugin
> | make: *** [configure-stamp] Error 1
> | debian/rules:38: recipe for target 'configure-stamp' failed
> | dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> For the full build log see
> https://people.debian.org/~sramacher/logs/imms_3.1.0~svn301-3.1_amd64-20151213-1845.log

The new upstream maintainer included a patch to port imms to Audacious 3.6+ [1].
See the attached debdiff for details.

Cheers

[1] 
https://github.com/martingkelly/imms/commit/f4c1da73bf6463f17669faf73c64898b69253d08
-- 
Sebastian Ramacher
diff -Nru imms-3.1.0~svn301/debian/changelog imms-3.1.0~svn301/debian/changelog
--- imms-3.1.0~svn301/debian/changelog	2014-09-10 10:55:51.0 +0200
+++ imms-3.1.0~svn301/debian/changelog	2015-12-15 01:35:10.0 +0100
@@ -1,3 +1,12 @@
+imms (3.1.0~svn301-3.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/control: Tighten audacious-dev in Build-Depends to (>= 3.6).
+  * debian/patches/audacious-3.6.patch: Upstream patch to port imms to
+Audacious 3.6+ (Closes: #807843)
+
+ -- Sebastian Ramacher   Tue, 15 Dec 2015 01:33:55 +0100
+
 imms (3.1.0~svn301-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru imms-3.1.0~svn301/debian/control imms-3.1.0~svn301/debian/control
--- imms-3.1.0~svn301/debian/control	2014-09-10 10:52:55.0 +0200
+++ imms-3.1.0~svn301/debian/control	2015-12-15 01:31:47.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Artur R. Czechowski 
 Standards-Version: 3.9.4
 Homepage: http://imms.luminal.org/
-Build-Depends: debhelper (>> 5.0.0), audacious-dev (>= 3.5), libsqlite3-dev (>=3.2.2), libpcre3-dev (>=4.3), libtag1-dev, libvorbis-dev (>=1.0), libfftw3-dev, libglib2.0-dev, zlib1g-dev, libxss-dev, libtorch3-dev, libglade2-dev, autoconf, automake, xsltproc, docbook-xsl, libaudclient-dev
+Build-Depends: debhelper (>> 5.0.0), audacious-dev (>= 3.6), libsqlite3-dev (>=3.2.2), libpcre3-dev (>=4.3), libtag1-dev, libvorbis-dev (>=1.0), libfftw3-dev, libglib2.0-dev, zlib1g-dev, libxss-dev, libtorch3-dev, libglade2-dev, autoconf, automake, xsltproc, docbook-xsl, libaudclient-dev
 
 Package: imms-common
 Architecture: any
diff -Nru imms-3.1.0~svn301/debian/patches/audacious-3.6.patch imms-3.1.0~svn301/debian/patches/audacious-3.6.patch
--- imms-3.1.0~svn301/debian/patches/audacious-3.6.patch	1970-01-01 01:00:00.0 +0100
+++ imms-3.1.0~svn301/debian/patches/audacious-3.6.patch	2015-12-15 01:33:37.0 +0100
@@ -0,0 +1,338 @@
+Description: Port to Audacious 3.6+
+Origin: upstream,
+ https://github.com/martingkelly/imms/commit/f4c1da73bf6463f17669faf73c64898b69253d08
+Bug-Debian: https://bugs.debian.org/807843
+Last-Update: 2015-12-15
+
+--- imms-3.1.0~svn301.orig/clients/audacious/audplugin.cc
 imms-3.1.0~svn301/clients/audacious/audplugin.cc
+@@ -24,56 +24,77 @@
+ #include 
+ #include 
+ 
+-extern "C" {
+-#include 
+-#include 
+-#include 
+ #include 
+-#include 
+-#include 
+-}
++#include 
++#include 
++#include 
++#include 
++#include 
+ 
+ #include "immsconf.h"
+-#include "cplugin.h"
+ #include "immsutil.h"
+ #include "clientstub.h"
+ 
++#define USE_XIDLE true
++
+ using std::string;
+-using std::cerr;
+-using std::endl;
++
++class IMMSPlugin : public GeneralPlugin
++{
++public:
++static const char about[];
++
++static constexpr PluginInfo info = {
++"IMMS",
++nullptr,
++about
++};
++
++constexpr IMMSPlugin() : GeneralPlugin(info, false) {}
++
++bool init();
++void cleanup();
++};
++
++IMMSPlugin aud_plugin_instance;
++
++const char IMMSPlugin::about[] =
++"Intelligent Multimedia Management System\n\n"
++"IMMS is an intelligent playlist plugin for Audacious that tracks your "
++"listening patterns and dynamically adapts to your taste.\n\n"
++"It is incredibly unobtrusive and easy to use as it requires no direct "
++"user interaction.\n\n"
++"For more information please visit:\n"
++"http://www.luminal.org/wiki/index.php/IMMS\n\n;
++"Written by Michael \"mag\" Grigoriev ";
+ 
+ // Local vars
++static QueuedFunc timer;
++
+ int cur_plpos, next_plpos = -1, pl_length = -1,
+ last_plpos = -1, last_song_length = -1;
+ int good_length = 0, song_length = 0,
+-busy = 0, just_enqueued = 0, ending = 0;
+-bool shuffle = true, select_pending = false, xidle_val = false;
++just_enqueued = 0, ending = 0;
++bool shuffle = true, select_pending = false;
+ 
+ string cur_path = "", last_path = "";
+ 
++static void 

Bug#721976: Roots trusted for email but not TLS

[Andrew Ayer]

On Mon, 14 Dec 2015 18:45:40 -0600
Michael Shuler  wrote:

> > As always, let me know if you could use any help.  I'm going to
> > start looking through the reverse depends for ca-certificates to
> > identify packages that might be relying on roots for email
> > authentication.
> 
> Exactly. I also do not know if pointing mail-related CAs to another
> filesystem location and patching mail-related packages to look there
> is sufficient - are there mail clients/utilities that also open https
> web urls?

It wouldn't be a question of HTTPS connections, but rather TLS
connections to IMAP, POP, and SMTP servers, which most MUAs will make.
MUAs that implement S/MIME should use separate trust stores for TLS and
S/MIME (or have some other way to distinguish between roots) and MUAs
that don't are buggy.  I would be interested in patching such MUAs,
although this would be a long-term effort.

Fortunately, there is a simple short-term solution that could be
implemented immediately and would provide a security improvement to the
majority of Debian users without removing any functionality: ship the
email-only roots in a separate package.  I suspect that only a small
minority of Debian users use S/MIME, whereas a large majority of users
use wget, curl, git, etc. with HTTPS, or MUAs with secure SMTP/IMAP/POP
(but not S/MIME).  The minority can install the S/MIME roots and have
the same security and functionality as now, while the majority
will benefit from better security.  Is this an acceptable solution
pending a long-term effort to assess and improve trust store handling
in MUAs?

Regards,
Andrew

Bug#807980: libevdocument3-4: Fails to install without specifying an error

[Wayne Rowcliffe]

Package: libevdocument3-4
Version: 3.18.2-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I had an upgrade that failed to complete. It said evince was partially
installed. So I ran `apt-get install -f` and the problem persisted.

I ran `apt-get remove libevdocument3-4 evince libevview3-3` and was then
able to complete the upgrade and afterwards install several other
packages.

I then tried to reinstall evince.

apt-get install evince
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  libevdocument3-4 libevview3-3

The following NEW packages will be installed:
  evince libevdocument3-4 libevview3-3
0 upgraded, 3 newly installed, 0 to remove and 0 not
upgraded.
Need to get 0 B/2,304 kB of archives.
After this operation, 3,591 kB of additional disk space will
be used.
Do you want to continue? [Y/n] y
(Reading database ... 311103 files and directories currently
installed.)
Preparing to unpack .../libevdocument3-4_3.18.2-1_amd64.deb

Unpacking libevdocument3-4 (3.18.2-1) over (3.18.2-1) ...
Selecting previously unselected package libevview3-3.
Preparing to unpack .../libevview3-3_3.18.2-1_amd64.deb ...
Unpacking libevview3-3 (3.18.2-1) ...
Selecting previously unselected package evince.
Preparing to unpack .../evince_3.18.2-1_amd64.deb ...
Unpacking evince (3.18.2-1) ...
Processing triggers for libc-bin (2.19-22) ...
Setting up libevdocument3-4 (3.18.2-1) ...
Setting up libevview3-3 (3.18.2-1) ...
Setting up evince (3.18.2-1) ...
Processing triggers for libc-bin (2.19-22) ...

That seemed to be successful.

However:

apt-get install
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
 evince : Depends: libevdocument3-4 (= 3.18.2-1) but it is not installed
 libevview3-3 : Depends: libevdocument3-4 (>= 3.18.0) but it is not
 installed
E: Unmet dependencies. Try using -f.

and

apt-cache policy libevdocument3-4
libevdocument3-4:
  Installed: (none)
  Candidate: 3.18.2-1
  Version table:
 3.18.2-1 700
   700 http://ftp.us.debian.org/debian testing/main amd64 Packages
   650 http://ftp.us.debian.org/debian unstable/main amd64 Packages

I am not sure what the issue is but I filed it under evince since that
is the package causing me issues.

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

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

Versions of packages libevdocument3-4 depends on:
ii  libarchive13 3.1.2-11+b1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo-gobject21.14.4-1
ii  libcairo21.14.4-1
ii  libdjvulibre21   3.5.27.1-5
ii  libgcc1  1:5.2.1-23
ii  libgdk-pixbuf2.0-0   2.32.2-1
ii  libglib2.0-0 2.46.2-1
ii  libgtk-3-0   3.18.5-1
ii  libgxps2 0.2.3.2-1
ii  libkpathsea6 2015.20150524.37493-7
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpoppler-glib8 0.26.5-4
ii  libspectre1  0.2.7-3
ii  libstdc++6   5.2.1-23
ii  libtiff5 4.0.5-1
ii  libxml2  2.9.2+zdfsg1-4
ii  zlib1g   1:1.2.8.dfsg-2+b1

libevdocument3-4 recommends no packages.

libevdocument3-4 suggests no packages.

-- no debconf information

Bug#807979: [Debian-med-packaging] Bug#807979: bamtools cannot open bam files on big endian systems

[Dominique Belhachemi]

Control: severity -1 grave

The package is useless on big endian systems if it cannot even open a bam file.

Please add a test case to the package, so it would FTBFS immediately.

Best
-Dominique

Bug#807849: nghttp2: cross Build-Depends unsatisfiable

[Tomasz Buchert]

On 14/12/15 06:43, Helmut Grohne wrote:
> Hi Tomasz,
> 
> On Sun, Dec 13, 2015 at 11:22:26PM +0100, Tomasz Buchert wrote:
> > I'll be happy to use your patch, of course. Could you tell me how I
> > can test this cross-building before?
> 
> Given the availability of readily working cross toolchains in unstable
> and the recent improvements on sbuild in unstable, the easiest way
> probably is to build your package with sbuild while adding
> --build=$your_native_arch --host=$some_other_arch. That should just work
> after adding my patch. If it doesn't, please complain at one of:
>  * Me.
>  * debian-cross@l.d.o
>  * #d-bootstrap (oftc)

Thanks, I'll try this. However, I have problems building nghttp2 with
"gbp buildpackage --git-pbuilder" (standard, non-cross build):

[.]
I: Building the package
W: execute priv not set on file A10set_ccache_options, not executing.
I: Running cd /build/*/ && env PATH="/usr/sbin:/usr/bin:/sbin:/bin" 
HOME="/nonexistent" dpkg-buildpackage -us -uc -rfakeroot
dpkg-buildpackage: source package nghttp2
dpkg-buildpackage: source version 1.5.0-2
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Tomasz Buchert 
 dpkg-source --before-build nghttp2-1.5.0
 dpkg-buildpackage: host architecture amd64
 dpkg-checkbuilddeps: error: Unmet build dependencies: python-sphinx:native
 dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
 dpkg-buildpackage: warning: (Use -d flag to override.)

It seems that python-sphinx:native does not work very well with pbuilder?

> 
> That said, nghttp2 will soon be cross built by rebootstrap[1] on a daily
> basis.

Ok.

Cheers,
Tomasz


signature.asc
Description: PGP signature

Bug#807976: appstream puts garbage on aptitude screen

[Vincent Lefevre]

Package: appstream
Version: 0.9.0-1
Severity: normal

In aptitude (curses UI), when I do an update ('u'), I get the
following message:

  AppStream cache update completed successfully.

and the aptitude screen is not correctly redrawn (probably because
aptitude doesn't expect a message).

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

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

Versions of packages appstream depends on:
ii  libappstream30.9.0-1
ii  libc62.21-4
ii  libglib2.0-0 2.46.2-1
ii  libprotobuf-lite9v5  2.6.1-1.3
ii  libxapian22v51.2.21-1.2
ii  libxml2  2.9.3+dfsg1-1
ii  libyaml-0-2  0.1.6-3

appstream recommends no packages.

appstream suggests no packages.

-- no debconf information

Bug#807929: syntax/gitrebase.vim: doesn't highlight "drop"

[James McCoy]

On Mon, Dec 14, 2015 at 03:41:23PM +0100, Jakub Wilk wrote:
> syntax/gitrebase.vim doesn't highlight the "drop" keyword.
> Patch attached.

Already fixed in vim-git upstream[0].  Just needs to be pulled into vim.
I'll nudge tpope.

[0]: 
https://github.com/tpope/vim-git/commit/602cf46a54e33cde55bbe8a466c33ecb6239cff1

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 

Bug#807976: appstream puts garbage on aptitude screen

[Matthias Klumpp]

Forget what I said, appstreamcli will always write to stdout, and
there is little aptitude can do about that, so this needs to be solved
in AppStream.
I wonder if I can detect the curses interface somehow...
If not, the refresh command will be quiet with the next release.

Cheers,
Matthias

Bug#807930: TEMP-0000000-166C73 code execution via improper escaping of ; in foomatic-rip

[Till Kamppeter]

On 12/14/2015 01:30 PM, Didier 'OdyX' Raboud wrote:

I'm likely to wait for 1.4.0 upstream release for an upload to unstable,
and will then prepare the package for jessie (if the Security Team
agrees).


I have 1.4.0 released upstream now, including the fix. I have also 
updated the Debian packaging on the Debian GIT repository now, so that 
the package is ready for upload.


   Till

Bug#807924: ghc: empty haddock interface version on hurd-i386

[Samuel Thibault]

Joachim Breitner, on Mon 14 Dec 2015 16:43:22 +0100, wrote:
> I don’t know off-hand by what mechanism the build system ensures
> that these are found, but I’d bet on rpath. Does hurd handle rpaths
> differently?

It does support rpath.  ghc apparently uses $ORIGIN in rpath.  IIRC we
added some support for that, perhaps it's not enough.

Samuel

Bug#807978: kdenlive: Please package new upstream version for crash when deleting tracks

[Kingsley G. Morse Jr.]

Package: kdenlive
Version: 15.08.3-1
Severity: normal
Tags: upstream

Hi Patrick,

Thank you very much for maintaining Debian's
packages of kdenlive.

Evidently Jean-Baptiste Mardelle fixed a crash
while deleting tracks a few days ago.

It is reported at

https://bugs.kde.org/show_bug.cgi?id=356313

Please create a package with Jean's new code for
Debian's unstable distribution.

Thanks,
Kingsley

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

Kernel: Linux 4.2.0-1-686-pae (SMP w/2 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: systemd (via /run/systemd/system)

Versions of packages kdenlive depends on:
ii  ffmpeg7:2.8.3-1
ii  kded5 5.15.0-1
ii  kdenlive-data 15.08.3-1
ii  kinit 5.15.0-1
ii  kio   5.15.0-1
ii  libc6 2.21-4
ii  libgcc1   1:5.3.1-3
ii  libgl1-mesa-glx [libgl1]  11.0.7-1
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libkf5archive55.16.0-1
ii  libkf5attica5 5.16.0-1
ii  libkf5auth5   5.16.0-1
ii  libkf5bookmarks5  5.16.0-1
ii  libkf5codecs5 5.16.0-1
ii  libkf5completion5 5.16.0-1
ii  libkf5configcore5 5.16.0-1
ii  libkf5configgui5  5.16.0-1
ii  libkf5configwidgets5  5.16.0-1
ii  libkf5coreaddons5 5.16.0-1
ii  libkf5dbusaddons5 5.16.0-1
ii  libkf5guiaddons5  5.16.0-1
ii  libkf5i18n5   5.16.0-1
ii  libkf5iconthemes5 5.16.0-1
ii  libkf5itemviews5  5.16.0-1
ii  libkf5jobwidgets5 5.16.0-1
ii  libkf5kiocore55.16.0-1
ii  libkf5kiofilewidgets5 5.16.0-1
ii  libkf5kiontlm55.16.0-1
ii  libkf5kiowidgets5 5.16.0-1
ii  libkf5newstuff5   5.16.0-1
ii  libkf5notifications5  5.16.0-1
ii  libkf5notifyconfig5   5.16.0-1
ii  libkf5plotting5   5.16.0-1
ii  libkf5service-bin 5.16.0-1
ii  libkf5service55.16.0-1
ii  libkf5solid5  5.16.0-1
ii  libkf5sonnetui5   5.16.0-1
ii  libkf5textwidgets55.16.0-1
ii  libkf5widgetsaddons5  5.16.0-1
ii  libkf5xmlgui5 5.16.0-1
ii  libmlt++3 0.9.8-3
ii  libmlt6   0.9.8-3
ii  libqt5concurrent5 5.5.1+dfsg-8
ii  libqt5core5a  5.5.1+dfsg-8
ii  libqt5dbus5   5.5.1+dfsg-8
ii  libqt5gui55.5.1+dfsg-8
ii  libqt5network55.5.1+dfsg-8
ii  libqt5qml55.5.1-3
ii  libqt5quick5  5.5.1-3
ii  libqt5script5 5.5.1+dfsg-2
ii  libqt5svg55.5.1-2
ii  libqt5widgets55.5.1+dfsg-8
ii  libqt5xml55.5.1+dfsg-8
ii  libstdc++65.3.1-3
ii  libv4l-0  1.8.0-1
ii  melt  0.9.8-3
ii  qml-module-qtquick2   5.5.1-3

Versions of packages kdenlive recommends:
ii  dvdauthor0.7.0-1.3
ii  dvgrab   3.5-2+b3
ii  frei0r-plugins   1.4-3+b1
ii  genisoimage  9:1.1.11-3
ii  recordmydesktop  0.3.8.1+svn602-1+b1
ii  swh-plugins  0.4.15+1-8

Versions of packages kdenlive suggests:
ii  khelpcenter  4:5.4.2-1

-- no debconf information

Bug#783615: "update-ca-certificates --fresh" doesn't correctly re-add certificates in /usr/local/share/ca-certificates

[Michael Shuler]

Control: tags -1 + pending

Committed to master for next upload. Thanks, Daniel!

-- 
Kind regards,
Michael

Bug#807979: bamtools cannot open bam files on big endian systems

[Dominique Belhachemi]

Package: bamtools
Version: 2.4.0+dfsg-2
Severity: grave


This bug affects big endian systems (mips, powerpc, ...) . It is not
possible to handle bam files.

Here is a quick test case:

$ bamtools count -in test.bam
bamtools count ERROR: could not open input BAM file(s)... Aborting.


I filed a bug report upstream with a detailed explanation.
https://github.com/pezmaster31/bamtools/issues/113


Best
-Dominique

Bug#807979: [Debian-med-packaging] Bug#807979: bamtools cannot open bam files on big endian systems

[Afif Elghraoui]

Control: severity -1 important
Control: forwarded -1 https://github.com/pezmaster31/bamtools/issues/113


Hi, Dominique,

على الإثنين 14 كانون الأول 2015 ‫18:09، كتب Dominique Belhachemi:
> Package: bamtools
> Version: 2.4.0+dfsg-2
> Severity: grave
> 
> 
> This bug affects big endian systems (mips, powerpc, ...) . It is not
> possible to handle bam files.
>

I'm reducing the severity because it does not appear to affect *all*
users (only users on a subset of architectures) based on your description.

Many thanks for your bug report

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#807982: ITP: undercover-el -- a test coverage library for Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: undercover-el
  Version : 0.5.0
  Upstream Author : Sviridov Alexander 
* URL : https://github.com/sviridov/undercover.el
* License : MIT
  Programming Lang: Emacs Lisp
  Description : a test coverage library for Emacs

undercover.el is a test coverage library for Emacs Lisp.  I'm
packaging it for use in running the tests for f-el, another ITP of
mine.

I intend to maintain it as part of the pkg-emacsen team.

Bug#807981: ITP: shut-up -- Emacs Lisp macros to quieten Emacs

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: shut-up
  Version : 0.3.2
  Upstream Author : Johan Andersson 
* URL : https://github.com/cask/shut-up
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : Emacs Lisp macros to quieten Emacs

This package provides several macros to quieten Emacs output.

I am packaging it as a dependency of undercover.el, another ITP of mine.

Bug#807975: RM: rtai -- RoQA; RC buggy, FTBFS, marginal popcon, depends on old libs

[Mattia Rizzolo]

Package: ftp.debian.org
X-Debbugs-Cc: r...@packages.debian.org

The old lib is python-support, it also FTBFS on amd64, even if it's not
reported.

It's not in stable.

Thanks.
-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#806239: Updating ca-certificates through stable-updates

[Andrew Ayer]

On Fri, 4 Dec 2015 23:36:57 -0600
Michael Shuler  wrote:
 
> Hi release team,
> 
> I just requested an upload of ca-certificates (20151204) to unstable,
> and I would like to follow that up with stable-pu and oldstable-pu
> updates to include the current Mozilla CA bundle changes for jessie
> and wheezy.

Hi Michael,

I'm curious why the 2.6 update wasn't included with the 20151204
release.

I've been told that one of the roots that was removed in the 2.6 update
is going to be used by the CA to issue certificates that violate the
Baseline Requirements[1].  It would be nice for Debian to stop trusting
it before the CA starts doing this.

Thanks,
Andrew

[1] This root is in addition to the Symantec root I mentioned in
#721976. Indeed, multiple CAs are doing this, which underscores the
need for timely root store updates.

Bug#721976: Roots trusted for email but not TLS

[Michael Shuler]

On 12/14/2015 06:18 PM, Andrew Ayer wrote:
> Hi Michael,
> 
> Have you given any more thought to a redesign of ca-certificates that
> separates the email certificates from the TLS certificates?  I suspect

Yep - got a patch?  :-)

> that the vast majority of packages that depend on ca-certificates use
> it for TLS server auth

Got patches for all the mail-related rdeps of ca-certificates?  :-)

I have not gone through every rdep package to cound, but there are quite
a few mail-related pacakges, so they should each have some new
filesystem location to search for mail-specific CA certificates.

> As always, let me know if you could use any help.  I'm going to start
> looking through the reverse depends for ca-certificates to identify
> packages that might be relying on roots for email authentication.

Exactly. I also do not know if pointing mail-related CAs to another
filesystem location and patching mail-related packages to look there is
sufficient - are there mail clients/utilities that also open https web urls?

-- 
Kind regards,
Michael

Bug#807852: aptitude fails when home dir does not exist (sbuild)

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2015-12-13 19:19 Vagrant Cascadian:

Package: aptitude
Version: 0.7.5-2
Severity: important

In a clean sid schroot, aptitude fails when the homedir doesn't exist:

# HOME=/nonexistant/ aptitude install bash
E: Could not create directory: /nonexistant//.cache: boost::filesystem::create_directory: 
No such file or directory: "/nonexistant//.cache"


This causes sbuild with schroot to using the aptitude backend to fail,
as it sets HOME=/sbuild-nonexistent.


Thanks for the report.

This is fixed in VCS, to be released soon (either as a Debian revision
or as new upstream), so marking as +pending.


@Axel: if you are reading this and it becomes critical in the next few
  days, when I might be slow to react, you can release at least a
  Debian revision with the patch -- I think that it is safe.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#807875: tracker.d.o can show the whole description where it's supposed to show only the short

[Raphael Hertzog]

On Tue, 15 Dec 2015, Mattia Rizzolo wrote:
> BTW, attached another example with syslog-summary, I'm going to NMU it,
> I'll hold it off till tomorrow so you can have a look at it, if you
> want.

I fixed the database:

for p in BinaryPackage.objects.filter(short_description__contains='\n'):
p.short_description = p.short_description.split('\n', 1)[0]
p.save()

It now looks good everywhere. :)

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#807875: tracker.d.o can show the whole description where it's supposed to show only the short

[Mattia Rizzolo]

On Tue, Dec 15, 2015 at 02:10:29AM +0100, Raphael Hertzog wrote:
> On Tue, 15 Dec 2015, Mattia Rizzolo wrote:
> > BTW, attached another example with syslog-summary, I'm going to NMU it,

turned out I forgot to attach it, meh

> I fixed the database:
> 
> for p in BinaryPackage.objects.filter(short_description__contains='\n'):
> p.short_description = p.short_description.split('\n', 1)[0]
> p.save()
> 
> It now looks good everywhere. :)

oh, cool!

Thanks so much! :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#807924: ghc: empty haddock interface version on hurd-i386

[Samuel Thibault]

Samuel Thibault, on Tue 15 Dec 2015 00:53:48 +0100, wrote:
> Joachim Breitner, on Mon 14 Dec 2015 16:43:22 +0100, wrote:
> > I don’t know off-hand by what mechanism the build system ensures
> > that these are found, but I’d bet on rpath. Does hurd handle rpaths
> > differently?
> 
> It does support rpath.  ghc apparently uses $ORIGIN in rpath.  IIRC we
> added some support for that, perhaps it's not enough.

No, some patches exist, but they have not been commited, so $ORIGIN is
not supported yet.

Samuel

Bug#769366: Zssh needs to be reompiled after upgrade

[Emmanuel Lacour]

I just been hited by this bug this WE, same "Out of pty's" message after
an upgrade on sid.

I just rebuilded the package without changes and it works again...

Bug#807728: 0.76 didn't fix it for me

[Hans-Christoph Steiner]

I'm also affected by this issue using cowbuilder 0.75.  Updating to 0.76
did not fix it.  This did:

sudo cowbuilder --login --save-after-login
# mkdir -p /home/hans/.cache

Here's the error:
Setting up pbuilder-satisfydepends-dummy (0.invalid.0) ...
E: Could not create directory: /home/hans/.cache:
boost::filesystem::create_directory: No such file or directory:
"/home/hans/.cache"
E: pbuilder-satisfydepends failed.



To reproduce it, I did:
sudo cowbuilder --login --save-after-login
# rm -rf /home/hans

Bug#807897: ITP: ruby-rails-assets-chartjs -- provide Chart.js via rails asset pipeline

[Pirate Praveen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

package: wnpp
severity: wishlist
owner: Pirate Praveen 

from rails-assets.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWboqmAAoJEM4fnGdFEsIqXoAP/35yIEYQc1BrGQ0AKIdmzeZF
KIsedIjw5lBnbvJDHRGq8GugIkwacSaojv1BkTfzObWqXbqM1U8Ea5RvRj4Rx5dJ
+I1KW+CEpvBzcA8T632z2vap2YBmqUTQWWJkit32shldx1iO0lV3o1NjyotxKuzx
m6+eGkocmMPVV7HUQA9mENx9sDaT7wNrsg2eqyMaSC0h7FV5bbL80cOIBUNNYyfM
LcmfmCLXjtOOSKq11TnZtuffdgyfXqwPdIziV9CCK6BTz0H8gClixKzOPDoWu42A
TXNDkTEHA4FMag3dRmz66qJca1yLEWTvKmpJe7FGYYoPw1GAe3ar/eK1lh1Thc80
Z/s3XjdfTZkrBWePqQsyijNdb9FTWF2iqqT2kWpXJTswUtiHyKibp5u/Bh83CW3V
H7d5o/IgHP3ubNwjuRah0AvP0XSX8mfzHIcyGhRM9NCz/3c12Bj/mfniMw6+JoE5
n5Zzxm768xI/1VfJulq/pwa7i5r7T9Gh7t85TR6CjN1pEaszrQnkhPxo14yWXNDA
E+4WIf66Xjohi/EiC84ovyIl1DFlzm25TeqE+psE85/ajK62ibx/mmjVDXrMsg4o
bL6R4BlK9NylR58mFzUWNkFgVfnwb6jpK/T9Q7P7h/LauyOYlIA8++oSL4wVkKDP
1W0Abx/APgDbYB7kAMdj
=l7nz
-END PGP SIGNATURE-

Bug#796784: Tentative patch for sending mails to signer

[Raphael Hertzog]

Hi,

On Sat, 12 Dec 2015, Ansgar Burchardt wrote:
> > There's a new configuration entry DInstall::UploadMailRecipients that
> > lists the recipients of the mails, either static ones (like
> > d...@security.debian.org) or dynamic ones (like "maintainer", "changed_by"
> > or "signer").
> 
> I prefer something like "mail:f...@example.com" over using the "@" do
> discriminate between e-mail addresses and keywords.

Done.

> > +fpr_addresses = gpg_get_key_addresses(fingerprint)
> > +for fpr_addr in fpr_addresses:
> > +if fpr_addr in emails_added:
> > +break  # The signer already gets a copy via another 
> > email
> > +else:
>
> Wrong indent?

No. It's the "else" clause of the for loop:
https://docs.python.org/2/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops

It's executed only when we come out of the loop without having hit any
break.

> Python also has a `any` function for this type of loops which should be
> a bit less verbose.

But the else is gone with this syntax now.

> That looks like `emails_added` should be a `set`.  As the order of
> recipients shouldn't matter, we can probably just use a single set for
> the mail addresses.

Changed them to set() but we need two because we retain the name
associated to the email but for the duplicate check we want to check
only on the email.

> Also the new logic to include the GPG mail address only when no other
> address from the key is already used depends on `signer` being the last
> keyword.

Right, I added a bit of logic to ensure this is always the case.

Thanks for the review! An updated patch is attached.

Thorsten, can you do some tests with the updated patch?

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/
>From 8da7b953f0353d0f67c6434e25c4f7eae415eb72 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= 
Date: Tue, 1 Dec 2015 16:20:22 +0100
Subject: [PATCH] Implement DInstall::UploadMailRecipients to control
 recipients of upload mails

This new setting lets you configure the list of recipients of upload
mails (Accepted/Rejected), you can mix harcoded emails and the special
keywords "maintainer", "changed_by" and "signer" which get replaced
by the corresponding address extracted from the upload data.

The goal is that the security archive only sends mails to the security
team and to the person who signed the upload to not leak any information
about embargoed uploads.

Closes: #796784
---
 config/debian-security/dak.conf |  5 -
 daklib/utils.py | 47 +++--
 2 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/config/debian-security/dak.conf b/config/debian-security/dak.conf
index ad47e33..1bd45e1 100644
--- a/config/debian-security/dak.conf
+++ b/config/debian-security/dak.conf
@@ -18,7 +18,10 @@ Dinstall
BXANotify "false";
DefaultSuite "stable";
SuiteSuffix "updates/";
-   OverrideMaintainer "d...@security.debian.org";
+   UploadMailRecipients {
+ "mail:d...@security.debian.org";
+ "signer";
+   };
LegacyStableHasNoSections "false";
AllowSourceOnlyUploads "true";
 };
diff --git a/daklib/utils.py b/daklib/utils.py
index 518d66e..9d743b1 100644
--- a/daklib/utils.py
+++ b/daklib/utils.py
@@ -1086,15 +1086,48 @@ def mail_addresses_for_upload(maintainer, changed_by, fingerprint):
 @return: list of RFC 2047-encoded mail addresses to contact regarding
  this upload
 """
-addresses = [maintainer]
-if changed_by != maintainer:
-addresses.append(changed_by)
+recipients = Cnf.value_list('Dinstall::UploadMailRecipients')
+if not recipients:
+recipients = [
+'maintainer',
+'changed_by',
+'signer'
+]
+
+# Ensure signer is last if present
+try:
+recipients.pop(recipients.index('signer'))
+recipients.append('signer')
+except ValueError:
+pass
+
+# Compute the set of addresses of the recipients
+addresses = set()  # Name + email
+emails = set() # Email only
+for recipient in recipients:
+if recipient.startswith('mail:'):  # Email hardcoded in config
+address = recipient[5:]
+elif recipient == 'maintainer':
+address = maintainer
+elif recipient == 'changed_by':
+address = changed_by
+elif recipient == 'signer':
+fpr_addresses = gpg_get_key_addresses(fingerprint)
+address = fpr_addresses[0] if len(fpr_addresses) > 0 else None
+if any([x in emails for x in fpr_addresses]):
+# The signer already gets a copy via another email
+address = None
+else:
+raise Exception('Unsupported entry in {0}: 

Bug#807589: libechonest: FTBFS on all architectures due to mismatched symbols file(s)

[John Paul Adrian Glaubitz]

On 12/14/2015 08:19 AM, Stefan Ahlers wrote:
> What should we do now? A new build only to fix the sh4 symbols or shell
> we fix it for the next release?

sh4 is one of my pet architectures. I will have a look and report back
later. I still need to set up the four more additional buildds to
speed up the build process similar to m68k. Hopefully I can do that
today, I still had to spend lots of time into getting ghc fixed
on sparc64 :).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#796345: [Debian-ha-maintainers] redhat-cluster/libdlm + lvm + perl transition

[Dominic Hargreaves]

On Mon, Dec 14, 2015 at 02:19:58AM +0100, Ferenc Wagner wrote:
> Dominic Hargreaves  writes:
> 
> > From [2] it appears that work is underway to fix all this, by including
> > libdlm as a separate package. Presumably at this point lvm2 would not
> > depend on redhat-cluster and it could be removed from testing?
> 
> Yes, that's the plan.
> 
> > As a more immediate fix - can the HA team comment on whether libccs-perl
> > has any value?
> 
> Being built from the redhat-cluster source package, it will go when we
> remove redhat-cluster from the archive.  Has it got any rdeps?

No rdeps and popcon of 3.

> > If not then perhaps that should just be dropped from the
> > redhat-cluster package ASAP [...] -- of course, since redhat-cluster
> > FTBFS, this would have to be done by the release team manually
> > removing (just) libccs-perl from testing. Is this feasible?
> 
> I don't know if it's possible, but if yes: no objection from the HA
> team.

Great, thanks. Let's wait to hear what the RT think then.

Cheers,
Dominic.

Bug#763822: simple next step for getting .buildinfo files into Debian

[Holger Levsen]

Hi ftp folks,

while we still appreciate your comments on this proposal as last week 
described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=763822 I'd like 
to make a intermediate very simple proposal, so that reproducible builds in 
Debian get one step forward:

- modify dak, so that it will not rejects uploads with a .buildinfo file 
included. 
- still, for now, throw the .buildinfo file immediatly away.
- only do this for experimental at the beginning. (maybe this restriction is 
not even needed/useful.)

That's it.

This would allow the dpkg maintainers to enable .buildinfo file creation, at 
least for builds for experimental.

What do you think?

As I see it, this should be a rather trivial code change for dak and yet bring 
us forward quite enourmously. Also it should be rather uncontroversial as we 
all agreed in Heidelberg at DebConf15 that we want .buildinfo files in Debian… 


cheers,
Holger



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

Bug#770087: ITP: corebird -- Native Gtk+ Twitter client for the Linux desktop

[Philip Rinn]

Hi Adnan,

this ITP is over one year old now and nothing seems to happen. Some people 
already
offered their help. Could you please consider handing over this ITP or uploading
corebird soon?
I'd be happy to maintain it if you don't find the time packaging it.

Please help making corebird available in Debian soon.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#807902: konsole: segfault on exit

[Dominik George]

Package: konsole
Version: 4:15.08.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Recently, Konsole started crashing when closing the last tab and exiting:

Application: konsole (konsole), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#6  0x7ff3c82a51b3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7ff3c829b5dd in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#8  0x7ff3c829bc79 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#9  0x7ff3c82902ed in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#10 0x7ff3c8290399 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#11 0x7ff3c7be2f52 in __run_exit_handlers (status=0, listp=0x7ff3c7f4b698 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#12 0x7ff3c7be2fa5 in __GI_exit (status=) at exit.c:104
#13 0x7ff3c7bcd877 in __libc_start_main (main=0x400710 , argc=1, 
argv=0x7fffdd5d0328, init=, fini=, 
rtld_fini=, stack_end=0x7fffdd5d0318) at libc-start.c:325
#14 0x00400749 in _start ()

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

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

Versions of packages konsole depends on:
ii  konsole-kpart   4:15.08.3-1
ii  libc6   2.21-4
ii  libkf5completion5   5.16.0-1
ii  libkf5configcore5   5.16.0-1
ii  libkf5configgui55.16.0-1
ii  libkf5configwidgets55.16.0-1
ii  libkf5coreaddons5   5.16.0-1
ii  libkf5i18n5 5.16.0-1
ii  libkf5iconthemes5   5.16.0-1
ii  libkf5kdelibs4support5  5.16.0-1
ii  libkf5kiowidgets5   5.16.0-1
ii  libkf5notifyconfig5 5.16.0-1
ii  libkf5widgetsaddons55.16.0-1
ii  libkf5windowsystem5 5.16.0-1
ii  libkf5xmlgui5   5.16.0-1
ii  libqt5core5a5.5.1+dfsg-8
ii  libqt5gui5  5.5.1+dfsg-8
ii  libqt5widgets5  5.5.1+dfsg-8
ii  libstdc++6  5.3.1-3

konsole recommends no packages.

konsole suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJOBAEBCAA4BQJWbp8OMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pY+hBAA29FL7JlCDi1kwBf6bvzB
x4/OkPgdDfS1PPP4t0e3ry/f6vR26lfLEslNiNMGrKAiBms/FljWWcM2OojeqQUj
bKKNCOPEUX9AzVXTzbdLVX7EyNt9WuBfIYGkx0aL10IyVJoeH7Vhl9lnW5CN4DRL
MyFGtaoCuj7bZVip215PYEl+fVanXC9H8BopYjV1RudrYE93doyjJ4EfK/6UDKVr
K4KY5ZO46dFMfV6R8uTFG7kPwz/l1aHkDMbvk18ntlrZt0oNnfa34dh7zazlH0oJ
TxqT35tVeX8YKYon9tbssrsDTnHjisqiIcuvXr7MIlazo6KDhNltAv8cw3jEvj99
AiUdi6VG+1xdtkGEa7YcKs/6H+DG+SqpZhNfhwmkxB0G5k/aZZrIgFseLKGu1VHs
6KjEIMXEemDPALgic7BEKcAqVV1Pl6NFUe9JVhaJFXKaUTx9mCo3Js3QjWbV3zDy
9T2aBOjxtLBNVhDHGUjflsSadJnnTUk+bSLXUFNwn5b93yNXNvrThVaZ0pmoXsY4
OBkHwc4t4wXLct1GSHlFo9BcuQQA6aZx6Ifpr7zx8SRL7OxrW4I40pVAhlFKuw/i
uvkQS/Ejbbk95jqr30L/JFpBirYV2udwCtXXahIUkIjZ4W6VOF/YUIM9BDPPBt/z
UoBeYq1/YXNM+K7FT0D6/Kw=
=qN5i
-END PGP SIGNATURE-

Bug#746268: gdcm: hundreds of "sh: 1: dot: not found" messages

[Gert Wollny]

There are actually two alternatives to fix this bug on the upstream
side: 

* Either convert the .dox files  actual man pages and then use these
directly (i.e, no longer invoking doxygen to create them). Since man
pages are actually text files this would be also a proper  source
format to apply changes. 

* Or create two different doxygen files: one for creating the man pages
only, and another one to create the reference documentation and handle
these accordingly. 

Best, 
Gert 

Bug#807911: bzflag-server: bzfs always launched on boot; RUN_AT_STARTUP setting ignored

[Thorsten Bonow]

Package: bzflag-server
Version: 2.4.2+ds1-6+b1
Severity: normal

Dear Maintainer,

it is not possible to start a bzfs server from within BZFlag because
there is one already running, launched during startup. Default setting
'RUN_AT_STARTUP="no"' in '/etc/default/bzflag' is ignored.

Manually stopping the server solves the problem. The systemd service
file has 'EnvironmentFile=-/etc/default/bzflag line, so the default
settings should be honoured.

Thx for packaging my favourite game.

Toto


$ ps aux | grep bzfs | grep -v grep
games 1100  0.0  0.2  88656  8668 ?Ss   13:04   0:00 
/usr/games/bzfs -advertise NONE


$ service bzflag status
● bzflag.service - BZFlag game server
   Loaded: loaded (/lib/systemd/system/bzflag.service; enabled; vendor preset: 
enabled)
   Active: active (running) since Mon 2015-12-14 13:04:12 CET; 5min ago
 Docs: man:bzfs(6)
 Main PID: 1100 (bzfs)
   CGroup: /system.slice/bzflag.service
   └─1100 /usr/games/bzfs -advertise NONE

Dec 14 13:04:12 talkietoaster systemd[1]: Started BZFlag game server.
Dec 14 13:04:12 talkietoaster bzfs[1100]: Note: no acceleration limit has been 
set.  Players using "mouse
Dec 14 13:04:12 talkietoaster bzfs[1100]: enhancements" may cause problems on 
this server due to very high
Dec 14 13:04:12 talkietoaster bzfs[1100]: acceleration rates which are not 
handled well by dead reckoning
Dec 14 13:04:12 talkietoaster bzfs[1100]: algorithms.  To eliminate this 
warning, set the -a switch in your
Dec 14 13:04:12 talkietoaster bzfs[1100]: configuration.  '-a 50 38' is 
recommended for standard-speed servers.
Dec 14 13:04:12 talkietoaster bzfs[1100]: Higher speed servers will need higher 
values for -a in order to not
Dec 14 13:04:12 talkietoaster bzfs[1100]: affect gameplay.  '-a 0 0' may be 
used to shut this message up without
Dec 14 13:04:12 talkietoaster bzfs[1100]: affecting any players, including 
those using "mouse enhancements".


$ cat /etc/default/bzflag
# RUN_AT_STARTUP
# "yes|true|enabled", /etc/init.d/bzflag will start bzfs.
# Any other value, /etc/init.d/bzflag will exit silently.
#
RUN_AT_STARTUP="no"

# OPTIONS
# Command line options to pass to bzfs. See bzfs(6) for more details.
#
OPTIONS="-advertise NONE"


$ cat /etc/systemd/system/multi-user.target.wants/bzflag.service
[Unit]
Description=BZFlag game server
Documentation=man:bzfs(6)
After=network.target

[Service]
Environment="OPTIONS=-advertise NONE"
EnvironmentFile=-/etc/default/bzflag
User=games
Group=games
ExecStart=/usr/games/bzfs $OPTIONS

[Install]
WantedBy=multi-user.target


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 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 bzflag-server depends on:
ii  init-system-helpers  1.24
ii  libc-ares2   1.10.0-2
ii  libc62.21-4
ii  libcurl3-gnutls  7.45.0-1+b1
ii  libgcc1  1:5.3.1-3
ii  libncurses5  6.0+20151024-2
ii  libstdc++6   5.3.1-3
ii  libtinfo56.0+20151024-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

bzflag-server recommends no packages.

bzflag-server suggests no packages.

-- no debconf information

Bug#786190: playitslowly: diff for NMU version 1.4.0-1.1

[Mattia Rizzolo]

On Sun, Dec 13, 2015 at 11:57:41PM -0500, Tiago Bortoletto Vaz wrote:
> Thanks for the NMU, I'm taking a breaking of Debian work so be free to
> take care of playitslowly as you wish. All my packages are either group
> maintained or are kept in collab-maint, so no worries.

Thanks Tiago.
Furthermore, I took care of doing the work out of the git repository, so
I just pushed everything, including a signed tag.

I also rescheduled the upload to 0-day.

Thanks for being so well-disposed ♥


Best.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#802885: [3.16] xfs: allow inode allocations in post-growfs disk space

[Luis Henriques]

On Mon, Dec 14, 2015 at 11:42:26AM +1100, Dave Chinner wrote:
> On Sun, Dec 13, 2015 at 12:27:39AM +, Ben Hutchings wrote:
> > Per the FAQ at
> > ,
> > I think the following commit should be cherry-picked for 3.16-ckt:
> > 
> > commit 9de67c3ba9ea961ba420573d56479d09d33a7587
> > Author: Eric Sandeen 
> > Date:   Thu Jul 24 20:51:54 2014 +1000
> > 
> > xfs: allow inode allocations in post-growfs disk space
> 
> Acked-by: Dave Chinner 
> 

Thanks, I'm queuing this for the next 3.16 release.

Cheers,
--
Luís

Bug#807670: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Can't build linux-tools-4.2 package)

[Alexey]

I just merge my debian and upstream branches to new branch. And then I 
successfully built from it.

I think this is abnormal situation.

Thanks for attention.

Bug#807903: r-cran-timeseries: package description refers to timeDate instead of timeSeries

[Dirk Eddelbuettel]

On 14 December 2015 at 11:54, Daniele Forsi wrote:
| Package: r-cran-timeseries
| Severity: minor
| 
| Dear Maintainer,
| 
| the last line of the package description refers to timeDate:
|  timeDate provides functions for financial time series objects.
| 
| I think it should refer to timeSeries:
|  timeSeries provides functions for financial time series objects.

Thanks so much -- I just fixed that in my sources. Clearly a copy error
from timeDate which this package depends upon.

Cheers, Dirk
 
| https://packages.debian.org/en/sid/r-cran-timeseries
| 
| thanks,
| Daniele

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#792759: setup instructions unclear, refusing to run with writable root?

[Eduard Bloch]

Hallo,
* Jörg Frings-Fürst [Mon, Dec 14 2015, 04:13:10AM]:
> Hello,
> 
> now answer for more then 20 weeks.
> 
> So I close this bug

Well, I failed to configure this software, and after stumbling upon
the mentioned problems I decided that it's a piece of crap and installed
something else. And sorry, I don't feel obliged to write improvements to
its documentation under these circumstances.

And I don't really care, feel free to close.

Regards,
Eduard.

Bug#807899: tasksel: prompts for CD/media with no 'cancel' option; ignores SIGINT/SIGTSTP, locks apt DB

[Jonathan Dowland]

Package: tasksel
Version: 3.31+deb8u1
Severity: normal

If you try to run tasksel on a machine which has removable media configured for
apt (such as a freshly installed system via CD-ROM/DVD) it's possible that
tasksel will prompt you to insert the media after selecting some tasks If you
can't do that for any reason, tasksel does not offer any way to cancel; it
loops between two screens with no way out. It also ignores SIGINT and SIGTSTP
and locks the apt database, so you can't easily update your sources.list in the
background. It would appear you need to issue a SIGTERM from another terminal,
adjust your sources.list and try again. This would be a problem in some
situations where you can't open a second terminal.

Bug#806595: aptitude: Changelog download throws warning: "W: Can't drop privileges for downloading as file '/tmp/aptitude-root.15442:qGi6mn/aptitudeDownload6J+8J:+PsVGmTNm^.^::Lz:%.Hi55VKA' couldn't b

[nfb]

I'm getting these same warnings, both for root and regular user, so
i found this bug report.

>In my system, both dirs' permissions are 700 and owned by _apt:root,
>it doesn't emit any error and changelog works fine, no warnings.

Anyway on my system (Debian stretch/testing, aptitude 0.7.4-2):

$ ls -ld /var/lib/apt/lists/partial /var/cache/apt/archives/partial
drwx-- 2 _apt root 4096 dic 14 10:00 /var/cache/apt/archives/partial
drwx-- 2 _apt root 4096 dic 14 09:58 /var/lib/apt/lists/partial

Bug#807900: microhttpd: attempt at working with LFS blows

[Shawn Landden]

Package: libmicrohttpd-dev
Version: 0.9.44+dfsg-1+b1
Severity: important
File: microhttpd

MHD_create_response_from_fd_at_offset64()

and the deprecation of

MHD_create_response_from_fd_at_offset()

creates dependency hell which is unnecessary.
Can't you just test for sizeof(off_t) and sizeof(size_t)
and only issue a warning if they are different?

I'm sure there are some docs on glibc LFS support,
and how to do this better.

Not sure what systemd should do with the situation in the meantime.

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

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

Versions of packages libmicrohttpd-dev depends on:
ii  libgcrypt20-dev [libgcrypt-dev]  1.6.4-3
ii  libgnutls28-dev  3.3.18-1
ii  libmicrohttpd10  0.9.44+dfsg-1+b1

libmicrohttpd-dev recommends no packages.

libmicrohttpd-dev suggests no packages.

-- no debconf information

Bug#807442: patch

[Hendrik Brueckner]

On Mon, Dec 14, 2015 at 09:28:08AM +0100, Hendrik Brueckner wrote:
> On Sun, Dec 13, 2015 at 03:50:01PM +0100, Philipp Kern wrote:
> > On Tue, Dec 08, 2015 at 03:17:49PM -0700, dann frazier wrote:
> > > --- s390-tools-1.32.0/debian/s390-tools.install   2014-07-26 
> > > 23:59:18.0 +0200
> > > +++ s390-tools-1.32.0/debian/s390-tools.install   2015-12-08 
> > > 23:08:30.0 +0100
> > > @@ -10,6 +10,10 @@
> > >  /sbin/dasdview
> > >  /usr/share/man/man8/dasdview.8
> > >  
> > > +# dbginfo.sh
> > > +/sbin/dbginfo.sh
> > > +/usr/share/man/man1/dbginfo.sh.1
> > > +
> >
> >  * Unless this is expected to be in /sbin, given that it's user
> >invoked and not usually scripted, should this be in /usr/sbin
> >instead?

I am not sure what you exactly mean with "user" invoked.
Anyhow, /sbin/ makes sense because the intention of the dbginfo.sh
script is to collect system and debugging information.  So it is
important to have it available early (even before /usr becomes
mounted).

I would also go further and would suggest to included it in the
s390-tools udeb package to be available in the debian installer
too.  But I would have to check if it runs in the debian installer
environment.  I could also imagine to integrate it into the
installation-report module.

Thanks and kind regards,
  Hendrik


pgp4VFlwRTv1O.pgp
Description: PGP signature

Bug#800681: getting the keycodes for Ctrl+Left and Ctrl+Right

[Arturo Borrero Gonzalez]

On 17 November 2015 at 14:57, Benno Schulenberg  wrote:
>
> Please try the attached patch.  (You have to undo the previous patch.)
> It works here on a Pantheon terminal.

It works, thanks.


-- 
Arturo Borrero González

Bug#791463: closing RFS: udfclient/0.8-1 [ITP] -- userland implementation of the UDF filesystem

[Andrew Shadura]

On 14/12/15 12:33, Pali Rohár wrote:
> On Friday 11 December 2015 18:04:06 Andrew Shadura wrote:
>> > you just dropping the patch into the right place.
> I know where and how. But I do not like idea to patching original source
> code if it is possible to compile and use it without patching.
> 
> Using patches has problem for inconsistency and upgrading if original
> source code which patch modify changes.
> 
> And also I see using patches as last option. Are not Debian want to
> reduce patches if they are not really needed?

I think it's appropriate to apply a patch (and submit it upstream) in
this case, as this is certainly a bug in the upstream makefile, and it
should be fixed.

-- 
Cheers,
  Andrew

Bug#807905: RFP: golang-github-ugorji-go-codec -- idiomatic codec and rpc library

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 740753 by -1

* Package name: golang-github-ugorji-go-codec
  Version : 0.0~git20151212.0.cd43bdd-1
  Upstream Author : Ugorji Nwoke
* URL : https://github.com/ugorji/go
* License : Expat
  Programming Lang: Go
  Description : idiomatic codec and rpc lib for msgpack, cbor, json, etc. 
msgpack.org


This is a high performance and feature-rich ideomatic encode/decode and rpc 
library for
msgpack, binc, cbor and json.

This is another requirement for Packer.

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#807908: rsyslogd sometimes dies around midnight

[Michael Biebl]

Hi Benjamin,

Am 14.12.2015 um 13:17 schrieb Benjamin Drung:
> Package: rsyslog
> Version: 8.4.2-1+deb8u1
> Severity: important
> Tags: patch
> 
> Hi,
> 
> We experienced dying rsyslogd processes. It seems to often be at
> midnight, or shortly afterwards, when a lot of files are being created,
> due to the dynamic naming of per-host/per-day files. We found upstream
> commit [1] that matches our symptoms. After applying this patch,
> rsyslogd has been running stable. So please apply this patch for jessie
> (a debdiff for that is attached). stretch/unstable are not affected since
> this upstream commit is part of rsyslog 8.12.0.
> 

Thanks for the patch, looks reasonable.
I already asked for another fix to be included 8.3 [1], will try to
update the jessie-pu accordingly. Let's see if the SRM are ok with it.

Regards,
Michael

[1] http://bugs.debian.org/807612

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#807909: apt-cacher-ng: 403 when apt is trying to download appstream data

[Laurent Bigonville]

Package: apt-cacher-ng
Version: 0.8.7-1
Severity: normal

Hello,

With the new appstream package, there is a new apt hook which download
the appstream data from the debian mirror.

When apt is set to use apt-cacher-ng, I get a 403 for these .yml.gz
files.

I guess these files should be white listed and cached?

Cheers,

Laurent Bigonville

-- Package-specific info:

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

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

Versions of packages apt-cacher-ng depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.58
ii  dpkg   1.18.3
ii  init-system-helpers1.24
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.21-4
ii  libgcc11:5.3.1-3
ii  liblzma5   5.1.1alpha+20120614-2.1
ii  libssl1.0.21.0.2e-1
ii  libstdc++6 5.3.1-3
ii  libsystemd0228-2
ii  libwrap0   7.6.q-25
ii  zlib1g 1:1.2.8.dfsg-2+b1

apt-cacher-ng recommends no packages.

Versions of packages apt-cacher-ng suggests:
ii  avahi-daemon  0.6.32~rc+dfsg-1
pn  doc-base  
ii  libfuse2  2.9.4-1

-- Configuration Files:
/etc/apt-cacher-ng/security.conf [Errno 13] Permission non accordée: 
u'/etc/apt-cacher-ng/security.conf'

-- debconf information excluded

Bug#807906: zsh-common: Command completion broken since aptitude 0.7.5

[Axel Beckert]

Hi Micha,

thanks for the bug report!

While I can't confirm it at the moment, I vaguely remember that I
noticed such an issue, too.

Micha Moskovic wrote:
> since updating aptitude to version 0.7.5-1, the command completion for 
> aptitude
> is broken.

Since I'm an uploader to both packages, I feel slightly responsible
for this bug. Will check and see if I can come up with a patch.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#807896: kid3 does not substitute slashes when building filename

[Francois Gouget]

Package: kid3
Version: 3.3.0-1
Severity: normal

Dear Maintainer,

Steps to reproduce this bug:
 * Start kid3 and load a set of tracks.
 * Go to Settings -> Configure Kid3... In Files, make sure that there is a rule
   to replace '/' with '-' or add one.
 * Back to the main dialog, edit one of the titles so it includes a slash.
   For instance "Noel Blanc / White Christmas".
 * Set the Format used to generate filenames to '%{title}' and click on the
   appropriate button to update the filename from the id3 tags.
 * BUG: The filename should now read 'Noel Blanc - White Christmas.mp3", but
   instead it is "Noel Blanc / White Christmas.mp3".
 * If you try to save the changes you get an error message saying the file is
   no writable. That makes sense given that there is no "Noel Blanc " directory.

The workaround is to manually edit the filename and redo the save operation.


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

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

Versions of packages kid3 depends on:
ii  kde-runtime 4:15.08.2-1
ii  kid3-core   3.3.0-1
ii  libc6   2.19-22
ii  libgcc1 1:5.2.1-23
ii  libkdecore5 4:4.14.13-1
ii  libkdeui5   4:4.14.13-1
ii  libkio5 4:4.14.13-1
ii  libphonon4  4:4.8.3-2
ii  libqt4-dbus 4:4.8.7+dfsg-5
ii  libqt4-declarative  4:4.8.7+dfsg-5
ii  libqt4-network  4:4.8.7+dfsg-5
ii  libqt4-svg  4:4.8.7+dfsg-5
ii  libqt4-xml  4:4.8.7+dfsg-5
ii  libqtcore4  4:4.8.7+dfsg-5
ii  libqtgui4   4:4.8.7+dfsg-5
ii  libstdc++6  5.2.1-23

kid3 recommends no packages.

kid3 suggests no packages.

-- no debconf information

Bug#807343: RM: ghc [armel] -- ROM; Not supported on armel any more

[Ansgar Burchardt]

Joachim Breitner  writes:
> with GHC-7.10.3, upstream dropped suppot for old ARM chipsets, such as
> our armel architecture (armhf is fine). It is not the case that anyone
> steps up to un-break this, so we’ll just have to remove Haskell
> from armel. See also
> https://lists.debian.org/debian-arm/2015/11/msg00010.html and
> https://lists.debian.org/debian-arm/2015/12/msg00020.html
>
> This will also solve #807020 trivially.
>
> I tried to conjure a complete set of packages to remove using "dak rm",
> but there are far too many false positives, e.g. arch-all-only sources
> that build-depend on packages like shellcheck. I hope you have better
> tools at your hand to calculate the set of reverse dependencies of ghc
> on armel that also need to be removed.

We don't have particular well tools for this, but I did the same dance
as the last time[1] to get the list of packages that build-depend on
ghc:

  zcat ftp/dists/unstable/main/source/Sources.gz | \
  grep-dctrl -e -ns Package -F Build-Depends '\' | \
  sort -u > ~/rm-haskell-armel-sources

The packages that dak's reverse-dependency check then complains about
are:

  dak rm -nR -p -B -a armel $(cat rm-haskell-armel-sources)
  [...]
  # Broken Depends:
  darcsweb: darcsweb
  fusionforge: fusionforge-plugin-scmdarcs
  ganeti: ganeti
  ganeti-htools
  ghc-mod: ghc-mod-el
  haskell-devscripts: haskell-devscripts
  haskell-diagrams: libghc-diagrams-dev
libghc-diagrams-prof
  haskell-platform: haskell-platform
haskell-platform-prof
  m2l-pyqt: mediawiki2latexguipyqt

These are all arch:all, so breaking them should be okay.  Note that
these become uninstallable and so do any armel packages that depend on
them (if such packages exist).

Ansgar

  [1] 

Bug#796345: [Debian-ha-maintainers] redhat-cluster/libdlm + lvm + perl transition

[Emilio Pozuelo Monfort]

On 14/12/15 11:10, Dominic Hargreaves wrote:
> On Mon, Dec 14, 2015 at 02:19:58AM +0100, Ferenc Wagner wrote:
>> Dominic Hargreaves  writes:
>>
>>> From [2] it appears that work is underway to fix all this, by including
>>> libdlm as a separate package. Presumably at this point lvm2 would not
>>> depend on redhat-cluster and it could be removed from testing?
>>
>> Yes, that's the plan.
>>
>>> As a more immediate fix - can the HA team comment on whether libccs-perl
>>> has any value?
>>
>> Being built from the redhat-cluster source package, it will go when we
>> remove redhat-cluster from the archive.  Has it got any rdeps?
> 
> No rdeps and popcon of 3.
> 
>>> If not then perhaps that should just be dropped from the
>>> redhat-cluster package ASAP [...] -- of course, since redhat-cluster
>>> FTBFS, this would have to be done by the release team manually
>>> removing (just) libccs-perl from testing. Is this feasible?
>>
>> I don't know if it's possible, but if yes: no objection from the HA
>> team.
> 
> Great, thanks. Let's wait to hear what the RT think then.

Not really. At least not AFAIK, and it'd be hackish and ugly if it was possible.
It'd be nice if the FTBFS got fixed instead. If it's too difficult to make it
build with GCC 5 (I guess it isn't, but...) then as a temporary workaround you
could make it build with GCC 4.9.

Cheers,
Emilio

Bug#746268: gdcm: hundreds of "sh: 1: dot: not found" messages

[Mathieu Malaterre]

Control: forwarded -1 https://sourceforge.net/p/gdcm/bugs/366/

On Mon, Dec 14, 2015 at 1:03 PM, Gert Wollny  wrote:
> There are actually two alternatives to fix this bug on the upstream
> side:
>
> * Either convert the .dox files  actual man pages and then use these
> directly (i.e, no longer invoking doxygen to create them). Since man
> pages are actually text files this would be also a proper  source
> format to apply changes.

Point taken. Will try to use doxygen + GENERATE_DOCBOOK to bootstrap a
conversion to docbook.

Thanks for taking care of GDCM package.

-M

Bug#807728: 0.76 didn't fix it for me

[Hans-Christoph Steiner]

Doh, just saw this is a bug in pbuilder, not cowbuilder.  I updated to
pbuilder 0.221.3 and it fixed the issue for me.

Bug#807343: RM: ghc [armel] -- ROM; Not supported on armel any more

[Joachim Breitner]

Control: tag -1 + moreinfo

Hi,

Am Montag, den 14.12.2015, 11:14 +0100 schrieb Ansgar Burchardt:
> We don't have particular well tools for this, but I did the same
> dance
> as the last time[1] to get the list of packages that build-depend on
> ghc:
> 
>   zcat ftp/dists/unstable/main/source/Sources.gz | \
>   grep-dctrl -e -ns Package -F Build-Depends '\' | \
>   sort -u > ~/rm-haskell-armel-sources
> 
> The packages that dak's reverse-dependency check then complains about
> are:
> 
>   dak rm -nR -p -B -a armel $(cat rm-haskell-armel-sources)
>   [...]
>   # Broken Depends:
>   darcsweb: darcsweb
>   fusionforge: fusionforge-plugin-scmdarcs
>   ganeti: ganeti
>   ganeti-htools
>   ghc-mod: ghc-mod-el
>   haskell-devscripts: haskell-devscripts
>   haskell-diagrams: libghc-diagrams-dev
> libghc-diagrams-prof
>   haskell-platform: haskell-platform
> haskell-platform-prof
>   m2l-pyqt: mediawiki2latexguipyqt
> 
> These are all arch:all, so breaking them should be okay.  Note that
> these become uninstallable and so do any armel packages that depend on
> them (if such packages exist).

thanks!

Neverthess, please actually hold this bug for a moment, Adrian Glaubitz
wants to give fixing ghc on armel a shot. Marking the bug as moreinfo.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#807892: lintian: warn about using TEMP CVE identifiers in debian/changelog

[Jakub Wilk]

Hi Paul!

* Paul Wise , 2015-12-14, 15:18:
Please warn about the use of TEMP CVE identifiers in debian/changelog. 
These identifiers are temporary and go away when CVEs are assigned so 
they are not at all useful to record.


The regex is TEMP-\d{7}-\d{6} (case sensitive):


I don't think this is the right regexp.


https://bugs.debian.org/799019


For example, this bug refers to "TEMP-000-1C4729", which your regexp 
wouldn't match.


--
Jakub Wilk

Bug#807904: mathicgb: wrong spelling for Gröbner in package description

[Daniele Forsi]

Package: mathicgb
Severity: minor

Dear Maintainer,

in the description for this package, I think that the name Groebner is wrongly 
spelled twice as Grobner (without the "e"):
signature Grobner bases...
"Practical Grobner Basis Computation"...

thanks,
Daniele

Bug#807907: RFP: golang-github-mitchellh-multistep -- Go library for building up complex actions using discrete steps

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 740753 by -1

* Package name: golang-github-mitchellh-multistep
  Version : 0.0~git20140407.0.162146f-1
  Upstream Author : Mitchell Hashimoto 
* URL : https://github.com/mitchellh/multistep
* License : Expat
  Programming Lang: Go
  Description : Go library for building up complex actions using discrete 
steps

This is a Go library for building up complex actions using discrete, individual 
"steps."
These steps are strung together and run in sequence to achieve a more complex 
goal. The
runner handles cleanup, cancelling, etc. if necessary.

This is another requirement for Packer.

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#807908: rsyslogd sometimes dies around midnight

[Benjamin Drung]

Package: rsyslog
Version: 8.4.2-1+deb8u1
Severity: important
Tags: patch

Hi,

We experienced dying rsyslogd processes. It seems to often be at
midnight, or shortly afterwards, when a lot of files are being created,
due to the dynamic naming of per-host/per-day files. We found upstream
commit [1] that matches our symptoms. After applying this patch,
rsyslogd has been running stable. So please apply this patch for jessie
(a debdiff for that is attached). stretch/unstable are not affected since
this upstream commit is part of rsyslog 8.12.0.

Thanks.

[1] 
https://github.com/rsyslog/rsyslog/commit/008f0097b610742595034cdab381749dbc00f93f

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.dr...@profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
diff -Nru rsyslog-8.4.2/debian/changelog rsyslog-8.4.2/debian/changelog
--- rsyslog-8.4.2/debian/changelog	2015-08-29 15:39:00.0 +0200
+++ rsyslog-8.4.2/debian/changelog	2015-12-14 13:15:08.0 +0100
@@ -1,3 +1,10 @@
+rsyslog (8.4.2-1+deb8u2) jessie; urgency=medium
+
+  * Prevent a segfault in dynafile creation. Patch cherry-picked from
+upstream Git.
+
+ -- Benjamin Drung   Mon, 14 Dec 2015 13:14:54 +0100
+
 rsyslog (8.4.2-1+deb8u1) jessie; urgency=medium
 
   * Disable transactions in ompgsql as they were not working properly.
diff -Nru rsyslog-8.4.2/debian/patches/0003-Prevent-a-segfault-in-dynafile-creation.patch rsyslog-8.4.2/debian/patches/0003-Prevent-a-segfault-in-dynafile-creation.patch
--- rsyslog-8.4.2/debian/patches/0003-Prevent-a-segfault-in-dynafile-creation.patch	1970-01-01 01:00:00.0 +0100
+++ rsyslog-8.4.2/debian/patches/0003-Prevent-a-segfault-in-dynafile-creation.patch	2015-11-19 11:11:18.0 +0100
@@ -0,0 +1,25 @@
+From 008f0097b610742595034cdab381749dbc00f93f Mon Sep 17 00:00:00 2001
+From: Tomas Heinrich 
+Date: Fri, 17 Jul 2015 21:00:23 +0200
+Subject: [PATCH] Prevent a segfault in dynafile creation
+
+A failure during the dynafile creation (in prepareFile(), most of the
+time) led to a misaddressing and a segfault.
+
+(cherry-picked from commit 008f0097b610742595034cdab381749dbc00f93)
+---
+ tools/omfile.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/tools/omfile.c
 b/tools/omfile.c
+@@ -779,7 +779,8 @@
+ 	DBGPRINTF("Added new entry %d for file cache, file '%s'.\n", iFirstFree, newFileName);
+ 
+ finalize_it:
+-	pCache[pData->iCurrElt]->nInactive = 0;
++	if(iRet == RS_RET_OK)
++		pCache[pData->iCurrElt]->nInactive = 0;
+ 	RETiRet;
+ }
+ 
diff -Nru rsyslog-8.4.2/debian/patches/series rsyslog-8.4.2/debian/patches/series
--- rsyslog-8.4.2/debian/patches/series	2015-08-29 15:39:00.0 +0200
+++ rsyslog-8.4.2/debian/patches/series	2015-11-19 11:10:21.0 +0100
@@ -1,2 +1,3 @@
 0001-Don-t-create-a-database.patch
 0002-bugfix-ompgsql-transaction-were-improperly-handled.patch
+0003-Prevent-a-segfault-in-dynafile-creation.patch

Bug#807892: lintian: warn about using TEMP CVE identifiers in debian/changelog

[Paul Wise]

On Mon, 2015-12-14 at 11:48 +0100, Jakub Wilk wrote:

> I don't think this is the right regexp.
> 
> > https://bugs.debian.org/799019
> 
> For example, this bug refers to "TEMP-000-1C4729", which your regexp 
> wouldn't match.

Woops, I found the wrong code location!

The correct regex and code location:

TEMP-\d{7}-[A-Z\d]{6}
https://anonscm.debian.org/viewvc/secure-testing/lib/python/bugs.py?view=markup#l400

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#807868: ITP: zjump -- Jump to frequent directories matching regex

[Osamu Aoki]

Hi,

On Mon, Dec 14, 2015 at 11:34:53AM +0100, Jakub Wilk wrote:
> * Thomas Ross , 2015-12-13, 16:57:
> >The package should actually be called 'Z', but according to reportbug
> >that is not a valid package name.
> 
> reportbug is right. As per Policy §5.6.1, package names “must be at
> least two characters long”.
> 
> >Are there any suggestions for this?
> 
> My suggestion is to ask upstream about their preference in alternative
> names for "z".

Yes.  That's the best thing to do.

Or at least, install its binary and manpage in some other name such as
rupa-z or zjump.  And add suggestion to make a short alias such as "z"
which does not conflict on the machine in its manpage and README.

So user can have a short name if he wishes but will not deprive others
to use z as alias.

This is a very simple package so maintaining patch is not too much of
burden.

Osamu

 

Bug#807898: Jessie regression: mp4 playback in native firefox broken

[Harald Dunkel]

Package: gstreamer0.10-plugins-base
Version: 0.10.36-2

The upgrade from Wheezy to Jessie broke mp4 playback in
native Firefox 38.4esr (binary downloaded from
http://ftp.mozilla.org). If I rebuild Firefox from source
using gstreamer 0.10 on Wheezy it doesn't work on Jessie,
either. There is surely a regression here.

Building Firefox with gstreamer 1.0 on Jessie seems to work,
but for verification I am bound to upstream's binary blobs.
Its highly painful.


Regards
Harri

Bug#807868: ITP: zjump -- Jump to frequent directories matching regex

[Jakub Wilk]

* Thomas Ross , 2015-12-13, 16:57:
The package should actually be called 'Z', but according to reportbug 
that is not a valid package name.


reportbug is right. As per Policy §5.6.1, package names “must be at 
least two characters long”.



Are there any suggestions for this?


My suggestion is to ask upstream about their preference in alternative 
names for "z".


--
Jakub Wilk

Bug#807901: ntlmaps: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Leonardo Rocha]

Package: ntlmaps
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.

-- 
Leonardo Rocha
4096R/7E7D1FE2
about.me/leonardo.rocha


pt_BR.po.gz
Description: application/gzip

Bug#807343: RM: ghc [armel] -- ROM; Not supported on armel any more

[Ansgar Burchardt]

Ansgar Burchardt  writes:
> We don't have particular well tools for this, but I did the same dance
> as the last time[1] to get the list of packages that build-depend on
> ghc:
>
>   zcat ftp/dists/unstable/main/source/Sources.gz | \
>   grep-dctrl -e -ns Package -F Build-Depends '\' | \
>   sort -u > ~/rm-haskell-armel-sources
>
> The packages that dak's reverse-dependency check then complains about
> are:
>
>   dak rm -nR -p -B -a armel $(cat rm-haskell-armel-sources)
>   [...]
>   # Broken Depends:
>   darcsweb: darcsweb
>   fusionforge: fusionforge-plugin-scmdarcs
>   ganeti: ganeti
>   ganeti-htools
>   ghc-mod: ghc-mod-el
>   haskell-devscripts: haskell-devscripts
>   haskell-diagrams: libghc-diagrams-dev
> libghc-diagrams-prof
>   haskell-platform: haskell-platform
> haskell-platform-prof
>   m2l-pyqt: mediawiki2latexguipyqt
>
> These are all arch:all, so breaking them should be okay.  Note that
> these become uninstallable and so do any armel packages that depend on
> them (if such packages exist).

And pandoc (which is getting removed) actually has reverse build-depends
too:

beef bladerf cafeobj daligner dazzdb flashcache flvmeta kicad ktap
libmaxminddb m2crypto mod-gnutls obnam osmcoastline osmium-tool
purity-ng rainbow ruby-standalone ssh-agent-filter sysdig tcpcrypt
tempest-for-eliza

(These are only the sources which do Build-Depends: pandoc, not
 Build-Depends-Indep.)

And these have rdeps too:

  Checking reverse dependencies...
  # Broken Depends:
  automx: automx
  flashproxy: flashproxy-common
  freedombox-setup: freedombox-setup
  freeipa: freeipa-server-trust-ad
  gdnsd: gdnsd
  gr-osmosdr: gr-osmosdr
  libgnuradio-osmosdr0.1.4
  hash-slinger: hash-slinger
  libstoragemgmt: python-libstoragemgmt
  m2ext: python-m2ext
  osc: osc
  oz: oz
  python-maxminddb: python-maxminddb
python3-maxminddb
  python-u2flib-server: python-u2flib-server
  pywbem: python-pywbem
  pyxmpp: python-pyxmpp
  rainbow: rainbow
  shadowsocks: shadowsocks
  tcosmonitor: tcosmonitor-common
  tribler: tribler
  wader: python-wader

  # Broken Build-Depends:
  fedmsg: python-m2crypto
  flashproxy: python-m2crypto
  gdnsd: libmaxminddb-dev
  gr-osmosdr: libbladerf-dev (>= 0.2014.09~rc2)
  libstoragemgmt: python-m2crypto
  python-maxminddb: libmaxminddb-dev
  python-u2flib-server: python-m2crypto
  pywbem: python-m2crypto
  pyxmpp: python-m2crypto
  wader: python-m2crypto
  wireless-regdb: python-m2crypto

I'm going to leave them broken as it's not clear what to do with them:
either the package they depend on could be made to build on armel by not
build-depending on pandoc, or the packages could (maybe) not depend on
the package that got removed due to pandoc.

Ansgar

Bug#807903: r-cran-timeseries: package description refers to timeDate instead of timeSeries

[Daniele Forsi]

Package: r-cran-timeseries
Severity: minor

Dear Maintainer,

the last line of the package description refers to timeDate:
 timeDate provides functions for financial time series objects.

I think it should refer to timeSeries:
 timeSeries provides functions for financial time series objects.

https://packages.debian.org/en/sid/r-cran-timeseries

thanks,
Daniele

Bug#807670: closed by Ben Hutchings <b...@decadent.org.uk> (Re: Can't build linux-tools-4.2 package)

[Alexey]

I still think this is a bug in source package.
Your build log showed me nothing.
I have separate branches for debian folder and upstream sources and 
building them with git-buildpackage command. And I think that you merged 
debian and upstream branches that is the reason you have no trouble with 
building linux-tools package.

It's ugly approach.

No regards.

Bug#807910: RFP: golang-github-mitchellh-panicwrap -- Go library for catching and handling panics

[Daniel Stender]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: block 740753 by -1

* Package name: golang-github-mitchellh-panicwrap
  Version : 0.0~git20151104.0.89dc8ac-1
  Upstream Author : Mitchell Hashimoto 
* URL : https://github.com/mitchellh/panicwrap
* License : Expat
  Programming Lang: Go
  Description : Go library for catching and handling panics

Panicwrap is a Go library that re-executes a Go binary and monitors stderr 
output from the binary for
a panic. When it finds a panic, it executes a user-defined handler function. 
Stdout, stderr, stdin, signals,
and exit codes continue to work as normal, making the existence of panicwrap 
mostly invisible to the end
user until a panic actually occurs.

This is another requirement for Packer.

Thanks,
DS

-- 
4096R/DF5182C8
46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
LPI certified Linux admin (LPI000329859 64mz6f7kt4)
http://www.danielstender.com/blog/

Bug#807810: got it

[積丹尼 Dan Jacobson]

> "NB" == Nicholas Bamber  writes:

NB> Forgot to copy the submitter. Fixed!

NB> On 13/12/15 12:32, Nicholas Bamber wrote:
>> You want to be able to support forwarding to two places. I doubt that
>> this is a worthwhile idea, but in any case it would firts need to be
>> fixed in the Debian bugs system.


OK, but probably should add notes:

   forwarded bug address
   Mark the bug as forwarded to the given address (usually an email
   address or a URL for an upstream bug tracker).

Note - a second forward command will wipe out the original forward
address, not add to it.

   notforwarded bug
   Mark a bug as not forwarded.

Note - actually just removes +forwarded status...

Bug#807571: ocserv: fails to install due to insserv rejecting the script header

[Yuxuan Wang]

Package: ocserv
Version: 0.10.7-1
Followup-For: Bug #807571

Dear Maintainer,

/etc/init.d/ocserv from package ocserv always try to use port 443, despite that
I have an /etc/ocserv/ocserv.conf file says otherwise

Start it manually will work:

/usr/sbin/ocserv --pid-file /var/run/ocserv.pid --config /etc/ocserv/ocserv.conf

But the init.d script doesn't. I failed to dig out why that init.d script always
tries to use port 443.

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


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

Kernel: Linux 4.3.0-1-amd64 (SMP w/2 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 ocserv depends on:
ii  libc6  2.21-4
ii  libgnutls-deb0-28  3.3.18-1
ii  libhttp-parser2.1  2.1-2
ii  liblz4-1   0.0~r131-1
ii  libnl-3-2003.2.26-1
ii  libnl-route-3-200  3.2.26-1
ii  libopts25  1:5.18.6-4
ii  libpam0g   1.1.8-3.1
ii  libpcl11.6-1
ii  libprotobuf-c1 1.1.1-1
ii  libreadline6   6.3-8+b4
ii  libseccomp22.2.3-2
ii  libsystemd0228-2
ii  libtalloc2 2.1.5-1
ii  libwrap0   7.6.q-25

Versions of packages ocserv recommends:
ii  ca-certificates  20150426
ii  ssl-cert 1.0.37

ocserv suggests no packages.

-- no debconf information

Bug#785991: Delayed upload

[Mattia Rizzolo]

Hi,

On Wed, Aug 26, 2015 at 09:10:28PM +0200, Michael Hanke wrote:
> The package update is done, but a failing tests prevent an immediate
> upload. See attached build log. Investigation is under way...

any news on this?
we'd like to go on... :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#807997: diffoscope: CbfsFile checks make diffoscope extra slow

[Mike Hommey]

Source: diffoscope
Version: ada1a1dcdc19217fb611e0a1e57bc3744399aefa
Severity: important

Dear Maintainer,

   * What led up to the situation?

Comparing
http://archive.mozilla.org/pub/firefox/try-builds/m...@glandium.org-93eecb52fcadc562b0f52cb22a8971770446a12e/try-linux64/firefox-45.0a1.en-US.linux-x86_64.tar.bz2
with
https://queue.taskcluster.net/v1/task/Y1kcxbpQQcOQhIHDp7oRxA/runs/0/artifacts/public/build/target.tar.bz2

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Ran `diffoscope --html output.html firefox-45.0a1.en-US.linux-x86_64.tar.bz2 
target.tar.bz2`

   * What was the outcome of this action?

It took 9 minutes and 15 seconds on my machine.

   * What outcome did you expect instead?

It taking much less time. In fact, after doing some profiling and seeing that
CbfsFile was a hotspot, applying the following patch made the command take 80
seconds instead, most of which is spent bunzip2'ing the two archives
sequentially, and objdump --disassemble'ing libxul.so in the two archives in
parallel (so there could be a win with bunzip2'ing the two archives in
parallel, too).

diff --git a/diffoscope/comparators/__init__.py 
b/diffoscope/comparators/__init__.py
index b4615c9..c4cffbb 100644
--- a/diffoscope/comparators/__init__.py
+++ b/diffoscope/comparators/__init__.py
@@ -129,7 +129,6 @@ FILE_CLASSES = (
 DebDataTarFile,
 TextFile,
 Bzip2File,
-CbfsFile,
 CpioFile,
 DebFile,
 DexFile,



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

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

Bug#808000: python-django-sitetree: Depends on depreciated python-django-south package

[Brian May]

Package: python-django-sitetree
Version: 1.5.0-1
Severity: important

python-django-south has a serious bug report, see #807994.
-- 
Brian May 
https://linuxpenguins.xyz/brian/

Bug#800681: getting the keycodes for Ctrl+Left and Ctrl+Right

[Benno Schulenberg]

On Mon, Dec 14, 2015, at 12:34, Arturo Borrero Gonzalez wrote:
> On 17 November 2015 at 14:57, Benno Schulenberg  
> wrote:
> > Please try the attached patch.  (You have to undo the previous patch.)
> > It works here on a Pantheon terminal.
> 
> It works, thanks.

Thanks for confirming.

The patch is in 2.5.0, released a week ago.  So when the Debian
maintainer catches up and packages 2.5.0, it should work out of
the box.

(Your nftables.nanorc didn't make it into 2.5.0, because I forgot
to add it to the dist files.  :|  It will be in 2.5.1.)

Benno

-- 
http://www.fastmail.com - mmm... Fastmail...

Bug#807934: ITP: python-ripe-atlas-cousteau -- Python wrapper around the RIPE Atlas API

[Apollon Oikonomopoulos]

Package: wnpp
Severity: wishlist
Owner: Apollon Oikonomopoulos 

* Package name: python-ripe-atlas-cousteau
  Version : 1.0.5
  Upstream Author : RIPE NCC
* URL : https://github.com/RIPE-NCC/ripe-atlas-cousteau
* License : GPLv3
  Programming Lang: Python
  Description : Python wrapper around the RIPE Atlas API

RIPE Atlas Cousteau is a Python library wrapping the RIPE Atlas HTTP 
API. RIPE Atlas is a global network of probes that measure Internet 
connectivity and reachability, providing an overview of the state of the 
Internet in real time.

Bug#807502: gcc-avr: Missing support for atxmega

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 13 December 2015 09:43:47 you wrote:
> Hi,
> I've now uploaded a new version of avr-libc with the new names on those
> files. I'll also update binutils to declear that it wont work with older
> avr-libc.

I confirm it works, thanks!


-- 
Bebe a bordo (pero con moderación)

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file

[Roger Shimizu]

On Mon, Dec 14, 2015 at 11:57 PM, Felipe Sateler  wrote:
> Another option is to simply not enable/start the service, and just
> ship instructions on how to do that in README.Debian.
>
> Running it on postinst looks weird to me. We normally do not run
> possibly long processes synchronously on package installs.

I agree to removing adjtimexconfig from postinst, which takes 70
seconds during install, is a good idea.
But the defconf selection on enable/disable service is another issue.
Yes, without adjtimexconfig running on install implies the service is
disabled by default. But user need an easy way to enable adjtimex
service after adjtimexconfig running.
Do you think it's okay to run debconf to let user decide whether to
start the service after manually running adjtimexconf?

Thank you!

Cheers,
Roger

Bug#807933: Spamassassin requirements/suggestions are not exactly valid

[Vladislav Artemyev]

package: spamassassin
version: 3.4.0-6, 3.4.1-3 (maybe others)

1. Debian Jessie comes with no libdigest-sha1-perl package. i believe it 
was deprecated in favor of libdigest-sha-perl (?). while using 
Spamassassin it clearly state Digest::SHA1 as a requirement. see 
sa-update -D sample output below:


root@vs01:~# sa-update -D
Dec 14 16:46:17.395 [25963] dbg: logger: adding facilities: all
Dec 14 16:46:17.395 [25963] dbg: logger: logging level is DBG
Dec 14 16:46:17.396 [25963] dbg: generic: SpamAssassin version 3.4.0
Dec 14 16:46:17.396 [25963] dbg: generic: Perl 5.020002, PREFIX=/usr, 
DEF_RULES_DIR=/usr/share/spamassassin, 
LOCAL_RULES_DIR=/etc/spamassassin, LOCAL_STATE_DIR=/var/lib/spamassassin

Dec 14 16:46:17.396 [25963] dbg: config: timing enabled
Dec 14 16:46:17.396 [25963] dbg: config: score set 0 chosen.
Dec 14 16:46:17.401 [25963] dbg: generic: sa-update version svn1475932
Dec 14 16:46:17.401 [25963] dbg: generic: using update directory: 
/var/lib/spamassassin/3.004000

Dec 14 16:46:17.567 [25963] dbg: diag: perl platform: 5.020002 linux
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: 
Digest::SHA, version 5.88
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: 
HTML::Parser, version 3.71
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: Net::DNS, 
version 0.81
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: 
NetAddr::IP, version 4.075
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: 
Time::HiRes, version 1.9726
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: 
Archive::Tar, version 1.96
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: IO::Zlib, 
version 1.10
*Dec 14 16:46:17.567 [25963] dbg: diag: [...] module not installed: 
Digest::SHA1 ('require' failed)*
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: 
MIME::Base64, version 3.14
Dec 14 16:46:17.567 [25963] dbg: diag: [...] module installed: DB_File, 
version 1.831
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Net::SMTP, version 2.33
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Mail::SPF, version v2.009
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: Geo::IP, 
version 1.45
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Razor2::Client::Agent, version 2.84
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
IO::Socket::IP, version 0.29
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
IO::Socket::INET6, version 2.72
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
IO::Socket::SSL, version 2.002
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Compress::Zlib, version 2.064
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Mail::DKIM, version 0.4
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: DBI, 
version 1.631
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Getopt::Long, version 2.42
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
LWP::UserAgent, version 6.06
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
HTTP::Date, version 6.02
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Encode::Detect, version 1.01
Dec 14 16:46:17.568 [25963] dbg: diag: [...] module installed: 
Net::Patricia, version 1.22

Dec 14 16:46:17.569 [25963] dbg: gpg: Searching for 'gpg'
Dec 14 16:46:17.569 [25963] dbg: util: current PATH is: 
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Dec 14 16:46:17.569 [25963] dbg: util: executable for gpg was found at 
/usr/bin/gpg

Dec 14 16:46:17.569 [25963] dbg: gpg: found /usr/bin/gpg
Dec 14 16:46:17.569 [25963] dbg: gpg: release trusted key id list: 
0C2B1D7175B852C64B3CDC716C55397824F434CE 
5E541DC959CB8BAC7C78DFDC4056A61A5244EC45
Dec 14 16:46:17.570 [25963] dbg: channel: attempting channel 
updates.spamassassin.org
Dec 14 16:46:17.570 [25963] dbg: channel: using existing directory 
/var/lib/spamassassin/3.004000/updates_spamassassin_org
Dec 14 16:46:17.570 [25963] dbg: channel: channel cf file 
/var/lib/spamassassin/3.004000/updates_spamassassin_org.cf
Dec 14 16:46:17.570 [25963] dbg: channel: channel pre file 
/var/lib/spamassassin/3.004000/updates_spamassassin_org.pre
Dec 14 16:46:17.570 [25963] dbg: channel: metadata version = 1717726, 
from file /var/lib/spamassassin/3.004000/updates_spamassassin_org.cf
Dec 14 16:46:17.579 [25963] dbg: dns: 0.4.3.updates.spamassassin.org => 
1717726, parsed as 1717726
Dec 14 16:46:17.579 [25963] dbg: channel: current version is 1717726, 
new version is 1717726, skipping channel

Dec 14 16:46:17.579 [25963] dbg: diag: updates complete, exiting with code 1

2. no libgeo-ip-perl (Geo::IP), libencode-detect-perl (Encode::Detect) 
or libnet-patricia-perl (Net::Patricia) are specified as suggested. do 
we need spamassassin to function or just stay there and look like it's 
fine as it is? that's all the suggestions/requirements i see when i 
trying to 

Bug#807936: ITP: python-ripe-atlas-sagan -- parsing library for RIPE Atlas measurement results

[Apollon Oikonomopoulos]

Package: wnpp
Severity: wishlist
Owner: Apollon Oikonomopoulos 

* Package name: python-ripe-atlas-sagan
  Version : 1.1.7
  Upstream Author : RIPE NCC
* URL : https://github.com/RIPE-NCC/ripe.atlas.sagan
* License : GPLv3
  Programming Lang: Python
  Description : parsing library for RIPE Atlas measurement results

Ripe Atlas Sagan is a Python library for parsing RIPE Atlas measurement 
results. It aims at providing a consistent high-level interface for a 
rapidly changing low-level format used by the RIPE Atlas probes. RIPE 
Atlas is a global network of probes that measure Internet
connectivity and reachability, providing an overview of the state of the
Internet in real time.

This package is required for packaging ripe-atlas-tools.

Bug#807919: horst: consider moving back to main

[Antoine Beaupré]

On 2015-12-14 08:52:23, Peter Green wrote:
> Package: horst
>
> Horst was moved from main to contrib a couple of months ago. The reason 
> given for this was that sparse was in non-free. However since then 
> sparse has been relicensed under MIT and moved to main.
>
> If there is no other reason to keep horst in contrib please consider 
> moving it back to main.

Sigh... sure, i'd be great. it's just that it took forever to pass new
last time, so i think i'll hold on for a while...

but yeah, it would be the next step.

-- 
Si Dieu est, l'homme est esclave ; 
or l'homme peut, doit être libre, donc Dieu n'existe pas.
Et si Dieu existait, il faudrait s'en débarrasser!
- Michel Bakounine

Bug#807907: Uploading golang-github-mitchellh-multistep

[Alexandre Viau]

Hey,

I am uploading  golang-github-mitchellh-multistep in a few minutes.

Cheers,

-- 
Alexandre Viau
av...@debian.org



signature.asc
Description: OpenPGP digital signature

Bug#807945: keyboard-configuration skips prompts when using only bluetooth keyboard

[bunnie]

Package: keyboard-configuration
Version: 1.123
Severity: normal

Dear Maintainer,

When configuring a system that uses only a bluetooth keyboard (no USB keyboard
directly attached), the function keyboard_present() in 
keyboard-configuration.config
indicates that no keyboard is present, which prevents the keyboard 
configuration UI
from ever running. 

The work around was to plug in a USB keyboard temporarily while running
dpkg-reconfigure keyboard-configuration, so that the function would return
true.

It might be nice if the script could work with bluetooth keyboards, or perhaps
at least emit an error message to console indicating that no keyboard was 
detected
therefore the configuration UI is being skipped. It took me a long time to 
figure
out that's why the script wasn't working. This is in part because I spent a lot
of time trying to figure out the significance of these warnings, which I think
are harmless red herrings in the end:

# dpkg-reconfigure keyboard-configuration
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults

thanks.

-b.

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.19.0-00485-gc5f2138 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_SG.utf8, LC_CTYPE=en_SG.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.56
ii  initscripts 2.88dsf-59
ii  liblocale-gettext-perl  1.05-8+b1

keyboard-configuration recommends no packages.

keyboard-configuration suggests no packages.

Versions of packages keyboard-configuration is related to:
ii  console-common  0.7.88
ii  console-data2:1.12-5
pn  console-tools   
ii  kbd 1.15.5-2

-- debconf information:
  keyboard-configuration/variantcode: dvorak
  keyboard-configuration/modelcode: pc105
  keyboard-configuration/other:
  keyboard-configuration/layout:
  keyboard-configuration/altgr: The default for the keyboard layout
  keyboard-configuration/toggle: No toggling
  keyboard-configuration/store_defaults_in_debconf_db: true
  keyboard-configuration/unsupported_layout: true
  keyboard-configuration/ctrl_alt_bksp: false
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/layoutcode: us
  keyboard-configuration/unsupported_options: true
  keyboard-configuration/switch: No temporary switch
* keyboard-configuration/unsupported_config_options: true
  keyboard-configuration/xkb-keymap: us(dvorak)
* keyboard-configuration/model: Generic 105-key (Intl) PC
  keyboard-configuration/optionscode: ctrl:nocaps
* keyboard-configuration/variant: English (US) - English (Dvorak)
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/compose: No compose key

Bug#790392: unbound chroot accumulates old files

[Simon Deziel]

Hi Robert,

On 12/12/2015 05:08 PM, Robert Edmonds wrote:
> Hi, Simon:
> 
> The chroot directory might be configured by a file in
> /etc/unbound/unbound.conf.d/*.conf, rather than in the main unbound.conf
> file.

Good point, this needs to be supported.

> What do you think of setting UNBOUND_CONF like this instead?
> 
> CHROOT_DIR="$(unbound-checkconf -o chroot)"

I tried it initially but it doesn't work:

# unbound-checkconf -o chroot
[1450106598] unbound-checkconf[11733:0] fatal error: config file
/etc/unbound/unbound.conf is not inside chroot /var/lib/unbound

Yet the unbound.conf does exist in the chroot:

# ll /var/lib/unbound/etc/unbound/unbound.conf
-rw-r--r-- 1 root root 2737 Nov 25 13:11
/var/lib/unbound/etc/unbound/unbound.conf

So this (bug?) requires to always pass the path to the chrooted config
file to unbound-checkconf when using a chroot.

# unbound-checkconf -o interface
[1450109011] unbound-checkconf[15475:0] fatal error: config file
/etc/unbound/unbound.conf is not inside chroot /var/lib/unbound

# unbound-checkconf /var/lib/unbound/etc/unbound/unbound.conf \
-o interface
127.0.0.1
::1


I've updated the patch to support setting the chroot anywhere in
unbound.conf, not just the main config file. Please let me know what you
think of the proposed workaround.

Regards,
Simon
--- /etc/init.d/unbound.orig	2015-06-28 13:38:39.604171157 -0400
+++ /etc/init.d/unbound	2015-12-14 10:56:13.688340726 -0500
@@ -21,7 +21,7 @@
 UNBOUND_ENABLE=true
 UNBOUND_CONF=/etc/unbound/unbound.conf
 UNBOUND_BASE_DIR=$(dirname $UNBOUND_CONF)
-CHROOT_DIR=$(awk '{if ($1 ~ "^chroot" && $2 != "\"\"") print $2}' $UNBOUND_CONF|sed -e "s#\"##g")
+CHROOT_DIR=$(awk '{if ($1 ~ "^chroot" && $2 != "\"\"") print $2}' $(find $UNBOUND_BASE_DIR -name '*.conf')|sed -e 's#"##g'|head -n1)
 ROOT_TRUST_ANCHOR_UPDATE=false
 ROOT_TRUST_ANCHOR_FILE=/var/lib/unbound/root.key
 RESOLVCONF=false
@@ -93,8 +93,9 @@
 
 do_chroot_setup() {
 if [ -d "$CHROOT_DIR" -a "$CHROOT_DIR" != "$UNBOUND_BASE_DIR" ]; then
+rm -rf $CHROOT_DIR/$UNBOUND_BASE_DIR && mkdir -p $CHROOT_DIR/$UNBOUND_BASE_DIR
 cd /
-tar --overwrite -cf - $(echo $UNBOUND_BASE_DIR | sed 's#^/##') | (cd $CHROOT_DIR && tar -xf -)
+tar -cf - $(echo $UNBOUND_BASE_DIR | sed 's/^\///') | (cd $CHROOT_DIR && tar -xf -)
 fi
 }
 


signature.asc
Description: OpenPGP digital signature

Bug#701656: cloning 701656 ..., reassign -1 to base-installer ...

[Jonathan Dowland]

Hi all, I hit this last week. I was doing an expert mode install of jessie onto
a PowerPC Mac Mini. I had a USB keyboard attached during install time and I did
not remove it. However, I was doing both an expert-mode install and using the 
remote console via ssh feature of the installer (not sure if that has any 
bearing).
I opted for targetted thinking "why not?" when asked by the installer.

Some notes, following up on a few points from the various threads for this bug

1) I saw some comment hoping this would be resolved in time for 7.0: sadly, it
   wasn't, and is present in 8.0.

2) as mentioned above, the issue is not just whether given hardware is present
   or not at kernel install time. My USB keyboard was attached, and yet 
targetted
   did not include the necessary drivers for boot-time passphrase entering.

I imagine that the targetted prompt doesn't show up for normal installs, but if
it does, I would suggest not showing it if the user has opted for an encrypted
disk during the partman stages.

Obviously the prompt will appear during expert-mode installs, so I'd echo some
of the previous comments that it should be re-worded. I'm not sure whether 
different
wording could be offered depending on whether encryption was selected during the
partman stages?

I think there still remains an actual bug in the targetted module selection
logic relating to USB devices on the PowerPC Mac Mini.


-- 
Jonathan Dowland

Bug#794311: KiCad 4.0 rc1

[Nick Østergaard]

FYI https://lists.launchpad.net/kicad-developers/msg21521.html

If that is accepted, that should get rid of the openssl dependency.

2015-11-02 19:14 GMT+01:00 Gregor Riepl :
>> Sorry, I rephrase: Kicad 4.0.0~rc1 is *not* installable in a Jessie
>> environment now, as long as you want to keep other packages qui depend on
>> libc prior to gcc-5.
>
> Ah, that makes more sense.
> I was only testing on stretch, where things are (mostly) settled in favor of
> gcc5 AFAIK. Does jessie have any gcc5 packages yet?
>
>>> Maybe a modification to use gnutls instead is possible?
>>> I'll post a request to Launchpad, if that makes sense to you.
>>
>> It does make sense, because of the Lintian error which is triggered.
>> There are three complementary ways to fix the license issue:
>>
>> 1 - no direct link from the GPLed code to OpenSSL libraries : when
>> necessary, a command implying OpenSSL stuff is forked in another
>> thread
>> 2 - get a special authorization to link OpenSSL's library with Kicad's
>> GPLed code
>> 3 - use gnutls instead of openssl.
>>
>> I fear that in either case this job is not a priority for Kicad's
>> developers: they got avhttp from a third party and did not modify it.
>> Avhttp comes with Boost license, which does not harm. However if you
>> take a look at
>> https://github.com/avplayer/avhttp/blob/master/CMakeLists.txt, you see
>> that it will try to link OpenSSL libraries, which are mandatory to
>> access Github now.
>
> HTTPS is generally good, the 3rd party library not so much, in this case.
> Another option would be to use libcurl+gnutls instead, but I'm sure this will
> meet some resistance as it has little use on non-Debian.
> I believe there is no common SSL API in libcurl or libcurlpp, so it will be a
> very specific dependence.
>
>>> Georges, did you post your build scripts somewhere public so I can do a 
>>> local
>>> test build and cross-examine?
>>
>> The full source package is the pool, see
>> http://debian.bononia.it/debian/pool/main/k/kicad/kicad_4.0.0~rc1-1.dsc
>>
>> Thank you in advance for the help, I shall wait your response before
>> uploading the backport for Jessie. (the only difference is a build
>> dependency on boost1.55 rather than boost1.58)
>
> Thank you!
> I'll give it a shot later.
>
>

Bug#807906: zsh-common: Command completion broken since aptitude 0.7.5

[Micha Moskovic]

Package: zsh-common
Version: 5.2-2
Severity: normal

Dear Maintainer,

since updating aptitude to version 0.7.5-1, the command completion for aptitude
is broken.
Pressing tab after writing aptitude on the command line has the following
result:

$ aptitude 
 -- no matches found --

while it would print the list of available commands in previous version of
aptitude.
Note that option completion ($ aptitude -) and package completion ($
aptitude install ) still work.
I believe that this is due to one of the following changes in aptitude 0.7.5-1
(from the changelog)

- User visible changes:
  * [cmdline] Minor improvements to help (Closes: #497136)
  * [cmdline] Hide Show-Why reasons when the string is empty
(Closes: #576584)
  * [cmdline] Slightly improve and reformat --help
  * [cmdline] Document add/remove-user-tag in --help

given that the output of 'aptitude -h' is parsed in order to provide the
command completions.
Line 83 of Completion/Debian/Command/_aptitude probably needs to be modified in
order to account for those recent changes in aptitude.



-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version Architecture  
  Description
+++-=-===-===-
ii  mpv   0.12.0-1amd64 
  video player based on MPlayer/mplayer2
ii  pulseaudio7.1-2   amd64 
  PulseAudio sound server
ii  systemd   228-2   amd64 
  system and service manager
ii  udev  228-2   amd64 
  /dev/ and hotplug management daemon
ii  vlc-nox   2.2.1-5+b1  amd64 
  multimedia player and streamer (without X support)

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh-common depends on:
ii  dpkg  1.18.3

Versions of packages zsh-common recommends:
ii  zsh  5.2-2

Versions of packages zsh-common suggests:
pn  zsh-doc  

-- no debconf information

Bug#807915: mono-addins: FTBFS with new mono, upgrade to 1.2 release?

[Dimitri John Ledkov]

Would something like attached work?
Description: set target framework to 4.5.
Author: Dimitri John Ledkov 

--- mono-addins-1.2.orig/Mono.Addins.CecilReflector/Mono.Addins.CecilReflector.csproj
+++ mono-addins-1.2/Mono.Addins.CecilReflector/Mono.Addins.CecilReflector.csproj
@@ -11,7 +11,7 @@
 Mono.Addins.CecilReflector
 True
 ..\mono-addins.snk
-v4.0
+v4.5
   
   
 True
--- mono-addins-1.2.orig/Mono.Addins.Gui/Mono.Addins.Gui.csproj
+++ mono-addins-1.2/Mono.Addins.Gui/Mono.Addins.Gui.csproj
@@ -11,7 +11,7 @@
 Mono.Addins.Gui
 True
 ..\mono-addins.snk
-v4.0
+v4.5
   
   
 True
--- mono-addins-1.2.orig/Mono.Addins.MSBuild/Mono.Addins.MSBuild.csproj
+++ mono-addins-1.2/Mono.Addins.MSBuild/Mono.Addins.MSBuild.csproj
@@ -11,6 +11,7 @@
 Mono.Addins.MSBuild
 True
 ..\mono-addins.snk
+v4.5
   
   
 True
--- mono-addins-1.2.orig/Mono.Addins.Setup/Mono.Addins.Setup.csproj
+++ mono-addins-1.2/Mono.Addins.Setup/Mono.Addins.Setup.csproj
@@ -11,7 +11,7 @@
 Mono.Addins.Setup
 True
 ..\mono-addins.snk
-v4.0
+v4.5
   
   
 True
--- mono-addins-1.2.orig/Mono.Addins/Mono.Addins.csproj
+++ mono-addins-1.2/Mono.Addins/Mono.Addins.csproj
@@ -11,7 +11,7 @@
 Mono.Addins
 True
 ..\mono-addins.snk
-v4.0
+v4.5
   
   
 True
--- mono-addins-1.2.orig/mautil/mautil.csproj
+++ mono-addins-1.2/mautil/mautil.csproj
@@ -9,6 +9,7 @@
 mautil
 2.0
 mautil
+v4.5
   
   
 True

Bug#807928: [plantuml] plantuml does not render to PDF

[Daniel Hornung]

On Monday 14 December 2015 16:11:28 you wrote:
> Hello,
> 
> About PDF generations, you have to install several supplementary jar files:
> avalon-framework-4.2.0.jar
> batik-all-1.7.jar
> commons-io-1.3.1.jar
> commons-logging-1.0.4.jar
> fop.jar
> xml-apis-ext-1.3.04.jar
> xmlgraphics-commons-1.4.jar
> 
> You will find some details on http://plantuml.com/pdf.html
> 
> Tell us if it's working for you.
> 
> Regards,
> 
> Arnaud Roques

Hi,

it's the same whether I explicitly set the classpath to the local location 
(shouldn't that be found automatically?) or a folder with the jars from your 
site.

System jars:

$ java -jar /usr/share/plantuml/plantuml.jar -cp /usr/share/java/ -tpdf 
data_model.plant_uml.pu
Exception in thread "main" java.lang.UnsupportedOperationException: PDF
at 
net.sourceforge.plantuml.ugraphic.ImageBuilder.createUGraphic(Unknown Source)
at 
net.sourceforge.plantuml.ugraphic.ImageBuilder.writeImageTOBEMOVED(Unknown 
Source)
at 
net.sourceforge.plantuml.ugraphic.ImageBuilder.writeImageTOBEMOVED(Unknown 
Source)
at net.sourceforge.plantuml.PSystemError.exportDiagram(Unknown Source)
at net.sourceforge.plantuml.PSystemUtils.exportDiagramsDefault(Unknown 
Source)
at net.sourceforge.plantuml.PSystemUtils.exportDiagrams(Unknown 
Source)
at 
net.sourceforge.plantuml.SourceFileReader.getGeneratedImages(Unknown Source)
at net.sourceforge.plantuml.Run.manageFileInternal(Unknown Source)
at net.sourceforge.plantuml.Run.processArgs(Unknown Source)
at net.sourceforge.plantuml.Run.manageAllFiles(Unknown Source)
at net.sourceforge.plantuml.Run.main(Unknown Source)

Local jars, from the zip file:

$ java -jar /usr/share/plantuml/plantuml.jar -cp ./jars/ -tpdf 
data_model.plant_uml.pu
Exception in thread "main" java.lang.UnsupportedOperationException: PDF
at 
net.sourceforge.plantuml.ugraphic.ImageBuilder.createUGraphic(Unknown Source)
at 
net.sourceforge.plantuml.ugraphic.ImageBuilder.writeImageTOBEMOVED(Unknown 
Source)
at 
net.sourceforge.plantuml.ugraphic.ImageBuilder.writeImageTOBEMOVED(Unknown 
Source)
at net.sourceforge.plantuml.PSystemError.exportDiagram(Unknown Source)
at net.sourceforge.plantuml.PSystemUtils.exportDiagramsDefault(Unknown 
Source)
at net.sourceforge.plantuml.PSystemUtils.exportDiagrams(Unknown 
Source)
at 
net.sourceforge.plantuml.SourceFileReader.getGeneratedImages(Unknown Source)
at net.sourceforge.plantuml.Run.manageFileInternal(Unknown Source)
at net.sourceforge.plantuml.Run.processArgs(Unknown Source)
at net.sourceforge.plantuml.Run.manageAllFiles(Unknown Source)
at net.sourceforge.plantuml.Run.main(Unknown Source)

The problem that the library can not be found goes away in both cases, but the 
second exception remains.



-- 
Max-Planck-Institute for Dynamics and Self-Organization
Research Group Biomedical Physics

Am Fassberg 17
D-37077 Goettingen
(+49) 551 5176 373

You can obtain my public key 0xF197B128 from all keyservers, e.g. pgp.mit.edu
Fingerprint: 9698 BDD4 71CC 1274 B7E2  2049 1EDD 012D F197 B128


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