Bug#818724: RFS: task-spooler/0.7.6-1

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Sun, Mar 20, 2016 at 07:59:35AM +0300, Alexander Inyukhin wrote:
> I am looking for a sponsor for my package "task-spooler"

sure thing :)

>   dget -x 
> http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.7.6-1.dsc
> 
> Changes since the last upload:
> 
>* Imported Upstream version 0.7.6
>* Update patches
>* Bump standards version to 3.9.7
>* Use https for VCS-* fields

though you got Vcs-Git wrong, you can't use /cgit/ to clone.
I suggest you just use /git/ for both fields, which has been valid for a
bit more than a month.

>* Fix typo as suggested by lintian


I see there patches with Last-Update: 2012, both marked as "Forwarded:
yes" and without Forwarded header.  I wonder, since 2012 it has not been
applied?? (particularly weird for cppcheck.patch).
Also, note that the Forwarded field should either be "no", "not-needed"
or some pointers to where it has been forwarded (like a url to some bug
thing).

also, about d/copyright: I assume some years should be bumped, and I see
this weird diff from the previous upload:

- This package is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; version 2 of the License.
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License
+ as published by the Free Software Foundation.

why does it loses the version??
Without considering that those copyright changes are not documented in
d/copyright.

and btw, having debian/* GPL-2+ technically makes upstream unable to
pull patches from debian/patches/*, as GPL-2+ is incompatible with
GPL-2 (only).

-- 
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#818624: RFS: r-cran-pbdzmq/0.2.1+dfsg-2

[Mattia Rizzolo]

control: block -1 by 818622

also, I just tried to build it and noticed it requires this other
package to be ready before.  please next time block RFS which depends on
other RFS like this ↑

(sorry for the double email, I accidentally typoed the bug email address
in the other email)

On Sun, Mar 20, 2016 at 05:24:57AM +, Mattia Rizzolo wrote:
> control: tag -1 moreinfo
> control: owner -1 !
> 
> On Fri, Mar 18, 2016 at 08:49:21PM +0100, Gordon Ball wrote:
> >   I am looking for a sponsor for my package "r-cran-pbdzmq"
> 
> hi there (3rd time ;))
> 
> > http://mentors.debian.net/debian/pool/main/r/r-cran-pbdzmq/r-cran-pbdzmq_0.2.1+dfsg-2.dsc
> 
> this looks nicer from a license POV, at least!
> 
> * debian/changelog:
>   + what happened to version -1 ?
> * debian/control:
>   + (Build-)Depends are not sorted, please sort them (wrap-and-sort(1)
> and cme(1) may help here)
>   + outdated Standards-Version
>   + very very short extended descript, please make it longer
> * DESCRIPTIONS:
>   + the Copyright field points to non-existant files, that may actually
> be interesting to read, where are they? (I see one is excluded in
> d/copyright, why?)
> * inst/doc/pbdZMQ-guide.pdf
>   + PDFs are tricky [1], and should be stripped out of the tarball and
> built at build time, it surely looks feasible, may you do it?
> * debian/tests:
>   + I wonder if an autodep8 thing for R would make sense, after having
> seen 3 quasi-identical tests for 3 different R packages
> 
> 
> [1] https://ftp-master.debian.org/REJECT-FAQ.html (grep for PDF)
> 
> -- 
> 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  `-



-- 
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#818624: RFS: r-cran-pbdzmq/0.2.1+dfsg-2

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Fri, Mar 18, 2016 at 08:49:21PM +0100, Gordon Ball wrote:
>   I am looking for a sponsor for my package "r-cran-pbdzmq"

hi there (3rd time ;))

> http://mentors.debian.net/debian/pool/main/r/r-cran-pbdzmq/r-cran-pbdzmq_0.2.1+dfsg-2.dsc

this looks nicer from a license POV, at least!

* debian/changelog:
  + what happened to version -1 ?
* debian/control:
  + (Build-)Depends are not sorted, please sort them (wrap-and-sort(1)
and cme(1) may help here)
  + outdated Standards-Version
  + very very short extended descript, please make it longer
* DESCRIPTIONS:
  + the Copyright field points to non-existant files, that may actually
be interesting to read, where are they? (I see one is excluded in
d/copyright, why?)
* inst/doc/pbdZMQ-guide.pdf
  + PDFs are tricky [1], and should be stripped out of the tarball and
built at build time, it surely looks feasible, may you do it?
* debian/tests:
  + I wonder if an autodep8 thing for R would make sense, after having
seen 3 quasi-identical tests for 3 different R packages


[1] https://ftp-master.debian.org/REJECT-FAQ.html (grep for PDF)

-- 
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#818623: RFS: r-cran-uuid/0.1.2-4

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Fri, Mar 18, 2016 at 08:47:33PM +0100, Gordon Ball wrote:
>   I am looking for a sponsor for my package "r-cran-uuid"
> 
>  * Package name: r-cran-uuid
>Version : 0.1.2-4
>Upstream Author : Simon Urbanek 
>  * URL : http://www.rforge.net/uuid
>  * License : MIT + bsd-3-clause
>Section : gnu-r
>
> http://mentors.debian.net/debian/pool/main/r/r-cran-uuid/r-cran-uuid_0.1.2-4.dsc

same thing as the other, MIT license no better specified with no copy
of it in the tarball.

then, as lintian says:
W: r-cran-uuid source: out-of-date-standards-version 3.9.6 (current is 3.9.7)
I: r-cran-uuid: extended-description-is-probably-too-short
W: r-cran-uuid: extra-license-file usr/lib/R/site-library/uuid/LICENSE

-- 
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#818724: RFS: task-spooler/0.7.6-1

[Alexander Inyukhin]

Package: sponsorship-requests
Severity: normal


Dear mentors,

I am looking for a sponsor for my package "task-spooler"

 * Package name: task-spooler
   Version : 0.7.6-1
   Upstream Author : Lluís Batlle i Rossel 
 * URL : http://vicerveza.homeunix.net/~viric/soft/ts/
 * License : GPLv2+
   Section : misc

It builds those binary packages:

  task-spooler - personal job scheduler

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/task-spooler

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.7.6-1.dsc

Changes since the last upload:

   * Imported Upstream version 0.7.6
   * Update patches
   * Bump standards version to 3.9.7
   * Use https for VCS-* fields
   * Fix typo as suggested by lintian

Regards,
   Alexander Inyukhin

Bug#818622: RFS: r-cran-r6/2.1.2-1

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Fri, Mar 18, 2016 at 08:47:27PM +0100, Gordon Ball wrote:
>   I am looking for a sponsor for my package "r-cran-r6"

here we go :)

>  * Package name: r-cran-r6
>Version : 2.1.2-1
>Upstream Author : Winston Chang 
>  * URL : https://github.com/wch/R6
>  * License : MIT
>Section : gnu-r
> 
> http://mentors.debian.net/debian/pool/main/r/r-cran-r6/r-cran-r6_2.1.2-1.dsc

well, it looks good (even if it uses CDBS which I don't like, but I know
there is the well-maintained r-base-dev that works pretty well for R).

though, you wrote that this packages uses the MIT license (though you
maybe want "Expat" instead), except for citing the MIT license in the
DESCRPTION file, I can't find any copy of the license itself.  This is
actually a violation of the MIT.
Please clarify 1) how you could know upstream intended *that* MIT
license (there are several, you reported the most common one called
Expat) 2) really upstream needs to ship one copy of it.

-- 
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#818536: qt5-qmake missing dependency

[Dmitry Shachnev]

Hi Lisandro,

On Fri, Mar 18, 2016 at 09:12:17AM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> [...]
>
> Now this is (kind of) a bug. Is there any usage for qt5-qmake if you don't
> have at least qtbase5-dev installed?

Sure. qmake is a generic build system and can be used for building non-Qt
applications (with CONFIG -= qt). This should be fixed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#818510: upgrade-reports: excellent upgrade experience on Lenovo E431

[anarcat]

Package: upgrade-reports
Severity: minor

I just upgraded my friend's laptop from the latest Wheezy to the latest Jessie
without a hitch! 

Things went really smoothly. I changed the sources.list by hand, ran apt-get
upgrade; apt-get dist-upgrade and everything went almost perfectly.

For some reason, db5.1-util and unoconv were not correctly upgraded on
dist-upgrade. Running dist-upgrade fixed the latter, but not the former. I
eneded up just purging db5.1-util.

autoremove didn't catch everything: a bunch of packages were "obsolete"
according to aptitude and I had to remove those by hand. it would be nice if
the upgrade process would cover those as well. this includes python 2.6, the
older kernel, openjdk 6, gcc 4.6 and a bunch more random libs that clutter the
system.

otherwise everything seems to be going well so far. the user's only complaint
so far is that the minimize button is gone from gnome, but she figured out she
can click on the window in the window list to achieve the same result.

mission accomplished! although ideally, *she* would have been able to do the
upgrade herself. maybe next time!

a.

PS: this is not really a bug report, more of a "good job" to whoever is
receiving those messages. :) of course if you think some bug reports should be
open for specific issues, I'll be glad to follow any pointer!

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

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

Bug#815205: sbcl: FTBFS due to TeX error

[Christoph Egger]

Hi!

Norbert Preining  writes:
> I sent already a minimal example derived from the sbcl code to the ti
> list, you should have gotten it cc

just seen it minutes after sending the email. Thanks for the fast
reaction!

  Christoph

Bug#818532: jessie-pu: package libdatetime-timezone-perl/1.75-2+2016b

[gregor herrmann]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've prepared an update for libdatetime-timezone-perl in jessie with
the data from the Olson db 2016b. As usual, the only change is a
quilt patch which adjusts the pm files containing the timezone data.
(Plus a typo fix in the changelog this time.)

Manually stripped down debdiff attached.

Cheers,
gregor

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJW6wntXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGRHgP/jnZNENC7B4FdmlhzVlSn+AS
ONitgz+BOf0VgvYVlK9YSCIinyeed4cjuT5QTKoDShKtbesiNnRawkMl8wJ90dmT
ISceY4XCJyhtPJWWb7xq9Im6cHypFzX/D1NVPHlgt/nzhIgAa7ilf8jnhqDnt4uG
DI+Cspy8vLySpiXsdnSnN30rQJOL/GPeGkOpP9XW67vaMzATsf7wgxreAPeZoxiT
WWrSdjVzxNlezzDkzSAT6PS5F9c33SECEBhJQSg4viX9ezU3w4BxHJ1hCFrbS7Af
rTizspiOWkswl4Cb1JCWJ9TsWdO6RbdGcb/OcPoueT0IvxF1x3aHLaIkHu/lNKyV
NzJ17yyR35LqeEZFZgA+FVPJ1kiajQ+64dtKBg9gpR7x6PcTAaZ2lj0e4aqtCT7l
pnO2RH+QNH6T/ndwl88h4OqKGXnTL4GPqw4VmmNoqIXdo2frxO3O8381WvTAb3PQ
zBdtwt/Fmo3OFAD6Me7RXB9Bswhy/5PPYGbunRtgpme2hIWgnWOKtLc2ACI3tkd+
E0czGo9xtlwgZfKd+JymOaLja/6LaRsHl2E8bJr8uCIdXbqSSMASwfPnIBFh0jnh
SEE+6k6Fs2LuAUdB6CGrkVNWWoXOZXtZ7uf96I7QfgEUUkDcenFPhnAJLcvmyFUI
dEzPt2J2srCcdMfp7L/L
=sTXA
-END PGP SIGNATURE-
diff -Nru libdatetime-timezone-perl-1.75/debian/changelog libdatetime-timezone-perl-1.75/debian/changelog
--- libdatetime-timezone-perl-1.75/debian/changelog	2016-02-03 20:43:20.0 +0100
+++ libdatetime-timezone-perl-1.75/debian/changelog	2016-03-17 20:23:04.0 +0100
@@ -1,10 +1,22 @@
+libdatetime-timezone-perl (1:1.75-2+2016b) UNRELEASED; urgency=medium
+
+  * Update to Olson database version 2016b.
+Add patch debian/patches/olson-2016b, which updates the timezone *.pm
+files, using upstream's tools/parse_olson script.
+This update contains contemporary changes for Russia, Haiti, and
+Palestine.
+  * Fix spelling of Chita in the previous changelog entry.
+Thanks to Stepan Golosunov for the bug report. (Closes: #813631)
+
+ -- gregor herrmann   Thu, 17 Mar 2016 20:22:46 +0100
+
 libdatetime-timezone-perl (1:1.75-2+2016a) jessie; urgency=medium
 
   * Update to Olson database version 2016a.
 Add patch debian/patches/olson-2016a, which updates the timezone *.pm
 files, using upstream's tools/parse_olson script.
 This update contains contemporary changes for the Cayman Islands, Iran,
-and Chrita, Russia.
+and Chita, Russia.
 
  -- gregor herrmann   Wed, 03 Feb 2016 20:40:57 +0100
 
diff -Nru libdatetime-timezone-perl-1.75/debian/patches/olson-2016b libdatetime-timezone-perl-1.75/debian/patches/olson-2016b
--- libdatetime-timezone-perl-1.75/debian/patches/olson-2016b	1970-01-01 01:00:00.0 +0100
+++ libdatetime-timezone-perl-1.75/debian/patches/olson-2016b	2016-03-17 20:23:04.0 +0100
@@ -0,0 +1,13321 @@
+Description: update to olson db 2016b
+Origin: vendor
+Author: gregor herrmann 
+Last-Update: 2016-03-17
+
+--- a/lib/DateTime/TimeZone/Africa/Abidjan.pm
 b/lib/DateTime/TimeZone/Africa/Abidjan.pm
+@@ -3,7 +3,7 @@
+ # DateTime::TimeZone module distribution in the tools/ directory
+ 
+ #
+-# Generated from debian/tzdata/africa.  Olson data version 2016a
++# Generated from debian/tzdata/africa.  Olson data version 2016b
+ #
+ # Do not edit this file directly.
+ #
+@@ -39,7 +39,7 @@
+ ],
+ ];
+ 
+-sub olson_version { '2016a' }
++sub olson_version { '2016b' }
+ 
+ sub has_dst_changes { 0 }
+ 
+--- a/lib/DateTime/TimeZone/Catalog.pm
 b/lib/DateTime/TimeZone/Catalog.pm
+@@ -179,6 +179,7 @@
+   Asia/Baghdad
+   Asia/Baku
+   Asia/Bangkok
++  Asia/Barnaul
+   Asia/Beirut
+   Asia/Bishkek
+   Asia/Brunei
+@@ -270,6 +271,7 @@
+   EST5EDT
+   Europe/Amsterdam
+   Europe/Andorra
++  Europe/Astrakhan
+   Europe/Athens
+   Europe/Belgrade
+   Europe/Berlin
+@@ -303,6 +305,7 @@
+   Europe/Stockholm
+   Europe/Tallinn
+   Europe/Tirane
++  Europe/Ulyanovsk
+   Europe/Uzhgorod
+   Europe/Vienna
+   Europe/Vilnius
+@@ -551,6 +554,7 @@
+ Baghdad
+ Baku
+ Bangkok
++Barnaul
+ Beirut
+ Bishkek
+ Brunei
+@@ -643,6 +647,7 @@
+   'Europe' => [ qw(
+ Amsterdam
+ Andorra
++Astrakhan
+ Athens
+ Belgrade
+ Berlin
+@@ -676,6 +681,7 @@
+ Stockholm
+ Tallinn
+ Tirane
++Ulyanovsk
+ Uzhgorod
+ Vienna
+ Vilnius
+@@ -763,15 +769,15 @@
+ ) ],
+   'aq' => [ qw(
+ Antarctica/McMurdo
+-Antarctica/Rothera
+-Antarctica/Palmer
+-Antarctica/Mawson
+-Antarctica/Davis
+ Antarctica/Casey
+-Antarctica/Vostok
++Antarctica/Davis
+ Antarctica/DumontDUrville
++Antarctica/Mawson
++Antarctica/Palmer
++Antarctica/Rothera
+ Antarctica/Syowa
+ Antarctica/Troll
++Antarctica/Vostok
+ ) ],
+   'ar' 

Bug#818313: [pkg-otr-team] Bug#818313: Bug#818313: off-the-record (OTR) plugin actually logs conversations

[Antoine Beaupré]

On 2016-03-16 11:37:51, micah wrote:
>> Yes. In fact, I think it compromises the "encryption", "PFS" and
>> "deniability" aspects of the protocol, to be more specific.
>
> It doesn't cryptographically.
>
> You cannot take an OTR conversation that has been logged through an
> external means and prove cryptographically that this conversation
> actually happened.

I stand corrected on the "deniability" aspect, but the PFS and
encryption aspects still stand, and they are, in my opinion, critical.

A.

-- 
Imagine a world in which every single person on the planet is given
free access to the sum of all human knowledge.
 - Jimmy Wales, co-founder of Wikipedia

Bug#817244: exim4-base: cron noise re environment

[Adam D. Barratt]

On Thu, 2016-03-17 at 15:38 -0400, shiz...@teksavvy.com wrote:
> Package: exim4-base
> Version: 4.84.2-1
> Followup-For: Bug #817244
> 
> Dear Maintainer,
> 
> Some supplemental information would be appreciated.
> 
> I've edited update-exim4.conf.conf
> and added
> add_environment='<; PATH=/bin:/usr/bin'
> keep_environment=''
> one by one then both

You can't just add random lines to update-exim4.conf.conf and expect
them to end up in your exim configuration.

> I've also edited exim4.conf.template
> and added

The information automatically added to your bug report says:

Configuration file is /etc/exim4/exim4.conf

so that's the file you need to be editing.

Regards,

Adam

Bug#818504: RM: giws -- ROM; not used, pretty much dead

[Sylvestre Ledru]

Package: ftp.debian.org
Severity: normal


Hello,
As both Debian maintainer and former upstream developer, I think we should
remove giws from the archive.
The popcon is 12! I was the main developer and I stopped working on it.
Nobody took the lead on it and, afaik, it is only used by Scilab and
they ship the generated sources directly.

Sylvestre

Bug#817244: exim4-base: cron noise re environment

[shizuma]

Package: exim4-base
Version: 4.84.2-1
Followup-For: Bug #817244

Dear Maintainer,

Some supplemental information would be appreciated.

I've edited update-exim4.conf.conf
and added
add_environment='<; PATH=/bin:/usr/bin'
keep_environment=''
one by one then both

I've also edited exim4.conf.template
and added

.ifdef MAIN_KEEP_ENVIRONMENT
keep_environment = MAIN_KEEP_ENVIRONMENT
.else
# set option to empty value to avoid warning.
keep_environment =
.endif
.ifdef MAIN_ADD_ENVIRONMENT
add_environment = MAIN_ADD_ENVIRONMENT
.endif

then replaced with 
#.ifdef MAIN_KEEP_ENVIRONMENT
#keep_environment = MAIN_KEEP_ENVIRONMENT
#.else
## set option to empty value to avoid warning.
keep_environment =
#.endif
#.ifdef MAIN_ADD_ENVIRONMENT
#add_environment = MAIN_ADD_ENVIRONMENT
#.endif

Between each edits, I've ran as root 
update-exim4.conf
and service exim4 reload

Nothing helped, the exim mainlog is still reporting

2016-03-17 15:30:03 Warning: purging the environment.
 Suggested action: use keep_environment.
2016-03-17 15:30:21 Warning: purging the environment.
 Suggested action: use keep_environment.
2016-03-17 15:35:02 Warning: purging the environment.
 Suggested action: use keep_environment.

every 5 minutes.

Thanks.

-- Package-specific info:
Exim version 4.84_2 #1 built 13-Mar-2016 17:47:17
Copyright (c) University of Cambridge, 1995 - 2014
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2014
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 PAM Perl Expand_dlfunc GnuTLS 
move_frozen_messages Content_Scanning DKIM Old_Demime PRDR OCSP
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch ldap ldapdn ldapm mysql nis nis0 passwd pgsql sqlite
Authenticators: cram_md5 cyrus_sasl dovecot plaintext spa
Routers: accept dnslookup ipliteral iplookup manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /etc/exim4/exim4.conf
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='dailyplanet.net'
dc_local_interfaces=''
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='smtp.teksavvy.com'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='false'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
smtp_receive_timeout='300s'
add_environment='<; PATH=/bin:/usr/bin'
keep_environment=''
mailname:teksavvy.com

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

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

Versions of packages exim4-base depends on:
ii  adduser3.113+nmu3
ii  cron [cron-daemon] 3.0pl1-127+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  exim4-config [exim4-config-2]  4.84.2-1
ii  libc6  2.19-18+deb8u3
ii  libdb5.3   5.3.28-9
ii  lsb-base   4.1+Debian13+nmu1
ii  netbase5.3

Versions of packages exim4-base recommends:
ii  bsd-mailx [mailx]  8.1.2-0.20141216cvs-2
ii  perl-modules   5.20.2-3+deb8u4
ii  psmisc 22.21-2

Versions of packages exim4-base suggests:
ii  bsd-mailx [mail-reader]  8.1.2-0.20141216cvs-2
ii  emacs24 [mail-reader]24.4+1-5
pn  exim4-doc-html | exim4-doc-info  
pn  eximon4  
ii  file 1:5.22+15-2+deb8u1
ii  mutt [mail-reader]   1.5.23-3
ii  openssl  1.0.1k-3+deb8u4
pn  spf-tools-perl   
ii  swaks20130209.0-3
ii  xemacs21-mule [mail-reader]  21.4.22-14~deb8u1

-- debconf information:
  exim4-base/drec:
  exim4/purge_spool: false

Bug#815688: musescore: missing user manual

[Peter Jonas]

I maintain MuseScore packages for Ubuntu via the Launchpad PPA which are
based on the Debian packages.

Looking at the source package it appears that the PDF manual is removed by
a patch for compliance with Debian's Free Software Guidelines. However, the
upstream version no longer includes the manual as a PDF so this patch is
now obsolete.

Note to the Debian maintainer:
In fact, all of the Debian patches will become obsolete with the next
upstream release, including "02-do-not-update-mime-during-build.patch" due
to the option to suppress the mime update via the Makefile override "make
UPDATE_CACHE=FALSE install".

Peter

Bug#806716: Jellyfish name conflicts

[Diego M. Rodriguez]

Hello Andreas,

> H, ftpmaster was fast - now python-jellyfish is accepted.  This only
> leaves us option 2 without fiddling around to much.

I noticed - and feels like yet another argument in favour of option 2.
If there is something I can do to help with the renaming of the DNA
jellyfish python module (collaborating on the upstream repository,
gathering more opinions on the matter, or anything else) I'd be willing
to lend a hand, just let me know!

> > With this in mind, I'm wondering if this would be a good time to rename
> > this ITP and the RFS (and the mentors package, etc) to the hopefully
> > final Debian package name ("python-jellyfishstr"?)?
> 
> The latter sounds sensible.  Sorry for all the confusion and leaving you
> alone a bit with this issue.

Thanks for sharing your thoughts on the package renaming issue, and no
worries at all - I really apreciate your guidance and efforts on helping
move this issue forward.

Best regards,
-- 
Diego M. Rodriguez
36B3 42A9 9F2F 2CFB F79B  FF9B B6C4 B901 06BC E232



signature.asc
Description: Digital signature

Bug#818723: chromium: please document how chromium selects where to output sound

[Arthur Marsh]

Package: chromium
Version: 49.0.2623.87-1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?

Changing sound cards resulted in no sound in chromium even after the new
sound card was made default as documented at:
http://www.alsa-project.org/main/index.php/Asoundrc

It was only by running pavucontrol that I discovered that sound was being
output by chromium to the HDMI audio device and by disabling sound output 
in KDE to that device was able to get sound playing from chromium to the 
default sound card.

   * 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'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages chromium depends on:
ii  libasound21.1.0-1
ii  libatk1.0-0   2.18.0-1
ii  libavcodec-ffmpeg56   7:2.8.6-1+b2
ii  libavformat-ffmpeg56  7:2.8.6-1+b2
ii  libavutil-ffmpeg547:2.8.6-1+b2
ii  libc6 2.22-3
ii  libcairo2 1.14.6-1
ii  libcups2  2.1.3-2.0nosystemd1
ii  libdbus-1-3   1.10.8-1.0nosystemd1
ii  libexpat1 2.1.1-1
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.6.3-3
ii  libgcc1   1:6-20160313-1
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libglib2.0-0  2.46.2-3
ii  libgnome-keyring0 3.12.0-1+b1
ii  libgtk2.0-0   2.24.30-1
ii  libjpeg62-turbo   1:1.4.2-2
ii  libnspr4  2:4.12-1
ii  libnspr4-0d   2:4.12-1
ii  libnss3   2:3.23-1
ii  libnss3-1d2:3.23-1
ii  libpango-1.0-01.38.1-1
ii  libpangocairo-1.0-0   1.38.1-1
ii  libpci3   1:3.3.1-1.1
ii  libspeechd2   0.8-7
ii  libsrtp0  1.4.5~20130609~dfsg-1.1
ii  libstdc++66-20160313-1
ii  libx11-6  2:1.6.3-1
ii  libxcomposite11:0.4.4-1
ii  libxcursor1   1:1.1.14-1+b1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxi62:1.7.6-1
ii  libxml2   2.9.3+dfsg1-1
ii  libxrandr22:1.5.0-1
ii  libxrender1   1:0.9.9-2
ii  libxslt1.11.1.28-2.1
ii  libxss1   1:1.2.2-1
ii  libxtst6  2:1.2.2-1+b1
ii  x11-utils 7.7+3
ii  xdg-utils 1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  1.07.4-1

Versions of packages chromium suggests:
ii  chromium-l10n  49.0.2623.87-1

-- debconf-show failed

Bug#816261: RFS: django-prometheus/1.0.6-1

[Mattia Rizzolo]

control: tag -1 moreinfo
control: owner -1 !

On Mon, Feb 29, 2016 at 08:32:06AM +, Christopher Baines wrote:
> I am looking for a sponsor for "django-prometheus"

ay!

> http://mentors.debian.net/debian/pool/main/d/django-prometheus/django-prometheus_1.0.6-1.dsc
> It is also available on git.debian.org:
> https://anonscm.debian.org/cgit/python-modules/packages/django-prometheus.git/

DPMT package → ignoring mentors.d.n, just using the git repository

* debian/control:
  + lack of VCS information, this is mandatory in the team.
* debian/copyright:
  + please name the license "Apache-2.0"
  + why normal people don't put license and copyright on
the header of the files?? :(
* debian/rules:
  + you should be able to do that thing with the tests with pybuild
tooling, like by using (untested)
PYBUILD_TEST_ARGS="{interpreter} ./test/end2end/manage.py test 
--verbosity=2"
note that you may also need to cp the tests or cd to {dir}.
Please have a look at pybuild(1) and the wiki page
https://wiki.debian.org/Python/Pybuild for more information
  + what's that notice about automatically generated file?

Then, on github the newest tag is 1.0.5, but you are packaging 1.0.6,
which makes me think you are not using github by pypi (checking... not
even, the tarballs are different).  Where did you get that tarball?

-- 
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#818285: non-functional (at least in jessie-backports)

[Gaetano Guerriero]

On Tue, Mar 15, 2016 at 03:50:07PM +0100, Christoph Egger wrote:

> Seems to be dying on some SSL error, backtrace attached.
> 
> Christoph
> 
> /usr/lib/python3.4/http/client.py in __init__(self, host, port, key_file, 
> cert_file, timeout, source_address, context, check_hostname)
>1209 check_hostname = will_verify
>1210 elif check_hostname and not will_verify:
> -> 1211 raise ValueError("check_hostname needs a SSL context 
> with "
>1212  "either CERT_OPTIONAL or 
> CERT_REQUIRED")
>1213 if key_file or cert_file:
> 
> ValueError: check_hostname needs a SSL context with either CERT_OPTIONAL or 
> CERT_REQUIRED

httplib2 is quite buggy in ssl certificates validation.

This bug should be ideally fixed there, but mantainer seems not very responsive
lately (there is a relative bug opened with no response:
https://github.com/jcgregorio/httplib2/issues/324).

To keep it short, with python 3.4.2 (jessie) httplib2 sends wrong parameters to
underlying http.client, and there it breaks. With python 3.4.4 the default
validation policy changed so we have no problems on stretch (and no problems
with python 2.7 too).

I've have prepared a patch, if Bastian wants to merge it, that conditionally
forces validation for python3 < 3.4.3.
https://github.com/venthur/python-debianbts/pull/27

With this patch I got tests passing on stretch with python 2.7, 3.4.4 and 3.5.1,
and on jessie with python 2.7 and 3.4.2.


 Gaetano

Bug#816284: Testing against 1.10.2-10

[Mattia Rizzolo]

On Sat, Mar 12, 2016 at 07:23:42AM +, Alastair McKinstry wrote:
> This appears to be an openmpi issue.
> Tracking the fix: https://github.com/open-mpi/ompi/issues/1446
> 
> I'm testing the fix in experimental:: 1.10.2-10
> 


Indeed now the package builds on s390x and some other architectures
(powerpc, sparc64, armel, ppc64), but mpicc started to segfault in mips
and mipsel, do you have some clues about what may be wrong here?

https://buildd.debian.org/status/fetch.php?pkg=mpi4py=mips=2.0.0-1=1458163273


-- 
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#818442: initscripts: Failing /run/shm migration and wrong message

[Pierre Ynard]

Package: initscripts
Version: 2.88dsf-59.2
Severity: normal

During my boot sequence, when /etc/init.d/mountdevsubfs.sh is run, I get
the following logs:

> Filesystem mounted on /dev/shm; setting up compatibility bind mount.
> Please remove this mount from /etc/fstab; it is no longer needed, and it is 
> preventing completion of the transition to /run/shm.

My /etc/fstab features no /dev/shm, nor /run/shm, nor any pseudo
filesystem. So if nothing else we already have a problem in the form of
a wrong and confusing warning message.

Digging a little deeper, my system doesn't run udev and uses a static,
disk-backed /dev. It contains an empty /dev/shm/ directory. When looking
into /lib/init/mount-functions.sh it appears it tries to permanently
symlink /dev/shm to /run/shm, and prints the warning after it fails
to delete my /dev/shm/ directory. The warning assumes that this is
because it is a mount point, however it's not, and it is rather my
understanding that the old /dev/shm/ directory removal fails simply
because the filesystem is still read-only at that point.

I suppose that ideally, the script should migrate this properly, at a
time when the filesystem is read-write. At least, it should be modified
to print an accurate diagnosis and instructions on how to fix this
manually.

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

Kernel: Linux 4.4.4-grsec
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages initscripts depends on:
ii  coreutils   8.25-2
ii  debianutils 4.7
ii  lsb-base9.20160110
ii  mount   2.27.1-3
ii  sysv-rc 2.88dsf-59.2
ii  sysvinit-utils  2.88dsf-59.2

Versions of packages initscripts recommends:
ii  e2fsprogs  1.42.13-1
ii  psmisc 22.21-2.1

initscripts suggests no packages.

-- Configuration Files:
/etc/default/rcS changed [not included]

-- no debconf information

Bug#818557: RFS: windowlab/1.40-3

[Mats Erik Andersson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "windowlab"

  Package name: windowlab
  Version : 1.40-3
  Upstream Author : Nick Gravgaard 
  URL : http://nickgravgaard.com/windowlab/
  License : GPL-2 and AEWM and 9WM
  Section : x11

It builds a single binary package, containing a windowmanager:

  windowlab  - small and simple Amiga-like window manager

Further information about this package:

  http://mentors.debian.net/package/windowlab


The built package can be downloaded for inspection:

  dget -x 
http://mentors.debian.net/debian/pool/main/w/windowlab/windowlab_1.40-3.dsc

Changes since last upload:

  * Step Standards-Version to 3.9.7, no changes.
  * Advance debhelper compatibility to 9.
+ debian/control, debian/compat: Updated.
+ debian/rules: Reduce rule set to use dh together with hooks
  "override_dh_install" and "override_dh_installwm".
  * debian/windowlab.postrm: New file. (Closes: #806403).
  * debian/copyright: Use single word names for licenses AEWM and 9WM.
Correctly rebuild the default files stanza to be 9WM, AEWM and GPL-2,
simultaneously, which is what the upstream author specifies.
  * [lintian] debian/control: Spelling error in description text.
  * [lintian] debian/windowlab.desktop: Add an entry for Keywords.


Best regards,
Mats Erik Andersson

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

[Ben Hutchings]

I intend to NMU git to fix these bugs in unstable, as they make most of
my development activity unsafe.

git maintainers, please let me know if you're already preparing an
update.

Ben.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.


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

Bug#813702: systemd: Oneshot service doesn't get killed after timeout.

[Michael Biebl]

Am 18.03.2016 um 20:52 schrieb Greg Edwards:
> This is the upstream commit in v217 that fixes this bug:
> 
>   commit 21b2ce39d4038cd6176394836fdcfb7fba63f424
>   Author: Lennart Poettering 
>   Date:   Thu Aug 21 18:01:22 2014 +0200
> 
>   service: use the right timeout for stop processes we fork
> 
> Could we get this patch added to a future systemd stable build?

Cyril, can you confirm that this patch fixes your issue?


-- 
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#818582: aptitude cannot deal with often changing IP

[Jaakov]

Package: aptitude
Version: 0.7.5-3

Some internet providers change the IP address of clients frequently - 
approximately once a minute instead of once a day. "aptitude update" and 
aptitude downloads executed by such clients cannot deal with this fact - 
neither with passive nor with active sockets. They manage to download a 
bit before the IP change and then say that a socket cannot be connected.


An improvement is needed. If it's already implemented, I'd like to see 
the documentation of this feature.


Thanks in advance

Jaakov

Bug#595336: mirror submission for mirror.telepoint.bg

[Stefan Nikolov]

Hello Donald,

Thank you for suggesting the new ftpsync script.
It is configured and the trace file seems ok.
Just to summarize, our mirror supports both IPv4 and IPv6. Currently
http and rsync protocols are enabled.
The mirror is synced every 4 hours.


Kind regards,
Stefan Nikolov


On 17.03.2016 05:17, Donald Norwood wrote:
> Hello,
>
> Our apologies for the significant delay in adding your mirror to the
> official Debian mirror list.
>
> In reviewing your mirror I've noticed that the trace files are missing
> in your /debian/project/trace directory, specifically the tracefile
> indicating your mirror. Please check your configuration. There is also a
> new ftpsync script available in /debian/project/ftpsync/ it may be
> easier to update to the newest script.
>
> Please advise when you have the chance.
>
> Best regards,
> Donald Norwood
> -Debian Mirrors Team
>
>
>
>
> On Mon, 13 Sep 2010 10:36:14 +0300 Telepoint - mirror admin
>  wrote:
>> On Sat, 2010-09-11 at 13:48 +0200, Simon Paillard wrote:
>>> On Sat, Sep 04, 2010 at 05:28:36PM +0300, Telepoint - mirror admin wrote:
 Everything is done. Please check now!

 On Fri, 2010-09-03 at 23:20 +0200, Simon Paillard wrote:
> Thanks for your interest in helping Debian.
> In summary, you should read carefully http://debian.org/mirror/ftpmirror
>
> On Fri, Sep 03, 2010 at 08:04:21AM +, Yordan Georgiev wrote:
>> Package: mirrors
>> Severity: wishlist
>>
>> Submission-Type: new
>> Site: mirror.telepoint.bg
>>> By the way, you may setup a virtual host dedicated to Debian mirror for
>>> more flexibility.
>>>
>>> You should setup your system to that the full hostname returned is a
>>> valid dns (tp-mirror without domain is not).
>>> You can also set MIRRORNAME in ftpsync.conf to mirror.telepoint.bg
>>> http://mirror.telepoint.bg/debian/project/trace/tp-mirror
>> Fix
>> Type: leaf
>> Archive-architecture: ALL alpha amd64 arm armel hppa hurd-i386 i386 ia64 
>> kfreebsd-amd64 kfreebsd-i386 m68k mips mipsel powerpc s390 sparc 
>> Archive-ftp: /debian/
>> Archive-http: /debian/
> Please use the tool recommended at:
> http://debian.org/mirror/ftpmirror#how
> then get back to us when it's done.
>
>> CDImage-ftp: /debian-cd/
>> CDImage-http: /debian-cd/
>>> http://mirror.telepoint.bg/debian-cd/ outdated, 5.0.6 released.
>>>
>> Fix. Permissions problem
>> IPv6: no
>> Archive-upstream: ftp.de.debian.org
> Seems not, according to http://mirror.telepoint.bg/debian/project/trace
> BTW, you should sync from ftp.bg.d.o that may be close to you.
>>> Did you test ftp.bg or other mirror ? ftp.de as already many downstreams.
>>>
>> I do not want to synchronize from BG. Suggest me another one with less
>> traffic, please
>> CDImage-upstream: ftp.de.debian.org
>> Updates: twice
>> Maintainer: Yordan Georgiev 
>> Country: BG Bulgaria
>> Sponsor: Telepoint http://telepoint.bg
>> Comment: Update frequency: 6h
>>  Approximate bandwidth: 1G
>>> Thanks for mirroring Debian and best regards.
>>>




smime.p7s
Description: S/MIME Cryptographic Signature

Bug#818623: RFS: r-cran-uuid/0.1.2-4

[Gordon Ball]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "r-cran-uuid"

 * Package name: r-cran-uuid
   Version : 0.1.2-4
   Upstream Author : Simon Urbanek 
 * URL : http://www.rforge.net/uuid
 * License : MIT + bsd-3-clause
   Section : gnu-r

  It builds those binary packages:

r-cran-uuid - Tools for generating and handling UUIDs

  To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/r-cran-uuid


  Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/r/r-cran-uuid/r-cran-uuid_0.1.2-4.dsc


  Regards,
   Gordon Ball

Bug#818452: gr-air-modes: FTBFS: No rule to make target 'swig/air_modes_swig.py'

[Martin Michlmayr]

Package: gr-air-modes
Version: 0.0.1.514414f-3
Severity: serious

This package fails to build in unstable:

> sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
...
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> [ 15%] Built target air_modes
> make -f swig/CMakeFiles/pygen_swig_65324.dir/build.make 
> swig/CMakeFiles/pygen_swig_65324.dir/depend
> make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
> cd /<>/obj-x86_64-linux-gnu && /usr/bin/cmake -E cmake_depends 
> "Unix Makefiles" /<> /<>/swig 
> /<>/obj-x86_64-linux-gnu 
> /<>/obj-x86_64-linux-gnu/swig 
> /<>/obj-x86_64-linux-gnu/swig/CMakeFiles/pygen_swig_65324.dir/DependInfo.cmake
>  --color=
> Scanning dependencies of target pygen_swig_65324
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> make -f swig/CMakeFiles/pygen_swig_65324.dir/build.make 
> swig/CMakeFiles/pygen_swig_65324.dir/build
> make[3]: Entering directory '/<>/obj-x86_64-linux-gnu'
> make[3]: *** No rule to make target 'swig/air_modes_swig.py', needed by 
> 'swig/air_modes_swig.pyc'.  Stop.
> make[3]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> CMakeFiles/Makefile2:199: recipe for target 
> 'swig/CMakeFiles/pygen_swig_65324.dir/all' failed
> make[2]: *** [swig/CMakeFiles/pygen_swig_65324.dir/all] Error 2
> make[2]: Leaving directory '/<>/obj-x86_64-linux-gnu'
> Makefile:141: recipe for target 'all' failed
> make[1]: *** [all] Error 2
> make[1]: Leaving directory '/<>/obj-x86_64-linux-gnu'

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#818372: tex-common: Trigger fails on initial install of tex-common

[Norbert Preining]

Hi Wookey,

thanks for that report. Interesting... I tried to reproduce
it without success, but I just called 
apt-get install texlive-xetex texlive-latex-base 
texlive-generic-recommended texlive-fonts-recommended lmodern
instead, though (the build-deps of rustc).

> dpkg: error processing package texlive-xetex (--configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of tipa:
>  tipa depends on tex-common (>= 3); however:
>   Package tex-common is not configured yet.
> 
> dpkg: error processing package tipa (--configure):
>  dependency problems - leaving unconfigured

Do you have the *full* log available by chance?

I might be a race between trigger invocationa dn proper postinst configure
invocation, but I am not sure.

There are two triggers involved:
* texmf-map triggered via the lmodern.postinst via update-texmf-config map
* file trigger on /usr/share/texmf interest by tex-common

Now the only possible szenario I can imagine is:
* two triggers are pending (the above)
* dpkg calls tex-common's postinst with *only* the texmf-map trigger
* and later with the file trigger

I am checking already on all passed in triggers, so it must be
that the posinst is invoked two times for triggers.

I don't have any other explanation.

The solution is unfortunately not nice, because it would create 
another set of mktexlsr calls for *each* trigger of a map/fmt,
which is exactly what I wanted to get rid off when switching
to triggers.

So long blabla cut short - if you have the full log, please send
it to me (output of dpkg/apt is fine).

Thanks


Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#818511: courier: FTBFS: error: required file '../../depcomp' not found

[Martin Michlmayr]

Package: courier
Version: 0.75.0-12
Severity: serious

This package fails to build in unstable:

> sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
...
> running CONFIG_SHELL=/bin/bash /bin/bash ./configure 
> --disable-option-checking --prefix=/usr --build=x86_64-linux-gnu 
> --includedir=${prefix}/include --mandir=${prefix}/share/man 
> --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
> --disable-silent-rules --libdir=${prefix}/lib/x86_64-linux-gnu 
> --libexecdir=${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
> --disable-dependency-tracking --with-piddir=/var/run/courier 
> --sysconfdir=/etc/courier --libexecdir=${prefix}/lib/courier 
> --datadir=${prefix}/lib/courier --localstatedir=/var/lib/courier 
> --with-mailuser=courier --with-mailgroup=courier --without-socks 
> --enable-workarounds-for-imap-client-bugs 
> --with-authdaemonvar=/var/run/courier/authdaemon --with-db=gdbm 
> --without-fcgi --with-htmllibdir=/usr/share/sqwebmail 
> --with-ispell=/usr/bin/ispell --enable-imageurl=/sqwebmail 
> --with-mailer=/usr/sbin/sendmail --enable-sendmail=/usr/sbin/sendmail 
> --with-cachedir=/var/cache/sqwebmail --with-calendardir=/var/run/cou
> rier/calendar --with-certsdir=/etc/courier 
> --with-postgresql-includes=/usr/include/postgresql 
> --with-webadmindir=/usr/share/courier/webadmin --enable-authlib 
> --enable-userdb --enable-syslog=1 --enable-unicode --disable-root-check 
> build_alias=x86_64-linux-gnu CFLAGS=-g -O2 -fPIE -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -pedantic LDFLAGS=-fPIE -pie 
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed CPPFLAGS=-Wdate-time 
> -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat 
> -Werror=format-security 
> --with-makedatprog=/usr/lib/courier/courier/makedatprog 
> --with-package=courier --with-version=0.75.0 
> --with-courierlogger=/usr/sbin/courierlogger --with-mailuid=1 
> --with-mailgid=1 --enable-trusted-groups=courier --with-formdata 
> --enable-utf7-folder-encoding --cache-file=/dev/null --srcdir=. --no-create 
> --no-recursion
> Makefile.am: error: required file '../../depcomp' not found
> Makefile.am:   'automake --add-missing' can install 'depcomp'
> Makefile:387: recipe for target 'Makefile.in' failed
> make[2]: *** [Makefile.in] Error 1

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#818521: kdevelop-php: FTBFS: error: 'Php::Php' has not been declared

[Martin Michlmayr]

Package: kdevelop-php
Version: 1.7.2-1
Severity: serious

This package fails to build in unstable:

> sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
...
> cd /<>/obj-x86_64-linux-gnu/duchain/tests && /usr/bin/c++   
> -DKDE_DEFAULT_DEBUG_AREA=9043 -D_BSD_SOURCE -D_DEFAULT_SOURCE 
> -I/usr/include/kdevplatform -I/usr/include/KDE -I/usr/include/qt4/phonon 
> -I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml 
> -I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest 
> -I/usr/include/qt4/QtSvg -I/usr/include/qt4/QtSql 
> -I/usr/include/qt4/QtScriptTools -I/usr/include/qt4/QtScript 
> -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtHelp 
> -I/usr/include/qt4/QtDesigner -I/usr/include/qt4/QtDeclarative 
> -I/usr/include/qt4/QtDBus -I/usr/include/qt4/Qt3Support 
> -I/usr/include/qt4/QtGui -I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt 
> -I/usr/share/qt4/mkspecs/default -I/usr/include/qt4 
> -I/usr/include/threadweaver -I/<>/obj-x86_64-linux-gnu 
> -I/<> -I/<>/duchain -I/<>/parser 
> -I/<>/obj-x86_64-linux-gnu/parser -I/usr/include/kdevelop-pg-qt 
> -I/<>/obj-x86_64-linux-gnu/du
> chain/tests  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
> -Wdate-time -D_FORTIFY_SOURCE=2  -Wnon-virtual-dtor -Wno-long-long -Wundef 
> -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security 
> -fno-exceptions -DQT_NO_EXCEPTIONS -fno-check-new -fno-common 
> -Woverloaded-virtual -fno-threadsafe-statics -fvisibility=hidden 
> -Werror=return-type -fvisibility-inlines-hidden -std=c++11 -DNDEBUG 
> -DQT_NO_DEBUG   -DKDESRCDIR="\"/<>/duchain/tests/\"" -o 
> CMakeFiles/benchmarks.dir/duchaintestbase.cpp.o -c 
> /<>/duchain/tests/duchaintestbase.cpp
> In file included from 
> /<>/duchain/tests/expressionparser.cpp:630:0:
> /<>/obj-x86_64-linux-gnu/duchain/tests/expressionparser.moc:85:11:
>  error: 'Php::Php' has not been declared
>  void Php::Php::TestExpressionParser::qt_static_metacall(QObject *_o, 
> QMetaObject::Call _c, int _id, void **_a)
>^
> /<>/obj-x86_64-linux-gnu/duchain/tests/expressionparser.moc: In 
> function 'void qt_static_metacall(QObject*, QMetaObject::Call, int, void**)':
> /<>/obj-x86_64-linux-gnu/duchain/tests/expressionparser.moc:89:9:
>  error: 'TestExpressionParser' was not declared in this scope
>  TestExpressionParser *_t = static_cast(_o);
>  ^

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#808760: kdbg: FTBFS: Unknown CMake command "check_include_files".

[Eriberto]

;-)

2016-03-16 14:52 GMT-03:00 Ana Guerrero Lopez :
>
> Thanks a lot Eriberto!
> I'm going to upload this orphaning the package.

Bug#568375: gnupg-agent: does not work with `git tag -s`

[Peter Colberg]

Hi Luca,

On Thu, Feb 04, 2010 at 12:32:21PM +0100, Luca Capello wrote:
> Package: gnupg-agent
> Version: 2.0.14-1
> Severity: important
> 
> Hi there!
> 
> It seems that `git tag -s` and gpg-agent fails to cooperate and do not
> show the pinentry dialog (in my case the -curses variant inside screen):
> =
> luca@gismo:~/Lab/thesis/text(git)[master]$ \
>  git tag -s -u E397832F -m "submitted" submitted $COMMIT
> 
> You need a passphrase to unlock the secret key for
> user: "Luca Capello "
> 4096-bit RSA key, ID 3BE9F36D, created 2009-07-01 (main key ID E397832F)
> 
> gpg: cancelled by user
> gpg: skipped "E397832F": bad passphrase
> gpg: signing failed: bad passphrase
> error: gpg failed to sign the tag
> error: unable to sign the tag

While this comes too late for signing the tag of your submitted thesis
(congratulations!), this is likely caused by a missing GPG_TTY variable.

https://www.gnupg.org/documentation/manuals/gnupg/Common-Problems.html

The gpg-agent man page nowadays includes the following hint:

  It is important to set the GPG_TTY environment variable in your login
  shell, for example in the ‘~/.bashrc’ init script:

  export GPG_TTY=$(tty)

Regards,
Peter

Bug#818104: Possible MBF: Packages depending on iceweasel but not firefox/firefox-esr

[David Prévot]

Le 18/03/2016 18:06, Josh Triplett a écrit :

> I would suggest that Firefox addon packages should depend on "firefox |
> firefox-esr"

Most of those packages are mozilla-devscripts for the build and just
need to be rebuilt to get fixed. Even if our infrastructure has all the
needed tools to binNMU all of them as a proper transition, some
limitations on the way arch:all binNMU are handled currently prevents us
from having most of them already fixed, see #818104.

What is currently needed if the arch:all binNMU doesn’t get fixed, is
“just” to upload all of them. I’m currently dragged into doing that for
hundred of PHP classes packages because of this no arch:all binNMU
limitation, so I hope someone else from the Debian Mozilla Extension
Maintainers could take the lead on it (new members are welcome ;).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#818722: gnupg2: Disabling deprecation warnings to support GnuPG v1/v2 coexistence

[Peter Colberg]

Package: gnupg2
Version: 2.1.11-6
Severity: minor

Dear Maintainer,

My ~/.gnupg/gpg.conf contains the following keyserver options:

  keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options ca-cert-file=/usr/share/gnupg2/sks-keyservers.netCA.pem
  keyserver-options no-honor-keyserver-url
  keyserver-options auto-key-retrieve

This causes gpg2 to emit the following deprecation warning:

  gpg: keyserver option 'ca-cert-file' is obsolete; please use 'hkp-cacert' in 
dirmngr.conf

The ca-cert-file option is required by GnuPG v1 to fetch public keys
over an encrypted connection. Many Debian tools hard-code GnuPG v1,
which makes it challenging to solely use GnuPG v2 [1] on a Debian
system without resorting to a manual dpkg-divert of /usr/bin/gpg.

[1] https://wiki.debian.org/Teams/GnuPG/UsingGnuPGv2

Would you consider disabling this and similar deprecation warnings in
the Debian gnupg2 package, at least until a system can be configured
to default to GnuPG v2?

Regards,
Peter

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

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

Versions of packages gnupg2 depends on:
ii  dpkg   1.18.4
ii  gnupg-agent2.1.11-6
ii  install-info   6.1.0.dfsg.1-5
ii  libassuan0 2.4.2-3
ii  libbz2-1.0 1.0.6-8
ii  libc6  2.22-3
ii  libgcrypt201.6.5-2
ii  libgpg-error0  1.21-2
ii  libksba8   1.3.3-3
ii  libreadline6   6.3-8+b4
ii  libsqlite3-0   3.11.1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

Versions of packages gnupg2 recommends:
ii  dirmngr  2.1.11-6

Versions of packages gnupg2 suggests:
pn  gnupg-doc   
pn  parcimonie  
ii  xloadimage  4.1-23+b1

-- no debconf information

Bug#818600: mate-settings-daemon cannot create file /run/user//dconf/user and fills up the memory (24 GB!)

[Francesco De Biasio]

Package: mate-settings-daemon
Version: 1.8.2-4
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?
I don't know: it happens suddenly without any plausible cause (just working
with chrome, libreoffice etc.)
   * 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 ***

work-around:
changed /run/user//dconf/user permissions to a+rwx and killed mate-
settings-daemon: the memory emptied out and the system load got back to
normality.



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

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

Versions of packages mate-settings-daemon depends on:
ii  mate-settings-daemon-pulse  1.8.2-4

mate-settings-daemon recommends no packages.

mate-settings-daemon suggests no packages.

-- no debconf information

Bug#813452: fpc-3.0 regression in armhf and armel architectures

[Gianfranco Costamagna]

Yes, if you send me the patch i can also build fpc by myself!
Thanks a lot

G.

Mer 16/3/16, Paul Gevers  ha scritto:

 Oggetto: Re: Bug#813452: fpc-3.0 regression in armhf and armel architectures
 A: "Gianfranco Costamagna" , 
"813...@bugs.debian.org" <813...@bugs.debian.org>
 Data: Mercoledì 16 marzo 2016, 20:41
 
 Hi Gianfranco,
 
 On 27-02-16 13:45, Paul Gevers
 wrote:
 >> I also tried to build with
 the current fpc and no fPIC for the pascal part, and the
 build is successful.
 >>
 >> actually fPIC was broken also before,
 according to the Cmake file
 >>
 if(${CMAKE_Pascal_COMPILER_VERSION} VERSION_GREATER 2.7 OR
 ${CMAKE_TARGET_ARCHITECTURES} MATCHES "x86_64" OR
 ${CMAKE_TARGET_ARCHITECTURES} MATCHES "i386")
 >> add_flag_append(CMAKE_Pascal_FLAGS
 "-fPIC")
 >> endif()
 >>
 >>
 >> so, disabling it again is not a
 "real" regression :)
 > 
 > Hmm, that also means we can lower the
 severity of this bug (no
 > regression)
 and have it migrate to testing, agreed? I would leave
 this
 > bug as important, but still have
 fpc 3 migrate to testing. Is anybody
 >
 objecting?
 
 Abou got the
 required changes from upstream on board. If I upload fpc
 to
 debomatic, could you try to build
 hedgewars with PIC enabled? I'd like
 to
 see that the patches actually work before uploading to the
 Debian
 archive.
 
 Paul

Bug#783422: php-services-json: Useless in Debian?

[Dmitry Smirnov]

On Saturday, 19 March 2016 11:18:56 PM AEDT David Prévot wrote:
> Looks like civicrm only build-depends on it, that seems strange (I wonder
> how php-services-json is used during the build).

The idea was to use dh_linktree to generate dependencies but I've temporary 
disabled that...


> Looks like civicrm is using dh_linktree for embedding PHP classes, that
> seems like a awful tool for the un-bundling job, you may wish to properly
> load the needed classes instead.

You are right of course...


> Since there is no actual dependencies, I
> wonder how php-services-json is actually useful for civicrm currently.

Not at the moment but I was planning to re-enable use of system "php-
services-json"...


> Anyway, if you wish to see php-services-json stay,

I don't insist on it. If CiviCRM is the only user of "php-services-json" then 
I'm not sure if the latter worth maintaining in its own package.


> you should consider taking over its maintenance,

I'm afraid I have no capacity to do that... :(

Eventually I might help PHP team a little if I can...


> and ensure it’s ready for PHP 7.0.

And no skills to do that... :(

-- 
All the best,
 Dmitry Smirnov.

---

It has been said that democracy is the worst form of government except
all the others that have been tried.
-- Winston Churchill


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

Bug#346321: aptitude: offers upgrade to exp version (pri -10) instead of unst version (990)

[Henrique de Moraes Holschuh]

On Thu, 17 Mar 2016, Manuel A. Fernandez Montecelo wrote:
> 2006-01-07 00:22 Henrique de Moraes Holschuh:
> >Package: aptitude
> >Version: 0.4.1-1
> >Severity: important
> >
> >I am tagging this as important because any bug that makes people install
> >experimental packages unawares is quite problematic :)
> >
> >$ apt-cache policy libarts1c2a
> >libarts1c2a:
> > Installed: 1.4.3-3
> > Candidate: 1.5.0-3
> > Version table:
> >1.5.0-3 0
> >   990 http://mirrors.kernel.org unstable/main Packages
> >   990 http://ftp.fi.debian.org unstable/main Packages
> >1.5.0-2 0
> >   -10 http://mirrors.kernel.org experimental/main Packages
> >   -10 http://ftp.fi.debian.org experimental/main Packages
> >*** 1.4.3-3 0
> >   100 /var/lib/dpkg/status
> >
> >However, aptitude does this:
> >libarts1c2a recommends libarts1-akode
> >--\ The following actions will resolve this dependency:
> > -> Upgrade libarts1c2a [1.4.3-3 (now) -> 1.5.0-2 (experimental, 
> > experimental)]
> > -> Keep libarts1c2a at version 1.4.3-3 (now)
> > -> Remove libarts1c2a [1.4.3-3 (now)]
> > -> Install libarts1-akode [4:3.5.0-2 (experimental, experimental)]
> > -> Leave the dependency "libarts1c2a recommends libarts1-akode" unresolved.
> >
> >i.e it prefers to install the experimental version, even if it is priority
> >-10. The correct solution is to install libarts1c2a 1.5.0-3, and leave the
> >dependency unresolved.  OR to hold everything.  But installing anything that
> >has a negative priority is a no-no.
> >
> >For reference, my /etc/apt/preferences is:
> >Package: *
> >Pin: release a=experimental
> >Pin-Priority: -10
> 
> This should not happen with "recent" versions of aptitude, recent as in
> the last 6 years at least, because solutions involving installations /
> upgrades of non-default versions are kept in a different level and only
> offered last, if at all, below upgrading to default versions, removing
> it or keeping everything at the same version.
> 
> Have you experience this behaviour recently?

No, but that doesn't mean anything: sometime after I reported the bug, I
disabled experimental, and I don't think I had any reason to reenable it in
the last decade (if I did, I most certainly used a disposable chroot, got
the job done, dropped the chroot in the bitbucket and promptly forgot about
it).

One would have to test current apt (or better yet, stable apt) to be sure.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Bug#818386: Fix support for DRA7xx EVMs

[Ben Hutchings]

Package: src:linux
Version: 4.4.4-2
Severity: important

The armmp kernel is supposed to support DRA7xx systems, but currently
fails to boot on the EVM as it's missing the driver for the GPIO
expanders.

Ben.

diff --git a/debian/changelog b/debian/changelog
index 8626fbb297af..f39d46d900a2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -78,6 +78,7 @@ linux (4.4.5-1) UNRELEASED; urgency=medium
 - efi: Fix boot crash by always mapping boot service regions into new EFI
   page tables (Closes: #815125)
 - mm/pat: Fix boot crash when 1GB pages are not supported by cpu
+  * [armhf] gpio: Enable GPIO_PCF857X as module, needed by TI DRA7xx EVMs
 
   [ Ian Campbell ]
   * [arm64] Enable ARCH_HISI (Hisilicon) and the set of currently available
diff --git a/debian/config/armhf/config.armmp b/debian/config/armhf/config.armmp
index 1c71d6d24a09..af73db29fefd 100644
--- a/debian/config/armhf/config.armmp
+++ b/debian/config/armhf/config.armmp
@@ -235,6 +235,7 @@ CONFIG_RASPBERRYPI_FIRMWARE=y
 CONFIG_GPIOLIB=y
 CONFIG_GPIO_GENERIC_PLATFORM=m
 CONFIG_GPIO_PCA953X=m
+CONFIG_GPIO_PCF857X=m
 CONFIG_GPIO_DA9052=m
 CONFIG_GPIO_PALMAS=y
 CONFIG_GPIO_TWL4030=y
-- 
2.7.0


-- 
Ben Hutchings
Software Developer, Codethink Ltd.

Bug#767418: closing telegram WNPP bugs

[Antoine Beaupré]

After reviewing the litterature, I agree that Telegram has serious
security issues that go beyond usual security compromises and
tradeoffs.

It seems to imply incompetence if not downright maliciousness from the
Telegram developpers, especially concerning the way contacts are shared
with the server without the user's consent, the lack of contact
authentication (allowing the server to perform MITM attacks) and
downright censorship in Iran.

One has to question why Telegram hasn't fixed those issues by changing
their protocols to fit the best current practices (e.g. the Axolotl
rachet) in the years since those criticisms came into being.

Anyways, I am still not clear on whether the software should just be
rejected from Debian completely. If someone comes up with neatly done
Debian packages, with warnings and all, maybe it would be useful if only
for the sake of interoperability. A *lot* of people are using Telegram
to chat, and the same way we allow users to install software that talks
with Facebook, Twitter and Gmail users, maybe we could allow Debian
users to talk to Telegram users...

But of course, I won't waste my time with Telegram anymore, now that I
know. I also clarified the state of the software in Wikipedia to avoid
future me getting confused again:

https://en.wikipedia.org/w/index.php?title=Telegram_%28software%29=revision=710418931=710242518

Thanks for everyone for the reviews, it was useful, as always, to have
Debian's WNPP directory as such an excellent source of information for
this sort of things.

A.
-- 
We all pay for life with death, so everything in between should be
free.
 - Bill Hicks

Bug#816169: RFS: fake-factory/0.5.3-1

[Mattia Rizzolo]

On Sat, Mar 19, 2016 at 10:11:07PM +, Christopher Baines wrote:
> I think I realised when I read this, that the source and binary package
> names can be handled separately, so I have gone ahead and renamed the
> source package to faker [1]. I'll delete the other (fake-factory)
> repository and try to update the BTS tomorrow, if I hear no objections.

yeah, looks cool.  please delete the other.

> The issues that you commented on above are fixed in this repository.
> 
> 1: https://anonscm.debian.org/cgit/python-modules/packages/faker.git

of what I wrote before these still need fixing:

* debian/control:
  + I: fake-factory source: duplicate-long-description python-fake-factory 
python3-fake-factory
  + I: python-fake-factory: extended-description-is-probably-too-short
  + I: python3-fake-factory: extended-description-is-probably-too-short

of the manpage erros you output, I can see man has to complain about
this:

:8: warning [p 1, 1.7i]: cannot adjust line
:8: warning [p 1, 1.8i]: can't break line
:33: warning [p 1, 5.3i, div `an-div', 0.0i]: cannot adjust line
:33: warning [p 1, 5.3i, div `an-div', 0.2i]: can't break line
:33: warning [p 1, 5.3i, div `an-div', 0.3i]: cannot adjust line
:33: warning [p 1, 5.3i, div `an-div', 0.5i]: can't break line

Indeed `faker --help` outputs this

  -l 
{lt_LT,lv_LV,de_AT,tr_TR,sv_SE,no_NO,pt_PT,it_IT,en_US,en_CA,en,zh_TW,fi_FI,hi_IN,hr_HR,fa_IR,bg_BG,zh_CN,sk_SK,fr_FR,en_GB,dk_DK,es,en_AU,sl_SI,el_GR,la,de_DE,bs_BA,uk_UA,pt_BR,nl_NL,pl_PL,ru_RU,cs_CZ,ja_JP,es_ES,ko_KR,es_MX,ne_NP},
 --lang 
{lt_LT,lv_LV,de_AT,tr_TR,sv_SE,no_NO,pt_PT,it_IT,en_US,en_CA,en,zh_TW,fi_FI,hi_IN,hr_HR,fa_IR,bg_BG,zh_CN,sk_SK,fr_FR,en_GB,dk_DK,es,en_AU,sl_SI,el_GR,la,de_DE,bs_BA,uk_UA,pt_BR,nl_NL,pl_PL,ru_RU,cs_CZ,ja_JP,es_ES,ko_KR,es_MX,ne_NP}
specify the language for a localized provider (e.g.
de_DE)

well, that's awful.
did you manually fix this in the build manpage by any chance?
imho the proper fix for this thing would be to have argparse (or
whatever thing this library/app is using to parse the options) to not
output the recognized options, and output them formatted in a saner way
(e.g. separated by ', ') at the bottom of the --help, then maybe
help2man will need some help to handle that correctly, though.

And BTW, I have another feeling that the list of languages is stored
inside a set, and that is passed to argparse as a list of valid options;
well, that makes argparse output non-reproducible, and as such the
generated manpage is non reproducible; please make that either a real
list (so the elements have a fixed position) or sort the set before
passing it over to argparse, so that the output is reproducible between
runs (and as such between rebuilds).
https://paste.debian.net/plain/417202 (this is not built with the
reproducible toolchain, and as such there is noise about filesystem
order (actually there is not, but this is by chance) and timestamps
inside the {control,data}.tar member of the .deb, that in the
reproducible toolchain is fixed by a patched dpkg not yet included in
dpkg mainstream)

-- 
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#783422: php-services-json: Useless in Debian?

[David Prévot]

Hi Dmitry,

> My concern for removal of this package is that recently introduced CiviCRM
> loosely depends on it.

Looks like civicrm only build-depends on it, that seems strange (I wonder
how php-services-json is used during the build).

Looks like civicrm is using dh_linktree for embedding PHP classes, that
seems like a awful tool for the un-bundling job, you may wish to properly
load the needed classes instead. Since there is no actual dependencies, I
wonder how php-services-json is actually useful for civicrm currently.

Anyway, if you wish to see php-services-json stay, you should consider
taking over its maintenance, and ensure it’s ready for PHP 7.0.

Regards

David

Bug#817199: transcode: should this package be removed?

[Fabian Greffrath]

Am Sonntag, den 13.03.2016, 21:25 +0100 schrieb Sebastian Ramacher:
> Yes, dvdwizard would have to be RoQ-ed if we are going to remove
> transcode. But it's also dead upstream and orphaned.

Alright, let's go for it.

Anyway, since transcode is a command-line utility, it should be rather
straightforward to convert dvdwizard to use something more advanced,
e.g. ffmpeg. But until someone who urgently needs dvdwizard volunteers
to do this, I think it should be alright to remove it from the archive.

 - Fabian


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

Bug#818591: control: split and improve dependency handling for disk detection

[Hendrik Brueckner]

Control: tags -1 + patch
>From 18604958d335666c4154c1e500dc424aff0c5998 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Fri, 18 Mar 2016 12:05:01 +0100
Subject: [PATCH] control: split and improve dependency handling for disk
 detection

To improve and provide a "guided" flow, split the harddrive
detection dependency for s390-dasd and s390-zfcp as follows:

- s390-dasd provides harddrive-detection-dasd
- s390-zfcp provides harddrive-detection-zfcp

The disk-detect package depends on
  -> harddrive-detection-dasd
  -> harddrive-detection-zfcp

and continues to provide the harddrive-detection.  With this split,
installation on mixed DASD and SCSI disks are possible.  Also move
the module before the disk-detect module in the Debian installer
menu.

See also related Debian Bugs for:
  disk-detect: #818586
  s390-zfcp: #818592

Signed-off-by: Hendrik Brueckner 
---
 debian/changelog | 8 
 debian/control   | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 69a0aa2..c83ad59 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+s390-dasd (0.0.36) UNRELEASED; urgency=medium
+
+  [ Hendrik Brueckner ]
+  * Split and improve dependency handling for disk detection and
+move the module before the disk-detect d-i module (Closes: #818591)
+
+ -- Hendrik Brueckner   Fri, 18 Mar 2016 
11:59:33 +0100
+
 s390-dasd (0.0.35) unstable; urgency=low
 
   * Team upload
diff --git a/debian/control b/debian/control
index f036662..e4c75fb 100644
--- a/debian/control
+++ b/debian/control
@@ -11,7 +11,7 @@ Package: s390-dasd
 Package-Type: udeb
 Architecture: s390 s390x
 Depends: ${shlibs:Depends}, ${misc:Depends}, dasd-modules, 
s390-sysconfig-writer, s390-tools-udeb
-Provides: harddrive-detection
-XB-Installer-Menu-Item: 3700
+Provides: harddrive-detection-dasd
+XB-Installer-Menu-Item: 3400
 Description: Configure DASD
  Configure DASD, s390 specific harddisks. 
-- 
2.7.0

Bug#818400: Built plugin from source

[Sebastian]

Dear Maintainer,
when I build the plugin from source like this:

apt-get source gcc-python3-plugin
cd gcc-python-plugin-0.15/
sudo apt-get install debhelper dh-python gcc-5-plugin-dev g++-5 python3-all-dev 
python3-all-dbg python3-lxml python3-pygments python3-six python3-sphinx
make  PYTHON=python3  PYTHON_CONFIG=python3-config  all

I am not sure if this is the correct way to build for debian - I just saw this 
example in the Makefile and tried.

I get these from the build:

Failed tests:
  tests/cpychecker/refcounts/PyDict_SetItem/correct
  tests/cpychecker/refcounts/PyDict_SetItemString/correct
  tests/cpychecker/refcounts/PyDict_SetItemString/incorrect
  tests/cpychecker/refcounts/PyFloat_AsDouble/correct_PyFloatObject
  tests/cpychecker/refcounts/PySequence_Size/correct
  tests/cpychecker/refcounts/PySequence_Size/null
  tests/cpychecker/refcounts/Py_BuildValue/correct-code-N
  tests/cpychecker/refcounts/Py_BuildValue/correct-code-O
  tests/cpychecker/refcounts/attributes/returns-borrowed-ref/correct-usage
  tests/cpychecker/refcounts/loops/complex-loop-conditional-1
  tests/cpychecker/refcounts/loops/complex-loop-conditional-2
  tests/cpychecker/refcounts/macros/Py_XDECREF/crash
  tests/cpychecker/refcounts/object_from_callback
  tests/cpychecker/refcounts/ticket-20

But the plugin still works when called like this:

./gcc-with-python ../../bugreport/script.py ../../bugreport/sourcefile.c -c -o 
tmp.o
rm tmp.o

Bug#813822: Update on the status

[Santiago Garcia Mantinan]

After sending the patch I did more tests with different backend real servers
and found out that apache 2.4 as a server doesn't like to be asked for a SNI
hostname different than the hostname on the Host header and gives an error.

I've found a more complete patch available here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=54656

But the discussion seems to have ended there, for what I see, if you want
ProxyPreserveHost you must have the frontend certs available at the backend,
at least with apache backend servers, as that's how they are implementing
this, the Host header must match the certificate name.

Before SNI on apache you could have a backend server with its own
certificate serving a Host of another domain, but this is no longer allowed. 
I really think they should think about this again, IMHO the backend server
should allow a mismatch if they are coming through a proxy or if a directive
tells it to do so, something like SSLStrictSNIVHostCheck but that relaxes
the check.  Not allowing this will mean that people won't check or use
certificates from the frontend to the backend, which means lower security
:-(

Regards.
-- 
Manty/BestiaTester -> http://manty.net

Bug#818721: OpenAL Soft 1.17.1 is available

[Marco d'Itri]

Package: libopenal1
Version: 1.16.0-3
Severity: wishlist

Please package the latest openal release, since maybe it fixes some 
ALSA-related bugs.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#818405: apt: Google Chrome repository unusable because of weak digest

[Ben Caradoc-Davies]

Thanks for the update, Julian. Google are leading the deprecation of 
SHA1 and their continuing use of SHA1 digests in these repos is no doubt 
an oversight. This bug report will notify other Debian users that you 
have informed Google of the problem.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Bug#783422: php-services-json: #783422 Useless in Debian?

[Dmitry Smirnov]

My concern for removal of this package is that recently introduced CiviCRM 
loosely depends on it. CiviCRM upstream tarball ships "Services/JSON.php" so 
I suppose I could use bundled copy if we are eager to get rid of "php-
services-json"...

-- 
Cheers,
 Dmitry Smirnov
 GPG key : 4096R/53968D1B

---

It is a mistake to try to look too far ahead. The chain of destiny can only
be grasped one link at a time.
-- Winston Churchill



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

Bug#719624: Upgrading xrdp

[Dominik George]

>An alternative strategy would be to simply copy it over on
>git.debian.org to debian-edu space and push there.

The issue is that I messed up some commits in the history.

I think I will do a manual merge of the changes instead…

-nik
-- 
PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17 FD26 B79A 3C16 A0C4 F296

Dominik George · Mobil: +49-151-61623918

Teckids e.V. · FrOSCon e.V. · OpenRheinRuhr e.V.
Fellowship of the FSFE · Piratenpartei Deutschland
Opencaching Deutschland e.V. · Debian Contributor

LPIC-3 Linux Enterprise Professional (Security)

Bug#818455: eom: "image-collection-position" broken

[Julian]

Package: eom
Version: 1.12.2-1
Severity: normal

Hello,

the position of the image collection can't be set anymore. In the past you
could set an integer value with dconf:
http://git.mate-
desktop.org/eom/tree/data/org.mate.eom.gschema.xml.in.in?h=1.6=c38cb72f0b012c83032b54ad2062ea6893e0a554
With 0 (default) for bottom, 1 for left, ...


  0
  <_summary>Image collection pane position. Set to 0 for bottom;  1 for
left; 2 for top; 3 for right.


This seems to have been changed to an "enum" value:
https://github.com/mate-
desktop/eom/blob/master/data/org.mate.eom.gschema.xml.in#L7

  
  'bottom'
  Image collection pane position.


Unfortunately dconf still only accepts numeric values. Even the standard value
"bottom" is not accepted. Also I think a descripton or at least hint in the
summary about the accepted values should be added. A previously set numeric
value is kept and not converted (but not working anymore of course).

I couldn't find a definition of "org.mate.eom.EomWindowCollectionPos". Maybe
it's missing?

Thanks :)



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

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

Versions of packages eom depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  eom-common   1.12.2-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.21-9
ii  libcairo21.14.6-1
ii  libdbus-1-3  1.10.6-1
ii  libdbus-glib-1-2 0.106-1
ii  libexempi3   2.2.2-2+b1
ii  libexif120.6.21-2
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.3-3
ii  libgdk-pixbuf2.0-0   2.32.3-1.2
ii  libgirepository-1.0-11.46.0-4
ii  libglib2.0-0 2.46.2-3
ii  libgtk2.0-0  2.24.30-1
ii  libjpeg62-turbo  1:1.4.2-2
ii  liblcms2-2   2.6-3+b3
ii  libmate-desktop-2-17 1.12.1-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  librsvg2-2   2.40.13-3
ii  librsvg2-common  2.40.13-3
ii  libstartup-notification0 0.12-4
ii  libx11-6 2:1.6.3-1
ii  libxml2  2.9.3+dfsg1-1
ii  mate-desktop-common  1.12.1-1
ii  shared-mime-info 1.5-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

eom recommends no packages.

eom suggests no packages.

-- no debconf information

Bug#817199: transcode: should this package be removed?

[Sebastian Ramacher]

Control: reassign -1 ftp.debian.org
Control: severity -1 normal
Control: retitle -1 RM: transcode -- RoM; dead upstream, replacements exist
Control: clone -1 -2
Control: retitle -2 RM: dvdwizard -- RoQA; orphaned, dead upstream, blocking 
transcode removal
Control: block -1 by -2

On 2016-03-18 09:58:52, Fabian Greffrath wrote:
> Am Sonntag, den 13.03.2016, 21:25 +0100 schrieb Sebastian Ramacher:
> > Yes, dvdwizard would have to be RoQ-ed if we are going to remove
> > transcode. But it's also dead upstream and orphaned.
> 
> Alright, let's go for it.
> 
> Anyway, since transcode is a command-line utility, it should be rather
> straightforward to convert dvdwizard to use something more advanced,
> e.g. ffmpeg. But until someone who urgently needs dvdwizard volunteers
> to do this, I think it should be alright to remove it from the archive.

Dear FTP masters, please remove transcode from unstable. From my initial mail
in this bug report:

> transcode is dead upstream since many years and it is also no longer really
> maintained Debian. We just keep sticking patches on top of it. I suppose most
> of its use-cases are also covered by other tools already available in Debian.
> Also, support for modern containers like mp4 is still very limited. So I think
> it's time to let it go.

Also, transcode will become RC-buggy once the ffmpeg 3.0 transition starts.

transcode has one reverse dependency: dvdwizard. dvdwizard is also dead upstream
and orphaned. Please remove it too.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#816720: Bug##816720: gail-common: provide udeb for accessibility

[Samuel Thibault]

Hello,

Michael Biebl, on Sun 20 Mar 2016 02:38:09 +0100, wrote:
> Am 16.03.2016 um 15:03 schrieb Samuel Thibault:
> > Samuel Thibault, on Mon 07 Mar 2016 03:07:29 +0100, wrote:
> >> Samuel Thibault, on Fri 04 Mar 2016 13:56:08 +0100, wrote:
> >>> Ok, I'll be testing the attached patch.
> >>
> >> Yes, it is working, could that be applied to gtk+2.0?
> 
> I haveen't looked at the patch in detail yet, just one comment from a
> cursory glance: I don't think there is much benefit in splitting the
> udeb in libgail18-udeb + libgail-common-udeb, soname transitions are no
> concern for d-i after all.
> So maybe a single udeb package as we have for libgtk2.0-0
> (libgtk2.0-0-udeb) would be more suitable.

Right, so that'd be as attached.

Samuel
Index: debian/control
===
--- debian/control  (révision 47627)
+++ debian/control  (copie de travail)
@@ -254,6 +254,22 @@
  .
  This package contains the shared library.
 
+Package: libgail18-udeb
+Package-Type: udeb
+Architecture: any
+Depends: ${misc:Depends},
+ ${shlibs:Depends},
+ libgtk2.0-0-udeb (= ${binary:Version})
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Description: GNOME Accessibility Implementation Library -- shared libraries
+ Gail implements ATK interfaces for GTK+ widgets which are dynamically
+ loadable at runtime by a GTK+ application. Once loaded, those parts of
+ an application that use standard GTK+ widgets will have a basic level
+ of accessibility, without the need to modify the application at all.
+ .
+ This package contains the shared library for the Debian installer.
+
 Package: libgail-common
 Architecture: any
 Depends: ${misc:Depends},
Index: debian/control.in
===
--- debian/control.in   (révision 47627)
+++ debian/control.in   (copie de travail)
@@ -254,6 +254,22 @@
  .
  This package contains the shared library.
 
+Package: libgail18-udeb
+Package-Type: udeb
+Architecture: any
+Depends: ${misc:Depends},
+ ${shlibs:Depends},
+ @UDEB_PKG@ (= ${binary:Version})
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
+Description: GNOME Accessibility Implementation Library -- shared libraries
+ Gail implements ATK interfaces for GTK+ widgets which are dynamically
+ loadable at runtime by a GTK+ application. Once loaded, those parts of
+ an application that use standard GTK+ widgets will have a basic level
+ of accessibility, without the need to modify the application at all.
+ .
+ This package contains the shared library for the Debian installer.
+
 Package: libgail-common
 Architecture: any
 Depends: ${misc:Depends},
Index: debian/libgail18-udeb.install.in
===
--- debian/libgail18-udeb.install.in(nonexistent)
+++ debian/libgail18-udeb.install.in(copie de travail)
@@ -0,0 +1,2 @@
+debian/install/shared_udeb/@LIBDIR@/libgail*.so.* @LIBDIR@
+debian/install/shared_udeb/@LIBDIR@/gtk-@APIVER@/modules/*.so 
@LIBDIR@/gtk-@APIVER@/modules
Index: debian/rules
===
--- debian/rules(révision 47627)
+++ debian/rules(copie de travail)
@@ -81,7 +81,7 @@
 
 # package groups, used in rule dependencies and in cleanup
 BINARY_INDEP_PKGS := $(COMMON_PKG) $(DOC_PKG) libgail-doc
-BINARY_ARCH_PKGS := $(SHARED_PKG) $(BIN_PKG) $(UDEB_PKG) $(DEV_PKG) 
$(DEBUG_PKG) $(EXAMPLES_PKG) $(PIXBUF_PKG) gir1.2-gtk-2.0 libgail18 libgail-dbg 
libgail-dev libgail-common
+BINARY_ARCH_PKGS := $(SHARED_PKG) $(BIN_PKG) $(UDEB_PKG) $(DEV_PKG) 
$(DEBUG_PKG) $(EXAMPLES_PKG) $(PIXBUF_PKG) gir1.2-gtk-2.0 libgail18 
libgail18-udeb libgail-dbg libgail-dev libgail-common
 ALL_PKGS := $(BINARY_INDEP_PKGS) $(BINARY_ARCH_PKGS)
 
 # list of flavors we build; each gets a builddir, a configure pass (configure
@@ -287,9 +287,9 @@
dh_installman -s
dh_installexamples -s
dh_link -s
-   dh_strip -s --dbg-package=$(DEBUG_PKG) -N$(UDEB_PKG) -Nlibgail18 
-Nlibgail-common
+   dh_strip -s --dbg-package=$(DEBUG_PKG) -N$(UDEB_PKG) -Nlibgail18 
-Nlibgail18-udeb -Nlibgail-common
dh_strip -plibgail18 -plibgail-common --dbg-package=libgail-dbg
-   dh_strip -p$(UDEB_PKG)
+   dh_strip -p$(UDEB_PKG) -plibgail18-udeb
dh_compress -s -X.sgml -X.devhelp
dh_fixperms -s -X$(LIBDIR)/$(SHARED_PKG)
dh_makeshlibs -p$(SHARED_PKG) \
@@ -300,6 +300,7 @@
dh_makeshlibs -plibgail18 \
-X$(MODULES_BASE_PATH) \
-V"libgail18 (>= $(SHVER)), libgail-common (>= $(SHVER))" \
+   --add-udeb=libgail18-udeb \
-- -c4
dh_girepository -pgir1.2-gtk-2.0
dh_installdeb -s

Bug#816720: Bug##816720: gail-common: provide udeb for accessibility

[Michael Biebl]

Am 20.03.2016 um 02:38 schrieb Michael Biebl:
> Am 16.03.2016 um 15:03 schrieb Samuel Thibault:
>> Hello gtk maintainers,
>>
>> Samuel Thibault, on Mon 07 Mar 2016 03:07:29 +0100, wrote:
>>> Samuel Thibault, on Fri 04 Mar 2016 13:56:08 +0100, wrote:
 Ok, I'll be testing the attached patch.
>>>
>>> Yes, it is working, could that be applied to gtk+2.0?
>>
>> Ping?
> 
> I haveen't looked at the patch in detail yet, just one comment from a
> cursory glance: I don't think there is much benefit in splitting the
> udeb in libgail18-udeb + libgail-common-udeb, soname transitions are no
> concern for d-i after all.
> So maybe a single udeb package as we have for libgtk2.0-0
> (libgtk2.0-0-udeb) would be more suitable.

Related to  that, the generated shlibs file for libgail8 has

> libgailutil 18 libgail18 (>= 2.24.0), libgail-common (>= 2.24.0)
> udeb: libgailutil 18 libgail18-udeb (>= 2.24.0), libgail-common (>= 2.24.0)

The udeb line is broken, as it produces a dependency on a non-udeb package.

Would be great if you can look into that.

-- 
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#813813: RFS: msi-keyboard -- command line tool to change MSI steelseries keyboards color setup

[Giulio Paci]

Hi Mattia,
thank you for your review and for wishing to sponsor this package.

On 19/03/2016 13:37, Mattia Rizzolo wrote:
> control: tag -1 moreinfo
> control: owner -1 !
> 
> On Fri, Feb 05, 2016 at 03:04:19PM +0100, Giulio Paci wrote:
>>   I am looking for a sponsor for my package "msi-keyboard":
> 
> alright.
> 
>>   https://anonscm.debian.org/cgit/collab-maint/msi-keyboard.git
> 
> cool!  finally somebody coming here with a git repository!
> 
> though:
> * I see no tags, I expect to see at least the upstream/* tags (also
>   otherwise gbp can be noisy and annoying)

Added a tag.

> * the HEAD points to master; given that the packaging branch is
>   "debian", please configure the remote repository on collab-maint to
>   have HEAD point to "debian" instead, so that cloning the repository
>   gives you the packaging branch even without specifying it.

Fixed.

> * as said you are using a non-standard repository layout, so I expect
>   debian/gbp.conf to be explicitly configured to use
>   'debian-branch = debian' and 'upstream-branch = master'

Fixed.

> * also, Vcs-Git does not specify the branch (which is kinda optional if
>   you set correctly HEAD on the remote repository, but it wouldn't harm
>   to write it here too)

Fixed.

> * I'm looking partly shocked at the commit
>   6fc1eec66c259cefeeb13453c3ceeb206fb24a55 why did you *substituted* the
>   pristine-tar data?  You should always just add them.

This is just because upstream never tagged a version, nor released a package.
I imported one using 0.0.1 version, but later noticed that 1.0 was set in the 
source and so I renamed the package.
This was before publishing the repository, while doing preliminary package work.
Then I forgot to cleanup the history before publishing it. :-(

> that's just about the git repository.
> 
> review on the package itself:
> * debian/control:
>   + please sort the build-deps with wrap-and-sort or with cme or

Done.

>   + please bump Standards-Version to 3.9.7

Done.

>   + please drop the build-dep on dpkg-dev, that version is old enough
> and dpkg-dev is in build-essential

Ok.

>   + please build-dep on debhelper (>= 9), no need for that ~

Ok.

>   + please drop the version constriction on qt5-qmake, that version is
> old enough

Ok.

> * debian/changelog:
>   + I see there is a weird space between the month and the year, how so?

Manual editing instead of using dch.

> * debian/copyright:
>   + there is a \t at line 9, please just use spaces for consistency.  I
> have a feeling you editor is configured to show a tab as 8 spaces,
> but this is not everybody's configuration, in fact here the line is
> indeed in a weird way.

Fixed (and correct guess about the editor configuration).

>   + please use the license names as specified by DEP-5, so name it
> "BSD-3-clause" and not lowercase

Fixed.

> * debian/msi-keyboard.{post,pre}inst:
>   + what aree these?  Quasi-empty files?

Dropped. I added them while trying to understand how to deal udev files... And 
then forgot about them.
BTW: do you know how to make the udev file work after installation, without 
rebooting the system?

> * debian/patches:
>   + debian/patches/series is empty, please remove the whole directory

Ok.

> Then, here it fails to build:
> 
>debian/rules override_dh_auto_build
> make[1]: Entering directory '/build/msi-keyboard-1.0'
> PATH="`pwd`":"$PATH" help2man msi-keyboard --no-info --name="MSI steelseries 
> keyboard color changer" > debian/msi-keyboard.1
> help2man: can't get `--help' info from msi-keyboard
> Try `--no-discard-stderr' if option outputs to stderr
> debian/rules:12: recipe for target 'override_dh_auto_build' failed
> make[1]: *** [override_dh_auto_build] Error 2
> make[1]: Leaving directory '/build/msi-keyboard-1.0'
> debian/rules:6: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> E: Failed autobuilding of package

Fixed. The issue was the build order vs help2man run, as Jakub said.

> I wonder why not just use `help2man ./msi-keyboard ...` instead of
> messing around with PATH (which is probably what went wrong here).

As Jakub pointed out, this is needed to get proper command name in the man page.

Bug#804487: [Pkg-openssl-devel] Bug#804487: openssl_1.0.2d-3 breaks mumble and mumble-server after binNMU

[Chris Knadle]

Kurt Roeckx:
> On Mon, Mar 14, 2016 at 10:25:30PM +0100, Mikkel Krautz wrote:
>> Quoting Kurt Roeckx:
>>> I would also like to say again that if we can somehow see in the
>>> meta data that they are using libssl, they would get rebuild at
>>> the same time and you wouldn't get into this situation that they
>>> are using a different version.
>>
>> Is this not possible without using -openssl-linked?
> 
> Maybe a Recommends in Qt?  But that's not picked up by the release
> team's transition tracker.  It could also just add a Depends ...
> 
> Maybe it's something you should ask the release team for input
> about?
> 
> Kurt

Sorry this took a bit of time (on my part).  I've asked both the security
and release teams for input and have heard back from the release team
concerning trying to add metadata to cause Qt and Mumble to get binNMUed at
nearly the same time:

---

There's no way to express that kind of relationship. Not unless you get into
complex territory which isn't really worth it in this case. Normally binNMUs
are scheduled at the same time, so in theory this shouldn't be such a big
issue. And it would only affect unstable users, only for a short amount of time.

---

  https://lists.debian.org/debian-release/2016/03/msg00371.html

So ... that sounds like another dead-end.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#817908: iceweasel: leaves cruft in /etc/iceweasel/ on upgrade

[Mike Hommey]

On Wed, Mar 16, 2016 at 06:45:00PM +0100, Christoph Anton Mitterer wrote:
> One should perhaps note that at least I have still stuff left:
> /etc/iceweasel$ tree
> .
> ├── pref
> ├── profile
> │   └── chrome
> └── searchplugins
> └── common

That is bug 815969

Mike

Bug#818598: src:linux: MTD device probe failed after migrating kernel variant from -orion5x to -marvell

[Roger Shimizu]

Package: src:linux
Version: 4.4.6-1
Severity: normal
Control: notfound -1 4.4-1~exp1
Control: found -1 4.4.1-1~exp1
X-Debbugs-Cc: rogershim...@gmail.com

Dear Maintainer,

I found my orion5x based Linkstation started to fail probing MTD
device, which stores u-boot binary and environment, after variant
migration from -orion5x to -marvell.

Kernel log with version info is like the following:

Linux LS-GL 4.4.0-trunk-orion5x #1 Debian 4.4-1~exp1 (2016-01-19)
armv5tel GNU/Linux

[1.838495] Found: SST 39LF020
[1.841662] f400.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[1.847985] number of JEDEC chips: 1
[1.868437] 3 ofpart partitions found on MTD device f400.flash
[1.874705] Creating 3 MTD partitions on "f400.flash":
[1.880288] 0x-0x0003 : "header"
[1.06] 0x0003-0x0003f000 : "uboot"
[1.897299] 0x0003f000-0x0004 : "uboot_env"



Linux LS-GL 4.4.0-trunk-marvell #1 Debian 4.4.1-1~exp1 (2016-02-10)
armv5tel GNU/Linux

[1.716090] Found: SST 39LF020
[1.719184] f400.flash: Found 1 x8 devices at 0x0 in 8-bit bank
[1.742133] Support for command set 0002 not present
[1.747188] gen_probe: No supported Vendor Command Set found
[1.752919] of-flash f400.flash: do_map_probe() failed for type
jedec_probe
[1.771450] of-flash f400.flash: do_map_probe() failed


I uses the same DTB, which ships with latest sid kernel, to do previous test.
(I put the DTB in /etc/flash-kernel/dtbs/)
It with the patches I applied:
- 
https://anonscm.debian.org/cgit/kernel/linux.git/tree/debian/patches/features/arm/device-tree?h=sid

I also checked the diff of kernel config for the two kernels, but found no clue.
And, the kirkwood based Linkstation doesn't have this issue.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 17B3ACB1

Bug#817872: llvm-toolchain-3.8 can migrate

[Gianfranco Costamagna]

I'm untagging 3.8 from the affected versions.
This is already fixed in svn for the snapshot package, and since the snapshot 
package won't ever migrate to testing
this bug will affect only unstable, hence 3.8 can migrate to testing.

cheers,

G.

Bug#816888: libncursesw5: mutt's thread display is broken

[Sven Joachim]

On 2016-03-06 18:51 +0900, Kusanagi Kouichi wrote:

> Package: libncursesw5
> Version: 6.0+20160213-1
> Severity: important
>
> Since ncurses 6.0+20160213-1, mutt's thread display is broken.

Right, but only in non-utf8 locales, which explains why nobody noticed
it before.

> Downgrading libncursesw5 to 6.0+20151024-2 fixes the issue.

A bisection shows that it appeared first in the 20151212 patchlevel
which has this NEWS entry:

,
| 20151212
|   + improve CF_XOPEN_CURSES macro used in test/configure, to define as
| needed NCURSES_WIDECHAR for platforms where _XOPEN_SOURCE_EXTENDED
| does not work.  Also modified the test program to ensure that if
| building with ncurses, that the cchar_t type is checked, since that
| normally is since 20111030 ifdef'd depending on this test.
|   + improve 20121222 workaround for broken acs, letting Solaris "work"
| in spite of its misconfigured wcwidth which marks all of the line
| drawing characters as double-width.
`

Comments from upstream (CC'ed) would be appreciated.

Cheers,
   Sven

Bug#818349: exim4-base: Still warns about purging the environment, even with add_environment set

[Andreas Metzler]

On 2016-03-16 Ben Hutchings  wrote:
> Control: severity -1 serious
> Control: tag -1 moreinfo

> Upgrading severity.  I consider this release-critical because a package
> should never:

> 1. Send spurious error messages from its cron job
> 2. Recommend changing the configuration in a way that would undo a
> security fix

Hello,

the situation is this:

* Upstream made a change (cleaning the environment by default) that in
  their opinion could break existing systems. There is not a magic
  switch that can be thrown to fix this. The safe default value (empty
  environment) is exactly what causes the breakage. To point
  admininistrators of failing system in the right direction exim prints
  a warning when keep_environment is not set.

* Afaik the Debian config works fine with empty environment which is why
  we have added an explicit 'keep_environment=" to prevent the runtime
  warning.

* Otoh if you are running a custom configuration you will get
  the warning exactly as upstream has intended and you will need to
  decide whether you need to modify the environment. This also applies
  to configuration based on the Debian configuration. - You'll need to
  look at the configuration and decide whether modifying the runtime
  environment is necessary. (You'll get a dpkg confile prompt and need
  to merge the changes.)

* In addition there is an entry in exim4-config.NEWS.

I am basically out of bright ideas on how to improve things from here.
The whole thing is trade-off, on one side now some people get a warning
message without experincing real breakage, on the other side if I patched
out the warning message some people would just see a broken e-mail
service without the helpful hint. Being in doubt I trusted upstream's
choice.

See http://article.gmane.org/gmane.mail.exim.devel/9142 and following.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#818720: eviacam: [INTL:pt] Portuguese translation for debconf messages

[Américo Monteiro]

Package: eviacam
version: 2.0.3-2
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for eviacam's debconf messages.
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' or the
Portuguese Translation Team .

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro


eviacam_2.0.3-2_pt.po.gz
Description: GNU Zip compressed data

Bug#816720: Bug##816720: gail-common: provide udeb for accessibility

[Michael Biebl]

Am 16.03.2016 um 15:03 schrieb Samuel Thibault:
> Hello gtk maintainers,
> 
> Samuel Thibault, on Mon 07 Mar 2016 03:07:29 +0100, wrote:
>> Samuel Thibault, on Fri 04 Mar 2016 13:56:08 +0100, wrote:
>>> Ok, I'll be testing the attached patch.
>>
>> Yes, it is working, could that be applied to gtk+2.0?
> 
> Ping?

I haveen't looked at the patch in detail yet, just one comment from a
cursory glance: I don't think there is much benefit in splitting the
udeb in libgail18-udeb + libgail-common-udeb, soname transitions are no
concern for d-i after all.
So maybe a single udeb package as we have for libgtk2.0-0
(libgtk2.0-0-udeb) would be more suitable.


-- 
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#818537: maildrop: FTBFS: ./../../depcomp: No such file or directory

[Martin Michlmayr]

Package: maildrop
Version: 2.7.1-3
Severity: serious

This package fails to build in unstable:

> sbuild (Debian sbuild) 0.68.0 (15 Jan 2016) on dl580gen9-02.hlinux
...
> make[3]: Entering directory '/<>/libs/numlib'
> source='atotimet.c' object='atotimet.lo' libtool=yes \
> DEPDIR=.deps depmode=none /bin/bash ./../../depcomp \
> /bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.   
> -Wdate-time -D_FORTIFY_SOURCE=2  -I.. -I./.. -g -O2 -fstack-protector-strong 
> -Wformat -Werror=format-security -Wall -pedantic -Wall -c -o atotimet.lo 
> atotimet.c
> /bin/bash: ./../../depcomp: No such file or directory
> Makefile:452: recipe for target 'atotimet.lo' failed
> make[3]: *** [atotimet.lo] Error 127
> make[3]: Leaving directory '/<>/libs/numlib'
> Makefile:345: recipe for target 'all' failed
> make[2]: *** [all] Error 2
> make[2]: Leaving directory '/<>/libs/numlib'
> Makefile:829: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1

-- 
Martin Michlmayr
Linux for HPE Helion, Hewlett Packard Enterprise

Bug#818113: Info received (I can have)

[Martin Naughton]

Actually i get it now. This is the package that supplied the client library
for you. All the code is in one file called mosquito with subscribe and
publish. I can see that is not available in debian stretch or on available
after jessie.

https://packages.debian.org/wheezy/all/python-mosquitto/

I will package up the new eclipse clients and submit it to debian.

On Thu, Mar 17, 2016 at 10:24 PM, Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  w...@debian.org
>
> If you wish to submit further information on this problem, please
> send it to 818...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 818113: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818113
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>



-- 
Regards
Martin Naughton

Bug#808476: Re : libreoffice-math: Libreoffice math shows 1xxxx utf8 characters incorrectly

[Stéphane Aulery]

Hi,

Le 16/03/2016 20:25, nicolas.patr...@gmail.com a écrit :

Le 02/03/2016 22:22:44, Stéphane Aulery a écrit :


Thanks for your help. I forward the document and comments.


The bug is corrected in LibreOffice:
Version: 5.1.1.3
Build ID: 1:5.1.1-1


You have tested this version and it's good?

Regards,

--
Stéphane Aulery

Bug#768400: libjs-iframe-resizer

[Doug Torrance]

Control: reopen -1
Control: owner -1 !

iframe-resizer is a dependency of WeBWorK, which I am currently packaging
as a member of the Debian Science Team.

Therefore, I plan to package it as a member of the Debian Javascript Team.

Bug#818571: ITP: golang-github-bgentry-speakeasy -- olang helpers for reading password input

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 etcd golang-github-mitchellh-cli

   Package name: golang-github-bgentry-speakeasy
Version: 0.0~git20150902
Upstream Author: Blake Gentry
License: Apache-2.0, Expat
URL: https://github.com/bgentry/speakeasy
Description: Golang helpers for reading password input
 This package provides cross-platform Golang helpers for taking user input
 from the terminal while not echoing the input back (similar to getpasswd).
 The package uses syscalls to avoid any dependence on cgo, and is therefore
 compatible with cross-compiling.


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

Bug#818433: gnome-documents not sourcing liblibreofficegtk.so

[Marc J. Driftmeyer]

Package: gnome-documents
Version: 3.19.4-2
Severity: normal

Dear Maintainer,

Launching gnome-documents causes a crash due to the directory path search for 
liblibreofficegtk.so

Workaround:

/usr/lib/x86_64-linux-gnu/$ sudo ln -s 
/usr/lib/libreoffice/program/liblibreofficekitgtk.so liblibreofficekitgtk.so

Better solution would be teaching the package to search under 
/usr/lib/libreoffice/program

- Marc

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 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 gnome-documents depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.24.0-2
ii  gir1.2-evince-3.03.19.92-1
ii  gir1.2-gdata-0.0 0.17.4-1
ii  gir1.2-gnomedesktop-3.0  3.19.92-1
ii  gir1.2-goa-1.0   3.19.92.1-1
ii  gir1.2-gtk-3.0   3.19.12-1
ii  gir1.2-tracker-1.0   1.7.5-1
ii  gir1.2-webkit2-4.0   2.10.8-1
ii  gir1.2-zpj-0.0   0.0.3-2
ii  gjs  1.45.3-1
ii  gnome-online-miners  3.14.3-1+b1
ii  libc62.22-3
ii  libcairo-gobject21.14.6-1
ii  libcairo21.14.6-1
ii  libevdocument3-4 3.19.92-1
ii  libevview3-3 3.19.92-1
ii  libgdata22   0.17.4-1
ii  libgdk-pixbuf2.0-0   2.33.2-1
ii  libglib2.0-0 2.47.92-1
ii  libgnome-desktop-3-123.19.92-1
ii  libgtk-3-0   3.19.12-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libzapojit-0.0-0 0.0.3-2
ii  tracker  1.7.5-1

Versions of packages gnome-documents recommends:
ii  gir1.2-lokdocview-0.1  1:5.1.1-1
ii  gnome-user-guide   3.18.1-1
ii  libgsf-bin 1.14.36-1
pn  unoconv

gnome-documents suggests no packages.

-- no debconf information

Bug#817803: please specify metadata-by-hash

[Colin Watson]

On Thu, Mar 10, 2016 at 03:33:12PM +0100, Peter Palfrader wrote:
> apt supports content-addressed metadata files (Translations, Packages, 
> Sources, ..).
> 
> With this feature, we can have significantly more robust Debian mirrors.
> 
> Please provide a spec of what apt expects from the archive so our friendly
> ftpteam can implement this archive side.

I know this doesn't replace a proper spec, but if it's helpful, here's
the code I wrote this week at work to implement the archive side of this
in Launchpad (all AGPLv3):

  
https://code.launchpad.net/~cjwatson/launchpad/db-archive-index-by-hash/+merge/289372
  
https://code.launchpad.net/~cjwatson/launchpad/archive-file-model/+merge/289376
  
https://code.launchpad.net/~cjwatson/launchpad/ds-publish-by-hash/+merge/289377
  
https://code.launchpad.net/~cjwatson/launchpad/archive-index-by-hash/+merge/289379

Obviously a lot of this consists of Launchpad specifics such as the
librarian (our large blob storage service) and details of our database
and test setup, but perhaps things like the core algorithm in
Publisher._updateByHash will be of some use.

Note that at the time of writing this is still pending code review, and
I also haven't actually integration-tested it against apt, although I
believe it matches what apt-ftparchive produces; obviously I'll do
proper integration tests on it before inflicting it on the world.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#818599: RM: iceweasel, iceweasel/experimental -- RoQA; renamed to firefox{,-esr}

[Ansgar Burchardt]

Package: ftp.debian.org
Severity: normal

Please remove the iceweasel source package from unstable and
experimental: it was renamed to firefox (firefox-esr) which also
provide transitional packages for the migration.

Please don't close the bugs though.

Ansgar

Bug#818719: ruby-rails-deprecated-sanitizer: FTBFS: action_view/helpers/sanitize_helper (LoadError)

[Chris Lamb]

Source: ruby-rails-deprecated-sanitizer
Version: 1.0.3-1
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

ruby-rails-deprecated-sanitizer fails to build from source in unstable/amd64:

  [..]
  
  
RUBYLIB=/home/lamby/temp/cdt.20160320085914.YMSdAoy2ta/ruby-rails-deprecated-sanitizer-1.0.3/debian/ruby-rails-deprecated-sanitizer/usr/lib/ruby/vendor_ruby:.
 
GEM_PATH=debian/ruby-rails-deprecated-sanitizer/usr/share/rubygems-integration/all:/home/lamby/.gem/ruby/2.3.0:/var/lib/gems/2.3.0:/usr/lib/x86_64-linux-gnu/rubygems-integration/2.3.0:/usr/share/rubygems-integration/2.3.0:/usr/share/rubygems-integration/all
 ruby2.3 -S rake -f debian/ruby-tests.rake
  /usr/bin/ruby2.3 -I"test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/cdata_node_test.rb" 
"test/deprecated_sanitizer_test.rb" "test/document_test.rb" "test/node_test.rb" 
"test/tag_node_test.rb" "test/text_node_test.rb" "test/tokenizer_test.rb" -v
  /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': 
cannot load such file -- action_view/helpers/sanitize_helper (LoadError)
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160320085914.YMSdAoy2ta/ruby-rails-deprecated-sanitizer-1.0.3/test/test_helper.rb:6:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from 
/home/lamby/temp/cdt.20160320085914.YMSdAoy2ta/ruby-rails-deprecated-sanitizer-1.0.3/test/cdata_node_test.rb:1:in
 `'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in 
`require'
from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:15:in `block in 
'
from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:4:in `select'
from /usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb:4:in `'
  rake aborted!
  Command failed with status (1): [ruby -I"test"  
"/usr/lib/ruby/vendor_ruby/rake/rake_test_loader.rb" "test/cdata_node_test.rb" 
"test/deprecated_sanitizer_test.rb" "test/document_test.rb" "test/node_test.rb" 
"test/tag_node_test.rb" "test/text_node_test.rb" "test/tokenizer_test.rb" -v]
  
  Tasks: TOP => default
  (See full trace by running task with --trace)
  ERROR: Test "ruby2.3" failed. Exiting.
  dh_auto_install: dh_ruby --install 
/home/lamby/temp/cdt.20160320085914.YMSdAoy2ta/ruby-rails-deprecated-sanitizer-1.0.3/debian/ruby-rails-deprecated-sanitizer
 returned exit code 1
  debian/rules:6: recipe for target 'binary' failed
  make: *** [binary] Error 1

  [..]

The full build log is attached.


Regards,

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


ruby-rails-deprecated-sanitizer.1.0.3-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#818053: mirror submission for mirror.n5tech.com

[Todd Crane]

Donald,
I have placed this for action for our overnight crew and it should be done by 
tomorrow morning.
Thank you
Todd CraneFounder/CEON5 Tech_
From: Donald Norwood 
Sent: Saturday, March 19, 2016 5:28 PM
Subject: Re: mirror submission for mirror.n5tech.com
To:  <818...@bugs.debian.org>,  


control: tag -1 +moreinfo

Hi,

In reviewing your submission there are two items of concern:

The /project/trace directory does not have the hostfile which indicates
which server this is. Please use the newest ftpsync script:
ftpsync-20160306.tar.gz, it is available in your own /project/ftpsync
directory and will ensure that your copy of the archive is in sync with
the master archive and gives the proper reporting tools.

Please display the README.html file in the /debian/ directory.

Looking forward to your reply.

[1]
Best regards,

Donald Norwood
-Debian Mirrors Team


On Sun, 13 Mar 2016 06:02:27 + "NOC Team"  wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.n5tech.com
> Aliases: mirrors.n5tech.com
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 
> kfreebsd-i386 mips mipsel powerpc s390x sparc 
> Archive-ftp: /debian/
> Archive-http: /debian/
> IPv6: yes
> Archive-upstream: ftp.us.debian.org
> Updates: four
> Maintainer: NOC Team 
> Country: AF Afghanistan
> Location: Phoenix, AZ
> Sponsor: N5 Tech http://www.n5tech.com
> Comment: bandwidth 1gb/s
> 
> 





signature.asc
Description: PGP signature

Bug#806716: Jellyfish name conflicts

[Andreas Tille]

Hi Diego,

On Tue, Mar 15, 2016 at 07:34:39PM +0100, Diego M. Rodriguez wrote:
> > This was not really intended but now it happened.  We now need to
> > decide about the two options:
> > 
> >   1. Cancel the upload to new and drop the python3-jellyfish package
> >   2. Just leave this as is and follow the advise of the jellyfish
> >  author quoted on top of this mail to the python list[4] to
> >  rename just the Python module.
> > 
> > I think option 2. is better for all parts and if you agree I'd
> > immediately cancel the upload to new.
> 
> thanks for the detailed clarification on the events surrounding the
> package and the prompt response!
> 
> I would be happy to go with either option (personally leaning towards
> option 2 as well), and basically rely on your expertise - the upstream
> string-jellyfish author has explicitely mentioned that he has no strong
> opinion on the Debian package name and I don't have either.

H, ftpmaster was fast - now python-jellyfish is accepted.  This only
leaves us option 2 without fiddling around to much.
 
> With this in mind, I'm wondering if this would be a good time to rename
> this ITP and the RFS (and the mentors package, etc) to the hopefully
> final Debian package name ("python-jellyfishstr"?)?

The latter sounds sensible.  Sorry for all the confusion and leaving you
alone a bit with this issue.

Kind regards

  Andreas.



-- 
http://fam-tille.de

Bug#797126: ITP: pdal -- Point Data Abstraction Library

[Sebastiaan Couwenberg]

retitle 797126 ITP: pdal -- Point Data Abstraction Library
thanks

On 08/28/2015 01:08 AM, Bas Couwenberg wrote:
> * Package name: pdal
>   Version : 1.0.0b1
> [...]
> 
> PDAL is a good alternative to liblas, PDAL support LAS 1.4 whereas liblas
> only supports 1.2. liblas development is not very active anymore, pdal
> is very much alive.
> 
> The Debian GIS team is a good home for pdal package.

Packaging for PDAL 1.1.0 [0] and its Python extension [1] are available
in the Debian GIS git repository.

The Python extension is packaged separately using the sources from PyPi,
because the extension cannot be built along with the rest of PDAL.

[0] https://anonscm.debian.org/cgit/pkg-grass/pdal.git
[1] https://anonscm.debian.org/cgit/pkg-grass/python-pdal.git

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#818053: mirror submission for mirror.n5tech.com

[Donald Norwood]

control: tag -1 +moreinfo

Hi,

In reviewing your submission there are two items of concern:

The /project/trace directory does not have the hostfile which indicates
which server this is. Please use the newest ftpsync script:
ftpsync-20160306.tar.gz, it is available in your own /project/ftpsync
directory and will ensure that your copy of the archive is in sync with
the master archive and gives the proper reporting tools.

Please display the README.html file in the /debian/ directory.

Looking forward to your reply.

[1]
Best regards,

Donald Norwood
-Debian Mirrors Team


On Sun, 13 Mar 2016 06:02:27 + "NOC Team"  wrote:
> Package: mirrors
> Severity: wishlist
> User: mirr...@packages.debian.org
> Usertags: mirror-submission
> 
> Submission-Type: new
> Site: mirror.n5tech.com
> Aliases: mirrors.n5tech.com
> Type: leaf
> Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 
> kfreebsd-i386 mips mipsel powerpc s390x sparc 
> Archive-ftp: /debian/
> Archive-http: /debian/
> IPv6: yes
> Archive-upstream: ftp.us.debian.org
> Updates: four
> Maintainer: NOC Team 
> Country: AF Afghanistan
> Location: Phoenix, AZ
> Sponsor: N5 Tech http://www.n5tech.com
> Comment: bandwidth 1gb/s
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#818712: frontend: "pager" doesn't wait/scroll anymore

[Adam Borowski]

On Sun, Mar 20, 2016 at 12:54:15AM +0100, Robert Luberda wrote:
> Adam Borowski writes:
> > Since the last upload, apt-listchanges just blasts all new changelog entries
> > to the terminal instead of feeding them to a pager. 
> 
> Do you use the -y or -q (or --assume-yes or --quiet) option of
> apt-get/aptitude?
> If not, what tool and with what options do you run to perform upgrades?

apt-get -y dist-upgrade

-- 
A tit a day keeps the vet away.

Bug#805609: grilo-plugins: Split grilo-plugins into base and extra

[Alberto Garcia]

On Fri, Nov 20, 2015 at 07:08:20PM +1100, Tim Lunn wrote:

> I discussed this with Alberto earlier in the year, and we went ahead
> and landed the split in Ubuntu last cycle, but seems I never got
> around to forwarding on the changes. Patches to follow.
> 
> https://bugs.launchpad.net/ubuntu/+source/grilo-plugins/+bug/1394731

Ok, so I could finally sit down a bit and take a look at the split
that you propose. I have some doubts, however.

As I see it, plugins should only go to the -extra package if they
require additional dependencies and they are not useful for most
users. Is this also your criteria, or do you have other concerns?

However, I've seen that that almost all plugins have the same
dependencies as libgrilo itself (glib, libxml, libsoup, libsqlite,
...), so I see no reason why they should go to -extra. However you're
putting there some of them:

- dLeyna
- Magnatune
- Podcasts

Then there's the Lua Factory plugin, that enables 10 extra built-in
plugins:

- Apple trailers
- Euronews
- Metrolyrics
- Musicbrainz cover art
- Spotify
- ...

The Lua plugin only depends on liblua, itself a small C++ library with
no special requirements.

From the plugins that you would put in the -extra package only DAAP
and Freebox seem to have additional dependencies, and even those are
quite standard for a GNOME desktop.

What are the ones that concern you the most to have in the main
package, and why?

Berto

Bug#818589: RM: r-other-bio3d -- ROM; Package was renamed to r-cran-bio3d

[Andreas Tille]

Package: ftp.debian.org
Severity: normal

Hi,

the package source of package r-other-bio3d moved from some external place
to CRAN and thus we renamed the package according R policy to r-cran-bio3d.
I just realised that r-other-bio3d remained on the Debian mirror.  Please
remove this package.

Kind regards

  Andreas.

Bug#818580: [pkg-go] Bug#818580: ITP: golang-github-prometheus-client-model -- data model artifacts for Prometheus

[Martín Ferrari]

Dmitry,

On 18/03/16 09:42, Dmitry Smirnov wrote:

>Package name: golang-github-prometheus-client-model
> Version: 0.0.2+git20150212
> Upstream Author: Prometheus Team
> License: Apache-2.0
> URL: https://github.com/prometheus/client_model
> Description: data model artifacts for Prometheus
>  Golang data model artifacts for Prometheus.

THis is already packaged as part of the golang-github-prometheus-common
package.

-- 
Martín Ferrari (Tincho)

Bug#818529: qsf: tries to install /usr/share/doc-base/doc-base file

[Robert Luberda]

Package: qsf
Version: 1.2.7-1.1
Severity: serious
Justification: uninstallable


Unpacking qsf (1.2.7-1.1) over (1.2.7-1+b2) ...
dpkg: error processing archive /var/cache/apt/archives/qsf_1.2.7-1.1_i386.deb 
(--unpack):
 trying to overwrite '/usr/share/doc-base/doc-base', which is also in package 
doc-base 0.10.7


/home/robert> dpkg-deb --contents 
/var/cache/apt/archives/qsf_1.2.7-1.1_i386.deb | grep doc-base
drwxr-xr-x root/root 0 2016-03-16 02:31 ./usr/share/doc-base/
-rw-r--r-- root/root   440 2016-03-16 02:30 ./usr/share/doc-base/qsf
-rw-r--r-- root/root   435 2007-08-28 15:26 ./usr/share/doc-base/doc-base

Regards,
robert


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

Kernel: Linux 4.4.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages qsf depends on:
ii  libc6 2.22-3
ii  libgdbm3  1.8.3-13.1
ii  libmysqlclient18  5.6.28-1
ii  libsqlite02.8.17-12+b1

Versions of packages qsf recommends:
ii  procmail  3.22-25

Versions of packages qsf suggests:
ii  fetchmail   6.3.26-2
ii  mutt1.5.24-1+b1
pn  mysql-server | sqlite   
ii  postfix [mail-transport-agent]  3.0.4-5

-- no debconf information

Bug#818717: deap: more recent version available

[Daniel Stender]

Package: deap
Version: 1.0.1-4
Severity: wishlist
Control: block -1 by 794109

There is more recent version of deap available (1.0.2.post2).

DS

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#818361: xul-ext-debianbuttons: security issues button & pages containing CVEs/DSAs/DLAs

[Paul Wise]

Package: xul-ext-debianbuttons
Severity: wishlist

I wrote a Greasemonkey script to allow me to easily load all the CVEs
mentioned on a page into new browser tabs. I have been thinking that I
should get this into Debian somehow and debianbuttons looks like the
right place for that.

Essentially the idea would be to have the security issues button check
for CVE/DSA/DLA in the clipboard or selection (or the full document if
there is no clipboard or selection) and open each one in a new tab.

If there are none then fall back to just appending the clipboard
keyword to the end of the URL as usual.

If the user wants to not open new tabs then fall back to just appending
the clipboard to the end of the URL as usual.

This should work for most existing uses as well as my use-case too.

The only case it would mess up is someone on a page with CVEs, having
no clipboard and wanting to visit the front page of the sectracker in a
new tab rather than the current tab. Any thoughts on that?

I don't know JavaScript well but I think it should look like this:

    load_uri: function(in_new, uri) {
if (in_new) {
var b = getBrowser();
var new_tab = b.addTab(uri);
b.selectedTab = new_tab;
}
else {
loadURI(uri);
}
},

load_keyword: function(in_new, keyword) {
var uri = "https://security-tracker.debian.org/;;
if (keyword) uri += "tracker/" + keyword;
},

lookup_security: function(in_new) {
var cver = /CVE-[0-9]+-[0-9]+/gi;
var dsar = /DSA-[0-9]+-[0-9]+/gi;
var dlar = /DSA-[0-9]+-[0-9]+/gi;
var cves, dsas, dlas;
var clip = IceDeb.getClipboardText();
var keyw = IceDeb.trim_keyword(clip);
if (clip && clip.length) {
cves = clip.match(cver);
dsas = clip.match(dsar);
dlas = clip.match(dlar);
} else {
var doc = 
content.document.getElementsByTagName('html')[0].innerHTML;
cves = doc.match(cver);
dsas = doc.match(dsar);
dlas = doc.match(dlar);
}
var ids = Array.concat(cves, dsas, dlas);
if (in_new && ids.length) {
for each (id in ids) {
IceDeb.load_keyword(in_new, id);
}
} else {
IceDeb.load_keyword(in_new, keyw);
}
},

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817961: RFS: awesfx/0.5.1e-1 [RC] [ITA]

[Dmitry Eremin-Solenikov]

2016-03-18 4:22 GMT+03:00 Mattia Rizzolo :
> A couple more (introduced with the last iteration):
>
> * d/changelog:
>   + s/DEB-5/DEP-5/ (it's "Debian Enhancement Proposal"), that particular
> one has been formalized as copyright-format 1.0.
>   + move "This version has internal buffer overflow fixed. LP: #744794."
> in a seblevel of the "New upstream release"; clearly, no need to say
> "This version has" while you're in the correct sublevel of a list
>   + document the removal of debian/dirs

Updated the package at mentors.d.o. Please review.

-- 
With best wishes
Dmitry

Bug#818430: ruby-coveralls: please make the build reproducible

[Dhole]

Source: ruby-coveralls 
Version: 0.7.0-2 
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

While working on the "reproducible builds" effort [1], we have noticed
that
ruby-coveralls could not be built reproducibly.

When generating the manpages, ronn uses the local timezone in the
embedded timestamps.

The attached patch fixes this by setting the timezone to UTC before
calling ronn. Once applied, ruby-coveralls can be built reproducibly in
our current experimental framework.

 [1]: https://wiki.debian.org/ReproducibleBuilds

Regards,
-- 
Dhole
diff -Nru ruby-coveralls-0.7.0/debian/changelog 
ruby-coveralls-0.7.0/debian/changelog
--- ruby-coveralls-0.7.0/debian/changelog   2015-12-15 18:17:57.0 
+0100
+++ ruby-coveralls-0.7.0/debian/changelog   2016-03-16 22:55:08.0 
+0100
@@ -1,3 +1,11 @@
+ruby-coveralls (0.7.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Set a deterministic date in the manpages to make the package build
+reproducibly. 
+
+ -- Eduard Sanou   Wed, 16 Mar 2016 22:52:56 +0100
+
 ruby-coveralls (0.7.0-2) unstable; urgency=low
 
   * Add missing B-D on ruby-multi-json. (Closes: #802116).
diff -Nru ruby-coveralls-0.7.0/debian/rules ruby-coveralls-0.7.0/debian/rules
--- ruby-coveralls-0.7.0/debian/rules   2014-03-05 00:51:37.0 +0100
+++ ruby-coveralls-0.7.0/debian/rules   2016-03-17 00:15:04.0 +0100
@@ -16,7 +16,7 @@
 
 override_dh_auto_build:
dh_auto_build
-   ronn --roff debian/coveralls.mkd
+   TZ=UTC ronn --roff debian/coveralls.mkd
 
 override_dh_auto_clean:
dh_auto_clean


signature.asc
Description: PGP signature

Bug#818524: similar on Stretch

[Thanasis Kinias]

I’m seeing something very similar with 0.4.5-1+b1 on a laptop running amd64
testing.  I can’t say exactly when this started, though, as yesterday was
the first time I fired up the game in a while – pretty sure we were on
0.4.4-2 last time I ran it – but freeorion used to run fine on this machine.

Examples of issues are: very high CPU usage on a 2.5GHz i5; 15–20 sec. to
process a turn right at the start of the game; multisecond lags when doing
things like adding builds or techs to the queue; UI lockup/window-repaint
failure; etc.

I nuked my .freeorion directory, too, to no effect.

I compiled from upstream source and didn’t see a dramatic difference from
the performance of the Debian package.

Best,
-- 
Thanasis Kinias
Doctoral Student, Department of History
Northeastern University

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

[Yves-Alexis Perez]

Hi,

On jeu., 2016-03-17 at 10:20 +0100, László Böszörményi (GCS) wrote:
>  It seems linux-grsec will remain i386 and amd64 only.

There's no reason to, actually. It's just that right now I don't have a way to
test on other architectures, so I prefer keeping it that way. But if someone
steps to to maintain it I'm all open.

>  But more
> important that's not suitable for a stable release. Filed by its
> maintainer, Yves-Alexis.

Well, uploading new Linux major version to stable looks indeed not trivial,
(thus my filing of #810506), but ultimately it's the RT's call.

>  The patch itself can be updated more easily
> with point releases and users may compile and test their updated
> kernels before using it. For me this gives more trust in the package,
> even if it needs more attention from time to time.

Well, I'm not sure how much sense that make. Do you intend to ship in stable a
patch completely unrelated to the current kernel and just follow the test
kernel and ship it pristine?
> 
> > I can certainly let you request the removal, or will handle it myself at
> > one point, unless you really want to keep it and have it updated.
>  Sure, I've failed big to keep it up-to-date. But I would like to keep
> this fresh in the archive. Hope upstream will release testing kernels
> every now and then.

I'm not sure what you mean here.
-- 
Yves-Alexis



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

Bug#818576: please provide more context in the title tag

[Raphael Hertzog]

Hi,

On Fri, 18 Mar 2016, Peter Palfrader wrote:
> currently the HTML title tag seems to be the same for all pages
> on tracker.debian.org.

That's a bit exagerated.

FTR, the case that Peter brought me up on IRC was the news page:
https://tracker.debian.org/news/755641 

All the profile pages already have customized titles. The package and team
pages have customized titles as well.

In fact I can't find another page that does not have a customized title.

> Please have the title tag actually be meaningful and represent
> what is on the page.

That said some of those customized titles could be improved by putting
the most specific data at the start of the title instead of after "Debian
Package Tracker".

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#818138: ITP: hunspell-ie -- Interlingue dictionary for Hunspell

[Rene Engelhard]

Hi,

On Tue, Mar 15, 2016 at 02:18:43AM +0600, -скрыто- Алекса wrote:
>> It's supposed to be like
>>
>> hunspell-*: spellchecking dicts
>> hyphen-*: hyphenation patterns
>>
>> there's stuff using hyphen but nbot hunspell, so by "hiding" it in
>hunspell-ie..
> 
>It creates two binary packages with those names.

Nah, that is ok. I was assuming you were mixing them both in hunspell-ie 
(whci hepoele did in the past, for whatever reason).

> What source package name do you propose than? It doesn't have much sense
> to have several source packages for a one language.

Depends, on whether those are usuaually shipped tgether or not. If they are
released idependently it _does_ make sense to have two source packages..

But I was aiming more at the binary packages, which you clarified. No problem
for me remaining :)

Regards,

Rene

Bug#818551: Pending fixes for bugs in the golang-go.tools package

[pkg-go-maintainers]

tag 818551 + pending
thanks

Some bugs in the golang-go.tools package are closed in revision
91d43a0ababd576701d2fd48de78567a734b1577 in branch 'master' by
Michael Hudson-Doyle

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-go.tools.git/commit/?id=91d43a0

Commit message:

Rename bundle to golang-bundle. (Closes: #818551)

Bug#608811: aptitude: Should prefer to install package in experimental rather than no version at all

[Manuel A. Fernandez Montecelo]

Control: tags -1 + wontfix


Hi,

2011-01-03 17:16 Nelson A. de Oliveira:

Package: aptitude
Version: 0.6.3-3.2
Severity: wishlist

Hi!

See:

=
# aptitude install transmission-cli
The following NEW packages will be installed:
 transmission-cli{b}
0 packages upgraded, 1 newly installed, 0 to remove and 4 not upgraded.
Need to get 378 kB of archives. After unpacking 811 kB will be used.
The following packages have unmet dependencies:
 transmission-cli: Depends: transmission-common (= 2.03-2) but 2.11-1 is 
installed.
The following actions will resolve these dependencies:

Keep the following packages at their current version:
1) transmission-cli [Not Installed]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

Install the following packages:
1) transmission-cli [2.11-1 (experimental)]



Accept this solution? [Y/n/q/?]
=

The first option is to keep the current version (to not install the
package); it's necessary to ask for the next solution to get what I
want.


aptitude doesn't know that you prefer to install the version from
experimental than the one from unstable, if it's pinned lower:


=
# apt-cache policy transmission-cli
transmission-cli:
 Installed: (none)
 Candidate: 2.03-2
 Version table:
2.11-1 0
   100 http://ftp.us.debian.org/debian/ experimental/main i386 Packages
2.03-2 0
   500 http://ftp.us.debian.org/debian/ sid/main i386 Packages
=

While I know that the install candidate is 2.03-2 (and aptitude will try
to install it), aptitude should prefer to install the new package at
experimental. The first logical solution seems to be "install the
version from experimental"


There are safety mechanisms in aptitude to not install versions from
"non-default versions", and there are many bugs already complaining that
it's very easy for them to install versions in aptitude inadvertently,
even when aptitude prints "experimental" in the process.

So many people would not agree that installing from "experimental" is
the first logical solution.



(since it already has all the dependencies
installed and it has been asked to install it) instead not installing the
desired package.


The request was to install the package from the (implicit) default
version.

To install particular versions or from other suites (from "man
aptitude"):

 install

   Install one or more packages. The packages should be listed after
   the “install” command; if a package name contains a tilde character
   (“~”) or a question mark (“?”), it will be treated as a search
   pattern and every package matching the pattern will be installed
   (see the section “Search Patterns” in the aptitude reference
   manual).

   To select a particular version of the package, append “=”
   to the package name: for instance, “aptitude install
   apt=0.3.1”. Similarly, to select a package from a particular
   archive, append “/” to the package name: for instance,
   “aptitude install apt/experimental”. You cannot specify both an
   archive and a version for a package.

So marking this as +wontfix.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#818111: noise in the noise source package creation step

[Holger Levsen]

Hi Gunnar,

in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818111#10 you
wrote:

> However, even with this, the package is *not yet* built reproducibly:
> There is still a source of noise for the source package creation
> step. 

I'm not sure you ment this(?) but it's a known (+sad) fact, that we
cannot create reproducible source packages yet. So don't bother about
this yet. Or did you mean something else?

> Maybe the answer would be to stop hand-building everything and
> update our packaging format to dh-based or something like that?

I think you should do this anyway. dh9 totally rocks :)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#818369: RFS: clblas/2.10-2

[Gianfranco Costamagna]

Done :)

cheers,

G.





Il Mercoledì 16 Marzo 2016 15:06, Ghislain Vaillant  ha 
scritto:
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "clblas"

* Package name: clblas
   Version : 2.10-2
   Upstream Author : Advanced Micro Devices, Inc.
* URL : https://github.com/clMathLibraries/clFFT
* License : Apache version 2
   Section : science

It builds those binary packages:

   libclblas-bin - OpenCL BLAS library (executables)
   libclblas-dev - OpenCL BLAS library (development files)
   libclblas-doc - OpenCL BLAS library (documentation)
   libclblas2 - OpenCL BLAS library (shared library)
   libclblas2-dbg - OpenCL BLAS library (debugging symbols)

To access further information about this package, please visit the 
following URL:

  http://mentors.debian.net/package/clblas

Alternatively, one can download the package with dget using this command:

   dget -x 
http://mentors.debian.net/debian/pool/main/c/clblas/clblas_2.10-2.dsc

Successful build log on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/clblas/2.10-2/buildlog

Changes since the last upload:

   * d/gbp.conf: change packaging branch to debian/master (DEP-14).
   * libclblas-dev: add install dependency on opencl-dev.
   * Use secure VCS-Git URI.
   * Bump standards version to 3.9.7, no changes required.
   * d/control: cme fix, wrap and sort.
   * d/copyright: update dates.

Best regards,
Ghislain Vaillant

Bug#818564: hidrd: FTBFS: inst.h:106: hidrd_fmt_init: Assertion `hidrd_fmt_valid(fmt)' failed.

[Chris Lamb]

Source: hidrd
Version: 0.2.0-11
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

hidrd fails to build from source in unstable/amd64:

  [..]

  # XFAIL: 0
  # FAIL:  0
  # XPASS: 0
  # ERROR: 0
  
  make[5]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/util'
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/util'
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/util'
  Making check in usage
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/usage'
  make  check-am
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/usage'
  make[4]: Nothing to be done for 'check-am'.
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/usage'
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/usage'
  Making check in item
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  make  hidrd_item_any_test
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  gcc -DHAVE_CONFIG_H -I. -I../..   
-I/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0 
-I/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/include 
-D_GNU_SOURCE -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -Werror -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -c -o any_test.o 
any_test.c
  /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -Wall -Wextra -Werror -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -o 
hidrd_item_any_test any_test.o ../usage/libhidrd_usage.la libhidrd_item.la 
  libtool: link: gcc -Wall -Wextra -Werror -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z -Wl,relro -o .libs/hidrd_item_any_test 
any_test.o  ../usage/.libs/libhidrd_usage.so ./.libs/libhidrd_item.so
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  make  check-TESTS
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  make[5]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  PASS: hidrd_item_any_test
  
  Testsuite summary for hidrd 0.2.0
  
  # TOTAL: 1
  # PASS:  1
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  0
  # XPASS: 0
  # ERROR: 0
  
  make[5]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  make[3]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/item'
  Making check in opt
  make[3]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/opt'
  make  hidrd_opt_test
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/opt'
  gcc -DHAVE_CONFIG_H -I. -I../..   
-I/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0 
-I/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/include 
-D_GNU_SOURCE -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -Wextra -Werror -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -c -o test.o test.c
  /bin/bash ../../libtool  --tag=CC   --mode=link gcc  -Wall -Wextra -Werror -g 
-O2 -fstack-protector-strong -Wformat -Werror=format-security  -Wl,-z,relro -o 
hidrd_opt_test test.o libhidrd_opt.la 
  libtool: link: gcc -Wall -Wextra -Werror -g -O2 -fstack-protector-strong 
-Wformat -Werror=format-security -Wl,-z -Wl,relro -o .libs/hidrd_opt_test 
test.o  ./.libs/libhidrd_opt.so
  make[4]: Leaving directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/opt'
  make  check-TESTS
  make[4]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/opt'
  make[5]: Entering directory 
'/home/lamby/temp/cdt.20160318102147.XL5ZBkNaUa/hidrd-0.2.0/lib/opt'
  PASS: hidrd_opt_test
  
  Testsuite summary for hidrd 0.2.0
  
  # TOTAL: 1
  # PASS:  1
  # SKIP:  0
  # XFAIL: 0
  # FAIL:  0
  # XPASS: 0
  # ERROR: 0
  
  make[5]: Leaving directory 

Bug#817789: Fixed the bug

[Georges Khaznadar]

Hi,
It was just adding a new dependency.

I need blogdiag as a dependency of seelablet, so I have made a NMU to
delayed+9.

Tell me if you prefer managing this bug report in some other way.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#818541: libbind-dev: arch-dependent files in "Multi-Arch: same" package

[Jakub Wilk]

Package: libbind-dev
Version: 1:9.10.3.dfsg.P2-5
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libbind-dev is marked as "Multi-Arch: same", but the following files are 
architecture-dependent:


/usr/include/isc/atomic.h
/usr/include/isc/platform.h

An example diff between i386 and arm64 is attached.

--
Jakub Wilk
diff -ur libbind-dev_9.10.3.dfsg.P2-5_i386/usr/include/isc/atomic.h 
libbind-dev_9.10.3.dfsg.P2-5_arm64/usr/include/isc/atomic.h
--- libbind-dev_9.10.3.dfsg.P2-5_i386/usr/include/isc/atomic.h  2016-03-04 
06:06:43.0 +0100
+++ libbind-dev_9.10.3.dfsg.P2-5_arm64/usr/include/isc/atomic.h 2016-03-04 
06:10:40.0 +0100
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2005, 2007, 2008  Internet Systems Consortium, Inc. ("ISC")
+ * Copyright (C) 2005, 2007  Internet Systems Consortium, Inc. ("ISC")
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -14,163 +14,11 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-/* $Id: atomic.h,v 1.10 2008/01/24 23:47:00 tbox Exp $ */
+/* $Id: atomic.h,v 1.4 2007/06/19 23:47:18 tbox Exp $ */
 
 #ifndef ISC_ATOMIC_H
 #define ISC_ATOMIC_H 1
 
-#include 
-#include 
+/* This file is inherently empty. */
 
-#ifdef ISC_PLATFORM_USEGCCASM
-/*
- * This routine atomically increments the value stored in 'p' by 'val', and
- * returns the previous value.
- */
-static __inline__ isc_int32_t
-isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
-   isc_int32_t prev = val;
-
-   __asm__ volatile(
-#ifdef ISC_PLATFORM_USETHREADS
-   "lock;"
-#endif
-   "xadd %0, %1"
-   :"=q"(prev)
-   :"m"(*p), "0"(prev)
-   :"memory", "cc");
-
-   return (prev);
-}
-
-#ifdef ISC_PLATFORM_HAVEXADDQ
-static __inline__ isc_int64_t
-isc_atomic_xaddq(isc_int64_t *p, isc_int64_t val) {
-   isc_int64_t prev = val;
-
-   __asm__ volatile(
-#ifdef ISC_PLATFORM_USETHREADS
-   "lock;"
-#endif
-   "xaddq %0, %1"
-   :"=q"(prev)
-   :"m"(*p), "0"(prev)
-   :"memory", "cc");
-
-   return (prev);
-}
-#endif /* ISC_PLATFORM_HAVEXADDQ */
-
-/*
- * This routine atomically stores the value 'val' in 'p'.
- */
-static __inline__ void
-isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
-   __asm__ volatile(
-#ifdef ISC_PLATFORM_USETHREADS
-   /*
-* xchg should automatically lock memory, but we add it
-* explicitly just in case (it at least doesn't harm)
-*/
-   "lock;"
-#endif
-
-   "xchgl %1, %0"
-   :
-   : "r"(val), "m"(*p)
-   : "memory");
-}
-
-/*
- * This routine atomically replaces the value in 'p' with 'val', if the
- * original value is equal to 'cmpval'.  The original value is returned in any
- * case.
- */
-static __inline__ isc_int32_t
-isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
-   __asm__ volatile(
-#ifdef ISC_PLATFORM_USETHREADS
-   "lock;"
-#endif
-   "cmpxchgl %1, %2"
-   : "=a"(cmpval)
-   : "r"(val), "m"(*p), "a"(cmpval)
-   : "memory");
-
-   return (cmpval);
-}
-
-#elif defined(ISC_PLATFORM_USESTDASM)
-/*
- * The followings are "generic" assembly code which implements the same
- * functionality in case the gcc extension cannot be used.  It should be
- * better to avoid inlining below, since we directly refer to specific
- * positions of the stack frame, which would not actually point to the
- * intended address in the embedded mnemonic.
- */
-#include   /* for 'UNUSED' macro */
-
-static isc_int32_t
-isc_atomic_xadd(isc_int32_t *p, isc_int32_t val) {
-   UNUSED(p);
-   UNUSED(val);
-
-   __asm (
-   "movl 8(%ebp), %ecx\n"
-   "movl 12(%ebp), %edx\n"
-#ifdef ISC_PLATFORM_USETHREADS
-   "lock;"
-#endif
-   "xadd %edx, (%ecx)\n"
-
-   /*
-* set the return value directly in the register so that we
-* can avoid guessing the correct position in the stack for a
-* local variable.
-*/
-   "movl %edx, %eax"
-   );
-}
-
-static void
-isc_atomic_store(isc_int32_t *p, isc_int32_t val) {
-   UNUSED(p);
-   UNUSED(val);
-
-   __asm (
-   "movl 8(%ebp), %ecx\n"
-   "movl 12(%ebp), %edx\n"
-#ifdef ISC_PLATFORM_USETHREADS
-   "lock;"
-#endif
-   "xchgl (%ecx), %edx\n"
-   );
-}
-
-static isc_int32_t
-isc_atomic_cmpxchg(isc_int32_t *p, isc_int32_t cmpval, isc_int32_t val) {
-   UNUSED(p);
-   UNUSED(cmpval);
-   UNUSED(val);
-
-   __asm (
-   "movl 8(%ebp), %ecx\n"
-   "movl 12(%ebp), %eax\n" /* must be %eax for cmpxchgl */
-   "movl 16(%ebp), 

Bug#818428: [Pkg-utopia-maintainers] Bug#818428: lost wlan0 (r8723au) on upgrade

[Michael Biebl]

Hi

Am 17.03.2016 um 00:26 schrieb Joey Hess:
> nmcli list no longer lists my wlan0 device. It's still there in
> iwconfig. Other (external) wifi devices are still listed and work.
> 
> This was caused by the upgrade to this version of network-manager.
> Downgrading to 1.1.90-6 got it managing wlan0 again.
> 
> Before that solution, I tried restarting network-manager, rebooting,
> etc. Nothing worked.
> 
> Oddly, after the downgrade fixed the problem, I re-upgraded and now 
> this version is managing wlan0. Hmm, something fishy going on.

That sounds a bit like #817115.
A debug log of NetworkManager might help


-- 
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#818718: ITP: python-pdal -- Point Data Abstraction Library - Python extension

[Bas Couwenberg]

Package: wnpp
Severity: wishlist
Owner: Bas Couwenberg 

* Package name: python-pdal
  Version : 1.1.0+ds
  Upstream Author : Hobu, Inc. 
* URL : https://pypi.python.org/pypi/PDAL
* License : BSD-3-Clause
  Programming Lang: Python/C++
  Description : Point Data Abstraction Library - Python extension

PDAL is a BSD licensed library for translating and manipulating point
cloud data of various formats. PDAL can be used to read, write and
translate point cloud data in many formats. Support is included for
input files of LAS, LAZ, SBET, BPF, QFIT and others. PDAL can also read
from and write to databases that support point cloud storage, including
Oracle, Postgres and SQLite.

PDAL should not be confused with PCL (Point Cloud Library). PCL is a
library specifically designed to provide algorithmic analysis and
modification of point clouds. PDAL provides a limited interface to the
facilities of PCL, but does not in general attempt to duplicate its
capabilities.


The Python extension is packaged separately from PDAL (#797126) using
the sources from PyPi, because the extension cannot be built along with
the rest of PDAL.

The python-pdal package will be maintained along with pdal in the
Debian GIS team.

Bug#817757: motion: FTBFS on kfreebsd-amd64: #error This header is not available for amd64

[Ximin Luo]

Steven Chamberlain:
> Steven Chamberlain wrote:
>> I've attached a quick and easy fix for this, but it's not suitable to go
>> upstream.
> 
> Oops, attached now.
> 

Hey Steven, thanks for the patch. Just to confirm, it's not going to interfere 
with the i386 build is it? I guess the current successful kfreebsd-i386 build 
must have been against older libraries, and would fail now against the current 
libraries, if I don't apply this patch?

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git