Bug#834852: exim4-config: update-exim4.conf does NOT update ANYTHING

[Andreas Metzler]

Control: forcemerge 834852 834853
Control: tags 834852 = moreinfo

On 2016-08-19 Bob Goldberg  wrote:
> Package: exim4-config
> Version: 4.80-7+deb7u3
> Severity: important
> Tags: upstream
[...]
>* What led up to the situation?
> needed to update exim4 to shut off "purging environment" warning
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> after changing conf files, ran update-exim4.conf 
>* What was the outcome of this action?
> discovered that running the update does NOT UPDATE A SINGLE THING.
> discovered that update script EXPRESSLY checks for existence of 
> /etc/exim4/exim4.conf and IF /var/lib/exim4/config.autogenerated is
> EQUAL TO ITSELF!???  THEN EXIT - un-ceremoniously.

I think you are misreading the script:

# exit immediately if /etc/exim4/exim4.conf exists and -o was not specified
if [ -e /etc/exim4/exim4.conf ] && \
  [ "${UPEX4C_outputfile}" = "${UPEX4C_autoconfigfile}" ] ; then
  exit 0
fi

There is no "equal to itself"-check here. UPEX4C_outputfile is the
output file. It is set to UPEX4C_autoconfigfile by default, but can be
overridden with -o. The tests therefore checks whether -o was passed to
the script.

> man page and docs for this script say NOTHING about specifying -o 
[...]

Quoting manual page update-exim4.conf.8:
---
   -o|--output file
  Write output to file instead of /var/lib/exim4/config.autogener‐
  ated.
[...]
 update-exim4.conf exits silently and does nothing if
 /etc/exim4/exim4.conf exists and -o was not used to direct the output
 to a different file than /var/lib/exim4/config.autogenerated.
---

cu Andreas

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

Bug#791923: alpine: please make the build reproducible

[Asheesh Laroia]

Oops, not yet. ETA 1 week.​ Apologies.

Bug#834611: open-infrastructure-container-tools: [INTL:nl] Dutch translation of debconf messages

[Daniel Baumann]

tag 834611 + pending
thanks

Hi Frans,

thanks for the translation, it's applied in Git.

Regards,
Daniel

Bug#834872: ITP: open-infrastructure-system-installer -- d-i component for installing from images

[Daniel Baumann]

Package: wnpp

  * Package name : open-infrastructure-system-installer
Upstream Author : Daniel Baumann 
  * License : GPL-3+
Description : system-installer contains the d-i component (udeb)
  for installing from images rather through debootstrap

Bug#834856: [Debian-med-packaging] Bug#834856: python-pysam fails to build on mips64el arch.: failed test

[Afif Elghraoui]

Control: severity -1 important
Control: tag -1 + help

Hello and thank you for the report.

على الجمعـة 19 آب 2016 ‫14:48، كتب Jonathan Jackson:
> Package: python-pysam
> Version: 0.9.1.4+ds-1
> Severity: grave
> Justification: renders package unusable
> 

While the package may be unusable on mips64el, it works well for the
vast majority of users as I understand it, so this situation deserves a
severity of 'important' rather than 'grave'.

> 
> Python-pysam packages failed to build on March 24th on a mips64el 
> architecture. Here is the tail of the failed-build log:
> 
[...]

I'd be happy to apply any patch that resolves this problem, but porting
work is beyond what I can commit to do for this package.

Many thanks and regards
Afif

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

Bug#834871: cryptsetup: initscript "stop" borks encrypted swap partition for subsequent "start"s

[Wayne Warren]

Package: cryptsetup
Version: 2:1.7.0-2
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?

I installed debian jessie, during which time the installer warned me that it
would be inadvisable not to use encrypted swap. Who am I to disagree? I later
upgraded to debian stretch/testing but as far as I can tell looking at the diff
between 1.6.6-5 and master at git://anonscm.debian.org/pkg-cryptsetup/cryptsetup
the bug is almost certain in jessie also. Does anyone else even use encrypted
swap? 

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

I edited /lib/cryptsetup/cryptdisks.functions to have the "stop" command check
for the "swap" option in the /etc/crypttab line and ran a new function named
"do_unswap()" to call "swapoff -a; do_close; return 0" to ensure that the
encrypted disk would be properly shut down on restart.

   * What was the outcome of this action?

Encrypted swap on this machine is great again.

   * What outcome did you expect instead?

This is what I expected since I verified manually before modifying the
cryptdisks.functions file that if I properly turn off swap and close the
encrypted partition before rebooting the swap partition would indeed be active
by the time i log in next.

I'll probably try submitting a patch or something.

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


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.6.0-1-amd64 
root=UUID=d470e0cc-ba84-4b67-bf35-552dd54ce2fd ro initrd=/install/initrd.gz 
quiet

-- /etc/crypttab
sdb5_crypt /dev/sdb5 none luks,swap
sdb6_crypt UUID=9815be3f-0dd8-4184-a121-b7ead1c3ee86 none luks

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
/dev/mapper/sdb6_crypt /   ext4errors=remount-ro 0   1
# /boot was on /dev/sdb1 during installation
UUID=0574ec56-0269-49ff-a2e9-a00ecf326353 /boot   ext2ro
  0   2
/dev/mapper/sdb5_crypt noneswapsw  0   0
/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0
tmpfs   /runtmpfs   nodev,nosuid,size=10%,mode=1755 0   0
tmpfs   /run/lock   tmpfs   nodev,nosuid,size=10%,mode=1777 0   0
tmpfs   /run/shmtmpfs   nodev,nosuid,size=20%,mode=1777 0   0
tmpfs   /tmptmpfs   nodev,nosuid,size=50%,mode=1777 0   0

-- lsmod
Module  Size  Used by
snd_hda_codec_hdmi 45056  1
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
intel_rapl 20480  0
x86_pkg_temp_thermal16384  0
snd_hda_codec_realtek86016  1
intel_powerclamp   16384  0
coretemp   16384  0
kvm_intel 188416  0
snd_hda_codec_generic69632  1 snd_hda_codec_realtek
kvm   561152  1 kvm_intel
irqbypass  16384  1 kvm
pcspkr 16384  0
serio_raw  16384  0
snd_hda_intel  36864  0
snd_hda_codec 135168  4 
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_intel
snd_hda_core   81920  5 
snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
snd_hwdep  16384  1 snd_hda_codec
joydev 20480  0
snd_pcm   106496  4 
snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel,snd_hda_core
sb_edac32768  0
snd_timer  32768  1 snd_pcm
edac_core  57344  1 sb_edac
lpc_ich24576  0
snd81920  8 
snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec_generic,snd_hda_codec,snd_hda_intel
sg 32768  0
mei_me 32768  0
i2c_i801   20480  0
mfd_core   16384  1 lpc_ich
ipmi_si57344  0
soundcore  16384  1 snd
mei94208  1 mei_me
ioatdma53248  0
dca16384  1 ioatdma
shpchp 36864  0
8250_fintek16384  0
ipmi_msghandler49152  1 ipmi_si
tpm_infineon   20480  0
tpm_tis20480  0
tpm45056  2 tpm_tis,tpm_infineon
processor  36864  0
evdev  24576  19
parport_pc 28672  0
sunrpc331776  1
ppdev  20480  0
lp 20480  0
parport49152  3 lp,ppdev,parport_pc
autofs440960  2
ext4  593920  4
ecb16384  0
crc16  16384  1 ext4
jbd2  106496  1 ext4
crc32c_generic 16384  0
mbcache16384  5 ext4
algif_skcipher 20480  0
af_alg   

Bug#834869: ITP: keysafe -- back up secret keys to cloud servers

[Joey Hess]

It would be fine to package keysafe now, but please be sure to note that
it has not been fully security reviewed yet. It would probably make
sense to keep it in experimental until version 1.x.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#834870: debian/rules clean doesn’t

[Anders Kaseorg]

Source: git
Version: 1:1.8.5~rc2-1
Tags: patch

The mw-to-git packaging in 1:1.8.5~rc2-1 (http://bugs.debian.org/718395), 
and the subtree packaging in 1:1.9.1-1 (http://bugs.debian.org/704652), do 
not clean up after themselves correctly, with the result that building a 
binary package and then a source package fails:

$ debuild -b
[…]
Successfully signed changes file
$ debuild -S
[…]
dpkg-source: warning: executable mode 0755 of 
'contrib/subtree/git-subtree' will not be represented in diff
dpkg-source: info: local changes detected, the modified files are:
 git/GIT-VERSION-FILE
 git/contrib/subtree/git-subtree
 git/contrib/subtree/git-subtree.1
 git/contrib/subtree/git-subtree.html
 git/contrib/subtree/git-subtree.xml
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/git_2.9.3-1.diff.EhLegS
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b git gave error exit status 2

We need to clean contrib/subtree which was not getting cleaned at all, and 
we need to clean contrib/mw-to-git before cleaning the top directory so 
that GIT-VERSION-FILE gets removed.  I intend to fix this as follows.

---
 debian/changelog | 7 +++
 debian/rules | 3 ++-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 0c50160..8774690 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git (1:2.9.3-2) UNRELEASED; urgency=medium
+
+  * debian/rules: Fix clean target to remove GIT-VERSION-FILE and
+contrib/subtree build products.
+
+ -- Anders Kaseorg   Fri, 19 Aug 2016 23:00:23 -0400
+
 git (1:2.9.3-1) unstable; urgency=medium
 
   * New upstream release (see RelNotes/2.8.2.txt, RelNotes/2.8.3.txt,
diff --git a/debian/rules b/debian/rules
index 61c735b..4cd0a75 100755
--- a/debian/rules
+++ b/debian/rules
@@ -84,11 +84,12 @@ build-indep-stamp: patch-stamp build-arch-stamp
touch build-indep-stamp
 
 clean: deb-checkdir
+   $(MAKE) -C contrib/mw-to-git clean $(OPTS)
+   $(MAKE) -C contrib/subtree clean $(OPTS)
$(MAKE) clean $(OPTS)
! test -e patch-stamp || \
{ \
  set -e; \
- $(MAKE) -Ccontrib/mw-to-git clean $(OPTS); \
  for i in `ls -1r debian/diff/*.diff debian/diff/*.patch \
  2>/dev/null || :`; do \
patch -p1 -NR -r- <$$i || test $$? = 1 || exit 1; \
-- 
2.10.0.rc0

Bug#834869: ITP: keysafe -- back up secret keys to cloud servers

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: keysafe
  Version : 0.20160819
  Upstream Author : Joey Hess 
* URL : https://joeyh.name/code/keysafe/
* License : AGPL-3
  Programming Lang: Haskell
  Description : back up secret keys to cloud servers

Upstream synopsis:

> Keysafe backs up a secret key to several cloud servers, split up so
> that no one server can access the whole secret by itself.

> A password is used to encrypt the data, and it is made expensive to
> decrypt, so password cracking is infeasibly expensive.

LWN write-up: https://lwn.net/Articles/696765/

The intended audience of keysafe is those using secret keys to encrypt
only their personal data, when storing it in the cloud.  Such a user
doesn't need to take the security precautions that a Debian Developer or
Debian Maintainer must take to protect their secret key.  However, they
still don't want to lose it and thus invalidate their backups.  Keybase
is designed to make it easy to backup secret keys in the cloud for this
kind of user.

Although this software is experimental, it has the potential to enable a
lot more Debian users to use public/private key cryptography to protect
the data that they store in the cloud.

I intend to package this and submit it for upload to experimental.  I
want to do this because I believe it will enable a lot more testing, and
useful feedback submitted to Joey.  In particular, it will enable
feedback from those who know a lot about cryptography but not much about
Haskell.  Further, we will want it in unstable eventually, and getting
the packaging in shape in advance makes that easy (Joey isn't the kind
of upstream to abandon the software while it's still alpha).

--
Sean Whitton


signature.asc
Description: PGP signature

Bug#807990: fail gracefully for missing users: redid the patch

[Antoine Beaupré]

i changed the patch a little because it turns out that my pam.d sample
config wasn't actually working as expected - the user_unknown=ignore
block needs to *replace* the "required" keyword, and not simply be
appended in the end.

here's a new patch that changes the README slightly.

>From 509c4cda7e08384d7cd16dfdb3917b4373f1e36e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Mon, 1 Aug 2016 12:25:10 -0400
Subject: [PATCH] fail gracefully for missing users

when the pam module is enabled, it forces *all* users to immediately
start using OATH, or they can't login at all.

a more progressive approach would seem more reasonable to me,
especially since each user need to get an admin user to update the
central file for them.

this patch adds an early check to the users file and makes sure the
user exists before prompting for a password.

if the user is missing, it exits early with a standard error code
(PAM_USER_UNKNOWN) which can then be ignored in the PAM configuration
(as shown in the README file). this leaves the policy decision up to
the admin (and defaults to "fail closed").

if the user is present, the code path remains the same except the
usersfile is scanned twice, which may be a performance penalty on very
slow filesystems or very large files. the only workaround I can think
of for this would be to load the whole file into memory, but this
could have significant memory impact on large files.

the function used (`oath_authenticate_usersfile`) is a little overkill
as it actually goes and tries to authenticate the user with an empty
password. this is harmless because the file isn't updated if the OTP
is incorrect and because no warning is sent to syslog.

a possible improvement on this would be to have a warning shown to the
user inciting them to configure OATH or to warn them about a possible
typo in their username before they enter their regular passphrase
---
 pam_oath/README |  2 +-
 pam_oath/pam_oath.c | 17 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/pam_oath/README b/pam_oath/README
index bef4265..24b9f8b 100644
--- a/pam_oath/README
+++ b/pam_oath/README
@@ -23,7 +23,7 @@ window open before making any changes!
 
 -
 # head -1 /etc/pam.d/su
-auth requisite pam_oath.so debug usersfile=/etc/users.oath window=20
+auth [user_unknown=ignore success=ok] pam_oath.so debug usersfile=/etc/users.oath window=20
 #
 -
 
diff --git a/pam_oath/pam_oath.c b/pam_oath/pam_oath.c
index 2820318..25a3452 100644
--- a/pam_oath/pam_oath.c
+++ b/pam_oath/pam_oath.c
@@ -162,6 +162,23 @@ pam_sm_authenticate (pam_handle_t * pamh,
 }
   DBG (("get user returned: %s", user));
 
+  // quick check to skip unconfigured users before prompting for password
+  {
+time_t last_otp;
+otp[0] = '\0';
+rc = oath_authenticate_usersfile (cfg.usersfile,
+  user,
+  otp, cfg.window, onlypasswd, _otp);
+
+DBG (("authenticate first pass rc %d (%s: %s) last otp %s", rc,
+  oath_strerror_name (rc) ? oath_strerror_name (rc) : "UNKNOWN",
+  oath_strerror (rc), ctime (_otp)));
+if (rc == OATH_UNKNOWN_USER)
+  {
+return PAM_USER_UNKNOWN;
+  }
+  }
+
   if (cfg.try_first_pass || cfg.use_first_pass)
 {
   retval = pam_get_item (pamh, PAM_AUTHTOK, (const void **) );
-- 
2.1.4


i would like to do a NMU for this to deploy this change, any objections?

a.
-- 
I prefer the tumult of liberty to the quiet of servitude.
- Thomas Jefferson

Bug#833478: xserver-xorg: Random brief (1s) screen-blanking with modesetting driver on intel hw

[Stefano Rivera]

Upgraded to linux 4.7.0-1 and now I'm seeing similar symptoms on the eDP
panel.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Bug#834566: Migrate patches to 3.0 (quilt) format

[Anders Kaseorg]

Actually working version:

---
 debian/changelog   |  6 +
 debian/git.README.source   | 11 -
 ...hook-capture-documentation-in-a-here-docum.diff |  0
 debian/patches/series  |  1 +
 debian/rules   | 26 +-
 5 files changed, 18 insertions(+), 26 deletions(-)
 rename debian/{diff => 
patches}/0001-pre-rebase-hook-capture-documentation-in-a-here-docum.diff (100%)
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 0c50160..8df6b35 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+git (1:2.9.3-2) UNRELEASED; urgency=medium
+
+  * Migrate patches to 3.0 (quilt) format.
+
+ -- Anders Kaseorg   Wed, 17 Aug 2016 00:35:17 -0400
+
 git (1:2.9.3-1) unstable; urgency=medium
 
   * New upstream release (see RelNotes/2.8.2.txt, RelNotes/2.8.3.txt,
diff --git a/debian/git.README.source b/debian/git.README.source
index 40a3923..ce13c78 100644
--- a/debian/git.README.source
+++ b/debian/git.README.source
@@ -62,12 +62,13 @@ config --add format.suffix .diff' to make that the default)
  $ git format-patch release..release+patches
  $ git checkout debian-sid
 
-Now move the extracted patches into the debian/diff/ directory, add a
-meaningful message to debian/changelog, and commit the changes to the
-debian-sid branch
+Now move the extracted patches into the debian/patches/ directory, add
+their filenames to debian/patches/series, add a meaningful message to
+debian/changelog, and commit the changes to the debian-sid branch:
 
- $ mv -*.diff debian/diff/
- $ git add debian/diff
+ $ ls -*.diff >> debian/patches/series
+ $ mv -*.diff debian/patches/
+ $ git add debian/patches
  $ debchange -pi
  $ git add debian/changelog
  $ git commit
diff --git 
a/debian/diff/0001-pre-rebase-hook-capture-documentation-in-a-here-docum.diff 
b/debian/patches/0001-pre-rebase-hook-capture-documentation-in-a-here-docum.diff
similarity index 100%
rename from 
debian/diff/0001-pre-rebase-hook-capture-documentation-in-a-here-docum.diff
rename to 
debian/patches/0001-pre-rebase-hook-capture-documentation-in-a-here-docum.diff
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..2cf5d5b
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-pre-rebase-hook-capture-documentation-in-a-here-docum.diff
diff --git a/debian/rules b/debian/rules
index 61c735b..843da90 100755
--- a/debian/rules
+++ b/debian/rules
@@ -51,18 +51,10 @@ PKG_INDEP += git-man
 TMP =$(shell pwd)/tmp
 GIT =$(shell pwd)/debian/git
 
-patch: deb-checkdir patch-stamp
-patch-stamp:
-   for i in `ls -1 debian/diff/*.diff debian/diff/*.patch \
-   2>/dev/null || :`; do \
- patch -p1 -N -r- <$$i || test $$? = 1 || exit 1; \
-   done
-   touch patch-stamp
-
 build: build-arch build-indep
 
 build-arch: deb-checkdir build-arch-stamp
-build-arch-stamp: patch-stamp
+build-arch-stamp:
-$(CC) -v
DESTDIR='$(GIT)' $(MAKE) all $(OPTS)
DESTDIR='$(GIT)' $(MAKE) -C contrib/subtree all $(OPTS)
@@ -76,7 +68,7 @@ build-arch-stamp: patch-stamp
touch build-arch-stamp
 
 build-indep: deb-checkdir build-indep-stamp
-build-indep-stamp: patch-stamp build-arch-stamp
+build-indep-stamp: build-arch-stamp
# git-man, git-doc
$(MAKE) -CDocumentation man html $(DOC_OPTS)
# git-mediawiki
@@ -84,18 +76,10 @@ build-indep-stamp: patch-stamp build-arch-stamp
touch build-indep-stamp
 
 clean: deb-checkdir
+   $(MAKE) -Ccontrib/mw-to-git clean $(OPTS)
$(MAKE) clean $(OPTS)
-   ! test -e patch-stamp || \
-   { \
- set -e; \
- $(MAKE) -Ccontrib/mw-to-git clean $(OPTS); \
- for i in `ls -1r debian/diff/*.diff debian/diff/*.patch \
- 2>/dev/null || :`; do \
-   patch -p1 -NR -r- <$$i || test $$? = 1 || exit 1; \
- done; \
-   }
rm -rf '$(TMP)'
-   rm -f patch-stamp build-arch-stamp build-indep-stamp
+   rm -f build-arch-stamp build-indep-stamp
set -e; \
  for i in '' $(patsubst git%,%,$(PKG_INDEP)) -core; do \
rm -rf '$(GIT)'$$i; \
@@ -361,7 +345,7 @@ binary-indep: install-indep $(patsubst 
%,%.deb,$(PKG_INDEP)) git-core.deb-DEBIAN
  dpkg -b '$(GIT)'$$i .. || exit 1; \
done
 
-.PHONY: patch clean
+.PHONY: clean
 .PHONY: build build-arch build-indep
 .PHONY: install install-arch install-indep
 .PHONY: binary binary-arch binary-indep
-- 
2.10.0.rc0

Bug#834868: qbittorrent: segfault at startup

[lkcl]

Package: qbittorrent
Version: 3.3.6-1+b1
Severity: important

right at startup.  got a dialog about converting saving to 3.3.0
and then this happens... and now happens on every startup

*
Catching signal: SIGSEGV
Please file a bug report at http://bug.qbittorrent.org and provide the 
following information:

qBittorrent version: v3.3.6
stack trace:
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1dfe68  [0x7f2ebf3dfe68]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1ddec5  [0x7f2ebf3ddec5]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1e33fa  [0x7f2ebf3e33fa]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1e357f  [0x7f2ebf3e357f]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0x1c1008  [0x7f2ebf3c1008]
  /usr/lib/libtorrent-rasterbar.so.9 : ()+0xc72bf  [0x7f2ebf2c72bf]
  /lib/x86_64-linux-gnu/libpthread.so.0 : ()+0x7464  [0x7f2ebdb82464]
  /lib/x86_64-linux-gnu/libc.so.6 : clone()+0x6d  [0x7f2ebd02530d]

[2]+  Segmentation fault  qbittorrent


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

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

Versions of packages qbittorrent depends on:
ii  geoip-database 20130213-1
ii  libboost-system1.61.0  1.61.0+dfsg-2.1
ii  libc6  2.23-4
ii  libgcc11:6.1.1-10
ii  libqt5core5a   5.6.1+dfsg-3+b1
ii  libqt5dbus55.6.1+dfsg-3+b1
ii  libqt5gui5 5.6.1+dfsg-3+b1
ii  libqt5network5 5.6.1+dfsg-3+b1
ii  libqt5widgets5 5.6.1+dfsg-3+b1
ii  libqt5xml5 5.6.1+dfsg-3+b1
ii  libstdc++6 6.1.1-10
ii  libtorrent-rasterbar9  1.1.0-2
ii  python 2.7.5-5
ii  zlib1g 1:1.2.8.dfsg-2+b1

qbittorrent recommends no packages.

Versions of packages qbittorrent suggests:
pn  qbittorrent-dbg  

-- no debconf information

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

[Christoph Anton Mitterer]

On Tue, 2016-08-16 at 21:20 +0200, Paul Gevers wrote:
> The intent is that dbconfig indeed support identd based
> authentication.
I see.. hmm well wouldn't be my first choice for security reasons,...
but I think it should be possible to get "full" support even with
supporting identd as well.


> But indeed, normally we run under root (which IS the common domain
> during installation/configuration of packages in the Debian.)
Well as I said, it might be, that the UNIX user that dbconfig runs as
already affects the actual authentication... so perhaps it's worth to
generally allow people to specify which UNIX-user to run under in
addition.
But once should probably also put some warnings in place, that this
really requires people to know what they're doing.


> > (3) For certain operations (user creation, DB creation and
> > similar),
> > i.e. all the things a remote DB admin wouldn't typically grant
> > normal users but supply them with,... dbconfig should:
> > first check if that already exists (perhaps try to use it and
> > see
> > if that works - if possible) and if it does, not creating it
> > again
> > but simply continuing with the DB-non-admin-user stuff
> 
> That is exactly what my pending upload is going to do.
:)



> > Perhaps a warning should be given, if the user/db already
> > exists,
> > asking whether one wants to (try to) continue (after all, the
> > admin
> > could have accidentally given you access to something).
> 
> What do you have in mind here exactly? I guess this is more of an
> issue
> for UNIX sockets than for password access, because if the admin tells
> me
> the right password, it must be expecting that I am going to do
> something.
Well... it's based on... let's call it personal experience...
I work for a university and we run a Tier-2 for the LHC Computing Grid
using a massive storage management software called dCache, which every
now and then changes its DB schemas (uses Postgres as well ;) )...
Their policy is usually also not to complain loudly/fail when things
are already there (e.g. when a site already created an index or so),
which over time resulted in many sites having different schemas even
though running the same version.
IMO this creates rather more problems than sites solve by having some
freedom of flexibility.

Therefore, I'd say it's better to warn one time too often than not.

And keep in mind that just by using TCP doesn't mean that the DB is
actually remote,... this is e.g. the case in dCache which is written in
Java (which doesn't support UNIX sockets for DB connections AFAIK).


> >   we don't run any commands under arbitrary other users like
> > "icinga"
> >   or "phpbb" either, which are again not "our" users and we
> > shouldn't
> >   su to them unless really necessary.
> 
> Well, here we may disagree. I think the package icinga is using
> dbconfig
> to do the DB setup, but it is the package icinga that is running the
> install.
Hmm this is in fact a valid point...

> I believe the heuristics already greatly improved between jessie and
> jessie-backports/strech, so maybe some of your ideas are already in
> place in a way.
Sure :)


> > Same as above... if the remote (or local) server doesn't give you
> > DB-
> > amin-rights... we never can do anything about it... just check
> > whether
> > the databases/DB-users we want to use already exist and move on if
> > they
> > do.
> 
> Ok, so here is something were some of my answered may be biased by:
> the
> (current) design and implementation of dbconfig. I think some of your
> ideas may be good/valid, but need extensive rewrite (for not enough?
> gain).
Well as I've said at some point... most of this should be firstly
considered brainstorming... it doesn't mean per se that it needs or
should be implemented :)


> So
> the
> logic in the main part should not be geared TOO much against
> PostgreSQL.
Sure... :)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

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

[Christoph Anton Mitterer]

Hey.


On Fri, 2016-08-19 at 09:50 +0200, Paul Gevers wrote:
> Would you agree with me, i.e. do you know the following to be true,
> that
> peer authentication requires Unix socket (localhost)
This, I think, is the case:
https://www.postgresql.org/docs/current/static/auth-pg-hba-conf.html
peer says: "This is only available for local connections."

>  and that Unix
> socket requires peer identification for PostgreSQL?
This is, I think, definitely not the case... at least "trust" and
"reject" would work there as well, notice also that the socket is
created as e.g.:
srwxrwxrwx  1 postgres postgres0 Aug 20 02:49 .s.PGSQL.5432
i.e. everyone can write/read.

I haven't checked whether the other postgres-protocol-level auth
methods work with sockets, but I would imagine that things like "md5",
"password", probably "pam"... etc. would.




> I tried the other day to have password authentication via the Unix
> socket, but that failed:
> root@sid:/# psql -U icinga234 -W
> Password for user icinga234:
> psql: FATAL:  Peer authentication failed for user "icinga234"
hmm what was your pg_hba.conf looking like?
You should notice that postgres will IIRC always take the first
possible matching rule in pg_hba.conf, so if you have:
local   all all peer
local   all all md5
it
would always try peer.


> By the way, I see that PostgreSQL has a lot more authentication
> possibilities than when Sean invented dbconfig. I don't think I am
> going
> to support this on the short/mid term, but it may warrant improved
> messages here and there.
Well the problem is that supporting all these is probably quite
difficult...OTOH, most of the others would be (IMO) much more
beneficial than md5/password ;-)


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#834775: gcc-6: Massive package size increase w.r.t gcc-5

[Matthias Klose]

On 19.08.2016 18:44, Celelibi wrote:
> It looks like the size increase is due to debug informations in the
> ELF file /usr/lib/gcc/i686-linux-gnu/6/lto1. (Same for cc1 in package
> cpp-6.)
> 
> The debug informations do not seem to be mandatory for a proper use of
> gcc.

It is necessary for getting accurate backtrace for compiler bugs. Some thing as
was done for gcc-5.

> Could this be split into a gcc-6-dbg package in order to reduce
> gcc-6 to a saner size?

Yes, before the release, not now.

Bug#834867: lintian: Please allow uniformly compressed .debs in Debian

[Guillem Jover]

Package: lintian
Version: 2.5.46
Severity: wishlist

Hi!

As proposed on debian-devel [P], I'd like to switch dpkg-deb to
generate uniformly compressed .debs by default soon. This would
require for ftpmasters to agree, for lintian to stop emitting
autoreject tags and I guess for a backport to be installed in
ftp-master. I'm CCing ftpmasters so that they can voice in.

  [P] 

Thanks,
Guillem

Bug#832338: Severity for horizon back to serious, as django 1.10 is in Unstable

[Thomas Goirand]

On 08/19/2016 04:41 PM, Santiago Vila wrote:
> affects 832338 src:designate-dashboard
> affects 832338 src:manila-ui
> affects 832338 src:murano-dashboard
> affects 832338 src:python-app-catalog-ui
> affects 832338 src:sahara-dashboard
> affects 832338 src:trove-dashboard
> thanks
> 
> Hello.
> 
> Please correct me if I'm wrong, but it seems that all the packages
> above FTBFS because of this bug, hence I'm using affects so that this
> bug is shown on the respective web pages.
> 
> Thanks.

Hi Santiago,

This is correct. FYI, upstream has nearly finished working on Django
1.10 compat, and the next (beta) release is due for the end of the
month. The work was really huge, so it is unlikely that a backport to
the previous version (ie: version 9) will happen. More likely, we'll
have to wait until Horizon final version 10 is out in September, to
replace the version currently in Sid.

Cheers,

Thomas Goirand (zigo)

Bug#826833: i3status: FTBFS on !linux: error: 'IW_ESSID_MAX_SIZE' undeclared here

[Axel Beckert]

Control: tag -1 + patch

Hi Michael,

Michael Stapelberg wrote:
> I don’t have the means to test on non-linux.

Every DD has access to porterboxes... :-)

> Can you please verify that the following patch fixes the issue? (also
> attached for convenience)

Nope. Still FTBFS:

 CC src/print_volume.c
cc -Wdate-time -D_FORTIFY_SOURCE=2 -DSYSCONFDIR=\"/etc\" -DVERSION=\""2.10 
(2016-01-01)"\" -g -O2 -fdebug-prefix-map=/home/abe/debian/i3status=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -Wshadow 
-Wpointer-arith -Wcast-qual -Wsign-compare -g -std=gnu99 -pedantic -Iinclude  
-idirafter yajl-fallback -c -o src/print_wireless_info.o 
src/print_wireless_info.c
src/print_wireless_info.c: In function ‘print_wireless_info’:
src/print_wireless_info.c:524:41: error: ‘wireless_info_t {aka struct 
}’ has no member named ‘essid’
 maybe_escape_markup(info.essid, );
 ^
Makefile:79: recipe for target 'src/print_wireless_info.o' failed

The following patch works for me, but is probably quite ugly:

Index: i3status/src/print_wireless_info.c
===
--- i3status.orig/src/print_wireless_info.c 2016-08-20 01:46:12.460196000 
+0200
+++ i3status/src/print_wireless_info.c  2016-08-20 01:53:50.946062000 +0200
@@ -64,7 +64,9 @@
 
 typedef struct {
 int flags;
+#ifdef IW_ESSID_MAX_SIZE
 char essid[IW_ESSID_MAX_SIZE + 1];
+#endif
 #ifdef LINUX
 uint8_t bssid[ETH_ALEN];
 #endif
@@ -518,9 +520,11 @@
 }
 
 if (BEGINS_WITH(walk + 1, "essid")) {
+#ifdef IW_ESSID_MAX_SIZE
 if (info.flags & WIRELESS_INFO_FLAG_HAS_ESSID)
 maybe_escape_markup(info.essid, );
 else
+#endif
 *(outwalk++) = '?';
 walk += strlen("essid");
 }

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

Bug#792529: date: invalid option -- '0'

[Samuel Henrique]

>
> I just had another look at it, and I'm wondering, why the date is
> included at all in the VERSION? Is there a good reason for it?
> If not I would suggest to drop the date from the version.
>
​
Not at all, that was something introduced by the last maintainer, I've
removed it :)

I updated the patch to use the new SOURCE_DATE_EPOCH variable and
> noticed another issue related to file ordering (which we didn't detect
> at the time this bug was submitted), which it also fixes.
>

Thanks, it looks ok here.

Samuel Henrique O. P. [samueloph]

2016-08-19 20:41 GMT-03:00 Reiner Herrmann :

> Hi Samuel,
>
> On Fri, Aug 19, 2016 at 08:26:05PM -0300, Samuel Henrique wrote:
> > Thank you very much for digging into this and providing a patch, altough
> > there's a little problem.
> >
> > The last part, used to get the date, returns an error "date: invalid
> option
> > -- '0'".
>
> I just had another look at it, and I'm wondering, why the date is
> included at all in the VERSION? Is there a good reason for it?
> If not I would suggest to drop the date from the version.
>
> > If you'd like to make another patch or just point out how to fix it, i
> > would be glad to include it on the next revision (i'm currently doing a
> new
> > one and i'm willing to wait until this reproducibility problem is fixed
> to
> > upload).
>
> I updated the patch to use the new SOURCE_DATE_EPOCH variable and
> noticed another issue related to file ordering (which we didn't detect
> at the time this bug was submitted), which it also fixes.
>
> Kind regards,
>   Reiner
>

Bug#792529: date: invalid option -- '0'

[Reiner Herrmann]

Hi Samuel,

On Fri, Aug 19, 2016 at 08:26:05PM -0300, Samuel Henrique wrote:
> Thank you very much for digging into this and providing a patch, altough
> there's a little problem.
> 
> The last part, used to get the date, returns an error "date: invalid option
> -- '0'".

I just had another look at it, and I'm wondering, why the date is
included at all in the VERSION? Is there a good reason for it?
If not I would suggest to drop the date from the version.

> If you'd like to make another patch or just point out how to fix it, i
> would be glad to include it on the next revision (i'm currently doing a new
> one and i'm willing to wait until this reproducibility problem is fixed to
> upload).

I updated the patch to use the new SOURCE_DATE_EPOCH variable and
noticed another issue related to file ordering (which we didn't detect
at the time this bug was submitted), which it also fixes.

Kind regards,
  Reiner
diff --git a/debian/patches/series b/debian/patches/series
index b8fe866..fd25cdb 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@
 06_SDLK_KP_ENTER.diff
 07_nosound.diff
 flags.diff
+sort_source_files.diff
diff --git a/debian/patches/sort_source_files.diff b/debian/patches/sort_source_files.diff
new file mode 100644
index 000..b3da855
--- /dev/null
+++ b/debian/patches/sort_source_files.diff
@@ -0,0 +1,14 @@
+Author: Reiner Herrmann 
+Description: Sort source files to get deterministic linking order
+
+--- a/makefile
 b/makefile
+@@ -51,7 +51,7 @@
+ endif
+ 
+ # Source and object files
+-SOURCES = $(wildcard src/*.cpp)
++SOURCES = $(sort $(wildcard src/*.cpp))
+ OBJS = $(SOURCES:.cpp=.o)
+ OBJS := $(subst src/,obj/,$(OBJS))
+ 
diff --git a/debian/rules b/debian/rules
index 25f2641..a106a27 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-DEBIAN_RULES_VERSION = \"$(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ')\ $(shell date --rfc-3339=date)\"
+DEBIAN_RULES_VERSION = \"$(shell dpkg-parsechangelog | egrep '^Version:' | cut -f 2 -d ' ')\ $(shell date --rfc-3339=date -u -d @$(SOURCE_DATE_EPOCH))\"
 export DEB_CFLAGS_MAINT_APPEND += `sdl-config --cflags` -DVERSION=$(DEBIAN_RULES_VERSION)
 export DEB_LDFLAGS_MAINT_APPEND += `sdl-config --libs` -lSDL_image -lSDL_mixer -lGL -lGLU
 


signature.asc
Description: Digital signature

Bug#834866: ITP: python-whitenoise -- static file serving for WSGI applications

[Antonio Terceiro]

Package: wnpp
Severity: wishlist
Owner: Antonio Terceiro 

* Package name: python-whitenoise
  Version : 3.2.1
  Upstream Author : David Evans
* URL : http://whitenoise.evans.io
* License : MIT/Expat
  Programming Lang: Python
  Description : static file serving for WSGI applications

With a couple of lines of config, WhiteNoise allows your web app to serve its
own static files, making it a self-contained unit that can be deployed
anywhere without relying on nginx, Amazon S3 or any other external service.

This is specially useful if you want to deploy a WSGI application in an
application container (e.g. docker).

I plan to import this package into the Debian Python Modules Team
repositories, even though I don't plan to get myself deeply involved
with the team. I will subscribe to this specific package through the
package tracker.


signature.asc
Description: PGP signature

Bug#834865: ITP: libjs-jquery-selectize.js -- Extensible jQuery-based custom select UI control

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: libjs-jquery-selectize.js
  Version : 0.12.2
  Upstream Author : Brian Reavis 
* URL : https://github.com/selectize/selectize.js
* License : Apache-2.0 and Expat
  Programming Lang: JavaScript
  Description: Extensible jQuery-based custom select UI control

 Selectize is an extensible jQuery-based custom select UI
 control. It's useful for tagging, contact lists, country selectors,
 and so on. The goal is to provide a solid & usable experience with a
 clean and powerful API.
 .
 Features
 .
  * Smart Option Searching / Ranking
 .
Options are efficiently scored and sorted on-the-fly (using
libjs-sifter.js). Want to search an item's title *and*
description?  No problem.
 .
  * Caret between items
 .
Order matters sometimes. Use the left and right arrow keys to move
between selected items.
 .
  * Select and delete multiple items at once
 .
Hold down the CTRL key to select more than one item to delete.
 .
  * Díåcritîçs supported
 .
Great for international environments.
 .
  * Item creation
 .
Allow users to create items on the fly (async saving is supported;
the control locks until the callback is fired).
 .
  * Remote data loading
 .
For when you have thousands of options and want them provided by
the server as the user types.
 .
  * Clean API and code
 .
Interface with it and make modifications easily.
 .
  * Extensible
 .
Plugin API for developing custom features (uses
libjs-microplugin.js).
 .
  * Touch Support

This package is a dependency necessary for pagure.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#792529: date: invalid option -- '0'

[Samuel Henrique]

Hi Reiner,

Thank you very much for digging into this and providing a patch, altough
there's a little problem.

The last part, used to get the date, returns an error "date: invalid option
-- '0'".

If you'd like to make another patch or just point out how to fix it, i
would be glad to include it on the next revision (i'm currently doing a new
one and i'm willing to wait until this reproducibility problem is fixed to
upload).

Thanks.

Samuel Henrique O. P. [samueloph]

Bug#834832: marked as done (listen on [::]:69 works only once)

[Ron]

On Fri, Aug 19, 2016 at 08:54:08PM +, Debian Bug Tracking System wrote:
> From: Marc Haber 
> Subject: Re: Bug#834832: Acknowledgement (listen on [::]:69 works only once)
> To: 834832-d...@bugs.debian.org
> 
> Version: 5.2+20150808-1
> 
> Cannot reproduce this with the version in sid.

Ah, then yeah, you almost certainly hit #793921, which is fixed there.
Please do try to remember to fix the version if you reportbug from a
machine running a different version to where you hit the bug, that
would have made this a bit more immediately obvious (to me at least ;)

  Cheers,
  Ron

Bug#834832: listen on [::]:69 works only once

[Ron]

Hi Marc,

On Fri, Aug 19, 2016 at 05:09:58PM +0200, Marc Haber wrote:
> Package: tftpd-hpa
> Version: 5.2+20150808-1
> Severity: normal
> Tags: ipv6
> 
> Hi,
> 
> /usr/sbin/in.tftpd --listen --user tftp --address [::]:69 --secure /srv/tftp
> 
> serves only the first request. All subsequent requests result in "Aug
> 19 17:07:08 weave in.tftpd[13781]: connect: Address family not
> supported by protocol" written to the syslog and the request times out.
> 
> After restarting the process, exactly one request is served again.
> 
> setting --address 0.0.0.0:69 probably turns off IPv6, but makes IPv4
> work reliably. I don't think this is the itended behavior.

I think you're going to need to provide a bit more information about
exactly what you are doing here (like what address you are connecting
from at least) ...

"Only serves the first request" seems like a rather odd failure mode,
which makes me think you're not connecting the same way for the
subsequent requests ...


Are you really running 5.2+20150808-1 on the machine where you are
seeing this, since there was an issue with IPv4 mapped IPv6 addresses
that should have been fixed in that release (see #793921).

  Cheers,
  Ron

Bug#834861: cookiecutter: please make the build reproducible

[Chris Lamb]

forwarded 834861 https://github.com/audreyr/cookiecutter/pull/800
thanks


Regards,

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

Bug#834864: hisat2: FTBFS on kfreebsd-amd64: help2man: can't get `--help' info from ./hisat2

[Aaron M. Ucko]

Source: hisat2
Version: 2.0.4-1
Severity: important
Justification: fails to build from source

The kfreebsd-amd64 build of hisat2 failed:

  help2man ./hisat2 --no-info --name \
'graph-based alignment of short nucleotide reads to many genomes, 
wrapper script' \
> debian/hisat2.1
  help2man: can't get `--help' info from ./hisat2
  Try `--no-discard-stderr' if option outputs to stderr
  debian/rules:15: recipe for target 'override_dh_auto_build' failed

Could you please take a look?

Thanks!

Bug#834863: hisat2: FTBFS on *i386: invalid instruction suffix for `popcnt'

[Aaron M. Ucko]

Source: hisat2
Version: 2.0.4-1
Severity: important
Justification: fails to build from source

Builds of hisat2 for *i386 failed:

  gfm.h: Assembler messages:
  gfm.h:547: Error: invalid instruction suffix for `popcnt'
  gfm.h:547: Error: invalid instruction suffix for `popcnt'
  gfm.h:547: Error: invalid instruction suffix for `popcnt'
  [...]

Could you please take a look?

Thanks!

Bug#834860: libgtop: "glibtop: statvfs '/run/user/0/gvfs' failed" ten times every second in syslog

[jpp]

Package: libgtop2-7
Version: 2.28.5-2+b1
Severity: important
File: libgtop

Dear Maintainer,

Hello, I get 2/3 messages every second in the syslog :
org.mate.panel.applet.MultiLoadAppletFactory[21255]: glibtop: statvfs 
'/run/user/0/gvfs' failed

More than 132000 such messages a day in the syslog, the system was freshly 
re-installed on new disks.

Regards

JP P

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

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

Versions of packages libgtop2-7 depends on:
ii  libc62.19-18+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtop2-common  2.28.5-2
ii  libxau6  1:1.0.8-1

libgtop2-7 recommends no packages.

libgtop2-7 suggests no packages.

-- no debconf information

Bug#834861: cookiecutter: please make the build reproducible

[Chris Lamb]

Source: cookiecutter
Version: 1.4.0-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/0003-Reproducible-build.patch  1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/0003-Reproducible-build.patch  2016-08-19 
23:59:45.688697595 +0100
@@ -0,0 +1,54 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-19
+
+--- cookiecutter-1.4.0.orig/cookiecutter/config.py
 cookiecutter-1.4.0/cookiecutter/config.py
+@@ -22,6 +22,7 @@ from .exceptions import InvalidConfigura
+ 
+ logger = logging.getLogger(__name__)
+ 
++NOT_PROVIDED = object()
+ USER_CONFIG_PATH = os.path.expanduser('~/.cookiecutterrc')
+ 
+ DEFAULT_CONFIG = {
+@@ -68,7 +69,7 @@ def get_config(config_path):
+ return config_dict
+ 
+ 
+-def get_user_config(config_file=USER_CONFIG_PATH):
++def get_user_config(config_file=NOT_PROVIDED):
+ """Retrieve the config from a file or return the defaults if None is
+ passed. If an environment variable `COOKIECUTTER_CONFIG` is set up, try
+ to load its value. Otherwise fall back to a default file or config.
+@@ -77,6 +78,10 @@ def get_user_config(config_file=USER_CON
+ if config_file is None:
+ return copy.copy(DEFAULT_CONFIG)
+ 
++# Differentiate between being passed ``None`` and the default.
++if config_file is NOT_PROVIDED:
++config_file = USER_CONFIG_PATH
++
+ # Load the given config file
+ if config_file and config_file is not USER_CONFIG_PATH:
+ return get_config(config_file)
+--- cookiecutter-1.4.0.orig/cookiecutter/main.py
 cookiecutter-1.4.0/cookiecutter/main.py
+@@ -16,7 +16,7 @@ import logging
+ import os
+ import re
+ 
+-from .config import get_user_config, USER_CONFIG_PATH
++from .config import get_user_config, NOT_PROVIDED
+ from .exceptions import InvalidModeException, RepositoryNotFound
+ from .prompt import prompt_for_config
+ from .generate import generate_context, generate_files
+@@ -71,7 +71,7 @@ def expand_abbreviations(template, confi
+ def cookiecutter(
+ template, checkout=None, no_input=False, extra_context=None,
+ replay=False, overwrite_if_exists=False, output_dir='.',
+-config_file=USER_CONFIG_PATH):
++config_file=NOT_PROVIDED):
+ """
+ API equivalent to using Cookiecutter at the command line.
+ 
--- a/debian/patches/series 2016-08-19 23:41:14.643167381 +0100
--- b/debian/patches/series 2016-08-19 23:50:49.588100239 +0100
@@ -1,2 +1,3 @@
 0001-Don-t-test-for-.DS_Store.patch
 0002-Use-PyYAML-instead-of-poyo.patch
+0003-Reproducible-build.patch

Bug#834862: hisat2: FTBFS on non-x86: -msse2 (and often -m32) unrecognized

[Aaron M. Ucko]

Source: hisat2
Version: 2.0.4-1
Severity: important
Justification: fails to build from source

Builds of hisat2 for non-x86 architectures failed due to its usage of
-msse2, and in some cases also -m32.  Even where supported, these
options can limit portability, or in the case of -m32, select the
wrong ABI.

  g++: error: unrecognized command line option ‘-m32’
  g++: error: unrecognized command line option ‘-msse2’

Could you please take a look?

Thanks!

Bug#834766: piuparts: unowned rcX.d

[Holger Levsen]

tags 834766 + pending
affects 834524 piuparts.debian.org
thanks

Hi anarcat,

thanks for pointing this out!

On Fri, Aug 19, 2016 at 05:53:47PM -0400, anarcat wrote:
> On Thu, Aug 18, 2016 at 07:38:37PM +, Holger Levsen wrote:
> > package: piuparts
> > severity: important
> > > I recently uploaded a new version of cfengine3 and I got an error from 
> > > piuparts,
> > > 
> > > From what I can see it seems that /etc/rcX.d directories are unowned 
> > > after the
> > > purge, the new version did not introduce a change to the init script so I 
> > > was
> > > wondering if something has changed in the way init scripts are handled or 
> > > there
> > > is something in particular that I'm missing
> This seems to be a bug with the init-system-helpers package, which ships
> update-rc.d but doesn't cleanup those directories on removal, see
> #834524.
> 
> Not sure it's a problem with Piuparts...

on the piuparts side we are tracking this as 834766 for which I have a
applied a fix (ignoring those directories…) in the develop branch today
and which I also deployed on piuparts.d.o.

Affected packages have also been rescheduled, hopefully there will be
good results tomorrow ;-)

Rather obviously I think 834524 should indeed be properly fixed in
init-system-helpers so that the fix/workaround for 834524 can be
removed, hopefully rather sooner than later. 


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#834859: echoping: please make the build reproducible

[Chris Lamb]

Source: echoping
Version: 6.0.2-9
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/006_reproducible-build.diff1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/006_reproducible-build.diff2016-08-19 
23:25:14.950925873 +0100
@@ -0,0 +1,40 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2016-08-19
+
+--- echoping-6.0.2.orig/configure
 echoping-6.0.2/configure
+@@ -23320,8 +23320,13 @@ echo "${ECHO_T}disabled" >&6; }
+ fi
+ 
+ 
+-compil_date=`date +%Y-%m-%d`
+-hostname=$ac_hostname
++if test "x$SOURCE_DATE_EPOCH" = "x"; then
++  compil_date=`date +%Y-%m-%d`
++  hostname=$ac_hostname
++else
++  compil_date=`date --utc --date="@$SOURCE_DATE_EPOCH" +%Y-%m-%d`
++  hostname=generic
++fi
+ 
+ 
+ 
+--- echoping-6.0.2.orig/configure.ac
 echoping-6.0.2/configure.ac
+@@ -334,8 +334,13 @@ DISPLAY_SETTING(LIBIDN)
+ DISPLAY_SETTING(TOS)
+ DISPLAY_SETTING(PRIORITY)
+ 
+-compil_date=`date +%Y-%m-%d`
+-hostname=$ac_hostname
++if test "x$SOURCE_DATE_EPOCH" = "x"; then
++  compil_date=`date +%Y-%m-%d`
++  hostname=$ac_hostname
++else
++  compil_date=`date --utc --date="@$SOURCE_DATE_EPOCH" +%Y-%m-%d`
++  hostname=generic
++fi
+ AC_SUBST(hostname)
+ AC_SUBST(compil_options)
+ AC_SUBST(compil_date)
--- a/debian/patches/series 2016-08-19 23:13:25.240754904 +0100
--- b/debian/patches/series 2016-08-19 23:16:12.530211168 +0100
@@ -3,3 +3,4 @@
 003-fix-for-https-creashes.diff
 002-FTBFS_against_gnutls26_greater_the_2.7.x_fix.diff
 001-manpage_fixes.diff
+006_reproducible-build.diff

Bug#834858: php-common: Process with given PID might have be terminated, hence causing an error

[Dmitry Katsubo]

Package: php-common
Version: 1:41

The script /usr/lib/php/sessionclean in line 48 iterates through PIDs which
might terminate in meanwhile. As a result the system administrator receives the
following error mail from cron:

find: ‘/proc/23493/fd’: No such file or directory

Perhaps this situation can be ignored:

find "/proc/$pid/fd" -ignore_readdir_race ... 2>/dev/null

-- 
With best regards,
Dmitry

Bug#775541: NFS mounts fail at boot after Debian 8.5 upgrade

[paul . szabo]

After upgrading from Debian jessie 8.4 to 8.5, my NFS mounts in fstab
failed at boot (or reboot) time. To fix, I changed the one file
  /lib/systemd/system/remote-fs-pre.target
adding the line
  After=rpcbind.target
then my NFS mounts work correctly.

Question: should I have used After=rpcbind.service instead?

Thanks, Paul

Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics   University of SydneyAustralia

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

On 2016-08-19 17:56:29, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
>
> On Fri, 2016-08-19 at 17:35 -0400, Antoine Beaupré wrote:
>> TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
>> from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.
>> 
>> Charybdis 3.4 suffers from a regression which breaks authentication in
>> certain scenarios. The bug is now documented upstream here:
>> 
>> https://github.com/charybdis-ircd/charybdis/pull/211
> [...]
>> I have produced a simple patch which fixes the issue for Charybdis 3.5
>> here:
>> 
>> https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467
>
> That patch doesn't appear to have been applied to the package in
> unstable. That's a pre-requisite for considering it for an update in
> stable.

Understood. I am waiting for upstream to release 3.5.3 which will
include that patch, tonight, before doing a new upload.

>> I'd be happy to provide a debdiff if that is necessary, but that would
>> be actually harder to use than the provided patch, which is just put
>> in debian/patches with a proper changelog mention.
>
> We'll need to see a debdiff before agreeing an upload, yes, as has
> always been the policy for stable updates.

Of course.

> In what way is it "harder to use"? What does it consist of other than
> the patch, a series update and the changelog stanza?

I always find it harder to review a debdiff than the actual file in
debian/patches because of the "+ " prefixes that break syntax
highlighting.

But I'll be happy to provide a debdiff as soon as I ship the fix in
unstable, which should happen shortly.

Thanks!

A.

-- 
A ballot is like a bullet. You don't throw your ballots until you see
a target, and if that target is not within your reach, keep your
ballot in your pocket.
 - Malcom X

Bug#834524: init-system-helpers: does not own /etc/rc?.d

[anarcat]

On Wed, Aug 17, 2016 at 12:08:05AM +0200, Michael Biebl wrote:
> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> > Package: init-system-helpers
> > Version: 1.25
> > Severity: normal
> > 
> > Hi,
> > 
> > Recently both my daemon packages started to exhibit this piuparts error:
> > 
> > ERROR: FAIL: Package purging left files on system:
> >   /etc/rc2.d/not owned
> >   /etc/rc3.d/not owned
> >   /etc/rc4.d/not owned
> >   /etc/rc5.d/not owned
> > 
> > I think this is the result of sysv-rc losing its Essential flag, which means
> > it isn't present in minimal chroots (like those used by piuparts) anymore.
> > On the other hand, init-system-helpers imported update-rc.d in version 1.25,
> > and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
> > this results in piuparts failures in recently tested daemon packages.
> > 
> > If the above analysis is correct, please fix this.
> 
> Fix what exactly?

I am not sure what the fix is either, but it breaks Piuparts (#834766)
for a *lot* of packages:

https://piuparts.debian.org/sid/unowned_files_after_purge_error.html

arguably, not all those matches are due to this specific bug, but at
this point, any package that ships a daemon with dh_installinit (and
that's a lot of packages!) are now yielding piuparts errors all over the
place (e.g. postfix, openssh-server, apache2 all now fail piuparts).

This bug is marked as "pending", with a patch. Would that fix piuparts?
If so, I would highly recommend uploading the new version ASAP to keep
people like me from looking all over the place to figure out what broke
in their packages.

If not, it would be great to have some way forward. Punting the issue in
Piuparts' backyard may work, but I think it would be nice to get rid of
those old directories on systems that do not have init.d files
anymore...

Thanks!

A.


signature.asc
Description: Digital signature

Bug#834857: nagios-nrpe: please make the build reproducible

[Chris Lamb]

Source: nagios-nrpe
Version: 2.15-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps randomness
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi,

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

Whilst I "fix" the Diffie-Hellman key parameters, this is no worse
than the current situation in that they were random across builds:
everyone using the (for example) amd64 package was using the same
parameters anyway…

Patch attached.

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


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/debian/patches/00list 2016-08-19 21:13:52.279707711 +0100
--- b/debian/patches/00list 2016-08-19 22:32:45.467992041 +0100
@@ -4,3 +4,4 @@
 06_pid_directory.dpatch
 07_warn_ssloption.dpatch
 09_noremove_pid.dpatch
+10_reproducible_build.dpatch
--- a/debian/patches/10_reproducible_build.dpatch   1970-01-01 
01:00:00.0 +0100
--- b/debian/patches/10_reproducible_build.dpatch   2016-08-19 
22:37:32.874466180 +0100
@@ -0,0 +1,26 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 10_reproducible_build.dpatch by Chris Lamb 
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Make the build reproducible.
+
+@DPATCH@
+diff -urNad '--exclude=CVS' '--exclude=.svn' '--exclude=.git' 
'--exclude=.arch' '--exclude=.hg' '--exclude=_darcs' '--exclude=.bzr' 
pkg-nrpe~/update-version pkg-nrpe/update-version
+--- pkg-nrpe~/update-version   2016-08-19 21:13:52.279707711 +0100
 pkg-nrpe/update-version2016-08-19 22:29:19.434217944 +0100
+@@ -20,11 +20,11 @@
+ 
+ # Get date (two formats)
+ if [ -n "$2" ]; then
+-LONGDATE=`date -d "$2" "+%B %d, %Y"`
+-SHORTDATE=`date -d "$2" "+%m-%d-%Y"`
++LONGDATE=$(LC_ALL=C date -u -d "$2" "+%B %d, %Y")
++SHORTDATE=$(date -u -d "$2" "+%m-%d-%Y")
+ else
+-LONGDATE=`date "+%B %d, %Y"`
+-SHORTDATE=`date "+%m-%d-%Y"`
++LONGDATE=$(LC_ALL=C date -u -d "@${SOURCE_DATE_EPOCH:-$(date +%s)}" "+%B 
%d, %Y")
++SHORTDATE=$(date -u -d "@${SOURCE_DATE_EPOCH:-$(date +%s)}" "+%m-%d-%Y")
+ fi
+ 
+ # Current version number
--- a/debian/rules  2016-08-19 21:13:52.279707711 +0100
--- b/debian/rules  2016-08-19 22:52:57.430353150 +0100
@@ -10,6 +10,8 @@
dh $@ --with dpatch,autotools_dev
 
 override_dh_auto_configure:
+   # Save deterministic "openssl dhparam" output.
+   cp include/dh.h include/dh.h.orig
./configure \
--prefix=/usr \
--enable-ssl \
@@ -18,5 +20,7 @@
--localstatedir=/var \
--libexecdir=/usr/lib/nagios/plugins \
--libdir=/usr/lib/nagios
+   # Restore deterministic "openssl dhparam" output.
+   cp include/dh.h.orig include/dh.h
 
 override_dh_auto_install:

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Adam D. Barratt]

Control: tags -1 + moreinfo

On Fri, 2016-08-19 at 17:35 -0400, Antoine Beaupré wrote:
> TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
> from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.
> 
> Charybdis 3.4 suffers from a regression which breaks authentication in
> certain scenarios. The bug is now documented upstream here:
> 
> https://github.com/charybdis-ircd/charybdis/pull/211
[...]
> I have produced a simple patch which fixes the issue for Charybdis 3.5
> here:
> 
> https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467

That patch doesn't appear to have been applied to the package in
unstable. That's a pre-requisite for considering it for an update in
stable.

> I'd be happy to provide a debdiff if that is necessary, but that would
> be actually harder to use than the provided patch, which is just put
> in debian/patches with a proper changelog mention.

We'll need to see a debdiff before agreeing an upload, yes, as has
always been the policy for stable updates.

In what way is it "harder to use"? What does it consist of other than
the patch, a series update and the changelog stanza?

Regards,

Adam

Bug#833854: sks: no longer logs to /var/log/sks/

[anarcat]

On Tue, Aug 09, 2016 at 09:23:51PM +0200, Christoph Anton Mitterer wrote:
> On Tue, 2016-08-09 at 12:06 -0400, Daniel Kahn Gillmor wrote:
> > it'd also likely fix this piuparts failure for sks itself at least:
> > 
> >  https://piuparts.debian.org/sid/fail/sks_1.1.6-1.log
> > 
> > 0m26.6s ERROR: FAIL: Package purging left files on system:
> >   /etc/rc1.d/    not owned
> >   /etc/rc2.d/    not owned
> >   /etc/rc3.d/    not owned
> >   /etc/rc4.d/    not owned
> >   /etc/rc5.d/    not owned
> > 
> > 0m26.7s ERROR: FAIL: Installation and purging test.
> 
> Kinda strange... here these packages are sysv-rc owned... if they're
> left over, than somewhere is a bug (dpkg-helper scripts? init-helper-
> scripts?)

Did you have any other ideas on how to fix this? I'm seeing similar
problems with charybdis, and i'm starting to believe this is a larger
problem than just our two packages:

https://piuparts.debian.org/sid/unowned_files_after_purge_error.html

Charybdis's log is here:

https://piuparts.debian.org/sid/fail/charybdis_3.5.2p1-2.log

Actually, I got pointed towards this bug which seems to be common, in
piuparts:

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

So this doesn't seem to be sks at all.

(I found this bug googling for the piuparts error message so i figured
i would mention it here for future seekers of truth.)

A.

-- 
L'ennui avec la grande famille humaine, c'est que tout le monde veut
en être le père.
- Mafalda


signature.asc
Description: Digital signature

Bug#834856: python-pysam fails to build on mips64el arch.: failed test

[Jonathan Jackson]

Package: python-pysam
Version: 0.9.1.4+ds-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,



Python-pysam packages failed to build on March 24th on a mips64el 
architecture. Here is the tail of the failed-build log:

>testAlt (VariantFile_test.TestParsing) ... ok
>testChrom (VariantFile_test.TestParsing) ... ok
>testFilter (VariantFile_test.TestParsing) ... ok
>testFormat (VariantFile_test.TestParsing) ... ok
>testId (VariantFile_test.TestParsing) ... ok
>testInfo (VariantFile_test.TestParsing) ... Illegal instruction
>E: pybuild pybuild:274: test: plugin distutils failed with: exit code=132: cd 
>/«BUILDDIR»/python-pysam-0.9.1.4+ds/.pybuild/pythonX.Y_2.7/build; python2.7 -m 
>nose 
>dh_auto_test: pybuild --test -i python{version} -p 2.7 returned exit code 13
>debian/rules:36: recipe for target 'override_dh_auto_test' failed
>make[1]: *** [override_dh_auto_test] Error 25
>make[1]: Leaving directory '/«BUILDDIR»/python-pysam-0.9.1.4+ds'
>debian/rules:30: recipe for target 'build-arch' failed
>make: *** [build-arch] Error 2
>dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

Precise cause of failure during "testInfo" is unknown atm.

Here is a link to the full failed-build log: 
https://buildd.debian.org/status/fetch.php?pkg=python-pysam=mips64el=0.9.1.4%2Bds-1=1469339179


Thank you,
Jonathan Jackson

-- System Information:
Package: python-pysam 0.9.1.4+ds-1
Version: 0.9.1.4+ds-1
Source Version: 0.9.1.4+ds-1
Distribution: sid
Machine Architecture: mipsel
Host Architecture: mips64el
Build Architecture: mips64el

Bug#834766: piuparts: unowned rcX.d

[anarcat]

On Thu, Aug 18, 2016 at 07:38:37PM +, Holger Levsen wrote:
> package: piuparts
> severity: important
> version: 0.72
> x-debbugs-cc: Antonio Radici 
> 
> On Wed, Aug 17, 2016 at 06:59:16AM +, Antonio Radici wrote:
> > Hi there,
> > I recently uploaded a new version of cfengine3 and I got an error from 
> > piuparts,
> > the log is here:
> > https://piuparts.debian.org/sid/fail/cfengine3_3.7.4-2.log
> > 
> > From what I can see it seems that /etc/rcX.d directories are unowned after 
> > the
> > purge, the new version did not introduce a change to the init script so I 
> > was
> > wondering if something has changed in the way init scripts are handled or 
> > there
> > is something in particular that I'm missing
> > 
> > Thanks a lot in advance!
> 
> thanks for your report, Antonio!
> 
> I'm quite busy right now and will try to look into this next week. Help &
> patches much welcome!

This seems to be a bug with the init-system-helpers package, which ships
update-rc.d but doesn't cleanup those directories on removal, see
#834524.

Not sure it's a problem with Piuparts...

A.


signature.asc
Description: Digital signature

Bug#834855: transition: glibc 2.24

[Aurelien Jarno]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

We would like to get a transition slot for glibc 2.24. It is currently
available in experimental and has been built successfully on all
official architectures. For the debian-ports architectures the
situation also looks good except for hppa with multiple regressions in
the testsuite due to the use of gcc-6 instead of gcc-5. This is being
worked on, and I don't think we should not block the transition on that.

The glibc 2.24 is built using gcc-6 instead of gcc-5, the transition is
therefore important for the gcc-5 removal. This will be the version
shipped with Stretch, so this is the last major change before the
release. Of course we plan to improve things by fixing additional bugs,
mostly by tracking the upstream 2.24 stable branch as long as possible.

As the glibc is using symbol versioning, there is no soname change. That
said a few packages are using libc internal symbols and have to be
rebuilt for this transition:
 - apitrace
 - bro
 - dante
 - libnih
 - libnss-db
 - unscd

Here is the corresponding ben file:
  title = "glibc";
  is_affected = .depends ~ /libc[0-9.]* \(<

Bug#834844: libc6: Illegal instruction updating from 2.21-8 to 2.23-4 on mipsel

[Aurelien Jarno]

control: severity -1 normal
control: reassign -1 releases-notes
control: retitle -1 releases-notes: document that mips* arches now require a R2 
CPU

On 2016-08-19 21:23, E. Bosch wrote:
> 
> Package: libc6
> Version: 2.23-4
> Severity: important
> 
> On a Lemote Yeeloong machine (mipsel) with sid/unstable when I try to update
> libc6 to the last version I get the following error:
> 
> Preparing to unpack .../libc6_2.23-4_mipsel.deb ...
> Checking for services that may need to be restarted...
> Checking init scripts...
> Unpacking libc6:mipsel (2.23-4) over (2.21-8) ...
> dpkg: warning: subprocess old post-removal script was killed by signal
> (Illegal instruction)
> dpkg: trying script from the new package instead ...
> dpkg: error processing archive
> /var/cache/apt/archives/libc6_2.23-4_mipsel.deb (--unpack):
>  subprocess new post-removal script was killed by signal (Illegal
> instruction)
> dpkg: error while cleaning up:
>  subprocess installed pre-installation script was killed by signal (Illegal
> instruction)
> Errors were encountered while processing:
>  /var/cache/apt/archives/libc6_2.23-4_mipsel.deb
> 
> uname -a:
> Linux name 3.3.4 #2 Sun May 20 20:45:52 CEST 2012 mips64 GNU/Linux

This is something to be expected as the mips and mipsel port now
defaults to using R2 instructions set. This means the Loongson 2
CPUs are not supported anymore (this includes the Yeeloong machine).

I have asked many times to document this changes in the release notes,
but this hasn't been done yet. I am therefore reassigning the bug there,
Cc:ing debian-mips so that somone can take care of that.

Thanks,
Aurelien


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#834852: exim4-config: update-exim4.conf does NOT update ANYTHING

[Bob Goldberg]

Package: exim4-config
Version: 4.80-7+deb7u3
Severity: important
Tags: upstream

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
needed to update exim4 to shut off "purging environment" warning
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
after changing conf files, ran update-exim4.conf 
   * What was the outcome of this action?
discovered that running the update does NOT UPDATE A SINGLE THING.
discovered that update script EXPRESSLY checks for existence of 
/etc/exim4/exim4.conf and IF /var/lib/exim4/config.autogenerated is
EQUAL TO ITSELF!???  THEN EXIT - un-ceremoniously.
man page and docs for this script say NOTHING about specifying -o 
   * What outcome did you expect instead?
I expected the update script to update the xim4 configuration environment!!

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


-- Package-specific info:
Exim version 4.80 #3 built 25-Mar-2016 04:30:20
Copyright (c) University of Cambridge, 1995 - 2012
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012
Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /etc/exim4/exim4.conf

-- System Information:
Debian Release: 7.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages exim4-config depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49

exim4-config recommends no packages.

exim4-config suggests no packages.

-- Configuration Files:
/etc/exim4/exim4.conf.template changed [not included]
/etc/exim4/passwd.client [Errno 13] Permission denied: 
u'/etc/exim4/passwd.client'

-- debconf information excluded

Bug#834854: jessie-pu: package charybdis/3.4.2-5~deb8u1

[Antoine Beaupré]

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

TL;DR: Charybdis 3.4 (Jessie) introduces a regression (CertFP broken)
from Charybdis 3.3 (Wheezy). 7-line patch (attached) fixes the issue.

Charybdis 3.4 suffers from a regression which breaks authentication in
certain scenarios. The bug is now documented upstream here:

https://github.com/charybdis-ircd/charybdis/pull/211

To provide some context, IRC servers support authentication through
two main mechanisms: passwords and X509 certificates (or CertFP). The
latter works fine in 3.3, but has been broken by a code refactoring in
3.4. Since upstream does not test our code path often (GnuTLS, used
primarly to avoid OpenSSL licensing issues), this bug has been
overlooked for a while.

I have produced a simple patch which fixes the issue for Charybdis 3.5
here:

https://github.com/charybdis-ircd/charybdis/pull/211/commits/0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467

The patch can be trivially ported to Charybdis 3.4. Such a patch is
attached to this bug report.

Upstream made its own version of the patch, but I do not recommend
using it as it is harder to review and more difficult to backport to
3.4:

https://github.com/charybdis-ircd/charybdis/commit/3288fc46483db508acf2dcdd546a5aea54401de5

If this update isn't possible, I will have to go through backports to
ship 3.5 in Jessie, but that would be unfortunate because I believe
that backports are more for new functionalities than fixing such
regressions.

Another option would be to ship 3.5 directly in Jessie, as it is now
considered to be the "stable" upstream version. However, that diff is
actually much larger:

 299 files changed, 20157 insertions(+), 14302 deletions(-)

I'd be happy to provide a debdiff if that is necessary, but that would
be actually harder to use than the provided patch, which is just put
in debian/patches with a proper changelog mention.

Thanks for your consideration and hard work!

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

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug: https://github.com/charybdis-ircd/charybdis/pull/211

will be factored into 3.5.3, so hold on before merging...

>From 0ff0a0592de84dec2a2f46d9f8d6e22f6c1ee467 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= 
Date: Fri, 19 Aug 2016 11:53:59 -0400
Subject: [PATCH] fix error handling in gnutls certfp support

---
 libratbox/src/gnutls.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/libratbox/src/gnutls.c b/libratbox/src/gnutls.c
index f51211f..9bb69bb 100644
--- a/libratbox/src/gnutls.c
+++ b/libratbox/src/gnutls.c
@@ -608,18 +608,17 @@ rb_get_ssl_certfp(rb_fde_t *F, uint8_t certfp[RB_SSL_CERTFP_LEN], int method)
 	if (gnutls_certificate_type_get(SSL_P(F)) != GNUTLS_CRT_X509)
 		return 0;
 
-	if (gnutls_x509_crt_init() < 0)
-		return 0;
-
 	cert_list_size = 0;
 	cert_list = gnutls_certificate_get_peers(SSL_P(F), _list_size);
-	if (cert_list == NULL)
+	if (cert_list_size <= 0)
 	{
-		gnutls_x509_crt_deinit(cert);
 		return 0;
 	}
 
-	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) < 0)
+	if (gnutls_x509_crt_init() != GNUTLS_E_SUCCESS)
+		return 0;
+
+	if (gnutls_x509_crt_import(cert, _list[0], GNUTLS_X509_FMT_DER) != GNUTLS_E_SUCCESS)
 	{
 		gnutls_x509_crt_deinit(cert);
 		return 0;

Bug#834853: exim4-config: update-exim4.conf does NOT update ANYTHING

[Bob Goldberg]

Package: exim4-config
Version: 4.80-7+deb7u3
Severity: important
Tags: upstream

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
needed to update exim4 to shut off "purging envronment" warning
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
after changing conf files, ran update-exim4.conf
   * What was the outcome of this action?
discovered that running the update does NOT UPDATE A SINGLE THING.
discovered that update script EXPRESSLY checks for existence of
/etc/exim4/exim4.conf and IF /var/lib/exim4/config.autogenerated is
EQUAL TO ITSELF!???  THEN EXIT - un-ceremoniously.
man page and docs for this script say NOTHING about specifying -o
   * What outcome did you expect instead?
I expected the update script to update the xim4 configuration environment!

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


-- Package-specific info:
Exim version 4.80 #3 built 25-Mar-2016 04:30:20
Copyright (c) University of Cambridge, 1995 - 2012
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2012
Berkeley DB: Berkeley DB 5.1.29: (October 25, 2011)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz 
dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Configuration file is /etc/exim4/exim4.conf

-- System Information:
Debian Release: 7.11
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages exim4-config depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49

exim4-config recommends no packages.

exim4-config suggests no packages.

-- Configuration Files:
/etc/exim4/exim4.conf.template changed [not included]
/etc/exim4/passwd.client [Errno 13] Permission denied: 
u'/etc/exim4/passwd.client'

-- debconf information excluded

Bug#834848: RFA: guilt -- quilt for git; similar to Mercurial queues

[Iulian Udrea]

Control: retitle -1 O: guilt -- quilt for git; similar to Mercurial queues

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

[Jack Henschel]

Forgot the link, sorry:
[0] https://developer.chrome.com/extensions/crx

(The site features a script for packing CRX files)



signature.asc
Description: OpenPGP digital signature

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

[Jack Henschel]

Hi James,

thanks for your suggestions!

I have updated the dependencies and fixed the spelling errors.
Also, thanks for hinting at README.Debian, that is indeed a better place for 
these setup instruction (although fewer people might look there).

I'll still have to look at packaging the Chrome theme.
The Firefox is no problem, since it is just plain CSS (I have already included 
it in vertex-theme.install).
However the Chrome theme (in extra/Chrome) features CRX files [0] as well as a 
source directive.
Maybe I can figure out how to 'create' those CRX files and then ship them.

Best Regards,
Jack Henschel

On 08/18/2016 02:32 AM, James Lu wrote:
> (Disclaimer: I'm not a DD with upload privileges or anything, just a
> customization enthusiast with a bit of packaging knowledge.)
> 
> But, some notes anyways on a first glance:
> 
> * https://github.com/horst3180/vertex-theme lists gnome-themes-standard
> as a dependency, but that's missing from debian/control
> 
> * A man page for something like a theme set seems a bit odd to me;
> aren't those usually for binaries or config files? AFAIK,  README.debian
> is the most common way of writing notes such as how to configure extras:
> see https://www.debian.org/doc/manuals/maint-guide/dother.en.html#readme
> 
> * I noticed some typos in the man page: enviroments instead of
> environments (line 8), IceWeasel instead of Iceweasel (line 9)
> 
> Other than that, the package looks fine to me :)
> 
> Best,
> James
> 
> On 17/08/2016 2:48 PM, Jack Henschel wrote:
>> My progress is now in collab-maint (vertex-theme):
>>
>>  https://anonscm.debian.org/git/collab-maint/vertex-theme.git
>>  git://anonscm.debian.org/collab-maint/vertex-theme.git
>>
>> I'm using gbp with the branches master, upstream and pristine-tar.
>>
>> What still needs to be done:
>>
>>  * Check dependencies
>>  * Complete and verify manpage
>>
>> Oh, and also I still need to fix all the other mistakes I probably made :-)
>>
> 



signature.asc
Description: OpenPGP digital signature

Bug#834790: [Aptitude-devel] Bug#834790: aptitude hangs at "Loading cache" when unable to download package list

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


2016-08-19 10:36 Axel Beckert:

Control: tag -1 - d-i

Hi Kipp,

Kipp Cannon wrote:

After doing an update (pressing "u"), if an entry in /etc/apt/sources.list
was invalid or the server did not respond, then upon returning from the
screen of package list download progress bars aptitude displays "Loading
cache" in a box and then stops and makes any further progress.  The program
is somewhat responsive, for example, pressing "q" presents an option to
quit the program, but it is impossible to use the program to install or
upgrade any software until all servers in sources.list are responding
again.

[...]

How to reproduce:  put a typo in /etc/apt/sources.list, e.g., replace
"stretch" with "strecth", run aptitude, press "u".


Thanks for the detailed bug report. Will try to reproduce it.


I tried to reproduce it, using a wrong domain name and a wrong suite
name ("unstable2"), and failed to get the behaviour that you describe.
It doesn't get stuck in "loading cache" -- it just shows errors, and one
can continue normally.

Perhaps it behaves as you describe if the domain name is valid but the
server takes long time to reply, or if it's the only repository
configured in /etc/apt/sources.list or some special condition like that,
I don't have much time nor bandwidth to test combinations now.

But in that case, I think that for most of these possible conditions,
the errors would be clear enough for the user to know that s/he has to
rectify the file, and for that one probably will quit aptitude anyway,
or will occur to them that the typos and subsequent errors are the main
cause of aptitude being stuck, and will indicate to them that restarting
aptitude is necessary/advisable.


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#825524: liblexical-underscore-perl: FTBFS with Perl 5.24: Can't use global $_ in "my"

[gregor herrmann]

On Sun, 05 Jun 2016 01:03:29 +0200, gregor herrmann wrote:

> There's a pull request over at
> https://github.com/tobyink/p5-lexical-underscore/pull/2 which
> disables the problematic tests in newer perls.

And a longer patch is at
https://rt.cpan.org/Public/Bug/Display.html?id=108203


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#832593: apt-listbugs: Ctrl-C is not handled correctly

[Francesco Poli]

On Fri, 19 Aug 2016 15:18:35 +0200 Julian Andres Klode wrote:

> On Fri, Aug 19, 2016 at 02:14:22PM +0200, Julian Andres Klode wrote:
[...]
> > I basically fixed this locally in theory, but in practice
> > this does not seem fixable. We invoke our commands with a shell,
> > as you might be aware. The signal handling of shells is not portable:
> > 
> > This means that regardless what apt-listbugs exits with, the dash
> > shell it was invoked by will always exit with the SIGINT signal.

Yes, it will.
This should be due to the already mentioned (in this same bug
report [1]) bug #683671 [2], which appears to be unfortunately still
unfixed...

[1] https://bugs.debian.org/832593#15
[2] https://bugs.debian.org/683671

> 
> I now added a build-time option APT_SHELL; defaulting to /bin/bash,
> and a APT config option Dir::Bin::sh, defaulting to the value of
> APT_SHELL, that is used instead of /bin/sh.
> 
> So things should work now:
> 
> https://github.com/Debian/apt/compare/master...julian-klode:bugfix/sigint?expand=1

Thanks a lot, I am looking forward to testing this modification, as
soon as the new version of apt is uploaded to unstable or has migrated
to testing.

Bye!


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2eZg0bpEIO.pgp
Description: PGP signature

Bug#825611: libparse-http-useragent-perl: FTBFS with newer version.pm: t/02-parser.t failure

[gregor herrmann]

On Sat, 28 May 2016 10:34:02 +0300, Niko Tyni wrote:

>   not ok 700 - Frozen data matches parse result for 'Java/1.6.0_21' -> 
> generic_name_version -> 233
>   [...]
>   Test Summary Report
>   ---
>   t/02-parser.t (Wstat: 256 Tests: 754 Failed: 1)
> Failed test:  700
>   Non-zero exit status: 1

The upstream bug links to https://gist.github.com/dagolden/9559280
which explains that version->numify() doesn't treat underscores as a
tuple separator anymore but simply ignores them.

What we have here is:

- raw version: 1.6.0_21
- old version->numify: 1.006000_021 = expected by test currently
- new version->numify: 1.006021

What we can do is (both tested):
- Change the _numify function in lib/Parse/HTTP/UserAgent.pm to
  replace "_" with "." like it's done with "-" (and other things).
  Then version->numify ends up with 1.00621 with old and new
  version.pm. This of course needs a change of the expected value in
  t/data/robot/1 as well.
  This leads to a consistend result for versions with underscores but
  a new one.
- Mark the 'Java/1.6.0_21' in t/data/robot/1 as TODO.
  Less invasive but leads to different results for underscore
  versions depending on the version.pm version.

Not sure which option is better from a user perspective ...

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#484011: aptitude: Display archive-name|origin|Label in package view (add %t to Package-Display-Format)

[Manuel A. Fernandez Montecelo]

2016-08-19 21:50 GMT+01:00 Manuel A. Fernandez Montecelo
:
>
> I'm not sure if this is a good idea to do by default, because of the
> attached example.

Attached for real now :-P

-- 
Manuel A. Fernandez Montecelo 
- width=80

i libapt-inst2.0-dbgsym1.3~pre3   1.3~rc2
i libapt-pkg5.0-dbgsym 1.3~pre3   1.3~rc2
iulibopenscenegraph100v5-dbgsym  +41.0 kB  3.2.3+dfsg1-2  3.2.3+dfsg1-2+


ilibapt-inst2.0-dbgsym unstabl 1.3~pre3   1.3~rc2
ilibapt-pkg5.0-dbgsym  unstabl 1.3~pre3   1.3~rc2
iu   libopenscenegraph100v5-dbgs +41.0 kB  unstabl 3.2.3+dfsg1-2  3.2.3+dfsg1-2+


- width=110

p golang-github-jtolds-gls-devunstable  
  4.2.0-1
p golang-github-juju-ratelimit-devunstable  
  0.0~git2015112
pigolang-github-julienschmidt-httprouter-de +71.7 kB  unstable  
  1.1-1
p golang-github-jwilder-encoding-dev  unstable  
  0.0~git2016042
p

Bug#834851: does not serve out-of-tree symlinks

[Marc Haber]

Package: tftpd-hpa
Version: 5.2+20150808-1
Severity: normal

Hi,

if /srv/tftp/undionly.kpxe is a symlink to
/usr/lib/ipxe/undionly.kpxe, the tftp server does not transfer the
file. With the tftp-hpa client, this results in a zero bytes file
being written to the target directory, followed by the error message
"Error code 1: File not found". A symlink of pxelinux.0 to
debian-installer/amd64/pxelinux.0 gets served just fine, thankfully.

In the out-of-tree symlink case, the server does not write anything to
the log. This behavior is also not documented in the man page (I would
have stayed with aftpd if I knew this beforehand).

Since symlinking undionly.kpxe is a rather common setup and gives the
local admin the advantage of always delivering a current
undionly.kpxe, this is rather unhandy.

If it is actually intended, please document and consider asking
upstream to implement a command line switch to enable serving of
out-of-tree symlinks.

If this is not the intended behavior, it's a bug and needs fixing.

Greetings
Marc

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

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

Versions of packages tftpd-hpa depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.23-4
ii  libwrap0   7.6.q-25

tftpd-hpa recommends no packages.

Versions of packages tftpd-hpa suggests:
pn  pxelinux  

-- debconf information:
  tftpd-hpa/directory: /srv/tftp
  tftpd-hpa/address: 0.0.0.0:69
  tftpd-hpa/username: tftp
  tftpd-hpa/options: --secure

Bug#834768: RFS: codicefiscale/0.9-1

[Mattia Rizzolo]

On Fri, Aug 19, 2016 at 10:47:37PM +0200, Elena ``of Valhalla'' wrote:
> On 2016-08-18 at 22:27:42 +, Mattia Rizzolo wrote:
> > * Files-Excluded in d/copyright doesn't list all the files that are
> >   removed (at least according to `git diff --stat
> >   upstream/0.9..upstream/0.9+ds0`)
> >   besides, wrapping that list might not be a bad idea
> 
> Uhm, I used uscan to remove the files, so nothing that wasn't listed was
> removed.
> 
> Do you mean that I should explicitely list all of the content of the
> directory ``codicefiscale.egg-info``, instead of just listing the
> directory?

No, it just means that I rashed too much at reviewing it last night and
was already sleeping.
I didn't notice all those files where inside a directory -.-'

> > * why do you disable the tests?  (a comment on d/rules might not be a
> >   bad idea here either)
> >   + I see setup.py lists non-existant tests, if that's the issue maybe
> > you can get that tests= arg removed (or the actual tests included)
> > upstream?
> 
> That's exactly the issue, I've added a comment with a pointer to 
> https://github.com/ema/pycodicefiscale/issues/6

The project doesn't strike me as very active, but thanks :)

> > * just quickly skimming over the README, I think it would make sense to
> >   include in the binaries, as it provides quick documentation (I think)
> 
> yes, it does, you're right (added in git)

You did this:

diff --git a/debian/docs b/debian/docs
new file mode 100644
index 000..a1320b1
--- /dev/null
+++ b/debian/docs
@@ -0,0 +1 @@
+README.rst

This is not going to do what you expect, check both the produced
binaries ;)
(`debc` right after having built the package is handy for that, I run
it in a pbuilder hook for example)

-- 
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#484011: aptitude: Display archive-name|origin|Label in package view (add %t to Package-Display-Format)

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi,

2015-01-07 23:48 Wookey:

Package: aptitude
Version: 0.6.11-1+b1
Followup-For: Bug #484011

I have been adding %t to the display format in aptitude for many years
now. It's enormously useful and I really think it would be a benefit
to users to make this the default . Changing it on every install is
very dull.

i.e change the default from
%c%a%M%S %p %Z %v %V
to
%c%a%M%S %p %Z %t %v %V


I'm not sure if this is a good idea to do by default, because of the
attached example.


Probably most people use 80+ column-wide terminals nowadays if using
them as full screens or similar, but maybe many people continue to use
small terminals of that width, e.g. in tiled configurations.

Due to the +dfsgN of many of our versions (e.g. "3.2.3+dfsg1-2" in the
examples, with added "+b1" very often) and the long package names or
versions (and versions appear twice) of packages across the board for
different reasons [1], many lines do already don't appear fully even in
terminals much wider than 80 (also, see attached file again).

It looks to me that the's been an hyperinflation of package name and
version lengths in the last few years.


So I am not sure if it's a good idea to have this enabled by default,
since in many systems is not very useful (if only having one repository
enabled, plus perhaps "debug").  The packages can only come from
"stable" in that case, even if the repository is called "stable-debug".
Same for people who only use e.g. unstable or testing.

People who are mixing distros/suites are the ones more likely to know
that these options exist, same as you did, because you even mention it
in the bug reports.

I understand that it would be less annoying to have it by default,
instead of modifying it every time (or not every time, but at least if
you use multiple repositories in every machine that you administer, and
also wide terminals).

But since the extra space doesn't always come from free, and it's likely
to hurt more the people who use Debian in "simpler" use-cases and are
perhaps less learned in the matters of package managers, I am reluctant
to go ahead with this change.

So it will need further consideration.


Cheers.


[1] Like:
fonts-symbol, 2:102.7+LibO5.1.5~rc1-1
cube2, 0.0.20130203+dfsg-1+b2
libcmis, 0.5.1+git20160603-1
libgraphicsmagick-q16-3, 1.3.24+hg20160808-1
libgstreamer-plugins-base1.0-0, 1.8.3-1
libjson-glib-1.0-common, 1.2.0-1
qml-module-org-kde-bluezqt, 5.25.0-1
openstreetmap-map-icons-classic, 0.0.svn32805-1
qml-module-qtquick-controls-styles-breeze, 4:5.7.0-1
libdatetime-format-strptime-perl, 1.6800-1
golang-github-audriusbutkevicius-go-nat-pmp-dev, 0.0~git20150722.0.3a76720-1
libicsharpcode-nrefactory-csharp5.0-cil, 5.3.0+20130718.73b6d0f-3
libmono-system-componentmodel-dataannotations4.0-cil, 4.2.1.102+dfsg2-8
libmono-system-runtime-serialization-formatters-soap4.0-cil, 4.2.1.102+dfsg2-8
postgresql-9.5-python3-multicorn, 1.3.2-1
addresses-goodies-for-gnustep, 0.4.8-2+b1
cairo-dock-desklet-rendering-plug-in, 3.4.0-1.4+b2
gccgo-multilib-powerpc64-linux-gnu, 6.1.1--2

--
Manuel A. Fernandez Montecelo 

Bug#834768: RFS: codicefiscale/0.9-1

[Elena ``of Valhalla'']

On 2016-08-18 at 22:27:42 +, Mattia Rizzolo wrote:
> FYI: no need to explicitly CC d-mentors@, RFSes are somehow sent there
> anyway.

ack

> This is DPMT, where the usage of git is mandated, so I expect the git
> repository to match the generated .dsc (hence I'm ignoring mentors here)

it does (hopefully) match, yes 

> A few small things I'd like to see:
> 
> * you email address in d/copyright

added in git

> * Files-Excluded in d/copyright doesn't list all the files that are
>   removed (at least according to `git diff --stat
>   upstream/0.9..upstream/0.9+ds0`)
>   besides, wrapping that list might not be a bad idea

Uhm, I used uscan to remove the files, so nothing that wasn't listed was
removed.

Do you mean that I should explicitely list all of the content of the
directory ``codicefiscale.egg-info``, instead of just listing the
directory?

> * Also would be nice to see Build-Depends wrap-and-sort'ed

done in git

> * python3-codicefiscale uses ${python:Depends} instead of
>   ${python3:Depends}

uooops, fixed in git

> * why do you disable the tests?  (a comment on d/rules might not be a
>   bad idea here either)
>   + I see setup.py lists non-existant tests, if that's the issue maybe
> you can get that tests= arg removed (or the actual tests included)
> upstream?

That's exactly the issue, I've added a comment with a pointer to 
https://github.com/ema/pycodicefiscale/issues/6

> * in d/watch, you dversionmangle '.ds0' away, but you're using '+ds0'
>   actually, so it's not actually mangling anything

I hate single character typos, fixed in git (it appeared to work in
practice, but only because of versions ordering)

> * just quickly skimming over the README, I think it would make sense to
>   include in the binaries, as it provides quick documentation (I think)

yes, it does, you're right (added in git)

-- 
Elena ``of Valhalla''

Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Josh Triplett]

On Fri, Aug 19, 2016 at 05:27:57PM -0300, Felipe Sateler wrote:
> On 19 August 2016 at 17:23, Josh Triplett  wrote:
> > On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
> >> On 19 August 2016 at 15:24, Josh Triplett  wrote:
> >> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  
> >> > wrote:
> >> >> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> >> >> > Michael Biebl  writes:
> >> >> >
> >> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >> >> >>
> >> >> >>> Recently both my daemon packages started to exhibit this piuparts 
> >> >> >>> error:
> >> >> >>>
> >> >> >>> ERROR: FAIL: Package purging left files on system:
> >> >> >>>   /etc/rc2.d/ not owned
> >> >> >>>   /etc/rc3.d/ not owned
> >> >> >>>   /etc/rc4.d/ not owned
> >> >> >>>   /etc/rc5.d/ not owned
> >> >> >>>
> >> >> >>> I think this is the result of sysv-rc losing its Essential flag, 
> >> >> >>> which means
> >> >> >>> it isn't present in minimal chroots (like those used by piuparts) 
> >> >> >>> anymore.
> >> >> >>> On the other hand, init-system-helpers imported update-rc.d in 
> >> >> >>> version 1.25,
> >> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never 
> >> >> >>> removed).  All
> >> >> >>> this results in piuparts failures in recently tested daemon 
> >> >> >>> packages.
> >> >> >>>
> >> >> >>> If the above analysis is correct, please fix this.
> >> >> >>
> >> >> >> Fix what exactly?
> >> >> >
> >> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> >> >> > directories.  (Removing them if they become empty is another option, 
> >> >> > but
> >> >> > does not sound a very good idea.)  Previously they were owned by
> >> >> > sysv-rc, which also provided update-rc.d, which used these 
> >> >> > directories.
> >> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> >> >> > followed along, but was forgotten, I guess.
> >> >>
> >> >> Indeed. init-system-helpers even already did this for
> >> >> /etc/systemd/system. I have added the rc?.d directories to the list.
> >> >>
> >> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
> >> >
> >> > This will cause the directories to continue to exist even when empty.
> >>
> >> Yes.
> >>
> >> >
> >> > Ideally, these directories could become empty and disappear eventually,
> >> > on a system not running sysvinit.  What would it take for that to
> >> > happen?
> >>
> >> A lot more than reverting that commit :)
> >>
> >> On my system I see:
> >>
> >> % dpkg -S /etc/init.d/*
> >> avahi-daemon: /etc/init.d/avahi-daemon
> >> binfmt-support: /etc/init.d/binfmt-support
> >> cron: /etc/init.d/cron
> >> dbus: /etc/init.d/dbus
> >> util-linux: /etc/init.d/hwclock.sh
> >> procps: /etc/init.d/procps
> >> rsync: /etc/init.d/rsync
> >> openssh-server: /etc/init.d/ssh
> >> sudo: /etc/init.d/sudo
> >> udev: /etc/init.d/udev
> >> unattended-upgrades: /etc/init.d/unattended-upgrades
> >> x11-common: /etc/init.d/x11-common
> >>
> >> util-linux is essential, udev is pretty much required on
> >> non-containers. Procps and cron are Priority important.
> >>
> >> As long as we support non-systemd init, all of those need to ship init
> >> scripts. And as long as they do, there will be /etc/rc?.d directories.
> >
> > Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
> > unless an init system making use of rc?.d links is installed.
> 
> Systemd is an init systemd that makes use of rc?.d links, as it uses
> that information to determine if a service without native unit is
> enabled.

That seems potentially fixable, by making the "disable" mechanism create
a foo.service -> /dev/null link.  (Or, more easily, by providing a
native unit.)

(I'm not arguing that this should happen *soon*, but I look forward to
moving in that direction.)

> >  (As a
> > random possibility, installing sysvinit or similar could trigger the
> > generation of rc?.d scripts, avoiding the need to generate them at
> > install time.  That would be a lot easier if update-rc.d ran via a
> > trigger, which seems a lot more plausible now that it no longer accepts
> > any kind of priority options and all such information must live in the
> > script.)
> 
> Unfortunately, invoke-rc.d relies on the enablement links as well.
> Thus update-rc.d must happen before invoke-rc.d. Converting
> invoke-rc.d to triggers is not as trivial, as not all scripts have to
> be started on package installation/upgrade, and restart-on-upgrade
> behavior differs.

That seems like something we should eventually migrate to something like
systemd-preset files, which would also make it much more convenient for
admins to set policies like whether to start services on installation or
not.  In addition, that would eliminate a huge number of maintainer
scripts in favor of declarative 

Bug#834850: glusterfs-server: Cannot mount file systems on second machine after update

[Thomas Renard]

Package: glusterfs-server
Version: 3.8.1-1
Severity: important

Dear Maintainer,

I have a cluster of two brick servers running glusterfs with mounted dirs from 
gluster.

 * Upgrade first machine to 3.8.2-1 and reboot it (works fine, other
   machine still on 3.8.1-1)
 * Upgrade second machine to 3.8.2-1 and reboot it

Expected: Machine 2 boots and mounts all mountpoints defined in fstab

Actual:
 * systemctl status is degraded, mounting failed.
 * when mounting by hand an error occurs ("read log for more")

fstab looks like this:

thishost:/name /data/name glusterfs 
defaults,_netdev,backupvolfile-server=otherhost 0 0

here otherhost 192.168.1.10, thishost 192.168.1.11 (see log)

example of such a log:

[2016-08-19 18:52:11.568199] E [socket.c:2391:socket_connect_finish]
0-glusterfs: connection to 192.168.1.10:24007 failed
(Verbindungsaufbau abgelehnt)
[2016-08-19 18:52:11.568292] E [glusterfsd-mgmt.c:1902:mgmt_rpc_notify]
0-glusterfsd-mgmt: failed to connect with remote-host: myhost.local
(Der Socket ist nicht verbunden)
[2016-08-19 18:52:11.568319] I [glusterfsd-mgmt.c:1919:mgmt_rpc_notify]
0-glusterfsd-mgmt: Exhausted all volfile servers

(sorry for the german localization)

journalctl -u data-name.mount shows error messages of the type:

failed to get the 'volume file' from server

(which occurs on an upstream bug for older version of glusterfs 3.4.2)

I could not find anything upstream for this effect for 3.8.2.

Then I reinstalled 3.8.1-1 from snapshots.debian.org and after rebooting
the machines everything works fine again.

Sorry for reporting this only now and not on unstable - I did not check it
on a testing system before (and learned something now)...


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

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

Versions of packages glusterfs-server depends on:
ii  glusterfs-client  3.8.1-1
ii  glusterfs-common  3.8.1-1
ii  libacl1   2.2.52-3
ii  libc6 2.23-4
ii  libncurses5   6.0+20160625-1
ii  libreadline6  6.3-8+b4
ii  libssl1.0.2   1.0.2h-1
ii  libtinfo5 6.0+20160625-1
ii  libuuid1  2.28-6
ii  libxml2   2.9.4+dfsg1-1+b1
ii  lsb-base  9.20160629
ii  python2.7.11-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages glusterfs-server recommends:
ii  nfs-common  1:1.2.8-9.2

glusterfs-server suggests no packages.

-- Configuration Files:
/etc/init.d/glusterfs-server changed [not included]

-- no debconf information

Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Felipe Sateler]

On 19 August 2016 at 17:23, Josh Triplett  wrote:
> On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
>> On 19 August 2016 at 15:24, Josh Triplett  wrote:
>> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  
>> > wrote:
>> >> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
>> >> > Michael Biebl  writes:
>> >> >
>> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
>> >> >>
>> >> >>> Recently both my daemon packages started to exhibit this piuparts 
>> >> >>> error:
>> >> >>>
>> >> >>> ERROR: FAIL: Package purging left files on system:
>> >> >>>   /etc/rc2.d/ not owned
>> >> >>>   /etc/rc3.d/ not owned
>> >> >>>   /etc/rc4.d/ not owned
>> >> >>>   /etc/rc5.d/ not owned
>> >> >>>
>> >> >>> I think this is the result of sysv-rc losing its Essential flag, 
>> >> >>> which means
>> >> >>> it isn't present in minimal chroots (like those used by piuparts) 
>> >> >>> anymore.
>> >> >>> On the other hand, init-system-helpers imported update-rc.d in 
>> >> >>> version 1.25,
>> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed). 
>> >> >>>  All
>> >> >>> this results in piuparts failures in recently tested daemon packages.
>> >> >>>
>> >> >>> If the above analysis is correct, please fix this.
>> >> >>
>> >> >> Fix what exactly?
>> >> >
>> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
>> >> > directories.  (Removing them if they become empty is another option, but
>> >> > does not sound a very good idea.)  Previously they were owned by
>> >> > sysv-rc, which also provided update-rc.d, which used these directories.
>> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
>> >> > followed along, but was forgotten, I guess.
>> >>
>> >> Indeed. init-system-helpers even already did this for
>> >> /etc/systemd/system. I have added the rc?.d directories to the list.
>> >>
>> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
>> >
>> > This will cause the directories to continue to exist even when empty.
>>
>> Yes.
>>
>> >
>> > Ideally, these directories could become empty and disappear eventually,
>> > on a system not running sysvinit.  What would it take for that to
>> > happen?
>>
>> A lot more than reverting that commit :)
>>
>> On my system I see:
>>
>> % dpkg -S /etc/init.d/*
>> avahi-daemon: /etc/init.d/avahi-daemon
>> binfmt-support: /etc/init.d/binfmt-support
>> cron: /etc/init.d/cron
>> dbus: /etc/init.d/dbus
>> util-linux: /etc/init.d/hwclock.sh
>> procps: /etc/init.d/procps
>> rsync: /etc/init.d/rsync
>> openssh-server: /etc/init.d/ssh
>> sudo: /etc/init.d/sudo
>> udev: /etc/init.d/udev
>> unattended-upgrades: /etc/init.d/unattended-upgrades
>> x11-common: /etc/init.d/x11-common
>>
>> util-linux is essential, udev is pretty much required on
>> non-containers. Procps and cron are Priority important.
>>
>> As long as we support non-systemd init, all of those need to ship init
>> scripts. And as long as they do, there will be /etc/rc?.d directories.
>
> Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
> unless an init system making use of rc?.d links is installed.

Systemd is an init systemd that makes use of rc?.d links, as it uses
that information to determine if a service without native unit is
enabled.

>  (As a
> random possibility, installing sysvinit or similar could trigger the
> generation of rc?.d scripts, avoiding the need to generate them at
> install time.  That would be a lot easier if update-rc.d ran via a
> trigger, which seems a lot more plausible now that it no longer accepts
> any kind of priority options and all such information must live in the
> script.)

Unfortunately, invoke-rc.d relies on the enablement links as well.
Thus update-rc.d must happen before invoke-rc.d. Converting
invoke-rc.d to triggers is not as trivial, as not all scripts have to
be started on package installation/upgrade, and restart-on-upgrade
behavior differs.


-- 

Saludos,
Felipe Sateler

Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Josh Triplett]

On Fri, Aug 19, 2016 at 04:51:12PM -0300, Felipe Sateler wrote:
> On 19 August 2016 at 15:24, Josh Triplett  wrote:
> > On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  
> > wrote:
> >> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> >> > Michael Biebl  writes:
> >> >
> >> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >> >>
> >> >>> Recently both my daemon packages started to exhibit this piuparts 
> >> >>> error:
> >> >>>
> >> >>> ERROR: FAIL: Package purging left files on system:
> >> >>>   /etc/rc2.d/ not owned
> >> >>>   /etc/rc3.d/ not owned
> >> >>>   /etc/rc4.d/ not owned
> >> >>>   /etc/rc5.d/ not owned
> >> >>>
> >> >>> I think this is the result of sysv-rc losing its Essential flag, which 
> >> >>> means
> >> >>> it isn't present in minimal chroots (like those used by piuparts) 
> >> >>> anymore.
> >> >>> On the other hand, init-system-helpers imported update-rc.d in version 
> >> >>> 1.25,
> >> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  
> >> >>> All
> >> >>> this results in piuparts failures in recently tested daemon packages.
> >> >>>
> >> >>> If the above analysis is correct, please fix this.
> >> >>
> >> >> Fix what exactly?
> >> >
> >> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> >> > directories.  (Removing them if they become empty is another option, but
> >> > does not sound a very good idea.)  Previously they were owned by
> >> > sysv-rc, which also provided update-rc.d, which used these directories.
> >> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> >> > followed along, but was forgotten, I guess.
> >>
> >> Indeed. init-system-helpers even already did this for
> >> /etc/systemd/system. I have added the rc?.d directories to the list.
> >>
> >> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
> >
> > This will cause the directories to continue to exist even when empty.
> 
> Yes.
> 
> >
> > Ideally, these directories could become empty and disappear eventually,
> > on a system not running sysvinit.  What would it take for that to
> > happen?
> 
> A lot more than reverting that commit :)
> 
> On my system I see:
> 
> % dpkg -S /etc/init.d/*
> avahi-daemon: /etc/init.d/avahi-daemon
> binfmt-support: /etc/init.d/binfmt-support
> cron: /etc/init.d/cron
> dbus: /etc/init.d/dbus
> util-linux: /etc/init.d/hwclock.sh
> procps: /etc/init.d/procps
> rsync: /etc/init.d/rsync
> openssh-server: /etc/init.d/ssh
> sudo: /etc/init.d/sudo
> udev: /etc/init.d/udev
> unattended-upgrades: /etc/init.d/unattended-upgrades
> x11-common: /etc/init.d/x11-common
> 
> util-linux is essential, udev is pretty much required on
> non-containers. Procps and cron are Priority important.
> 
> As long as we support non-systemd init, all of those need to ship init
> scripts. And as long as they do, there will be /etc/rc?.d directories.

Not necessarily.  /etc/init.d will need to exist; /etc/rc?.d doesn't,
unless an init system making use of rc?.d links is installed.  (As a
random possibility, installing sysvinit or similar could trigger the
generation of rc?.d scripts, avoiding the need to generate them at
install time.  That would be a lot easier if update-rc.d ran via a
trigger, which seems a lot more plausible now that it no longer accepts
any kind of priority options and all such information must live in the
script.)

Bug#829940: gnome-multi-writer: Uses deprecated gnome-common macros/variables

[Herbert Fortes]

Hi,

> > 
> > deprecated variables
> > 
> > The following variables used in gnome-autogen.sh have been declared
> > deprecated [3]:
> > 
> >  REQUIRED_GNOME_DOC_UTILS_VERSION
> >  REQUIRED_DOC_COMMON_VERSION
> >  USE_COMMON_DOC_BUILD
> >  FORBIDDEN_M4MACROS
> >  GNOME2_DIR
> >  GNOME2_PATH

> >  USE_GNOME2_MACROS

> >
[...]
> > If you have further question, please don't hesitate to ask.
> > 
> > Regards,
> > Michael
> > 
> > [1] https://git.gnome.org/browse/gnome-common/commit/?id=6684e2fa5
> > [2] https://git.gnome.org/browse/gnome-common/commit/?id=1f60e9536
> > [3] https://git.gnome.org/browse/gnome-common/commit/?id=4c8d8ad93
> > [4] https://git.gnome.org/browse/gnome-common/commit/?id=b57bae0be
> > [5] https://git.gnome.org/browse/gnome-common/commit/?id=2bffd7e1u
> > [6] https://wiki.gnome.org/Projects/GnomeCommon/Migration
> 

The new release has an option '--enable-compile-warnings=no',
so it was possible to build the package. But gnome-autogen.sh
still has:

gnome-multi-writer-3.21.90$ grep -r 'GNOME_' ./
./autogen.sh:REQUIRED_AUTOMAKE_VERSION=1.7 GNOME_DATADIR="$gnome_datadir" 
USE_GNOME2_MACROS=1 . gnome-autogen.sh

How this affect the program ? I will orphan this package, but
want to give away a good package.



regards,
-- 
Herbert Parentes Fortes Neto (hpfn)

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

Bug#832821: when configured address contains .onion, things go wrong

[Donncha O'Cearbhaill]

On Fri, 29 Jul 2016 07:17:00 + Peter Palfrader 
wrote:
> Package: onionbalance
> Version: 0.1.4-1~bpo8+1
> Severity: normal
> 
> Hi,
> 
> I had this config:
> 
> |  - # ftp.debian.org via vwakviie2ienjx6t.onion
> |key: private_keys/ftp.debian.org.key
> |instances:
> |  - address: kpw6vrobjzz4yd7x.onion
> |name: klecker-ftp.debian.org
> 
> And shortly after start up I would get
> | [WARNING]: Received a descriptor with address kpw6vrobjzz4yd7x.onion that 
> did not match any configured service instances.
> 
> Digging a little, suggests that onionbalance would try to set up things
> and fetch the descriptor for kpw6vrobjzz4yd7x.onion.  However, when it
> was getting the descriptor, it ended up being confused about the .onion
> extensioni.  I added some log lines to descriptor.py's descriptor_received():
> 
> | [WARNING]: [weasel] iterating over configured services
> | [WARNING]: [weasel]  service  0x7f03bff246d8>
> | [WARNING]: [weasel]   instance  0x7f03bff24588>
> | [WARNING]: [weasel]onion_address kpw6vrobjzz4yd7x.onion
> | [WARNING]: [weasel]descriptor_onion_address kpw6vrobjzz4yd7x
>^^ of course, == will fail between these.
> | [WARNING]: Received a descriptor with address kpw6vrobjzz4yd7x.onion that 
> did not match any configured service instances.
> 
> I suggest that onionbalance either handle .onion as address everywhere,
> or that it reject them earlier.

I have fixed this bug upstream in
https://github.com/DonnchaC/onionbalance/issues/37. The fix has not been
included in a release yet, but it is scheduled for release 0.1.5.

Regards,
Donncha

Bug#834849: (no subject)

[Breno Leitao]

Package: cappuccino
Version: 0.5.1-2.3
Severity: normal

Currently cappuccino does not run properly on a default Debian system
because it expects that polygen (which is a game) is on the PATH, which
is not true.

In that way, the software complains as following:

sh: 1: polygen: not found
sh: 1: polygen: not found

Since this package is orphaned, I am planning to take it and fix this
(and other) problems.

Bug#825609: Pending fixes for bugs in the libnet-snpp-perl package

[pkg-perl-maintainers]

tag 825609 + pending
thanks

Some bugs in the libnet-snpp-perl package are closed in revision
31a5e8df3f8a2a56f5547b6f0b13503178ed4363 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libnet-snpp-perl.git/commit/?id=31a5e8d

Commit message:

Add patch from CPAN RT for libnet-3.08 compatibility.

Closes: #825609

Bug#834848: RFA: guilt -- quilt for git; similar to Mercurial queues

[Iulian Udrea]

Package: wnpp
Severity: normal

Long description:

Guilt (Git Quilt) is a series of bash scripts which add a Mercurial queues-like
functionality and interface to git.  The one distinguishing feature from other
quilt-like porcelains, is the format of the patches directory.
.
All the information is stored as plain text - a series file and the patches (one
per file). This easily lends itself to versioning the patches using any number
of SCMs.

Homepage: http://repo.or.cz/w/guilt.git

Cheers,
Iulian

Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Felipe Sateler]

On 19 August 2016 at 15:24, Josh Triplett  wrote:
> On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  wrote:
>> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
>> > Michael Biebl  writes:
>> >
>> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
>> >>
>> >>> Recently both my daemon packages started to exhibit this piuparts error:
>> >>>
>> >>> ERROR: FAIL: Package purging left files on system:
>> >>>   /etc/rc2.d/ not owned
>> >>>   /etc/rc3.d/ not owned
>> >>>   /etc/rc4.d/ not owned
>> >>>   /etc/rc5.d/ not owned
>> >>>
>> >>> I think this is the result of sysv-rc losing its Essential flag, which 
>> >>> means
>> >>> it isn't present in minimal chroots (like those used by piuparts) 
>> >>> anymore.
>> >>> On the other hand, init-system-helpers imported update-rc.d in version 
>> >>> 1.25,
>> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  
>> >>> All
>> >>> this results in piuparts failures in recently tested daemon packages.
>> >>>
>> >>> If the above analysis is correct, please fix this.
>> >>
>> >> Fix what exactly?
>> >
>> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
>> > directories.  (Removing them if they become empty is another option, but
>> > does not sound a very good idea.)  Previously they were owned by
>> > sysv-rc, which also provided update-rc.d, which used these directories.
>> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
>> > followed along, but was forgotten, I guess.
>>
>> Indeed. init-system-helpers even already did this for
>> /etc/systemd/system. I have added the rc?.d directories to the list.
>>
>> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
>
> This will cause the directories to continue to exist even when empty.

Yes.

>
> Ideally, these directories could become empty and disappear eventually,
> on a system not running sysvinit.  What would it take for that to
> happen?

A lot more than reverting that commit :)

On my system I see:

% dpkg -S /etc/init.d/*
avahi-daemon: /etc/init.d/avahi-daemon
binfmt-support: /etc/init.d/binfmt-support
cron: /etc/init.d/cron
dbus: /etc/init.d/dbus
util-linux: /etc/init.d/hwclock.sh
procps: /etc/init.d/procps
rsync: /etc/init.d/rsync
openssh-server: /etc/init.d/ssh
sudo: /etc/init.d/sudo
udev: /etc/init.d/udev
unattended-upgrades: /etc/init.d/unattended-upgrades
x11-common: /etc/init.d/x11-common

util-linux is essential, udev is pretty much required on
non-containers. Procps and cron are Priority important.

As long as we support non-systemd init, all of those need to ship init
scripts. And as long as they do, there will be /etc/rc?.d directories.

-- 

Saludos,
Felipe Sateler

Bug#834847: RFA: modglue

[Iulian Udrea]

Package: wnpp
Severity: normal

Library of cadabra. See
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834846.

Cheers,
Iulian

Bug#834846: RFA: cadabra -- field-theory motivated computer algebra system

[Iulian Udrea]

Package: wnpp
Severity: normal

Long description: 

Cadabra is a computer algebra system designed specifically for the solution of
problems encountered in field theory. It has extensive functionality for tensor
polynomial simplification including multi-term symmetries, fermions and
anti-commuting variables, Clifford algebras and Fierz transformations, implicit
coordinate dependence, multiple index types and many more. The input format is
a subset of TeX.

Homepage: http://cadabra.phi-sci.com/

Cheers,
Iulian

Bug#834845: chicken: CVE-2016-6830 CVE-2016-6831

[Salvatore Bonaccorso]

Source: chicken
Version: 4.9.0.1-1
Severity: grave
Tags: security upstream patch

Hi,

the following vulnerabilities were published for chicken.

CVE-2016-6830[0]:
|Buffer overrun in CHICKEN Scheme's "process-execute" and
|"process-spawn" procedures from the posix unit

CVE-2016-6831[1]:
|Memory leak in CHICKEN Scheme's process-execute and process-spawn
|procedures

The upstream patch [2] addresses both CVEs.

If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6830
[1] https://security-tracker.debian.org/tracker/CVE-2016-6831
[2] 
https://lists.nongnu.org/archive/html/chicken-hackers/2016-07/txtSWHYeFeG0R.txt

Regards,
Salvatore

Bug#834844: libc6: Illegal instruction updating from 2.21-8 to 2.23-4 on mipsel

[E. Bosch]

Package: libc6
Version: 2.23-4
Severity: important

On a Lemote Yeeloong machine (mipsel) with sid/unstable when I try to 
update libc6 to the last version I get the following error:


Preparing to unpack .../libc6_2.23-4_mipsel.deb ...
Checking for services that may need to be restarted...
Checking init scripts...
Unpacking libc6:mipsel (2.23-4) over (2.21-8) ...
dpkg: warning: subprocess old post-removal script was killed by signal 
(Illegal instruction)

dpkg: trying script from the new package instead ...
dpkg: error processing archive 
/var/cache/apt/archives/libc6_2.23-4_mipsel.deb (--unpack):
 subprocess new post-removal script was killed by signal (Illegal 
instruction)

dpkg: error while cleaning up:
 subprocess installed pre-installation script was killed by signal 
(Illegal instruction)

Errors were encountered while processing:
 /var/cache/apt/archives/libc6_2.23-4_mipsel.deb

uname -a:
Linux name 3.3.4 #2 Sun May 20 20:45:52 CEST 2012 mips64 GNU/Linux

Apt aborts the installation and the system keeps running.

If I force the update manually I get a broken system giving "Illegal 
instruction" error for each process spawn. If I reboot I get a kernel 
panic (sorry, I haven't the message but I suppose it stuck on init), I 
reverted the situation mounting the disk on another machine and doing 
rollback to 2.21-8.

Bug#834843: ruby-doorkeeper: CVE-2016-6582

[Salvatore Bonaccorso]

Source: ruby-doorkeeper
Version: 3.1.0-1
Severity: grave
Tags: security upstream patch
Forwarded: https://github.com/doorkeeper-gem/doorkeeper/issues/875

Hi,

the following vulnerability was published for ruby-doorkeeper.

CVE-2016-6582[0]:
Doorkeeper does not revoke tokens and wrong auth/auth method

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-6582

Regards,
Salvatore

Bug#811882: Fix for the knutclient FTBFS

[Adrian Bunk]

tags 811882 -help
tags 811882 +patch
thanks

Hi Dmitry,

the attached patch fixes the knutclient FTBFS with gcc 6.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Description: Fix the build with gcc 6
Author: Adrian Bunk 
Bug-Debian: https://bugs.debian.org/811882

--- knutclient-1.0.5.orig/src/knutprefdlg.cpp
+++ knutclient-1.0.5/src/knutprefdlg.cpp
@@ -958,7 +958,7 @@ void KNutPrefDlg::initFonts () {
   QHBoxLayout *setFontLayout = new QHBoxLayout();
   QStringList fontsList;
   KFontChooser::getFontList(fontsList, KFontChooser::SmoothScalableFonts);
-  m_fontWidget = new KFontChooser(mainPageWidget, false, fontsList);
+  m_fontWidget = new KFontChooser(mainPageWidget, KFontChooser::NoDisplayFlags, fontsList);
   setFontLayout->addWidget (m_fontWidget ,0);
   topLayout->addLayout(setFontLayout);
 

Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Josh Triplett]

On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler  wrote:
> On 17 August 2016 at 03:45, Ferenc Wágner  wrote:
> > Michael Biebl  writes:
> >
> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
> >>
> >>> Recently both my daemon packages started to exhibit this piuparts error:
> >>>
> >>> ERROR: FAIL: Package purging left files on system:
> >>>   /etc/rc2.d/ not owned
> >>>   /etc/rc3.d/ not owned
> >>>   /etc/rc4.d/ not owned
> >>>   /etc/rc5.d/ not owned
> >>>
> >>> I think this is the result of sysv-rc losing its Essential flag, which 
> >>> means
> >>> it isn't present in minimal chroots (like those used by piuparts) anymore.
> >>> On the other hand, init-system-helpers imported update-rc.d in version 
> >>> 1.25,
> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
> >>> this results in piuparts failures in recently tested daemon packages.
> >>>
> >>> If the above analysis is correct, please fix this.
> >>
> >> Fix what exactly?
> >
> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
> > directories.  (Removing them if they become empty is another option, but
> > does not sound a very good idea.)  Previously they were owned by
> > sysv-rc, which also provided update-rc.d, which used these directories.
> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
> > followed along, but was forgotten, I guess.
> 
> Indeed. init-system-helpers even already did this for
> /etc/systemd/system. I have added the rc?.d directories to the list.
> 
> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059

This will cause the directories to continue to exist even when empty.

Ideally, these directories could become empty and disappear eventually,
on a system not running sysvinit.  What would it take for that to
happen?

Bug#834751: RawTherapee crashes with "libpng error: IDAT: invalid distance too far back"

[Tobias Frost]

Source: libpng1.6
Followup-For: Bug #834751
Control: severity -1 important

Hi,

First thoughts about this:
libpng 1.6 is more strict about invalid pngs and the message you're seeing is
an indication that the file was corrupt.

(reducing severity as this is seems only for broken images; I currently suspect 
that this is
not a bug in libpng, but kind of missing checks for failures. But this needs a
little more investigations to be sure, I'll try to squeeze that in on the 
weekend.)

-- 
tobi

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

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

Bug#834313: RFS: dh-text/1.0 ITP

[Dmitry Bogatov]

> Guillem got enthusiastic about this and came up with this patch:
>
> https://www.hadrons.org/~guillem/tmp/0001-FIXME-Implement-source-stanza-sustvars.patch

Are there any chances it will reach sid till the middle of september?
If yes, I can wait for it to repace all my uses of dh-text. If not, I
am still seeking for sponsor dh-text.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#822203: bitcoin-qt: New upstream release (0.12.1)

[Anthony Towns]

On Mon, Aug 01, 2016 at 02:25:25PM +1000, Anthony Towns wrote:
> I've had a go at packaging 0.12.1, and it seems to have worked. Changes
> versus the collab-maint repo are at:

I've taken the liberty of uploading NMUs of 0.12.1 and 0.13.0rc3 to
unstable and experimental via DELAYED/3. The git changes are at:

   https://github.com/ajtowns/bitcoin-deb/commits/master

In particular:

 
https://github.com/ajtowns/bitcoin-deb/commit/7b93639aa24744a7c1a87cd616bf0dbd7d713756

and

 
https://github.com/ajtowns/bitcoin-deb/commit/775a3f5490335204d42e9353696aa84bd422f092

If someone wants to do an official maintainer upload instead, that'd be
great of course :)

Cheers,
aj



signature.asc
Description: PGP signature

Bug#811767: Fix for the geoip FTBFS

[Adrian Bunk]

tags 811767 -help
tags 811767 +patch
thanks

Hi Patrick,

what broke the build of geoip is that gcc 6 changed the default 
C++ standard from C++98 to C++14.

Note that this just changed the default, when told to process C++98 code 
gcc 6 does not differ in any significant way from gcc 5.

Not all valid C++98 code is also valid C++11 and C++14 code.

Making the code compatible with C++14 would be the best possible
solution, but there is nothing wrong with fixing the build with
the following change to tell gcc that this is C++98 code:

--- debian/rules.old2016-08-19 17:30:30.0 +
+++ debian/rules2016-08-19 17:33:09.0 +
@@ -11,9 +11,9 @@
 override_dh_auto_install:
$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp
# Build the build script.
-   $(CXX) $(CPPFLAGS) $(LDFLAGS) -g debian/src/geoip-csv-to-dat.cpp -o 
debian/tmp/geoip-generator -lGeoIP \
+   $(CXX) $(CPPFLAGS) -std=gnu++98 $(LDFLAGS) -g 
debian/src/geoip-csv-to-dat.cpp -o debian/tmp/geoip-generator -lGeoIP \
-I $(CURDIR)/debian/tmp/usr/include/ -L 
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
-   $(CXX) $(CPPFLAGS) $(LDFLAGS) -g debian/src/geoip-asn-csv-to-dat.cpp -o 
debian/tmp/geoip-generator-asn -lGeoIP \
+   $(CXX) $(CPPFLAGS) -std=gnu++98 $(LDFLAGS) -g 
debian/src/geoip-asn-csv-to-dat.cpp -o debian/tmp/geoip-generator-asn -lGeoIP \
-I $(CURDIR)/debian/tmp/usr/include/ -L 
$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/
chrpath -d -k debian/tmp/usr/bin/geoip*
 

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#834842: wordpress: allow multiple wp instances in same webserver

[Ioan Eugen Stan]

Package: wordpress
Version: 4.5.3+dfsg-1
Severity: wishlist

Dear Maintainer,

Please accpet my contribution to the wordpress package. It allows users to
select a wordpress specific configuration from the web server config file.

The issue with the current wordpress configuration lookup is that it uses only
the host name to perform lookup.
This does not allow you to host multiple separate wordpress sites on the same
domain/hostname.

My solution adds a few lines to the config and enables users to select the
wordpress config they wish to use by setting a CGI variable called
'WORDPRESS_CONFIG'. The solution should work with every web server that
implements CGI specification [1].

I have included sample apache config option and wp-config.php updates.

In apache vhost configuration you can set the configuration you wish to use
with somethink like:


SetEnvIf Request_URI "^/blog/(.*)$" WORDPRESS_CONFIG=blog





/* Look up a host-specific config file in
 * /etc/wordpress/config-.php or /etc/wordpress/config-.php
 */
$debian_server = preg_replace('/:.*/', "", $_SERVER['HTTP_HOST']);
$debian_server = preg_replace("/[^a-zA-Z0-9.\-]/", "", $debian_server);

if (isset($_SERVER['WORDPRESS_CONFIG'])) {
   $debian_file = '/etc/wordpress/config-'.$_SERVER['WORDPRESS_CONFIG']
.'.php';
} else {
   $debian_file = '/etc/wordpress/config-'.strtolower($debian_server).'.php';
}



The above code will select configuration '/etc/wordpress/config-blog.php' if
the request path starts with "/blog/".


I believe the patch greatly enhances the flexibility of the package with just a
few lines of code. It enables users to host multiple wordpress instances in the
same virtual host configuration like:

- example.com
- example.com/blog
- example.com/other-wp-site

etc.


[1] https://tools.ietf.org/html/rfc3875
[2] https://httpd.apache.org/docs/current/mod/mod_setenvif.html



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

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

Versions of packages wordpress depends on:
ii  apache2 [httpd] 2.4.23-4
ii  ca-certificates 20160104
ii  libapache2-mod-php  1:7.0+44
ii  libapache2-mod-php7.0 [libapache2-mod-php]  7.0.9-2
ii  libjs-cropper   1.2.2-1
ii  libphp-phpmailer5.2.14+dfsg-2
ii  mysql-client5.6.30-1
ii  nginx-full [httpd]  1.10.1-1
ii  php 1:7.0+44
ii  php-gd  1:7.0+44
ii  php-getid3  1.9.12+dfsg-1
ii  php-mysql   1:7.0+44
ii  php7.0 [php]7.0.9-2
ii  php7.0-gd [php-gd]  7.0.9-2
ii  php7.0-mysql [php-mysqlnd]  7.0.9-2

Versions of packages wordpress recommends:
ii  wordpress-l10n 4.5.3+dfsg-1
ii  wordpress-theme-twentysixteen  4.5.3+dfsg-1

Versions of packages wordpress suggests:
pn  mysql-server  
ii  php-ssh2  1.0+0.13-1

-- no debconf information

Bug#832364: kodi: Crashes on trying to play any TV recording

[Tobias Grimm]

Hello Balint,

> Tobias, could you please share the test file or test kodi again?

I've just tested it. It crashes when playing a VDR TS recording with
16.1+dfsg1-1 and after upgrading to 16.1+dfsg1-2 it works fine for the
same recording.

So I think 832364 can be closed.

bye,

Tobias




signature.asc
Description: OpenPGP digital signature

Bug#834839: manila: FTBFS too much often (ImportError: No module named pep8)

[Santiago Vila]

Package: src:manila
Version: 1:2.0.0-4
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-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
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python2,systemd,sphinxdoc
   dh_testdir -i -O--buildsystem=python_distutils
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions

[... snipped ...]

manila.tests.volume.test_cinder.CinderApiTestCase.test_get
manila.tests.volume.test_cinder.CinderApiTestCase.test_get ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_all
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_all ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_all_snapshots
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_all_snapshots ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_failed_1
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_failed_1 ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_failed_2
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_failed_2 ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_snapshot
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_snapshot ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_snapshot_failed
manila.tests.volume.test_cinder.CinderApiTestCase.test_get_snapshot_failed ... 
ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_initialize_connection
manila.tests.volume.test_cinder.CinderApiTestCase.test_initialize_connection 
... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_reserve_volume
manila.tests.volume.test_cinder.CinderApiTestCase.test_reserve_volume ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_roll_detaching
manila.tests.volume.test_cinder.CinderApiTestCase.test_roll_detaching ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_terminate_connection
manila.tests.volume.test_cinder.CinderApiTestCase.test_terminate_connection ... 
ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_unreserve_volume
manila.tests.volume.test_cinder.CinderApiTestCase.test_unreserve_volume ... ok
manila.tests.volume.test_cinder.CinderApiTestCase.test_update
manila.tests.volume.test_cinder.CinderApiTestCase.test_update ... ok

==
FAIL: unittest2.loader._FailedTest.manila.tests.test_hacking
unittest2.loader._FailedTest.manila.tests.test_hacking
--
_StringException: Traceback (most recent call last):
ImportError: Failed to import test module: manila.tests.test_hacking
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File "manila/tests/test_hacking.py", line 19, in 
import pep8
ImportError: No module named pep8


--
Ran 5751 tests in 233.447s

FAILED (failures=1, skipped=14)
debian/rules:52: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Because this source package only generates "Arch: all" packages, this
is the same as a FTBFS bug in the usual sense, and the fact that I was
doing "dpkg-buildpackage -A" does not mean anything special.

Thanks.

Bug#834840: neutron: FTBFS too much often (ImportError: No module named pep8)

[Santiago Vila]

Package: src:neutron
Version: 2:8.1.2-1
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-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
py3versions: no X-Python3-Version in control file, using supported versions
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 build-indep --buildsystem=python_distutils --with python2,systemd
   dh_testdir -i -O--buildsystem=python_distutils
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions

[... snipped ...]

neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_no_ignored_tracebacks
 ... ok
neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_single_member_trailing_chain
neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_single_member_trailing_chain
 ... ok
neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_two_member_trailing_chain
neutron.tests.unit.tests.test_post_mortem_debug.TestGetIgnoredTraceback.test_two_member_trailing_chain
 ... ok
neutron.tests.unit.tests.test_post_mortem_debug.TestTesttoolsExceptionHandler.test__get_debugger
neutron.tests.unit.tests.test_post_mortem_debug.TestTesttoolsExceptionHandler.test__get_debugger
 ... ok
neutron.tests.unit.tests.test_post_mortem_debug.TestTesttoolsExceptionHandler.test_exception_handler
neutron.tests.unit.tests.test_post_mortem_debug.TestTesttoolsExceptionHandler.test_exception_handler
 ... ok
neutron.tests.unit.tests.test_tools.ImportModulesRecursivelyTestCase.test_object_modules
neutron.tests.unit.tests.test_tools.ImportModulesRecursivelyTestCase.test_object_modules
 ... ok
Slowest Tests
Test id 
   Runtime (s)
-
  ---
neutron.tests.unit.extensions.test_extraroute.ExtraRouteDBSepTestCase.test_router_add_interface_ipv6_subnet
4.841
neutron.tests.unit.extensions.test_extraroute.ExtraRouteDBIntTestCase.test_router_add_interface_ipv6_subnet
4.484
neutron.tests.unit.extensions.test_l3.L3NatDBSepTestCase.test_router_add_interface_ipv6_subnet
 4.116
neutron.tests.unit.extensions.test_l3.L3NatDBIntTestCase.test_router_add_interface_ipv6_subnet
 3.749
neutron.tests.unit.extensions.test_l3.TestL3DbOperationBoundsTenant.test_floatingip_list_queries_constant
  3.564
neutron.tests.unit.extensions.test_l3.TestL3DbOperationBounds.test_floatingip_list_queries_constant
3.543
neutron.tests.unit.extensions.test_extraroute.ExtraRouteDBSepTestCase.test_floatingip_update_different_router
  3.494
neutron.tests.unit.db.test_agentschedulers_db.OvsAgentSchedulerTestCase.test_router_sync_data
  3.247
neutron.tests.unit.plugins.ml2.test_agent_scheduler.Ml2AgentSchedulerTestCase.test_router_sync_data
3.032
neutron.tests.unit.extensions.test_l3.L3NatDBSepTestCase.test_floatingip_update_different_router
   3.019

==
FAIL: unittest2.loader._FailedTest.neutron.tests.unit.hacking.test_checks
unittest2.loader._FailedTest.neutron.tests.unit.hacking.test_checks
--
_StringException: Traceback (most recent call last):
ImportError: Failed to import test module: 
neutron.tests.unit.hacking.test_checks
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File "/<>/neutron/tests/unit/hacking/test_checks.py", line 15, 
in 
from neutron.hacking import checks
  File "/<>/neutron/hacking/checks.py", line 17, in 
import pep8
ImportError: No module named pep8


--
Ran 7338 tests in 1774.457s

FAILED (failures=1, skipped=54)
debian/rules:177: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:9: recipe for target 'build-indep' 

Bug#834841: sahara: FTBFS too much often (ImportError: No module named pep8)

[Santiago Vila]

Package: src:sahara
Version: 1:4.0.0-2
Severity: serious

Dear maintainer:

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


[...]
 debian/rules build-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
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh build-indep --buildsystem=python_distutils --with python2,sphinxdoc,systemd
   dh_testdir -i -O--buildsystem=python_distutils
   dh_update_autotools_config -i -O--buildsystem=python_distutils
   dh_auto_configure -i -O--buildsystem=python_distutils
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions

[... snipped ...]

utils.test_ssh_remote.TestInstanceInteropHelper.test_use_floating_ips ... ok
Arguments dropped when creating context: {'token': 'test_auth_token'}
utils.test_ssh_remote.TestInstanceInteropHelper.test_use_namespaces
utils.test_ssh_remote.TestInstanceInteropHelper.test_use_namespaces ... ok
utils.test_types.TypesTestCase.test_is_int
utils.test_types.TypesTestCase.test_is_int ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_add_equal_separated_dict
utils.test_xml_utils.XMLUtilsTestCase.test_add_equal_separated_dict ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_add_property_to_configuration
utils.test_xml_utils.XMLUtilsTestCase.test_add_property_to_configuration ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_add_tagged_list
utils.test_xml_utils.XMLUtilsTestCase.test_add_tagged_list ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_adjust_description
utils.test_xml_utils.XMLUtilsTestCase.test_adjust_description ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_create_hadoop_xml
utils.test_xml_utils.XMLUtilsTestCase.test_create_hadoop_xml ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_get_if_not_exist_and_add_text_element
utils.test_xml_utils.XMLUtilsTestCase.test_get_if_not_exist_and_add_text_element
 ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_get_if_not_exist_and_add_to_element
utils.test_xml_utils.XMLUtilsTestCase.test_get_if_not_exist_and_add_to_element 
... ok
utils.test_xml_utils.XMLUtilsTestCase.test_load_xml_defaults
utils.test_xml_utils.XMLUtilsTestCase.test_load_xml_defaults ... ok
utils.test_xml_utils.XMLUtilsTestCase.test_load_xml_document_strip
utils.test_xml_utils.XMLUtilsTestCase.test_load_xml_document_strip ... ok

==
FAIL: unittest2.loader._FailedTest.utils.test_hacking
unittest2.loader._FailedTest.utils.test_hacking
--
_StringException: Traceback (most recent call last):
ImportError: Failed to import test module: utils.test_hacking
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 456, in 
_find_test_path
module = self._get_module_from_name(name)
  File "/usr/lib/python2.7/dist-packages/unittest2/loader.py", line 395, in 
_get_module_from_name
__import__(name)
  File "/<>/sahara/tests/unit/utils/test_hacking.py", line 17, in 

from sahara.utils.hacking import checks
  File "sahara/utils/hacking/checks.py", line 16, in 
import pep8
ImportError: No module named pep8


--
Ran 1146 tests in 65.224s

FAILED (failures=1, skipped=5)
debian/rules:17: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1
make[1]: Leaving directory '/<>'
debian/rules:13: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


Because this source package only generates "Arch: all" packages, this
is the same as a FTBFS bug in the usual sense, and the fact that I was
doing "dpkg-buildpackage -A" does not mean anything special.

Thanks.

Bug#834838: Dove­cot ft­s-sq­uat cor­rupt uidl­ist - wr­ong index­id

[nikwrt]

Package: dovecot-core
Version: 1:2.2.13-12~deb8u1

I use Debian Jessie, linux-image-3.16.0-4-amd64 3.16.7-ckt25-2+deb8, libc6 
2.19-18+deb8u4

I have been suffering from the corrupted fts-squat uidlist file bug:

Aug 19 03:43:43 x dovecot: imap(x): Error: Corrupted squat uidlist file 
/var/mail/x/Maildir/dovecot.index.search.uids: wrong indexid

When it happens the IMAP search results become incomplete. This is a fairly old 
and rather annoying issue:

http://dovecot.org/list/dovecot/2012-April/135162.html

I found the bug, patched it and submitted upstream. My patch was reviewed, 
accepted and merged into dovecot trunk 3 days ago:

https://github.com/dovecot/core/commit/d5db0fd38f7babf6b12c8bcc83dc8b5f32b71cc9

Please consider merging it.

Bug#834837: Dovecot fts-squat corrupt uidlist - wrong indexid

[nikwrt]

Package: dovecot-core
Version: 1:2.2.13-12~deb8u1

I use Debian Jessie, linux-image-3.16.0-4-amd64 3.16.7-ckt25-2+deb8, libc6 
2.19-18+deb8u4

I have been suffering from the corrupted fts-squat uidlist file bug:

Aug 19 03:43:43 x dovecot: imap(x): Error: Corrupted squat uidlist file 
/var/mail/x/Maildir/dovecot.index.search.uids: wrong indexid

When it happens the IMAP search results become incomplete.  This is a fairly 
old and rather annoying issue:

http://dovecot.org/list/dovecot/2012-April/135162.html

I found the bug, patched it and submitted upstream. My patch was reviewed, 
accepted and merged into dovecot trunk 3 days ago:

https://github.com/dovecot/core/commit/d5db0fd38f7babf6b12c8bcc83dc8b5f32b71cc9

Please consider merging it.

Bug#834836: binutils-multiarch: Try to overwrite '/usr/bin/i686-linux-gnu-addr2line', which is also in package binutils 2.27-6

[Christian Marillat]

Package: binutils-multiarch
Version: 2.27-5
Severity: serious

Dear Maintainer,

Package uninstallable.


Adding 'diversion of /usr/bin/i386-linux-gnu-readelf to 
/usr/bin/i386-linux-gnu-readelf.single by binutils-multiarch'
Unpacking binutils-multiarch (2.27-6) over (2.27-5) ...
dpkg: error processing archive 
/var/cache/apt/archives/binutils-multiarch_2.27-6_i386.deb (--unpack):
 trying to overwrite '/usr/bin/i686-linux-gnu-addr2line', which is also in 
package binutils 2.27-6
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)


Christian

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

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

Versions of packages binutils-multiarch depends on:
iu  binutils  2.27-6
ii  libc6 2.23-4
ii  zlib1g1:1.2.8.dfsg-2+b1

binutils-multiarch recommends no packages.

binutils-multiarch suggests no packages.

-- no debconf information

Bug#746943: mlocate is confused by btrfs subvols and doesn't descend into all mount points

[Tristan Miller]

Same issue reported for openSUSE: 
https://bugzilla.novell.com/show_bug.cgi?id=994663  Recent versions of 
openSUSE default to btrfs so they may have a better incentive to fix this 
problem.

Regards,
Tristan

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Tristan Miller
Free Software developer, ferret herder, logologist
 https://logological.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


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

Bug#834775: gcc-6: Massive package size increase w.r.t gcc-5

[Celelibi]

It looks like the size increase is due to debug informations in the
ELF file /usr/lib/gcc/i686-linux-gnu/6/lto1. (Same for cc1 in package
cpp-6.)

The debug informations do not seem to be mandatory for a proper use of
gcc. Could this be split into a gcc-6-dbg package in order to reduce
gcc-6 to a saner size?


Best regards,
Celelibi

Bug#827216: More info.

[Chirayu Desai]

So this bug was caused by an assert being hit in libutils

It was in:

#3  0x7790410b in android::VectorImpl::itemLocation
(this=0x7fffc990, index=0) at libutils/VectorImpl.cpp:319

(Which is a build from current git, 6.0.1+r55

Android builds have NDEBUG set system wide during the build, so this
code wouldn't have really been built / tested much without that set. It
works as the opposite of the flag DEBUG.

Once that was set, the assert wasn't hit anymore and so the code
continued to run like it normally would.

This bug was hit in aapt as it links against libutils and went through a
code path which the others may not have, or not in the same way.

In the future, we should take care and add NDEBUG to all android
projects, and also keep using gdb because once I got used to that it
didn't take long to see what went wrong :)

Bug#827216: [Android-tools-devel] Bug#827216: Bug#827216: Fixed.

[Markus Koschany]

On 19.08.2016 14:09, Markus Koschany wrote:
> On 19.08.2016 13:58, Chirayu Desai wrote:
>> http://deb.li/yXp2 fixes this.
>> Can now build apps and use apktool.
> 
> Wow. Good work! I'll take a look at this today and upload the new revision.
> 

Ah, I see now that this fix is intended for
android-platform-frameworks-base. Could you just push your changes to
the repository Chirayu?

Apparently the new upload requires us to upload the updated
build-dependencies too. As you know I'm not really fond of the versioned
build-dependencies approach or uploading packages just for bumping the
version, so I leave the rest to Hans-Christoph. The debian packaging
looks good to me on first glance though.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#834757: Breaks between gnupg1 and gnupg currently break bootstrapping of stretch

[Jeremy Bicha]

Is there a reason gnupg1 just doesn't include a gnupg transitional package?

Thanks,
Jeremy Bicha

Bug#834799: Pending fixes for bugs in the libdevel-callparser-perl package

[pkg-perl-maintainers]

tag 834799 + pending
thanks

Some bugs in the libdevel-callparser-perl package are closed in
revision a1f016d3d448afd8f93324d6012bddce04ef32fc in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdevel-callparser-perl.git/commit/?id=a1f016d

Commit message:

Drop optional build dependency on libdata-alias-perl.

Closes: #834799

Bug#834834: linux-image-4.6.0-0.bpo.1-amd64: screen flickering on older notebook display (in x-windows)

[Artur Linhart]

Package: src:linux
Version: 4.6.4-1~bpo8+1
Severity: important

Problem occurs on the notebook display only, the attached screen display does
no flickering at all with any kernel tried. After the last version of package
the flickering is very massive after the boot of the system and start of
X-Windows, and does not stop even after chaniging the parameters of the display
(resolution). Also if using the kernel 4.5.0 (package linux-
image-4.5.0-0.bpo.2-amd64 in version 4.5.4-1~bpo8+1) the flickering occurs,
with the older kernel 3.13 (package linux-image-3.13-1-amd64 in version
3.13.10-1) the display works well and no flickering at all can be seen.



-- Package-specific info:
** Version:
Linux version 4.6.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.6.0-0.bpo.1-amd64 
root=UUID=db6ab517-0ceb-47fb-9e8d-8ce27468ca23 ro

** Tainted: E (8192)
 * Unsigned module has been loaded (currently expected).

** Kernel log:
[2.658507] ACPI Warning: SystemIO range 
0x1028-0x102F conflicts with OpRegion 
0x1000-0x1042 (\_SB.C003.C004.C0BC) 
(20160108/utaddress-255)
[2.658689] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[2.658759] ACPI Warning: SystemIO range 
0x1130-0x113F conflicts with OpRegion 
0x1100-0x113B (\_SB.C003.C004.C0CE) 
(20160108/utaddress-255)
[2.658935] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[2.659002] ACPI Warning: SystemIO range 
0x1100-0x112F conflicts with OpRegion 
0x1100-0x113B (\_SB.C003.C004.C0CE) 
(20160108/utaddress-255)
[2.659178] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[2.659245] lpc_ich: Resource conflict(s) found affecting gpio_ich
[2.660167] leds_ss4200: no LED devices found
[2.665170] usb 4-7.4.2: New USB device found, idVendor=09da, idProduct=c10a
[2.665233] usb 4-7.4.2: New USB device strings: Mfr=1, Product=2, 
SerialNumber=0
[2.665300] usb 4-7.4.2: Product: USB Mouse
[2.665357] usb 4-7.4.2: Manufacturer: A4Tech
[2.688728] yenta_cardbus :02:06.0: ISA IRQ mask 0x0c78, PCI irq 18
[2.688792] yenta_cardbus :02:06.0: Socket status: 3006
[2.688852] pci_bus :02: Raising subordinate bus# of parent bus (#02) 
from #03 to #06
[2.688925] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge window: 
[io  0x8000-0x8fff]
[2.688992] yenta_cardbus :02:06.0: pcmcia: parent PCI bridge window: 
[mem 0xf420-0xf45f]
[2.689060] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xf420-0xf45f:
[2.689129]  excluding 0xf420-0xf423
[2.712049] tifm_core: MMC/SD card detected in socket 0:1
[2.749373] input: PC Speaker as /devices/platform/pcspkr/input/input18
[2.846499] [drm] fb mappable at 0xE00C
[2.846561] [drm] vram apper at 0xE000
[2.846618] [drm] size 7258112
[2.846674] [drm] fb depth is 24
[2.846730] [drm]pitch is 6912
[2.848221] fbcon: radeondrmfb (fb0) is primary device
[2.874110] Adding 5859324k swap on /dev/sda2.  Priority:-1 extents:1 
across:5859324k SSFS
[2.923056] Console: switching to colour frame buffer device 128x48
[2.925686] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[2.936071] [drm] Initialized radeon 2.43.0 20080528 for :01:00.0 on 
minor 0
[3.027244] input: HP WMI hotkeys as /devices/virtual/input/input19
[3.045816] iTCO_vendor_support: vendor-support=0
[3.046337] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[3.046432] iTCO_wdt: Found a ICH7-M or ICH7-U TCO device (Version=2, 
TCOBASE=0x1060)
[3.048918] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[3.056251] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: 
discard,commit=600
[3.079379] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0c-0x0f:
[3.079394]  excluding 0xc-0xc 0xe-0xf
[3.079410] pcmcia_socket pcmcia_socket0: cs: memory probe 
0xa000-0xa0ff:
[3.079419]  excluding 0xa000-0xa0ff
[3.079434] pcmcia_socket pcmcia_socket0: cs: memory probe 
0x6000-0x60ff:
[3.079443]  excluding 0x6000-0x60ff
[3.167732] systemd-journald[194]: Received request to flush runtime journal 
from PID 1
[3.268273] tpm_tis 00:03: TPM is disabled/deactivated (0x7)
[3.302959] hidraw: raw HID events driver (C) Jiri Kosina
[3.311217] usbcore: registered new interface driver usbhid
[3.311219] usbhid: USB HID core driver
[3.322558] input: A4Tech USB Mouse as 
/devices/pci:00/:00:1d.7/usb4/4-7/4-7.4/4-7.4.2/4-7.4.2:1.0/0003:09DA:C10A.0001/input/input20
[3.323918] 

Bug#721751: dnsmasq-base: Always listens on all interfaces

[Simon Kelley]

On 05/08/16 16:59, Clément Hermann wrote:
> Hi,
> 
> Just want to add my bit on this one.
> 
> The documentation states that when "interface" option is used, the
> daemon binds on * but reject queries that come to interfaces not listed.
> 
> This does not work, so eitheir the documentation is misleading or there
> is a bug (arguably a security one, since it leads to a false sense of
> security when you think you're not enabling DNS service on a public
> interface when in fact you are).
> 
> Cheers,
> 

Could you give a specific configuration where this occurs? It would
indeed by a bad bug, but I can't reproduce it.


Cheers,

Simon.

Bug#834835: RFP: ShogiGUI -- GUI for japanese Chess (Shogi)

[A.H.]

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

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

   Package name: ShogiGUI
Version: 0.0.6.1
Upstream Author: [shogix...@gmail.com] Can't figure out who the author is.
URL: [http://shogigui.siganus.com/]
License: [MIT/X,]
Description: This is a GUI for Shogi, which is japanese Chess. The 
program is developed since 2015 and has a lot of features which are 
really up-to-date. I know that in debian there are some shogi-apps, but 
they are all quite aotdated. Hence it would be great if Shogi-GUI could 
be integrated.


At the moment it is version 0.0.6.1 but very rapidly developed.

Some Features:
- supports english language (after you've figured out going to options, 
change it and restart the program)

- supports USI-Engines
- shows thinking
- uses arrows on the board to show moves
- also shows all book moves as arrows
- supports branches
- analyzes and considers modes
- has a nice Notation-tree-window
- supports user own images for piece, board, ...
- supports a score graph
- it even supports second (third, fourth, ...) best move!!! (Is GPSfish 
maybe finaly supporting the searchmoves-command. So the - 
winboard-protocol - version from HGM will no longer be the only one)


Yours
Andreas Hausmann

Bug#834795: Pending fixes for bugs in the libmethod-signatures-perl package

[pkg-perl-maintainers]

tag 834795 + pending
thanks

Some bugs in the libmethod-signatures-perl package are closed in
revision eb4b8d1564b26ad9dbdb24fe1f7de79c8de1ac75 in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libmethod-signatures-perl.git/commit/?id=eb4b8d1

Commit message:

Drop libdata-alias-perl from Build-Depends-Indep and Recommends.

Closes: #834795

Bug#834677: refcard: FTBFS in testing (xelatex compilation failed)

[Holger Wansing]

Control: tags -1 + pending


Santiago Vila  wrote:
> Package: src:refcard
> Version: 9.0.1
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:

Fixed in git.


Holger


-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/