Bug#811377: RFA: sysvinit -- System-V-like init utilities - transitional package

[Michael Biebl]

On Tue, Jan 19, 2016 at 01:20:47PM +, Ben Hutchings wrote:
> An additional point from Petter Reinholdtsen:
> 
> 09:39 < pere> bwh: note, the insserv and startpar packages are part of the 
>   sysvinit group of packages, and should probably be handled by 
> the 
>   same group of people.

I've filed

RFA: insserv -- boot sequence organizer using LSB init.d script
dependency information
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834284

RFA: startpar -- run processes in parallel and multiplex their output
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834283

Regards,
Michael

Bug#834239: blends-tasks: Add FreedomBox to debian-blends-tasks

[Jonas Smedegaard]

Hi James,

Quoting James Valleroy (2016-08-14 00:34:27)
> On Sat, 13 Aug 2016 19:26:51 +0200 Jonas Smedegaard  wrote:
>> Quoting James Valleroy (2016-08-13 18:36:02)
>>> The attached patch will add FreedomBox to the blends tasks list, 
>>> shown in Debian installer.
>>>
>>> Note one issue: Selecting this item will install freedombox-setup 
>>> package, but that is not quite sufficient to get a working 
>>> FreedomBox. The user will need to run /usr/lib/freedombox/setup and 
>>> reboot, to complete the setup process.
>>
>> What does that mean? What works and does not work without running it?
> 
> 
> What works: The dependencies for freedombox-setup are all installed 
> and running, with their default configurations. This includes apache2, 
> avahi-daemon, firewalld, network-manager, ntp, and others.
> 
> 
> What doesn't work:
> - Plinth is not accessible through apache, because its apache conf is
> not enabled yet.
> - firewalld with default config will block incoming HTTP, HTTPS, XMPP,
> etc., because zones and services have not been configured yet.
> 
> These start working after /usr/lib/freedombox/setup is run.

Thanks for clarifying.

Please correct me if I am wrong: As I understand it, access to Plinth 
via a web interface is not an optional feature of FreedomBox but a 
crucial core mechanism.

To me that sounds like in its current state you will not get a working 
blend without that custom script, and I therefore recommend to postpone 
inclusion of FreedomBox into debian-blends-tasks until fixed.


>>> We are working to resolve this issue. But, I'm hoping that it is not 
>>> so bad that it would prevent FreedomBox from being added to the 
>>> list.
>>
>> Is that tracked in a bugreport where interested parties can follow
>> progress?
> 
> 
> I just reported bug #834260 to track the progress.

Great!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#834262: RFS: pdfrw/0.2-3 [QA] -- PDF file manipulation library

[Johannes Schauer]

Hi Sean,

Quoting Sean Whitton (2016-08-13 23:30:54)
> Changes since the last upload:
> 
>   * QA upload.
>   * Drop "Conflicts:/Provides:/Replaces: pdfrw" lines (Closes: #814289).
> The pdfrw binary package is long gone and was never part of a release.
> This fixes co-installing python-pdfrw and python3-pdfrw, and other
> package combinations.
> Thanks to Aaron M. Ucko and Yuri D'Elia for useful information.
>   * d/copyright improvements:
> - Add proper DEP-5 header
> - Correct licence name MIT -> Expat
> - Factor out Expat license text into its own paragraph
> - Update copyright years for Patrick Maupin
> - Add missing copyrights of Attila Tajti, Narijus Mika & Mathieu Fenniak
>   See LICENSE.txt in upstream source.
>   * Fix Vcs-* URIs.
> They were previously pointing at the dgit repo for src:botch.

whoops! I have *no idea* who could've made this mistake! :D

>   * Declare compliance with Policy 3.9.8 (no changes required).
>   * Drop duplicate build-dependency on python-setuptools.
>   * Run wrap-and-sort -abst

Thanks, I did not know of wrap-and-sort. It looks useful!

> Since this package already has history on the dgit git server, I would
> like to request that the package be sponsored using dgit (non-DDs cannot
> push the history there).  To do that:
> 
> dgit clone pdfrw
> cd pdfrw
> git remote add -f spwhitton https://git.spwhitton.name/pdfrw
> git merge --ff-only spwhitton/master

This failed.

Instead, I rebased your branch on top of dgit/sid (which worked without
conflicts) and then rebased dgit/sid on top of your branch.

> git log -1
> # ^ confirm that commit hash is d715f1ef184907956865d94be4f14648bb279342

The latest commit hash in dgit/sid is now obviously different due to the rebase
but I confirmed it to be the right hash in your branch.

> # now perform all your pre-upload tests, builds etc., and then:
> dgit build-source
> dgit push

The last command is missing a -k. Otherwise it will fail because gpg cannot
find your private key on my system. ;)

Thanks a lot for your work!

Your changes all look good and thus I built, tested and uploaded the package
unstable.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#834283: RFA: startpar -- run processes in parallel and multiplex their output

[Michael Biebl]

Package: wnpp
Severity: normal


Following the advice in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377#10
I request an adopter for the startpar package, which should be taken
over along with sysvinit and insserv.

The package description is:
 Used by the sysv-rc boot system executor to run init.d scripts in parallel
 while making sure the script output is not completely messed up.

Bug#834284: RFA: insserv -- boot sequence organizer using LSB init.d script dependency information

[Michael Biebl]

Package: wnpp
Severity: normal

Following the advice in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377#10
I request an adopter for the insserv package, which should be taken
over along with sysvinit and startpar.

The package description is:
 The insserv program is used by the standard SysV-based init system. It
 updates the order of symlinks in /etc/rc?.d/ based on dependencies
 specified by LSB headers in the init.d scripts themselves.
 .
 These declared relations between scripts make it possible to optimize
 the boot sequence for the currently installed set of packages, while
 detecting and rejecting dependency loops.
 .
 Using insserv incorrectly can result in an unbootable system.

Bug#834282: ITP: squid-prefetch -- Simple page-prefetch for Squid3 web proxy

[hiroshi]

Package: wnpp
Severity: wishlist
Owner: hiroshi 

* Package name: squid-prefetch
  Version : 1.1-3
  Upstream Author :
* URL :
* License : (public domain)
  Programming Lang: Perl
  Description : Simple page-prefetch for Squid3 web proxy

Squid-Prefetch will perform early fetches of pages
linked to by pages already read.
This means that a user that clicks on a link will have
that new page appear instantly instead of having to
wait for it to be fetched from the Internet.
Only text pages are prefetched on the assumption that
the images can be loaded later so long as the text
of a page is available for display.

orphaned package squid-prefetch_1.1-3 was fixed to use with squid3.
also fixed error on install.

Bug#834271: notmuch: FTBFS in testing

[David Bremner]

Santiago Vila  writes:

> Package: src:notmuch
> Version: 0.22.1-2
> Severity: serious
>
> Dear maintainer:
>
> This package currently fails to build from source in stretch:
>

Attached please find a debdiff that fixes the problem in unstable. I'm
fairly certain it's the same problem (same spurious output) as in
testing. I'm not sure when I'll be able to upload this, so if someone
wants to NMU/sponsor it, feel free.

You can also find the changes in upstream git

git clone git://git.notmuchmail.org/git/notmuch -b release

diff -Nru notmuch-0.22.1/debian/changelog notmuch-0.22.1/debian/changelog
--- notmuch-0.22.1/debian/changelog	2016-07-19 20:51:33.0 +0900
+++ notmuch-0.22.1/debian/changelog	2016-08-14 13:31:13.0 +0900
@@ -1,3 +1,10 @@
+notmuch (0.22.1-3) unstable; urgency=medium
+
+  * Gag gdb even more. Bug fix: "FTBFS in testing", thanks to Santiago
+Vila (Closes: #834271).
+
+ -- David Bremner   Sun, 14 Aug 2016 13:31:13 +0900
+
 notmuch (0.22.1-2) unstable; urgency=medium
 
   * Add explicit build-depends on gnupg, for the test suite.
diff -Nru notmuch-0.22.1/debian/.gitignore notmuch-0.22.1/debian/.gitignore
--- notmuch-0.22.1/debian/.gitignore	2016-07-19 20:51:33.0 +0900
+++ notmuch-0.22.1/debian/.gitignore	1970-01-01 09:00:00.0 +0900
@@ -1,14 +0,0 @@
-tmp/
-libnotmuch-dev/
-libnotmuch*/
-notmuch-emacs/
-notmuch/
-notmuch-dbg/
-notmuch-mutt/
-notmuch-vim/
-ruby-notmuch/
-python*-notmuch/
-*.debhelper
-*.debhelper.log
-*.substvars
-files
diff -Nru notmuch-0.22.1/debian/patches/0001-test-make-gdb-even-quieter.patch notmuch-0.22.1/debian/patches/0001-test-make-gdb-even-quieter.patch
--- notmuch-0.22.1/debian/patches/0001-test-make-gdb-even-quieter.patch	1970-01-01 09:00:00.0 +0900
+++ notmuch-0.22.1/debian/patches/0001-test-make-gdb-even-quieter.patch	2016-08-14 13:31:13.0 +0900
@@ -0,0 +1,46 @@
+From af42874b5911791b8593aaeb1424c7ba444abd15 Mon Sep 17 00:00:00 2001
+From: David Bremner 
+Date: Tue, 28 Jun 2016 23:08:54 +0200
+Subject: [PATCH] test: make gdb even quieter
+
+gdb sometimes writes warnings to stdout, which we don't need/want, and
+for some reason --batch-silent isn't enough to hide. So in this commit
+we write them to a log file, which is probably better for debugging
+anyway. To see an illustrative test failure before this change, run
+
+% make
+% touch notmuch-count.c
+% cd test && ./T060-count.sh
+
+(cherry picked from commit f45fa5bdd397d52473f7092f7ae3e2ffb9b7aee5)
+---
+ test/T060-count.sh  | 2 ++
+ test/T070-insert.sh | 2 ++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/test/T060-count.sh b/test/T060-count.sh
+index 0ac8314..d6933a7 100755
+--- a/test/T060-count.sh
 b/test/T060-count.sh
+@@ -103,6 +103,8 @@ restore_database
+ 
+ cat < count-files.gdb
+ set breakpoint pending on
++set logging file count-files-gdb.log
++set logging on
+ break count_files
+ commands
+ shell cp /dev/null ${MAIL_DIR}/.notmuch/xapian/postlist.${db_ending}
+diff --git a/test/T070-insert.sh b/test/T070-insert.sh
+index e7ec6a6..c2485bb 100755
+--- a/test/T070-insert.sh
 b/test/T070-insert.sh
+@@ -192,6 +192,8 @@ for code in OUT_OF_MEMORY XAPIAN_EXCEPTION FILE_NOT_EMAIL \
+ gen_insert_msg
+ cat < index-file-$code.gdb
+ set breakpoint pending on
++set logging file index-file-$code.log
++set logging on
+ break notmuch_database_add_message
+ commands
+ return NOTMUCH_STATUS_$code
diff -Nru notmuch-0.22.1/debian/patches/series notmuch-0.22.1/debian/patches/series
--- notmuch-0.22.1/debian/patches/series	1970-01-01 09:00:00.0 +0900
+++ notmuch-0.22.1/debian/patches/series	2016-08-14 13:31:13.0 +0900
@@ -0,0 +1,2 @@
+# exported from git by git-debcherry
+0001-test-make-gdb-even-quieter.patch

Bug#834035: kdb5_util hangs forever

[Greg Hudson]

>From what I can tell, _LARGEFILE_SOURCE only seems to provide prototypes
for fseeko() and ftello().  I assume Sam means building such that off_t
is 64 bits, which I think requires defining _FILE_OFFSET_BITS=64.

off_t doesn't appear in any public krb5 header file, so there shouldn't
be any direct ABI impact from building with 64-bit off_t.  There is one
instance of FILE * in gssrpc/xdr.h.  Do those interoperate between the
_FILE_OFFSET_BITS=64 universe and the regular universe?

Bug#834281: libgnupg-interface-perl: FTBFS, test failures, probably gpg2

[gregor herrmann]

Package: libgnupg-interface-perl
Version: 0.52-2
Severity: serious
Tags: upstream
Justification: fails to build from source
Forwarded: https://rt.cpan.org/Public/Bug/Display.html?id=102651

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As detected by ci.debian.net and confirmed locally,
libgnupg-interface-perl's testsuite fails; probably due to gpg
being gpg2 now:

https://ci.debian.net/data/packages/unstable/amd64/libg/libgnupg-interface-perl/20160813_032126.autopkgtest.log.gz


Cheers,
gregor

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQJ8BAEBCgBmBQJXr+ozXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREMUUxMzE2RTkzQTc2MEE4MTA0RDg1RkFC
QjNBNjgwMTg2NDlBQTA2AAoJELs6aAGGSaoGaOMQALkEaIUpCtCASpebjRxtwtvs
dY+nL+AAd+2bHjABLs7rKDdZR8djz00R5cuSJV+W7NEJKxWjG61kVAi4UDbJhusR
mXi5I20a+MBX9Zun9y/B/RuucEJhxNA+re5CcBy4Gib+l/d/ppITl34zmtVwKWec
ON5RxoxM5dgQYZ9LNcBd0ibOl5oKCvNw/DA166hHARWVRLKPHWJyIG0vvbMZ8Sls
pZWazEmBUyDim70b35N9MfKpns3AkWF7F+Qf6d9r06w85Le6Ha36R8gUhAG0pTsR
PaZj9MmdppNeKVv/UN7IurBvUrFT86hNEE6n5vKcbOKFvMsLoGG+nhthFCeojV7L
qQZK4MEKrczTMd/I924RdllJaiI03gpWMkj/X5zQjHfzdBmMZgAfuMPi3IWkyHx9
+i97v49a/lB5bHpDphS1iExw59EtWV6vxKI95zzkzmyY6xQGhAWasglyJcHled0b
Ko3bP6mj/6hLXaKdPAKFqiMWlA7+GYWS0R47nE3ZrY8WBIeLu7lkFuqlul1MlA5h
7soPJMXYLevHhannnXDH7bwwCMkuvwUUfZXGFkQHqOck2bn8bGBKhZY3ZVnAe79L
8aEN/dR4NNz+ybdgpz4S5rLJRDhO9mU1nkxBqQDl81+sh8sh4q97suZHSvshWZQA
wzCRLS6/dHf2nZU93lap
=MBlZ
-END PGP SIGNATURE-

Bug#829032: assword does scary things when the window it wants to type into goes away

[Jameson Graef Rollins]

On Wed, Jun 29 2016, Daniel Kahn Gillmor  wrote:
> If i don't notice that the dialog went away before hitting enter,
> assword appears to type the password into some arbitrary window.
>
> instead, assword should decline to type (and possibly should show the
> user an error message when it can figure out what happened).
>
> Even better would be if "assword gui" could detect when the target
> window goes away, so that it could interrupt the user even before they
> select a context.

How can assword detect that the original window has disappeared?  Is
there an xdo command that can provide that info?

jamie.


signature.asc
Description: PGP signature

Bug#834199: dh-make-perl: Uses deprecated Dpkg::Source:Package variable

[gregor herrmann]

On Sat, 13 Aug 2016 02:03:19 +0200, Guillem Jover wrote:

> This package uses the scalar $diff_ignore_default_regexp from the
> Dpkg::Source::Package module, which was deprecated in dpkg 1.17.2.
> Please switch to use the get_default_diff_ignore_regex() function.

Fixed in git.

(In a quite ugly way, since "use constant foo => qr/STRING/" works
but not the same with a FUNCTION. Improvements welcome.)
 
> (For reference, this is documented in the man page for the module and
> was mentioned in the debian/changelog. I'm not sure how to make this
> kind of thing more visible to API users, 

Good question. I read the changelog of important packages like dpkg
carefully but I didn't know by heart that dh-make-perl uses
$diff_ignore_default_regexp ... I guess in the end there's no real
safe alternative to bug reports after the fact :/


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles


signature.asc
Description: Digital Signature

Bug#834199: Pending fixes for bugs in the dh-make-perl package

[pkg-perl-maintainers]

tag 834199 + pending
thanks

Some bugs in the dh-make-perl package are closed in revision
491c2e45dd25de42dd1969290fbd9dd785416b40 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/dh-make-perl.git/commit/?id=491c2e4

Commit message:

Use Dpkg::Source::Package's get_default_diff_ignore_regex() function

instead of the deprecated $diff_ignore_default_regexp string.

Thanks: Guillem Jover for the bug report.
Closes: #834199

Bug#834280: opensmtpd: missing dependency on ed

[Jeremy Volkening]

Package: opensmtpd
Version: 5.7.3p2-1~bpo8+1
Severity: important

Dear Maintainer,

opensmtpd from jessie-backports failed to install on a fresh server at 
the "dpkg --configure" stage. I was able to track this down to a line in 
the postinstall script calling "ed" to modify "/etc/aliases". "ed" was 
not installed on the system and does not appear to be specified as a 
dependency of the opensmtpd package. Installing "ed" from the repos 
allowed me to install opensmtpd without errors.

It seems necessary to either add a dependency on "ed" or modify the 
postinstall script to not use it.

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

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

Bug#777182: kerberos-configs: please make the build reproducible

[Sam Hartman]

Hi.  kerberos-configs also hasn't been uploaded in 555 days:-)
It's a fairly static package, and I don't think reproducible builds adds
enough value to this package to justify an upload just for this patch.
That said, I've reviewed the patch, and it seems entirely reasonable, so
I will include it in the next upload.

However, looking at the outstanding bugs, #741051 does seem worth
dealing with.
I'll try to get to something including this patch and that bug in the
next couple of months.

I'd prefer not an NMU for this issue alone, because the effort of
integrating the NMU changes seems lower than the value of getting this
package to build reproducibly, but if there is an NMU for another reason
I'd recommend including this patch.

Bug#834279: phpldapadmin: please make the build reproducible

[Chris Lamb]

Source: phpldapadmin
Version: 1.2.2-6
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: umask
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that phpldapadmin could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2016-08-14 02:18:46.614591767 +0100
--- b/debian/rules  2016-08-14 02:19:43.771041257 +0100
@@ -57,11 +57,11 @@
dh_installdocs
dh_install
dh_compress
-   dh_fixperms
dh_install debian/conf/apache.conf /etc/phpldapadmin/
dh_link /etc/phpldapadmin/templates /usr/share/phpldapadmin/templates
dh_link /usr/share/doc/phpldapadmin /usr/share/phpldapadmin/doc
dh_installdebconf -pphpldapadmin
+   dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums

Bug#806494: gnupg: please make the build reproducible

[Chris Lamb]

affects -1 + gnupg1
thanks

> gnupg: please make the build reproducible

(And gnupg1 now after rename..)


Regards,

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

Bug#809013: hy: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: hy
> Version: 0.10.1-1
> Tags: patch

There hasn't seem to be any update on this bug in 231 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777408: mh-book: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: mh-book
> Version: 200605-1
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777401: sauce: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: sauce
> Version: 0.9.0+nmu3
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#790741: libapache-poi-java: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: libapache-poi-java
> Version: 3.10.1-2
> Tags: patch

There hasn't seem to be any update on this bug in 409 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#778419: fedmsg: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: fedmsg
> Version: 0.9.3-2
> Tags: patch

There hasn't seem to be any update on this bug in 546 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#797539: cadabra: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: cadabra
> Version: 1.29-1
> Tags: patch

There hasn't seem to be any update on this bug in 348 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#797254: splint: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: splint
> Version: 3.1.2.dfsg1-2
> Tags: patch

There hasn't seem to be any update on this bug in 351 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777413: mailto: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: mailto
> Version: 1.3.2-3
> Tags: patch

There hasn't seem to be any update on this bug in 552 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777360: wily: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: wily
> Version: 0.13.41-7.2
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777355: xjig: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: xjig
> Version: 2.4-13
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777444: perlpanel: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: perlpanel
> Version: 1:0.9.1+cvs20051225-2ubuntu1
> Tags: patch

There hasn't seem to be any update on this bug in 552 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777361: witalian: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: witalian
> Version: 1.7.5
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777407: makepp: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: makepp
> Version: 2.0.98.5-1
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777182: kerberos-configs: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: kerberos-configs
> Version: 2.3
> Tags: patch

There hasn't seem to be any update on this bug in 555 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777284: aspell-ar-large: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: aspell-ar-large
> Version: 1.2-0-3
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777021: netqmail: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: netqmail
> Version: 1.06-5
> Tags: patch

There hasn't seem to be any update on this bug in 557 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#834278: ITP: zuki-themes -- Zuki themes for GNOME, Xfce, and more

[James Lu]

Package: wnpp
Severity: wishlist
Owner: James Lu 

* Package name: zuki-themes
  Version : 3.20+git20160813~c8bc920-1
  Upstream Author : lassekongo83
* URL : https://github.com/lassekongo83/zuki-themes
* License : GPL-3
  Description : Zuki themes for GNOME, Xfce, and more

The Zuki themes (Zukitwo, Zukitre) are set of GTK+ themes for GNOME,
Xfce, and other desktops.


The package version is based off a Git snapshot right now because there
are no official versions yet.

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#776956: diploma: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: diploma
> Version: 1.2.11
> Tags: patch

There hasn't seem to be any update on this bug in 557 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#777375: dput: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: dput
> Version: 0.9.6.4ubuntu3
> Tags: patch

There hasn't seem to be any update on this bug in 553 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#776433: dict-devil: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: dict-devil
> Version: 1.0-11
> Tags: patch

There hasn't seem to be any update on this bug in 564 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#776376: dict-gazetteer2k: please make the build reproducible

[Chris Lamb]

Dear Maintainer,

> Source: dict-gazetteer2k
> Version: 1.0.0-5.2
> Tags: patch

There hasn't seem to be any update on this bug in 564 days, in which
time the Reproducible Builds effort has come on a long way. :)

Would you consider applying this patch and uploading?


Regards,

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

Bug#834268: RFS: open-invaders/0.3-5 [NMU] [ITA]

[Adam Borowski]

On Sat, Aug 13, 2016 at 11:33:05PM +0200, Hanno 'Rince' Wagner wrote:
> I am looking for a sponsor for my package "open-invaders"
>   
>* Package name: open-invaders
>  Version : 0.3-5
> 
>  dget -x  
> https://mentors.debian.net/debian/pool/main/o/open-invaders/open-invaders_0.3-5.dsc

> Changes since the last upload:Fixed Type-Incompatibility g++-old and
> g++-new, taking over Maintainership after the package has been orphaned.

This is an ITA rather than a NMU.  Also, as 0.3-4.2 didn't happen, please
merge the two changelog entries, preferably to:
,--
open-invaders (0.3-5) unstable; urgency=low

  * New maintainer (Closes: #826461)
  * clean declaration and casts (Closes: #811654)

 -- Hanno 'Rince' Wagner   Sat, 13 Aug 2016 18:12:33 +0100
`


Alas, there's one "small" detail:

[~]$ open-invaders 
/usr/share
Allegro initialised...
Loading graphics...
Fatal error: Could not load file ship.pcx
Fatal error: Could not load file invader_top.pcx
Aborted (core dumped)

... and it leaves me with a bad screen resolution.


-- 
An imaginary friend squared is a real enemy.

Bug#834277: pybit: please make the build reproducible

[Chris Lamb]

Source: pybit
Version: 1.0.0-2.1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that pybit could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/rules  2016-08-14 01:39:42.990995356 +0100
--- b/debian/rules  2016-08-14 01:44:05.441148811 +0100
@@ -92,6 +92,7 @@
dh_compress
dh_python2
dh_link
+   dh_fixperms
dh_installdeb
dh_gencontrol
dh_md5sums

Bug#834276: tf5: please make the build reproducible

[Chris Lamb]

Source: tf5
Version: 5.0beta8-5
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0], I noticed
that tf5 could not be built reproducibly.

Patch attached.

 [0] https://reproducible-builds.org/


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/reproducible-build 1970-01-01 01:00:00.0 +0100
--- b/debian/patches/reproducible-build 2016-08-14 01:41:59.936125384 +0100
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-14
+
+--- tf5-5.0beta8.orig/src/tfdefs.h.in
 tf5-5.0beta8/src/tfdefs.h.in
+@@ -7,7 +7,7 @@
+  /
+ /* $Id: tfdefs.h.in,v 35004.8 2007/01/13 23:12:39 kkeys Exp $ */
+ 
+-#define UNAME "@UNAME@"
++#define UNAME "generic"
+ #define stringify_token(s) #s
+ #define stringify_value(s) stringify_token(s)
+ #define DEFAULT_TFLIBD stringify_value(DATADIR) "/@LIBNAME@"
--- a/debian/patches/series 2016-08-14 01:38:33.246414208 +0100
--- b/debian/patches/series 2016-08-14 01:41:58.860116560 +0100
@@ -1 +1,2 @@
 debian-changes
+reproducible-build

Bug#796414: ITP: vertex-theme -- Vertex themes for GTK 2/3

[James Lu]

Hi,

Is there any update on this package?

Best,
James



signature.asc
Description: OpenPGP digital signature

Bug#834275: cinder: FTBFS:

[Chris Lamb]

Source: cinder
Version: 2:8.0.0-4
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,

cinder fails to build from source in unstable/amd64:

  [..]

  copying cinder/backup/manager.py -> build/lib.linux-x86_64-2.7/cinder/backup
  copying cinder/backup/chunkeddriver.py -> 
build/lib.linux-x86_64-2.7/cinder/backup
  copying cinder/backup/driver.py -> build/lib.linux-x86_64-2.7/cinder/backup
  copying cinder/tests/unit/backup/__init__.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/fake_swift_client.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/fake_swift_client2.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/fake_service.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/test_rpcapi.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/fake_google_client2.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/fake_service_with_verify.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  copying cinder/tests/unit/backup/fake_google_client.py -> 
build/lib.linux-x86_64-2.7/cinder/tests/unit/backup
  creating build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/qos_specs_manage.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_type_encryption.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/admin_actions.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/__init__.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_tenant_attribute.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/consistencygroups.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/types_manage.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/extended_snapshot_attributes.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_encryption_metadata.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_type_access.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/snapshot_actions.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_mig_status_attribute.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/image_create.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/availability_zones.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/services.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/backups.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_manage.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/cgsnapshots.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/quota_classes.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/hosts.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/capabilities.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_unmanage.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_host_attribute.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/snapshot_unmanage.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/used_limits.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_transfer.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_actions.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/scheduler_hints.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/quotas.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/snapshot_manage.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/extended_services.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/types_extra_specs.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/scheduler_stats.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  copying cinder/api/contrib/volume_image_metadata.py -> 
build/lib.linux-x86_64-2.7/cinder/api/contrib
  creating build/lib.linux-x86_64-2.7/cinder/volume/drivers/nexenta/ns5
  copying cinder/volume/drivers/nexenta/ns5/__init__.py -> 
build/lib.linux-x86_64-2.7/cinder/v

Bug#834274: mrpt: FTBFS in testing

[Santiago Vila]

Package: src:mrpt
Version: 1.4.0-5
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:

--
[ 29%] Building CXX object 
libs/opengl/CMakeFiles/mrpt-opengl.dir/src/CEllipsoidInverseDepth2D.cpp.o
cd /build/mrpt-1.4.0/obj-x86_64-linux-gnu/libs/opengl && /usr/bin/c++   
-DMRPT_ASSIMP_VERSION_MAJOR=3 -DWXUSINGDLL -D_FILE_OFFSET_BITS=64 -D__WXGTK__ 
-Dmrpt_opengl_EXPORTS -I/usr/include/eigen3 -I/usr/include/eigen3/unsupported 
-I/usr/include/libftdi1 -I/usr/include/opencv -I/usr/include/x86_64-linux-gnu 
-I/usr/include/x86_64-linux-gnu/ffmpeg 
-I/usr/include/x86_64-linux-gnu/libavcodec 
-I/usr/include/x86_64-linux-gnu/libavformat 
-I/usr/include/x86_64-linux-gnu/libswscale -isystem 
/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -isystem 
/usr/include/wx-3.0 -I/build/mrpt-1.4.0/. 
-I/build/mrpt-1.4.0/obj-x86_64-linux-gnu/include/mrpt-config/unix 
-I/build/mrpt-1.4.0/libs/opengl/src -I/build/mrpt-1.4.0/libs/opengl/src/glext 
-I/usr/include/assimp -I/build/mrpt-1.4.0/libs/opengl/include 
-I/build/mrpt-1.4.0/libs/base/include  -isystem /usr/include/wx-3.0 -I 
/usr/include/wx-3.0 -isystem 
/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-3.0 -I 
/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unic
 ode-3.0 -isystem /usr/include/eigen3 -g -O2 
-fdebug-prefix-map=/build/mrpt-1.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2  -pthread -Wreturn-type 
-Wextra -Wno-unused-parameter  -Wall -Wno-long-long -Wno-variadic-macros 
-Wno-write-strings -std=c++11 -pthread  -msse2 -funroll-loops -mfpmath=sse  -g 
-O2 -fdebug-prefix-map=/build/mrpt-1.4.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -fPIC   -I/usr/include/assimp -o 
CMakeFiles/mrpt-opengl.dir/src/CEllipsoidInverseDepth2D.cpp.o -c 
/build/mrpt-1.4.0/libs/opengl/src/CEllipsoidInverseDepth2D.cpp
tests/CMakeFiles/test_mrpt_base.dir/build.make:353: recipe for target 
'tests/CMakeFiles/test_mrpt_base.dir/__/libs/base/src/math/matrix_ops4_unittest.cpp.o'
 failed
make[4]: *** 
[tests/CMakeFiles/test_mrpt_base.dir/__/libs/base/src/math/matrix_ops4_unittest.cpp.o]
 Error 1
--

There are full logs available here:

https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/mrpt.html

Thanks.

Bug#834273: kmailtransport: FTBFS in testing

[Santiago Vila]

Package: src:kmailtransport
Version: 16.04.2-2
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:

--
cd /build/kmailtransport-16.04.2/obj-x86_64-linux-gnu/src && /usr/bin/c++   
-DKCOREADDONS_LIB -DKF5MailTransport_EXPORTS -DQT_CORE_LIB -DQT_DBUS_LIB 
-DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_GUI_LIB -DQT_NETWORK_LIB 
-DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_DEBUG -DQT_NO_URL_CAST_FROM_STRING 
-DQT_USE_FAST_OPERATOR_PLUS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB 
-DQT_XML_LIB -DTRANSLATION_DOMAIN=\"libmailtransport5\" -D_GNU_SOURCE 
-D_LARGEFILE64_SOURCE -I/build/kmailtransport-16.04.2/obj-x86_64-linux-gnu/src 
-I/build/kmailtransport-16.04.2/src -isystem /usr/include/KF5/KWallet -isystem 
/usr/include/KF5 -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtCore -isystem 
/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -isystem 
/usr/include/KF5/AkonadiCore -isystem /usr/include/KF5/KCoreAddons -isystem 
/usr/include/KF5/KItemModels -isystem /usr/include/KF5/KMime -isystem 
/usr/include/KF5/Akonadi/KMime -isystem /usr
 /include/KF5/akonadi/kmime -isystem /usr/include/KF5/KI18n -isystem 
/usr/include/KF5/KIOCore -isystem /usr/include/KF5/KService -isystem 
/usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KConfigGui -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtXml -isystem 
/usr/include/KF5/KWidgetsAddons -isystem 
/usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem 
/usr/include/KF5/KConfigWidgets -isystem /usr/include/KF5/KCodecs -isystem 
/usr/include/KF5/KAuth -isystem /usr/include/x86_64-linux-gnu/qt5/QtDBus 
-isystem /usr/include/x86_64-linux-gnu/qt5/QtNetwork -isystem 
/usr/include/KF5/KCompletion  -g -O2 
-fdebug-prefix-map=/build/kmailtransport-16.04.2=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time 
-D_FORTIFY_SOURCE=2  -std=c++0x -fno-exceptions -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -pedantic -fPIC 
-fvisibility=hid
 den -fvisibility-inlines-hidden   -DQT_NO_CAST_FROM_ASCII 
-DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -fPIC 
-fexceptions -o CMakeFiles/KF5MailTransport.dir/resourcesendjob.cpp.o -c 
/build/kmailtransport-16.04.2/src/resourcesendjob.cpp
In file included from /usr/include/KF5/AkonadiCore/exception.h:28:0,
 from /usr/include/KF5/AkonadiCore/item.h:26,
 from /build/kmailtransport-16.04.2/src/filteractionjob_p.h:25,
 from /build/kmailtransport-16.04.2/src/outboxactions_p.h:24,
 from /build/kmailtransport-16.04.2/src/outboxactions.cpp:20:
/usr/include/KF5/AkonadiCore/std_exception.h:1:40: fatal error: 
/usr/include/c++/5/exception: No such file or directory
 #include "/usr/include/c++/5/exception"
^
compilation terminated.
--

There are full logs available here:

https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/kmailtransport.html

Thanks.

Bug#834272: glib2.0: FTBFS in testing

[Santiago Vila]

Package: src:glib2.0
Version: 2.48.1-2
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:

--
ERROR: regex


**
ERROR:/build/glib2.0-2.48.1/./glib/tests/regex.c:82:test_new: assertion failed 
(g_regex_get_compile_flags (regex) == data->real_compile_opts): (0x == 
0x0001)
Aborted
# random seed: R02S3a16f16e7544d343b415274317394026
1..572
# Start of regex tests
ok 1 /regex/properties
PASS: regex 1 /regex/properties
ok 2 /regex/class
PASS: regex 2 /regex/class
ok 3 /regex/lookahead
PASS: regex 3 /regex/lookahead
ok 4 /regex/lookbehind
PASS: regex 4 /regex/lookbehind
ok 5 /regex/subpattern
PASS: regex 5 /regex/subpattern
ok 6 /regex/condition
PASS: regex 6 /regex/condition
ok 7 /regex/recursion
PASS: regex 7 /regex/recursion
# Bug Reference: http://bugzilla.gnome.org/640489
ok 8 /regex/multiline
PASS: regex 8 /regex/multiline
ok 9 /regex/explicit-crlf
PASS: regex 9 /regex/explicit-crlf
ok 10 /regex/max-lookbehind
PASS: regex 10 /regex/max-lookbehind
# Start of new tests
ok 11 /regex/new/1
PASS: regex 11 /regex/new/1
ok 12 /regex/new/2
PASS: regex 12 /regex/new/2
ok 13 /regex/new/3
PASS: regex 13 /regex/new/3
ok 14 /regex/new/4
PASS: regex 14 /regex/new/4
ok 15 /regex/new/5
PASS: regex 15 /regex/new/5
ok 16 /regex/new/6
PASS: regex 16 /regex/new/6
ok 17 /regex/new/7
PASS: regex 17 /regex/new/7
ok 18 /regex/new/8
PASS: regex 18 /regex/new/8
ok 19 /regex/new/9
PASS: regex 19 /regex/new/9
ok 20 /regex/new/10
PASS: regex 20 /regex/new/10
ok 21 /regex/new/11
PASS: regex 21 /regex/new/11
ok 22 /regex/new/12
PASS: regex 22 /regex/new/12
ok 23 /regex/new/13
PASS: regex 23 /regex/new/13
# End of new tests
# Start of new-check-flags tests
ok 24 /regex/new-check-flags/14
PASS: regex 24 /regex/new-check-flags/14
ok 25 /regex/new-check-flags/15
PASS: regex 25 /regex/new-check-flags/15
# ERROR:/build/glib2.0-2.48.1/./glib/tests/regex.c:82:test_new: assertion 
failed (g_regex_get_compile_flags (regex) == data->real_compile_opts): 
(0x == 0x0001)
ERROR: regex - too few tests run (expected 572, got 25)
ERROR: regex - exited with status 134 (terminated by signal 6?)
--

There are full logs available here:

https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/glib2.0.html

Thanks.

Bug#834271: notmuch: FTBFS in testing

[Santiago Vila]

Package: src:notmuch
Version: 0.22.1-2
Severity: serious

Dear maintainer:

This package currently fails to build from source in stretch:

--
INFO: using 2 minute timeout for tests

T060-count: Testing "notmuch count" for messages and threads
 FAIL   error message from query_search_messages
--- T060-count.14.EXPECTED  2016-08-12 08:19:04.119417429 +
+++ T060-count.14.OUTPUT.clean  2016-08-12 08:19:04.123417376 +
@@ -1,3 +1,4 @@
+107notmuch-count.c: No such file or directory.
 notmuch count: A Xapian exception occurred
 A Xapian exception occurred performing query
 Query string was: *
Added 2 new messages to the database.
 missing prerequisites: database-v1.tar.xz - fetch with 'make 
download-test-databases'
 SKIP   all tests in T530-upgrade
 BROKEN No ghosts should remain after deletion of second message
--- T590-thread-breakage.22.expected2016-08-12 08:19:44.110890846 
+
+++ T590-thread-breakage.22.output  2016-08-12 08:19:44.110890846 
+
@@ -1 +1 @@
-0
+1

Notmuch test suite complete.
776/778 tests passed.
1 broken test failed as expected.
1 test failed.
test/Makefile.local:64: recipe for target 'test' failed
make[1]: *** [test] Error 1
make[1]: Leaving directory '/<>'
dh_auto_test: make -j1 test VERBOSE=1 returned exit code 2
--

Full build logs are available here:

https://tests.reproducible-builds.org/debian/rb-pkg/testing/amd64/notmuch.html

Thanks.

Bug#834035: kdb5_util hangs forever

[Sam Hartman]

For debian, is there any reason not to build krb5 with
_LARGEFILE_SOURCE?

Bug#834230: libgtk-3-0: FTBFS on current sid

[Norbert Preining]

On Sat, 13 Aug 2016, Norbert Preining wrote:
> I tried to rebuild gtk3 on my system because I want to do some
> debugging of nemo bugs, but gtk3 FTBFS:

Here is the error:

(/home/norbert/Debian/gtk/gtk+3.0-3.20.7/debian/build/shared/testsuite/gtk/.libs/lt-notify:22795):
 Gtk-CRITICAL **: file 
/home/norbert/Debian/gtk/gtk+3.0-3.20.7/./gtk/gtkcssenumvalue.c: line 467 
(_gtk_css_font_weight_value_new): should not be reached
FAIL


Norbert

--
PREINING Norbert + TeX Live & Debian Developer + http://www.preining.info
GPG: 0x860CDC13fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#831726: Opinion on bug 831726 Very confusing prompt regarding administrative database passwords

[Justin B Rye]

Paul Gevers wrote:
> Hi d-l10n-english,
> 
> I recently got the bug report against my package dbconfig-common (which
> you reviewed multiple times the last couple of years) below. What do you
> think, should we improve the template (as suggested)?
> 
> Paul
> PS: no need to reply to me directly, I read the bug.

(I'll Cc Iustin, though.  Revised version and patch attached.)
 
> On Mon, 18 Jul 2016 20:39:01 +0200 Iustin Pop  wrote:
>> I'm installing db-common for the first time, so I'm not familiar with
>> its configuration or even what is its purpose (installing as a
>> dependency).
>> 
>> During installation, I'm presented with a debconf prompt, which says:
>> 
(De-mangling the unicode ellipses:)
>> "By default [...] These passwords will be stored in debconf's
>> configuration database only for as long as they are needed.
>> 
>> This behavior can be disabled, in which case the passwords will remain
>> in the debconf database [...] though this is less secure and thus not the
>> default setting.".
>> 
>> Then the prompt follows: "Keep "administrative" database passwords?
>> Yes/No".
>> 
>> This is very confusing. The prompt talks about default setting vs.
>> non-default, but then follows with a 'yes/no'. Is yes the default? or
>> No?

It is true that it can take some effort to work out what the question
means.  Let's see: if the default is that the passwords will be kept
only briefly, and the question is whether they should be kept
(permanently) that means the default is a "no".

>> The prompt is also confusing as it asks about "keeping" the passwords,
>> but the initial explanation says that both options keep the password,
>> just for different amounts of time.

Actually the first paragraph already avoids the word "keep", perhaps
for this very reason, but the final prompt could certainly be clearer
about the fact that it means "permanently retained".
 
>> I would suggest asking "keep passwords in debconf (unsecure) yes/no" or
>> something similar.

Hang on, let me look at it without the ellipses.

# Template: dbconfig-common/remember-admin-pass

"Remember" might actually be a useful word.

# Type: boolean
# Default: false
# _Description: Keep "administrative" database passwords?

You know, I always forget that this synopsis turns up as the final
prompt line.  I'll come back to this.

# By default, you will be prompted for all administrator-level database
# passwords when you configure, upgrade, or remove applications with
# dbconfig-common. These passwords will be stored in debconf's configuration
# database only for as long as they are needed.

So by default I'll be prompted?  And it's asking me whether I want to
choose the nondefault option of *not* being prompted?  Oh, because if
it's remembered them I won't need to enter them again... but maybe it
would be clearer if it started with some context:
  
  When you configure, upgrade, or remove applications with dbconfig-common,
  administrator-level database passwords are needed. [...]

Now, if I was writing this in conversational English for native
speakers I'd expect the "only" in the next sentence to be differently
positioned:

   These passwords will only be stored in debconf's
  configuration database for as long as they are needed.

which gives clearer advance warning that it's focussing on a
*restriction* on the storage.  Unfortunately non-native-speakers often
find this placement of "only" illogical and confusing.

Wait, though; do we need to go into technical details about what
*isn't* being done?  Isn't that covered in the next paragraph where it
gives that option?  So we could simplify it down to:
  
  When you configure, upgrade, or remove applications with dbconfig-common,
  administrator-level database passwords are needed. By default, these
  passwords are not stored, so you will be prompted for them.

# .
# This behavior can be disabled, in which case the passwords will
# remain in the debconf database. This database is protected by Unix file
# permissions, though this is less secure and thus not the default
# setting.

The "behaviour" being the forgetting, not the storing; maybe that can
be avoided.  It's also a bit unclear to say that "this is [...] not
the default" when "this" seems at first glance to be talking about the
standard Unix permission system.  How about:

  Alternatively the passwords can be permanently remembered in the debconf
  database (which is protected by Unix file permissions), though this is 
  less secure and thus not the default setting.

# .
# If you would rather not be bothered for an administrative password
# every time you upgrade a database application with dbconfig-common,
# you should choose this option. Otherwise, you should refuse this
# option.

"If you're confident and/or lazy you should answer yes to accept the
nondefault option" (but we never quite say that because for a start
we don't know if the UI in use is the one that features a "Yes/No").

And then the prompt is
# _Description: Ke

Bug#834270: xorg: logging out of shell on vt2 crashes X on vt1

[Rob Browning]

Package: xorg
Version: 1:7.7+16
Severity: normal

With a machine running more or less current stretch the following steps
will crash X on VT1 every time:

  - log in to VT1
  - launch X via startx (.xsession launches a few things, and then xmonad)
  - Ctrl-Alt-F2
  - log in as another user on VT2
  - launch X via startx (.xsession launches xmonad)
  - quit xmonad, which quits the xsession
  - exit the VT2 shell

At that point, the X instance on VT1 will crash with something like this
in the log:

  [   248.046] (II) AIGLX: Suspending AIGLX clients for VT switch
  [   248.046] (II) AIGLX: Resuming AIGLX clients after VT switch
  [   248.047] (EE) modeset(0): failed to set mode: Permission denied
  [   248.047] (EE) 
  Fatal server error:
  [   248.047] (EE) EnterVT failed for screen 0
  [   248.047] (EE) 
  [   248.047] (EE) 
  Please consult the The X.Org Foundation support 
   at http://wiki.x.org
   for help. 
  [   248.047] (EE) Please also check the log file at 
"/home/rlb/.local/share/xorg/Xorg.0.log" for additional information.
  [   248.047] (EE) 
  [   248.047] (II) AIGLX: Suspending AIGLX clients for VT switch
  [   248.207] (EE) Server terminated with error (1). Closing log file.

I don't upgrade to current stretch regularly, but I suspect this may
have started happening sometime in stretch in the past month or two.

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

lrwxrwxrwx 1 root root 13 Sep 20  2009 /etc/X11/X -> /usr/bin/Xorg
-rwxr-xr-x 1 root root 274 Jul 19 22:00 /usr/bin/Xorg

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0126] (rev 09)

/etc/X11/xorg.conf does not exist.

/etc/X11/xorg.conf.d does not exist.

KMS configuration files:

/etc/modprobe.d/i915-kms.conf:
  options i915 modeset=1
/etc/modprobe.d/radeon-kms.conf:
  options radeon modeset=1

Kernel version (/proc/version):
---
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18)

DRM Information from dmesg:
---
[0.892683] Linux agpgart interface v0.103
[   33.792290] [drm] Initialized drm 1.1.0 20060810
[   34.211926] [drm] Memory usable by graphics device = 2048M
[   34.211989] [drm] Replacing VGA console driver
[   34.269778] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[   34.269786] [drm] Driver supports precise vblank timestamp query.
[   34.293012] [drm] Initialized i915 1.6.0 20160229 for :00:02.0 on minor 0
[   34.353634] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit 
banging on pin 2
[   34.651507] fbcon: inteldrmfb (fb0) is primary device
[   35.766465] i915 :00:02.0: fb0: inteldrmfb frame buffer device


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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=, 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 xorg depends on:
ii  gnome-terminal [x-terminal-emulator]  3.20.2-2
ii  konsole [x-terminal-emulator] 4:16.04.2-1
ii  libgl1-mesa-dri   11.2.2-1
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libglu1-mesa  9.0.0-2.1
ii  stterm [x-terminal-emulator]  0.6-1
ii  terminator [x-terminal-emulator]  0.98-1
ii  x11-apps  7.7+6
ii  x11-session-utils 7.7+2
ii  x11-utils 7.7+3
ii  x11-xkb-utils 7.7+3
ii  x11-xserver-utils 7.7+7
ii  xauth 1:1.0.9-1
ii  xfce4-terminal [x-terminal-emulator]  0.6.3-2
ii  xfonts-100dpi 1:1.0.4+nmu1
ii  xfonts-75dpi  1:1.0.4+nmu1
ii  xfonts-base   1:1.0.4+nmu1
ii  xfonts-scalable   1:1.0.3-1.1
ii  xfonts-utils  1:7.7+3
ii  xinit 1.3.4-3
ii  xkb-data  2.17-1
ii  xorg-docs-core1:1.7.1-1
ii  xserver-xorg  1:7.7+16
ii  xterm [x-terminal-emulator]   325-1

xorg recommends no packages.

Versions of packages xorg suggests:
ii  x11-xfs-utils  7.7+2
pn  xorg-docs  

Versions of packages xserver-xorg depends on:
ii  x11-xkb-utils  7.7+3
ii  xkb-data   2.17-1
ii  xserver-xorg-core  

Bug#834239: blends-tasks: Add FreedomBox to debian-blends-tasks

[James Valleroy]

On Sat, 13 Aug 2016 19:26:51 +0200 Jonas Smedegaard  wrote:
> Quoting James Valleroy (2016-08-13 18:36:02)
> > The attached patch will add FreedomBox to the blends tasks list, shown
> > in Debian installer.
> >
> > Note one issue: Selecting this item will install freedombox-setup
> > package, but that is not quite sufficient to get a working FreedomBox.
> > The user will need to run /usr/lib/freedombox/setup and reboot, to
> > complete the setup process.
>
> What does that mean? What works and does not work without running it?


What works: The dependencies for freedombox-setup are all installed and
running, with their default configurations. This includes apache2,
avahi-daemon, firewalld, network-manager, ntp, and others.


What doesn't work:
- Plinth is not accessible through apache, because its apache conf is
not enabled yet.
- firewalld with default config will block incoming HTTP, HTTPS, XMPP,
etc., because zones and services have not been configured yet.

These start working after /usr/lib/freedombox/setup is run.


> > We are working to resolve this issue. But, I'm hoping that it is not
> > so bad that it would prevent FreedomBox from being added to the list.
>
> Is that tracked in a bugreport where interested parties can follow
> progress?


I just reported bug #834260 to track the progress.

--
James



signature.asc
Description: OpenPGP digital signature

Bug#833656: cme fails with dpkg error

[gregor herrmann]

On Sat, 13 Aug 2016 15:45:36 +0200, David Kalnischkies wrote:

Thanks for looking into this issue!

> The problem for cme while caused by the same change in apt, is caused in
> a completely different way through. 

Ack, I realized this later ...

> /var/lib/apt/var/lib/dpkg/status
> suggests that apts "configuration" wasn't initialized before "system"
> is, so that Dir, Dir::State and Dir::State::Status are empty. 

Interestingly not, I checked the variables.

And the next interesting thing is that 
/usr/share/perl5/Config/Model/Dpkg/Dependency.pm
does the same as 
/usr/share/doc/libapt-pkg-perl/examples/apt-cache
the latter works, the former has an undefined $apt_cache variable.

/usr/share/perl5/Config/Model/Dpkg/Dependency.pm :

use AptPkg::Config '$_config';
use AptPkg::System '$_system';
use AptPkg::Version;
use AptPkg::Cache ;

$_config->init;
$_system = $_config->system;
my $vs = $_system->versioning;
my $apt_cache = AptPkg::Cache->new ;


/usr/share/doc/libapt-pkg-perl/examples/apt-cache :

use AptPkg::Config '$_config';
use AptPkg::System '$_system';
use AptPkg::Cache;

$_config->init;
$_system = $_config->system;
$_config->{quiet} = 2;
my $cache = AptPkg::Cache->new;


> So Dir has
> no default value in this codepath (it should have /), which results in
> Dir::State::Status being set to var/lib/dpkg/status and later then this
> setting is read it will be noticed that the setting isn't absolute, so
> Dir and Dir::State are considered which are by now set and hence result
> in a /var/lib/apt to be prefixed…

Hm, maybe Dir is empty, I only checked Dir::State::Status which was
indeed var/lib/dpkg/status.

Let's look again:

 'Dir' => '/',
 'Dir::State' => 'var/lib/apt/',
 'Dir::State::status' => 'var/lib/dpkg/status',

(Same for /usr/share/doc/libapt-pkg-perl/examples/apt-cache.)

So this is still a miracle to me why $apt_cache in
Config::Model::Dpkg::Dependency is undefined but $cache in the
libapt-pkg-perl example script works.
 
> I am going to fix this in apt so that this problem will be hidden again,

Thanks!

> but I would suggest looking into initializing apt in the right order or
> you will eventually will run again into issues with config options not
> having the option set they are supposed to have, which is why I leave
> this bug here – unsure if its a cme or libapt-pkg-perl problem, I am
> just not enough of a perler to know…

Me neither, it seems :/

(cc'ing the 2 authors, maybe they find the issue quicker in their code.)


Cheers,
gregor

-- 
 .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Various Artists: Theme From Harry's Game


signature.asc
Description: Digital Signature

Bug#834269: RM: python-bcrypt python3-bcrypt [hurd-i386 kfreebsd-amd64 kfreebsd-i386] -- ROM; ports not supported anymore

[Daniel Stender]

Package: ftp.debian.org
Severity: normal
Control: block 834062 by -1

python-bcrypt >= 3.0.0 uses another C backend (OpenBSD instead of openwall), 
which doesn't support the
non-Linux ports.

Please remove the outdated cruft packages.

Thanks,
Daniel Stender

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



signature.asc
Description: OpenPGP digital signature

Bug#820261: package

[Christof Schulze]

Sorry for this being my third email today - still I would like to share 
my experimental packages so other will not have to go through the hassle 
of setting up a build environment to get the git plugin working.

See the attached torrent file.

Christof
--
()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments



kicad-with-github-plugin.torrent
Description: application/bittorrent

Bug#834259: findbugs: Old BCEL version

[Emmanuel Bourg]

On 08/13/2016 11:23 PM, Christopher Hoskin wrote:

> Should there not be a 6.x generic version then?

If we were to change the generic version it should be for something like
'debian', so it won't change again when BCEL 7.0 is released.

But that's just a cosmetic detail, we can keep using 5.x for now.

Bug#834098: libc6: name resolution fails for keys.gnupg.net on some machines / networks

[Vincent Lefevre]

On 2016-08-13 16:46:46 +0200, Aurelien Jarno wrote:
> On 2016-08-13 04:23, Vincent Lefevre wrote:
> > I was not suggesting not to return all addresses. But in case of error
> > (which could just be a temporary network error, not necessarily due to
> > a bug in the nameserver, e.g. due to network congestion), if some of
> > the IP addresses are known, they could be made available to the calling
> > application in case they could be useful (e.g. for a connection). If
> > the application wants all the addresses, it can check error conditions
> > as usual.
> 
> The glibc provides getaddrinfo() which is a POSIX interface, also
> described in RFC2553. You can't change it just because you think it's
> better. Alternatively some other resolver libraries might provide the
> behaviour you need. Anyway in both cases it requires some changes on the
> application side too, which is clearly out of scope of this bug report.

It seems that POSIX doesn't specify the answer in the struct addrinfo
in case of error. But anyway, I was thinking more of an alternative
function, which could be more efficient when the goal is to do a
connection, since the applications need to be modified. Since many
applications could benefit from this, having such a function in the
GNU libc may be better than another resolver library.

Now, in the present case of keys.gnupg.net, this may be unnecessary
(see below about the 11/9/5 and the truncation bit).

> Also note that in your case the getaddrinfo() function returns an
> EAI_AGAIN error aka "Temporary failure in name resolution". The
> application (in your case gnupg) can try to handle the failure or at
> least display a better error message than "Host not found" which is
> clearly misleading in that case.

Indeed. Now, with the new gnupg 2.x that has just replaced the old
one in Debian/unstable, resolving seems to be done differently and
I no longer get an error (I've checked that "ping" still fails to
be sure that this wasn't due to something else). So, there's no bug
to report to gnupg. :)

> > And I would say that it could be the opposite. Imagine a host with
> > hundreds of millions of IP addresses...
> 
> I am sure there is a limit somewhere in one of the RFC.

I haven't found a limit (though I didn't check everything).

According to

  
http://serverfault.com/questions/652237/whats-the-maximum-number-of-ips-a-dns-a-record-can-have

there isn't a limit, but this doesn't seem to be based on RFC's,
more on testing. With the example, 1000 records are obtained per
TCP query; other records are obtained with additional TCP queries,
but only one more at a time (rotation by 1). Well, this is rather
ugly with this client.

> Anyway if such a DNS entry exists, I don't think returning a failure
> is really a problem.

And this is what the nameserver of our router is doing! Its chosen
limit can appear to be low, but in absence of specification, how
to choose a practical limit? It seems to be rare to have more than
4 A or  records. Even www.google.org has only one. BTW, I'd be
interested in some statistics.

> > > The point is that the local resolver is supposed to be working
> > > correctly.
> > 
> > and the network quality is good, which is not always the case.
> > 
> > > If it doesn't, one can easily setup a local recursive name server
> > > like unbound.
> > 
> > Unfortunately, this is not a general solution due to buggy ISP's.
> > 
> > > > 11:55:59.097743 IP 192.168.0.6.41008 > 192.168.0.1.domain: 60367+ A? 
> > > > keys.gnupg.net. (32)
> > > > 11:55:59.097796 IP 192.168.0.6.41008 > 192.168.0.1.domain: 31606+ ? 
> > > > keys.gnupg.net. (32)
> > > > 11:55:59.098339 IP 192.168.0.6.38010 > 192.168.0.1.domain: 4217+ PTR? 
> > > > 1.0.168.192.in-addr.arpa. (42)
> > > > 11:55:59.143100 IP 192.168.0.1.domain > 192.168.0.6.38010: 4217 
> > > > NXDomain* 0/1/0 (94)
> > > > 11:55:59.143325 IP 192.168.0.6.43592 > 192.168.0.1.domain: 23396+ PTR? 
> > > > 6.0.168.192.in-addr.arpa. (42)
> > > > 11:55:59.161082 IP 192.168.0.1.domain > 192.168.0.6.41008: 60367 11/9/5 
> > > > CNAME pool.sks-keyservers.net., A 198.128.3.63, A 93.94.119.246, A 
> > > > 78.46.223.54, A 131.175.15.4, A 151.252.40.184, A 5.9.50.141, A 
> > > > 209.135.211.141, A 5.135.158.148, A 68.187.0.77, A 193.17.17.6 (502)
> > > 
> > > This tcpdump trace doesn't show the answer header, so we don't know if
> > > the truncation flag is set. That said the 11/9/5 says that the answer
> > > contains 11 answer records, 9 name server records and 5 additional
> > > records. This clearly doesn't fit. A normal DNS server would just return
> > > 11 answers, so 11/0/0.
> > > 
> > > That said I just realized that the strace entry in your previous email
> > > contains the beginning of the answer:
> > > 
> > > > 30419 recvfrom(4, 
> > > > "'J\203\200\0\1\0\v\0\10\0\0\4keys\5gnupg\3net\0\0\34\0\1"..., 2048, 0, 
> > > > {sa_family=AF_INET, sin_port=htons(53), 
> > > > sin_addr=inet_addr("192.168.0.1")}, [16]) = 500
> > > 
> > > Converted into hexadecima

Bug#834267: debian-installer: d-i can't find firmware on the second usb stick (jessie)

[Łukasz Stelmach]

Package: debian-installer
Severity: normal

Dear Maintainer,

I have booted debian-installer from a USB stick with the hybrid ISO
image. I was requested to provide wifi firmware files. I have recorded
them on another stick and plugged it in. Unfortunately the installer
can't find them.

As far as I cen tell the problem is in the mountmedia script which
appears to mount the first device returned by its devlist function. In
my case it is the main partition on the d-i USB stick.

To work around this problem copied the firmware package into /firmware
of the running installer.

-- 
Było mi bardzo miło.  --- Rurku. --- ...
>Łukasz<--- To dobrze, że mnie słuchasz.

Bug#834264: postgresql-common: pg_* tools should set current workingdir

[Christoph Anton Mitterer]

Source: postgresql-common
Version: 165+deb8u1
Severity: normal


Hey.

Just close this if it's already fixed in more recent versions:
When doing e.g.
# pg_createcluster 9.4 test
Creating new cluster 9.4/test ...
  config /etc/postgresql/9.4/test
  data   /var/lib/postgresql/9.4/test
  locale en_DE.UTF-8
Flags of /var/lib/postgresql/9.4/test set as -e-C
could not change directory to "/root": Permission denied
  port   5433

>From within a directory not readable by postgresql, one get's the:
could not change directory to "/root": Permission denied


These tools should perhaps all "cd /" in some early place :)


Cheers,
Chris.


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

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

Bug#834266: dbconfig-pgsql: support specifying the socket dir and socket "port"

[Christoph Anton Mitterer]

Package: dbconfig-pgsql
Version: 2.0.4~bpo8+1
Severity: wishlist


Hi.

As of now it seems, on cannot configure the socket dir and "port" that is
used by dbconfig, when UNIX sockets are used with postgresql.

Instead it seems it would always use /var/run/postgresql/.s.PGSQL.5432.

But it's perfectly valid to have both, another dir and another "port"
number and this is even supported out of the box by the debian postgresql
packages, which allow to run multiple postgresql daemons per node, that
then simply use different directories (for settings, DB data, etc.)
and a different port (for TCP, and for the socket file name).

See the pg_* tools from postgresql-common package, as well as the options:
- port
- unix_socket_directories
in 
https://www.postgresql.org/docs/current/static/runtime-config-connection.html,
the later which specifies the socket file pathname to be always:
>In addition to the socket file itself, which is named .s.PGSQL. where
> is the server's port number, an ordinary file named .s.PGSQL..lock
>will be created in each of the unix_socket_directories directories.


Cheers,
Chris.

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

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

Bug#834263: dbconfig-pgsql: "ident" auth method with UNIX sockets

[Christoph Anton Mitterer]

Package: dbconfig-pgsql
Version: 2.0.4~bpo8+1
Severity: normal

Hey.

When having UNIX sockets in dbconfig-common, it still uses the term "ident" as
the auth mode.
This is a bit obsolete since many postgresql versions, as "peer" will be 
actually
done when "ident" is specified and UNIX sockets are used.
ident is in principle actually the ident daemon that could be used with TCP.
See https://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html.


It would be nice if dbconfig could use "peer" instead, in both places:
- what the user sees in the UI
- what's actually stored in the configs/etc.

But it should be noticed that "peer" as a actual name is only available
since postgresql 9.1 (though all older versions are upstream unsupported),
so when an older version is used "peer" is not understood by postgresql.
Anyway I don't think this is anyhow specified/used when dbconfig invokes
postgresql, or is it?

Cheers,
Chris.


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

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

Bug#834265: postgresql-common: pg_* tools should perhaps reload systemd config?

[Christoph Anton Mitterer]

Source: postgresql-common
Version: 165+deb8u1
Severity: wishlist

Hey.
The pg_* tools that add/remove clusters, and thus generated units like:
systemctl start postgresql@9.4-myCluster.service
should perhaps do something like:
systemctl daemon-reload

OTOH, this also means that any not-yet active confi changes will get
active, and perhaps the sysadmin may have deliberately not reloaded
systemd config yet.

So perhaps these tools should just print a info message like:
run "systemctl daemon-reload" in case you want the generated units
to be used.

Cheers,
Chris.


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

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

Bug#834262: RFS: pdfrw/0.2-3 [QA] -- PDF file manipulation library

[Sean Whitton]

Package: sponsorship-requests
Severity: normal
Control: block 814289 by -1

Dear mentors,

I am looking for a sponsor for a QA upload of pdfrw.

* Package name: pdfrw
  Version : 0.2-3
  Upstream Author : Patrick Maupin 
* License : Expat & BSD-3-clause
  Section : python

Changes since the last upload:

  * QA upload.
  * Drop "Conflicts:/Provides:/Replaces: pdfrw" lines (Closes: #814289).
The pdfrw binary package is long gone and was never part of a release.
This fixes co-installing python-pdfrw and python3-pdfrw, and other
package combinations.
Thanks to Aaron M. Ucko and Yuri D'Elia for useful information.
  * d/copyright improvements:
- Add proper DEP-5 header
- Correct licence name MIT -> Expat
- Factor out Expat license text into its own paragraph
- Update copyright years for Patrick Maupin
- Add missing copyrights of Attila Tajti, Narijus Mika & Mathieu Fenniak
  See LICENSE.txt in upstream source.
  * Fix Vcs-* URIs.
They were previously pointing at the dgit repo for src:botch.
  * Declare compliance with Policy 3.9.8 (no changes required).
  * Drop duplicate build-dependency on python-setuptools.
  * Run wrap-and-sort -abst

Since this package already has history on the dgit git server, I would
like to request that the package be sponsored using dgit (non-DDs cannot
push the history there).  To do that:

dgit clone pdfrw
cd pdfrw
git remote add -f spwhitton https://git.spwhitton.name/pdfrw
git merge --ff-only spwhitton/master
git log -1
# ^ confirm that commit hash is d715f1ef184907956865d94be4f14648bb279342

# now perform all your pre-upload tests, builds etc., and then:
dgit build-source
dgit push

If you have any problems with this, I can help -- I use dgit for DM uploads.

If you don't like dgit, I've uploaded a source package to mentors:

dget -x http://mentors.debian.net/debian/pool/main/p/pdfrw/pdfrw_0.2-3.dsc

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#713004: retitle 713004 to O: ndisc6 -- IPv6 diagnostic tools / retitle 777699 to O: psutils -- PostScript document handling utilities

[Axel Beckert]

retitle 713004 RFA: ndisc6 -- IPv6 diagnostic tools
retitle 777699 RFA: psutils -- PostScript document handling utilities
kthxbye

Dear Bart,

Bart Martens wrote in two separate mails:
> retitle 713004 O: ndisc6 -- IPv6 diagnostic tools
> retitle 777699 O: psutils -- PostScript document handling utilities

These packages were never orphaned before someone decided to adopt
them. The maintainers only requested an adopter. So they should be
changed back to RFA and not to O.

Please be more careful in the future when you change RFAs to O. At
least I'd be pissed off if you would do that to one of my RFAs.

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

Bug#834261: jessie-pu: package intel-microcode/3.20160714.1~deb8u1

[Henrique de Moraes Holschuh]

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

I would like to update the intel-microcode packages in stable to address
several critical errata in newer Intel processors, as well as to
properly support the Linux kernel 4.4 and later.

The updated packages being proposed in this bug report are identical to
the ones in unstable/testing and jessie-backports, other than
debian/changelog and version numbering.

These changes have been tested in unstable since 2016-07-22 and in
testing and jessie-backports since 2016-07-28, without any issues being
reported.

This microcode update is very important to get Debian to run in a more
stable way on the newer processors that have TSX enabled, but as usual,
it also fixes other unspecified errata, so it is important even for
processors without TSX.


As usual, you will find attached the debdiff output with the changes in
the two microcode data files removed for brevity...

Diffstat below:
 Makefile   |3 
 changelog  |   23 
 debian/README.Debian   |  237 
 debian/changelog   |  140 
 debian/control |2 
 debian/initramfs.hook  |   22 
 microcode-20151106.dat |43449 ---
 microcode-20160714.dat |59389 +
 8 files changed, 59733 insertions(+), 43532 deletions(-)

(diffstat of the abridged debdiff, for better resolution):
 Makefile  |3 
 changelog |   23 
 debian/README.Debian  |  237 ++
 debian/changelog  |  140 +
 debian/control|2 
 debian/initramfs.hook |   22 +++-
 6 files changed, 344 insertions(+), 83 deletions(-)

Thank you!

-- 
  Henrique Holschuh
diff -Nru intel-microcode-3.20151106.1~deb8u1/changelog intel-microcode-3.20160714.1~deb8u1/changelog
--- intel-microcode-3.20151106.1~deb8u1/changelog	2015-12-28 11:54:52.0 -0200
+++ intel-microcode-3.20160714.1~deb8u1/changelog	2016-07-31 18:11:41.0 -0300
@@ -1,3 +1,26 @@
+2016-07-14:
+  * Updated Microcodes:
+sig 0x000306f4, pf mask 0x80, 2016-06-07, rev 0x000d, size 15360
+sig 0x000406e3, pf mask 0xc0, 2016-06-22, rev 0x009e, size 97280
+sig 0x000406f1, pf mask 0xef, 2016-06-06, rev 0xb1d, size 25600
+sig 0x000506e3, pf mask 0x36, 2016-06-22, rev 0x009e, size 97280
+
+2016-06-07:
+  * New Microcodes:
+sig 0x000406e3, pf mask 0xc0, 2016-04-06, rev 0x008a, size 96256
+sig 0x000406f1, pf mask 0xef, 2016-05-20, rev 0xb1c, size 25600
+sig 0x00050662, pf mask 0x10, 2015-12-12, rev 0x000f, size 28672
+sig 0x000506e3, pf mask 0x36, 2016-04-06, rev 0x008a, size 96256
+
+  * Updated Microcodes:
+sig 0x000306c3, pf mask 0x32, 2016-03-16, rev 0x0020, size 22528
+sig 0x000306d4, pf mask 0xc0, 2016-04-29, rev 0x0024, size 17408
+sig 0x000306f2, pf mask 0x6f, 2016-03-28, rev 0x0038, size 32768
+sig 0x000306f4, pf mask 0x80, 2016-02-11, rev 0x000a, size 15360
+sig 0x00040651, pf mask 0x72, 2016-04-01, rev 0x001f, size 20480
+sig 0x00040661, pf mask 0x32, 2016-04-01, rev 0x0016, size 24576
+sig 0x00040671, pf mask 0x22, 2016-04-29, rev 0x0016, size 11264
+
 2015-11-06:
   * New Microcodes:
 sig 0x000306f4, pf mask 0x80, 2015-07-17, rev 0x0009, size 14336
diff -Nru intel-microcode-3.20151106.1~deb8u1/debian/changelog intel-microcode-3.20160714.1~deb8u1/debian/changelog
--- intel-microcode-3.20151106.1~deb8u1/debian/changelog	2015-12-28 16:06:24.0 -0200
+++ intel-microcode-3.20160714.1~deb8u1/debian/changelog	2016-08-07 21:49:00.0 -0300
@@ -1,3 +1,141 @@
+intel-microcode (3.20160714.1~deb8u1) stable; urgency=medium
+
+  * Rebuild for Debian jessie stable update (no changes)
+  * STABLE RELEASE MANAGER INFORMATION:
++ This is the same package which is in unstable since 2016-07-22,
+  and stretch (testing) and jessie-backports since 2016-07-28,
+  with no issues reported
++ Contains updated microcode for:
+  Skylake/H/DT, Broadwell/E/EP/H/DE/WS, Haswell/E/WS/EP/EX, and their
+  usual variants (U/ULT,Y,S...): mobile, desktop, embedded, single-
+  and dual-socket server/workstation.  Also includes related Pentium
+  and Celeron
++ Somewhat unusually, this release includes an update for the
+  multi-socket Haswell-EX E7-v3 Xeon server processors
++ Fixes critical issues on Intel Skylake processors, such as:
+  - TSX unpredictable behavior
+  - AVX data/calculation corruption
+  - High-hitting crashes and hangs related to MCEs and power
+management errata that might make it impossible to even install
+Debian in the first place (systems with very outdated firmware)
++ Likely fixes a recently identified, critical but low-hitting TSX
+  erratum on Broadwell, Broadwell-E and related Xeons
+  (Broadwell-DE/WS/EP: Xeon-D 1500, E3-v4 and E5-v4)
++ Fix 

Bug#832415: Further information: upstream software works fine

[Rafael Laboissière]

Control: tags -1 + unreproducible moreinfo

* Rafael Laboissière  [2016-08-08 16:29]:

Could you please provide a script that triggers the bug, as I asked in 
a previous message?


I cannot reproduce the bug.  The simple example below works for me with 
the versions currently in unstable (octave 4.0.3-1 and octave-parallel 
3.1.0-1):


   octave:1> pkg load parallel
   octave:2> parcellfun (2, @(x) x^2, {1, 2})
   parcellfun: 2/2 jobs done

Does it work for you?

Rafael Laboissière

Bug#830888: icinga2-ido-pgsql: dbconfig configuration fails with unix sockets

[Christoph Anton Mitterer]

Hey.

See below... went actually much faster than I'd have expected.

I think it already shows the possible problem that happens:
>populating database via sql...  warning: ident method specified but local 
>account doesn't exist.
>warning: ident method specified but local account doesn't exist.

It thinks the account doesn't exist (which is correct, but doesn't
really matter) and I'd blindly assume now it falls back to TCP for this
reason?


One further thing I've just notied, there is no way to configure the
socket dir and "port", i.g.:
/var/run/postgresql/.s.PGSQL.5432
per default.
But this may be different and for postgresql there may be even multiple
daemons running all with their own "ports" e.g. .s.PGSQL.5433 ... this
is all perfectly supported out of the box by the debian packages with
the pg_* tools.

I'll open separate tickets for these in a minute.

Cheers,
Chris.

On Sat, 2016-08-13 at 22:56 +0200, Paul Gevers wrote:
> but having
> the output of dbc_debug=true will be extremely valuable and making my
> life in debugging a lot easier

# dpkg-reconfigure icinga2-ido-pgsql 
(prerm) dbc_go() icinga2-ido-pgsql upgrade 2.4.10-1~bpo8+1.
dbc_config() icinga2-ido-pgsql upgrade 2.4.10-1~bpo8+1.
dbc_set_dbtype_defaults() .
dbc_read_package_config() .
dbc_set_dbtype_defaults() pgsql.
(config) dbc_go() icinga2-ido-pgsql reconfigure 2.4.10-1~bpo8+1.
dbc_config() icinga2-ido-pgsql reconfigure 2.4.10-1~bpo8+1.
dbc_set_dbtype_defaults() .
dbc_register_debconf() .
dbc_read_package_config() .
dbc_preseed_package_debconf() .
dbc_forget_app_password() .
dbc_get_app_pass() .
(postinst) dbc_go() icinga2-ido-pgsql configure 2.4.10-1~bpo8+1.
dbc_config() icinga2-ido-pgsql configure 2.4.10-1~bpo8+1.
dbc_set_dbtype_defaults() .
dbc_read_package_debconf() .
dbc_set_dbtype_defaults() pgsql.
settings determined from dbc_read_package_debconf:.
dbc_install=true.
dbc_upgrade=true.
dbc_remove=true.
dbc_dbtype=pgsql.
dbc_dbuser=icinga.
dbc_dbpass=t3QJ3BzYp2om.
dbc_dballow=.
dbc_dbadmin=postgres.
dbc_dbadmpass=.
dbc_dbserver=localhost.
dbc_dbport=.
dbc_dbname=icinga.
dbc_authmethod_admin=ident.
dbc_authmethod_user=ident.
dbc_ssl=.
dbc_write_package_config() .
dbconfig-common: writing config to /etc/dbconfig-common/icinga2-ido-pgsql.conf
dbc_read_package_config() .
dbc_detect_installed_dbtype() pgsql.
_dbc_detect_installed_dbtype() pgsql.
su -s /bin/sh postgres -c "env HOME='/tmp/dbconfig-common.psql_home.0wG8JU' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.0wG8JU/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' template1" 2>&1.
creating postgres user icinga:  su -s /bin/sh postgres -c "env 
HOME='/tmp/dbconfig-common.psql_home.sCUNV3' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.sCUNV3/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' template1" 2>&1.
su -s /bin/sh postgres -c "env HOME='/tmp/dbconfig-common.psql_home.7D4bvy' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.7D4bvy/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' -U 'postgres' template1" 2>&1.
success.
verifying creation of user: su -s /bin/sh postgres -c "env 
HOME='/tmp/dbconfig-common.psql_home.xFZUCY' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.xFZUCY/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' template1" 2>&1.
success.
dbconfig-common: dumping pgsql database icinga to 
/var/tmp/icinga2-ido-pgsql.icinga.2016-08-13-23.09.pgsql.4IRwbV.
su -s /bin/sh postgres -c "env HOME='/tmp/dbconfig-common.psql_home.NU1oJg' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.NU1oJg/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' template1" 2>&1.
database does not exist.
dbconfig-common: dropping old pgsql database icinga.
su -s /bin/sh postgres -c "env HOME='/tmp/dbconfig-common.psql_home.UsQZjg' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.UsQZjg/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' template1" 2>&1.
dropping database icinga: database does not exist.
_dbc_detect_installed_dbtype() psql.
su -s /bin/sh postgres -c "env HOME='/tmp/dbconfig-common.psql_home.FOmBye' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.FOmBye/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' template1" 2>&1.
creating database icinga: su -s /bin/sh postgres -c "env 
HOME='/tmp/dbconfig-common.psql_home.Ln487E' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.Ln487E/.pgpass' PGSSLMODE='prefer' 
psql --set \"ON_ERROR_STOP=1\" -q -U 'postgres' -U 'postgres'" 2>&1.
success.
verifying database icinga exists: success.
populating database via sql...  warning: ident method specified but local 
account doesn't exist.
warning: ident method specified but local account doesn't exist.
su -s /bin/sh root -c "env HOME='/tmp/dbconfig-common.psql_home.RIlqrF' 
PGPASSFILE='/tmp/dbconfig-common.psql_home.RIlqrF/.pgpass' PG

Bug#834259: findbugs: Old BCEL version

[Christopher Hoskin]

Dear Emmanuel,

Should there not be a 6.x generic version then?

Christopher

Bug#834260: freedombox-setup: Run setup script automatically when installed

[James Valleroy]

Package: freedombox-setup

Currently, to set up FreedomBox, the user must install the
freedombox-setup package, and then run /usr/lib/freedombox/setup.

Instead, we should run /usr/lib/freedombox/setup from postinst, so that
simply installing this package will be sufficient to get a working
FreedomBox. This will also allow a nicer setup experience if FreedomBox
can be selected in Debian installer (see bug #834239).

However, there are a few things that need to be cleaned up first:

1. Add all the packages needed for "essential" Plinth modules, as
dependencies for freedombox-setup. This is mostly covered by #795755,
the only other one needed is letsencrypt. Will require plinth >= 0.10.0.

2. plinth --setup should detect if packages are already installed, and
skip running apt-get update/install in this case
(https://github.com/freedombox/Plinth/issues/553).

3. Need to avoid modifying /etc/ldapscripts/ldapscripts.conf, as it is a
conffile owned by ldapscripts package. Have ldapscripts re-use settings
from nslcd instead (https://github.com/freedombox/Plinth/issues/534).




signature.asc
Description: OpenPGP digital signature

Bug#834259: findbugs: Old BCEL version

[Emmanuel Bourg]

On 08/13/2016 11:06 PM, Christopher Hoskin wrote:

> Findbugs has switched to using BCEL 6.0, version 5 is no longer packaged
> in unstable, and is instead relocated to 6. Therefore the debian/maven.rules
> file should be updated accordingly.

Hi Christopher,

Actually the generic version for BCEL is still 5.x, if you switch to 6.0
the build will break the next time a newer version of BCEL is packaged.

Emmanuel Bourg

Bug#834259: findbugs: Old BCEL version

[Christopher Hoskin]

Package: findbugs
Version: 3.1.0~preview2-1
Severity: minor
Tags: patch

Dear Maintainer,

Findbugs has switched to using BCEL 6.0, version 5 is no longer packaged in 
unstable, and is instead relocated to 6. Therefore the debian/maven.rules file 
should be updated accordingly.

(This would help when using build systems like Gradle which do not fully 
support POM relocation to a different version.)

Thanks.

Christopher Hoskin



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

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

Versions of packages findbugs depends on:
ii  default-jre [java8-runtime]2:1.8-57
ii  java-wrappers  0.1.28
ii  libfindbugs-ant-java   3.1.0~preview2-1
ii  libfindbugs-java   3.1.0~preview2-1
ii  openjdk-8-jre [java8-runtime]  8u102-b14.1-2

findbugs recommends no packages.

findbugs suggests no packages.

-- no debconf information
diff --git a/debian/maven.rules b/debian/maven.rules
index 8f7a0b4..a75ca3e 100644
--- a/debian/maven.rules
+++ b/debian/maven.rules
@@ -1,3 +1,3 @@
 
-s/com.google.code.findbugs/org.apache.bcel/ s/bcel-findbugs/bcel/ * s/.*/5.x/ * *
+s/com.google.code.findbugs/org.apache.bcel/ s/bcel-findbugs/bcel/ * s/.*/6.0/ * *
 com.google.code.findbugs jsr305 * s/.*/0.x/ * *

Bug#834258: qla-tools: kernel incompatibility bug #739368 is back

[Pierre Bernhardt]

Package: qla-tools
Version: 20140529-1
Severity: important

Dear Maintainer,

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

root@host:~# ql-dynamic-tgt-lun-disc
Kernel 4.6.0-0.bpo.1-amd64 not yet supported.
root@host:~# ql-hba-snapshot
Only Kernel version 2.6 and above are supported
root@host:~#

It looks like it's the same issue which was allready described in #739368
which had to been fixed.

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


-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages qla-tools depends on:
ii  sg3-utils  1.39-1

qla-tools recommends no packages.

qla-tools suggests no packages.

-- no debconf information

Bug#830888: icinga2-ido-pgsql: dbconfig configuration fails with unix sockets

[Paul Gevers]

Hi Christoph,

I am going to bed, now, so a short answer.

On 13-08-16 22:45, Christoph Anton Mitterer wrote:
> Was the information above already enough for you?
> If not I can stop the services, make some temp DB for a test and run it
> with dbc_debug=true

I will try to reproduce with the information you provided, but having
the output of dbc_debug=true will be extremely valuable and making my
life in debugging a lot easier, as I then can follow what YOU did
instead of trying to reproduce what steps you did exactly (I for one
don't know yet how to disable the TCP in postgresql etc).

Thanks for your report.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#834257: dh-python: pybuild should clean *.egg-info directories

[Sean Whitton]

Package: dh-python
Version: 2.20160721
Severity: normal

Dear maintainer,

Building with pybuild can leave a dir foo/foo.egg-info/.  When debhelper
invokes `dh_auto_clean -O--buildsystem=pybuild`, this should be deleted.

Thanks.

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

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

Versions of packages dh-python depends on:
pn  python3:any  

dh-python recommends no packages.

Versions of packages dh-python suggests:
ii  libdpkg-perl  1.18.10

-- no debconf information

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#834256: Please don't force PS1

[Declercq Laurent]

I've already reported the issue to upstream author.


See https://github.com/netblue30/firejail/issues/704


--
Laurent Declercq
iHMS/i-MSCP Project Director

Bug#830888: icinga2-ido-pgsql: dbconfig configuration fails with unix sockets

[Christoph Anton Mitterer]

On Sat, 2016-08-13 at 22:19 +0200, Paul Gevers wrote:
> Sorry for taking a while before responding. Holiday season.
No worries..

> I couldn't quickly find under which user
> the
> program icinga is running
Mutliple things come here together:
- the user/groups under which the icinga daemon itself runs
  => per default user: nagios
- the user/groups under which several services, sitting on top of
  icinga, run... for example the webfrontends, which access the DB then
  => here it depends a bit on the frontend (the legacy one from nagios,
     which runs as CGI vs. the "new" ones from icinga itself, which run
     as PHP). The legacy one however, doesn't access the DB.
  => for CGI, it depends again,... is suexec?
  => for PHP, it depends again on the SAPI (mod_php, CGI?, FCGI?)

In the end, every user is basically free to choose, I for example run
all frontends under their own separated user.
So the legacy CGI get's su'ed to e.g. cgi-icinga-classic, the new ones
run via PHP-CGI and get's su'ed to e.g. cgi-icinga-web...

> but are Unix sockets appropriate?
This is also the most appropriate way. Security-wise it's plain stu***
to run all CGI programs under the same user (e.g. cgi-suexec), and it's
even worse to run PHP programs with mod_php, which place them all under
the webserver's user context (typically and per default www-data user
in Debian).


>  I.e. I
> found a hint it may be running under the nagios user, then Unix
> sockets
> only work if the database user is called the same obviously.
Which is the hint?
Anyway, e.g. postgresql (which I use) allows for a user mapping (https:
//www.postgresql.org/docs/current/static/auth-username-maps.html) when
using the socket based "peer" auth method.
That basically means I can tell postgresql, if system user "foo"
connects, treat him as postgresql user "bar".
So there is no need for the user names being the same.

This works quite well, partially even under db-config (for some of the
connections it makes)... its just that it still tries to make TCP
connections for whatever reason.


>  (The
> maintainers of icinga believe that the default authentication scheme
> should be password (thus TCP) as can be seen in the config file of
> icinga2-ido-pgsql.
Well not sure what they actually mean or not.
Icinga1/2 both support connecting via UNIX sockets, they just don't
show examples for this in their installation guide.


>  One of my packages (cacti) doesn't even know itself
> how to run via an Unix socket
Sure? Normally most postgresql driver interfaces support both (the only
exception I'd know are the Java drivers),.. usually they just configure
it awkwardly via the host/port config options shared with TCP.


> If you leave the password for the icinga user blank, dbconfig will
> create one for you, as if you are using the password scheme, you need
> a
> password obviously.
Well I've seen that,...

I generally think that's a bad thing, btw,... if the user says don't
set a password, then no password should be set, assuming the user does
security somehow else (e.g. via sockets, which is way more secure than
doing local auth with some password, that can probably be easily brute-
forced).
*If* the user takes care on security already somehow else, the
additional password auth just costs performance on each connection.
On UNIX socket connections, no passwords are examined anyway.
Any on TCP the user may have far more superior stuff in place (some
tunneling via a secure network/VPN/SSH?).


>  Now, when
> I try to install icinga2-ido-pgsql (with normal priority), the
> package
> installs fine. So can you please be more verbose on what you did and
> answered in the TCP case, such that I can reproduce?
Well as I've said I did choose UNIX sockets, and I think I've renamed
the DB from icinga2 to just icinga, but that shouldn't matter.
Also my debconf prio was low.

The error that came was as given in the initial bug report, i.e.
despite me choosing unix sockets, it still tried TCP connections (which
of course didn't work, as I've disabled it in postgresql).


> Please also run "debconf-show icinga2-ido-pgsql" and show us the
> output
> (in the situation where you have the issue).
# debconf-show icinga2-ido-pgsql
  icinga2-ido-pgsql/pgsql/app-pass: (password omitted)
  icinga2-ido-pgsql/password-confirm: (password omitted)
  icinga2-ido-pgsql/app-password-confirm: (password omitted)
  icinga2-ido-pgsql/pgsql/admin-pass: (password omitted)
* icinga2-ido-pgsql/db/app-user: icinga@localhost
  icinga2-ido-pgsql/install-error: abort
  icinga2-ido-pgsql/internal/reconfiguring: false
* icinga2-ido-pgsql/pgsql/authmethod-admin: ident
  icinga2-ido-pgsql/missing-db-package-error: abort
* icinga2-ido-pgsql/pgsql/admin-user: postgres
  icinga2-ido-pgsql/remote/newhost:
  icinga2-ido-pgsql/upgrade-error: abort
  icinga2-ido-pgsql/pgsql/no-empty-passwords:
* icinga2-ido-pgsql/dbconfig-reinstall: false
* icinga2-ido-pgsql/db/dbname: icinga
  icinga2-ido-pgsql/remove-error: abort
  icinga2-ido-p

Bug#831726: Opinion on bug 831726 Very confusing prompt regarding administrative database passwords

[Paul Gevers]

Hi d-l10n-english,

I recently got the bug report against my package dbconfig-common (which
you reviewed multiple times the last couple of years) below. What do you
think, should we improve the template (as suggested)?

Paul
PS: no need to reply to me directly, I read the bug.

On Mon, 18 Jul 2016 20:39:01 +0200 Iustin Pop  wrote:
> I'm installing db-common for the first time, so I'm not familiar with
> its configuration or even what is its purpose (installing as a
> dependency).
> 
> During installation, I'm presented with a debconf prompt, which says:
> 
> "By default […] These passwords will be stored in debconf's
> configuration database only for as long as they are needed.
> 
> This behavior can be disabled, in which case the passwords will remain
> in the debconf database […] though this is less secure and thus not the
> default setting.".
> 
> Then the prompt follows: "Keep "administrative" database passwords?
> Yes/No".
> 
> This is very confusing. The prompt talks about default setting vs.
> non-default, but then follows with a 'yes/no'. Is yes the default? or
> No?
> 
> The prompt is also confusing as it asks about "keeping" the passwords,
> but the initial explanation says that both options keep the password,
> just for different amounts of time.
> 
> I would suggest asking "keep passwords in debconf (unsecure) yes/no" or
> something similar.




signature.asc
Description: OpenPGP digital signature

Bug#800573: heimdall-flash and galaxy S5

[Matt Taggart]

I also was able to successfully use heimdall-flash on a Samsung S5 using 
git from 2016-08-12 built on jessie, with no warnings:

=
$ ./Heimdall/build/bin/heimdall flash --RECOVERY twrp-3.0.2-1-klte.img 
--no-reboot
Heimdall v1.4.1

Copyright (c) 2010-2014 Benjamin Dobell, Glass Echidna
http://www.glassechidna.com.au/

This software is provided free of charge. Copying and redistribution is
encouraged.

If you appreciate this software and you would like to support future
development please consider donating:
http://www.glassechidna.com.au/donate/

Initialising connection...
Detecting device...
Claiming interface...
Setting up interface...

Initialising protocol...
Protocol initialisation successful.

Beginning session...

Some devices may take up to 2 minutes to respond.
Please be patient!

Session begun.

Downloading device's PIT file...
PIT file download successful.

Uploading RECOVERY
100%
RECOVERY upload successful

Ending session...
Releasing device interface...

$
=

Maybe upstream should be pursuaded to do a release?

-- 
Matt Taggart
tagg...@debian.org

Bug#829188: icedove segfault in nsDisplayList::DeleteAll

[Ben Caradoc-Davies]

I have not had a single crash since upgrading yesterday to icedove 
1:45.2.0-3 amd64. The upgrade fixes #833532 (crash on startup blamed on 
iceowl), but it also seems to have stopped the folder navigation crashes 
for me. I will report back if I see another crash.


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

Bug#834256: firejail: Please don't force PS1

[Reiner Herrmann]

Hi GSR,

On Sat, Aug 13, 2016 at 09:44:45PM +0200, GSR wrote:
> firejail seems to force PS1. A grep in the git source shows it is done
> by setting PROMPT_COMMAND (!?) in two different places (join.c and
> env.c), but no explanation why in source or documentation.
> 
> If there is a security reason to force PS1 (or even the roundabout way
> with PROMPT_COMMAND) it should be documented. Also using only colors
> to inform of something can backfire, not all terminals support them.
> 
> Otherwise PS1 and PROMPT_COMMAND should be left under shell control
> from the start. They can be overridden once you figure what is going
> on anyway, and I would had not noticed anything if I had used
> PROMPT_COMMAND for something.

I will ask upstream about the reason to change the prompt and if it
can be made optional.

> While investigating this, I found out ${container} env var too with a
> comment talking about Linux Containers. LXC doesn't seem to document
> that one either, and the ones documented follow the standard of all
> upper case (LXC_*), so I also have doubts about its correctness (some
> left over from a LXC script? bug and will be fixed to be upper case?).

The "container" variable is named correctly. LXC and other container
technologies (docker, systemd-nspawn, etc.) export it, to indicate that
a process is running containerized, see also [1].

[1]: https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/


signature.asc
Description: Digital signature

Bug#795755: freedombox-setup: Cleanup LDAP setup process

[James Valleroy]

On Sun, 16 Aug 2015 21:44:07 +0530 Sunil Mohan Adapa 
wrote:
> - Move packages as dependencies: there are many packages being
> installed during
> LDAP setup process. They should instead be added as dependencies in the
> control file. This will allow auto-removing LDAP stuff when
> freedombox-setup
> is removed.
>
> ...
>
> - Move configuration to Plinth: As an alternative to the above process,
> consider moving LDAP setup process to Plinth. This can only happen when
> Plinth has a setup mechanism.
>
The LDAP configuration has been moved to Plinth. We still need to add
the LDAP packages as dependencies though. This will require plinth >=
0.10.0, which allows for re-configuration of the packages after
installation.

--
James



signature.asc
Description: OpenPGP digital signature

Bug#820261: Makefile-patch also needs change

[Christof Schulze]

after applying the patches manually I can confirm they do work well.

--
()  ascii ribbon campaign - against html e-mail
/\  against proprietary attachments

Bug#817469: gartoon: Removal of debhelper compat 4

[Giovani Ferreira]

tags 817469 patch
tags 817469 pending

thanks

Hi,

I did make a NMU and Eriberto sponsored upload to 10-day/delay queue.
Feel free to cancel this upload if needed.

The debian/changelog is:

  * Non-maintainer upload.
  * Update DH level to 9. (Closes: #817469)
  * debian/compat: updated to 9.
  * debian/control:
 - Added the ${misc:Depends} variable to provide the right install
   dependencies.
 - Bumped Standards-Version to 3.9.8.
  * debian/rules:
 - Disabled dh_clean -k line, deprecated.


I attached a debdiff.


cheers,

-- 
Giovani Ferreira
http://softwarelivre.org/jova2
0x78494EF72375A66C
diff -u gartoon-0.5/debian/compat gartoon-0.5/debian/compat
--- gartoon-0.5/debian/compat
+++ gartoon-0.5/debian/compat
@@ -1,2 +1 @@
-4
-4
+9
diff -u gartoon-0.5/debian/changelog gartoon-0.5/debian/changelog
--- gartoon-0.5/debian/changelog
+++ gartoon-0.5/debian/changelog
@@ -1,3 +1,17 @@
+gartoon (0.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update DH level to 9. (Closes: #817469)
+  * debian/compat: updated to 9.
+  * debian/control:
+ - Added the ${misc:Depends} variable to provide the right install
+   dependencies.
+ - Bumped Standards-Version to 3.9.8.
+  * debian/rules:
+ - Disabled dh_clean -k line, deprecated.
+
+ -- Giovani Augusto Ferreira   Sat, 13 Aug 2016 16:25:39 
-0300
+
 gartoon (0.5-4) unstable; urgency=low
 
   * Applied patch from Ubuntu to solve a fliped files. Thanks to Oliver
diff -u gartoon-0.5/debian/control gartoon-0.5/debian/control
--- gartoon-0.5/debian/control
+++ gartoon-0.5/debian/control
@@ -2,15 +2,15 @@
 Section: gnome
 Priority: optional
 Maintainer: Otavio Salvador 
-Build-Depends: debhelper (>= 4.0.0)
-Standards-Version: 3.7.2
+Build-Depends: debhelper (>=9)
+Standards-Version: 3.9.8
 
 Package: gnome-icon-theme-gartoon
 Architecture: all
 Provides: gtk2-engines-gartoon
 Conflicts: gtk2-engines-gartoon (<< 0.4.5-2)
 Replaces: gtk2-engines-gartoon (<< 0.4.5-2)
-Depends: librsvg2-common
+Depends: ${misc:Depends}, librsvg2-common
 Description: Gartoon icon theme for GTK+ 2.x
  This GTK+ theme provides an animated scalable group of icons to be used
  by GTK+ 2.x applications like GNOME 2.
diff -u gartoon-0.5/debian/rules gartoon-0.5/debian/rules
--- gartoon-0.5/debian/rules
+++ gartoon-0.5/debian/rules
@@ -13,7 +13,7 @@
 install: build
dh_testdir
dh_testroot
-   dh_clean -k 
+#  dh_clean -k 
dh_installdirs
 
cp -r index.theme scalable 
debian/gnome-icon-theme-gartoon/usr/share/icons/gartoon/

Bug#834241: open-iscsi-udeb: uninstallable, depends on libmount1-udeb

[Cyril Brulebois]

Hi,

Christian Seiler  (2016-08-13):
> (Cc'ing util-linux and selinux maintainers.)
> 
> On 08/13/2016 07:08 PM, Cyril Brulebois wrote:
> > partman-iscsi and open-iscsi-udeb are no longer installable since the
> > latter now depends on libmount1-udeb, which was dropped in 2014 (see
> > https://bugs.debian.org/723168).
> [ summary of #723168: libmount1-udeb was dropped because it
>   had no rdep at that time, and it now depended on libselinux,
>   which didn't have an udeb at the time and still doesn't ]
> 
> Yikes. I'm terribly sorry I didn't catch that. :-(

No worries, we've had udeb installability checks for a while, and
they're here for a reason. :)

> Note that libmount1-udeb is not explicitly listed as a
> dependency, but added via substvars automatically. And since
> libmount-dev needs to explicitly have the udeb in its shlibs,
> once I saw the automatic dependency in the udeb, I assumed
> that libmount1-udeb would just exist. (I think the udeb:
> line in the shlibs file of libmount is still there, even
> though the udeb was removed.)

I filed the bug report right away to avoid forgetting about it but yeah,
the following in libmount1 is somewhat misleading (second line):
| libmount 1 libmount1 (>= 2.28~)
| udeb: libmount 1 libmount1-udeb (>= 2.28~)

> The question is: what's the best fix for that?
> 
>  - libmount is now a hard dependency of open-iscsi. It's not
>critical functionality (it's a new safety feature to not
>log out of sessions that still have mounted file systems,
>which is not that important in a d-i environment), and I
>could easily patch it out. OTOH, I seriously doubt
>upstream will want to make libmount optional. (Especially
>since it's from util-linux, which is really a base
>package.)
> 
>  - OTOH, this affects more than just one package
> 
> As a short term fix I could build open-iscsi twice, once
> with and once without the libmount dependency. But I really
> don't want to carry a Debian-specific patch that removes
> libmount forever, so the proper solution would be to
> coordinate with util-linux and selinux to have both of them
> (selinux first) provide udebs for the libraries. (I doubt
> that util-linux maintainers want to build util-linux twice
> either.)
> 
> So I'd probably want to do the following:
> 
>  Step 1: build open-iscsi twice, once with libmount patched
>  out (closing this bug)
>  Step 2: file bugs against util-linux and libselinux to
>  have them build udebs (I can provide patches)
>  Step 3: make open-iscsi-udeb depend on libmount1-udeb again
> 
> Is that agreeable?

I can't comment on the libmount/libselinux bits, but looking at it from
a debian-boot@ point of view, that looks rather sane, thanks.


KiBi.


signature.asc
Description: Digital signature

Bug#834241: open-iscsi-udeb: uninstallable, depends on libmount1-udeb

[Christian Seiler]

Control: tags -1 + confirmed

(Cc'ing util-linux and selinux maintainers.)

On 08/13/2016 07:08 PM, Cyril Brulebois wrote:
> partman-iscsi and open-iscsi-udeb are no longer installable since the
> latter now depends on libmount1-udeb, which was dropped in 2014 (see
> https://bugs.debian.org/723168).
[ summary of #723168: libmount1-udeb was dropped because it
  had no rdep at that time, and it now depended on libselinux,
  which didn't have an udeb at the time and still doesn't ]

Yikes. I'm terribly sorry I didn't catch that. :-(

Note that libmount1-udeb is not explicitly listed as a
dependency, but added via substvars automatically. And since
libmount-dev needs to explicitly have the udeb in its shlibs,
once I saw the automatic dependency in the udeb, I assumed
that libmount1-udeb would just exist. (I think the udeb:
line in the shlibs file of libmount is still there, even
though the udeb was removed.)

The question is: what's the best fix for that?

 - libmount is now a hard dependency of open-iscsi. It's not
   critical functionality (it's a new safety feature to not
   log out of sessions that still have mounted file systems,
   which is not that important in a d-i environment), and I
   could easily patch it out. OTOH, I seriously doubt
   upstream will want to make libmount optional. (Especially
   since it's from util-linux, which is really a base
   package.)

 - OTOH, this affects more than just one package

As a short term fix I could build open-iscsi twice, once
with and once without the libmount dependency. But I really
don't want to carry a Debian-specific patch that removes
libmount forever, so the proper solution would be to
coordinate with util-linux and selinux to have both of them
(selinux first) provide udebs for the libraries. (I doubt
that util-linux maintainers want to build util-linux twice
either.)

So I'd probably want to do the following:

 Step 1: build open-iscsi twice, once with libmount patched
 out (closing this bug)
 Step 2: file bugs against util-linux and libselinux to
 have them build udebs (I can provide patches)
 Step 3: make open-iscsi-udeb depend on libmount1-udeb again

Is that agreeable?

Regards,
Christian

Bug#830888: icinga2-ido-pgsql: dbconfig configuration fails with unix sockets

[Paul Gevers]

Control: tags -1 moreinfo

Hi Christoph,

Sorry for taking a while before responding. Holiday season.

On Tue, 19 Jul 2016 01:35:13 +0200 Christoph Anton Mitterer
 wrote:
> I've just checked the whole package again, and nothing in it seems to
> so contain anything about tcp or UNIX sockets... so it rather seems to
> me that this might be a problem in dbconfig, thus reassigning and
> kindly asking its maintainers to have a look.

I agree with you that the issue you experience is more likely in
dbconfig than in icinga.

I have multiple question:

For your initial question: I couldn't quickly find under which user the
program icinga is running, but are Unix sockets appropriate? I.e. I
found a hint it may be running under the nagios user, then Unix sockets
only work if the database user is called the same obviously. (The
maintainers of icinga believe that the default authentication scheme
should be password (thus TCP) as can be seen in the config file of
icinga2-ido-pgsql. One of my packages (cacti) doesn't even know itself
how to run via an Unix socket, so the dbconfig question is misleading
there (but luckily for the package ignored anyways), maybe icinga has a
similar "issue".

If you leave the password for the icinga user blank, dbconfig will
create one for you, as if you are using the password scheme, you need a
password obviously. The debconf question should have told you. Now, when
I try to install icinga2-ido-pgsql (with normal priority), the package
installs fine. So can you please be more verbose on what you did and
answered in the TCP case, such that I can reproduce?

Please also run "debconf-show icinga2-ido-pgsql" and show us the output
(in the situation where you have the issue).

Also, if you can reproduce the issue, running the installation with
export dbc_debug=true
is also very helpful (mind you, you may have to hide your passwords
before you send the response).

Paul



signature.asc
Description: OpenPGP digital signature

Bug#834256: firejail: Please don't force PS1

[GSR]

Package: firejail
Version: 0.9.40-3
Severity: normal

Dear Maintainer,

firejail seems to force PS1. A grep in the git source shows it is done
by setting PROMPT_COMMAND (!?) in two different places (join.c and
env.c), but no explanation why in source or documentation.

If there is a security reason to force PS1 (or even the roundabout way
with PROMPT_COMMAND) it should be documented. Also using only colors
to inform of something can backfire, not all terminals support them.

Otherwise PS1 and PROMPT_COMMAND should be left under shell control
from the start. They can be overridden once you figure what is going
on anyway, and I would had not noticed anything if I had used
PROMPT_COMMAND for something.

While investigating this, I found out ${container} env var too with a
comment talking about Linux Containers. LXC doesn't seem to document
that one either, and the ones documented follow the standard of all
upper case (LXC_*), so I also have doubts about its correctness (some
left over from a LXC script? bug and will be fixed to be upper case?).

Thanks,
GSR

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

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

Versions of packages firejail depends on:
ii  libc6  2.23-4

Versions of packages firejail recommends:
pn  xpra | xserver-xephyr  

firejail suggests no packages.

-- no debconf information

Bug#834201: ImportError: No module named '_xapian'

[Olly Betts]

Control: forwarded -1 https://trac.xapian.org/ticket/731
Control: tags -1 +fixed-upstream

On Fri, Aug 12, 2016 at 05:34:23PM -0700, Jameson Graef Rollins wrote:
> I run into the following ImportError when I try to import the python3
> xapian module:

Thanks - this was already reported and fixed upstream in fact.

> Looking forward to seeing python3-xapian in testing soon!

That's probably at least a few weeks off yet - we need to finish
preparing for the xapian-core library transition and then get a
transition slot from the release team.

Cheers,
Olly

Bug#834255: liferea: Internal Browser Doesn't Save PWDs

[Stephen]

Package: liferea
Version: 1.10.19-2
Severity: normal

Dear Maintainer,

I like to use the internal browser and post important articles to
Twitter. So I went through the authorization process but on subsequent
startups, Liferea is prompted for the login information again. It
doesn't appear to use the Gnome built in Keychain, which it is supposed
to. I say this, because one is usually prompted to save a pwd, by
Keychain when invoked. Didn't happen.

Thanks for your consideration, look forward to a fix.

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

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

Versions of packages liferea depends on:
ii  dbus-x11 1.10.8-1
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-1
ii  gir1.2-gtk-3.0   3.20.7-1
ii  gir1.2-peas-1.0  1.18.0-3
ii  libatk1.0-0  2.20.0-1
ii  libc62.23-4
ii  libcairo21.14.6-1+b1
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libgirepository-1.0-11.48.0-3
ii  libglib2.0-0 2.48.1-2
ii  libgtk-3-0   3.20.7-1
ii  libindicate5 0.6.92-3
ii  libjson-glib-1.0-0   1.2.2-1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpeas-1.0-01.18.0-3
ii  libpeas-1.0-python2loader1.18.0-3
ii  libsoup2.4-1 2.54.1-1
ii  libsqlite3-0 3.14.0-1
ii  libwebkitgtk-3.0-0   2.4.11-2+b2
ii  libxml2  2.9.4+dfsg1-1+b1
ii  libxslt1.1   1.1.28-4
ii  liferea-data 1.10.19-2
ii  python-gi3.20.1-1
pn  python:any   

Versions of packages liferea recommends:
ii  gir1.2-gnomekeyring-1.0  3.12.0-1+b1
ii  gnome-icon-theme 3.12.0-2
ii  gnome-keyring3.20.0-2

Versions of packages liferea suggests:
pn  kget 
ii  network-manager  1.2.4-2

-- no debconf information

Bug#824130: ITP: libgames-support -- Useful functionality shared among GNOME games

[Jeremy Bicha]

On Sat, Aug 13, 2016 at 3:58 AM, Michael Catanzaro  wrote:
> I've done this once before (libgames-scores -> libgames-support) so I'm
> really not keen on doing a rename again. That said, if you want to
> submit a patch and do the work with the sysadmins to make the rename
> happen, you have my permission; you can point them to this comment to
> show that.

Patches submitted at https://bugzilla.gnome.org/769860

Thanks,
Jeremy

Bug#833798: krb5: FTBFS with -O3: uninitialized variables

[Benjamin Kaduk]

On Thu, 11 Aug 2016, Steve Langasek wrote:

> Well, gcc -O3 should give you the same answer anywhere, not just on ppc64el

It should, yes, though since I don't have an ubuntu machine handy it might
be a different version, etc., so I like to go back to the original
environment when possible.

> :)  Yes, I can confirm that the above patch also fixes the build failure
> (after fixing the syntax error in the patch to src/tests/asn.1/trval.c).

Whoops, sorry about the syntax error.  Thanks for testing; the fixed
version is now https://github.com/krb5/krb5/pull/511

-Ben

Bug#811866: fixed in hyphy 2.2.6+dfsg-4

[Andreas Tille]

Hi Santiago,

On Sat, Aug 13, 2016 at 07:32:45PM +0200, Santiago Vila wrote:
> found 811866 2.2.6+dfsg-4
> thanks
> 
> Still FTBFS:

Probably not "still" but again since this is a different error.
 
> https://tests.reproducible-builds.org/debian/rbuild/testing/amd64/hyphy_2.2.6+dfsg-4.rbuild.log

It boils down to


...
build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '2.3969e+2' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
 };
 ^
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '3.0598e+1' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '2.8051e+1' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '1.0455e+2' from 'double' to 'unsigned char' inside { } 
[-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '1.1731e+2' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '2.32050001e+2' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '2.32050001e+2' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '8.6703e+1' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
/build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:113:1: error: narrowing 
conversion of '4.5899e+1' from 'double' to 'unsigned char' inside { 
} [-Wnarrowing]
...


Which is caused by:


_HYColorchartColors [HY_CHART_COLOR_COUNT] = {
{255*.94, 255*.12, 255*.11 },//(Red)
{255*.41, 255*.46, 255*.91 },//(Evening Blue)
{255, 255*.91, 255*.34 },//(Banana)
{255*.18, 255*.55, 255*.13 },//(Clover)
{255*.55, 255*.38, 255*.21 },//(Dirt)
{255*.42, 255*.09, 255*.69 },//(Royal Violet)
{255*.09, 255*.29, 255*.51 },//(Sea Blue)
{255   ,  255*.57, 255*.09 },//(Orange)
{255*.67, 255*.67, 255*.67 },//(Concrete)
{255*.85, 255*.27, 255*.42 } //(Carnation)
};


the narrowing conversion in this case is absolutely intended here
obviously.  Is there any more elegant solution for these case than
something like

s:\.\([0-9][0-9]\):\1/100:g

?

Kind regards

   Andreas.


-- 
http://fam-tille.de

Bug#832011: ncl: FTBFS with -fdebug-prefix-map

[Mattia Rizzolo]

On Sat, Aug 13, 2016 at 08:47:45PM +0200, Santiago Vila wrote:
> Great! Yesterday I was looking for the way to disable that in another
> package. Is this documented properly in the manpages / debian wiki?

of course.
in dpkg-buildflags(1).
:)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://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#832011: ncl: FTBFS with -fdebug-prefix-map

[Santiago Vila]

severity 832011 serious
thanks

On Thu, 21 Jul 2016, Mattia Rizzolo wrote:

> Source: ncl
> Version: 6.3.0-8
> Severity: important
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> 
> Dear maintainer, your package FTBFS when dpkg enables the build flag
> -fdebug-prefix-map from the reproducible/fixdebugpath feature area:

This now happens by default, so raising severity.

> A quick workaround would be to disable the reproducible/fixdebugpath
> buildflags with
> export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixdebugpath

Great! Yesterday I was looking for the way to disable that in another
package. Is this documented properly in the manpages / debian wiki?

I could not find it.

Thanks.

Bug#834248: libtexttools: FTBFS in testing

[Santiago Vila]

Note: Bug #832011 is very similar.

Workaround by Mattia: Put this in debian/rules:

export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixdebugpath

(Not tested myself)

Thanks.

Bug#832129: [wine-development]: RegEdit fails to export whole registry

[Jens Reyer]

On 13.08.2016 19:40, Joerg Schiermeier wrote:

Hello,

I sent a patch to WinHQ and it was accepted. See patch here:


Now this is working.
Maybe someone wants to close this ticket?


Thanks for your work.
I already tagged the report fixed-upstream. It will be closed once the 
fixed version is uploaded to the archive.


Greets
jre

Bug#834238: dh-python: misparses dh-control and copies build profiles into substvars

[Chris Lamb]

tags 834238 + patch
thanks

Patch attached.

The spec for this field is here:

  https://wiki.debian.org/BuildProfileSpec

An_alternative diff could be:

  -\(?(?P[>=<]+\s*[^\)]+)?\)?
  +\(?(?P[>=<]+(?!!)\s*[^\)]+)?\)?

.. if there is a good reason why we make the parens optional, rather
than the entire version group. However, I could not find anything in
the git log so I am assuming its an oversight.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/dhpython/debhelper.py b/dhpython/debhelper.py
index d54c2d8..6608d27 100644
--- a/dhpython/debhelper.py
+++ b/dhpython/debhelper.py
@@ -29,7 +29,7 @@ log = logging.getLogger('dhpython')
 parse_dep = re.compile('''[,\s]*
 (?P[^ ]+)
 \s*
-\(?(?P[>=<]+\s*[^\)]+)?\)?
+(?:\((?P[>=<]+\s*[^\)]+)?\))?
 \s*
 (?P\[[^\]]+\])?
 ''', re.VERBOSE).match

Bug#834035: kdb5_util hangs forever

[Greg Hudson]

This appears to be gnu libc bug 20251, which does not appear to have
been fixed yet:

https://sourceware.org/bugzilla/show_bug.cgi?id=20251

We will explore workarounds.  I have opened a ticket in our database to
track the issue:

http://krbdev.mit.edu/rt/Ticket/Display.html?id=8474

Bug#834207: tj3: Copyright of lib/taskjuggler/AlgorithmDiff.rb

[Vincent Bernat]

 ❦ 13 août 2016 07:33 CEST, Christopher Hoskin  :

> The file lib/taskjuggler/AlgorithmDiff.rb contains the text "But some
> code fragments are very similar to the original and are copyright (C)
> 2001 Lars Christensen."
>
> Should this be reflected in the debian/copyright file (see attached
> patch)?

The original implementation cited is written in Perl. This
implementation is in Ruby. An algorithm itself cannot be
copyrighted. The attribution is done in a bit of confusing way. I don't
think this is worth to push this confusion in debian/copyright. If the
author (Chris) really thinks that his work is derived work, he should
have just added the name of the original author in its copyright
attribution.
-- 
It usually takes more than three weeks to prepare a good impromptu speech.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#834254: New usptream available

[Martin Michlmayr]

Package: getmail4
Severity: wishlist

4.50.0 has been available for a while.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#800219: wordplay: Please migrate a supported debhelper compat level

[Giovani Ferreira]

tags 800219 patch
tags 800219 pending

thanks

Hi,

I did make a NMU and Herbert sponsored upload to 10-day/delay queue.
Feel free to cancel this upload if needed.


The debian/changelog is:

  * Non-maintainer upload.
  * Update DH level to 9. (Closes: #800219)
  * debian/compat: created and set to 9, instead of using DH_COMPAT.
  * debian/control:
 - Added the ${misc:Depends} variable to provide the right install
   dependencies.
 - Bumped Standards-Version to 3.9.8.
  * debian/rules:
 - Disabled the DH_COMPAT line.
 - Disabled dh_clean -k line, deprecated.

I attached a debdiff.


cheers,

-- 
Giovani Ferreira
http://softwarelivre.org/jova2
0x78494EF72375A66C
diff -u wordplay-7.22/debian/changelog wordplay-7.22/debian/changelog
--- wordplay-7.22/debian/changelog
+++ wordplay-7.22/debian/changelog
@@ -1,3 +1,18 @@
+wordplay (7.22-17.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Update DH level to 9. (Closes: #800219)
+  * debian/compat: created and set to 9, instead of using DH_COMPAT.
+  * debian/control:
+ - Added the ${misc:Depends} variable to provide the right install
+   dependencies.
+ - Bumped Standards-Version to 3.9.8.
+  * debian/rules:
+ - Disabled the DH_COMPAT line.
+ - Disabled dh_clean -k line, deprecated.
+
+ -- Giovani Augusto Ferreira   Sat, 13 Aug 2016 14:25:55 
-0300
+
 wordplay (7.22-17) unstable; urgency=low
 
   * Improved description using proposals by Justin B Rye 
diff -u wordplay-7.22/debian/control wordplay-7.22/debian/control
--- wordplay-7.22/debian/control
+++ wordplay-7.22/debian/control
@@ -1,13 +1,13 @@
 Source: wordplay
 Section: games
 Priority: optional
-Build-Depends: debhelper (>> 3.0.0)
+Build-Depends: debhelper (>=9)
 Maintainer: Pawel Wiecek 
-Standards-Version: 3.6.2
+Standards-Version: 3.9.8
 
 Package: wordplay
 Architecture: any
-Depends: ${shlibs:Depends}
+Depends: ${misc:Depends}, ${shlibs:Depends}
 Description: anagram generator
  Wordplay generates anagrams of words or phrases. For example,
  "Debian GNU/Linux" = "laud benign unix", "nubian lug index",
diff -u wordplay-7.22/debian/rules wordplay-7.22/debian/rules
--- wordplay-7.22/debian/rules
+++ wordplay-7.22/debian/rules
@@ -3,7 +3,6 @@
 # GNU copyright 1997 to 1999 by Joey Hess.
 
 # Uncomment this to turn on verbose mode.
-export DH_COMPAT=3
 
 build: build-stamp
 build-stamp:
@@ -26,7 +25,7 @@
 binary-arch: build
dh_testdir
dh_testroot
-   dh_clean -k
+#  dh_clean -k
dh_installdirs
install -s wordplay debian/wordplay/usr/bin
install -m 644 words721.txt debian/wordplay/usr/share/games/wordplay
only in patch2:
unchanged:
--- wordplay-7.22.orig/debian/compat
+++ wordplay-7.22/debian/compat
@@ -0,0 +1 @@
+9