Bug#831992: ui: Fix clickable table row cursor on display-mail-archive

[Christos Trochalakis]

Package: nm.debian.org
Severity: minor
Tags: patch

Hello,

Although rows are clickable in the auto expanding mail table, the cursor
is not a pointer.

It appears that the functionallity exists (there is a tr.clickable CSS
class) but the clickable class is by mistake assigned to the table
instead of the tr elements.

The attached patch should fix the issue.
>From 06c240a6aa39a03589ec031cf965bda7908b0fd3 Mon Sep 17 00:00:00 2001
From: Christos Trochalakis 
Date: Wed, 20 Jul 2016 15:50:28 +0300
Subject: [PATCH] Fix clickable table row cursor

Although rows are clickable in the auto expanding mail table the cursor
is not a pointer.

It appears that the functionallity exists (there is a tr.clickable CSS
class) but the clickable class is by mistake assigned to the table
instead of the tr elements.

While we are at it, we can clarify the mailstable.find() expression a
bit.
---
 process/templates/process/display-mail-archive.html   | 6 +++---
 restricted/templates/restricted/display-mail-archive.html | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/process/templates/process/display-mail-archive.html b/process/templates/process/display-mail-archive.html
index 0fe2b1b..4801b10 100644
--- a/process/templates/process/display-mail-archive.html
+++ b/process/templates/process/display-mail-archive.html
@@ -25,7 +25,7 @@ $(function() {
 },
 });
 
-mailstable.find("tbody").find("tr").click(function(ev) {
+mailstable.find("tr.clickable").click(function(ev) {
   var el = $(this);
   el.next(".showable").toggle();
 });
@@ -42,7 +42,7 @@ $(function() {
 
 (Click to see the message body)
 
-
+
 
 
 Date
@@ -52,7 +52,7 @@ $(function() {
 
 
 {% for m in mails %}
-
+
 {{m.Date}}
 {{m.From}}
 {{m.Subject}}
diff --git a/restricted/templates/restricted/display-mail-archive.html b/restricted/templates/restricted/display-mail-archive.html
index 0fe2b1b..4801b10 100644
--- a/restricted/templates/restricted/display-mail-archive.html
+++ b/restricted/templates/restricted/display-mail-archive.html
@@ -25,7 +25,7 @@ $(function() {
 },
 });
 
-mailstable.find("tbody").find("tr").click(function(ev) {
+mailstable.find("tr.clickable").click(function(ev) {
   var el = $(this);
   el.next(".showable").toggle();
 });
@@ -42,7 +42,7 @@ $(function() {
 
 (Click to see the message body)
 
-
+
 
 
 Date
@@ -52,7 +52,7 @@ $(function() {
 
 
 {% for m in mails %}
-
+
 {{m.Date}}
 {{m.From}}
 {{m.Subject}}
-- 
2.8.1

Bug#792787: #792787

[Nicolas MAUBERT]

Hello,

I have the same problem.

I temporaly solved by change the system language from fr_FR.UTF-8 to 
en_US.UTF-8 by the command dpkg-reconfigure locales.
You can also fix juste for one with this syntax : LANG=C 
/usr/lib/nagios/plugins/check_ntp_time -H ntp.ovh.net -w 1 -c 2


Regards,
Nico.

Bug#831990: ITP: python-prompt-toolkit -- Library for building powerful interactive command lines in Python

[Julien Puydt]

Package: wnpp
Severity: wishlist

* Package name : python-prompt-toolkit
  Version  : 1.0.3
  Upstream author  : Jonathan Slenders
* URL  : 
https://github.com/jonathanslenders/python-prompt-toolkit

  License  : BSD-3-clause
  Programming Lang.: Python
  Description  : Library to build powerful interactive command 
lines in Python

 This module is a library to build powerful interactive command lines,
 with syntax highlightning during typing, multi-line editing, advanced
 code completion and a long list of other features.

This is a dep of recent ipython versions. I plan to package it within 
the Debian Python Module Team repository.


Snark on #debian-games

Bug#828632: (no subject)

[Pino Toscano]

yes, it would be great if you can backport the fix, and upload to
Debian.  This way, we can finish the tidy-html5 transition also on
non-Linux architectures (kfreebsd-* and hurd-*), and thus have one step
less to remove the old tidy source.

PS: the Debian bug tracking system emails only the assignee when
writing to n...@bugs.debian.org, so please explicitly CC interested
people (e.g. using nnn-submitter@b.d.o) when you need their feedback.
I know it might sound confusing, but it is what it is...

Thanks,
-- 
Pino

Bug#831989: icedove: Crash in nsDisplayItem::GetClippedBounds / GetBounds

[Stefan Weil]

Package: icedove
Version: 1:45.1.0-1
Severity: normal

Dear Maintainer,

icedove crashed randomly during normal operation.
The stack differs from two other kinds of random crashes
which I got some days ago.

This is the first time that I see a crash in GetBounds,
nor did I find similar crashes in the net.

Regards
Stefan

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

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

Versions of packages icedove depends on:
ii  debianutils   4.4+b1
ii  fontconfig2.11.0-6.3
ii  libasound21.0.28-1
ii  libatk1.0-0   2.20.0-1
ii  libc6 2.23-1
ii  libcairo2 1.14.0-2.1+deb8u1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.102-1
ii  libevent-2.0-52.0.21-stable-2
ii  libffi6   3.1-2+b2
ii  libfontconfig12.11.0-6.3
ii  libfreetype6  2.5.2-3+deb8u1
ii  libgcc1   1:6.1.1-9
ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
ii  libglib2.0-0  2.48.1-1
ii  libgtk2.0-0   2.24.25-3+deb8u1
ii  libhunspell-1.4-0 1.4.1-2
ii  libicu55  55.1-7
ii  libnspr4  2:4.12-2
ii  libnss3   2:3.23-2
ii  libpango-1.0-01.40.1-1
ii  libpangocairo-1.0-0   1.40.1-1
ii  libpangoft2-1.0-0 1.40.1-1
ii  libpixman-1-0 0.32.6-3
ii  libsqlite3-0  3.8.7.1-1+deb8u1
ii  libstartup-notification0  0.12-4
ii  libstdc++66.1.1-9
ii  libvpx3   1.5.0-3
ii  libx11-6  2:1.6.2-3
ii  libxcomposite11:0.4.4-1
ii  libxdamage1   1:1.1.4-2+b1
ii  libxext6  2:1.3.3-1
ii  libxfixes31:5.0.1-2+b2
ii  libxrender1   1:0.9.8-1+b1
ii  libxt61:1.1.4-1+b1
ii  psmisc22.21-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages icedove recommends:
ii  hunspell-de-at [hunspell-dictionary]  20131206-5
ii  hunspell-de-ch [hunspell-dictionary]  20131206-5
ii  hunspell-de-de [hunspell-dictionary]  20131206-5
ii  hunspell-en-us [hunspell-dictionary]  20070829-6
ii  iceowl-extension  1:45.1.0-1

Versions of packages icedove suggests:
ii  fonts-lyx 2.1.2-2
ii  libgssapi-krb5-2  1.14.2+dfsg-1

-- no debconf information

Bug#817424: here's a patch

[Adam Borowski]

control: tags -1 +patch

Hi!
Here's a patch migrating debfoster to dh 9, fixing the FTBFS.

I've moved the bash_completion file to a dir on its own to simplify the
packaging -- debian/rules is now the usual dh two-liner.


Meow!
-- 
An imaginary friend squared is a real enemy.
>From 0eb439c5dc0816aa1f38150fae518818f2e03bd8 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Thu, 21 Jul 2016 06:36:31 +0200
Subject: [PATCH] dh 9

---
 debian/bash_completion/debfoster | 41 +++
 debian/compat|  2 +-
 debian/control   |  2 +-
 debian/debfoster.bash_completion | 41 ---
 debian/install   |  2 +
 debian/rules | 85 +---
 6 files changed, 47 insertions(+), 126 deletions(-)
 create mode 100644 debian/bash_completion/debfoster
 delete mode 100644 debian/debfoster.bash_completion
 create mode 100644 debian/install

diff --git a/debian/bash_completion/debfoster b/debian/bash_completion/debfoster
new file mode 100644
index 000..0c6e3ac
--- /dev/null
+++ b/debian/bash_completion/debfoster
@@ -0,0 +1,41 @@
+# -*- sh -*-
+
+# Provided by Eric Hansander  in
+# 
+
+have debfoster &&
+_debfoster()
+{
+local cur prev options
+
+COMPREPLY=()
+cur=${COMP_WORDS[COMP_CWORD]}
+prev=${COMP_WORDS[COMP_CWORD-1]}
+options='-v --verbose -V --version -h --help -q --quiet -f --force \
+  -m --mark-only -u --upgrade -c --config -k --keeperfile -n \
+  --no-keeperfile -i --ignore-default-rules -a --show-keepers -s \
+  --show-orphans -d --show-depends -e --show-dependents -p \
+  --show-providers -r --show-related -t --use-tasks -o --option'
+
+case $prev in
+-@(c|-config|k|-keeperfile))
+_filedir
+return 0
+;;
+-@(d|-show-depends|e|-show-dependents|r|-show-related))
+COMPREPLY=( $( _comp_dpkg_installed_packages $cur ) )
+return 0
+;;
+esac
+
+if [[ "$cur" == -* ]]; then
+COMPREPLY=( $( compgen -W "$options" -- $cur ) )
+else
+# This is just an approximation.  Actually, debfoster can
+# install new packages, which won't appear in that list.
+COMPREPLY=( $( _comp_dpkg_installed_packages $cur ) )
+fi
+
+return 0
+}
+test "$have" && complete -F _debfoster $default debfoster
diff --git a/debian/compat b/debian/compat
index b8626c4..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-4
+9
diff --git a/debian/control b/debian/control
index 80a4dfc..228b0c9 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: admin
 Priority: optional
 Maintainer: debfoster Maintainer Team 
 Uploaders: Andreas Barth , Marc Haber , Florian Weimer 
-Build-Depends: debhelper (>> 4.0.0), gettext, libgc-dev
+Build-Depends: debhelper (>> 9), gettext, libgc-dev
 Standards-Version: 3.7.2
 
 Package: debfoster
diff --git a/debian/debfoster.bash_completion b/debian/debfoster.bash_completion
deleted file mode 100644
index 0c6e3ac..000
--- a/debian/debfoster.bash_completion
+++ /dev/null
@@ -1,41 +0,0 @@
-# -*- sh -*-
-
-# Provided by Eric Hansander  in
-# 
-
-have debfoster &&
-_debfoster()
-{
-local cur prev options
-
-COMPREPLY=()
-cur=${COMP_WORDS[COMP_CWORD]}
-prev=${COMP_WORDS[COMP_CWORD-1]}
-options='-v --verbose -V --version -h --help -q --quiet -f --force \
-  -m --mark-only -u --upgrade -c --config -k --keeperfile -n \
-  --no-keeperfile -i --ignore-default-rules -a --show-keepers -s \
-  --show-orphans -d --show-depends -e --show-dependents -p \
-  --show-providers -r --show-related -t --use-tasks -o --option'
-
-case $prev in
--@(c|-config|k|-keeperfile))
-_filedir
-return 0
-;;
--@(d|-show-depends|e|-show-dependents|r|-show-related))
-COMPREPLY=( $( _comp_dpkg_installed_packages $cur ) )
-return 0
-;;
-esac
-
-if [[ "$cur" == -* ]]; then
-COMPREPLY=( $( compgen -W "$options" -- $cur ) )
-else
-# This is just an approximation.  Actually, debfoster can
-# install new packages, which won't appear in that list.
-COMPREPLY=( $( _comp_dpkg_installed_packages $cur ) )
-fi
-
-return 0
-}
-test "$have" && complete -F _debfoster $default debfoster
diff --git a/debian/install b/debian/install
new file mode 100644
index 000..e8c99f8
--- /dev/null
+++ b/debian/install
@@ -0,0 +1,2 @@
+debian/debfoster2aptitude usr/sbin/
+debian/bash_completion/debfoster etc/bash_completion.d/
diff --git a/debian/rules b/debian/rules
index a19d653..be1a4c2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,86 +1,5 @@
 #!/usr/bin/make -f
-# Sample debian/rules that uses debhelper.
-# GNU copyright 1997 to 1999 by Joey Hess.
-
-# Uncomment this t

Bug#831891: [Debian-med-packaging] Bug#831891: r-cran-dplyr: New upstream release v0.5.0

[Charles Plessy]

Le Wed, Jul 20, 2016 at 10:04:46PM +0800, Frederik Vanrenterghem a écrit :
> 
> Version 0.5.0 of dplyr was released in June 2016 with several breaking 
> changes.

Thanks Frederik,

to update the r-cran-dplyr package we will need to create at least one new
Debian package, for the tibble R package.  So you will have to be patient,
sorry !

Have a nice day,

Charles

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

Bug#831897: [Reproducible-builds] Bug#831897: lepton: leaves a zombie process around after build

[陳昌倬]

Control: forwarded -1 https://github.com/dropbox/lepton/issues/42

On Wed, Jul 20, 2016 at 04:12:51PM +, Mattia Rizzolo wrote:
> That said, I find totally unacceptable for a build to leak a process and
> leave it zombie (because that process had no parent, actually), so I'm
> filing this at RC level.

Thanks for the report. I will look into it.

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D
  BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#829188: icedove SEGV backtrace

[Benoît Ganne]

>   LANG= /usr/lib/icedove/run-mozilla.sh -g /usr/lib/icedove/icedove-bin
> --safe-mode 2>&1 | tee /tmp/icedove-gdb-$(apt-cache show icedove | grep
> Version | awk '{ print $2 }')_$(date +%F_%T).log

I just reproduced the crash with the above command, please find the
logfile including backtrace (gzip'ed) attached.
Hope this help.

ben

icedove-gdb-1:45.2.0-1.gz
Description: GNU Zip compressed data

Bug#824896: the patch is bogus

[Adam Borowski]

control: tags -1 -patch

The only actual error in the copyright file that I know is claiming GPL2+
instead of GPL2 for most files.

On the other hand, the proposed patch introduces about as many serious
errors as it has entries; it's beyond worthless.

-- 
An imaginary friend squared is a real enemy.

Bug#810890: caddy in Debian

[Zlatan Todoric]

Hi,

On 07/21/2016 04:12 AM, Nicolas Braud-Santoni wrote:
> Hi Zlatan,
> 
> I'm taking the liberty to start packaging caddy and its dependencies,
> as part of the pkg-go team.
> 
> I would be happy to see this package be co-maintained, though,
> whether it is by you or Iain.

All sounds fine but I wish you notified me few days earlier before
pushing ITPs. I for example have uploaded the shlex package to mentors
which you seem you're going to duplicate now (it was once in newqueue
and reject because it missed Google in copyright notice). Also I have
few more prepared (just needs finish touches) which may or may not be
worked at your side - but again potential duplicated effort.

I am happy that you decided to work on this, and yes I would (will) join
the co-maint role but also I think it would be polite to notify me at
least few days in front and not just hijack ITPs.

> 
> 
> Best,
> 
>   nicoo
> 

Bug#831678: Fw: gtk2-engines-murrine: Text shadow misaligned for desktop icons on XFCE

[James Lu]

Control: affects 831678 xfdesktop4

Hi everyone, forwarding this to pkg-xfce-devel so they're in the loop.

Best,
James

On Mon, 18 Jul 2016 08:20:41 -0400 Jeremy Bicha  wrote:
> Package: gtk2-engines-murrine
> Version: 0.98.1.1-6
> 
> The most recent gtk2-engines-murrine update (0.98.1.1-6) to fix bug
> 827134 caused a regression in some themes on the Xfce desktop. The
> text shadow is significantly misaligned with the text for Xfce desktop
> icons. See https://launchpad.net/bugs/1598316
> 
> You can verify using arc-theme which was recently packaged in Debian.
> 
> In my testing, I was not able to duplicate this issue on Ubuntu MATE
> which also uses GTK2 but uses Nautilus to draw the desktop. Therefore,
> I'm thinking this bug should be raised with Xfce.
> 
> Thanks,
> Jeremy Bicha
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#831751: openafs-client unreliable after kernel update

[Benjamin Kaduk]

fixed 831751 1.6.17-1
thanks

On Mon, 18 Jul 2016, Chad Seys wrote:

> Package: openafs-client
> Version: 1.6.9-2+deb8u5
> Severity: important
>
> Dear Maintainer,
>
> As discussed on the openafs-info mailing list, the openafs-client is 
> unreliable
> (cannot checkout certain repos) after some backported patches were applied to 
> the
> kernel.

Thanks for the report!  I'll note that it's fixed in sid, and leave the
bug open pending a backport to jessie.  (People interested in a backport
to wheezy as well should speak up -- though the backport should not be
difficult, it is helpful to justify the upload when there is user demand.)

-Ben

Bug#811622: here's a patch

[Adam Borowski]

control: tags -1 +patch

Here's a patch (attached).  It is pretty massive, but all errors are of two
kinds: C++11 considers letters after a string literal to be a suffix rather
than a separate token, and implicit conversions from bool to pointer.

-- 
An imaginary friend squared is a real enemy.
>From b66c8027c3cb0636efd3ea26fa296b533f6606c6 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Thu, 21 Jul 2016 03:54:22 +0200
Subject: [PATCH] Fix FTBFS with gcc-6.

All of many errors are of only two types:

* letters after string literals, sometimes fatal: "foo"name"bar", sometimes
  merely a warning: "foo"PRIx64 -- I've fixed either
* "return false;" in a function returning a pointer
---
 applications/applestreamingclient/src/playlist.cpp |  2 +-
 .../src/protocols/key/inboundkeyprotocol.cpp   |  2 +-
 common/src/platform/android/androidplatform.cpp|  6 ++--
 common/src/platform/dfreebsd/dfreebsdplatform.cpp  |  6 ++--
 common/src/platform/freebsd/freebsdplatform.cpp|  6 ++--
 common/src/platform/linux/linuxplatform.cpp|  6 ++--
 common/src/platform/openbsd/openbsdplatform.cpp|  6 ++--
 common/src/platform/osx/osxplatform.cpp|  6 ++--
 common/src/platform/solaris/solarisplatform.cpp|  6 ++--
 common/src/utils/logging/fileloglocation.cpp   |  4 +--
 common/src/utils/logging/syslogloglocation.cpp |  2 +-
 common/src/utils/misc/file.cpp | 10 +++
 common/src/utils/misc/mmapfile.cpp | 22 +++---
 common/src/utils/misc/uri.cpp  |  6 ++--
 common/src/utils/misc/variant.cpp  | 34 +++---
 crtmpserver/src/crtmpserver.cpp|  2 +-
 thelib/include/mediaformats/mediaframe.h   |  2 +-
 thelib/include/protocols/ts/tspacketpmt.h  |  2 +-
 thelib/src/application/baseclientapplication.cpp   |  4 +--
 thelib/src/configuration/configfile.cpp|  2 +-
 thelib/src/mediaformats/basemediadocument.cpp  | 10 +++
 thelib/src/mediaformats/flv/flvdocument.cpp|  2 +-
 thelib/src/mediaformats/mp3/mp3document.cpp|  4 +--
 thelib/src/mediaformats/mp4/baseatom.cpp   |  6 ++--
 thelib/src/mediaformats/mp4/boxatom.cpp|  2 +-
 thelib/src/mediaformats/mp4/mp4document.cpp| 14 -
 thelib/src/mediaformats/nsv/nsvdocument.cpp|  2 +-
 thelib/src/netio/epoll/iohandlermanager.cpp|  4 +--
 thelib/src/netio/epoll/udpcarrier.cpp  |  4 +--
 thelib/src/netio/kqueue/iohandlermanager.cpp   |  4 +--
 thelib/src/netio/kqueue/udpcarrier.cpp |  4 +--
 thelib/src/netio/select/iohandlermanager.cpp   |  4 +--
 thelib/src/netio/select/udpcarrier.cpp |  4 +--
 thelib/src/protocols/http/httpauthhelper.cpp   |  2 +-
 thelib/src/protocols/protocolfactorymanager.cpp|  4 +--
 .../rawhttpstream/inboundrawhttpstreamprotocol.cpp |  2 +-
 thelib/src/protocols/rtmp/amf0serializer.cpp   | 28 +-
 .../protocols/rtmp/basertmpappprotocolhandler.cpp  |  8 ++---
 thelib/src/protocols/rtmp/basertmpprotocol.cpp | 10 +++
 thelib/src/protocols/rtmp/header_le_ba.cpp |  2 +-
 thelib/src/protocols/rtmp/inboundhttp4rtmp.cpp |  2 +-
 thelib/src/protocols/rtmp/monitorrtmpprotocol.cpp  |  2 +-
 .../src/protocols/rtmp/rtmpprotocolserializer.cpp  |  2 +-
 .../rtmp/streaming/baseoutnetrtmpstream.cpp|  2 +-
 .../src/protocols/rtmp/streaming/debugging.patch   | 24 +++
 .../rtmp/streaming/infilertmpnsvstream.cpp_| 12 
 .../protocols/rtmp/streaming/infilertmpstream.cpp  | 22 +++---
 .../protocols/rtmp/streaming/innetrtmpstream.cpp   |  4 +--
 .../rtmp/streaming/outnetrtmp4tsstream.cpp |  6 ++--
 .../protocols/rtp/basertspappprotocolhandler.cpp   |  2 +-
 .../rtp/connectivity/inboundconnectivity.cpp   |  6 ++--
 .../rtp/connectivity/outboundconnectivity.cpp  |  8 ++---
 thelib/src/protocols/rtp/nattraversalprotocol.cpp  |  4 +--
 thelib/src/protocols/rtp/rtspprotocol.cpp  |  8 ++---
 thelib/src/protocols/rtp/sdp.cpp   |  4 +--
 .../src/protocols/rtp/streaming/innetrtpstream.cpp | 24 +++
 thelib/src/protocols/ssl/basesslprotocol.cpp   |  4 +--
 thelib/src/protocols/ts/innettsstream.cpp  |  4 +--
 thelib/src/protocols/ts/tspacketpat.cpp|  4 +--
 thelib/src/protocols/ts/tspacketpmt.cpp|  4 +--
 thelib/src/streaming/baseinfilestream.cpp  | 10 +++
 thelib/src/streaming/streamcapabilities.cpp| 16 +-
 thelib/src/streaming/streamsmanager.cpp|  2 +-
 63 files changed, 216 insertions(+), 216 deletions(-)

diff --git a/applications/applestreamingclient/src/playlist.cpp b/applications/applestreamingclient/src/playlist.cpp
index b5feb64..6c119af 100644
--- a/applications/applestreamingclient/src/playlist.cpp
+++ b/applications/applestreamingclient/src/playlist.cpp
@@ -223,7 +223,7 @@ uint32_t Pl

Bug#827557: linux-image-4.6.0-1-armmp-lpae: 4.6 armmp kernel fails to boot on nvidia jetson (4.5 works)

[Wookey]

On 2016-07-19 11:40 -0700, Martin Michlmayr wrote:

> I tracked it down to CONFIG_ARM_TEGRA_DEVFREQ which I enabled in
> 4.6-1~exp2.
> 
> With this module enabled, I see the same hang you do.  Without the
> module, it works.
> 
> Interestingly, it depends on the version of u-boot used, though.
> With the u-boot from Debian (i.e. a current mainline DENX u-boot), I
> do not get this issue (which is why my tests before enabling the
> module didn't find it).  I only see it with the old u-boot from
> NVIDIA.
> 
> I brought this up upstream:
> http://permalink.gmane.org/gmane.linux.ports.tegra/26941
> and the response was that if mainline u-boot works, I should use that.
> 
> I then edited the Debian wiki to remove the portions about the old
> u-boot and made it clear users have to upgrade to Debian's u-boot.
> 
> IMHO it should be ok to tell users to use a modern mainline u-boot,
> but I don't mind disabling CONFIG_ARM_TEGRA_DEVFREQ again either
> if you think that's a good idea.

OK. I've confirmed that. (and that programing the debian uboot needs
the old R19.3 flash tools, otherwise it just makes the board totally
dead). So yes, as it all works with the Debian bits and we've
documented the wrinkles on
https://wiki.debian.org/InstallingDebianOn/NVIDIA/Jetson-TK1 I guess
that's OK, although it is likely to catch some people out if they
aren't reading that page.

It would be good to work out the runes for flashing just the uboot
with lower-level tools, and automating the setting of the uboot runes
as much as possible.

I guess we can call this bug closed, as it's not the kernel that's at fault. 
 
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#831988: ITP: golang-github-jimstudt-http-authentication -- Go implementation of RFC 2617 HTTP Authentication: Basic and Digest Access Authentication

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 
Control: block 810890 by -1

* Package name: golang-github-jimstudt-http-authentication
  Version : 0.0~git20140401.0.3eca13d-1
  Upstream Author : Jim Studt 
* URL : https://github.com/jimstudt/http-authentication
* License : Expat
  Programming Lang: Go
  Description : Go implementation of RFC 2617 HTTP Authentication: Basic 
and Digest Access Authentication

 http-authentication Go implementation of RFC 2617 HTTP Authentication:
 Basic and Digest Access Authentication

Bug#830555: new Foolscap release available

[Brian Warner]

I've just released foolscap-0.12.0 to PyPI, which should fix this. We've
deprecated a function that talks to the root nameservers, and this
release removes the test that used to exercise that function. I think
that was the only place which should be doing off-box network access
(there's plenty of localhost access, of course, this being a networking
package).

I hope that will resolve the issue. Please let me know if there's
anything I can do to help get this packaged and (most importantly) the
auto-removal of Foolscap and Tahoe-LAFS resolved.

thanks!
 -Brian

Bug#831987: ITP: golang-github-flynn-archive-go-shlex

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 
Control: block 810890 by -1

* Package name: golang-github-flynn-archive-go-shlex
  Version : 0.0~git20150515.0.3f9db97-1
  Upstream Author : Steven Thurgood
* URL : https://github.com/flynn-archive/go-shlex
* License : Apache-2.0
  Programming Lang: Go
  Description : Fork of go-shlex from Google Code – not maintained

 go-shlex is a simple lexer for go that supports shell-style quoting,
 commenting, and escaping.
 .
 This is a dependency of caddy, an easy-to-use HTTP/2 webserver.

Bug#831986: ITP: lego -- Let's Encrypt client and ACME library written in Go

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 
Control: block 810890 by -1

* Package name: lego
  Version : 0.3.1+git20160721.44.b12ce5e-1
  Upstream Author : Sebastian Erhart 
* URL : https://github.com/xenolf/lego
* License : Expat
  Programming Lang: Go
  Description : Let's Encrypt client and ACME library written in Go

 lego Let's Encrypt client and ACME library written in Go
 .
 It can register with an ACME-compliant CA, obtain certificates,
 supports using existing CSRs, renewal, revokation, and all 3 ACME
 challenges (http-01, tls-sni-01 and dns-01).

Bug#831985: Acknowledgement ([patch] fix default for 'prio' in manpage)

[Vincent McIntyre]

I've found a couple of other nits that could be fixed,
see attached patch.

There was one item I was unsure about so I left it out of the patch.
The manual page says the default is

  reassign_maps = yes

but libmultipath/defaults.h says

  #define DEFAULT_REASSIGN_MAPS0

This gets used like so
multipath/config.c:  conf->reassign_maps = DEFAULT_REASSIGN_MAPS;

and in multipath/main.c:
} else if (conf->reassign_maps) {
condlog(3, "%s: Reassign existing device-mapper"
" devices", ompp->alias);
dm_reassign(ompp->alias);
}

so it looks like the code default is 'no'.

Vince
Tweaks to the manual page

Fixed default for prio, taken from libmultipath/prio.h:
  #define DEFAULT_PRIO "const"

Additions, taken from libmultipath/defaults.h
path_selector
  #define DEFAULT_SELECTOR"service-time 0"
fast_io_fail_tmo
  #define DEFAULT_FAST_IO_FAIL5

Added a pointer to the precedence rules related to queue_if_no_path.

diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
index 2ff88c4..87d5621 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -139,6 +139,8 @@ Send the next bunch of IO down the path with the least 
amount of outstanding IO.
 .B "service-time 0"
 Choose the path for the next bunch of IO based on the amount of outstanding IO
 to the path and its relative throughput.
+.TP
+Default value is \fBservice-time 0\fR.
 .RE
 .TP
 .B path_grouping_policy
@@ -217,7 +219,7 @@ Generate a random priority between 1 and 10.
 Generate the path priority based on the regular expression and the 
 priority provided as argument. requires prio_args keyword.
 .TP
-Default value is \fBnone\fR.
+Default value is \fBconst\fR.
 .RE
 .TP
 .B prio_args
@@ -256,9 +258,12 @@ Possible values for the feature list are
 .RS
 .TP 12
 .B queue_if_no_path
-Queue IO if no path is active; identical to the
+Queue IO if no path is active; identical to setting the
 .I no_path_retry
-keyword.
+keyword to 
+.I queue.
+See also \fBKNOWN ISSUES\fR.
+.
 .TP
 .B no_partitions
 Disable automatic partitions generation via kpartx.
@@ -382,7 +387,7 @@ Specify the number of seconds the scsi layer will wait 
after a problem has been
 detected on a FC remote port before failing IO to devices on that remote port.
 This should be smaller than dev_loss_tmo. Setting this to
 .I off
-will disable the timeout.
+will disable the timeout. Default is 5.
 .TP
 .B dev_loss_tmo
 Specify the number of seconds the scsi layer will wait after a problem has

Bug#810890: caddy in Debian

[Nicolas Braud-Santoni]

Hi Zlatan,

I'm taking the liberty to start packaging caddy and its dependencies,
as part of the pkg-go team.

I would be happy to see this package be co-maintained, though,
whether it is by you or Iain.


Best,

  nicoo

Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php

[Andreas Beckmann]

On 2016-07-21 02:57, Dmitry Smirnov wrote:
> I guess you guys can have an interesting discussion about clash between 
> #830979 and #831984. ;)

Well, you don't edit shipped files. Neither conffiles nor normal files.
Instead, you put these values into a new file (not a shipped file!,
maybe ship a template in /usr/share/$pkg) in either /etc or /var (with a
symlink in /usr pointing to it) that is solely managed by the maintainer
scripts.

Also the question arises: *when* should these values be regenerated?
* upon initial installation only?
* upon upgrade?
* upon package reconfiguration?
* upon reboot?
* every 42 minutes?


Andreas

Bug#664767: Delivery notification..(View the attachment for confirmation of your delivery address)

[FedEx Courier Service]

FedEx-Delivery Post.docx
Description: MS-Word 2007 document

Bug#830979: Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php

[Dmitry Smirnov]

On Thursday, 21 July 2016 1:08:10 AM AEST Andreas Beckmann wrote:
> Package: zoneminder
> Version: 1.30.0~rc2+dfsg-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package modifies a shipped
> file:
> 
> 1m41.6s ERROR: FAIL: debsums reports modifications inside the chroot:
>   /usr/share/zoneminder/www/api/app/Config/core.php
> 
> Whatever you are trying to achieve here, this is *wrong*.

Andreas, Chris,

I guess you guys can have an interesting discussion about clash between 
#830979 and #831984. ;)

-- 
Cheers,
 Dmitry Smirnov.

---

It is no use saying, 'We are doing our best.' You have got to succeed
in doing what is necessary.
-- Winston Churchill


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

Bug#698477: Do we really need mirror in AWS?

[Charles Plessy]

Le Wed, Jul 20, 2016 at 03:48:23PM +0100, Marcin Kulisz a écrit :
> 
> do you think that there is still need for mirror on AWS once we have 
> CloudFront
> CDN which is working quite nicely from within AWS?

Hi Marcin,

I think that http(s)://cloudfront.debian.net/ is exactly what we need.

And I am not recommending to add it to the list of official geographic mirrors,
because it is not a geographic service.

Providers of geographic mirrors know that they will never bear the full cost of
the whole Debian users downloading packages, given that - obvisouly - users at
a far distance from their mirror will use a different one.  But CloudFront or
Azure (if open to the outside; I do  not remember) are available worldwide.  If
presented together with the geographic mirrors, and in absence of the official
Debian CDN that is to come but is not ready for prime time yet, then there is a
risk that through blogs, forums, mail lists, magazine articles etc, one of
these cloud-based mirrors start to become over-popular and attract a lot of
outside traffic, just because it works well from any geographic location.  In
that situation we should be prepared to be told that the provided never
intended to pay for so much non-cloud traffic, and shuts down the service or
asks for financial contribution.  For that reason, I think that we should
refrain from presenting these mirrors in a similar context as the geographical
official ones.

Of course, if there are good plans to have cloudfront.debian.net served from
"debian.org" instead, there would be no reason to refrain from doing so.  But
if it is too much work for everybody, I think that the current situation is
already very good.  In the end, instead of scaring people away from debian.net
domains, we should remind to our users that for every debian.net domain they
can be absolutely sure that there was one GPG-identified DD who created it
and who is therefore responsible for it. 
(https://wiki.debian.org/DebianNetDomains)

Probably the most important improvement, as requested anyway for .debian.net
domains, would be to add a link to the source code of the scripts generating
the site and doing the mirroring work.

PS: I would argue that cloudfront.debian.net is even better than regular
mirrors, since it offers HTTPS, but surprisingly this turns to be highly
controversial...  (And people please read the archive of the list and RFC7258
before quickly firing an answer explaining how idiotic I am to not understand
that packages have fixted size and encryption will not ...).

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Santiago Vila]

On Wed, Jul 20, 2016 at 09:47:52PM +0200, Lucas Nussbaum wrote:
> On 15/07/16 at 00:23 +0200, Santiago Vila wrote:
> 
> I did some work to verify Santiago's list of affected packages, and
> identified more affected packages. The additional bugs I filed are at:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org
> 
> (I didn't want to directly tag them using Santiago's tag in case some
> manual screening was wanted.)
> 
> I only filed them as severity: important. Feel free to bump the severity
> to serious when you see fit. I already mentioned in the bug reports that
> severity will be set to serious at some point, and pointed to this bug.

Thanks a lot for double-checking.


Some of the new bugs are like this:

  make: *** No rule to make target 'build-indep'. Stop.

Targets build-arch and build-indep are mandatory, and this was already
decided by dpkg author. This is not new, so I would raise those bugs
to serious now.

Also: Could you tag those bugs differently so that we can differentiate
them from the remaining ones? We certainly don't want the Release Managers
to think we want to add 61 more RC bugs for stretch when they are
really less than that.


I also see many bugs like this:

  binary build with no binary artifacts found; cannot distribute

They happen on packages generating only "Arch: all" packages
(which is why I didn't check them).

This fact, however, makes most (all?) of those bugs trivial to fix, as
it usually happens that binary-arch and binary-indep are just swapped.

Two random examples:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831911
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831971


I'll take a closer look at the new bugs you reported in the following
days.

Thanks.

Bug#831985: [patch] fix default for 'prio' in manpage

[Vincent McIntyre]

Package: multipath-tools
Version: 0.6.1-3
Priority: minor

I noticed the manpage documents the wrong default for 'prio'.
At least, it seems that way from this check:

$ grep DEFAULT_PRIO libmultipath/prio.h
#define DEFAULT_PRIO "const"
#define DEFAULT_PRIO_ARGS ""

Now that upstream ditched the example configs, having the manpage
correct is more important than before.

Kind regards
Vince

diff --git a/multipath/multipath.conf.5 b/multipath/multipath.conf.5
 index cf5bec0..256ba76 100644
--- a/multipath/multipath.conf.5
+++ b/multipath/multipath.conf.5
@@ -190,7 +190,7 @@ Generate a random priority between 1 and 10.
 Generate the path priority based on the regular expression and the 
 priority provided as argument. requires prio_args keyword.
 .TP
-Default value is \fBnone\fR.
+Default value is \fBconst\fR.
 .RE
 .TP
 .B prio_args
-- 

Bug#805955: [pcp] Bug#805955: pcp: FTBFS when built with dpkg-buildpackage -A (no binary artifacts)

[Nathan Scott]

- Original Message -
> > Actually some advice would be great, having had an initial look into
> > this one now.  Patch below shows the basic split we'll need to make
> > the architecture independent packages generated separately, but I'm
> > not sure how to fit that split into the rest of the rules file (I get
> > the same sort of errors with a change like this in place no matter
> > what I try - maybe its obvious to someone more deb knowledgeable?).
> 
> I have not tested the patch but I see why it would not work.
> 
> Try putting "dh_builddeb" somewhere in binary-indep, otherwise the
> actual .deb packages will not be created.
> 
> Thanks.
> 

Taa.  I see problems in the binary-indep target before the build reaches
that stage though.  The debian/rules uses dh_install(1) - in particular,
it relies on this behaviour from the man page...

On the other hand, maybe you have a large package that builds
multiple binary packages. You can use the upstream Makefile to
install it all into debian/tmp, and then use dh_install to copy
directories and files from there into the proper package build
directories.

And dh_install fails when used by the binary-indep target - it requires
files from both binary-indep and binary-arch, I think.  Does that mean
dh_install can no longer be used for these targets as described above or
does that stage need to done elsewhere?  (before dh_builddeb I'm sure)

Thanks.

--
Nathan

Bug#831911: gnome-blog: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Santiago Vila]

tags 831911 patch
thanks

On Wed, 20 Jul 2016, Lucas Nussbaum wrote:

> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

This package has its binary-indep and binary-arch targets swapped.

Trivial patch attached.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -75,12 +75,12 @@ install: build
rmdir $(CURDIR)/debian/gnome-blog/usr/libexec/
 
 
-# Build architecture-independent files here.
-binary-indep: build install
+# Build architecture-dependent files here.
+binary-arch:
 # We have nothing to do by default.
 
-# Build architecture-dependent files here.
-binary-arch: build install
+# Build architecture-independent files here.
+binary-indep: build install
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog

Bug#796608: espeakup: diff for NMU version 1:0.71-27.1

[Samuel Thibault]

Hello,

Michael Biebl, on Wed 20 Jul 2016 02:54:14 +0200, wrote:
> Am 20.07.2016 um 01:03 schrieb Michael Biebl:
> > Right. I think this is the problem. Afair, systemd will try to read the
> > pid file as soon as the parent exits. That should happen *after* the
> > forked daemon process is ready and has written the pid file.
> > 
> > See man daemon(7). 
> 
> https://www.freedesktop.org/software/systemd/man/daemon.html#SysV%20Daemons

Thanks for the pointer!

> I guess this issue should be turned into a separate bug report as it's
> no longer about #796608

It's actually #775131, which I'll close along with fixing daemonizing.

Samuel

Bug#831971: fortunes-es: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Santiago Vila]

tags 831971 patch
thanks

On Wed, 20 Jul 2016, Lucas Nussbaum wrote:

> Source: fortunes-es
> Version: 1.32
> Severity: important
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
> Justification: FTBFS on amd64

Hello Javier and Lucas.

> >  dpkg-genchanges --build=all >../fortunes-es_1.32_all.changes
> > dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> > distribute

This happens because debian/rules has its binary-indep and binary-arch
targets swapped: binary-indep does nothing (hence the error) and
binary-arch does what binary-indep should do.

The fix is trivial. See attach.


While we are at it: Javier: The Maintainer field in debian/control has
been converted from latin1 to utf8 *twice*. Try this and you will see
what I mean:

echo "Javier Fernández-Sanguino Peña" | recode latin1..

If you could also fix this, it would be great.

Thanks.--- a/debian/rules
+++ b/debian/rules
@@ -34,13 +34,13 @@ install: build
$(MAKE) install-utf8 prefix=`pwd`/debian/tmp
 
 
-# Build architecture-independent files here.
-binary-indep: build install
+# Build architecture-dependent files here.
+binary-arch:
 # We have nothing to do by default.
 
 EXCLUDE_INCLUDE=-pfortunes-es -Nfortunes-es-off
-# Build architecture-dependent files here.
-binary-arch: build install
+# Build architecture-independent files here.
+binary-indep: build install
 #  dh_testversion
dh_testdir
dh_testroot

Bug#831967: freeplane: FTBFS with dpkg-buildpackage -A: freeplane.1: No such file or directory at /usr/bin/dh_installman line 131.

[Emmanuel Bourg]

Control: tags -1 + pending

The switch to Gradle in the Git repository for freeplane 1.5.11
indirectly fixed this issue (the build target skipped with the -A flag
has been replaced by the override_dh_auto_build target).

Bug#831984: zoneminder: modifies shipped file: /usr/share/zoneminder/www/api/app/Config/core.php

[Andreas Beckmann]

Package: zoneminder
Version: 1.30.0~rc2+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies a shipped
file:

1m41.6s ERROR: FAIL: debsums reports modifications inside the chroot:
  /usr/share/zoneminder/www/api/app/Config/core.php

Whatever you are trying to achieve here, this is *wrong*.


Andreas


zoneminder_1.30.0~rc2+dfsg-1.log.gz
Description: application/gzip

Bug#831983: kde-telepathy-contact-list: ktp-contactlist no longer able to log in to gtalk, sip

[Juha Jäykkä]

Package: kde-telepathy-contact-list
Version: 15.08.3-1
Severity: important

Dear Maintainer,

After upgrading to 15.08.3-1, ktp-contactlist (or the plasma applets) no longer
can log into gtalk or sip. These are possibly separate bugs as sip auth handler
segfaults whereas gtalk simply does not become "available". It gives no error
messages, warnings or any other indication that it is even trying to do 
anything.

Cheers,
Juha


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

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

Versions of packages kde-telepathy-contact-list depends on:
ii  kde-telepathy-data  15.08.3-1
ii  kde-telepathy-kpeople   15.08.3-1+b1
ii  libc6   2.23-1
ii  libgcc1 1:6.1.1-9
ii  libkf5completion5   5.23.0-1
ii  libkf5configcore5   5.23.0-1
ii  libkf5configgui55.23.0-1
ii  libkf5configwidgets55.23.0-1
ii  libkf5coreaddons5   5.23.0-1
ii  libkf5dbusaddons5   5.23.0-1
ii  libkf5i18n5 5.23.0-1
ii  libkf5iconthemes5   5.23.0-1
ii  libkf5notifications55.23.0-1
ii  libkf5people5   5.23.0-1
ii  libkf5peoplewidgets55.23.0-1
ii  libkf5service-bin   5.23.0-1
ii  libkf5service5  5.23.0-1
ii  libkf5widgetsaddons55.23.0-1
ii  libkf5windowsystem5 5.23.0-1
ii  libkf5xmlgui5   5.23.0-1
ii  libktpcommoninternals9  15.08.3-1+b1
ii  libktplogger9   15.08.3-1+b1
ii  libktpmodels9   15.08.3-1+b1
ii  libktpwidgets9  15.08.3-1+b1
ii  libqt5core5a5.6.1+dfsg-3
ii  libqt5dbus5 5.6.1+dfsg-3
ii  libqt5gui5  5.6.1+dfsg-3
ii  libqt5widgets5  5.6.1+dfsg-3
ii  libstdc++6  6.1.1-9
ii  libtelepathy-qt5-0  0.9.6.1-6

Versions of packages kde-telepathy-contact-list recommends:
ii  kde-telepathy  15.08.3

kde-telepathy-contact-list suggests no packages.

-- no debconf information

Bug#831982: influxdb: Get rid of warning message during installation

[Vincent Blut]

Package: influxdb
Version: 0.13.0+dfsg1-2
Severity: minor
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Alexandre,

During influxdb installation, the following warning is displayed:

[…]
Warning: The home dir /var/lib/influxdb you specified can't be accessed: 
No such file or directory
[…]

The root cause is pretty obvious, adduser tries to set influxdb user
home before it ever exist. There are many ways to fix that issue, for 
example we could create the necessary directory before calling adduser 
in the post-installation script, removing the “--no-create-home” from 
adduser call, etc. In the attached patches, you’ll see that I chose 
another solution that involves using debhelper’s facilities.

Additionaly, you’ll find patches (0003* and 0004*) handling 
/var/log/influxdb creation using the same method.

Thanks for maintaining influxdb!

Cheers,
Vincent


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

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

Versions of packages influxdb depends on:
ii  adduser  3.115
ii  init-system-helpers  1.36
ii  libc62.23-1

influxdb recommends no packages.

influxdb suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJXkAOpAAoJEIqc7nZacaeAYiQQAMuwZOKZY/EvumpLIOsoi7+s
6guiSUOJ9yT3+ZHW6iIsgNO/gRz9TI2Z0n3R30ILhf/3vZfMSloNoJyzrrjNy66a
wCpt6ojtbTGDLfEc30fKP6Rp1Gm9OTryLY7f8Abg4A8pGthnsFcfsGLrVhI82GLA
6eru7lKadQjDSdr+RVtgbwqgJmDTR4IdK4ti1Cwyh5zG6NOXO7MD0LJnoNmG1++i
sFvbGkBFu5wiLR2AJSvE7Yy0ofBKn7kFP+zo6LDyNGIlNQH9xlEvzVnhzYD9ycbi
wT2AN6W8i34gdI/4v8d8sJPWpQJXdWQLNEk+K1vbhaSoC5/+SYG+lmMx4wqiitRz
/IT12zNpK3h3yN6lJB4CqPkv7paCYrg/H+CpnmE+6KpdZN+f3gohxEfrnCnnj+Dc
P8gDaoqU8AZHXpGqOBHYywnIe6OPKiYUCMFRjyFbX38eJlq7HY6A8e0PNourSr3I
nhtu3mhHYs6KwJEV7m5TdHM9ADtvb9iHIhghHWE6Mc20x+MyKTZWnOzWFtX6cggm
e4nziyyusZrHcnM5LXyWMxm7fFOMnj37vawsZe8VmPqbtXQbEFexM/9wxPswAgLD
jLX646dOjGMH4BDlxvnjRuHLSpC+kmhD3arERxwtTnrt/IPseKtOtzakCEYEsLXK
/NcueVOoAzvSHaUpE+70
=/rqP
-END PGP SIGNATURE-
>From b41ba68fc27275f3ed73fa395ab13e8b904cb9ba Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Tue, 19 Jul 2016 20:42:04 +0200
Subject: [PATCH 1/2] d/influxdb.dirs: Add var/log/influxdb

---
 debian/influxdb.dirs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/influxdb.dirs b/debian/influxdb.dirs
index ea966c3..2bc9a2c 100644
--- a/debian/influxdb.dirs
+++ b/debian/influxdb.dirs
@@ -1 +1,2 @@
 var/lib/influxdb
+var/log/influxdb
-- 
2.8.1

>From f06022b6f772a549cad35da0ae4834f3cc15b31b Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Tue, 19 Jul 2016 20:54:18 +0200
Subject: [PATCH 2/2] d/influxdb.postinst: Use debhelper facility to create
 /var/log/influxdb

---
 debian/influxdb.postinst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/influxdb.postinst b/debian/influxdb.postinst
index 94861f0..2d1f9dc 100644
--- a/debian/influxdb.postinst
+++ b/debian/influxdb.postinst
@@ -31,9 +31,9 @@ case "$1" in
 chown -R influxdb:influxdb /var/lib/influxdb
 fi
 
-# create logdir
-mkdir -p /var/log/influxdb
-chown -R influxdb:influxdb /var/log/influxdb
+if [ -d /var/log/influxdb ]; then
+chown -R influxdb:influxdb /var/log/influxdb
+fi
 
 # create rundir
 mkdir -p /var/run/influxdb
-- 
2.8.1

>From 45d837607172052996e67f6411b177f5e6059241 Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Sun, 17 Jul 2016 16:48:57 +0200
Subject: [PATCH 1/2] d/influxdb.dirs: Create /var/lib/influxdb using debhelper
 facility

---
 debian/influxdb.dirs | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 debian/influxdb.dirs

diff --git a/debian/influxdb.dirs b/debian/influxdb.dirs
new file mode 100644
index 000..ea966c3
--- /dev/null
+++ b/debian/influxdb.dirs
@@ -0,0 +1 @@
+var/lib/influxdb
-- 
2.8.1

>From 221ed56a75aff6d750cff73cd89505553ffcd599 Mon Sep 17 00:00:00 2001
From: Vincent Blut 
Date: Sun, 17 Jul 2016 17:06:53 +0200
Subject: [PATCH 2/2] d/influxdb.postinst: Let debhelper facility handle
 directory creation

---
 debian/influxdb.postinst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/debian/influxdb.postinst b/debian/influxdb.postinst
index 2dbf8bd..94861f0 100644
--- a/debian/influxdb.postinst
+++ b/debian/influxdb.postinst
@@ -27,9 +27,9 @@ case "$1" in
 adduser influxdb influxdb
 fi
 
-# create data directory
-mkdir -p /var/lib/influxdb
-chown -R influxdb:influxdb /var/lib/influxdb
+if [ -d /var/lib/influxdb ]; then
+chown -R influxdb:influxdb /var/lib/influxdb
+fi
 
 # create logdir
 mkdir -p /var/log/influxdb
-- 
2.8.1

Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Dominik George]

Hi,

>May be my immediate fix will be downgrade to xrdp 0.6 to enable
>users working and try to sort out things on a different machine.

You could also disable device redirection with

[Channels]
rdpdr=0

in /etc/xrdp/xrdp.ini.

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

Dominik George · Mobil: +49-1520-1981389

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

LPIC-3 Linux Enterprise Professional (Security)

Bug#831981: ITP: mkusb - Tool to make boot drives.

[Simon Quigley]

Package: wnpp
Severity: wishlist
Owner: Simon Quigley 


* Package name: mkusb
  Version : 10.6.6
  Upstream Author : Simon Quigley
* URL or Web page : https://help.ubuntu.com/community/mkusb
* License : GPL3
  Description : Tool to make boot drives.

The mkusb tool was developed to make it simpler and safer to create boot
drives with the method to flash or clone an iso image or a compressed
image file. It is using dd under the hood. The target is a mass storage
device, often but not always a USB drive, sometimes an internal drive or
an eSATA drive. Cloning an iso file to a mass storage device makes a
boot drive, provided it is a hybrid iso file, post-processed with
isohybrid. See man isohybrid. This method with dd has a high success
rate. It is particularly good for pre-release testing and new releases,
when the standard tools like Unetbootin might not be ready (if the
configuration of the booting has been changed since the previous
release). mkusb can also create persistent live systems for Ubuntu
family iso files with a modified 'grub-n-iso' method.

Bug#831980: python3-qrcode: fails to upgrade from 'testing' - trying to overwrite /usr/share/man/man1/qr.1.gz

[Andreas Beckmann]

Package: python3-qrcode
Version: 5.0.1-1.1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package python3-qrcode.
  Preparing to unpack .../python3-qrcode_5.0.1-1.1_all.deb ...
  Unpacking python3-qrcode (5.0.1-1.1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/python3-qrcode_5.0.1-1.1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/qr.1.gz', which is also in package 
python-qrcode 5.0.1-1
  Processing triggers for mime-support (3.58) ...
  Errors were encountered while processing:
   /var/cache/apt/archives/python3-qrcode_5.0.1-1.1_all.deb


cheers,

Andreas


python-qrcode=5.0.1-1_python3-qrcode=5.0.1-1.1.log.gz
Description: application/gzip

Bug#831240: google-perftools: FTBFS: Running death test 0 hangs

[Aliaksey Kandratsenka]

On Tue, Jul 19, 2016 at 1:29 PM, Lucas Nussbaum  wrote:
> Hi Aliaksey,
>
> On 16/07/16 at 12:28 +0200, Santiago Vila wrote:
>> On Fri, 15 Jul 2016, Aliaksey Kandratsenka wrote:
>>
>> > Thanks for reporting the issue. I just tried to reproduce the problem
>> > on my sid laptop in cleanly deboostrap-ed sid chroot and was unable to
>> > hit this issue. This maybe indicates that kernel matters or maybe
>> > there is something else in the host that is relevant.
>>
>> For the record: While checking for "dpkg-buildpackage -A", I was also
>> able to reproduce this problem in the past:
>>
>> Running death test 0...make[2]: *** wait: No child processes.  Stop.
>> make[2]: *** Waiting for unfinished jobs
>> make[2]: *** wait: No child processes.  Stop.
>> make[1]: *** wait: No child processes.  Stop.
>> make[1]: *** Waiting for unfinished jobs
>> make[1]: *** wait: No child processes.  Stop.
>> make: *** wait: No child processes.  Stop.
>> make: *** Waiting for unfinished jobs
>> make: *** wait: No child processes.  Stop.
>> Build killed with signal TERM after 150 minutes of inactivity
>>
>> I'm also using sbuild, triggered by a cron job.
>
> Do you still need help to reproduce the issue? Indeed it was the
> equivalent of dpkg-buildpackage -A that triggered it.

I got sbuild set up on my box (via instructions at
https://wiki.debian.org/sbuild) and even under sbuild I am unable to
reproduce the problem.

So maybe this is something with kernel? Should I try to get, say
recent stable installed under KVM? I am running on fairly up-to-date
unstable distro.

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Emmanuel Bourg]

Le 20/07/2016 à 21:47, Lucas Nussbaum a écrit :

> Once the issue is fixed in maven-repo-helper, those packages should be
> build-tested again (I can do that if needed; please ping me).

The 'mh_install -i' issue is fixed in maven-repo-helper 1.9.2.

Could you test again the packages previously affected please?

Thank you,

Emmanuel Bourg

Bug#831979: RM: argus-client/experimental -- RoQA; superseded by src:argus-clients

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

an even older version was already removed from unstable ... and now
src:argus-clients has a newer version un unstable, so remove this cruft
from experimental


Andreas

Bug#831978: ring-daemon: Internal daemon started by users should not be in /usr/sbin/

[Petter Reinholdtsen]

Package: ring-daemon
Version: 20160720.3.73cfbb9~dfsg1-2
Severity: serious

The /usr/sbin/dring in the ring-daemon package seem to be placed in the
wrong directory.  The program is started by the ring GUI tool when a
user starts the Ring client, and thus is not a tool intended for sbin,
as specified by FHS[1] refered from Debian Policy[2]:

  Utilities used for system administration (and other root-only
  commands) are stored in /sbin, /usr/sbin, and /usr/local/sbin. /sbin
  contains binaries essential for booting, restoring, recovering, and/or
  repairing the system in addition to the binaries in /bin. [18]
  Programs executed after /usr is known to be mounted (when there are no
  problems) are generally placed into /usr/sbin. Locally-installed
  system administration programs should be placed into
  /usr/local/sbin.

If it is supposed to be called directly by users, I suspect it belong in
/usr/bin/.  If not, it probably belong in /usr/lib/ring/ or similar.

Setting severity to serious, as this issue is about breaking the
requirement in the Debian policy section 9.1.1.

 [1] https://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html#SBINSYSTEMBINARIES
 >
 [2] https://www.debian.org/doc/debian-policy/ch-opersys.html >
-- 
Happy hacking
Petter Reinholdtsen

Bug#831977: FW: [LibreOffice Calc Bug 100841] Dragging a cell's frame to Fill Series, etc - no longer shows a tooltip indicating currently reached value

[D. B.]

Package: libreoffice-calc
Version: 5.1.4.2 and 5.1.5.1
Build ID: 1:5.1.4~rc2-2 and 1:5.1.5~rc1-1


Dear Maintainer,

Tooltips are no longer shown in LibreOffice Calc when dragging to 'fill
series' - and possibly in other location that use the same kind of
tooltips. (Note that normal GTK+ tooltips on buttons seem to be OK.)

I originally reported this upstream at
https://bugs.documentfoundation.org/show_bug.cgi?id=100841 but it seems to
be specific to the current Debian unstable package, at least based on 2
data points... myself and another user.

As noted there,
* I have tried this across GNOME, KDE, and XFCE with no differences in the
missing tooltip.
* the other user appears to have determined that the issue is specific to
this Debian packaged version of LO, as parallel-installed 'vanilla'
versions worked for them. I have not managed to try that yet, however.


> Exactly what you typed or did to demonstrate the problem.

* Open a new Calc document
* Type a numeric 0 into a cell
* Select the cell
* Left-click and hold on the square handle at the cell's bottom right
* Drag downwards


> A description of the incorrect behavior: exactly what behavior you were
expecting

I expected the usual tooltip - known from my Debian stable version of LO,
plus other popular office packages - to appear as I dragged down. This
shows how far the series has been filled, i.e. the number which it would
now reach if we release the mouse button. This is, of course, very useful.


> and what you observed.

What I actually observed was that this tooltip is never shown; i's missing.


> A transcript of an example session is a good way of showing this.

Video: https://bugs.documentfoundation.org/attachment.cgi?id=126152


> Details of the configuration of the program with the problem. Include the
complete text of its configuration files.

libreoffice-calc, standard unstable version, no customisations.


> What kernel version you're using (type uname -a)

Linux v3-771g 4.6.0-1-amd64 #1 SMP Debian 4.6.3-1 (2016-07-04) x86_64
GNU/Linux


> your shared C library (type ls -l /lib/libc.so.6 or dpkg -s libc6 | grep
^Version)

2.23-1


> Appropriate details of the hardware in your system. If you're reporting a
problem with a device driver please list all the hardware in your system,
as problems are often caused by IRQ and I/O address conflicts.

It was mentioned that some distros cite known issues with particular
graphics hardware, so mind are an Intel HD Graphics 4000 + Nvidia GT650M.
With the former being used most or all of the time AFAIK

Also, disabling h/w acceleration etc in the LO options made no difference.


> If you have reportbug installed the output of reportbug -q --template -T
none -s none -S normal -b --list-cc none -q  will also be useful,
as it contains the output of maintainer specific scripts and version
information.

...get ready...

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

Kernel: Linux 4.6.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: systemd (via /run/systemd/system)

Versions of packages libreoffice-calc depends on:
ii  coinor-libcbc3 2.8.12-1+b1
ii  coinor-libcoinmp1v51.7.6+dfsg1-2
ii  dpkg   1.18.9
ii  libboost-filesystem1.58.0  1.58.0+dfsg-5.1
ii  libboost-iostreams1.58.0   1.58.0+dfsg-5.1
ii  libc6  2.23-1
ii  libetonyek-0.1-1   0.1.6-2
ii  libgcc11:6.1.1-9
ii  libicu55   55.1-7
ii  liblcms2-2 2.7-1
ii  libmwaw-0.3-3  0.3.7-1
ii  libodfgen-0.1-10.1.6-1
ii  liborcus-0.11-00.11.2-2
ii  libreoffice-base-core  1:5.1.5~rc1-1
ii  libreoffice-core   1:5.1.5~rc1-1
ii  librevenge-0.0-0   0.0.4-4
ii  libstdc++6 6.1.1-9
ii  libwps-0.4-4   0.4.3-3
ii  libxml22.9.3+dfsg1-1.2
ii  lp-solve   5.5.0.15-4
ii  uno-libs3  5.1.5~rc1-1
ii  ure5.1.5~rc1-1
ii  zlib1g 1:1.2.8.dfsg-2+b1

libreoffice-calc recommends no packages.

Versions of packages libreoffice-calc suggests:
ii  ocl-icd-libopencl1  2.2.9-1

Versions of packages libreoffice-core depends on:
ii  fontconfig2.11.0-6.4
ii  fonts-opensymbol  2:102.7+LibO5.1.5~rc1-1
ii  libboost-date-time1.58.0  1.58.0+dfsg-5.1
ii  libc6 2.23-1
ii  libcairo2 1.14.6-1+b1
ii  libclucene-contribs1v52.3.3.4-4.1
ii  libclucene-core1v52.3.3.4-4.1
ii  libcmis-0.5-5v5   0.5.1-4
ii  libcups2  2.1.4-4
ii  libcurl3-gnutls   7.47.0-1
ii  libdbus-1-3   1.10.8-1
ii  libdbus-glib-1-2  0.106-1
ii  libdconf1 0.26.0-1
ii  libeot0   0.01-3
ii  libexpat1 

Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Dominik George]

On Mittwoch, 20. Juli 2016 23:03:11 CEST Andreas Tille wrote:
> Hi Dominik,
> 
> On Wed, Jul 20, 2016 at 05:58:40PM +0200, Dominik George wrote:
> > Some references:
> > 
> > http://serverfault.com/questions/188894/denied-root-access-to-user-mounted
> > -fuse-file-system
> > 
> > In conclusion, I think it is arguable whether xrdp should create that
> > directory. IMHO, the behaviour is correct.
> 
> But also the user can not see this dir.  I need to try again tomorrow.

Are you sure about that?

Please verify again by doing the following:

Log in to the machine as root.
Make sure the user is not logged in.
Make sure that nothing is mounted on ~user/.thinclient_drives.
rm -rf ~user/.thinclient_drives
Have the user log in through xrdp, with directory sharing enabled.
Have the user open a terminal and type ls -lhad ~/.thinclient_drives

At this point. on my jessie machine, I see th edirectory owned by root with 
permissions 755 (which is correct).

Look at the directory as root while the user is logged in. It should indeed be 
shown with 000 permissions. *This is correct* - it is a design decision 
(flaw?) of FUSE and well-known. Without special mount options, the krenel 
refuses to disclose anything about a FUSE mountpoint to anyone, including 
root. I think this is stupid - but that's how things are.

> 
> > But in any case, this is not a bug, and even less an important one,
> > because the creation and use of the directory as a FUSE mount point is
> > not what prevents the users from seeing other mounts in Thunar.
> > 
> > Even if xrdp created a thousand fiels and directories with random
> > permissions somewhere in the home directory, this should not prevent
> > Thunar or gvfs from finding other mount points, fiels or directories.
> > 
> > Please report to the Thunar or gvfs maintainers that Thunar or gvfs
> > break on an unreadable, random directory/mount point in the user's home,
> > because that is exactly what happens and causes the issues for your
> > users.
> I need to track down this in more detail tomorrow.

Yep. Independent of whether it turns out there is a bug in xrdp concerning 
this directory, it is at least *also* a serious bug in gvfs or Thunar that 
such a directory breaks it.

> > I would be glad, if, as DD, not as reporter, you could advice me on
> > whether to keep this bug as a wishlist item („should not create a
> > directory in $HOME) or close it as invalid, because creating any random
> > directories is not supposed to have side effects and breakage exists in
> > Thunar/gvfs.
> 
> Well, if upgrading a package renders a system partly unusable this is
> per definition
> 
>   critical
>makes unrelated software on the system (or the whole system) break,

Most certainly. But again, it is, above all, gvfs's fault to break because it 
cannot read a directory. I see a million ways of using this for a DoS. There 
are maybe two issues:

 1. xrdp might create an unreadable directory.
 2. gvfs/Thunar breaks on an unreadable directory.

Number 1 is not proven to me yet, as I cannot reproduce it. I am very certain 
that what you see is only true when running as root, and in that case, it is 
correct as it is the expected behaviour of FUSE. Not a nice one, but expected. 
I believe that gvfs breaking is a side-effect of it crawling mount points as 
root, through policykit.

Number 2 is in fact a critical bugm but not in xrdp. Would you report a bug in 
coreutils if the directory were created by mkdir and chmod and gvfs crashed on 
it?

> 
> Thunar and xrdp 0.6 used to work together under Jessie and it was broken
> once xrdp 0.9 was installed.  So please lets not play severity pingpong
> here.

This is not about severity ping pong. It is about assigning the bug to the 
package that is broken, which is, from all that was gathered until now, not 
xrdp.

As you quoted from bugs.debian.org, let me quote from backports.debian.org:

  Backports cannot be tested as extensively as Debian stable, and backports 
are provided on an as-is basis, with risk of incompatibilities with other 
components in Debian stable. Use with care!

You decided to install xrdp from bpo, knowing that it might break something. 
Doing so, you found a bug concerning the compatibility between xrdp and gvfs 
from stable. While this sure is annoying, it is still necessary to find the 
real culprit. And, sorry for repeating myself: From all the information I got, 
it looks as though gvfs in stable breaks on a regular FUSE mountpoint not 
readable by root because its code lacks sanity checks.

> May be my immediate fix will be downgrade to xrdp 0.6 to enable
> users working and try to sort out things on a different machine.  It
> might turn out that the bug needs to be re-assigned but we somehow need
> to prevent other people to break their system in the same way as I did
> (which is not even the case when setting severity only to important).

Sorry, Andreas, please do not get this wrong… but, looking at things, I see 
that you uploa

Bug#831974: black screen with nvidia driver

[Luca Boccassi]

On Wed, 2016-07-20 at 23:22 +0200, VA wrote:
> Package: nvidia-kernel-dkms
> Version: 352.79-10
> Severity: important
> 
> After upgrade to kernel 4.6, nvidia driver does not seem to work
> anymore, I just get a black screen. There's some flickering, Xorg seems
> to be restarting though nothing appears.
> 
> Here's what I get in dmesg:
> 
> [   58.134694] pmd_set_huge: Cannot satisfy [mem 0xf400-0xf420]
> with a huge-page mapping due to MTRR override.
> [   87.050458] INFO: rcu_sched self-detected stall on CPU
> [   87.050460]2-...: (5249 ticks this GP) idle=8eb/141/0
> softirq=7323/7323 fqs=5248
> [   87.050462] (t=5250 jiffies g=3816 c=3815 q=1064)
> [   87.050462] Task dump for CPU 2:
> [   87.050464] XorgR running  0  3279   3274 0x0048
> [   87.050466]  0003 844c7874 f77dbe70 c10cc1cd c1735e80 c1735e80
> f78fa880 c1735e80
> [   87.050467]  f77dbec0 c10cf6c1 c1664320 1482 0ee8 0ee7
> 0428 
> [   87.050468]  f78fa040  c1861040 f77dbec0 c109985a f0374f00
>  1b6b
> [   87.050469] Call Trace:
> [   87.050477]  [] ? rcu_dump_cpu_stacks+0x6d/0xb0
> [   87.050479]  [] ? rcu_check_callbacks+0x4a1/0x700
> [   87.050483]  [] ? account_process_tick+0x5a/0x160
> [   87.050484]  [] ? update_process_times+0x32/0x60
> [   87.050486]  [] ? tick_sched_handle.isra.12+0x26/0x60
> [   87.050487]  [] ? tick_sched_timer+0x3a/0x80
> [   87.050488]  [] ? __remove_hrtimer+0x3f/0x80
> [   87.050489]  [] ? __hrtimer_run_queues+0xce/0x2a0
> [   87.050491]  [] ? __wake_up+0x37/0x50
> [   87.050492]  [] ? tick_sched_handle.isra.12+0x60/0x60
> [   87.050493]  [] ? hrtimer_interrupt+0x93/0x1a0
> [   87.050495]  [] ? add_interrupt_randomness+0x15c/0x1c0
> [   87.050498]  [] ? hpet_interrupt_handler+0x15/0x40
> [   87.050499]  [] ? handle_irq_event_percpu+0x7e/0x1c0
> [   87.050501]  [] ? find_next_bit+0x17/0x30
> [   87.050502]  [] ? handle_irq_event+0x2f/0x50
> [   87.050504]  [] ? handle_edge_irq+0x6d/0x120
> [   87.050505]  [] ? handle_level_irq+0xe0/0xe0
> [   87.050506]  [] ? handle_irq+0x54/0x70
> [   87.050509][] ? do_IRQ+0x3c/0xc0
> [   87.050510]  [] ? common_interrupt+0x33/0x38
> [   87.050601]  [] ? rm_is_supported_device+0x188/0x18c [nvidia]
> [   87.050659]  [] ? os_io_read_byte+0xc/0x10 [nvidia]
> [   87.050737]  [] ? rm_shutdown_gvi_device+0x73/0x260 [nvidia]
> [   87.050817]  [] ? _nv016241rm+0x76b6/0xacb0 [nvidia]
> [   87.050896]  [] ? _nv000817rm+0x74/0x8c [nvidia]
> [   87.050971]  [] ? _nv012223rm+0x146/0x4d0 [nvidia]
> [   87.051050]  [] ? _nv012593rm+0x63/0x140 [nvidia]
> [   87.051128]  [] ? _nv000712rm+0x25e/0x2e0 [nvidia]
> [   87.051205]  [] ? _nv000636rm+0x24a/0x4dc [nvidia]
> [   87.051274]  [] ? _nv000648rm+0xc5/0x358 [nvidia]
> [   87.051343]  [] ? rm_disable_adapter+0x46/0xc4 [nvidia]
> [   87.051345]  [] ? down+0x13/0x50
> [   87.051396]  [] ? nvidia_close+0x1a0/0x410 [nvidia]
> [   87.051446]  [] ? nvidia_frontend_compat_ioctl+0x1d/0x30
> [nvidia]
> [   87.051496]  [] ? nvidia_frontend_close+0x3d/0x90 [nvidia]
> [   87.051499]  [] ? __fput+0xca/0x1d0
> [   87.051502]  [] ? task_work_run+0x87/0xa0
> [   87.051503]  [] ? exit_to_usermode_loop+0xd5/0xe0
> [   87.051504]  [] ? do_fast_syscall_32+0x127/0x140
> [   87.051506]  [] ? sysenter_past_esp+0x47/0x75

Not the first time I see that backtrace, but I don't think it has
anything to do with the packaging, I'm beginning to think it might be an
incompatibility between the kernel modules in the older releases and
newer kernel versions..

Still, could you please attach the full system report with:

reportbug -N 831974

Kind regards,
Luca Boccassi


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

Bug#830107: glabels: Scaling of 101% required to match templates

[David Griffith]

On Wed, 20 Jul 2016, Jakob Haufe wrote:



Tested with templates 5871 (business card) and 5163 (4x2 sticker).


I justed printed an outline sheet of 5871 on a LaserJet 2300 and they
perfectly match the size from the official .doc template.

Tested using 3.2.1-2, of course.


Whoops.  I've seen this problem with 3.2.1-2 as well.

--
David Griffith
d...@661.org

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Bug#831324: docker.io: /etc/docker is not readable by the docker group

[Nicolas Braud-Santoni]

Thanks a bunch.

Given that this is blocking for another bug,
would it be possible to have a new upload soon-ish?


Best,

  nicoo

On Mon, Jul 18, 2016 at 11:15:12AM -0700, Tianon Gravi wrote:
> 
> Thanks!  I've applied this in Git, and it'll go out with the next upload. :)

Bug#831976: please define the canonical person page URL, and redirect there

[Mattia Rizzolo]

package: nm.debian.org

this exist
https://nm.debian.org/public/person/mattia
and this does too
https://nm.debian.org/person/mattia

FTR, the upper right corner with my name links to the latter now, but
used to link the former some weeks ago.

I assume they are both the same page, generated by the same thing, but
if the canonical "person page" URL changed, possibly there should be a
301 redirect from the former to the latter, imho.

-- 
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#831975: ci.debian.net: Run test for packages in suites other than unstable

[Santiago Ruano Rincón]

Package: debci
Version: 1.3
Severity: wishlist

Dear Terceiro,

As discussed during Debconf16, it would be great if ci.debian.net also
runs tests for packages in suites other than unstable. This could
include experimental, stable{,-proposed-updates}, oldstable and so on.

Thanks!

Santiago

Bug#831836: python-django: Add pymysql support

[Raphael Hertzog]

On Wed, 20 Jul 2016, Corey Bryant wrote:
> This was originally driven as a result of upstream OpenStack's decision to
> move to PyMySQL [1].  Only one client is typically supported in Ubuntu
> main, so we decided to go with python-pymysql.  As a result, any Ubuntu
> main packages that had a dependency on python-mysqldb had to be moved to
> python-pymysql, and python-django was one of those.

Thanks for the explanation.

Strictly speaking, the package has no "dependency" on python-mysqldb, only
a "suggests". It can be used with other database drivers as well.

While I understand your reasoning, I believe that this change must happen
at the upstream level first. Debian has no similar restriction and I thus
don't see the need to diverge from upstream on this specific point.

Jeremy, alternatively, you could possibly create a
python-pymsql-as-mysqldb that would "Provide: python-mysqldb" and would
contain the corresponding Python package but built on top of
python-pymysql (and would conflict with python-mysqldb). That might be
something upstreamable in pymysql or in the Debian package of
python-pymysql.

I see that many Openstack packages in Debian depend on both
python-mysqldb and python-pymysql. I guess in Ubuntu they depend only in
python-pymysql? Is the difference explained by this Django patch only?

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#831974: black screen with nvidia driver

[VA]

Package: nvidia-kernel-dkms
Version: 352.79-10
Severity: important

After upgrade to kernel 4.6, nvidia driver does not seem to work
anymore, I just get a black screen. There's some flickering, Xorg seems
to be restarting though nothing appears.

Here's what I get in dmesg:

[   58.134694] pmd_set_huge: Cannot satisfy [mem 0xf400-0xf420]
with a huge-page mapping due to MTRR override.
[   87.050458] INFO: rcu_sched self-detected stall on CPU
[   87.050460]  2-...: (5249 ticks this GP) idle=8eb/141/0
softirq=7323/7323 fqs=5248
[   87.050462]   (t=5250 jiffies g=3816 c=3815 q=1064)
[   87.050462] Task dump for CPU 2:
[   87.050464] XorgR running  0  3279   3274 0x0048
[   87.050466]  0003 844c7874 f77dbe70 c10cc1cd c1735e80 c1735e80
f78fa880 c1735e80
[   87.050467]  f77dbec0 c10cf6c1 c1664320 1482 0ee8 0ee7
0428 
[   87.050468]  f78fa040  c1861040 f77dbec0 c109985a f0374f00
 1b6b
[   87.050469] Call Trace:
[   87.050477]  [] ? rcu_dump_cpu_stacks+0x6d/0xb0
[   87.050479]  [] ? rcu_check_callbacks+0x4a1/0x700
[   87.050483]  [] ? account_process_tick+0x5a/0x160
[   87.050484]  [] ? update_process_times+0x32/0x60
[   87.050486]  [] ? tick_sched_handle.isra.12+0x26/0x60
[   87.050487]  [] ? tick_sched_timer+0x3a/0x80
[   87.050488]  [] ? __remove_hrtimer+0x3f/0x80
[   87.050489]  [] ? __hrtimer_run_queues+0xce/0x2a0
[   87.050491]  [] ? __wake_up+0x37/0x50
[   87.050492]  [] ? tick_sched_handle.isra.12+0x60/0x60
[   87.050493]  [] ? hrtimer_interrupt+0x93/0x1a0
[   87.050495]  [] ? add_interrupt_randomness+0x15c/0x1c0
[   87.050498]  [] ? hpet_interrupt_handler+0x15/0x40
[   87.050499]  [] ? handle_irq_event_percpu+0x7e/0x1c0
[   87.050501]  [] ? find_next_bit+0x17/0x30
[   87.050502]  [] ? handle_irq_event+0x2f/0x50
[   87.050504]  [] ? handle_edge_irq+0x6d/0x120
[   87.050505]  [] ? handle_level_irq+0xe0/0xe0
[   87.050506]  [] ? handle_irq+0x54/0x70
[   87.050509][] ? do_IRQ+0x3c/0xc0
[   87.050510]  [] ? common_interrupt+0x33/0x38
[   87.050601]  [] ? rm_is_supported_device+0x188/0x18c [nvidia]
[   87.050659]  [] ? os_io_read_byte+0xc/0x10 [nvidia]
[   87.050737]  [] ? rm_shutdown_gvi_device+0x73/0x260 [nvidia]
[   87.050817]  [] ? _nv016241rm+0x76b6/0xacb0 [nvidia]
[   87.050896]  [] ? _nv000817rm+0x74/0x8c [nvidia]
[   87.050971]  [] ? _nv012223rm+0x146/0x4d0 [nvidia]
[   87.051050]  [] ? _nv012593rm+0x63/0x140 [nvidia]
[   87.051128]  [] ? _nv000712rm+0x25e/0x2e0 [nvidia]
[   87.051205]  [] ? _nv000636rm+0x24a/0x4dc [nvidia]
[   87.051274]  [] ? _nv000648rm+0xc5/0x358 [nvidia]
[   87.051343]  [] ? rm_disable_adapter+0x46/0xc4 [nvidia]
[   87.051345]  [] ? down+0x13/0x50
[   87.051396]  [] ? nvidia_close+0x1a0/0x410 [nvidia]
[   87.051446]  [] ? nvidia_frontend_compat_ioctl+0x1d/0x30
[nvidia]
[   87.051496]  [] ? nvidia_frontend_close+0x3d/0x90 [nvidia]
[   87.051499]  [] ? __fput+0xca/0x1d0
[   87.051502]  [] ? task_work_run+0x87/0xa0
[   87.051503]  [] ? exit_to_usermode_loop+0xd5/0xe0
[   87.051504]  [] ? do_fast_syscall_32+0x127/0x140
[   87.051506]  [] ? sysenter_past_esp+0x47/0x75
[  112.356682] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 22s!
[Xorg:3279]
[  112.356694] Modules linked in: pci_stub(E) vboxpci(OE) vboxnetadp(OE)
vboxnetflt(OE) vboxdrv(OE) nf_conntrack_ipv6(E) nf_defrag_ipv6(E)
xt_multiport(E) xt_tcpudp(E) ip6table_filter(E) ip6_tables(E)
iptable_filter(E) ip_tables(E) nf_conntrack_irc(E) nf_conntrack_pptp(E)
nf_conntrack_proto_sctp(E) nf_conntrack_sip(E) nf_conntrack_tftp(E)
nf_conntrack_netlink(E) nfnetlink(E) nf_conntrack_snmp(E)
xt_conntrack(E) x_tables(E) nf_conntrack_proto_udplite(E)
nf_conntrack_sane(E) nf_conntrack_ftp(E) nf_conntrack_h323(E)
nf_conntrack_proto_dccp(E) nf_conntrack_proto_gre(E)
nf_conntrack_netbios_ns(E) nf_conntrack_broadcast(E) ts_kmp(E)
nf_conntrack_amanda(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E)
nf_conntrack(E) cpufreq_stats(E) cpufreq_powersave(E)
cpufreq_conservative(E) cpufreq_userspace(E) binfmt_misc(E)
[  112.356711]  fuse(E) snd_hda_codec_hdmi(E) snd_hda_codec_via(E)
snd_hda_codec_generic(E) iTCO_wdt(E) joydev(E) coretemp(E)
iTCO_vendor_support(E) evdev(E) kvm_intel(E) kvm(E) snd_hda_intel(E)
snd_hda_codec(E) serio_raw(E) snd_hda_core(E) snd_hwdep(E)
snd_pcm_oss(E) pcspkr(E) irqbypass(E) i7core_edac(E) snd_mixer_oss(E)
edac_core(E) i2c_i801(E) snd_pcm(E) sg(E) snd_timer(E) snd(E)
soundcore(E) asus_atk0110(E) lpc_ich(E) mfd_core(E) button(E)
8250_fintek(E) shpchp(E) acpi_cpufreq(E) tpm_tis(E) tpm(E) processor(E)
nvidia(POE) drm(E) parport_pc(E) ppdev(E) lp(E) parport(E) loop(E)
autofs4(E) ext4(E) xts(E) lrw(E) gf128mul(E) ablk_helper(E) cryptd(E)
aes_i586(E) crc16(E) jbd2(E) crc32c_generic(E) mbcache(E) ecb(E) cbc(E)
algif_skcipher(E) af_alg(E) dm_crypt(E) dm_mod(E) sd_mod(E)
hid_generic(E) ata_generic(E)
[  112.356715]  usbhid(E) hid(E) crc32c_intel(E) psmouse(E) ata_piix(E)
ahci(E) pata_jmicron(E) libahci(E) libata(E) r8169(E) mii(E) scsi_mod(E)
ehci_pci(

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Lucas Nussbaum]

On 20/07/16 at 22:31 +0200, Emmanuel Bourg wrote:
> Le 20/07/2016 à 21:47, Lucas Nussbaum a écrit :
> 
> > So, it would make sense to fix that bug on the maven-repo-helper side, 
> > rather
> > than require changes to each of those packages individually.
> 
> Thank you for investigating this Lucas. Please do not start a mass bug
> filing for these packages though, they will just end up merged in the
> maven-repo-helper bug since we aren't going to close them one by one anyway.

Sure.

> I'm not really happy to see this class of issue marked as serious for
> stretch, it's not reasonable to raise the severity and risk an auto
> removal if "dpkg-buildpackage -A" fails but not "dpkg-buildpackage".
> This is just a minor convenience to enable source-only uploads (which
> aren't even mandatory!).
 
#830997 is a better place to voice such concerns.

Lucas

Bug#811986: qwtplot3d: FTBFS with GCC 6: symbol changes

[Scott Kitterman]

On Tuesday, January 19, 2016 08:13:48 PM you wrote:
> Package: qwtplot3d
> Version: 0.2.7+svn191-9
> Severity: important
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-6 gcc-6-symbols
> 
> This package fails to build with GCC 6.  GCC 6 has not been released
> yet, but it's expected that GCC 6 will become the default compiler for
> stretch.
> 
> Note that only the first error is reported; there might be more.  You
> can find a snapshot of GCC 6 in experimental.  To build with GCC 6,
> you can set CC=gcc-6 CXX=g++-6 explicitly.
> 
> You may be able to find out more about this issue at
> https://gcc.gnu.org/gcc-6/changes.html
> 
> > sbuild (Debian sbuild) 0.67.0 (26 Dec 2015) on dl580gen9-02.hlinux
> 
> ...
> 
> > dpkg-gensymbols: warning: some symbols or patterns disappeared in the
> > symbols file: see diff output below dpkg-gensymbols: warning:
> > debian/libqwtplot3d-qt4-0v5/DEBIAN/symbols doesn't match completely
> > debian/libqwtplot3d-qt4-0v5.symbols ---
> > debian/libqwtplot3d-qt4-0v5.symbols
> > (libqwtplot3d-qt4-0v5_0.2.7+svn191-9_amd64) +++
> > dpkg-gensymbolsFodDeO   2016-01-19 23:39:20.896195539 +
...

This is trivially fixable once GCC-6 is default, so removal from testing now 
makes no sense.  No idea how failing to build with a non-default compiler is 
RC in any case.

Scott K

Bug#831252: [Pkg-julia-devel] Bug#831252: Bug#831252: Bug#831252: julia: FTBFS: Tests failures

[Graham Inggs]

On 19 July 2016 at 23:41, Peter Colberg  wrote:
> The issue with eatmydata has come up repeatedly [1]. Graham, do you
> think adding Build-Conflicts: eatmydata to julia is sensible?

I think filing a bug against eatmydata would be more sensible.

Bug#831886: firefox-esr: crashes with __libc_res_nquery: Assertion (hp != ((void *)0)) && (hp2 != ((void *)0))' failed.

[Mike Hommey]

reassign 831886 libc6
thanks

On Wed, Jul 20, 2016 at 03:18:13PM +0200, Dominik George wrote:
> Package: firefox-esr
> Version: 45.2.0esr-1~deb8u1
> Severity: normal
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Firefox ESR crashes upon loading some website:
> 
> nik@50-e5-49-5b-f2-5d ~ % LC_ALL=C firefox
>   :(
> (process:12202): GLib-CRITICAL **: g_path_get_basename: assertion 'file_name 
> != NULL' failed
> firefox-esr: res_query.c:262: __libc_res_nquery: Assertion (hp != ((void 
> *)0)) && (hp2 != ((void *)0))' failed.

This is an assertion in glibc.


>   [Child 12202] ###!!! ABORT: Aborting on channel error.: file 
> /build/firefox-esr-m27Oa3/firefox-esr-45.2.0esr/ipc/glue/MessageChannel.cpp, 
> line 1861
>   [Child 12202] ###!!! ABORT: Aborting on channel error.: file 
> /build/firefox-esr-m27Oa3/firefox-esr-45.2.0esr/ipc/glue/MessageChannel.cpp, 
> line 1861
>   Crash Annotation GraphicsCriticalError: |[0][GFX1]: CompositorChild was not 
> deinitialized[GFX1]: CompositorChild was not deinitialized
> [1]12123 abort (core dumped)  LC_ALL=C firefox
> 
> 
> Backtrace attached.
> 
> - -- Package-specific info:
> 
> - -- Extensions information
> Name: Default theme
> Location: 
> /usr/lib/firefox-esr/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}.xpi
> Package: firefox-esr
> Status: enabled
> 
> Name: Deutsch (DE) Language Pack locale
> Location: 
> /usr/lib/firefox-esr/browser/extensions/langpack...@firefox-esr.mozilla.org.xpi
> Package: firefox-esr-l10n-de
> Status: enabled
> 
> Name: Firefox Hello Beta
> Location: ${PROFILE_EXTENSIONS}/l...@mozilla.org.xpi
> Status: enabled
> 
> Name: HTTPS-Everywhere
> Location: 
> /usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/https-everywh...@eff.org
> Package: xul-ext-https-everywhere
> Status: enabled
> 
> - -- Plugins information
> Name: Gnome Shell Integration
> Location: /usr/lib/mozilla/plugins/libgnome-shell-browser-plugin.so
> Package: gnome-shell
> Status: enabled
> 
> Name: iTunes Application Detector
> Location: /usr/lib/mozilla/plugins/librhythmbox-itms-detection-plugin.so
> Package: rhythmbox-plugins
> Status: enabled
> 
> 
> - -- Addons package information
> ii  firefox-esr45.2.0esr-1~ i386 Mozilla Firefox web browser - Ext
> ii  firefox-esr-l1 45.2.0esr-1~ all  German language package for Firef
> ii  gnome-shell3.14.4-1~deb i386 graphical shell for the GNOME des
> ii  rhythmbox-plug 3.1-1i386 plugins for rhythmbox music playe
> ii  xul-ext-https- 4.0.2-3  all  extension to force the use of HTT
> 
> - -- System Information:
> Debian Release: 8.5
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16.0-4-686-pae (SMP w/6 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages firefox-esr depends on:
> ii  debianutils   4.4+b1
> ii  fontconfig2.11.0-6.3
> ii  libasound21.0.28-1
> ii  libatk1.0-0   2.14.0-1
> ii  libc6 2.19-18+deb8u4
> ii  libcairo2 1.14.0-2.1+deb8u1
> ii  libdbus-1-3   1.8.20-0+deb8u1
> ii  libdbus-glib-1-2  0.102-1
> ii  libevent-2.0-52.0.21-stable-2
> ii  libffi6   3.1-2+b2
> ii  libfontconfig12.11.0-6.3
> ii  libfreetype6  2.5.2-3+deb8u1
> ii  libgcc1   1:4.9.2-10
> ii  libgdk-pixbuf2.0-02.31.1-2+deb8u5
> ii  libglib2.0-0  2.42.1-1+b1
> ii  libgtk2.0-0   2.24.25-3+deb8u1
> ii  libhunspell-1.3-0 1.3.3-3
> ii  libpango-1.0-01.36.8-3
> ii  libsqlite3-0  3.8.7.1-1+deb8u1
> ii  libstartup-notification0  0.12-4
> ii  libstdc++64.9.2-10
> ii  libx11-6  2:1.6.2-3
> ii  libxcomposite11:0.4.4-1
> ii  libxdamage1   1:1.1.4-2+b1
> ii  libxext6  2:1.3.3-1
> ii  libxfixes31:5.0.1-2+b2
> ii  libxrender1   1:0.9.8-1+b1
> ii  libxt61:1.1.4-1+b1
> ii  procps2:3.3.9-9
> ii  zlib1g1:1.2.8.dfsg-2+b1
> 
> Versions of packages firefox-esr recommends:
> ii  gstreamer1.0-libav 1.4.4-2
> ii  gstreamer1.0-plugins-good  1.4.4-2
> 
> Versions of packages firefox-esr suggests:
> ii  fonts-lmodern  2.004.4-5
> ii  fonts-stix [otf-stix]  1.1.1-1
> ii  libcanberra0   0.30-2.1
> ii  libgnomeui-0   2.24.5-3
> ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u2
> pn  mozplugger 
> 
> - -- no debconf information
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
> 
> iQJOBAEBCAA4BQJXj3oVMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
> cGctcG9saWN5LnR4dC5hc2M

Bug#829188: Latest IceDove crashes do not occur in upstream binaries

[Hadi]

Hi,

I have been experiencing the same frequent random crashes in IceDove
1:45.1.0-1~deb8u1 as reported in bugs #829188 and #828069. I have done
some debugging that might be of help:

- The crash exists even after disabling all add-ons, and recreating the
user profile from scratch (by deleting .icedove).

- The crash does NOT happen with upstream binaries (Thunderbird 45.2.0)
with the same add-ons, mailboxes, and profile. (I renamed .icedove to
.thunderbird).

Thus the problem is either introduced by IceDove's repackaging, or
resolved upstream between TB 45.1 and 45.2.

Cheers,
Hadi

Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Andreas Tille]

Hi Dominik,

On Wed, Jul 20, 2016 at 05:58:40PM +0200, Dominik George wrote:
> Some references:
> 
> http://serverfault.com/questions/188894/denied-root-access-to-user-mounted-fuse-file-system
> 
> In conclusion, I think it is arguable whether xrdp should create that
> directory. IMHO, the behaviour is correct.

But also the user can not see this dir.  I need to try again tomorrow.
 
> But in any case, this is not a bug, and even less an important one,
> because the creation and use of the directory as a FUSE mount point is
> not what prevents the users from seeing other mounts in Thunar.
> 
> Even if xrdp created a thousand fiels and directories with random
> permissions somewhere in the home directory, this should not prevent
> Thunar or gvfs from finding other mount points, fiels or directories.
> 
> Please report to the Thunar or gvfs maintainers that Thunar or gvfs
> break on an unreadable, random directory/mount point in the user's home, 
> because
> that is exactly what happens and causes the issues for your users.

I need to track down this in more detail tomorrow.

> I would be glad, if, as DD, not as reporter, you could advice me on
> whether to keep this bug as a wishlist item („should not create a
> directory in $HOME) or close it as invalid, because creating any random
> directories is not supposed to have side effects and breakage exists in
> Thunar/gvfs.

Well, if upgrading a package renders a system partly unusable this is
per definition

  critical
   makes unrelated software on the system (or the whole system) break,

Thunar and xrdp 0.6 used to work together under Jessie and it was broken
once xrdp 0.9 was installed.  So please lets not play severity pingpong
here.  May be my immediate fix will be downgrade to xrdp 0.6 to enable
users working and try to sort out things on a different machine.  It
might turn out that the bug needs to be re-assigned but we somehow need
to prevent other people to break their system in the same way as I did
(which is not even the case when setting severity only to important).

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Andreas Tille]

On Wed, Jul 20, 2016 at 04:43:24PM +0200, Dominik George wrote:
> > Fuse is not used on this machine […]
> 
> Yes, it is. xrdp uses FUSE to provide shared directories from RDP
> clients.

OK, I was not aware of this.
 
> You provided the link between the directory and FUSE in your original bug
> report.
> 
> > and the directory did not exist in
> > users $HOME dirs until they start an xrdp session with the new xrdp
> > version.
> 
> Yes. Before mounting a FUSE fielsystem, the directory needs to be
> created, obviously.

If this is the case its created with wrong permissions.

> > In other words: Under xrdp 0.6 from Jessie the problem did
> > not exist but occures with the backport of 0.9.
> 
> Yes, but that's not because the directory is broken, but because old
> xrdp did not support shared directories.

I admit our users were used to this old behaviour and the new feature
does create rather trouble than advantages.  Is there any chance to
disable this feature?
 
> > So something not normal is happening here.  As I said the user can not
> > open or access it - no wonder if it has all permissions unset and
> > belongs to root.
> 
> You actually didn't say that. You posted some commands and their results
> when run as root, and what you posted is normal behaviour with FUSE.

I intended to say this by

  In MidnightCommander it is displayer in red with a leading '?'
  dated 01.01.1990 is owned by root and has all permissions unset
  (like `chmod 000 .thinclient_drives`)
 
> Could you please repeat these commands as the user running the xrdp
> session, from within the xrdp session?

Well, I have a good example:  When I tested whether xrdp works I simply
logged into the defaul GUI xfce and immediately logged out afterwards.
I did not do any specific command at all but the broken directory
exists.
 
> > > I guess gvfsd in jessie is running as root and doing nasty magic through
> > > policykit or something?
> > 
> > I checked the gxfsd processes on the machine and each user has a
> > separate one.  There was no fidling around with gvfsd - just a plain
> > Debian stable installation.
> 
> That does not mean that it does not try to access the directory as root.

I thought your question was whether there is some special gvfsd
configuration which is not the case.
 
> > > > $ grep -R thinclient_drives
> > > > debian/patches/fusepath.diff:-/* define FUSE mount point to 
> > > > ~/xrdp_client, ~/thinclient_drives */
> > > > debian/patches/fusepath.diff:+/* define FUSE mount point to 
> > > > ~/.xrdp_client, ~/.thinclient_drives */
> > > > debian/patches/fusepath.diff:-FuseMountName=thinclient_drives
> > > > debian/patches/fusepath.diff:+FuseMountName=.thinclient_drives
> > > > sesman/sesman.ini:FuseMountName=thinclient_drives
> > > > sesman/chansrv/chansrv_fuse.c:/* define FUSE mount point to 
> > > > ~/xrdp_client, ~/thinclient_drives */
> > > > 
> > > > so it is definitely xrdp that's causing this strange dir.
> > > 
> > > xrdp creates it as a FUSE mountpoint. but the consequences you see
> > > definitely look like a combination of the bad behaviours oF FUSE and
> > > gvfs in jessie (or in general?).
> > > 
> > > I expect this to also happen with an sshfs mount. Could you try that?
> > 
> > The mounts are samba shares (cifs).
> > 
> > What exactly do you want me to try?
> 
> $ sudo apt-get install sshfs
> $ mkdir .foobar
> $ sshfs u...@ezample.com: .foobar
> 
> Then see whether it impacts Thunar as well.
> 
> sshfs uses FUSE, just like xrdp, and I expect that you see the same
> behaviour with .ffobar after mounting sshfs on it as you see with
> .thinclient_drives.

I can try tomorrow - but as long as thunar has permissions to read the
dir I guess everything will be fine.  Thunar tries to cache the
available directories - but it can not parse a dir that belongs to root
and has permissions set to 000.  Not even root can access the dir. :-(
 
> >  
> > > If you still think this is specific to xrdp, please explain why. If not, 
> > > this should be discussed with the gvfs maintainers.
> > 
> > I think xrdp is creating a directory that creates problems.  IHMO the
> > fix would be to make sure xrdp does not create this directory (and
> > simply is using it if it exists).
> 
> No, that is not a fix. It would mean that users would not be able to use
> shared directories over RDP unless they manually create some directory.

That's no difference to the current behaviour since the directory is not
accessible for anyone.  However, the cifs mounted directories are
perfectly accessible in the xrdp session.  I can easily browse them when
using bash or mc.
 
> As I cannot reproduce the problem (without Thunar/gvfs) and in fact find
> a working FUSE mountpoint in ~/.thinclient_drives, I think the real
> cause of the issues should be found instead of breaking user experience
> with xrdp.

Well, the user experience is *now* broken.  You said old xrdp 0.6 was
not supporting shared directories.  However, every user was able to

Bug#830074: fixed in iodine 0.7.0-5

[bugs-debian]

Sorry for being late on all of this, but I have a few remarks on this.
First, thanks for the service file, and the long explanation.
Regarding socket activation, I currently have this (custom) socket unit:

[Unit]
Description=Iodine socket

[Socket]
# For now, listen only in IPv4
ListenDatagram=0.0.0.0:5354
BindIPv6Only=both

[Install]
WantedBy=sockets.target

This is fine. It does not solve the case where "-i" exit too quickly,
but I have not experienced this. Do you have a bug report for this
incorrect behavior?

Since iodine is a pure network service, it should be protected as much
as possible with systemd's own mechanism like:
PrivateTmp=true
ProtectSystem=full
ProtectHome=true
NoNewPrivileges=true

I understand that chroot can offer some protection, so I'll be glad to
here that those directive are useless with it. In the same way, I may
have missed new containement directives that can be used to restrict the
attack surface further.

Adrien

Bug#831184: mumble: FTBFS with GCC 6

[Christopher Knadle]

Hello again, Lucas.

Thanks for reporting this bug.
Sorry for the delay in response: unfortunately the hard disk in my mail
server died on Thursday night and since then I've been scrambling to try to
recover what data I could and get it back up again after disk replacement.

I had a quick look at the bug and the build log, and I think you pointed
out the correct section of the log where the compile went awry.

I should be able to look more deeply at this on Monday.  Meanwhile I'll try
to inform upstream about the problem so that they're aware.

Thanks.

-- Chris

Bug#831973: smartd sometimes starts before USB drives are detected by the system during boot

[Mathew Newton]

Package: smartmontools
Version: 6.3+svn4002-2

When booting my Raspberry Pi (running Raspbian, an unofficial Debian 
Jessie port) I am *sometimes* finding that smartd fails to pick up an 
external USB-attached drive. Looking at syslog the reason for this 
appears to be that smartd is often started in the boot sequence before 
the drive is being picked up and therefore the /dev/disk/by-id/ 
reference doesn't (yet) exist:


Jul 20 18:59:17 backup systemd[1]: Starting Self Monitoring and 
Reporting Technology (SMART) Daemon...
Jul 20 18:59:17 backup systemd[1]: Started Self Monitoring and Reporting 
Technology (SMART) Daemon.
Jul 20 18:59:17 backup smartd[403]: smartd 6.4 2014-10-07 r4002 
[armv7l-linux-4.4.13-v7+] (local build)
Jul 20 18:59:17 backup smartd[403]: Copyright (C) 2002-14, Bruce Allen, 
Christian Franke, www.smartmontools.org
Jul 20 18:59:17 backup smartd[403]: Opened configuration file 
/etc/smartd.conf
Jul 20 18:59:17 backup smartd[403]: Configuration file /etc/smartd.conf 
parsed.
Jul 20 18:59:17 backup smartd[403]: Device: 
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6FVL47R [SAT], open() 
failed: No such device
Jul 20 18:59:17 backup smartd[403]: Unable to monitor any SMART enabled 
devices. Try debug (-d) option. Exiting...
Jul 20 18:59:17 backup systemd[1]: smartd.service: main process exited, 
code=exited, status=17/n/a
Jul 20 18:59:17 backup systemd[1]: Unit smartd.service entered failed 
state.

 |

 |
Jul 20 18:59:21 backup kernel: [9.092426] usb 1-1.2: New USB device 
found, idVendor=174c, idProduct=1053
Jul 20 18:59:21 backup kernel: [9.092439] usb 1-1.2: New USB device 
strings: Mfr=2, Product=3, SerialNumber=1
Jul 20 18:59:21 backup kernel: [9.092446] usb 1-1.2: Product: USB3.0 
Device
Jul 20 18:59:21 backup kernel: [9.092452] usb 1-1.2: Manufacturer: 
Generic
Jul 20 18:59:21 backup kernel: [9.092458] usb 1-1.2: SerialNumber: 
AC01
Jul 20 18:59:21 backup kernel: [9.093049] usb-storage 1-1.2:1.0: USB 
Mass Storage device detected
Jul 20 18:59:21 backup kernel: [9.094618] scsi host0: usb-storage 
1-1.2:1.0
Jul 20 18:59:22 backup kernel: [   10.091572] scsi 0:0:0:0: 
Direct-Access ASMT 2105 0PQ: 0 ANSI: 6
Jul 20 18:59:22 backup kernel: [   10.096115] sd 0:0:0:0: [sda] Very big 
device. Trying to use READ CAPACITY(16).
Jul 20 18:59:22 backup kernel: [   10.099979] sd 0:0:0:0: [sda] 
5860533168 512-byte logical blocks: (3.00 TB/2.73 TiB)
Jul 20 18:59:22 backup kernel: [   10.05] sd 0:0:0:0: [sda] 
4096-byte physical blocks
Jul 20 18:59:22 backup kernel: [   10.104503] sd 0:0:0:0: Attached scsi 
generic sg0 type 0
Jul 20 18:59:22 backup kernel: [   10.104857] sd 0:0:0:0: [sda] Write 
Protect is off
Jul 20 18:59:22 backup kernel: [   10.104873] sd 0:0:0:0: [sda] Mode 
Sense: 43 00 00 00
Jul 20 18:59:22 backup kernel: [   10.106730] sd 0:0:0:0: [sda] Write 
cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jul 20 18:59:22 backup kernel: [   10.110461] sd 0:0:0:0: [sda] Very big 
device. Trying to use READ CAPACITY(16).

Jul 20 18:59:22 backup kernel: [   10.157535]  sda: sda1 sda2 sda3
Jul 20 18:59:22 backup kernel: [   10.161101] sd 0:0:0:0: [sda] Very big 
device. Trying to use READ CAPACITY(16).
Jul 20 18:59:22 backup kernel: [   10.163033] sd 0:0:0:0: [sda] Attached 
SCSI disk


In case it is relevant here is my smartd.conf:

/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6FVL47R -d sat -n 
standby -a -o on -S on -s (S/../.././03|L/../../7/04) -r 194 -I 194 -W 
5,40,45


I am using the /dev/disk/by-id/ reference as I sometimes swap disks 
around and each has different smartd configuration parameters. Following 
boot completion the symlink does indeed exist:


#  ls -l /dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6FVL47R
lrwxrwxrwx 1 root root 9 Jul 20 18:59 
/dev/disk/by-id/ata-WDC_WD30EFRX-68EUZN0_WD-WCC4N6FVL47R -> ../../sda


...and if I then start smartmontool manually everything is fine.

More often than not it works fine without intervention i.e. the disk is 
picked up before smartd starts but as seen above there can be a few 
seconds difference the other way which ends in non-obvious failure (i.e. 
I only spot if if I check the logs). Should/could there by anything to 
prevent this race condition?


Perhaps it is a Raspbian-specific issue? If so, apologies for this 
misdirected report.


Regards,

Mathew

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Emmanuel Bourg]

Le 20/07/2016 à 21:47, Lucas Nussbaum a écrit :

> So, it would make sense to fix that bug on the maven-repo-helper side, rather
> than require changes to each of those packages individually.

Thank you for investigating this Lucas. Please do not start a mass bug
filing for these packages though, they will just end up merged in the
maven-repo-helper bug since we aren't going to close them one by one anyway.

I'm not really happy to see this class of issue marked as serious for
stretch, it's not reasonable to raise the severity and risk an auto
removal if "dpkg-buildpackage -A" fails but not "dpkg-buildpackage".
This is just a minor convenience to enable source-only uploads (which
aren't even mandatory!).

Emmanuel Bourg

Bug#831901: xserver-xorg-core: no hardware assisted 3D acceleration using modesetting driver on Sandybridge

[Martin Steigerwald]

Am Mittwoch, 20. Juli 2016, 22:12:48 CEST schrieb Andreas Boll:
> On Wed, Jul 20, 2016 at 06:51:21PM +0200, Martin Steigerwald wrote:
> > Package: xserver-xorg-core
> > Version: 2:1.18.4-1
> > Severity: important
> > 
> > Dear Timo, dear Maintainers,
> > 
> > as apt-listchanges informed me that with newest X server modesetting
> > driver
> > is now default, I tried it.
> > 
> > It basically works, but subjectively feels a bit more sluggish (expected,
> > but read on why).
> > 
> > 
> > But kwin_x11 doesn´t enable OpenGL compositor anymore but falls back to
> > XRender:
> > 
> > OpenGL vendor string:   VMware, Inc.
> > OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8,
> > 256 bits) OpenGL version string:  3.0 Mesa 12.0.1
> > OpenGL shading language version string: 1.30
> > Driver: LLVMpipe
> > GPU class:  Unknown
> > OpenGL version: 3.0
> > GLSL version:   1.30
> > Mesa version:   12.0.1
> > X server version:   1.18.4
> > Linux kernel version:   4.7
> > Requires strict binding:yes
> > GLSL shaders:   yes
> > Texture NPOT support:   yes
> > Virtual Machine:no
> > kwin_core: OpenGL driver recommends XRender based compositing. Falling
> > back to XRender. kwin_core: To overwrite the detection use the
> > environment variable KWIN_COMPOSE kwin_core: For more information see
> > http://community.kde.org/KWin/Environment_Variables#KWIN_COMPOSE
> > kwin_core: Failed to initialize compositing, compositing disabled
> > 
> > 
> > glxinfo agrees that LLVMpipe OpenGL renderer is active instead of the
> > Intel mesa> 
> > driver:
> > Vendor: VMware, Inc. (0x)
> > Device: llvmpipe (LLVM 3.8, 256 bits) (0x)
> > Version: 12.0.1
> > Accelerated: no
> > Video memory: 15829MB
> > Unified memory: no
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > >
> > >From the Xorg log it looks like initialization of OpenGL based Glamor
> > 
> > 2D acceleration also fails:
> > 
> > [ 47090.425] (II) Loading sub module "glamoregl"
> > [ 47090.425] (II) LoadModule: "glamoregl"
> > [ 47090.425] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
> > [ 47090.432] (II) Module glamoregl: vendor="X.Org Foundation"
> > [ 47090.432] »··compiled for 1.18.4, module version = 1.0.0
> > [ 47090.432] »··ABI class: X.Org ANSI C Emulation, version 0.4
> > [ 47090.432] (II) glamor: OpenGL accelerated X.org driver based.
> > [ 47090.452] (EE) modeset(0): eglInitialize() failed
> > [ 47090.452] (EE) modeset(0): glamor initialization failed
> 
> Yep EGL failed to initialize.
> 
> 
> snip
> 
> > Versions of packages xserver-xorg-core depends on:
> > ii  keyboard-configuration1.147
> > ii  libaudit1 1:2.6.5-1
> > ii  libc6 2.23-2
> > ii  libdbus-1-3   1.10.8-1
> > ii  libdrm2   2.4.68-1
> > ii  libegl1-mesa  12.0.1-3
> > ii  libepoxy0 1.3.1-1
> > ii  libgbm1   11.2.2-1
> 
> If you use mesa from experimental you need to upgrade all binary
> packages of mesa.
> Upgrading libgbm1 to version 12.0.1-3 should fix glamor and 3d acceleration.

Thank you Andreas.

Indeed. I wasn´t aware of libgbm1. Upgrading it to experimental fixes the 
issue for me. So feel free to close the bug report.

> > ii  libgcrypt20   1.7.2-2
> > ii  libgl1-mesa-glx [libgl1]  12.0.1-3
> > ii  libpciaccess0 0.13.4-1
> > ii  libpixman-1-0 0.33.6-1
> > ii  libselinux1   2.5-3
> > ii  libsystemd0   230-7
> > ii  libudev1  230-7
> > ii  libxau6   1:1.0.8-1
> > ii  libxdmcp6 1:1.1.2-1.1
> > ii  libxfont1 1:1.5.1-1
> > ii  libxshmfence1 1.2-1
> > ii  udev  230-7
> > ii  xserver-common2:1.18.4-1
> > 
> > Versions of packages xserver-xorg-core recommends:
> > ii  libgl1-mesa-dri  12.0.1-3
> > ii  libpam-systemd   230-7
> > 
> > Versions of packages xserver-xorg-core suggests:
> > ii  xfonts-100dpi1:1.0.4+nmu1
> > ii  xfonts-75dpi 1:1.0.4+nmu1
> > ii  xfonts-scalable  1:1.0.3-1.1
> > 
> > -- no debconf information

-- 
Martin

Bug#675008: LSB feature request

[Patrick Schleizer]

Posted an LSB feature request:

define bash non-login shell snippet drop-in folder /etc/bash.bashrc.d/
in LSB

https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=4167

Cheers,
Patrick

Bug#830126: IT: purify -- Next-generation radio interferometric imaging

[Ole Streicher]

Hi Ian,

Ian Jackson writes:
> Gijs Molenaar writes ("Bug#830126: IT: purify -- Next-generation radio 
> interferometric imaging"):
>> * Package name: purify
> 
> Might you want to choose a different name ?
> 
> https://en.wikipedia.org/wiki/Purify
> 
> In general I think perhaps the ITP template ought to be changed to
> include something about naming and name collisions.

I think this is probably not relevant for us:

* The latest release of Rational Purify is of 2009, so it is quite dead
* It is propertiary software, so the inclusion in Debian is unprobable
* Today, the (again propertiary) successor is called "PurifyPlus"

IMO, there is no reason to honor the name forever, and I would
especially not care too much about a non-free program here. If at some
day IBM/Rational purify would become DFSG conform and we want to include
it in Debian (unprobably IMO anyway), we still can call it "ibm-purify"
or "rational-purify", so this is not a showstopper.

Best regards

Ole

Bug#831910: tracker.debian.org: loaddata imports package sources wrong

[Raphael Hertzog]

Hi,

On Wed, 20 Jul 2016, Muri Nicanor wrote:
> When following the instructions on
> https://tracker.debian.org/docs/setup/repositories.html#repositories
> the command
> ./manage.py tracker_update_repositories
> fails, because the file
> data/cache/apt-cache/etc/sources.list
> contains sections like
> m a i n   c o n t r i b   n o n - f r e e

I can't reproduce this with Django 1.9.7. What version of Django are you
using? Version 1.8.x is the minimal version that we support (it's
available in jessie-backports).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

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

Bug#831901: xserver-xorg-core: no hardware assisted 3D acceleration using modesetting driver on Sandybridge

[Andreas Boll]

On Wed, Jul 20, 2016 at 06:51:21PM +0200, Martin Steigerwald wrote:
> Package: xserver-xorg-core
> Version: 2:1.18.4-1
> Severity: important
> 
> Dear Timo, dear Maintainers,
> 
> as apt-listchanges informed me that with newest X server modesetting driver
> is now default, I tried it.
> 
> It basically works, but subjectively feels a bit more sluggish (expected,
> but read on why).
> 
> 
> But kwin_x11 doesn´t enable OpenGL compositor anymore but falls back to
> XRender:
> 
> OpenGL vendor string:   VMware, Inc.
> OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.8, 
> 256 bits)
> OpenGL version string:  3.0 Mesa 12.0.1
> OpenGL shading language version string: 1.30
> Driver: LLVMpipe
> GPU class:  Unknown
> OpenGL version: 3.0
> GLSL version:   1.30
> Mesa version:   12.0.1
> X server version:   1.18.4
> Linux kernel version:   4.7
> Requires strict binding:yes
> GLSL shaders:   yes
> Texture NPOT support:   yes
> Virtual Machine:no
> kwin_core: OpenGL driver recommends XRender based compositing. Falling back 
> to XRender.
> kwin_core: To overwrite the detection use the environment variable 
> KWIN_COMPOSE
> kwin_core: For more information see 
> http://community.kde.org/KWin/Environment_Variables#KWIN_COMPOSE
> kwin_core: Failed to initialize compositing, compositing disabled
> 
> 
> glxinfo agrees that LLVMpipe OpenGL renderer is active instead of the Intel 
> mesa
> driver:
> 
> Vendor: VMware, Inc. (0x)
> Device: llvmpipe (LLVM 3.8, 256 bits) (0x)
> Version: 12.0.1
> Accelerated: no
> Video memory: 15829MB
> Unified memory: no
> Preferred profile: core (0x1)
> Max core profile version: 3.3
> Max compat profile version: 3.0
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.0
> 
> 
> 
> >From the Xorg log it looks like initialization of OpenGL based Glamor
> 2D acceleration also fails:
> 
> [ 47090.425] (II) Loading sub module "glamoregl"
> [ 47090.425] (II) LoadModule: "glamoregl"
> [ 47090.425] (II) Loading /usr/lib/xorg/modules/libglamoregl.so
> [ 47090.432] (II) Module glamoregl: vendor="X.Org Foundation"
> [ 47090.432] »··compiled for 1.18.4, module version = 1.0.0
> [ 47090.432] »··ABI class: X.Org ANSI C Emulation, version 0.4
> [ 47090.432] (II) glamor: OpenGL accelerated X.org driver based.
> [ 47090.452] (EE) modeset(0): eglInitialize() failed
> [ 47090.452] (EE) modeset(0): glamor initialization failed
> 

Yep EGL failed to initialize.


snip

> 
> Versions of packages xserver-xorg-core depends on:
> ii  keyboard-configuration1.147
> ii  libaudit1 1:2.6.5-1
> ii  libc6 2.23-2
> ii  libdbus-1-3   1.10.8-1
> ii  libdrm2   2.4.68-1
> ii  libegl1-mesa  12.0.1-3
> ii  libepoxy0 1.3.1-1
> ii  libgbm1   11.2.2-1

If you use mesa from experimental you need to upgrade all binary
packages of mesa.
Upgrading libgbm1 to version 12.0.1-3 should fix glamor and 3d acceleration.

Thanks,
Andreas

> ii  libgcrypt20   1.7.2-2
> ii  libgl1-mesa-glx [libgl1]  12.0.1-3
> ii  libpciaccess0 0.13.4-1
> ii  libpixman-1-0 0.33.6-1
> ii  libselinux1   2.5-3
> ii  libsystemd0   230-7
> ii  libudev1  230-7
> ii  libxau6   1:1.0.8-1
> ii  libxdmcp6 1:1.1.2-1.1
> ii  libxfont1 1:1.5.1-1
> ii  libxshmfence1 1.2-1
> ii  udev  230-7
> ii  xserver-common2:1.18.4-1
> 
> Versions of packages xserver-xorg-core recommends:
> ii  libgl1-mesa-dri  12.0.1-3
> ii  libpam-systemd   230-7
> 
> Versions of packages xserver-xorg-core suggests:
> ii  xfonts-100dpi1:1.0.4+nmu1
> ii  xfonts-75dpi 1:1.0.4+nmu1
> ii  xfonts-scalable  1:1.0.3-1.1
> 
> -- no debconf information


signature.asc
Description: Digital signature

Bug#831972: aboot: please make the build reproducible

[Reiner Herrmann]

Source: aboot
Version: 1.0~pre20040408-4
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps locale
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that aboot could not be built reproducibly.
It has a copy of the docbook2man-de-spec.pl script from docbook-utils,
which doesn't support SOURCE_DATE_EPOCH yet, so the timestamp
embedded into manpages varies with locale and build time.

The attached patch fixes this.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/doc/man/de/docbook2man-de-spec.pl b/doc/man/de/docbook2man-de-spec.pl
index 2eed901..d52b26a 100644
--- a/doc/man/de/docbook2man-de-spec.pl
+++ b/doc/man/de/docbook2man-de-spec.pl
@@ -78,6 +78,7 @@ Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA.
 use SGMLS;			# Use the SGMLS package.
 use SGMLS::Output;		# Use stack-based output.
 use SGMLS::Refs;
+use POSIX qw(strftime setlocale LC_TIME);
 
 
 
@@ -93,6 +94,10 @@ $blank_xrefs = 0;
 
 $default_sect = "1";
 $default_date = `date "+%d %B %Y"`;   # L10N
+if ($ENV{SOURCE_DATE_EPOCH}) {
+setlocale(LC_TIME, "C");
+$default_date = strftime("%d %B %Y", gmtime($ENV{SOURCE_DATE_EPOCH} || time));
+}
 
 while (@ARGV) {
 	my $arg = shift @ARGV;


signature.asc
Description: PGP signature

Bug#829088: Jessie

[Joel Rosdahl]

For reference: I have requested to include ccache 3.1.12 in Jessie in
#831426 .

-- Joel

Bug#830997: release.debian.org: Permission to consider dpkg-buildpackage -A bugs as RC

[Lucas Nussbaum]

On 15/07/16 at 00:23 +0200, Santiago Vila wrote:
> On Wed, 13 Jul 2016, Emilio Pozuelo Monfort wrote:
> 
> > Great. We can handle that for Stretch. You can send a ping to the bug 
> > reports
> > saying that these are going to be RC for Stretch and that you will bump them
> > after a week, and then do that.
> 
> Hi. The pings have been sent. Bugs of type "pending upload" and "patch 
> available"
> yesterday, bugs of type "unclassified" today. Will probably bump severities
> during the weeking of next week.
> 
> Thanks a lot.

Hi,

I did some work to verify Santiago's list of affected packages, and
identified more affected packages. The additional bugs I filed are at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-indep;users=debian...@lists.debian.org

(I didn't want to directly tag them using Santiago's tag in case some
manual screening was wanted.)

I only filed them as severity: important. Feel free to bump the severity
to serious when you see fit. I already mentioned in the bug reports that
severity will be set to serious at some point, and pointed to this bug.

Also, I ran into #805228 which causes build failures for many Java
packages (which Santiago already identified). That bug should probably
be set serious at the same time as the initial set. Once that bug is
fixed, the affected Java packages should be build-tested again. (list
available in #805228)

Lucas

Bug#805228: Bug#806630: libnative-platform-java: FTBFS when built with dpkg-buildpackage -A (mh_installjar fails)

[Lucas Nussbaum]

Hi,

I did some work to try to confirm/verify/extend the list of issues
already identified by Santiago Vila, and ran into this bug.

The full list of affected packages is:

android-platform-libcore
android-platform-tools-base
apache-pom
classycle
closure-compiler
commons-parent
cup
findbugs-bcel
gentlyweb-utils
geronimo-osgi-support
gradle-jflex-plugin
gradle-plugin-protobuf
gradle-propdeps-plugin
graxxia
groovycsv
hsqldb
icu4j-4.2
icu4j
insubstantial
isorelax
jakarta-taglibs-standard
jansi
jansi-native
jcifs
jflex
jhighlight
josql
junit
jython
kxml2
libcommons-lang-java
libfreemarker-java
libgpars-groovy-java
libibatis-java
libjackson-json-java
libjava-jdbc-clojure
libjbcrypt-java
libjdom1-java
libjdom2-java
libjt400-java
libkryo-java
libminlog-java
libmnemonicsetter-java
libreflectasm-java
librelaxng-datatype-java
libsmali-java
libtools-logging-clojure
libtools-macro-clojure
lombok
lombok-ast
maven-parent
mockito
parboiled
pegdown
plexus-classworlds2
polyglot-maven
proguard
projectreactor
qdox
scala
scala-parser-combinators
scala-xml
simple-http
spock
wsdl4j

So, it would make sense to fix that bug on the maven-repo-helper side, rather
than require changes to each of those packages individually.

Once the issue is fixed in maven-repo-helper, those packages should be
build-tested again (I can do that if needed; please ping me).

Lucas

Bug#817316: clean-crypto: Mandatory debian/compat for debhelper

[Logan Rosen]

Package: clean-crypto
Version: 1-1
Followup-For: Bug #817316
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/compat: Indicate compatibility level of 9.
  * debian/control:
- Build-depend on debhelper (>= 9).
- Remove needless dependency on JRE.

Thanks for considering the patch.

Logan Rosen

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-21-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -u clean-crypto-1/debian/control clean-crypto-1/debian/control
--- clean-crypto-1/debian/control
+++ clean-crypto-1/debian/control
@@ -9,7 +9,7 @@
  Kyo Lee ,
  Daniel Nuomi ,
 DM-Upload-Allowed: yes
-Build-Depends: ant, debhelper (>= 5), cdbs (>= 0.4.5.3)
+Build-Depends: ant, debhelper (>= 9), cdbs (>= 0.4.5.3)
 Build-Depends-Indep: default-jdk
 Standards-Version: 3.8.4
 Homepage: https://code.launchpad.net/~chris-grze/eucalyptus-commons-ext/clean-crypto
@@ -17,7 +17,7 @@
 
 Package: libclean-crypto-java
 Architecture: all
-Depends: ${misc:Depends}, default-jre-headless
+Depends: ${misc:Depends}
 Description: Simplified and unrestricted javax.crypto bootstrap library
  Provides a simple unrestricted version of the javax.crypto package
  which can be provided when bootstrapping the Java Virtual Machine. This
only in patch2:
unchanged:
--- clean-crypto-1.orig/debian/compat
+++ clean-crypto-1/debian/compat
@@ -0,0 +1 @@
+9

Bug#831970: py-libmpdclient: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: py-libmpdclient
Version: 0.11.1-4
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k 
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs
> python setup.py install --no-compile --prefix 
> /<>/debian/python-mpdclient/usr
> running install
> running build
> running build_py
> creating build
> creating build/lib.linux-x86_64-2.7
> copying mpdclient2.py -> build/lib.linux-x86_64-2.7
> running install_lib
> creating /<>/debian/python-mpdclient/usr
> creating /<>/debian/python-mpdclient/usr/lib
> creating /<>/debian/python-mpdclient/usr/lib/python2.7
> creating 
> /<>/debian/python-mpdclient/usr/lib/python2.7/site-packages
> copying build/lib.linux-x86_64-2.7/mpdclient2.py -> 
> /<>/debian/python-mpdclient/usr/lib/python2.7/site-packages
> running install_egg_info
> Writing 
> /<>/debian/python-mpdclient/usr/lib/python2.7/site-packages/py_libmpdclient-0.11.1-py2.7.egg-info
>  dpkg-genchanges --build=all >../py-libmpdclient_0.11.1-4_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/py-libmpdclient_0.11.1-4_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831971: fortunes-es: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: fortunes-es
Version: 1.32
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[3]: Entering directory '/<>/datfiles/ofensivas'
> for i in machosno.fortunes misogino.fortunes varios.fortunes 
> proverbios.fortunes camioneros.fortunes feministas.fortunes 
> homosexuales.fortunes   racistas.fortunes ; \
> do cp unrotated/$i unrotated/$i.u8 ; \
> recode latin1..u8 unrotated/$i.u8 ; \
> done
> touch utf8-stamp
> for i in machosno.fortunes misogino.fortunes varios.fortunes 
> proverbios.fortunes camioneros.fortunes feministas.fortunes 
> homosexuales.fortunes   racistas.fortunes ; \
> do ../../util/rot < unrotated/$i.u8 > $i || exit $? ; done
> touch rotated-stamp
> touch ocookies-utf8-stamp
> install -m 0755 -d /<>/debian/tmp/usr/share/games/fortunes/off
> for i in machosno.fortunes misogino.fortunes varios.fortunes 
> proverbios.fortunes camioneros.fortunes feministas.fortunes 
> homosexuales.fortunes   racistas.fortunes  ; \
> do install -m 0644 $i 
> /<>/debian/tmp/usr/share/games/fortunes/off || exit $? ;  \
> ln -s $i /<>/debian/tmp/usr/share/games/fortunes/off/$i.u8 ; 
> \
> /usr/bin/strfile -x 
> /<>/debian/tmp/usr/share/games/fortunes/off/$i;  \
> done
> "/<>/debian/tmp/usr/share/games/fortunes/off/machosno.fortunes.dat"
>  created
> There were 25 strings
> Longest string: 146 bytes
> Shortest string: 51 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/misogino.fortunes.dat"
>  created
> There were 237 strings
> Longest string: 503 bytes
> Shortest string: 35 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/varios.fortunes.dat"
>  created
> There were 86 strings
> Longest string: 530 bytes
> Shortest string: 30 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/proverbios.fortunes.dat"
>  created
> There were 242 strings
> Longest string: 147 bytes
> Shortest string: 27 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/camioneros.fortunes.dat"
>  created
> There were 521 strings
> Longest string: 118 bytes
> Shortest string: 9 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/feministas.fortunes.dat"
>  created
> There were 102 strings
> Longest string: 268 bytes
> Shortest string: 46 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/homosexuales.fortunes.dat"
>  created
> There were 3 strings
> Longest string: 153 bytes
> Shortest string: 56 bytes
> "/<>/debian/tmp/usr/share/games/fortunes/off/racistas.fortunes.dat"
>  created
> There were 4 strings
> Longest string: 105 bytes
> Shortest string: 38 bytes
> make[3]: Leaving directory '/<>/datfiles/ofensivas'
> if [ 0 = 1 ] ; then cd html && /usr/bin/make install ; fi
> for i in amistad.fortunes arte.fortunes ciencia.fortunes deprimente.fortunes 
> familia.fortunes filosofia.fortunes humanos.fortunes informatica.fortunes 
> leydemurphy.fortunes libertad.fortunes pintadas.fortunes poder.fortunes 
> proverbios.fortunes refranes.fortunes sabiduria.fortunes 
> sentimientos.fortunes varios.fortunes varios.fortunes-pre verdad.fortunes 
> vida.fortunes lao-tse.fortunes  nietzsche.fortunes  schopenhauer.fortunes 
> asimov.fortunes famosos.fortunes ; do \
>   install -m 0644 $i /<>/debian/tmp/usr/share/games/fortunes 
> || exit cookies-utf8-stamp ;   \
>   recode latin1..u8 
> /<>/debian/tmp/usr/share/games/fortunes/$i;  \
>

Bug#831964: pentium-builder: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: pentium-builder
Version: 0.20
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs usr/bin
> install builder-cc builder-c++ debian/pentium-builder/usr/bin
> dh_link usr/bin/builder-cc usr/bin/gcc \
>   usr/bin/builder-c++ usr/bin/g++
>  dpkg-genchanges --build=all >../pentium-builder_0.20_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/pentium-builder_0.20_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831962: z3: FTBFS with dpkg-buildpackage -A: ln: failed to create symbolic link 'debian/libz3-jni/usr/share/doc/libz3-jni': No such file or directory

[Lucas Nussbaum]

Source: z3
Version: 4.4.1-0.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_installchangelogs RELEASE_NOTES
> for p in python-z3 libz3-ocaml-dev libz3-cil libz3-java libz3-jni ; do \
>   rm -f -rf debian/$p/usr/share/doc/$p/ ; \
>   ln -s libz3-dev debian/$p/usr/share/doc/$p ; \
> done
> ln: failed to create symbolic link 
> 'debian/python-z3/usr/share/doc/python-z3': No such file or directory
> ln: failed to create symbolic link 
> 'debian/libz3-ocaml-dev/usr/share/doc/libz3-ocaml-dev': No such file or 
> directory
> ln: failed to create symbolic link 
> 'debian/libz3-cil/usr/share/doc/libz3-cil': No such file or directory
> ln: failed to create symbolic link 
> 'debian/libz3-jni/usr/share/doc/libz3-jni': No such file or directory
> debian/rules:117: recipe for target 'override_dh_installchangelogs' failed
> make[1]: *** [override_dh_installchangelogs] Error 1

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/z3_4.4.1-0.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831969: api-sanity-checker: FTBFS with dpkg-buildpackage -A: debian/api-sanity-checker.1: No such file or directory at /usr/bin/dh_installman line 131.

[Lucas Nussbaum]

Source: api-sanity-checker
Version: 1.98.7-1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_installchangelogs doc/Changelog.html
> make[1]: Leaving directory '/<>'
>dh_installman -i
> debian/api-sanity-checker.1: No such file or directory at 
> /usr/bin/dh_installman line 131.
> debian/rules:4: recipe for target 'binary-indep' failed
> make: *** [binary-indep] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/api-sanity-checker_1.98.7-1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831963: netqmail: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.

[Lucas Nussbaum]

Source: netqmail
Version: 1.06-5
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens when there is no build-indep target in
debian/rules.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  debian/rules build-indep
> make: *** No rule to make target 'build-indep'.  Stop.

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/netqmail_1.06-5_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831968: jacksum: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: jacksum
Version: 1.7.0-4
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_prep
> dh_installdirs
>  dpkg-genchanges --build=all >../jacksum_1.7.0-4_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/jacksum_1.7.0-4_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831967: freeplane: FTBFS with dpkg-buildpackage -A: freeplane.1: No such file or directory at /usr/bin/dh_installman line 131.

[Lucas Nussbaum]

Source: freeplane
Version: 1.3.15-4
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_listpackages: -s/--same-arch is deprecated; please use -a/--arch instead
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> CDBS WARNING:DEB_DH_INSTALL_ARGS is deprecated since 0.4.85
> CDBS WARNING:DEB_COMPRESS_EXCLUDE is deprecated since 0.4.85
> CDBS WARNING:  DEB_ANT_INSTALL_TARGET unset, skipping default ant.mk 
> common-install target
> Adding cdbs dependencies to debian/freeplane.substvars
> dh_installdirs -pfreeplane \
>   
> Adding cdbs dependencies to debian/libjortho-freeplane-java.substvars
> dh_installdirs -plibjortho-freeplane-java \
>   
> dh_installdocs -pfreeplane 
> dh_installexamples -pfreeplane 
> dh_installman -pfreeplane 
> freeplane.1: No such file or directory at /usr/bin/dh_installman line 131.
> /usr/share/cdbs/1/rules/debhelper.mk:240: recipe for target 
> 'binary-install/freeplane' failed
> make: *** [binary-install/freeplane] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/freeplane_1.3.15-4_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831965: asciidoc: FTBFS with dpkg-buildpackage -A: doc/testasciidoc.1: No such file or directory at /usr/bin/dh_installman line 131.

[Lucas Nussbaum]

Source: asciidoc
Version: 8.6.9-3
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> dh_install
>   cp --reflink=auto -a ./asciidoc.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./docbook45.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./help.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./html4.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./html5.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-cs.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-de.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-el.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-en.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-es.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-fr.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-hu.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-it.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-nl.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-pt-BR.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-ro.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-ru.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./lang-uk.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./latex.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./slidy.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./text.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./xhtml11-quirks.conf 
> debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./xhtml11.conf debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./tests/data/ debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a .//images/icons 
> debian/asciidoc//usr/share/asciidoc/
>   cp --reflink=auto -a ./asciidocapi.py 
> debian/asciidoc//usr/share/asciidoc/
>   cp --reflink=auto -a ./dblatex debian/asciidoc//etc/asciidoc//
>   install -d debian/asciidoc//usr/share/vim/registry
>   cp --reflink=auto -a ./debian/asciidoc.yaml 
> debian/asciidoc//usr/share/vim/registry/
>   cp --reflink=auto -a ./docbook-xsl debian/asciidoc//etc/asciidoc//
>   cp --reflink=auto -a ./docbook-xsl/chunked.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/common.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/epub.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/fo.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/htmlhelp.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/manpage.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/text.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./docbook-xsl/xhtml.xsl 
> debian/asciidoc//etc/asciidoc/docbook-xsl//
>   cp --reflink=auto -a ./filters/code 
> debian/asciidoc//etc/asciidoc/filters//
>   cp --reflink=auto -a ./filters/graphviz 
> debian/asciidoc//etc/asciidoc/filters//
>   cp --reflink=auto -a ./filters/latex 
> debian/asciidoc//etc/asciidoc/filters//
>   cp --reflink=auto -a ./filters/music 
> debian/asciidoc//etc/asciidoc/filters//
>   cp --reflink=auto -a ./filters/source 
> debian/asciidoc//etc/as

Bug#831966: imediff2: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: imediff2
Version: 1.1.2-1.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs
>  dpkg-genchanges --build=all >../imediff2_1.1.2-1.1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/imediff2_1.1.2-1.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831960: pygobject-2: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.

[Lucas Nussbaum]

Source: pygobject-2
Version: 2.28.6-12
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens when there is no build-indep target in
debian/rules.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  debian/rules build-indep
> make: *** No rule to make target 'build-indep'.  Stop.

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/pygobject-2_2.28.6-12_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831958: manpages-es-extra: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: manpages-es-extra
Version: 0.8a-17
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> test -d man2 -a -f debian/rules
> test root = "`whoami`"
> dh_testdir
>  dpkg-genchanges --build=all >../manpages-es-extra_0.8a-17_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/manpages-es-extra_0.8a-17_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831957: adzapper: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: adzapper
Version: 20090301.dfsg.1-0.2
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs
> # Add here commands to install the package into debian/adzapper.
> install -m 755 scripts/squid_redirect debian/adzapper/usr/bin/adzapper
> install -m 755 debian/adzapper.wrapper debian/adzapper/usr/bin
> install -m 755 debian/adzapper2konq debian/adzapper/usr/bin
> install -m 755 debian/adzapper2ab debian/adzapper/usr/bin
> install -m 644 debian/adzapper.conf debian/adzapper/etc/
>  dpkg-genchanges --build=all >../adzapper_20090301.dfsg.1-0.2_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/adzapper_20090301.dfsg.1-0.2_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831956: yocto-reader: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: yocto-reader
Version: 0.9.4+nmu1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[1]: Entering directory '/<>/yocto-reader-0.9.4+nmu1'
> 1997 blocks
> mkdir -p 
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader
> cp -r \
>   feedread.html permalinks.html reader themes \
>   
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader
> (cd 
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader;
>  /bin/ln -s feedread.html index.html)
> mkdir -p 
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/etc/yocto-reader
> mv 
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader/reader/mockapi.js
>  \
>   
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/etc/yocto-reader
> ln -s /etc/yocto-reader/mockapi.js \
>   
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader/reader/mockapi.js
> (VERSION=`dpkg-parsechangelog -S version`; /bin/cp 
> yocto-reader-$VERSION.tar.gz 
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader;
>  cd 
> /<>/yocto-reader-0.9.4+nmu1/debian/yocto-reader/usr/share/yocto-reader;
>  /bin/ln -s yocto-reader-$VERSION.tar.gz yocto-reader.tar.gz)
> make[1]: Leaving directory '/<>/yocto-reader-0.9.4+nmu1'
>  dpkg-genchanges --build=all >../yocto-reader_0.9.4+nmu1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/yocto-reader_0.9.4+nmu1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831959: mrb: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: mrb
Version: 0.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k 
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_install mrb usr/bin
> dh_installman mrb.8
>  dpkg-genchanges --build=all >../mrb_0.1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/mrb_0.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831961: proftpd-dfsg: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.

[Lucas Nussbaum]

Source: proftpd-dfsg
Version: 1.3.5a-1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens when there is no build-indep target in
debian/rules.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  debian/rules build-indep
> make: *** No rule to make target 'build-indep'.  Stop.

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/proftpd-dfsg_1.3.5a-1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831949: ewipe: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: ewipe
Version: 1.2.0-8.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs
> # Add here commands to install the package into debian/ewipe.
> #/usr/bin/make install DESTDIR=`pwd`/debian/ewipe
> install -m 755 ewipe `pwd`/debian/ewipe/usr/bin
> install -m 644 definefont.tcl `pwd`/debian/ewipe/usr/lib/ewipe
> install -m 644 edittable.tcl `pwd`/debian/ewipe/usr/lib/ewipe
> install -m 644 setpointer.tcl `pwd`/debian/ewipe/usr/lib/ewipe
> install -m 644 viewer.tcl `pwd`/debian/ewipe/usr/lib/ewipe
> install -m 644 tclIndex `pwd`/debian/ewipe/usr/lib/ewipe
>  dpkg-genchanges --build=all >../ewipe_1.2.0-8.1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/ewipe_1.2.0-8.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831947: disc-cover: FTBFS with dpkg-buildpackage -A: dh_install: missing files, aborting

[Lucas Nussbaum]

Source: disc-cover
Version: 1.5.6-1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_listpackages: -s/--same-arch is deprecated; please use -a/--arch instead
> test -x debian/rules
> dh_testroot
> dh_prep 
> dh_installdirs -A 
> mkdir -p "."
> Adding cdbs dependencies to debian/disc-cover.substvars
> dh_installdirs -pdisc-cover \
>   
> dh_installdocs -pdisc-cover ./TODO ./AUTHORS
> dh_installexamples -pdisc-cover 
> dh_installman -pdisc-cover 
> dh_installinfo -pdisc-cover 
> dh_installmenu -pdisc-cover 
> dh_installcron -pdisc-cover 
> dh_systemd_enable -pdisc-cover 
> dh_installinit -pdisc-cover 
> dh_installdebconf -pdisc-cover 
> dh_installemacsen -pdisc-cover 
> dh_installcatalogs -pdisc-cover 
> dh_installpam -pdisc-cover 
> dh_installlogrotate -pdisc-cover 
> dh_installlogcheck -pdisc-cover 
> dh_installchangelogs -pdisc-cover ./CHANGELOG
> dh_installudev -pdisc-cover 
> dh_lintian -pdisc-cover 
> dh_bugfiles -pdisc-cover 
> dh_install -pdisc-cover 
> dh_install: Cannot find (any matches for) "disc-cover.1" (tried in "." and 
> "debian/tmp")
> dh_install: disc-cover missing files: disc-cover.1
> dh_install: missing files, aborting
> /usr/share/cdbs/1/rules/debhelper.mk:240: recipe for target 
> 'binary-install/disc-cover' failed
> make: *** [binary-install/disc-cover] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/disc-cover_1.5.6-1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831954: libsnmp-mib-compiler-perl: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: libsnmp-mib-compiler-perl
Version: 0.06-2.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> Manifying 2 pod documents
> Installing 
> /<>/debian/libsnmp-mib-compiler-perl/usr/share/perl5/Bundle/SNMP/MIB/Compiler.pm
> Installing 
> /<>/debian/libsnmp-mib-compiler-perl/usr/share/perl5/SNMP/MIB/Compiler.pm
> Installing 
> /<>/debian/libsnmp-mib-compiler-perl/usr/share/man/man3/Bundle::SNMP::MIB::Compiler.3pm
> Installing 
> /<>/debian/libsnmp-mib-compiler-perl/usr/share/man/man3/SNMP::MIB::Compiler.3pm
> Installing 
> /<>/debian/libsnmp-mib-compiler-perl/usr/bin/mibbrowser
> Installing 
> /<>/debian/libsnmp-mib-compiler-perl/usr/bin/mibcompiler
> make[1]: Leaving directory '/<>'
> chmod a-x 
> /<>/debian/libsnmp-mib-compiler-perl/usr/share/perl5/SNMP/MIB/Compiler.pm
> touch install-stamp
> dh_testdir
> touch arrange-stamp
> dh_testdir
> touch binary-indep-stamp
>  dpkg-genchanges --build=all 
> >../libsnmp-mib-compiler-perl_0.06-2.1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/libsnmp-mib-compiler-perl_0.06-2.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831955: gpsim-doc: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: gpsim-doc
Version: 0.22.0-2
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_prep
>   rm -f debian/gpsim-doc.substvars
>   rm -f debian/gpsim-doc.*.debhelper
>   rm -rf debian/gpsim-doc/
> dh_installdirs
>   install -d debian/gpsim-doc
>   install -d debian/gpsim-doc/usr/share/doc/gpsim-doc
>  dpkg-genchanges --build=all >../gpsim-doc_0.22.0-2_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/gpsim-doc_0.22.0-2_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831951: g2p-sk: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: g2p-sk
Version: 0.4.2-1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh_testdir
> dh_testroot
> dh_clean -k 
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs
> # Add here commands to install the package into debian/g2p-sk.
> #/usr/bin/make install DESTDIR=/<>/debian/g2p-sk
> cp -v  Trans_morfems.pm /<>/debian/g2p-sk/usr/share/perl5/g2p_sk/
> 'Trans_morfems.pm' -> 
> '/<>/debian/g2p-sk/usr/share/perl5/g2p_sk/Trans_morfems.pm'
> cp -v  Trans_cod.pm /<>/debian/g2p-sk/usr/share/perl5/g2p_sk/
> 'Trans_cod.pm' -> 
> '/<>/debian/g2p-sk/usr/share/perl5/g2p_sk/Trans_cod.pm'
> cp -v -r  Exceptions /<>/debian/g2p-sk/usr/share/g2p_sk/
> 'Exceptions' -> '/<>/debian/g2p-sk/usr/share/g2p_sk/Exceptions'
> 'Exceptions/morfemy.ddat' -> 
> '/<>/debian/g2p-sk/usr/share/g2p_sk/Exceptions/morfemy.ddat'
> 'Exceptions/general_iso.ddat' -> 
> '/<>/debian/g2p-sk/usr/share/g2p_sk/Exceptions/general_iso.ddat'
> 'Exceptions/na_konci_ou.txt' -> 
> '/<>/debian/g2p-sk/usr/share/g2p_sk/Exceptions/na_konci_ou.txt'
> 'Exceptions/priaeu_iso.ddat' -> 
> '/<>/debian/g2p-sk/usr/share/g2p_sk/Exceptions/priaeu_iso.ddat'
> cp -v  g2p-sk /<>/debian/g2p-sk/usr/bin/
> 'g2p-sk' -> '/<>/debian/g2p-sk/usr/bin/g2p-sk'
>  dpkg-genchanges --build=all >../g2p-sk_0.4.2-1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/g2p-sk_0.4.2-1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831952: thp: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: thp
Version: 0.4.6-10
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> for file in lib/*.pl ; do \
>   perl -c $file >/dev/null 2>&1 || { echo "$file syntax is not OK" ; 
> exit; }; \
> done
> dh_testdir
> dh_testroot
> dh_clean -k
> dh_clean: dh_clean -k is deprecated; use dh_prep instead
> dh_installdirs
> install -m755 logthis debian/tinyhoneypot/usr/sbin/thpot
> install -m644 thpfunc.pl debian/tinyhoneypot/usr/share/thpot/
> install -m644 thp.conf debian/tinyhoneypot/etc/thpot/
> install -m644 ls.txt fakerpc debian/tinyhoneypot/usr/share/thpot/
> install -m644 debian/thpot.logrotate debian/tinyhoneypot/etc/logrotate.d/thpot
> cp -aR lib/ debian/tinyhoneypot/usr/share/thpot/
>  dpkg-genchanges --build=all >../thp_0.4.6-10_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/thp_0.4.6-10_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831953: dctrl2xml: FTBFS with dpkg-buildpackage -A: doc/dctrl2xml.1: No such file or directory at /usr/bin/dh_installman line 131.

[Lucas Nussbaum]

Source: dctrl2xml
Version: 0.18+nmu1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> dh binary-indep --with python2
>dh_testroot -i
>dh_prep -i
>dh_auto_install -i
> pyversions: missing X(S)-Python-Version in control file, fall back to 
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported versions
>   python setup.py install --force 
> --root=/<>/dctrl2xml-0.18\+nmu1/debian/dctrl2xml --no-compile -O0 
> --install-layout=deb
> running install
> running build
> running build_scripts
> running install_scripts
> creating /<>/dctrl2xml-0.18+nmu1/debian/dctrl2xml/usr
> creating /<>/dctrl2xml-0.18+nmu1/debian/dctrl2xml/usr/bin
> copying build/scripts-2.7/dctrl2xml -> 
> /<>/dctrl2xml-0.18+nmu1/debian/dctrl2xml/usr/bin
> changing mode of 
> /<>/dctrl2xml-0.18+nmu1/debian/dctrl2xml/usr/bin/dctrl2xml to 775
> running install_egg_info
> Creating 
> /<>/dctrl2xml-0.18+nmu1/debian/dctrl2xml/usr/lib/python2.7/dist-packages/
> Writing 
> /<>/dctrl2xml-0.18+nmu1/debian/dctrl2xml/usr/lib/python2.7/dist-packages/dctrl2xml-0.18.egg-info
>dh_installdocs -i
>dh_installchangelogs -i
>dh_installexamples -i
>dh_installman -i
> doc/dctrl2xml.1: No such file or directory at /usr/bin/dh_installman line 131.
> debian/rules:12: recipe for target 'binary-indep' failed
> make: *** [binary-indep] Error 2

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/dctrl2xml_0.18+nmu1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831948: ftpwatch: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: ftpwatch
Version: 1.22
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> test -f debian/rules
> test root = "`whoami`"
> test -f debian/rules
>  dpkg-genchanges --build=all >../ftpwatch_1.22_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/ftpwatch_1.22_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831946: python-pcs: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: python-pcs
Version: 0.5+debian-1.2
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  fakeroot debian/rules binary-indep
> pyversions: missing X(S)-Python-Version in control file, fall back to 
> debian/pyversions
> pyversions: missing debian/pyversions file, fall back to supported versions
> dh_testdir
> for python in python2.7; do $python setup.py config build; done
> running config
> running build
> running build_py
> mkdir -p docs/tmp
> cd docs \
>   && pdflatex --output-directory=tmp pcs.tex \
>   && pdflatex --output-directory=tmp pcs.tex
> This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016/Debian) 
> (preloaded format=pdflatex)
>  restricted \write18 enabled.
> entering extended mode
> (./pcs.tex
> LaTeX2e <2016/03/31> patch level 1
> Babel <3.9r> and hyphenation patterns for 3 language(s) loaded.
> (/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
> Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
> (/usr/share/texlive/texmf-dist/tex/latex/base/size11.clo))
> (./codespelunking.sty)
> (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hyperref.sty
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-hyperref.sty
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/hobsub-generic.sty))
> (/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty)
> (/usr/share/texlive/texmf-dist/tex/generic/ifxetex/ifxetex.sty)
> (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/auxhook.sty)
> (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty)
> (/usr/share/texlive/texmf-dist/tex/latex/hyperref/pd1enc.def)
> (/usr/share/texlive/texmf-dist/tex/latex/latexconfig/hyperref.cfg)
> (/usr/share/texlive/texmf-dist/tex/latex/url/url.sty))
> 
> Package hyperref Message: Driver: hpdftex.
> 
> (/usr/share/texlive/texmf-dist/tex/latex/hyperref/hpdftex.def
> (/usr/share/texlive/texmf-dist/tex/latex/oberdiek/rerunfilecheck.sty))
> (tmp/pcs.aux) (/usr/share/texlive/texmf-dist/tex/latex/hyperref/nameref.sty
> (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/gettitlestring.sty))
> (tmp/pcs.out) (tmp/pcs.out)
> 
> LaTeX Warning: Citation `rfc791' on page 1 undefined on input line 42.
> 
> 
> Overfull \hbox (13.6647pt too wide) in paragraph at lines 63--63
> []\OT1/cmtt/m/n/10.95 0   1   2   
>  
>3[] 
> 
> Overfull \hbox (25.16208pt too wide) in paragraph at lines 63--63
> []\OT1/cmtt/m/n/10.95 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
> 6
>  7 8 9 0 1[] 
> 
> Overfull \hbox (30.91077pt too wide) in paragraph at lines 63--63
> []   \OT1/cmtt/m/n/10.95 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+-+[] 
> 
> Overfull \hbox (30.91077pt too wide) in paragraph at lines 63--63
> []   \OT1/cmtt/m/n/10.95 |Version|  IHL  |Type of Service|  Total 
> Lengt
> h |[] 
> 
> Overfull \hbox (30.91077pt too wide) in paragraph at lines 63--63
> []   \OT1/cmtt/m/n/10.95 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+-+[] 
> 
> Overfull \hbox (30.91077pt too wide) in paragraph at lines 63--63
> []   \OT1/cmtt/m/n/10.95 | Identification|Flags|  
> Fragment 
> Offset|[] 
> 
> Overfull \hbox (30.91077pt too wide) in paragraph at lines 63--63
> []   \OT1/cmtt/m/n/10.95 
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-+-+-+-+-+[] 
> 
> Overfull \hbox (30.91077pt too wide) in paragraph at lines 63--

Bug#831950: gnome-python: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.

[Lucas Nussbaum]

Source: gnome-python
Version: 2.28.1+dfsg-1.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens when there is no build-indep target in
debian/rules.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  debian/rules build-indep
> make: *** No rule to make target 'build-indep'.  Stop.

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/gnome-python_2.28.1+dfsg-1.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831945: pygtk: FTBFS with dpkg-buildpackage -A: make: *** No rule to make target 'build-indep'. Stop.

[Lucas Nussbaum]

Source: pygtk
Version: 2.24.0-4
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens when there is no build-indep target in
debian/rules.

If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now. If not, debian/rules
should be modified so that the build-indep and binary-indep target generates
the architecture independent packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
>  debian/rules build-indep
> make: *** No rule to make target 'build-indep'.  Stop.

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/pygtk_2.24.0-4_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.

Bug#831939: jailer: FTBFS with dpkg-buildpackage -A: dpkg-genchanges: error: binary build with no binary artifacts found; cannot distribute

[Lucas Nussbaum]

Source: jailer
Version: 0.4-17.1
Severity: important
Tags: stretch sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20160720 qa-ftbfs qa-indep
Justification: FTBFS on amd64

Hi,

During a rebuild of all packages in sid, your package failed to build on
amd64.  This rebuild was done by building only the architecture-independent
packages.  At the same time, a normal build succeeded, which points the
problem specifically to build-indep/binary-indep targets.


The specific error below usually happens there is a binary-indep target in
debian/rules which is either empty or does not do anything useful.

If all the arch-independent packages are dummy transitional packages released
with jessie, the easy fix is to drop them now. If not, debian/rules should be
modified so that the binary-indep target generates the architecture independent
packages (and only those).

After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B" work
properly, this package will be suitable to be uploaded in source-only form if
you wish.

I file this bug as severity: important, but Santiago Vila, who led this
effort (kudos to him), got approval from the release team to consider those
bugs RC for stretch. The severity will be increased to 'serious' shortly.
See #830997 for details.

Relevant part (hopefully):
> make[4]: Entering directory '/<>/doc'
> make[4]: Nothing to be done for 'install-exec-am'.
> make[4]: Nothing to be done for 'install-data-am'.
> make[4]: Leaving directory '/<>/doc'
> make[3]: Leaving directory '/<>/doc'
> make[2]: Leaving directory '/<>/doc'
> make[1]: Leaving directory '/<>'
> # rename jailer.pl to jailer
> mv `pwd`/debian/jailer/usr/sbin/jailer.pl `pwd`/debian/jailer/usr/sbin/jailer
>  dpkg-genchanges --build=all >../jailer_0.4-17.1_all.changes
> dpkg-genchanges: error: binary build with no binary artifacts found; cannot 
> distribute

The full build log is available from:
   
http://people.debian.org/~lucas/logs/2016/07/20/jailer_0.4-17.1_unstable_archallonly.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

About the archive rebuild: The rebuild was done on EC2 VM instances from
Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
failed build was retried once to eliminate random failures.