Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60

[Thomas Orgis]

Package: mpg123

This is mpg123 upstream formally informing you of a vulnerability
(crash on illegal memory read) in all mpg123 versions since 0.60, so
very likely all debian versions of mpg123 and libmpg123 are affected.

See more detail at http://mpg123.org/bugs/240 . A one-line fix for any
version is this:

perl -pi -e 's:(while\()(tagpos < length-10\)):${1}length >= 10 && $2:' 
$(find src -name id3.c)


Alrighty then,

Thomas


pgpVu0bSOeA2b.pgp
Description: Digitale Signatur von OpenPGP

Bug#838959: gir1.2-pango-1.0 or other library breaks virt-viewer

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: virt-viewer
Version: 4.0-1
Severity: important

This bug is in gir1.2-pango-1.0 or related. but read below.

I am even not fully sure which library it is exactly. It was not
possible to downgrade one package after another. So possible candidates
are:
- - gir1.2-freedesktop
- - gir1.2-glib-2.0
- - gir1.2-gtk-3.0
- - gir1.2-pango-1.0
- - libglib2.0-0
- - libgtk-3-0
- - libgtk-3-common
- - libpango-1.0-0
- - libpango1.0-0
- - libpangocairo-1.0-0
- - libpangoft2-1.0-0
- - libpangoxft-1.0-0

To the bug itself:

When starting virt-viewer after an upgrade of the libraries above, the
screen content is not updated anymore. Nor is it displayed correctly.
The only message that is seen is (wording not necessarily correct, I
report it from my memory.) "Waiting for graphic server" and nothing
happens anymore.

I was not able to test effects to other software before downgrading as I
am depending on virt-viewer.

Sorry to file this bug against virt-viewer. I first filed it against
gir1.2-pango-1.0 with the note that it can be reassigned to the real
package but Michael Biebl is so stupid to just ignore the bug and does
just blame all other packages involved just not "his" gir1.2-pango-1.0.
(See #836362.)

I don't think that this bug is in virt-viewer itself as it was triggered
by an update of one of the above packages that cannot be updated
independently. But I see no other way than filling it against
virt-viewer. Nevertheless, there is a small change that it is in this
package.
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGcBAEBCgAGBQJX6gUOAAoJEKZ8CrGAGfasR2EL/A8HDNGydDccBBeTojBioiwj
Q2O+0zbPqSvvmitYAnQT2INMKDl59PC8XVgX+stJOt48SMsN6NeqO3l+gtdnhh7u
sXxguLo/QP8iDBLA/Lf5zYn0U3EN85axx7AjUPonr8PLN/ZJO9MxA1xPHF0AvEWF
GmuAguSGDScKMTjz6kSLFHgzIdOlRBjqIntVGKfGuqip6VDTqxEBmo9K0hNUbG1c
IdlSG9ID7oJ5AAm7V6zrKCdzKxsoPlxkpw9LZg4gCzaMmVA1dlw2j3ps6yYRl35L
CXZldAHCN/edpFcW7bOG0cNFh7IYbHXWjrZAsaQoG5X01XfB7TWbof5hWy5hlrk2
O7f8EIiHqyF8gFoj7X1YKjjBDXKNOMpNHA7OhCLTMCYL02K+yRWyF8WjUGyuW0Kc
skEfubSvCqaFwbQ0EW9XXbaOhDBcWiZu5fr1ErxJxhbIYl5B6/YFSsXhyoicop1+
mK+O1w2jSzfgt+toWbVXK5gcgrmkBcr0cXRho774uw==
=zyYZ
-END PGP SIGNATURE-

Bug#838958: linux: mount(2) _silently_ ignores other mountflags when MS_BIND is set

[g1]

Source: linux
Severity: important
Tags: upstream

>From the mount(2) man page:

MS_BIND (Linux 2.4 onward)
Perform a bind mount, making a file or a directory subtree visible at
another point within a filesystem. Bind mounts may cross filesystem
boundaries and span chroot(2) jails. The filesystemtype and data
arguments are ignored. Up until Linux 2.6.26, mountflags was also
ignored (the bind mount has the same mount options as the underlying
mount point).

Apparently, this applies to recent kernels too (at least 3.16).

Silently ignoring user-specified flags can open security holes, e.g. when
a sysadm bind-mounts a filesystem for use by a containter, thinking the mount
will be read-only:

# mount -o bind,ro /usr /containers/X/usr

Despite mount returning successfully, container X has /usr mounted
read/write, and root inside the container can easily corrupt/subvert
the host system.

Please keep in mind that recent versions of mount(1) work around the bug, by
calling mount() twice (once with the "bind" flag, then with the other flags),
but other applications calling mount() directly are usually affected.

Best regards,
giuseppe

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#838957: lxc: read-only bind mounts are in fact read/write

[g1]

Package: lxc
Version: 1:1.0.6-6+deb8u3
Severity: important

To reproduce:

root@debian-host# lxc-create -n bb -t busybox

root@debian-host# cat /var/lib/lxc/bb/config 
lxc.network.type = empty
lxc.rootfs = /var/lib/lxc/bb/rootfs
lxc.haltsignal = SIGUSR1
lxc.utsname = bb
lxc.tty = 1
lxc.pts = 1
lxc.cap.drop = sys_module mac_admin mac_override sys_time

lxc.mount.entry = /lib lib none ro,bind 0 0
lxc.mount.entry = /usr/lib usr/lib none ro,bind 0 0
lxc.mount.entry = /lib64 lib64 none ro,bind 0 0
lxc.mount.entry = /sys/kernel/security sys/kernel/security none 
ro,bind,optional 0 0
lxc.mount.auto = proc:mixed sys

root@debian-host# lxc-start -n bb -d

root@debian-host# lxc-attach -n bb touch /lib/test-file

root@debian-host# ls -l /lib/test-file && rm -f /lib/test-file
-rw-r--r-- 1 root root 0 Sep 15 16:57 /lib/test-file

I.E., where the lxc config specifies "ro,bind" for the bind mounts,
in fact only the "bind" flag is honoured, and filesystems are mounted
read/write.  That's because of this passage in the mount(2) manpage:

MS_BIND (Linux 2.4 onward)
Perform a bind mount, making a file or a directory subtree visi-
ble at another point within a filesystem.  Bind mounts may cross
filesystem boundaries and span chroot(2) jails.  The filesystem-
type and data arguments are ignored.   Up  until  Linux  2.6.26,
>>>mountflags  was  also ignored<<< (the bind mount has the same
mount options as the underlying mount point).

Apparently, this behaviour (respect MS_BIND, _silently_ ignore other
flags) is still present in recent kernels, and is (IMO) a bug in
itself.

As a result, people are misled into thinking they can use LXC to build
sandboxes, perhaps by dropping the SYS_ADMIN capability in the containers,
yet commands performed by root inside such a container (think dpkg -i/-r,
or rm -rf or ...) may cause considerable damage to the host system, unless
uid/gid remapping is enforced.

The bug in mount(2) can be verified in debian/jessie e.g. by running
# mkdir /tmp/xyz-lib; mount -o ro,bind /lib /tmp/xyz-lib
which leaves /lib mounted r/w as /tmp/xyz-lib.

Recent versions of the mount(1) command work around the bug in mount(2)
by calling it twice, once with the MS_BIND flag, and then with the
other user-specified flags.  It is not an ideal solution (implies a race
condition), yet the end result is correct.

As to LXC, I believe the problem was fixed upstream by this commit:
https://github.com/lxc/lxc/commit/7c5b6e7c3524031c3e9e203a9ab3beea7efa7a41
which implements the double call to mount(2), and AFAICT is included
in lxc-1.0.7.  Therefore, I suggest to rebase the debian/jessie lxc
sources on lxc-1.0.7, instead of lxc-1.0.6.

Best regards,
giuseppe


-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lxc depends on:
ii  init-system-helpers  1.22
ii  libapparmor1 2.9.0-3
ii  libc62.19-18+deb8u6
ii  libcap2  1:2.24-8
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  multiarch-support2.19-18+deb8u6
ii  python3  3.4.2-2

Versions of packages lxc recommends:
ii  debootstrap  1.0.67
ii  openssl  1.0.1t-1+deb8u5
ii  rsync3.1.1-3

Versions of packages lxc suggests:
pn  lua5.2  

-- no debconf information

Bug#833477: chromium: Chromecast device not found after update to 52.

[Jamin]

Unless the built-in media router not working is genuinely a bug, can we
consider disabling it by default?


diff -ur a/debian/chromium/etc/chromium.d/default-flags
b/debian/chromium/etc/chromium.d/default-flags
--- a/debian/chromium/etc/chromium.d/default-flags  2016-09-26
20:37:32.036974879 -0700
+++ b/debian/chromium/etc/chromium.d/default-flags  2016-09-26
20:38:13.044976103 -0700
@@ -8,3 +8,6 @@

 # Disable background networking
 export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --disable-background-networking"
+
+# Disable media router (bug #833477)
+export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --media-router=0"

Bug#834563: libuv1-dev: Add libkvm-dev to Depends for kfreebsd-any

[James McCoy]

On Wed, Aug 17, 2016 at 12:05:13AM -0400, James McCoy wrote:
> Packages which build against libuv need to add libkvm-dev to their
> Build-Depends in order to prevent FTBFS on kfreebsd-*.  For example, see
> neovim[0] and lua-luv[1] build logs.
> 
> Consumers of libuv shouldn't need to worry about this implementation
> detail, so libuv1-dev should express this in the Depends.

Any update on this?  If you're low on time, I can NMU this change.

> [0]: 
> https://buildd.debian.org/status/fetch.php?pkg=neovim=kfreebsd-amd64=0.1.2-1=1458491409
> [1]: 
> https://buildd.debian.org/status/fetch.php?pkg=lua-luv=kfreebsd-amd64=1.9.1-0-1=1471133552

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#811053: *.poms Should Not Be Required to Ensure Trailing Newline

[Christopher Hoskin]

Package: maven-repo-helper
Version: 1.9.2
Followup-For: Bug #811053

I haven't reproduced the trailing newline issue, but there's definitely a 
problem with multiple poms.

What happens at the moment is that jh_maven_repo_helper adds the following to 
the debhelper sequence:

mh_installpoms
mh_linkjars --skip-clean-poms

mh_installpoms calls mh_installpom for each pom, which calls mh_cleanpom, which 
creates (amongst other things) the file debian/.mh/pom.properties. mh_linkjars 
--skip-clean-poms calls mh_linkjar --skip-clean-poms for each pom. The 
--skip-clean-poms option assumes that debian/.mh/pom.properties already exists 
and reuses it in the creation of the symlinks.

This is fine if there's only one pom to deal with, but if there are multiple 
poms, each call to mh_installpom overwrites the previous 
debian/.mh/pom.properties, so that mh_linkjar only creates the symlink for the 
last pom processed by mh_installpoms.

You can see this in the package mongo-java-driver which I am currently working 
on. I am working around the problem by overriding mh_linkjars in debian/rules 
to remove the --skip-clean-poms option.

The attached patch modifies jh_maven_repo_helper.pm to remove the 
--skip-clean-poms options from the debhelper sequence. (Another option might be 
to modify mh_installpom to copy debian/.mh/pom.properties to 
debian/.mh/${artifactId}-${version}.properties and then modify mh_linkjar to 
look for this file instead.)

Christopher

Dear Maintainer,

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

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

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


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

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

Versions of packages maven-repo-helper depends on:
ii  default-jre-headless [java2-runtime-headless]2:1.8-57
ii  gcj-5-jre-headless [java2-runtime-headless]  5.4.1-1
ii  libstax-java 1.2.0-3
ii  openjdk-7-jre-headless [java2-runtime-headless]  7u111-2.6.7-1
ii  openjdk-8-jre-headless [java2-runtime-headless]  8u102-b14.1-2

Versions of packages maven-repo-helper recommends:
ii  debhelper  10

Versions of packages maven-repo-helper suggests:
ii  maven-debian-helper  2.1.1

-- no debconf information
>From dad07cffc697dea5d23fba0453e5b4992556d526 Mon Sep 17 00:00:00 2001
From: Christopher Hoskin 
Date: Tue, 27 Sep 2016 04:11:52 +0100
Subject: [PATCH] Fix jh_maven_repo_helper to work with multiple poms (Closes:
 #811053)

---
 debian/changelog   | 4 
 src/main/share/jh_maven_repo_helper.pm | 1 -
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index b75212d..2f4c9f6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,13 @@
 maven-repo-helper (1.9.3) UNRELEASED; urgency=medium
 
+  [ tony mancill ]
   * Team upload.
   * Apply patch for mh_patchpoms to honor the --verbose option.
 Thank you to Christopher Hoskin for the patch. (Closes: #835042)
 
+  [ Christopher Hoskin ]
+  * Fix jh_maven_repo_helper to work with multiple poms (Closes: #811053)
+
  -- tony mancill   Tue, 23 Aug 2016 22:26:59 -0700
 
 maven-repo-helper (1.9.2) unstable; urgency=medium
diff --git a/src/main/share/jh_maven_repo_helper.pm b/src/main/share/jh_maven_repo_helper.pm
index 0dcbdb7..def5e37 100644
--- a/src/main/share/jh_maven_repo_helper.pm
+++ b/src/main/share/jh_maven_repo_helper.pm
@@ -8,7 +8,6 @@ use Debian::Debhelper::Dh_Lib;
 
 insert_after("jh_depends", "mh_installpoms");
 insert_after("mh_installpoms", "mh_linkjars");
-add_command_options("mh_linkjars", "--skip-clean-poms");
 insert_before("dh_clean", "mh_clean");
 
 1;
-- 
2.9.3

Bug#838956: manpages-dev: Inconsistent documentation in NOTES section of "man wcstombs"

[Igor Liferenko]

Package: manpages-dev
Version: 4.07-1
Severity: normal

Dear Maintainer,

In "man wcstombs" the words

The function wcsrtombs(3) provides a thread safe interface to the same 
functionality.

should be changed to

The function wcsrtombs(3) provides a better interface to the same 
functionality.

Because

1) wcsrtombs is not thread safe if "ps" is NULL (see "ATTRIBUTES" in "man 
wcsrtombs")

2) wcstombs *is* thread safe (see "ATTRIBUTES" in "man wcstombs")

3) "man mbstowcs" says "The function mbsrtowcs(3) provides a better interface 
to the same functionality." in the same NOTES section.

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

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

Versions of packages manpages-dev depends on:
ii  manpages  4.07-1

manpages-dev recommends no packages.

Versions of packages manpages-dev suggests:
ii  man-db [man-browser]  2.7.5-1

-- no debconf information

Bug#838953: add choice to do configuration for the user

[積丹尼 Dan Jacobson]

Also taking a look at:
> WARNING: errors ignored on restore: 9
So we can ignore all those errors?
> Analyzing database zaokeng...
> Fixing hardcoded library paths for stored procedures...
So those errors got fixed? Or maybe those aren't those errors...
> Upgrading database template1...
> Analyzing database template1...
> Fixing hardcoded library paths for stored procedures...
> Upgrading database postgres...
> Analyzing database postgres...
> Re-enabling connections to the old cluster...
> Re-enabling connections to the new cluster...
> Copying old configuration files...
> Copying old start.conf...
> Copying old pg_ctl.conf...
> Stopping target cluster...
> Redirecting stop request to systemctl
> Stopping old cluster...
> Redirecting stop request to systemctl
> Disabling automatic startup of old cluster...
> Configuring old cluster to use a different port (5433)...
> Starting target cluster on the original port...
> Redirecting start request to systemctl
> Success. Please check that the upgraded cluster works. If it does,
Success? Despite all those errors?

And the administrator's role is to just upgrade, not run these programs
to see if they work... and what would be a test to see if it works?

> you can remove the old cluster with
> 
>   pg_dropcluster 9.5 main

Despite all those errors?

Bug#838953: add choice to do configuration for the user

[積丹尼 Dan Jacobson]

Also it seems 9.6 is installed for us, so maybe don't tell us to install
it again.

Bug#838953: add choice to do configuration for the user

[積丹尼 Dan Jacobson]

By the way, the whole thing fails anyway

# pg_dropcluster --stop 9.6 main
Redirecting stop request to systemctl
# pg_upgradecluster 9.5 main
Stopping old cluster...
Notice: extra pg_ctl/postgres options given, bypassing systemctl for stop 
operation
Disabling connections to the old cluster during upgrade...
Restarting old cluster with restricted connections...
Redirecting start request to systemctl
Creating new cluster 9.6/main ...
  config /etc/postgresql/9.6/main
  data   /var/lib/postgresql/9.6/main
  locale zh_TW.UTF-8
  socket /var/run/postgresql
  port   5433
Disabling connections to the new cluster during upgrade...
Redirecting start request to systemctl
Roles, databases, schemas, ACLs...
ERROR:  could not open extension control file 
"/usr/share/postgresql/9.6/extension/postgis.control": No such file or directory
ERROR:  extension "postgis" does not exist
ERROR:  type "geometry" does not exist
LINE 3: "wkb_geometry" "geometry"(Geometry,4326),
   ^
ERROR:  relation "kk1" does not exist
ERROR:  relation "kk1" does not exist
ERROR:  type "geometry" does not exist
LINE 3: "wkb_geometry" "geometry"(Geometry,4326),
   ^
ERROR:  relation "燥坑門牌" does not exist
ERROR:  relation "燥坑門牌" does not exist
ERROR:  relation "kk1" does not exist
ERROR:  relation "燥坑門牌" does not exist
ERROR:  relation "kk1" does not exist
ERROR:  relation "燥坑門牌" does not exist
ERROR:  relation "kk1" does not exist
ERROR:  relation "燥坑門牌" does not exist
Fixing hardcoded library paths for stored procedures...
Upgrading database zaokeng...
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3440; 0 17775 TABLE DATA kk1 
jidanni
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "kk1" 
does not exist
Command was: ALTER TABLE kk1 DISABLE TRIGGER ALL;


pg_restore: [archiver (db)] could not execute query: ERROR:  relation "kk1" 
does not exist
Command was: COPY "kk1" ("ogc_fid", "wkb_geometry", "name", "description", 
"timestamp", "begin", "end", "altitudemode", "tessellate", "ex...
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "kk1" 
does not exist
Command was: ALTER TABLE kk1 ENABLE TRIGGER ALL;


pg_restore: [archiver (db)] Error from TOC entry 3307; 0 16677 TABLE DATA 
spatial_ref_sys postgres
pg_restore: [archiver (db)] could not execute query: ERROR:  relation 
"spatial_ref_sys" does not exist
Command was: ALTER TABLE spatial_ref_sys DISABLE TRIGGER ALL;


pg_restore: [archiver (db)] could not execute query: ERROR:  relation 
"spatial_ref_sys" does not exist
Command was: COPY "spatial_ref_sys"  FROM stdin;

pg_restore: [archiver (db)] could not execute query: ERROR:  relation 
"spatial_ref_sys" does not exist
Command was: ALTER TABLE spatial_ref_sys ENABLE TRIGGER ALL;


pg_restore: [archiver (db)] Error from TOC entry 3438; 0 17763 TABLE DATA 燥坑門牌 
jidanni
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "
燥坑門牌" does not exist
Command was: ALTER TABLE "燥坑門牌" DISABLE TRIGGER ALL;


pg_restore: [archiver (db)] could not execute query: ERROR:  relation "燥坑門牌" 
does not exist
Command was: COPY "燥坑門牌" ("ogc_fid", "wkb_geometry", "name", "description", 
"timestamp", "begin", "end", "altitudemode", "tessell...
pg_restore: [archiver (db)] could not execute query: ERROR:  relation "燥坑門牌" 
does not exist
Command was: ALTER TABLE "燥坑門牌" ENABLE TRIGGER ALL;


WARNING: errors ignored on restore: 9
Analyzing database zaokeng...
Fixing hardcoded library paths for stored procedures...
Upgrading database template1...
Analyzing database template1...
Fixing hardcoded library paths for stored procedures...
Upgrading database postgres...
Analyzing database postgres...
Re-enabling connections to the old cluster...
Re-enabling connections to the new cluster...
Copying old configuration files...
Copying old start.conf...
Copying old pg_ctl.conf...
Stopping target cluster...
Redirecting stop request to systemctl
Stopping old cluster...
Redirecting stop request to systemctl
Disabling automatic startup of old cluster...
Configuring old cluster to use a different port (5433)...
Starting target cluster on the original port...
Redirecting start request to systemctl
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with

  pg_dropcluster 9.5 main

And I don't know what to do now.

Bug#838955: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/(?

[積丹尼 Dan Jacobson]

Package: postgresql-9.6

Setting up postgresql-9.6 (9.6~rc1-1+b1) ...
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/(?

Bug#838953: add choice to do configuration for the user

[積丹尼 Dan Jacobson]

Or make a shell script the user can run, that will do all the steps.

Bug#610282: partman-lvm/confirm boolean true does not suppress "Before the Logical Volume ..."

[Vincent McIntyre]

(we were discussing having a branch of manual for each stable release)

This appears to have happened - thanks Samuel!

https://anonscm.debian.org/viewvc/d-i/branches/manual/jessie/

I think it would be worth mentioning the existence of this
in the trunk README - suggested patch below. Please let me know
if I should open another bug for this or cross-reference to an
existing one.

Index: README
===
--- README  (revision 70307)
+++ README  (working copy)
@@ -17,4 +17,10 @@
 All help is welcome! Send suggestions to the debian-boot list. Patches
 can be submitted against the package installation-guide.
 
-Last update: 09 July 2006
+Patches should normally be submitted against the 'trunk' version of
+the manual, so they will be included in the next stable release.
+However there are some cases where it is appropriate to update the
+stable release also: such patches should be made against the branch
+for the relevant stable release codename: ^/branches/manual/.
+
+Last update: 27 September 2016

-- 

Bug#838954: Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/(?

[積丹尼 Dan Jacobson]

Package: libpam-runtime

Setting up postgresql-9.6 (9.6~rc1-1+b1) ...
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/(?

Bug#838952: w3m omits all of the text in this .html file

[Robert Munyer]

Package: w3m
Version: 0.5.3-29
Severity: normal

I have a .html file that contains lots of text, and is valid according
to w3c.org's validator, but when this file is given to w3m -dump there
is no content written to standard output, and no error message written
to standard error, and zero exit status returned to the parent process.

The content is copyrighted, so I redacted the content by replacing all
non-linefeed characters with "x", and found that the bug still occurs.

The redacted file is attached.

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

Kernel: Linux 4.6.0-1-686 (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
Init: sysvinit (via /sbin/init)

Versions of packages w3m depends on:
ii  libc62.23-5
ii  libgc1c2 1:7.4.2-8
ii  libgpm2  1.20.4-6.2
ii  libssl1.0.2  1.0.2h-1
ii  libtinfo56.0+20160625-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages w3m recommends:
ii  ca-certificates  20160104

Versions of packages w3m suggests:
pn  cmigemo   
pn  libsixel-bin  
ii  man-db2.7.5-1
ii  mime-support  3.60
pn  mpv   
pn  w3m-el
pn  w3m-img   
ii  wget  1.18-2+b1
pn  xdg-utils 
pn  xsel  

-- no debconf information


lots-of-x.html.bz2
Description: w3m omits all of the text in this .html file

Bug#838953: add choice to do configuration for the user

[積丹尼 Dan Jacobson]

Package: postgresql-common
Version: 176
Severity: wishlist

We see:


│ Obsolete major version 9.5
 │
   │
│
   │ The PostgreSQL version 9.5 is obsolete, but the server or client packages 
are still installed. Please install the latest packages  │
   │ (postgresql-9.6 and postgresql-client-9.6) and upgrade the existing  
clusters with pg_upgradecluster (see manpage).│
   │
│
   │ Please be aware that the installation of postgresql-9.6 will automatically 
create a default cluster 9.6/main. If you want to upgrade the   │
   │ 9.5/main cluster, you need to remove the already existing 9.6 cluster 
(pg_dropcluster --stop 9.6 main, see manpage for details).   │
   │
│
   │ The old server and client packages are no longer supported. After the 
existing clusters are upgraded, the postgresql-9.5 and   │
   │ postgresql-client-9.5 packages should be removed.  
│
   │
│
   │ Please see /usr/share/doc/postgresql-common/README.Debian.gz for
   details.


Can't there be a an additional button choice added to do this all for us.

Bug#838951: lightdm: fails to start X login session by lightdm

[cutsea110]

Package: lightdm
Version: 1.18.2-2
Severity: important

Dear Maintainer,

It fails to start X login session after apt upgrade last time 2016-09-24.
I found a warning message in /var/log/lightdm/lightdm.log and x-0-greeter.log 
below.

cheers.

== /var/log/lightdm/lightdm.log 
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.18.2, UID=0 PID=1426
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from 
/usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Registered seat module xlocal
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.01s] DEBUG: Monitoring logind for seats
[+0.01s] DEBUG: New seat added from logind: seat0
[+0.01s] DEBUG: Seat seat0: Loading properties from config section Seat:*
[+0.01s] DEBUG: Seat seat0: Starting
[+0.01s] DEBUG: Seat seat0: Creating greeter session
[+0.01s] DEBUG: Seat seat0: Creating display server of type x
[+0.01s] DEBUG: Could not run plymouth --ping: Failed to execute child process 
"plymouth" (No such file or directory)
[+0.01s] DEBUG: Using VT 7
[+0.01s] DEBUG: Seat seat0: Starting local X display on VT 7
[+0.01s] DEBUG: DisplayServer x-0: Logging to /var/log/lightdm/x-0.log
[+0.01s] DEBUG: DisplayServer x-0: Can't launch X server X, not found in path
[+0.01s] DEBUG: DisplayServer x-0: X server stopped
[+0.01s] DEBUG: Releasing VT 7
[+0.01s] DEBUG: Seat seat0: Display server stopped
[+0.01s] DEBUG: Seat seat0: Can't create display server for greeter
[+0.01s] DEBUG: Seat seat0: Session stopped
[+0.01s] DEBUG: Seat seat0: Stopping display server, no sessions require it
[+0.01s] DEBUG: Seat seat0: Stopping
[+0.01s] DEBUG: Seat seat0: Stopped
[+0.01s] DEBUG: Failed to start seat: seat0

== /var/log/lightdm/x-0-greeter.log 

** Message: Starting lightdm-gtk-greeter 2.0.1 (Jun 21 2015, 09:15:25)
** Message: [Configuration] Reading file: 
/usr/share/lightdm/lightdm-gtk-greeter.conf.d/01_debian.conf
** Message: [Configuration] Reading file: /etc/lightdm/lightdm-gtk-greeter.conf

** (lightdm-gtk-greeter:11572): WARNING **: [PIDs] Failed to execute command: 
upstart

** (process:11575): WARNING **: Failed to register client: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.gnome.SessionManager was not provided by any .service files

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

(lightdm-gtk-greeter:11572): Gtk-WARNING **: Drawing a gadget with negative 
dimensions. Did you forget to allocate a size? (node menubar owner 
GreeterMenuBar)

Bug#831587: stressapptest: please make the build reproducible

[Blanc Pierre]

Hello,

> - This won't be reproducible as $username is not fixed too.
Right.

> - I don't think always setting "hostname" to "localhost" is right.
>   Feels wrong.
Ok, you right. The better is to remove information

>
> Why not follow my previous suggestion of wrapping the:
>
>  AC_DEFINE_UNQUOTED([STRESSAPPTEST_TIMESTAMP],
>
> when SOURCE_DATE_EPOCH is set?
Something like that:

-AC_DEFINE_UNQUOTED([STRESSAPPTEST_TIMESTAMP],
+if test -n "$SOURCE_DATE_EPOCH"; then
+  AC_DEFINE(STRESSAPPTEST_TIMESTAMP,"")
+else
+  AC_DEFINE_UNQUOTED([STRESSAPPTEST_TIMESTAMP],
"$username @ $hostname on $timestamp",
[Timestamp when ./configure was executed])
+fi
+

Regards

Bug#838950: ITP: libdatetime-calendar-julian-perl -- library to handle dates in the Julian calendar

[Norbert Preining]

Package: wnpp
Severity: wishlist
Owner: Norbert Preining 

* Package name: libdatetime-calendar-julian-perl
  Version : 0.04
  Upstream Author : Eugene van der Pijll 
* URL : https://metacpan.org/release/DateTime-Calendar-Julian
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : library to handle dates in the Julian calendar

DateTime::Calendar::Julian implements the Julian Calendar.


I need this package as a dependency for biber's new release 2.6.
I have applied for membership in the pkg-perl group and plan
to have the package in a git repo in the pkg-perl space.

Bug#838949: patch

[dann frazier]

tags 838949 + patch
kthxbye
diff -Nru libvirt-2.2.0/debian/changelog libvirt-2.2.0/debian/changelog
--- libvirt-2.2.0/debian/changelog	2016-09-09 08:51:48.0 -0600
+++ libvirt-2.2.0/debian/changelog	2016-09-26 18:42:57.0 -0600
@@ -1,3 +1,9 @@
+libvirt (2.2.0-2) UNRELEASED; urgency=medium
+
+  * Enable --with-numactl on arm64 (Closes: #838949).
+
+ -- dann frazier   Mon, 26 Sep 2016 18:42:57 -0600
+
 libvirt (2.2.0-1) unstable; urgency=medium
 
   * [7772549] New upstream version 2.2.0~rc1
diff -Nru libvirt-2.2.0/debian/control libvirt-2.2.0/debian/control
--- libvirt-2.2.0/debian/control	2016-09-09 07:54:40.0 -0600
+++ libvirt-2.2.0/debian/control	2016-09-26 18:42:44.0 -0600
@@ -33,7 +33,7 @@
  libnl-route-3-dev [linux-any],
  libyajl-dev,
  libpcap0.8-dev,
- libnuma-dev [amd64 i386 ia64 mips mipsel powerpc ppc64 ppc64el],
+ libnuma-dev [amd64 arm64 i386 ia64 mips mipsel powerpc ppc64 ppc64el],
  radvd [linux-any],
  libnetcf-dev (>= 1:0.2.3-3~) [linux-any],
  libsanlock-dev [linux-any],
diff -Nru libvirt-2.2.0/debian/rules libvirt-2.2.0/debian/rules
--- libvirt-2.2.0/debian/rules	2016-09-09 07:54:40.0 -0600
+++ libvirt-2.2.0/debian/rules	2016-09-26 18:42:51.0 -0600
@@ -43,7 +43,7 @@
   else
   WITH_DTRACE = --without-dtrace
   endif
-  ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 i386 ia64 mips mipsel powerpc ppc64el))
+  ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 arm64 i386 ia64 mips mipsel powerpc ppc64el))
   WITH_NUMA   = --with-numactl
   else
   WITH_NUMA   = --without-numactl

Bug#838949: Enable NUMA support in arm64 builds

[dann frazier]

Source: libvirt
Version: 2.2.0-1

arm64 is currently omitted from the list of architectures built with
numactl support. arm64 platforms with NUMA support are available and,
even on non-NUMA implementations, libvirt needs to have NUMA support
enabled to expose the necessary capabilities to nova to allow for
hugetlbfs-backed-KVM instances.

Bug#837054: /usr/bin/weather: The service url required for functionality has changed

[Bert Riding]

Package: weather-util-data
Version: 2.0-1
Followup-For: Bug #837054

Dear Maintainer,

The files in /usr/share/weather-util provided by weather-util-data still 
contain the outdated URLs.

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

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

-- no debconf information

Bug#838948: [patch] preseed appendix of d-i manual: use_autoconfig

[Vincent McIntyre]

Package: installation-guide
Severity: minor
Tags: d-i patch
thanks
 
(resending as a bug, my post to -boot didn't elicit any replies)


For some years the disable_autoconfig preseed has been shown
in the appendix on preseeding. However setting that just sets
use_autoconfig appropriately. Yet use_autoconfig is not even
mentioned in the appendix, ever.

There might be something I'm missing here, such as disable_autoconfig
is the only thing that works if you pass it on the boot command line.
I might also be misinterpreting 'manual configuration' as meaning
'set up an "iface ethX inet static" stanza in /etc/network/interfaces'.

If not, is it time to start deprecating use of disable_auotconfig?
I realise it was needed in the past but the code has been fixed.

--- preseed.xml (revision 70296)
+++ preseed.xml (working copy)
@@ -882,6 +882,10 @@
 
 # If you prefer to configure the network manually, uncomment this line and
 # the static network configuration below.
+#d-i netcfg/use_autoconfig boolean false
+
+# The following also forces manual configuration, but is deprecated
+# for end user preseed files. It will set use_autoconfig to false.
 #d-i netcfg/disable_autoconfig boolean true
 


Cheers
Vince
-- 

Bug#830178: Possible fix

[Nish Aravamudan]

So I am tracking the same issue seen on Ubuntu 16.10 and I found:

https://github.com/sphinx-doc/sphinx/pull/2396

I tested the following patch to the sourc3, and it does seem to build,
although I'm not sure I fully understand why yet (I'm completely new to
sphinx, just trying to help fix these bugs :) But I think it's because
upstream sphinx has changed an underlying data structure (index)?

-Nish

--- a/doc/build/templates/genindex.mako
+++ b/doc/build/templates/genindex.mako
@@ -21,7 +21,7 @@
 numcols = 1
 numitems = 0
 %>
-% for entryname, (links, subitems) in entries:
+% for entryname, (links, subitems, dummy) in entries:
 
 
 % if links:


-- 
Nishanth Aravamudan
Ubuntu Server
Canonical Ltd

Bug#821053: UEFI Secure Boot support in d-i build

[Ben Hutchings]

Control: reassign -1 grub-installer
Control: tag -1 patch

On Fri, 01 Jul 2016 23:15:07 +0200 Ben Hutchings  wrote:
> On Fri, 15 Apr 2016 01:04:15 +0100 Steve McIntyre 
> wrote:
> > Package: debian-installer
> > Severity: important
> > Control: block 820036 with -1
> >
> > Check what changes will be needed in the d-i build scripts to support
> > signed modules etc. for UEFI Secure Boot.
> 
> I think the answer is 'nothing at all', as udebs will be built with
> signed binaries and their names won't change.  This is implemented in
> linux-signed/experimental.

...but we do need to install grub-signed and shim-signed.  Here's a
patch based on what Ubuntu does, extended to cover arm64 and i386:

--- a/grub-installer
+++ b/grub-installer
@@ -319,7 +319,7 @@ experimental_arch () {
 
 case $ARCH in
 arm64/efi)
-   grub_package="grub-efi-arm64"
+   grub_package="grub-efi-arm64-signed"
;;
 armhf/efi)
grub_package="grub-efi-arm"
@@ -343,9 +343,9 @@ case $ARCH in
if [ -f /sys/firmware/efi/fw_platform_size ] ; then
SIZE=$(cat /sys/firmware/efi/fw_platform_size)
if [ $SIZE -eq 64 ] ; then
-   grub_package="grub-efi-amd64"
+   grub_package="grub-efi-amd64-signed"
elif [ $SIZE -eq 32 ] ; then
-   grub_package="grub-efi-ia32"
+   grub_package="grub-efi-ia32-signed"
fi
fi
fi
@@ -464,10 +464,10 @@ db_progress INFO grub-installer/progress/step_install
 # to grub legacy, or vice-versa
 case "$grub_package" in
 grub)
-   log-output -t grub-installer $chroot $ROOT dpkg -P grub-pc-bin grub-pc 
grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-ia32-bin grub-efi-ia32
+   log-output -t grub-installer $chroot $ROOT dpkg -P grub-pc-bin grub-pc 
grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed 
grub-efi-ia32-bin grub-efi-ia32 grub-efi-ia32-signed
;;
 grub-pc)
-   log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-ia32-bin grub-efi-ia32
+   log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
grub-efi grub-efi-amd64-bin grub-efi-amd64 grub-efi-amd64-signed 
grub-efi-ia32-bin grub-efi-ia32 grub-efi-ia32-signed
 ;;
 grub-efi*)
log-output -t grub-installer $chroot $ROOT dpkg -P grub grub-legacy 
grub-pc-bin grub-pc
@@ -487,6 +487,11 @@ case "$grub_package" in
*)
# Will pull in os-prober based on global setting for Recommends
apt-install $grub_package || exit_code=$? 
+   case $grub_package in
+   *-signed)
+   apt-install shim-signed || true
+   ;;
+   esac
;;
 esac
 
--- END ---

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.


signature.asc
Description: Digital signature

Bug#838947: Please package new version 1.0.0.8

[W. Martin Borgert]

Package: trac-graphviz
Version: 0.7.5-1.1
Severity: wishlist

A new version 1.0.0.8 is available.

Bug#838877: Installing packages writes to unexpected locations

[Elliott Mitchell]

On Mon, Sep 26, 2016 at 11:23:56PM +0200, Guillem Jover wrote:
> Control: tags -1 moreinfo
> 
> On Sun, 2016-09-25 at 16:46:56 -0700, Elliott Mitchell wrote:
> > Package: dpkg
> > Version: 1.17.27
> 
> > When installing packages which *only* have files in /usr, I generally
> > try to leave / read-only.  With the recent release of `dpkg` though this
> > has become problematic.
> 
> Do you mean that it used to work, and it does not anymore. In which
> case, what versions?

Anything 1.16.18 (oldstable) or earlier didn't exhibit this behavior.

> > >From the error message, during unpacking `dpkg` is trying to create a
> > file/directory as /usr.dpkg-tmp, which fails if / is read-only.  This
> > could actually cause some problems.  Notably if `dpkg` is doing this to
> > check whether the filesystem has sufficient free space, this check *WILL*
> > fail since / and /usr could well be different filesystems.  This could
> > also cause trouble if /usr.dpkg-tmp is large and / has limited free
> > space.
> 
> This should not happen for pre-existing directories, and dpkg should
> skip those. The actual error message would be helpful here. Also the
> debug output from using -D113 would also be helpful.

Sigh, really should have grabbed the full error.  Mentioned a failure
trying to do some operation on /usr. and "read-only
filesystem" (/usr was read-write, / was read-only).  Remounting /
read-write gets past the error, but I dislike that.  Since the package
had no files outside of /usr, this really shouldn't occur.

> > I'm unsure how to rate the severity of this issue.  This is distinctly
> > annoying and can trigger warning flags, but I suppose in many cases it
> > won't cause problems for people.  Folks who always remount / read-write
> > when upgrading packages may well not notice, but those of use who pay a
> > bit more attention do notice.
> 
> I'm actually very surprised by this bug report, because something
> related was fixed in dpkg 1.17.14, so the version you are reporting
> against should actually behave better for your use case:
> 
>   * Never try to remove the root directory or its backups. There's no point in
> it, and makes life more difficult for a read-only root with a read-write
> overlay or a symlink farm. Requested by sepero...@gmx.com.

This isn't about the removal of something, this is about creating an
unneeded extra file/directory outside of where any files should be
being created.  This file/directory is removed afterwords, but writing
outside bothers me.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#838946: [patch] preseed appendix of d-i manual: use_autoconfig

[Vincent McIntyre]

Package: debian-installer-manual
Version: Head
Severity: minor
Tags: d-i patch
thanks

(resending as a bug, my post to -boot didn't elicit any replies)


For some years the disable_autoconfig preseed has been shown
in the appendix on preseeding. However setting that just sets
use_autoconfig appropriately. Yet use_autoconfig is not even
mentioned in the appendix, ever.

There might be something I'm missing here, such as disable_autoconfig
is the only thing that works if you pass it on the boot command line.
I might also be misinterpreting 'manual configuration' as meaning
'set up an "iface ethX inet static" stanza in /etc/network/interfaces'.

If not, is it time to start deprecating use of disable_auotconfig?
I realise it was needed in the past but the code has been fixed.

--- preseed.xml (revision 70296)
+++ preseed.xml (working copy)
@@ -882,6 +882,10 @@
 
 # If you prefer to configure the network manually, uncomment this line and
 # the static network configuration below.
+#d-i netcfg/use_autoconfig boolean false
+
+# The following also forces manual configuration, but is deprecated
+# for end user preseed files. It will set use_autoconfig to false.
 #d-i netcfg/disable_autoconfig boolean true
 


Cheers
Vince
-- 

Bug#838945: please incorporate some patches

[Matthias Klose]

Package: src:libecap
Version: 1.0.1-3
Tags: patch

Please could you consider applying the attached patch to the package?  It
includes the following fixes:

  * Don't encode the build environment in the include headers. Closes: #815820.
  * Bump standards and debhelper versions.
  * Drop obsolete g++ build dependency.
  * Build with optimization and hardening flags.
  * Create symbols file for the libecap3 shared library.

I'm planning to do a NMU later this/next months.

Thanks, Matthias
diff -Nru libecap-1.0.1/debian/changelog libecap-1.0.1/debian/changelog
--- libecap-1.0.1/debian/changelog  2016-02-17 00:59:20.0 +0100
+++ libecap-1.0.1/debian/changelog  2016-09-27 00:23:35.0 +0200
@@ -1,3 +1,14 @@
+libecap (1.0.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't encode the build environment in the include headers. Closes: #815820.
+  * Bump standards and debhelper versions.
+  * Drop obsolete g++ build dependency.
+  * Build with optimization and hardening flags.
+  * Create symbols file for the libecap3 shared library.
+
+ -- Matthias Klose   Tue, 27 Sep 2016 00:23:35 +0200
+
 libecap (1.0.1-3) unstable; urgency=medium
 
   * Multiarchify the package (thanks to Matthias Klose) (Closes: #812911)
diff -Nru libecap-1.0.1/debian/control libecap-1.0.1/debian/control
--- libecap-1.0.1/debian/control2016-02-17 00:59:20.0 +0100
+++ libecap-1.0.1/debian/control2016-09-27 00:23:35.0 +0200
@@ -1,8 +1,8 @@
 Source: libecap
 Priority: extra
 Maintainer: Luigi Gangitano 
-Build-Depends: debhelper (>= 8.0.0), autotools-dev, cdbs, dh-autoreconf, g++ 
(>= 4:5.2)
-Standards-Version: 3.9.6
+Build-Depends: debhelper (>= 9), autotools-dev, cdbs, dh-autoreconf
+Standards-Version: 3.9.8
 Section: libs
 Homepage: http://www.e-cap.org/Downloads
 
diff -Nru libecap-1.0.1/debian/libecap3.symbols 
libecap-1.0.1/debian/libecap3.symbols
--- libecap-1.0.1/debian/libecap3.symbols   1970-01-01 01:00:00.0 
+0100
+++ libecap-1.0.1/debian/libecap3.symbols   2016-09-27 00:23:35.0 
+0200
@@ -0,0 +1,131 @@
+# SymbolsHelper-Confirmed: 1.0.1 amd64 armhf i386 powerpc
+libecap.so.3 libecap3 #MINVER#
+ _ZN7libecap10methodHeadE@Base 1.0.1
+ _ZN7libecap10methodPostE@Base 1.0.1
+ _ZN7libecap11metaVirusIdE@Base 1.0.1
+ _ZN7libecap11methodTraceE@Base 1.0.1
+ _ZN7libecap11protocolFtpE@Base 1.0.1
+ _ZN7libecap11protocolUrnE@Base 1.0.1
+ _ZN7libecap12RegisterHostERKNSt3tr110shared_ptrINS_4host4HostEEE@Base 1.0.1
+ _ZN7libecap12metaClientIpE@Base 1.0.1
+ _ZN7libecap12metaServerIpE@Base 1.0.1
+ _ZN7libecap12metaUserNameE@Base 1.0.1
+ _ZN7libecap12methodDeleteE@Base 1.0.1
+ _ZN7libecap12protocolHttpE@Base 1.0.1
+ _ZN7libecap12protocolWaisE@Base 1.0.1
+ 
_ZN7libecap13TextExceptionC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKci@Base
 1.0.1
+ 
_ZN7libecap13TextExceptionC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKci@Base
 1.0.1
+ _ZN7libecap13TextExceptionD0Ev@Base 1.0.1
+ _ZN7libecap13TextExceptionD1Ev@Base 1.0.1
+ _ZN7libecap13TextExceptionD2Ev@Base 1.0.1
+ _ZN7libecap13VersionStringEv@Base 1.0.1
+ _ZN7libecap13headerRefererE@Base 1.0.1
+ _ZN7libecap13methodConnectE@Base 1.0.1
+ _ZN7libecap13methodOptionsE@Base 1.0.1
+ _ZN7libecap13protocolHttpsE@Base 1.0.1
+ _ZN7libecap13protocolWhoisE@Base 1.0.1
+ _ZN7libecap14protocolGopherE@Base 1.0.1
+ _ZN7libecap15RegisterServiceEPNS_7adapter7ServiceE@Base 1.0.1
+ _ZN7libecap15headerXClientIpE@Base 1.0.1
+ _ZN7libecap15headerXServerIpE@Base 1.0.1
+ _ZN7libecap16metaNextServicesE@Base 1.0.1
+ _ZN7libecap16metaResponseDescE@Base 1.0.1
+ _ZN7libecap16metaResponseInfoE@Base 1.0.1
+ _ZN7libecap16metaSubscriberIdE@Base 1.0.1
+ _ZN7libecap19headerContentLengthE@Base 1.0.1
+ _ZN7libecap20StdStringAreaDetailsD0Ev@Base 1.0.1
+ _ZN7libecap20StdStringAreaDetailsD1Ev@Base 1.0.1
+ _ZN7libecap20StdStringAreaDetailsD2Ev@Base 1.0.1
+ _ZN7libecap21metaAuthenticatedUserE@Base 1.0.1
+ _ZN7libecap22headerTransferEncodingE@Base 1.0.1
+ _ZN7libecap23metaAuthenticatedGroupsE@Base 1.0.1
+ _ZN7libecap24RegisterVersionedServiceEPNS_7adapter7ServiceEPKc@Base 1.0.1
+ (arch-bits=32)_ZN7libecap4Area14FromTempBufferEPKcj@Base 1.0.1
+ (arch-bits=64)_ZN7libecap4Area14FromTempBufferEPKcm@Base 1.0.1
+ 
_ZN7libecap4Area14FromTempStringERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base
 1.0.1
+ _ZN7libecap4Name6NextIdEv@Base 1.0.1
+ _ZN7libecap4Name9TheLastIdE@Base 1.0.1
+ 
_ZN7libecap4NameC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 
1.0.1
+ 
_ZN7libecap4NameC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base 
1.0.1
+ _ZN7libecap4NameC1Ev@Base 1.0.1
+ 
_ZN7libecap4NameC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 
1.0.1
+ 
_ZN7libecap4NameC2ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEi@Base 
1.0.1
+ _ZN7libecap4NameC2Ev@Base 1.0.1
+ _ZN7libecap4NameD1Ev@Base 1.0.1
+ _ZN7libecap4NameD2Ev@Base 1.0.1
+ 

Bug#671847: #3879: mutt: encoded-words are not decoded in mailto:

[Mutt]

#3879: mutt: encoded-words are not decoded in mailto:
+--
  Reporter:  antonio@…  |  Owner:  mutt-dev
  Type:  defect | Status:  new
  Priority:  major  |  Milestone:
 Component:  charset|Version:  1.7.0
Resolution: |   Keywords:
+--
Changes (by kevin8t8):

 * Attachment "ticket-3879.patch" added.


--
Ticket URL: 
Mutt 
The Mutt mail user agent

Bug#671847: #3879: mutt: encoded-words are not decoded in mailto:

[Mutt]

#3879: mutt: encoded-words are not decoded in mailto:
+--
  Reporter:  antonio@…  |  Owner:  mutt-dev
  Type:  defect | Status:  new
  Priority:  major  |  Milestone:
 Component:  charset|Version:  1.7.0
Resolution: |   Keywords:
+--

Comment (by kevin8t8):

 I'm attaching a proposed patch.  This just adds a rfc2047 decode call for
 the header values (with the exception of body).  I think this should solve
 the problem for the basic "subject" case.

 One concern I have is for other address fields, e.g. Cc, whether doing the
 decode before the mutt_parse_rfc822_line() call is acceptable.  I'll have
 to think about that a bit more before I commit it.

--
Ticket URL: 
Mutt 
The Mutt mail user agent

Bug#822555: ffmpeg: please compile with --enable-libtesseract

[Bálint Réczey]

Hi Sebastian,

2016-09-24 21:56 GMT+02:00 Sebastian Ramacher :
> Hi
>
> On 2016-09-07 03:33:38, Bálint Réczey wrote:
>> Control: tags -1 confirmed patch
>>
>> Hi Jan,
>>
>> 2016-04-25 12:43 GMT+02:00 Jan Gerber :
>> > Package: ffmpeg
>> > Version: 7:3.0.1-3
>> > Severity: wishlist
>> >
>> > Dear Maintainer,
>> >
>> > FFmpeg 3.0 introduced a new ocr filter that depends on libtesseract.
>> > Would be nice to see this enabled in Debian.
>>
>> I have prepared a patch which may be enough.
>> It needs testing however. Sebastian, what do you think?
>
> I'm not a huge fan of adding more -extra flavors [1], but the patch looks 
> okayish.
> The dh_auto_build-arch override may need to be updated, though.

It seems to still work well since libavfilter is recompiled properly.
The package also works, it performs OCR.

I have tested it using the image and script from here:
http://ffmpeg-users.933282.n4.nabble.com/How-to-use-ocr-filter-td4672454.html

ffprobe -show_entries frame_tags=lavfi.ocr.text -f lavfi -i "movie=img.png,ocr"

One also need to install tesseract-ocr-eng to make it work.

Pushing the commit to ffmpeg.git.

Cheers,
Balint

Bug#838944: vimhelp-de: depends on vim 7.4 but unstable has vim 8.0

[Emilio Pozuelo Monfort]

Package: vimhelp-de
Version: 7.4.130818-2
Severity: serious

SSIA

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

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

Bug#838943: ITP: commonmark-bkrs -- Python parser for the CommonMark Markdown spec

[Jerome Benoit]

Package: wnpp
Severity: wishlist
Owner: Jerome Benoit 

* Package name: commonmark-bkrs
  Version : 0.5.4
  Upstream Author : Roland Shoemaker 
* URL : https://github.com/rolandshoemaker/CommonMark-py
* License : BSD
  Programming Lang: Python
  Description : Python parser for the CommonMark Markdown spec

Pure Python port of `jgm''s CommonMark, a Markdown parser and renderer for the
CommonMark (http://commonmark.org) specification, using only native modules.

This provides the CommonMark-py Python package as developed by Bibek Kafle and
Roland Shoemaker (BKRS). After release 0.5.4, their project moved to `Read the
Docs' (http://readthedocs.org) and major changes broke compatibility. However
some Python packages may still depend on their last implementation, hence this
Debian package which is meant to smooth the transition.

Bug#838942: letsencrypt.sh: fails without ca-certificates, needs dependency

[Ariel]

Source: letsencrypt.sh
Version: 0.2.0-4~bpo8+1
Severity: normal

If you try to run letsencrypt.sh -c without ca-certificates installed you get:
ERROR: Problem connecting to server (curl returned with 60)

After installing the package it works fine. Since it fails without it, you 
should add a dependency.

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

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

Bug#780155: ITP: baculum -- Baculum WebGUI tool for Bacula Community program

[Carsten Leonhardt]

Control: retitle -1 RFP: baculum -- Baculum WebGUI tool for Bacula Community 
program
Control: submitter -1 pkg-bacula-de...@lists.alioth.debian.org

Hi Marcin,

thanks for your feedback.

> You can close this ITP requires if you want. I am not sure what is the
> procedure for this type of cases.

I've changed it to a "Request for Package", so that if someone else will
pick this up they can see the previous information contained in this bug
report.

To anyone interested in packaging this: it would be nice to do this
under the Bacula Packaging Team umbrella.

 - Carsten

Bug#831248: maxima: FTBFS: tests failures

[Camm Maguire]

tags 831248 unreproducible
severity 831248 important
thanks

Greetings!  I cannot reproduce this, but can imagine how this might be
triggered.  Can you detail your setup, especially how much ram/swap was
available at runtime?  Can I ssh into this environment?

Take care,

Lucas Nussbaum  writes:

> Source: maxima
> Version: 5.38.0-3
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160714 qa-ftbfs
> Justification: FTBFS on amd64
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
>
> Relevant part (hopefully):
>> make[2]: Entering directory '/«PKGBUILDDIR»'
>> make[2]: Nothing to be done for 'all-am'.
>> make[2]: Leaving directory '/«PKGBUILDDIR»'
>> make[1]: Leaving directory '/«PKGBUILDDIR»'
>> echo ':lisp (setq maxima::*maxima-started* nil si::*optimize-maximum-pages* 
>> t si::*code-block-reserve* (make-array 1000 :element-type (quote 
>> character) :static t))(si::sgc-on nil)(si::gbc t)(si::save-system "foo")' | 
>> ./maxima-local && mv foo src/binary-gcl/maxima
>> Maxima 5.38.0 http://maxima.sourceforge.net
>> using Lisp GNU Common Lisp (GCL) GCL 2.6.12
>> Distributed under the GNU Public License. See the file COPYING.
>> Dedicated to the memory of William Schelter.
>> The function bug_report() provides bug reporting information.
>> (%i1) chmod +x ./maxima-local
>> touch tests/tests-gcl.log
>> ./maxima-local -g --lisp=gcl --batch-string="run_testsuite();"  >tmp 2>&1 & \
>>  j=$! ; echo Waiting on pid $j ; \
>>  tail -f --pid=$j --retry tests/tests-gcl.log tmp & wait $j
>> Waiting on pid 25726
>> tail: warning: --retry only effective for the initial open
>> ==> tests/tests-gcl.log <==
>> 
>> ==> tmp <==
>> 
>> Maxima 5.38.0 http://maxima.sourceforge.net
>> using Lisp GNU Common Lisp (GCL) GCL 2.6.12
>> Distributed under the GNU Public License. See the file COPYING.
>> Dedicated to the memory of William Schelter.
>> The function bug_report() provides bug reporting information.
>> (%i1) run_testsuite()
>> Running tests in rtest_rules: 103/103 tests passed
>> Running tests in rtestnset: 597/597 tests passed
>> Running tests in rtest1: 180/180 tests passed (not counting 1 expected 
>> errors)
>> Running tests in rtest1a: 27/27 tests passed
>> Running tests in rtest2: 144/144 tests passed (not counting 2 expected 
>> errors)
>> Running tests in rtest4: 93/93 tests passed
>> Running tests in rtest5: start address -T 0x28f2010 start address -T 
>> 0x2922ae0 start address -T 0x292a250 start address -T 0x292e730 start 
>> address -T 0x2932bb0 start address -T 0x293b6b0 start address -T 0x2940800 
>> start address -T 0x2944360 80/80 tests passed
>> Running tests in rtest6: 39/39 tests passed
>> Running tests in rtest6a: 62/62 tests passed
>> Running tests in rtest6b: 16/16 tests passed
>> Running tests in rtest7: 85/85 tests passed
>> Running tests in rtest9: 89/89 tests passed
>> Running tests in rtest9a: 76/76 tests passed
>> Running tests in rtest10: 62/62 tests passed (not counting 2 expected errors)
>> Running tests in rtest11: 181/181 tests passed
>> Running tests in rtest13: 23/23 tests passed
>> Running tests in rtest13s: 17/17 tests passed
>> Running tests in rtest14: 418/418 tests passed
>> Running tests in rtest15: 334/334 tests passed
>> Running tests in rtest16: 540/540 tests passed
>> Running tests in rtestode: 90/90 tests passed
>> Running tests in rtestode_zp: 30/30 tests passed
>> Running tests in rtest3: 149/149 tests passed
>> Running tests in rtest8: 
>> ** Problem 133 ***
>> Input:
>> (compile(foo17), first(quad_qags(foo17, u, - 1, 0)))
>> 
>> 
>> Result:
>> Compiling /tmp/gazonk_25726_0.lsp.
>> End of Pass 1.  
>> End of Pass 2.  
>> error-catch
>> 
>> This differed from the expected result:
>> - 0.359753467469551
>> 
>> 163/164 tests passed
>> 
>> The following 1 problem failed: (133)
>> Running tests in rtest12: 79/79 tests passed (not counting 2 expected errors)
>> Running tests in rexamples: 137/137 tests passed
>> Running tests in rtesthyp: 423/423 tests passed (not counting 6 expected 
>> errors)
>> Running tests in rtest_hypgeo: 291/291 tests passed (not counting 1 expected 
>> errors)
>> Running tests in rtestmt19937: 15/15 tests passed
>> Running tests in rtest_allnummod: 544/544 tests passed
>> Running tests in rtestconjugate: 136/136 tests passed
>> Running tests in rtestsum: 306/306 tests passed (not counting 4 expected 
>> errors)
>> Running tests in rtest_trig: 160/160 tests passed
>> Running tests in rtest_zeta: 22/22 tests passed
>> Running tests in rtest_diff_invtrig: 22/22 tests passed
>> Running tests in rtest_scalarp: 20/20 tests passed
>> Running tests in rtest_everysome: 84/84 tests passed
>> Running tests in rtestint: 287/287 tests passed
>> Running tests in rtest_numth: 201/201 tests passed
>> Running tests in rtestifactor: 25/25 tests passed
>> Running tests in rtest_equal: 207/207 tests passed (not counting 2 

Bug#834927: maxima: Draw package fails to find 'libvtkCommonCoreTCL-6.3.so'.

[Camm Maguire]

reassign 834927 vtk6
thanks

Greetings, and thanks for your report!  Maxima only calls vtk via a
shell system call using script input it writes to a file.

Take care,

"Thomas E. Vaughan"  writes:

> Package: maxima
> Version: 5.38.0-3
> Severity: normal
>
> The 'draw3d' function defined int he 'draw' package for maxima is failing.
>
> In a conversation with me on debian-user, Nicolas George suggests that maxima
> should be referring to the library through the SONAME, not through the file
> ending with '.so'.  That is, one should not have to install the corresponding
> '-dev' package.
>
> Being not too bright, I had worked around this by manually making a few
> symlinks via a shell script.  It seems that I might better have worked around
> the problem by installing an appropriate '-dev' package, but I don't know what
> the right package would be.  There seems to be no 'tcl-vtk6-dev' package in
> Debian unstable.  But I didn't look hard to find an appropriately named
> package.
>
> I am running Debian unstable with maxima, vtk6, and tcl-vtk6 installed
> according to documation here: http://riotorto.users.sourceforge.net/vtk/
>
> The error output (pasted below) refers to a file that does not exist:
> /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so
>
> Using 'dpkg -S libvtkCommonCoreTCL', I find
> libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3.0
> libvtk6.3: /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so.6.3
>
> Here is the error message:
>
> (%i8) draw3d(color=white,elevation_grid(m,0,0,10,10));
> (%o8)done
> (%i9) couldn't load file 
> "/usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so": 
> /usr/lib/x86_64-linux-gnu/libvtkCommonCoreTCL-6.3.so: cannot open shared 
> object file: No such file or directory
> attempt to provide package vtkCommonCoreTCL 6.3 failed: no version of package 
> vtkCommonCoreTCL provided
> attempt to provide package vtkcommoncore 6.3 failed: no version of package 
> vtkcommoncore provided
> Error in startup script: attempt to provide package vtk 6.3 failed: no 
> version of package vtk provided
> ("package ifneeded vtk 6.3" script)
> invoked from within
> "package.orig require vtk"
> ("eval" body line 1)
> invoked from within
> "eval package.orig $args"
> (procedure "package" line 2)
> invoked from within
> "package require vtk"
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages maxima depends on:
> ii  libc6 2.23-4
> ii  libgmp10  2:6.1.1+dfsg-1
> ii  libreadline6  6.3-8+b4
> ii  libx11-6  2:1.6.3-1
>
> Versions of packages maxima recommends:
> ii  gnuplot-x11   5.0.4+dfsg1-3
> ii  maxima-share  5.38.0-3
>
> Versions of packages maxima suggests:
> ii  maxima-doc5.38.0-3
> pn  maxima-emacs  
> pn  texmacs   
> ii  tk [wish] 8.6.0+9
> ii  xmaxima   5.38.0-3
>
> -- no debconf information

-- 
Camm Maguirec...@maguirefamily.org
==
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Bug#819664: .sign suffix?

[Eduard Bloch]

Hallo,
* Steve McIntyre [Mon, Sep 26 2016, 03:14:21PM]:
> On Mon, Sep 26, 2016 at 09:10:37AM +0200, Stéphane Blondon wrote:
> >Hello,
> >
> >Le 25/09/2016 à 17:57, Eduard Bloch a écrit :
> >> I am slightly wondering about this new filename ending .sign. IMHO the
> >> usual pattern for such files was .gpg before (for example: Release.gpg).
> >> 
> >> This .sign looks weird, it does not tell you which format the data
> >> inside might have.
> >
> >Can you provide an example where the extension has changed?
> >
> >There are signatures ending with .sign for each cd, dvd, etc. images but
> >the suffix seems to be always .sign since release 3.1:
> >http://cdimage.debian.org/cdimage/archive/3.1_r0/i386/iso-cd/
> >
> >it's like today:
> >http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/
> >
> >The scheme is
> >{MD5, SHAx}SUMS : the checksum according to each algorithm
> >{MD5, SHAx}SUMS.sign : the checksum signed by a Debian CD signing key
> 
> Exactly - we've been using the .sign filenames for many years for CD
> releases.

Uhm, ok, sorry, please forgive my failure to research.

Best regards,
Eduard.

Bug#836362: closed by Michael Biebl <bi...@debian.org> (Re: Bug#836362: closed by Michael Biebl <bi...@debian.org> (Re: Breakes at least virt-viewer competly))

[Klaus Ethgen]

Idiot!

Read the mails you get!

And don't be the stupid idiot you are!

-- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C

Bug#817563: libxml-dumper-perl: Removal of debhelper compat 4

[Chris Lamb]

tags 817563 + pending patch
thanks

I've uploaded libxml-dumper-perl 0.81-1.2 to DELAYED/5:
  
  libxml-dumper-perl (0.81-1.2) unstable; urgency=medium
  
* Non-maintainer upload.
* Move to debhelper compat level 9. (Closes: #817563)
* Move debhelper to Build-Depends (from Build-Depends-Indep) to satisfy 
clean
  target.

The full debdiff is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff -u libxml-dumper-perl-0.81/debian/changelog 
libxml-dumper-perl-0.81/debian/changelog
--- libxml-dumper-perl-0.81/debian/changelog
+++ libxml-dumper-perl-0.81/debian/changelog
@@ -1,3 +1,12 @@
+libxml-dumper-perl (0.81-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Move to debhelper compat level 9. (Closes: #817563)
+  * Move debhelper to Build-Depends (from Build-Depends-Indep) to satisfy clean
+target.
+
+ -- Chris Lamb   Mon, 26 Sep 2016 23:44:25 +0200
+
 libxml-dumper-perl (0.81-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u libxml-dumper-perl-0.81/debian/compat 
libxml-dumper-perl-0.81/debian/compat
--- libxml-dumper-perl-0.81/debian/compat
+++ libxml-dumper-perl-0.81/debian/compat
@@ -1 +1 @@
-4
+9
diff -u libxml-dumper-perl-0.81/debian/control 
libxml-dumper-perl-0.81/debian/control
--- libxml-dumper-perl-0.81/debian/control
+++ libxml-dumper-perl-0.81/debian/control
@@ -3,7 +3,8 @@
 Priority: optional
 Maintainer: Florian Hinzmann 
 Standards-Version: 3.6.2
-Build-Depends-Indep: perl (>= 5.6.0-16), debhelper (>= 4)
+Build-Depends: debhelper (>= 9)
+Build-Depends-Indep: perl (>= 5.6.0-16)
 
 Package: libxml-dumper-perl
 Architecture: all

Bug#838888: dh-haskell: "Experimental push on scalar is now forbidden at [..]/Buildsystem/haskell.pm"

[Chris Lamb]

tags 83 + patch
thanks

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/lib/Debian/Debhelper/Buildsystem/haskell.pm 
b/lib/Debian/Debhelper/Buildsystem/haskell.pm
index b5644a1..f7aa96f 100644
--- a/lib/Debian/Debhelper/Buildsystem/haskell.pm
+++ b/lib/Debian/Debhelper/Buildsystem/haskell.pm
@@ -466,7 +466,7 @@ Readonly my $TMP_INSTALL_DIR => 
"debian/tmp-install-$HC_BIN";
 
 sub do_dispatch {
 my %INSTALL = ( dev => [], prof => [], doc => [], bin => [], );
-my $dispatch = sub { push $INSTALL{ @_[0] }, $_ };
+my $dispatch = sub { push @{$INSTALL{ @_[0] }}, $_ };
 
 my $dispatcher = sub {
 no strict 'subs';# barewords sometimes are neat

Bug#831587: stressapptest: please make the build reproducible

[Chris Lamb]

> https://anonscm.debian.org/git/collab-maint/stressapptest.git/commit/?id=57885d7144ac4eb9d3861cbf579a0b45a07f9ca3

- This won't be reproducible as $username is not fixed too. 

- I don't think always setting "hostname" to "localhost" is right.
  Feels wrong.

- Using "Author: [me]" when I did not write the patch is... strange.

Why not follow my previous suggestion of wrapping the:

 AC_DEFINE_UNQUOTED([STRESSAPPTEST_TIMESTAMP],

when SOURCE_DATE_EPOCH is set?

:)


Regards,

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

Bug#831587: stressapptest: please make the build reproducible

[Blanc Pierre]

Hi Chris,

> Well, I am 100% certain you do not want to be patching the generated
> ./configure file so I would not upload this.
You have totally right.

I used you previous patch.
https://anonscm.debian.org/git/collab-maint/stressapptest.git/commit/?id=57885d7144ac4eb9d3861cbf579a0b45a07f9ca3

And this is the package uploaded on mentors:
https://mentors.debian.net/package/stressapptest

Best regards

Bug#615368: gcolor2: please use Homepage field to point to upstream homepage

[Fernando Ike]

Control: tags 615368 patch
Control: tags 615368 pending

Hi,

  I made a NMU and it upload to 10-day/delay queue. Feel free to cancel
this upload if needed.

  The debian/changelog is:

gcolor2 (0.4-2.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Update DH level to 9. (Closes: #817472)
  * debian/control:
- Added depends ${misc:Depends}.
- Added Homepage field. (Closes: #615368)
- Bumped Standards-Version to 3.9.8
  * debian/watch:
- Added watch file.


  I attached a debdiff.

Regards,

-- 
Fernando Ike
http://www.fernandoike.com


gcolor2.debdiff
Description: Binary data

Bug#838877: Installing packages writes to unexpected locations

[Guillem Jover]

Control: tags -1 moreinfo

On Sun, 2016-09-25 at 16:46:56 -0700, Elliott Mitchell wrote:
> Package: dpkg
> Version: 1.17.27

> When installing packages which *only* have files in /usr, I generally
> try to leave / read-only.  With the recent release of `dpkg` though this
> has become problematic.

Do you mean that it used to work, and it does not anymore. In which
case, what versions?

> >From the error message, during unpacking `dpkg` is trying to create a
> file/directory as /usr.dpkg-tmp, which fails if / is read-only.  This
> could actually cause some problems.  Notably if `dpkg` is doing this to
> check whether the filesystem has sufficient free space, this check *WILL*
> fail since / and /usr could well be different filesystems.  This could
> also cause trouble if /usr.dpkg-tmp is large and / has limited free
> space.

This should not happen for pre-existing directories, and dpkg should
skip those. The actual error message would be helpful here. Also the
debug output from using -D113 would also be helpful.

> I'm unsure how to rate the severity of this issue.  This is distinctly
> annoying and can trigger warning flags, but I suppose in many cases it
> won't cause problems for people.  Folks who always remount / read-write
> when upgrading packages may well not notice, but those of use who pay a
> bit more attention do notice.

I'm actually very surprised by this bug report, because something
related was fixed in dpkg 1.17.14, so the version you are reporting
against should actually behave better for your use case:

  * Never try to remove the root directory or its backups. There's no point in
it, and makes life more difficult for a read-only root with a read-write
overlay or a symlink farm. Requested by sepero...@gmx.com.

Thanks,
Guillem

Bug#817472: gcolor2: Removal of debhelper compat 4

[Fernando Ike]

Control: tags 817472 patch
Control: tags 817472 pending

Hi,

  I made a NMU and it upload to 10-day/delay queue. Feel free to cancel
this upload if needed.

  The debian/changelog is:

gcolor2 (0.4-2.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Update DH level to 9. (Closes: #817472)
  * debian/control:
- Added depends ${misc:Depends}.
- Added Homepage field. (Closes: #615368)
- Bumped Standards-Version to 3.9.8
  * debian/watch:
- Added watch file.


  I attached a debdiff.

Regards,
-- 
Fernando Ike
http://www.fernandoike.com


gcolor2.debdiff
Description: Binary data

Bug#838941: RFS: duperemove/0.11~beta3-3 ITP

[peter . zahradnik]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

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

 * Package name: duperemove
   Version : 0.11~beta3-3
   Upstream Author : Mark Fasheh 
 * URL : https://github.com/markfasheh/duperemove
 * License : GPL-2, GPL-2+, BSD-2-Clause
   Section : admin

  It builds those binary packages:

duperemove - Tools for deduping file systems

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


  https://mentors.debian.net/package/duperemove


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


dget -x 
https://mentors.debian.net/debian/pool/main/d/duperemove/duperemove_0.11~beta3-3.dsc


  Regards,
  Peter Zahradnik

Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Martin Steigerwald]

Am Montag, 26. September 2016, 13:53:21 CEST schrieb Josh Triplett:
> On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote:
> > Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett:
> > > On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote:
> > > > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett:
> > > > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald
> > > > > 
> > > > 
> > > > wrote:
> > > > > > Package: systemd
> > > > > > Version: 231-5
> > > > > > Severity: minor
> > > > > > 
> > > > > > Dear Martin, dear Michael, dear Systemd maintainers,
> > > > > > 
> > > > > > systemctl status for a long time just printed the status directly
> > > > > > onto
> > > > > > the
> > > > > > terminal (Konsole in my case). But since also quite a while it
> > > > > > uses
> > > > > > less
> > > > > > on
> > > > > > my system, even tough the output is not larger than one page.
> > > > > > 
> > > > > > Also the color escape sequences are not executed by less, leavinge
> > > > > > me
> > > > > > with
> > > > > > something like:
> > > > > > 
> > > > > > ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting
> > > > > > daemon
> > > > > > 
> > > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
> > > > > >vendor
> > > > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since
> > > > > >So
> > > > > >2016-09-04 10:48:07 CEST; 1s ago>
> > > > > >
> > > > > >  Docs: man:atopacctd(8)
> > > > > >   
> > > > > >   Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited,
> > > > > >   status=0/SUCCESS)
> > > > > >  
> > > > > >  Main PID: 5034 (atopacctd)
> > > > > >  
> > > > > > Tasks: 1 (limit: 4915)
> > > > > >
> > > > > >CGroup: /system.slice/atopacct.service
> > > > > >
> > > > > >└─5034 /usr/sbin/atopacctd
> > > > > > 
> > > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process
> > > > > > accounting
> > > > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service:
> > > > > > PID
> > > > > > file
> > > > > > /run/atopacctd.pid not readable (yet?) after start: No such file
> > > > > > or
> > > > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3
> > > > > > -
> > > > > > 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]:
> > > > > > Started
> > > > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba
> > > > > > atopacctd[5034]:
> > > > > > ^[[0;1;39mreactivate process accounting^[[0m
> > > > > 
> > > > > Works fine here with systemd 231-5: "systemctl status" uses less,
> > > > > but it
> > > > > interprets color escape sequences, and exits if the output fits
> > > > > entirely
> > > > > on the screen.  Can you provide your environment (output of "env"),
> > > > > and
> > > > > in particular the values of $LESS and $PAGER?  And can you check if
> > > > > this
> > > > > occurs in another terminal, such as xterm?
> > > > 
> > > > Thanks for your answer Josh. I missed it first seems it was sortet
> > > > more
> > > > downwards due to old date:
> > > > 
> > > > 
> > > > merkaba:~> systemctl status
> > > > merkaba:~> echo $LESS
> > > > 
> > > >  -w
> > > > 
> > > > merkaba:~> echo $PAGER
> > > > 
> > > > I do not know who has put that "-w" into LESS variable.
> > > > 
> > > > But removing it doesn´t help:
> > > > 
> > > > merkaba:~> unset LESS
> > > > merkaba:~> systemctl status
> > > > ^[[0;1;31m●^[[0m merkaba
> > > > 
> > > > State: ^[[0;1;31mdegraded^[[0m
> > > > 
> > > >  Jobs: 0 queued
> > > >
> > > >Failed: 2 units
> > > >
> > > > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago
> > > >
> > > >CGroup: /
> > > > 
> > > > Same in xterm.
> > > > 
> > > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64
> > > > less:amd64/sid 481-2.1 uptodate
> > > > systemd:amd64/sid 231-7 uptodate
> > > 
> > > What happens if you explicitly export LESS=R ?  Does that help?
> > 
> > No.
> > 
> > > Try running the following in your terminal:
> > > 
> > > /usr/bin/printf '\e[0;1;31mRED\e[0m'
> > > 
> > > Does the word "RED" show up in red?
> > 
> > Yes.
> > 
> > > Also try this:
> > > 
> > > /usr/bin/printf '\e[2J'
> > > 
> > > Does that clear your screen?
> > 
> > Yes.
> > 
> > Okay, I think I found something:
> > 
> > martin@merkaba:~> echo $SHELL
> > /usr/bin/zsh
> > martin@merkaba:~> systemctl status
> > 
> > ^[[0;1;31m●^[[0m merkaba
> > 
> > State: ^[[0;1;31mdegraded^[[0m
> > 
> >  Jobs: 0 queued
> >
> >Failed: 2 units
> > 
> > But:
> > 
> > 
> > martin@merkaba:~> bash
> > martin@merkaba:~ -> systemctl status
> > 
> > ● merkaba
> > 
> > State: degraded
> > 
> >  Jobs: 0 queued
> >
> >Failed: 2 units
> > 
> > The red dot and degraded are in red.
> > 
> > 
> > So seems some interaction with Z-Shell, that leads to broken escape
> > sequences.
> > 
> > I use zsh 5.2-5.
> 
> Ah, interesting.  Perhaps zsh puts the 

Bug#838915: saga: Segmentation fault in CSG_Projections::WKT_to_Proj4() with merge layers

[Johan Van de Wauw]

A somewhat dirty workaround, but since the projection on both files is
identical, you can actually skip using proj at all by removing/renaming the
*.prj files. Then merging should work.

Bug#838915: saga: Segmentation fault in CSG_Projections::WKT_to_Proj4() with merge layers

[Johan Van de Wauw]

Thanks for your report.

I can confirm this also happens on debian unstable. I'll investigate
further.

Bug#838940: rdtool: rd2man-lib.rb messes up with following DescListItem, if Description is multi-TextBlock

[Francesco Poli (wintermute)]

Package: rdtool
Version: 0.6.38-4
Severity: important

Hello again,
I think I found one more bug in rd2man-lib.rb .

Steps to reproduce with the attached trivial Ruby Document file:

  $ rd2 -r rd/rd2html-lib.rb -o desc desc.rd

Everything's fine. The resulting HTML file looks OK:

  $ sensible-browser desc.html

But, if I want to get a man page:

  $ rd2 -r rd/rd2man-lib.rb -o desc desc.rd

the resulting man page is:

  $ cat desc.1 
  .\" DO NOT MODIFY THIS FILE! it was generated by rd2
  .TH DESC 1 "September 2016"
  .TP
  .fi
  .B
  Term
  Description.

  More description..TP
  .fi
  .B
  Another term
  Another description.

which lacks the newline character before the second .TP
causing

  More description.
  .TP

to become

  More description..TP

Visualizing the man page confirms that the second DescListItem is not
rendered correctly:

  $ man ./desc.1


Is there anything I failed to understand?

If this is indeed a bug in rd2man-lib.rb, please investigate the issue
and fix it, and/or forward my bug report upstream.

Thanks for your time.
Bye!


P.S.: I think the attached test case is so trivial that it is not copyrighted.
  Hence no license should be needed, for the file to be copied, modified,
  and/or distributed. Anyway, should this turn out to be false, I hereby
  grant premission to deal with the file under the terms of the Expat/MIT
  license 


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

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

Versions of packages rdtool depends on:
ii  ruby 1:2.3.0+4
ii  ruby-rd  0.6.38-4

rdtool recommends no packages.

rdtool suggests no packages.

-- no debconf information


desc.rd.gz
Description: application/gzip

Bug#786471: missing return rule when ENABLE_AUTO_IDS Y

[Franck Joncourt]

Hi,

I took a look.

There is no problem with iptables rules added by psad.

When psad blocks an IP, it adds a new chain PSAD_BLOCK_INPUT at the top
of your firewall rules.


Chain PSAD_BLOCK_INPUT (1 references)
target prot opt source   destination
DROP   all  --  franck.home  anywhere

This one means all packets coming from franck.home are dropped but other
packets continue their way through the INPUT chain until they reach a
target rule. If there is no match, then it matches the default policy on
INPUT chain which is most of the time DROP.

The firewall on my laptop blacklisted workstation #1 and there is no way
to access my ssh server on my laptop from workstation #1. However from
workstation #2, not blacklisted, I can access the ssh server available
on my laptop.

If you are fine with the explanation I will close this bug report.

http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html#toc7.4

Regards,

--
Franck



signature.asc
Description: OpenPGP digital signature

Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Josh Triplett]

On Mon, Sep 26, 2016 at 10:27:40PM +0200, Martin Steigerwald wrote:
> Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett:
> > On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote:
> > > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett:
> > > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald
> > > > 
> > > 
> > > wrote:
> > > > > Package: systemd
> > > > > Version: 231-5
> > > > > Severity: minor
> > > > > 
> > > > > Dear Martin, dear Michael, dear Systemd maintainers,
> > > > > 
> > > > > systemctl status for a long time just printed the status directly onto
> > > > > the
> > > > > terminal (Konsole in my case). But since also quite a while it uses
> > > > > less
> > > > > on
> > > > > my system, even tough the output is not larger than one page.
> > > > > 
> > > > > Also the color escape sequences are not executed by less, leavinge me
> > > > > with
> > > > > something like:
> > > > > 
> > > > > ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting daemon
> > > > > 
> > > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
> > > > >vendor
> > > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So
> > > > >2016-09-04 10:48:07 CEST; 1s ago>
> > > > >
> > > > >  Docs: man:atopacctd(8)
> > > > >   
> > > > >   Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited,
> > > > >   status=0/SUCCESS)
> > > > >  
> > > > >  Main PID: 5034 (atopacctd)
> > > > >  
> > > > > Tasks: 1 (limit: 4915)
> > > > >
> > > > >CGroup: /system.slice/atopacct.service
> > > > >
> > > > >└─5034 /usr/sbin/atopacctd
> > > > > 
> > > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting
> > > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID
> > > > > file
> > > > > /run/atopacctd.pid not readable (yet?) after start: No such file or
> > > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 -
> > > > > 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]: Started
> > > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba
> > > > > atopacctd[5034]:
> > > > > ^[[0;1;39mreactivate process accounting^[[0m
> > > > 
> > > > Works fine here with systemd 231-5: "systemctl status" uses less, but it
> > > > interprets color escape sequences, and exits if the output fits entirely
> > > > on the screen.  Can you provide your environment (output of "env"), and
> > > > in particular the values of $LESS and $PAGER?  And can you check if this
> > > > occurs in another terminal, such as xterm?
> > > 
> > > Thanks for your answer Josh. I missed it first seems it was sortet more
> > > downwards due to old date:
> > > 
> > > 
> > > merkaba:~> systemctl status
> > > merkaba:~> echo $LESS
> > > 
> > >  -w
> > > 
> > > merkaba:~> echo $PAGER
> > > 
> > > I do not know who has put that "-w" into LESS variable.
> > > 
> > > But removing it doesn´t help:
> > > 
> > > merkaba:~> unset LESS
> > > merkaba:~> systemctl status
> > > ^[[0;1;31m●^[[0m merkaba
> > > 
> > > State: ^[[0;1;31mdegraded^[[0m
> > > 
> > >  Jobs: 0 queued
> > >
> > >Failed: 2 units
> > >
> > > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago
> > >
> > >CGroup: /
> > > 
> > > Same in xterm.
> > > 
> > > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64
> > > less:amd64/sid 481-2.1 uptodate
> > > systemd:amd64/sid 231-7 uptodate
> > 
> > What happens if you explicitly export LESS=R ?  Does that help?
> 
> No.
> 
> > Try running the following in your terminal:
> > 
> > /usr/bin/printf '\e[0;1;31mRED\e[0m'
> > 
> > Does the word "RED" show up in red?
> 
> Yes.
> 
> > Also try this:
> > 
> > /usr/bin/printf '\e[2J'
> > 
> > Does that clear your screen?
> 
> Yes.
> 
> Okay, I think I found something:
> 
> martin@merkaba:~> echo $SHELL
> /usr/bin/zsh
> martin@merkaba:~> systemctl status
> 
> ^[[0;1;31m●^[[0m merkaba
> State: ^[[0;1;31mdegraded^[[0m
>  Jobs: 0 queued
>Failed: 2 units
> 
> But:
> 
> 
> martin@merkaba:~> bash
> martin@merkaba:~ -> systemctl status
> 
> ● merkaba
> State: degraded
>  Jobs: 0 queued
>Failed: 2 units
> 
> The red dot and degraded are in red.
> 
> 
> So seems some interaction with Z-Shell, that leads to broken escape sequences.
> 
> I use zsh 5.2-5.

Ah, interesting.  Perhaps zsh puts the terminal into an unexpected mode
somehow?

Can you run zsh with whatever options cause it to ignore all your shell
configuration and startup files?  Does that fix the problem?

If the *default* configuration of zsh causes this bug, I'd suggest
reassigning this bug to zsh.

- Josh Triplett

Bug#838939: RFS: devtodo/0.1.20-6.1 [NMU]

[Fernando Seiti Furusato]

Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: bren...@br.ibm.com

Dear mentors,

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

* Package name: devtodo
  Version : 0.1.20-6.1
  Upstream Author : Alec Thomas 
* URL : http://swapoff.org/DevTodo
* License : GPLv2
  Section : utils

It builds those binary packages:

  devtodo- hierarchical, prioritised todo list manager

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

 https://mentors.debian.net/package/devtodo

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/devtodo/devtodo_0.1.20-6.1.dsc

Changes since the last upload:

  * Non-maintainer upload.
  * debian/control: added dh-autoreconf as build-dep, removed its
dependencies and added libtool-bin to fix ftbfs. (Closes: #779551, #723964)
  * debian/rules
- added usage of dh-autoreconf
- expanded dh clean to include dh_autoreconf_clean before dh_clean

Regards,
Fernando Seiti Furusato




signature.asc
Description: OpenPGP digital signature

Bug#838938: rdtool: rd2man-lib.rb introduces spurious spaces around ((*emphasized*)) words in DescListItem Terms

[Francesco Poli (wintermute)]

Package: rdtool
Version: 0.6.38-4
Severity: important

Hello again,
I think I found another bug in rd2man-lib.rb .

Steps to reproduce with the attached trivial Ruby Document file:

  $ rd2 -r rd/rd2html-lib.rb -o emph emph.rd

Everything's fine. The resulting HTML file looks OK:

  $ sensible-browser emph.html

But, if I want to get a man page:

  $ rd2 -r rd/rd2man-lib.rb -o emph emph.rd

the resulting man page is:

  $ cat emph.1 
  .\" DO NOT MODIFY THIS FILE! it was generated by rd2
  .TH EMPH 1 "September 2016"
  .TP
  .fi
  .B
  Emphasized [ \fItext\fP ]
  Text surrounded by emphasis inline.

which has additional unintended spaces before and after the emphasis,
causing

  [\fItext\fP]
  
to become

  [ \fItext\fP ]

Visualizing the man page confirms that the the word [text] is displayed
spaced:

  $ man ./emph.1


Is there anything I failed to understand?

If this is indeed a bug in rd2man-lib.rb, please investigate the issue
and fix it, and/or forward my bug report upstream.

Thanks for your time!
Bye.


P.S.: I think the attached test case is so trivial that it is not copyrighted.
  Hence no license should be needed, for the file to be copied, modified,
  and/or distributed. Anyway, should this turn out to be false, I hereby
  grant premission to deal with the file under the terms of the Expat/MIT
  license 


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

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

Versions of packages rdtool depends on:
ii  ruby 1:2.3.0+4
ii  ruby-rd  0.6.38-4

rdtool recommends no packages.

rdtool suggests no packages.

-- no debconf information


emph.rd.gz
Description: application/gzip

Bug#731634: Bug#838937: xz-utils: diff for NMU version 5.2.2-1.1

[Sebastian Andrzej Siewior]

On 2016-09-26 22:16:02 [+0200], Sebastian Andrzej Siewior wrote:
> I've prepared an NMU for xz-utils (versioned as 5.2.2-1.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

And this version is the debian/ folder only ignoring the main version
change.

Sebastian
diff -Nru xz-utils-5.1.1alpha+20120614/debian/changelog xz-utils-5.2.2/debian/changelog
--- xz-utils-5.1.1alpha+20120614/debian/changelog	2015-06-18 20:27:36.0 +0200
+++ xz-utils-5.2.2/debian/changelog	2016-09-26 20:45:45.0 +0200
@@ -1,3 +1,15 @@
+xz-utils (5.2.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * switch to git-dpm for packaging (closes: #540405)
+  * New Upstream (closes: #731634)
+   - no more "xzless error in line 49" (closes: #693537)
+   - xzgrep -h works (closes: #780268)
+  * update symbol file
+  * enable threads for the "normal build"
+
+ -- Sebastian Andrzej Siewior   Mon, 26 Sep 2016 20:45:45 +0200
+
 xz-utils (5.1.1alpha+20120614-2.1) unstable; urgency=medium
 
   [ Helmut Grohne ]
diff -Nru xz-utils-5.1.1alpha+20120614/debian/clean.sh xz-utils-5.2.2/debian/clean.sh
--- xz-utils-5.1.1alpha+20120614/debian/clean.sh	2011-10-21 04:13:36.0 +0200
+++ xz-utils-5.2.2/debian/clean.sh	2016-09-26 20:45:45.0 +0200
@@ -38,7 +38,7 @@
 '
 
 dh_testdir
-rm -f debug/translation.bash tests/test_block.c ChangeLog
+rm -f debug/translation.bash tests/test_block.c
 rm -f ABOUT-NLS aclocal.m4 config.h.in configure
 (cd po && perl -e "$remove_files") < debian/generated-po.list
 (cd m4 && perl -e "$remove_files") < debian/generated-m4.list
diff -Nru xz-utils-5.1.1alpha+20120614/debian/.git-dpm xz-utils-5.2.2/debian/.git-dpm
--- xz-utils-5.1.1alpha+20120614/debian/.git-dpm	1970-01-01 01:00:00.0 +0100
+++ xz-utils-5.2.2/debian/.git-dpm	2016-09-26 20:45:45.0 +0200
@@ -0,0 +1,8 @@
+# see git-dpm(1) from git-dpm package
+e284cfe27457239e932038fb90084c91f4229c36
+e284cfe27457239e932038fb90084c91f4229c36
+141d36d7861b6e8522c213194d5fba1e47af63e9
+141d36d7861b6e8522c213194d5fba1e47af63e9
+xz-utils_5.2.2.orig.tar.xz
+72c567d3263345844191a7e618779b179d1f49e0
+1016404
diff -Nru xz-utils-5.1.1alpha+20120614/debian/patches/abi-liblzma2-compat xz-utils-5.2.2/debian/patches/abi-liblzma2-compat
--- xz-utils-5.1.1alpha+20120614/debian/patches/abi-liblzma2-compat	2012-10-12 00:38:38.0 +0200
+++ xz-utils-5.2.2/debian/patches/abi-liblzma2-compat	1970-01-01 01:00:00.0 +0100
@@ -1,208 +0,0 @@
-From: Jonathan Nieder 
-Date: Thu, 17 May 2012 18:49:00 -0500
-Subject: liblzma: skip ABI-incompatible check when liblzma.so.2 is loaded
-
-When liblzma started using ELF symbol versioning at the same time
-as a soname bump (2 → 5) and a small increase in the reserved space at
-the end of the lzma_stream structure checked by lzma_code, introducing
-an unversioned compatibility symbol to ease the transition seemed like
-a great idea.  After all:
-
- - most applications only use one version of the library (liblzma.so.2
-   or liblzma.so.5) and would obviously work fine
-
- - applications linking to the new version of the library
-   (liblzma.so.5) should use the default, versioned lzma_code symbol so
-   errors initializing the reserved space can be noticed
-
- - symbol versioning should ensure application/library mixtures
-   independently making use of both versions of the library also
-   work.  Calls using the unversioned symbol names would be resolved
-   using the old symbol from liblzma.so.2 or the compatibility symbol
-   from liblzma.so.5, avoiding segfaults and spurious
-   LZMA_OPTIONS_ERROR errors.
-
- - application/library mixtures using both versions of the library and
-   passing lzma_stream objects between the two would break, but that
-   was never supposed to be supported, anyway.
-
-Three toolchain bugs dash that plan.
-
-Current (2.22) versions of the gold linker cannot be used to build
-libraries providing versioned and unversioned symbols with the same
-name.  On the other hand, BFD ld doesn't mind.  So GNU gold refuses to
-link versions of liblzma including the compatibility symbol (PR12261):
-
-	/usr/bin/ld: error: symbol lzma_code has undefined version
-
-Annoying, but livable.  liblzma with the compatibility symbol just
-has to be built with BFD ld.
-
-More importantly, gold does not support linking to libraries providing
-versioned and unversioned symbols with the same name.  If I link some
-code to a version of liblzma with the compatibility symbol:
-
-	ld -o demo demo.o -llzma
-
-then the documented behavior, implemented by BFD ld, is to interpret
-calls to lzma_code as referring to the default version
-(lzma_code@XZ_5.0).  Current versions of GNU gold treat such calls as
-referring to whichever symbol comes first in liblzma.so.5's symbol
-table.  If the unversioned symbol comes first (and in Debian liblzma5
-5.1.1alpha+20110809-3 it does), GNU gold will mislink new applications
-to 

Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Martin Steigerwald]

Am Montag, 26. September 2016, 13:08:07 CEST schrieb Josh Triplett:
> On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote:
> > Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett:
> > > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald
> > > 
> > 
> > wrote:
> > > > Package: systemd
> > > > Version: 231-5
> > > > Severity: minor
> > > > 
> > > > Dear Martin, dear Michael, dear Systemd maintainers,
> > > > 
> > > > systemctl status for a long time just printed the status directly onto
> > > > the
> > > > terminal (Konsole in my case). But since also quite a while it uses
> > > > less
> > > > on
> > > > my system, even tough the output is not larger than one page.
> > > > 
> > > > Also the color escape sequences are not executed by less, leavinge me
> > > > with
> > > > something like:
> > > > 
> > > > ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting daemon
> > > > 
> > > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled;
> > > >vendor
> > > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So
> > > >2016-09-04 10:48:07 CEST; 1s ago>
> > > >
> > > >  Docs: man:atopacctd(8)
> > > >   
> > > >   Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited,
> > > >   status=0/SUCCESS)
> > > >  
> > > >  Main PID: 5034 (atopacctd)
> > > >  
> > > > Tasks: 1 (limit: 4915)
> > > >
> > > >CGroup: /system.slice/atopacct.service
> > > >
> > > >└─5034 /usr/sbin/atopacctd
> > > > 
> > > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting
> > > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID
> > > > file
> > > > /run/atopacctd.pid not readable (yet?) after start: No such file or
> > > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 -
> > > > 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]: Started
> > > > Atop process accounting daemon. Sep 04 10:48:07 merkaba
> > > > atopacctd[5034]:
> > > > ^[[0;1;39mreactivate process accounting^[[0m
> > > 
> > > Works fine here with systemd 231-5: "systemctl status" uses less, but it
> > > interprets color escape sequences, and exits if the output fits entirely
> > > on the screen.  Can you provide your environment (output of "env"), and
> > > in particular the values of $LESS and $PAGER?  And can you check if this
> > > occurs in another terminal, such as xterm?
> > 
> > Thanks for your answer Josh. I missed it first seems it was sortet more
> > downwards due to old date:
> > 
> > 
> > merkaba:~> systemctl status
> > merkaba:~> echo $LESS
> > 
> >  -w
> > 
> > merkaba:~> echo $PAGER
> > 
> > I do not know who has put that "-w" into LESS variable.
> > 
> > But removing it doesn´t help:
> > 
> > merkaba:~> unset LESS
> > merkaba:~> systemctl status
> > ^[[0;1;31m●^[[0m merkaba
> > 
> > State: ^[[0;1;31mdegraded^[[0m
> > 
> >  Jobs: 0 queued
> >
> >Failed: 2 units
> >
> > Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago
> >
> >CGroup: /
> > 
> > Same in xterm.
> > 
> > merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64
> > less:amd64/sid 481-2.1 uptodate
> > systemd:amd64/sid 231-7 uptodate
> 
> What happens if you explicitly export LESS=R ?  Does that help?

No.

> Try running the following in your terminal:
> 
> /usr/bin/printf '\e[0;1;31mRED\e[0m'
> 
> Does the word "RED" show up in red?

Yes.

> Also try this:
> 
> /usr/bin/printf '\e[2J'
> 
> Does that clear your screen?

Yes.

Okay, I think I found something:

martin@merkaba:~> echo $SHELL
/usr/bin/zsh
martin@merkaba:~> systemctl status

^[[0;1;31m●^[[0m merkaba
State: ^[[0;1;31mdegraded^[[0m
 Jobs: 0 queued
   Failed: 2 units

But:


martin@merkaba:~> bash
martin@merkaba:~ -> systemctl status

● merkaba
State: degraded
 Jobs: 0 queued
   Failed: 2 units

The red dot and degraded are in red.


So seems some interaction with Z-Shell, that leads to broken escape sequences.

I use zsh 5.2-5.

Thanks,
-- 
Martin

Bug#827953: maxima: Uses too much memory to build

[Camm Maguire]

Greetings!  The BTS seems to have swallowed my reply of yesterday to
you.  In any case, my results seem to show that the total build avoids
swap, and that Committed_AS is misleading relative to other variables in
/proc/meminfo for this purpose.

Does this close the issue for you?

(P.S. if you have the text of my results and can post it to the BTS in a
way that takes, that would be great.)

Take care,

Santiago Vila  writes:

> Package: maxima
> Version: 5.38.0-3
>
> Hello Camm.
>
> The more memory it has the machine on which I build this package,
> the more memory it uses during the build, and there does not seem to
> be a limit for that.
>
> Last time it was a machine with 8GB RAM. The file /proc/meminfo
> reported a Committed_AS memory of 17823MB (more than 17GB!).
>
> This is specially bad for me because I rely on /proc/meminfo to know
> how much memory the package "really" needs.
>
> While checking for "dpkg-buildpackage -A" I have measured the memory
> required to build around 3400 different source packages in stretch.
> If I order them by required memory, these are the last 20:
>
> [...]
> gnutls28 4189
> mapnik 4199
> mia 4279
> gcc-4.9 4287
> gap-guava 4315
> seqan 4376
> yade 4509
> webkit2gtk 4558
> llvm-toolchain-3.8 4673
> aces3 4795
> python2.7 5685
> libbson 5700
> webkitgtk 7015
> acl2 7355
> gap 8268
> gcl 9375
> mame 10363
> gdk-pixbuf 11564
> maxima 17823
> axiom 21190
>
> In practice, this means several things:
>
> * As I don't currently have such a big machine, I have to rent one to
> build those packages.
>
> * As they use so much memory, I can't use a 8GB plan or a 12GB plan, I
> have to use a 24GB plan (or whatever is close).
>
> * I need a bigger machine *only* to build the packages at the end of
> the above list.
>
> I know that you have been fine-tuning the memory usage for these
> programs lately, but it still happens that the more memory II have,
> the more memory they take, so I still have the problem that I can't
> measure how much memory they really need.
>
> Thanks.
> From unknown Mon Sep 26 19:22:45 2016
> X-Loop: ow...@bugs.debian.org
> Subject: Bug#827953: maxima: Uses too much memory to build
> Reply-To: Camm Maguire , 827...@bugs.debian.org
> Resent-From: Camm Maguire 
> Resent-To: debian-bugs-dist@lists.debian.org
> Resent-CC: Camm Maguire 
> X-Loop: ow...@bugs.debian.org
> Resent-Date: Sun, 10 Jul 2016 15:39:06 +
> Resent-Message-ID: 
> Resent-Sender: ow...@bugs.debian.org
> X-Debian-PR-Message: followup 827953
> X-Debian-PR-Package: maxima
> X-Debian-PR-Keywords: 
> X-Debian-PR-Source: maxima
> Received: via spool by 827953-sub...@bugs.debian.org 
> id=B827953.146816505024139
>   (code B ref 827953); Sun, 10 Jul 2016 15:39:06 +
> Received: (at 827953) by bugs.debian.org; 10 Jul 2016 15:37:30 +
> X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02
>   (2014-02-07) on buxtehude.debian.org
> X-Spam-Level: 
> X-Spam-Status: No, score=-4.4 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER,
>   HDRS_LCASE,NO_RDNS_DOTCOM_HELO,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,
>   RCVD_IN_MSPIKE_WL,T_MANY_HDRS_LCASE,URIBL_CNKR autolearn=ham
>   autolearn_force=no version=3.4.0-bugs.debian.org_2005_01_02
> X-Spam-Bayes: score:0. Tokens: new, 10; hammy, 150; neutral, 132; spammy,
>   0. spammytokens: hammytokens:0.000-+--python27, 0.000-+--python2.7,
>   0.000-+--H*f:sk:alpine., 0.000-+--H*u:Gnus, 0.000-+--H*u:linux
> Received: from vms173017pub.verizon.net ([206.46.173.17])
>   by buxtehude.debian.org with esmtps 
> (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128)
>   (Exim 4.84_2)
>   (envelope-from )
>   id 1bMGnS-0006H2-3e
>   for 827...@bugs.debian.org; Sun, 10 Jul 2016 15:37:30 +
> Received: from vz-proxy-m001.mx.aol.com ([64.236.83.14])
>  by vms173017.mailsrvcs.net
>  (Oracle Communications Messaging Server 7.0.5.32.0 64bit (built Jul 16 2014))
>  with ESMTPA id <0oa300dg7slhk...@vms173017.mailsrvcs.net> for
>  827...@bugs.debian.org; Sun, 10 Jul 2016 09:36:59 -0500 (CDT)
> X-CMAE-Score: 0
> X-CMAE-Analysis: v=2.1 cv=J+9Xl1TS c=1 sm=1 tr=0  
> a=MJxOpqxZADbEbEImuSX/mw==:117
>  a=kj9zAlcOel0A:10 a=cAmyUtKerLwA:10  a=9N09Ue-c:8 
> a=ZeoOlCyH8KQX3YoRE1wA:9
>  a=CjuIK1q_8ugA:10
> Received: by 173.61.133.218 with SMTP id 18f50746; Sun, 10 Jul 2016 14:36:59 
> GMT
> Received: from camm by localhost.m.enhanced.com with local (Exim 4.80)
>   (envelope-from )id 1bMFqR-0006PD-Im; 
> Sun,
>  10 Jul 2016 10:36:31 -0400
> From: Camm Maguire 
> To: Santiago Vila 
> Cc: 827...@bugs.debian.org
> References: 
> Date: Sun, 10 Jul 2016 10:36:31 -0400
> In-reply-to: 
>  (Santiago

Bug#836580: systemd: systemctl status pipes through less with escape sequences not applied

[Josh Triplett]

On Mon, Sep 26, 2016 at 12:10:34PM +0200, Martin Steigerwald wrote:
> Am Sonntag, 4. September 2016, 14:47:50 CEST schrieb Josh Triplett:
> > On Sun, 04 Sep 2016 10:59:07 +0200 Martin Steigerwald  
> wrote:
> > > Package: systemd
> > > Version: 231-5
> > > Severity: minor
> > > 
> > > Dear Martin, dear Michael, dear Systemd maintainers,
> > > 
> > > systemctl status for a long time just printed the status directly onto the
> > > terminal (Konsole in my case). But since also quite a while it uses less
> > > on
> > > my system, even tough the output is not larger than one page.
> > > 
> > > Also the color escape sequences are not executed by less, leavinge me with
> > > something like:
> > > 
> > > ^[[0;1;32m●^[[0m atopacct.service - Atop process accounting daemon
> > > 
> > >Loaded: loaded (/lib/systemd/system/atopacct.service; enabled; vendor
> > >preset: enabled) Active: ^[[0;1;32mactive (running)^[[0m since So
> > >2016-09-04 10:48:07 CEST; 1s ago>
> > >  Docs: man:atopacctd(8)
> > >   
> > >   Process: 5032 ExecStart=/usr/sbin/atopacctd (code=exited,
> > >   status=0/SUCCESS)
> > >  
> > >  Main PID: 5034 (atopacctd)
> > >  
> > > Tasks: 1 (limit: 4915)
> > >
> > >CGroup: /system.slice/atopacct.service
> > >
> > >└─5034 /usr/sbin/atopacctd
> > > 
> > > Sep 04 10:48:07 merkaba systemd[1]: Starting Atop process accounting
> > > daemon... Sep 04 10:48:07 merkaba systemd[1]: atopacct.service: PID file
> > > /run/atopacctd.pid not readable (yet?) after start: No such file or
> > > directory Sep 04 10:48:07 merkaba atopacctd[5034]: Version: 2.2-3 -
> > > 2015/06/25 11:07:21 […] Sep 04 10:48:07 merkaba systemd[1]: Started
> > > Atop process accounting daemon. Sep 04 10:48:07 merkaba atopacctd[5034]:
> > > ^[[0;1;39mreactivate process accounting^[[0m
> > Works fine here with systemd 231-5: "systemctl status" uses less, but it
> > interprets color escape sequences, and exits if the output fits entirely
> > on the screen.  Can you provide your environment (output of "env"), and
> > in particular the values of $LESS and $PAGER?  And can you check if this
> > occurs in another terminal, such as xterm?
> 
> Thanks for your answer Josh. I missed it first seems it was sortet more 
> downwards due to old date:
> 
> 
> merkaba:~> systemctl status
> merkaba:~> echo $LESS
>  -w
> merkaba:~> echo $PAGER
> 
> I do not know who has put that "-w" into LESS variable.
> 
> But removing it doesn´t help:
> 
> merkaba:~> unset LESS
> merkaba:~> systemctl status
> ^[[0;1;31m●^[[0m merkaba
> State: ^[[0;1;31mdegraded^[[0m
>  Jobs: 0 queued
>Failed: 2 units
> Since: So 2016-09-25 00:35:01 CEST; 1 day 11h ago
>CGroup: /
> 
> 
> Same in xterm.
> 
> merkaba:~> apt-show-versions | egrep "^less|^systemd:" | grep amd64
> less:amd64/sid 481-2.1 uptodate
> systemd:amd64/sid 231-7 uptodate

What happens if you explicitly export LESS=R ?  Does that help?

Try running the following in your terminal:

/usr/bin/printf '\e[0;1;31mRED\e[0m'

Does the word "RED" show up in red?

Also try this:

/usr/bin/printf '\e[2J'

Does that clear your screen?

Bug#838936: Vagrant + VirtualBox "Cable connected: off" + debian/jessie64 8.6.0

[Łukasz Zaremba]

Package: cloud.debian.org
Severity: normal

When installing "debian/jessie64" via Vagrant and using VirtualBox as a 
provider it seems that networking is not working (1).


VM is created with "Cable connected: off" status and Vagrant fails to boot.

Steps to reproduce (make sure to use box version 8.6.0):
$ mkdir test
$ cd test
$ vagrant init debian/jessie64
$ vagrant up

Last working box version is 8.5.2.

I've tested other boxes: centos/7 and ubuntu/trusty64 and they are 
working properly.


It is possible to workaround this issue by modifying Vagrantfile (2):

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|

  config.vm.box = "debian/jessie64"

  # Bugfix for "Cable connected: off"
  config.vm.provider :virtualbox do |vm|
vm.customize [
  "modifyvm", :id,
  "--cableconnected1", "on",
]
  end

end

and now VM boots properly.

I'm using Vagrant 1.8.5, VirtualBox 5.0.26 r108824 and OS X El Capitan 
10.11.3.


I should mention that I'm finding it hard to reproduce this problem 
reliably on different computers (it either works in 100% out of the box 
and every time or the opposite - depending on the computer used).


I've tested it on 4 computers and only on 2 of them problem is occurring.


(1) Big thanks to Stuart Spencer for finding the reason of this issue 
and Emmanuel Kasper for providing the help.


(2) Source: http://stackoverflow.com/questions/20910716/#answer-20911136

Bug#838934: Pending fixes for bugs in the libperl-apireference-perl package

[pkg-perl-maintainers]

tag 838934 + pending
thanks

Some bugs in the libperl-apireference-perl package are closed in
revision ed3a81d93b51be2a150ea6c4015d690ae16f5f1d in branch 'master'
by gregor herrmann

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

Commit message:

Add support for 5.24.1.

Closes: #838934

Bug#838919: debian-installer: please calculate swap parition according to max RAM supported by the motherboard

[Hakan Bayındır]

On Monday, September 26, 2016 10:23:02 AM EEST Lennart Sorensen wrote:
> On Mon, Sep 26, 2016 at 05:06:18PM +0300, Martin-Éric Racine wrote:
> > Package: debian-installer
> > Severity: wishlist
> > 
> > As far as I can tell, d-i calculates the size of the swap partition
> > according to the curently installed amount of RAM.
> > 
> > Whenever the RAM is upgraded later on, the swap parition no longer
> > fulfills its intended purpose, in cases when it would be needed to store
> > hibernate images, since the parition was calculated to store a much
> > smaller RAM image.
> > 
> > A more desirable method would be for d-i to use 'dmidecode' to probe the
> > system's memory controller for the maximum amount of RAM that is
> > supported and to calculate the swap partition size according to that.
> Of course many people never upgrade their ram, and often going beyond 50%
> of maximum gets very expensive.
> 
> Also many people never suspend.
> 
> Also dmidecode is x86 only and some older systems didn't have it, so it
> wouldn't help the majority of architectures.
> 
> So while it is an idea, I am not convinced it doesn't actually create
> problems.
> 
> Besides I could move the disk to a new system later which could have
> even more ram, so even making it as large as dmidecode says won't solve
> all cases.  I would think that case is at least as likely as maxing out
> the ram in a machine is.

Besides, some servers (and similarly workstations) have exorbitant memory 
capacities. I've managed some servers with 256GB RAM capacity, and since these 
servers were designed for processing roles, they had ~300GB disks. In that 
case, most of the disk will be wasted as swap which may never be used in its 
lifetime.

So in either desktop or server case, dmidecode way looks more problematic. It 
potentially wastes space, and addresses a rare problem.

Bug#838714: dch: avoid adding section in snapshot mode if distribution is UNRELEASED

[Linn Crosetto]

On Mon, Sep 26, 2016 at 08:19:27AM +0200, Guido Günther wrote:
[...]
> This makes sense. Can you add a test to 11_test_dch_main.py to make sure
> we don't break this again in the future?
> Cheers,

I added a test, and have attached the v2 patch. The following are the test
results with and without the patch applied:

$ git checkout master
$ git checkout snapshot-fix -- tests/11_test_dch_main.py
$ dpkg-buildpackage -us -uc
[...]
python setup.py nosetests --with-xcoverage
running nosetests
running egg_info
writing gbp.egg-info/PKG-INFO
writing top-level names to gbp.egg-info/top_level.txt
writing dependency_links to gbp.egg-info/dependency_links.txt
writing entry points to gbp.egg-info/entry_points.txt
reading manifest file 'gbp.egg-info/SOURCES.txt'
writing manifest file 'gbp.egg-info/SOURCES.txt'
.SS.FSwitched
 to a new branch 'bar'
.Switched to a new branch 'bar'
...
==
FAIL: Test dch.py like gbp dch script does: snapshot mode with unreleased 
debian version
--
Traceback (most recent call last):
  File "/home/crosetto/dev/git-buildpackage/tests/11_test_dch_main.py", line 
353, in test_dch_main_unreleased_debian_version_with_snapshot
self.assertIsNotNone(header)
AssertionError: unexpectedly None
 >> begin captured logging << 
gbp: info: Changelog last touched at 'f6cf282ecee80f64016056ede581ecf4eb38df65'
gbp: info: Continuing from commit 'f6cf282ecee80f64016056ede581ecf4eb38df65'
gbp: info: Changelog 1.0-2~1.gbp3a1060 (snapshot #1) prepared up to 3a10607
- >> end captured logging << -
[...]
$ git reset HEAD --hard
$ git am v2-0001-dch-avoid-adding-section-in-snapshot-mode-if-dist.patch
Applying: dch: avoid adding section in snapshot mode if distribution is 
UNRELEASED
.git/rebase-apply/patch:18: indent with spaces.
add_section = False
.git/rebase-apply/patch:34: indent with spaces.
elif cp['Distribution'] != "UNRELEASED" and not found_snapshot_banner:
.git/rebase-apply/patch:35: indent with spaces.
if commits:
.git/rebase-apply/patch:36: indent with spaces.
# the last version was a release and we have pending commits
.git/rebase-apply/patch:37: indent with spaces.
add_section = True
warning: squelched 17 whitespace errors
warning: 22 lines add whitespace errors.
$ dpkg-buildpackage -us -uc
[...]
python setup.py nosetests --with-xcoverage
running nosetests
running egg_info
writing gbp.egg-info/PKG-INFO
writing top-level names to gbp.egg-info/top_level.txt 
writing dependency_links to gbp.egg-info/dependency_links.txt
writing entry points to gbp.egg-info/entry_points.txt 
reading manifest file 'gbp.egg-info/SOURCES.txt'
writing manifest file 'gbp.egg-info/SOURCES.txt'
.SS..Switched
 to a new branch 'bar'
.Switched to a new branch 'bar'
...
[...]

-- Linn
From d5870bc950fc88cd120f832c93477ed560577be6 Mon Sep 17 00:00:00 2001
From: Linn Crosetto 
Date: Wed, 21 Sep 2016 15:59:00 -0600
Subject: [PATCH v2] dch: avoid adding section in snapshot mode if distribution
 is UNRELEASED

When using git-dch in snapshot mode, a section is added without checking
whether the distribution is set to UNRELEASED. If the distribution is
UNRELEASED, the version will be incremented but a new section will not be
added, resulting in a skipped version in the changelog.

Change this behavior to add a new section in snapshot mode only if the
distribution is not set to UNRELEASED.

Signed-off-by: Linn Crosetto 
---
v2
 - dhc.py: set default value for add_section
 - add test_dch_main_unreleased_debian_version_with_snapshot (Guido Günther)

 gbp/scripts/dch.py| 16 
 tests/11_test_dch_main.py | 16 
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/gbp/scripts/dch.py b/gbp/scripts/dch.py
index 2ccbacb..d716fba 100644
--- a/gbp/scripts/dch.py
+++ b/gbp/scripts/dch.py
@@ -466,6 +466,7 @@ def main(argv):
options=options.git_log.split(" "))
 commits.reverse()
 
+add_section = False
 # add a new changelog section if:
 if (options.new_version or options.bpo or options.nmu or options.qa or
 

Bug#838933: Pending fixes for bugs in the libio-compress-lzma-perl package

[pkg-perl-maintainers]

tag 838933 + pending
thanks

Some bugs in the libio-compress-lzma-perl package are closed in
revision 6466be0a3b8b43fbe8a4a01819cad1bcb277ec7b in branch 'master'
by gregor herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libio-compress-lzma-perl.git/commit/?id=6466be0

Commit message:

Fix (build) dependencies on IO::{Compress,Uncompress}::Base.

Closes: #838933

Bug#647883: lists ${distro_codename}-updates but needs stable-updates

[anarcat]

Control: fixed 647883 0.83.3.1

On Tue, Nov 08, 2011 at 12:00:26PM +0100, Michael Vogt wrote:
> On Mon, Nov 07, 2011 at 10:53:12AM +0100, Philipp Kern wrote:
> > The commented-out example for squeeze-updates (${distro_codename}-updates)
> > provided by unattended-upgrades does not work.  You actually need to specify
> > stable-updates to get automatic upgrades.
>  
> Thanks for your bugreport.
> 
> I pushed this fix to
> http://anonscm.debian.org/bzr/apt/unattended-upgrades/debian-squeeze/  
> and it will need a proposed-updates upload.

It looks like you forgot to close this bug report. I believe this was
actually fixed in 0.83.3.1:

https://github.com/mvo5/unattended-upgrades/commit/9a2afa59502b34a5941ee6d1f72294f4494d129a
 
On Tue, Dec 20, 2011 at 11:47:52AM +0200, Teodor MICU wrote:
> This bug look very much like #618336.

... which has been marked as resolved.

> If it doesn't worth the trouble for a backport to 'stable' maybe close it?

We are now 5 years later. I would assume it is too late for a backport
and we can just close this bug report.

Sorry for the delays everyone, it looks like the BTS needs a lot of
triage for unattended-upgrades... volunteers? :)

A.

-- 
Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
- Aristote


signature.asc
Description: Digital signature

Bug#838934: libperl-apireference-perl: FTBFS with Perl 5.24.1

[Niko Tyni]

Package: libperl-apireference-perl
Version: 0.22-3
Severity: serious
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition
Control: block 830200 with -1

This package fails to build with Perl 5.24.1, including
the release candidate currently in sid.

  Processing: 5.22.2
  Processing: 5.24.0
  echo Current Perl is `perl -MConfig -we'printf("%d_%03d_%03d.pm", 
$Config{PERL_REVISION}, $Config{PERL_VERSION}, $Config{PERL_SUBVERSION})'`
  Current Perl is 5_024_001.pm
  test -f lib/Perl/APIReference/V`perl -MConfig -we'printf("%d_%03d_%03d.pm", 
$Config{PERL_REVISION}, $Config{PERL_VERSION}, $Config{PERL_SUBVERSION})'`
  debian/rules:8: recipe for target 'regenerated-stamp' failed
  make[1]: *** [regenerated-stamp] Error 1
 
It looks like we only tested rebuilds with 5.24.0 and therefore missed this.
Similar to #825613, the fix is hopefully trivial.
-- 
Niko Tyni   nt...@debian.org

Bug#787945: unattended-upgrades: Does not upgrade packages in jessie, only jessie-security

[Antoine Beaupré]

Control: found 787945 0.83.3.2
Control: forwarded 787945 https://github.com/mvo5/unattended-upgrades/issues/33

On Mon, Sep 26, 2016 at 03:15:05PM -0400, Antoine Beaupré wrote:
> It looks like this is fixed in the 0.83.3.2 upload, which ships the
> proper .Debian file.

Sorry, I got confused here: shipping a proper .Debian file is not all,
it must also enable stable updates!

This is still not the case, even upstream:

https://github.com/mvo5/unattended-upgrades/blob/master/data/50unattended-upgrades.Debian

In the above config, the regular updates are not allowed.

I believe this is a mistake - point releases should be followed, by
default.

I have reported this upstream as well.

A.

-- 
Some believe it is only great power that can hold evil in check, but
that is not what I have found. It is the small everyday deeds of
ordinary folk that keep the darkness at bay. Small acts of kindness and
love.   - J.R.R. Tolkien


signature.asc
Description: Digital signature

Bug#838935: apt-transport-https should be mandatory dependency for apt

[Senthil Kumaran S]

Package: apt
Version: 1.3
Severity: normal

Dear Maintainer,

When a package repository URL is added with 'https://' an 'apt update'
or 'apt-get update' fails with the following error:


$ sudo apt-get update
Hit:1 http://ftp.us.debian.org/debian testing InRelease
Hit:2 http://security.debian.org testing/updates InRelease
Hit:3 http://ftp.us.debian.org/debian testing-updates InRelease
Reading package lists... Done
E: The method driver /usr/lib/apt/methods/https could not be found.
N: Is the package apt-transport-https installed?
E: Failed to fetch
https://images.validation.linaro.org/staging-repo/dists/sid/InRelease
E: Some index files failed to download. They have been ignored, or old
ones used instead.


https:// is very common, hence apt should, by default have a mandatory
dependency on 'apt-transport-https' and should be installed when apt
or apt-get is installed.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.6\.0-1-amd64$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";

Bug#806068: linaro-image-tools: diff for NMU version 2014.11-1.1

[Steve McIntyre]

Control: tags 806068 + pending

Dear maintainer,

I've prepared an NMU for linaro-image-tools (versioned as 2014.11-1.1) and
uploaded it. It's a trivial change, just using the patch from
Santiago. Here's the NMU diff for completeness.

Cheers,

Steve



diff -Nru linaro-image-tools-2014.11/debian/changelog linaro-image-tools-2014.11/debian/changelog
--- linaro-image-tools-2014.11/debian/changelog	2014-11-25 13:56:57.0 +
+++ linaro-image-tools-2014.11/debian/changelog	2016-09-26 20:08:37.0 +0100
@@ -1,3 +1,11 @@
+linaro-image-tools (2014.11-1.1) unstable; urgency=medium
+
+  * NMU
+  * Fix build for dpkg-buildpackage -A. Thanks to Santiago Vila for the
+patch. Closes: #806068
+
+ -- Steve McIntyre <93...@debian.org>  Mon, 26 Sep 2016 12:08:40 -0700
+
 linaro-image-tools (2014.11-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru linaro-image-tools-2014.11/debian/rules linaro-image-tools-2014.11/debian/rules
--- linaro-image-tools-2014.11/debian/rules	2012-04-21 17:19:50.0 +0100
+++ linaro-image-tools-2014.11/debian/rules	2016-09-26 20:06:55.0 +0100
@@ -7,7 +7,8 @@
 
 %:
 	dh $@ --with python2
-override_dh_install:
+
+override_dh_install-arch:
 	dh_install
 	find debian/linaro-image-tools -type f |xargs sed -i 's|#!/usr/bin/env python|#!/usr/bin/python|'
 


signature.asc
Description: Digital signature

Bug#787945: unattended-upgrades: Does not upgrade packages in jessie, only jessie-security

[Antoine Beaupré]

Package: unattended-upgrades
Followup-For: Bug #787945

Control: fixed 787945 0.83.3.2

It looks like this is fixed in the 0.83.3.2 upload, which ships the
proper .Debian file.

A.

-- System Information:
Debian Release: 8.6
  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)

Versions of packages unattended-upgrades depends on:
ii  apt1.0.9.8.3
ii  apt-utils  1.0.9.8.3
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.22
ii  lsb-base   4.1+Debian13+nmu1
ii  lsb-release4.1+Debian13+nmu1
ii  python33.4.2-2
ii  python3-apt0.9.3.12
ii  ucf3.0030
ii  xz-utils   5.1.1alpha+20120614-2+b3

unattended-upgrades recommends no packages.

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx 8.1.2-0.20141216cvs-2
ii  msmtp-mta [mail-transport-agent]  1.4.32-2

-- debconf information excluded

Bug#836362: closed by Michael Biebl <bi...@debian.org> (Re: Breakes at least virt-viewer competly)

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

Am Do den 22. Sep 2016 um 18:09 schrieb Debian Bug Tracking System:
> From: Michael Biebl 
> > I am even not fully sure which library it is exactly. It was not
> > possible to downgrade one package after another. So possible candidates
> > are:
> > - gir1.2-freedesktop
> > - gir1.2-glib-2.0
> > - gir1.2-gtk-3.0
> > - gir1.2-pango-1.0
> > - libglib2.0-0
> > - libgtk-3-0
> > - libgtk-3-common
> > - libpango-1.0-0
> > - libpango1.0-0
> > - libpangocairo-1.0-0
> > - libpangoft2-1.0-0
> > - libpangoxft-1.0-0
> > 
> 
> I'm pretty sure gir1.2-pango-1.0 is not to blame here.
> You might try downgrading libgtk-3-0 and check if that makes a difference.

It is pretty hard to debug this as they all depends on each other so it
is not possible to downgrade them individually.

I tried out the smallest amount of packages to downgrade to not see the
bug anymore.

I also wrote that it is fine to reassign the bug to another package.
Please don't ask me how I find the way to close it just to get open
identically to another package. That is not helpful to bring back
working packages.

If you find it is gtk, fine for me, if you find it is something else,
also fine for me. Just to close it cause you don't like this bug is not
fine.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGcBAEBCgAGBQJX6XN5AAoJEKZ8CrGAGfasmEIL/2sx5tL1YhP1EGuKkorzpj0L
amZHqEQp2QCNuMr4g9f87UtOkgmLVzYXCKbSG9VWOmXCidmfOH2EDrVe/6ogPi6V
WsTLhzwEN6GfuMTfGLxwliYo6DnOKy2farEl8QN5zP75xveTN5LKlmXLf0taSHsu
AhKg8uJVpT30+yo2nnGFKjrGVMYGuw4kzUa2WY0LH9Aixs/KW9pd8jND1FUjPeLW
plVz1LhRD48nTbpqaBZtxCPwuEemSUQAwRNDvAoia8LbUPPAvfutoDY90qkGmAKM
AKHtKVfjFifG39vE9qKBBAOUS5xEPu1g3uuLdz8gTwy/MonRMdb99JRFJELIC4F7
D5V0WbDmYb0FSdz/LBdrTYTj0Ji7RePXojt4LL6OM859wU5U6RRAVVnUktG72JQH
N1VejGC/+R3pXnbzur4X9gZhzxXCWyI4FbsgfYgJq0he6s+4l1e5jJwjNoLuuSxD
AI1oqqDzSsnAEqi0IcxkXi7wb8iIRjS7wtdeEgx4UQ==
=stXh
-END PGP SIGNATURE-

Bug#837778: Couldn't reproduce with 8:6.8.9.9-5+deb8u5

[Ivan Krylov]

The new 8:6.8.9.9-5+deb8u5 version converts the file from my first
message properly; my other scans are also handled correctly.

Thanks!

-- 
Best regards,
Ivan

Bug#838933: libio-compress-lzma-perl: uninstallable and unbuildable with Perl 5.24

[Niko Tyni]

Package: libio-compress-lzma-perl
Version: 2.069-1
Severity: grave
User: debian-p...@lists.debian.org
Usertags: perl-5.24-transition
Control: block 830200 with -1

This package has versioned build and runtime dependencies on
libio-compress-perl (>= 2.069), but Perl 5.24 bundles version 2.069_001.
It therefore declares a Breaks on libio-compress-perl (<< 2.069.001)
to make sure older separate packages can't override the newer core one.

This has the effect of making the current separate libio-compress-perl
package in sid uninstallable because it's "only" at 2.069.

Although perl Provides a libio-compress-perl virtual package, we haven't
adopted versioned provides yet (see #758100) so versioned dependencies are
not satisfied. This in turn renders libio-compress-lzma-perl uninstallable
and unbuildable.

The fix is to declare build and runtime dependencies on
  perl (>= 5.23.4) | libio-compress-perl (>= 2.069)

-- 
Niko Tyni   nt...@debian.org

Bug#835253: RFS: steghide/0.5.1-11 [QA]

[Fernando Seiti Furusato]

Hello, Gianfranco.

Thanks a lot for taking some time to verify this.

I tried to follow your recommendations:


On 09/12/2016 05:05 PM, Gianfranco Costamagna wrote:
> BTW, what about having the documentation in a separate -doc package?
> (and in the doc standard location)

I tried to to that. But then I had to add doxygen as a build-dep.

> 1) std-version is now 3.9.8

Corrected that.

>
> 2) 
> -rw-r--r-- root/root  6816 2016-08-22 23:03 
> ./usr/share/doc/steghide/COPYING.gz
>
>
> now this file is installed (and probably useless)
> quoting changelog:
>
> +  * Refixed so that INSTALL and COPYING information is not in the
> +deb archive.
>
>
>
> quoting old rules:
>
> +   $(MAKE) install prefix=`pwd`/debian/steghide/usr
> +   rm -rf `pwd`/debian/steghide/usr/doc
> +   rm -f `pwd`/debian/steghide/usr/share/doc/steghide/INSTALL
> +   rm -f `pwd`/debian/steghide/usr/share/doc/steghide/INSTALL.gz
> +   rm -f `pwd`/debian/steghide/usr/share/doc/steghide/COPYING
>
>
> so, I would try to remove it again

Well, I just used the same commands, just not the make install part.

>
> 3) this RFS has been picked up by Breno, so he should have the final words 
> about the
> package :)
> (I hope he don't mind my review, and hope he won't ask you to change 
> something back)

I talked to Breno last week, he said he might not have time to do this
and it would
be fine if you sponsored this one.

If you could take a look I would appreciate.

It can be found at the same place:

  dget -x
https://mentors.debian.net/debian/pool/main/s/steghide/steghide_0.5.1-11.dsc

Thanks!

-- 
Fernando Seiti Furusato
IBM Linux Technology Center




signature.asc
Description: OpenPGP digital signature

Bug#780155: ITP: baculum -- Baculum WebGUI tool for Bacula Community program

[Marcin Haba]

Hello Carsten,

Thanks for reminding me this ITP request.

Yes, I have succeeded to make some progress with Baculum deb packages.

To be honest, I didn't start unbundling PHP framework which Baculum uses
and in consequence I didn't report ITP about the PHP framework.

The progress is that I prepared official deb and rpm repositories to use
from bacula.org. Here is info in documentation about it:

http://www.bacula.org/7.4.x-manuals/en/console/Baculum_Web_GUI_Tool.html

For now I prefer to provide Baculum packages this way. When something
will change please be sure that I inform here about it.

I reported this ITP to add Baculum to Debian and to make it slightly
more popular. Now I think that in current Baculum state the repository
on bacula.org is sufficient for Baculum. It seems to me that good
application doesn't require too much advertisements and I think that
better when it comes natural and without forcing it.

Second reason is that to develop Baculum and to make Baculum better I
need to prepare some useful functionalities. When I focus on packaging
Baculum in Debian, I have less time for developing new features. I think
that Debian package maintainers will do it better than I.

You can close this ITP requires if you want. I am not sure what is the
procedure for this type of cases.

Best regards.
Marcin Haba

On 15.09.2016 16:34, Carsten Leonhardt wrote:
> Hi Marcin,
> 
> it's been a while since we last heard of each other, have you succeeded
> in making any progress here?
> 
>  - Carsten
> 

Bug#770436: libcryptui: patch - fix logic flaw in the prompt recipients dialog

[Vlad Orlov]

Sure, it should go into Unstable first. But since I've already provided
the patch, I didn't think that I should do some additional steps to make
it accepted. I've submitted debdiffs for some packages previously, and
the patches made their way into Unstable without requiring any more work
from me. :)

Bug#838420: gifsicle: incorrect escape for 8-bit characters on platforms with signed char

[Herbert Fortes]

forwarded 838420 https://github.com/kohler/gifsicle/issues/75
thanks


On 20-09-2016 21:40, Yuriy M. Kaminskiy wrote:
> Package: gifsicle
> Version: 1.86-1
> Severity: minor
> Tags: upstream patch
>
> Dear Maintainer,
>
> When showing comment containing non-ASCII characters, `gifsicle -I`
> shows incorrect escape code (\364 instead of \364) on
> platforms with signed char (e.g. x86{,_64}).
> Patches against 1.86 and 1.88 attached.
>
> -- System Information:
> Debian Release: 8.6
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable'), (100,
> 'proposed-updates')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
> Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages gifsicle depends on:
> ii  libc6 2.19-18+deb8u4
> ii  libice6   2:1.0.9-1+b1
> ii  libsm62:1.2.2-1+b1
> ii  libx11-6  2:1.6.2-3
>
> gifsicle recommends no packages.
>
> gifsicle suggests no packages.
>
> -- no debconf information
>

Bug#805579: nouveau: lockup with "[TTM] Buffer eviction failed"

[Eric Cooper]

Package: src:linux
Version: 4.6.4-1
Followup-For: Bug #805579

For a long time I didn't experience these lockups, but in the past
week or so they have started occurring again, about once a day:

[397467.956723] nouveau :01:00.0: fifo: read fault at 956000 engine 15 
[PCE0] client 01 [PCOPY0] reason 02 [PAGE_NOT_PRESENT] on channel 0 [001fe74000 
DRM]
[397467.956728] nouveau :01:00.0: fifo: ce0 engine fault on channel 0, 
recovering...
[397497.955174] [TTM] Buffer eviction failed
[397527.955845] [TTM] Buffer eviction failed
[397542.956067] [TTM] Buffer eviction failed

I haven't changed any of the hardware since my original report.
The bug seems to occur most often when I have lots of tabs open in
chromium.

-- Package-specific info:
** Version:
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.6.0-1-amd64 
root=UUID=1bd202e7-8d8c-4170-8388-abddc49cd075 ro quiet

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

** Kernel log:
[6.167715] systemd[1]: Started Remount Root and Kernel File Systems.
[6.183580] systemd[1]: Starting Load/Save Random Seed...
[6.192558] systemd[1]: Starting udev Coldplug all Devices...
[6.193067] systemd[1]: Activating swap /swap...
[6.242335] systemd[1]: Started udev Coldplug all Devices.
[6.360002] systemd[1]: Started Create list of required static device nodes 
for the current kernel.
[6.375615] systemd[1]: Starting Create Static Device Nodes in /dev...
[6.424481] systemd[1]: Started Set the console keyboard layout.
[6.433829] systemd[1]: Started Journal Service.
[6.725839] systemd-journald[1008]: Received request to flush runtime 
journal from PID 1
[6.781160] lp: driver loaded but no devices found
[6.812496] ppdev: user-space parallel port driver
[6.846108] parport_pc 00:07: reported by Plug and Play ACPI
[6.846173] parport0: PC-style at 0x378, irq 7 [PCSPP]
[6.850215] RPC: Registered named UNIX socket transport module.
[6.850217] RPC: Registered udp transport module.
[6.850218] RPC: Registered tcp transport module.
[6.850219] RPC: Registered tcp NFSv4.1 backchannel transport module.
[6.935616] lp0: using parport0 (interrupt-driven).
[6.994592] Installing knfsd (copyright (C) 1996 o...@monad.swb.de).
[7.442457] Adding 34179680k swap on /swap.  Priority:-1 extents:30 
across:38783584k FS
[8.463735] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[8.467167] ACPI Warning: SystemIO range 
0x0400-0x041F conflicts with OpRegion 
0x0400-0x040F (\SMRG) (20160108/utaddress-255)
[8.467172] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.475249] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input7
[8.475253] ACPI: Power Button [PWRB]
[8.475290] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input8
[8.475292] ACPI: Power Button [PWRF]
[8.540063] ACPI Warning: SystemIO range 
0x0828-0x082F conflicts with OpRegion 
0x0800-0x084F (\PMRG) (20160108/utaddress-255)
[8.540070] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.540074] ACPI Warning: SystemIO range 
0x0530-0x053F conflicts with OpRegion 
0x0500-0x053F (\GPS0) (20160108/utaddress-255)
[8.540077] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.540079] ACPI Warning: SystemIO range 
0x0500-0x052F conflicts with OpRegion 
0x0500-0x053F (\GPS0) (20160108/utaddress-255)
[8.540082] ACPI: If an ACPI driver is available for this device, you should 
use it instead of the native driver
[8.540117] lpc_ich: Resource conflict(s) found affecting gpio_ich
[8.634159] [drm] Initialized drm 1.1.0 20060810
[8.653154] wmi: Mapper loaded
[9.533626] EDAC MC: Ver: 3.0.0
[9.607130] EDAC MC0: Giving out device to module i7core_edac.c controller 
i7 core #0: DEV :3f:03.0 (POLLED)
[9.607166] EDAC PCI0: Giving out device to module i7core_edac controller 
EDAC PCI controller: DEV :3f:03.0 (POLLED)
[9.607172] EDAC i7core: Driver loaded, 1 memory controller(s) found.
[9.624166] sd 2:0:0:0: Attached scsi generic sg0 type 0
[9.624197] sr 3:0:0:0: Attached scsi generic sg1 type 5
[9.697431] nouveau :01:00.0: NVIDIA GF108 (0c1000a1)
[9.706592] input: Griffin PowerMate as 
/devices/pci:00/:00:1d.0/usb2/2-1/2-1.8/2-1.8.3/2-1.8.3:1.0/input/input9
[9.706643] usbcore: registered new interface driver powermate
[9.789145] iTCO_vendor_support: vendor-support=0
[9.790831] iTCO_wdt: 

Bug#838932: apache2: multiple apache instances don't start after reboot without the default apache enabled

[Horst Platz]

Package: apache2
Version: 2.4.10-10+deb8u7
Severity: minor
Tags: patch

Dear Maintainer,

multiple apache instances don't start after reboot without the default
apache enabled.

:~# sh /usr/share/doc/apache2/examples/setup-instance xxx
:~# sh /usr/share/doc/apache2/examples/setup-instance yyy

:~# systemctl enable apache2-xxx
:~# systemctl enable apache2-yyy

disable default installed apache because ist should only the template
for the suffix apaches

:~# systemctl disable apache2

:~# shutdown -r now

/var/run/apache2 ist now no longer available because tmpfs

:~# cat /var/log/apache2-zzz/error.log
[...]
[Sat Sep 24 11:10:00.566132 2016] [core:error] [pid 2229] AH00100:
apache2: could not log pid to file /var/run/apache2/apache2-xxx.pid
[...]

solution

:~# vim /etc/apache2-xxx/envvars
:~# vim /etc/apache2-yyy/envvars
[...]
#export APACHE_PID_FILE=/var/run/apache2/apache2$SUFFIX.pid
export APACHE_PID_FILE=/var/run/apache2$SUFFIX/apache2$SUFFIX.pid

or rather in /etc/apache2/envvars

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

patch for /etc/apache2/envvars

--- envvars 2016-09-25 10:54:40.901929219 +0200
+++ envvars.new 2016-09-25 10:54:08.113544407 +0200
@@ -16,7 +16,7 @@ fi
 export APACHE_RUN_USER=www-data
 export APACHE_RUN_GROUP=www-data
 # temporary state file location. This might be changed to /run in Wheezy+1
-export APACHE_PID_FILE=/var/run/apache2/apache2$SUFFIX.pid
+export APACHE_PID_FILE=/var/run/apache2$SUFFIX/apache2$SUFFIX.pid
 export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
 export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
 # Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.


it is also attached

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

Versions of packages apache2 is related to:
ii  apache2  2.4.10-10+deb8u7
ii  apache2-bin  2.4.10-10+deb8u7

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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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)

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

you can look also to ubuntu launchpad where i have the bug reported first

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1627339

https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1627339/comments/5

File to fix is part of packaging debian/config-dir/envvars

-  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -

kind regards horst
--- envvars 2016-09-25 10:54:40.901929219 +0200
+++ envvars.new 2016-09-25 10:54:08.113544407 +0200
@@ -16,7 +16,7 @@ fi
 export APACHE_RUN_USER=www-data
 export APACHE_RUN_GROUP=www-data
 # temporary state file location. This might be changed to /run in Wheezy+1
-export APACHE_PID_FILE=/var/run/apache2/apache2$SUFFIX.pid
+export APACHE_PID_FILE=/var/run/apache2$SUFFIX/apache2$SUFFIX.pid
 export APACHE_RUN_DIR=/var/run/apache2$SUFFIX
 export APACHE_LOCK_DIR=/var/lock/apache2$SUFFIX
 # Only /var/log/apache2 is handled by /etc/logrotate.d/apache2.

Bug#838854: cups-bsd: Typos in man pages

[Helge Kreutzmann]

Hello Didier,
On Mon, Sep 26, 2016 at 10:41:39AM +0200, Didier 'OdyX' Raboud wrote:
> Le dimanche, 25 septembre 2016, 21.05:13 h CEST Helge Kreutzmann a écrit :
> > While updating the German man page translation I finally moved myself
> > to report the numerous typos/inconsistencies noted during the German
> > translation. (Thus I marked them from the po file, but this is easily
> > translatable into the source files):
> 
> Thanks for this report; I've translated this into patches against the groff 
> source files and filed a pull request (see above URL)

Thanks.

> > *
> > 
> > Isn't the proper mark up "B"?
> > 
> > #. type: Plain text
> > #: ippfind.man:83
> > msgid ""
> > "Lists attributes returned by Get-Printer-Attributes for IPP printers and "
> > "traditional I \"-ls\" output for HTTP URLs.  The result is true if
> > the " "URI is accessible, false otherwise."
> 
> No, because `find -ls` isn't runnable as-is. You need `find  -ls` etc, 
> so referring to `find` 's "-ls" output makes sense.

Ah, but then the »'s« is missing, isn't it?

> > *
> > 
> > # FIXME: String broken??
> > #.  character. Common attributes and values are listed in the IANA IPP
> > registry \- see references below. #. type: Plain text
> > #: ipptoolfile.man:144
> > #, fuzzy
> > #| msgid ""
> > #| "Adds an attribute to the test request. Values are separated by the comma
> > " #| "(\",\")  character - escape commas using the \"\\e\" character.
> > Common " #| "attributes and values are listed in the IANA IPP registry -
> > see " #| "references below."
> > msgid ""
> > "Adds an attribute to the test request. Values are separated by the comma
> > (\"," "\") character - escape commas using the \""
> 
> I can't really see what's wrong here. How is it broken? In the original/final 
> manpages?

This might actually be a po4a bug. The part after »\"« is missing in the
pot file, i.e. the remaining part:
character. Common attributes and values are listed in the IANA IPP
registry \- see references below.

Greetings

  Helge
-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#827579: related to 94990

[Ilya Guterman]

Hi,


I see in the log "firmware: failed to load nvidia/gm204/gr/sw_nonctx.bin"

which means there is no such file in /lib/firmware/nvidia/
you can add it by installing 'apt-get install firmware-linux-nonfree'
(if package not found add, 'non-free' to /etc/apt/sources.list)

intrigeri:
it seems the firmwares are in debian, just not in fresh installation which
is uncomfortable.

I am not sure what to do in such situation, i guess the driver had to
fallback
to work without firmwares and just give a warning.

On Sun, Sep 25, 2016 at 8:54 PM intrigeri  wrote:

> Hi,
>
> Ilya Guterman:
> > This bug is started from nouveau after adding the secure boot firmwares,
> > https://bugs.freedesktop.org/show_bug.cgi?id=94990
>
> We have a bug report about including these firmware in Debian:
>
>   https://bugs.debian.org/823637
>
> So I'm not 100% sure if it makes sense to keep #827579 open.
>
> Cheers,
> --
> intrigeri
>

Bug#838420: gifsicle: incorrect escape for 8-bit characters on platforms with signed char

[Herbert Fortes]

Hi Yuriy M. Kaminskiy,

> Package: gifsicle
> Version: 1.86-1
> Severity: minor
> Tags: upstream patch
>
> Dear Maintainer,
>
> When showing comment containing non-ASCII characters, `gifsicle -I`
> shows incorrect escape code (\364 instead of \364) on
> platforms with signed char (e.g. x86{,_64}).
> Patches against 1.86 and 1.88 attached.
>

I checking the package now.

Thanks for your help!



Regards,
Herbert

Bug#838913: libc6: There's probably a bug in libpthread, affecting several user programs.

[Florian Weimer]

* Fernando Santagata:

> One month ago everything worked fine on my Debian sid computer.
> After an update/dist-upgrade cycle in which libc6 was updated I
> started noticing some malfunctions.

Did you upgrade the kernel at the same time?

Bug#838928: [Pkg-openssl-devel] Bug#838928: libssl1.0.0: Some E-mail clients stopped working with dropped connections with deb8u5. deb8u3 works ok.

[Kurt Roeckx]

On Mon, Sep 26, 2016 at 04:38:13PM +0200, Hrvoje Dagelic wrote:
> Package: libssl1.0.0
> Version: 1.0.1t-1+deb8u5
> Severity: important

This is probably a result of moving 3DES from the HIGH level to
the MEDIUM level because of the sweet32 attack.

My guess is that those systems that have a problem are still
running windows XP.

I suggest you alter the settings of your server to allow the
MEDIUM ciphers.


Kurt

Bug#828446: Fwd: Re: OpenSSL 1.1.0 support

[Kurt Roeckx]

--- Begin Message ---
On Sun, Sep 25, 2016 at 09:32:41PM +0200, Kurt Roeckx wrote:
> Hi,
> 
> The attached makes the current trunk build with OpenSSL 1.1.0.
> 
> There are various tests that fail both before and after the patch.
> They're all fixed by this patch:

I left some debugging in there, whoops!  I removed that, and committed 
your patch.  I adjusted SSL_SESSION_cmp slightly to use an unsigned 
char buffer, else I got a warning with OpenSSL 1.0.2h; I presume that's 
fine for OpenSSL 1.1 too.

Thanks a lot for the patch!  I'll try to spin a new release this week 
with these fixes.

Regards, Joe

--- End Message ---

Bug#838931: repro: logrotate script fails if repro is not running

[Gard Spreemann]

Package: repro
Version: 1:1.9.7-5
Severity: normal

Dear Maintainer,

The logrotate script for repro uses start-stop-daemon in its
postrotate in a way that makes it exit with status 1 if repro is not
running. This can cause needless e-mails to be sent to the
administrator of the system if repro is installed but deliberately not
running, or if the package has been removed with configuration files
kept in place.

I do not know what the most appropriate way to fix this is, but it
seems that adding --oknodo to start-stop-daemon in repro's logrotate
script will work.

Best,
Gard Spreemann

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

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

Bug#836664: wsjtx: diff for NMU version 1.1.r3496-3.1

[Mattia Rizzolo]

Control: tags 836664 + pending

Dear maintainer,

I've prepared an NMU for wsjtx (versioned as 1.1.r3496-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
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  `-
diff -Nru wsjtx-1.1.r3496/debian/changelog wsjtx-1.1.r3496/debian/changelog
--- wsjtx-1.1.r3496/debian/changelog	2013-09-09 18:19:22.0 +
+++ wsjtx-1.1.r3496/debian/changelog	2016-09-26 15:33:49.0 +
@@ -1,3 +1,15 @@
+wsjtx (1.1.r3496-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch so that the build system can make use of exported buildflags
+  * Bump compat level to 9, so that dh exports dpkg-buildflags in the env by
+itself.
+  * Use DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie instead of using
+hardening-wrapper.  Closes: #836664
+  * Remove a bunch of useless comments from d/rules.
+
+ -- Mattia Rizzolo   Mon, 26 Sep 2016 15:33:49 +
+
 wsjtx (1.1.r3496-3) unstable; urgency=low
 
   * remove -mno-stack-arg-probe from lib/Makefile.linux CFLAGS
diff -Nru wsjtx-1.1.r3496/debian/compat wsjtx-1.1.r3496/debian/compat
--- wsjtx-1.1.r3496/debian/compat	2013-05-29 01:16:36.0 +
+++ wsjtx-1.1.r3496/debian/compat	2016-09-26 15:22:49.0 +
@@ -1 +1 @@
-8
+9
diff -Nru wsjtx-1.1.r3496/debian/control wsjtx-1.1.r3496/debian/control
--- wsjtx-1.1.r3496/debian/control	2013-09-03 22:45:49.0 +
+++ wsjtx-1.1.r3496/debian/control	2016-09-26 15:22:57.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Hams group 
 Uploaders: John T. Nogatch , Kamal Mostafa 
-Build-Depends: debhelper (>= 8.0.0), qt4-dev-tools, qt4-qmake, libqt4-dev, gfortran, hardening-wrapper, libfftw3-dev, libhamlib-dev, libqwt5-qt4-dev, libsamplerate0-dev, portaudio19-dev (>= 19+svn2021-1~) 
+Build-Depends: debhelper (>= 9), qt4-dev-tools, qt4-qmake, libqt4-dev, gfortran, libfftw3-dev, libhamlib-dev, libqwt5-qt4-dev, libsamplerate0-dev, portaudio19-dev (>= 19+svn2021-1~)
 Standards-Version: 3.9.4
 Homepage: http://www.physics.princeton.edu/pulsar/K1JT/wsjtx.html
 #Vcs-Git: git://git.debian.org/collab-maint/wsjt.git
diff -Nru wsjtx-1.1.r3496/debian/patches/dpkg-buildflags.patch wsjtx-1.1.r3496/debian/patches/dpkg-buildflags.patch
--- wsjtx-1.1.r3496/debian/patches/dpkg-buildflags.patch	1970-01-01 00:00:00.0 +
+++ wsjtx-1.1.r3496/debian/patches/dpkg-buildflags.patch	2016-09-26 15:30:10.0 +
@@ -0,0 +1,29 @@
+Description: repspects CFLAGS, FFLAGS and LDFLAGS from the environment
+ This makes the build system to use the flags exported by dpkg-buildflags
+ including hardening ones.
+Author: Mattia Rizzolo 
+Last-Updated: 2016-09-26
+Forwarded: no
+
+--- a/lib/Makefile.linux
 b/lib/Makefile.linux
+@@ -1,8 +1,8 @@
+ CC = gcc
+ FC = gfortran
+ 
+-FFLAGS = -O2 -fbounds-check -Wall -Wno-conversion -fno-second-underscore
+-CFLAGS = -I. -fbounds-check
++FFLAGS := -O2 -fbounds-check -Wall -Wno-conversion -fno-second-underscore $(FFLAGS)
++CFLAGS := -I. -fbounds-check $(CFLAGS)
+ 
+ # Default rules
+ %.o: %.c
+@@ -44,7 +44,7 @@
+ OBJS2 = jt9.o jt9a.o jt9b.o jt9c.o
+ 
+ jt9: 	$(OBJS2) libjt9.a 
+-	g++ -o jt9 $(OBJS2) libjt9.a -lfftw3f -lgfortran -lQtCore
++	g++ -o jt9 $(OBJS2) libjt9.a $(LDFLAGS) -lfftw3f -lgfortran -lQtCore
+ 	cp jt9 ../wsjtx_install
+ 
+ OBJS3 = jt9sim.o 
diff -Nru wsjtx-1.1.r3496/debian/patches/series wsjtx-1.1.r3496/debian/patches/series
--- wsjtx-1.1.r3496/debian/patches/series	2013-09-09 18:13:38.0 +
+++ wsjtx-1.1.r3496/debian/patches/series	2016-09-26 15:14:37.0 +
@@ -3,3 +3,4 @@
 

Bug#838531: nose2: FTBFS in testing (failing tests)

[Barry Warsaw]

On Sep 24, 2016, at 03:47 PM, Chris Lamb wrote:

>> nose2: FTBFS in testing (failing tests)
>
>This is somewhat mind-bending to debug:
>
>   AssertionError: Regex didn't match:
>  'FAILED \\(failures=5, errors=1, skipped=1\\)' not found in
>  […] FAILED (failures=1, errors=1, skipped=1)\n'
>
>ie. the wrong tests in a set of tests for a testcase in a testing utility
>are passing when they should be failing, and it's not even clear which of
>them should be failing.

Hi, I can't seem to reproduce this on unstable.  Both dpkg-buildpackage -A and
sbuild work just fine, as does autopkgtest in an unstable chroot.

However, the reproducible build problem is a real issue; I'm about to upload
0.6.5-2 which will fix this.  Once that's pushed to git or uploaded, could you
please try again?

Bug#834572: ci.debian.net: Please run dkms tests automatically

[Antonio Terceiro]

On Wed, Sep 21, 2016 at 11:42:56PM +0200, Martin Pitt wrote:
> Hey Antonio,
> 
> Antonio Terceiro [2016-09-21 14:20 -0300]:
> > the fact that Ubuntu runs tests on KVM and we run on LXC makes all the
> > difference.
> >
> > however making the package have their tests executed is trivial; what's
> > not trivial will be moving to KVM so that their tests have any chance of
> > working.
> 
> Do you have enough EC2 quota to run tests in (ephemeral) nova
> instances? In Ubuntu we do that, i. e. I have a permanent "controller"
> instance that has the cloud credentials and an autopkgtest checkout,
> and worker instances [1] which take AMQP test requests and call autopkgtest 
> with
> the ssh runner and the "nova" setup script [2] -- i. e. the actual
> test is being run in an ephemeral instance, with full
> "isolation-machine"/KVM capabilities like mucking around with kernel
> stuff.

Sure that's doable, as is moving to a simple "KVM on localhost"; it is
just a matter of doing the work.


signature.asc
Description: PGP signature

Bug#741660: rtpproxy: diff for NMU version 1.2.1-2.2

[Mattia Rizzolo]

Control: tags 741660 + pending
Control: tags 765250 + patch
Control: tags 765250 + pending
Control: tags 836652 + pending

Dear maintainer,

I've prepared an NMU for rtpproxy (versioned as 1.2.1-2.2) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

-- 
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  `-
diff -Nru rtpproxy-1.2.1/debian/changelog rtpproxy-1.2.1/debian/changelog
--- rtpproxy-1.2.1/debian/changelog	2015-01-12 18:25:43.0 +
+++ rtpproxy-1.2.1/debian/changelog	2016-09-26 15:00:22.0 +
@@ -1,3 +1,18 @@
+rtpproxy (1.2.1-2.2) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debhelper compat level to 10:
++ This means automatic dh-autoreconf.  Closes: #765250
++ This also means automatic config.{sub,guess} update.  Closes: #741660
++ Also drop build-dependencies on dh-autoreconf and all autotools, they are
+  implied by debhelper >= 10
+  * Stop using hardening-wrapper and instead make use of dpkg-buildflags with
+DEB_BUILD_MAINT_OPTIONS = hardening=+all
+Closes: 836652
+  * Bump Standards-Version to 3.9.8, no changes needed.
+
+ -- Mattia Rizzolo   Mon, 26 Sep 2016 15:00:22 +
+
 rtpproxy (1.2.1-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru rtpproxy-1.2.1/debian/compat rtpproxy-1.2.1/debian/compat
--- rtpproxy-1.2.1/debian/compat	2014-02-16 03:57:22.0 +
+++ rtpproxy-1.2.1/debian/compat	2016-09-26 14:55:55.0 +
@@ -1 +1 @@
-9
+10
diff -Nru rtpproxy-1.2.1/debian/control rtpproxy-1.2.1/debian/control
--- rtpproxy-1.2.1/debian/control	2014-02-16 03:57:22.0 +
+++ rtpproxy-1.2.1/debian/control	2016-09-26 15:00:22.0 +
@@ -3,8 +3,8 @@
 Priority: optional
 Maintainer: Debian VoIP Team 
 Uploaders: Mark Purcell , Kilian Krause 
-Build-Depends: hardening-wrapper, debhelper (>= 9), autotools-dev, autoconf, automake, xsltproc, docbook-xsl, docbook-xml
-Standards-Version: 3.9.5
+Build-Depends: debhelper (>= 10), xsltproc, docbook-xsl, docbook-xml
+Standards-Version: 3.9.8
 Homepage: http://www.rtpproxy.org
 Vcs-Svn: svn://anonscm.debian.org/pkg-voip/rtpproxy/trunk/
 Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-voip/rtpproxy/
diff -Nru rtpproxy-1.2.1/debian/rules rtpproxy-1.2.1/debian/rules
--- rtpproxy-1.2.1/debian/rules	2014-02-16 03:57:22.0 +
+++ rtpproxy-1.2.1/debian/rules	2016-09-26 15:00:18.0 +
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-export DEB_BUILD_HARDENING=1
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
 	dh $@


signature.asc
Description: PGP signature

Bug#838064: Still happening with 1.7.0-6

[Edward Betts]

Hi Antonio,

I tried with 1.7.0-6, same thing, it is still happening.

Thanks,
-- 
Edward.

Bug#838929: virt-manager: Does not render remote display unless window is larger than needed

[Matthew Gabeler-Lee]

Package: virt-manager
Version: 1:1.4.0-3
Severity: normal

If the remote VM display window is exactly the size it needs to be, then the
remote display does not render for me.  If I resize the window to be just
one pixel bigger (in either or both dimensions), everything works fine.  Of
course, this totally breaks fullscreen mode if my screen and the remote
screen are the same resolution.

This is happening with both a Windows 10 guest, and a text-mode-only Linux
guest.  In both cases, remote qemu/kvm VMs.

The "doesn't render" extends to not even clearing the window background.  If
the viewer window was partly obscured by another window, and I switch focus
to the viewer and raise it, it leaves whatever pixels were on screen from
the occluding window still there until I resize the window.

Note: this also seems to affect virt-viewer 4.0, but details of that app's
behavior make it harder to see what's going on with this bug.

The requested run with --debug --no-fork doesn't produce any output when
resizing the windows either into or out of the problem state.  It prints
debug messages for connecting to the remote VM and connecting the spice
channels, but once connected, no output on any of the window resizes.

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

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

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gconf2   3.2.6-3
ii  gir1.2-gtk-3.0   3.21.5-3
ii  gir1.2-gtk-vnc-2.0   0.6.0-1
ii  gir1.2-libosinfo-1.0 0.3.1-5
ii  gir1.2-libvirt-glib-1.0  0.2.3-2
ii  gir1.2-vte-2.91  0.45.90-2
ii  librsvg2-common  2.40.16-1
ii  python-dbus  1.2.4-1
ii  python-gi3.22.0-1
ii  python-gi-cairo  3.22.0-1
ii  python-libvirt   2.2.0-1
ii  python-requests  2.11.1-1
pn  python2.7:any
pn  python:any   
ii  virtinst 1:1.4.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-spice-client-gtk-3.0  0.32-1
ii  gnome-icon-theme 3.12.0-2
ii  libvirt-daemon-system2.2.0-1

Versions of packages virt-manager suggests:
ii  gnome-keyring 3.20.0-3
ii  python-gnomekeyring   2.32.0+dfsg-3
pn  python-guestfs
ii  ssh-askpass-fullscreen [ssh-askpass]  0.3-3.1
ii  virt-viewer   4.0-1

-- no debconf information

Bug#838928: libssl1.0.0: Some E-mail clients stopped working with dropped connections with deb8u5. deb8u3 works ok.

[Hrvoje Dagelic]

Package: libssl1.0.0
Version: 1.0.1t-1+deb8u5
Severity: important

Dear Maintainer,

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

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

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


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

Kernel: Linux 2.6.32-openvz-042stab113.11-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages libssl1.0.0 depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  libc6  2.19-18+deb8u3
ii  multiarch-support  2.19-18+deb8u6

libssl1.0.0 recommends no packages.

libssl1.0.0 suggests no packages.

-- debconf information excluded

Bug#838921: apipkg: new upstream release

[Daniel Stender]

Source: apipkg
Version: 1.0-1.1
Severity: wishlist
Control: block 790677 by -1

A newer version of apipkg is available (1.4). It's needed for
updating execnet (1.3), and with that, pytest-xdist (1.15.0).

I'll take care of this.

DS

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

Kernel: Linux 4.5.0-2-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#838927: ITP: vagrant-azure -- Enable Vagrant to manage virtual machines in Microsoft Azure

[Iain R. Learmonth]

Package: wnpp
Severity: wishlist
Owner: "Iain R. Learmonth" 

* Package name: vagrant-azure
  Version : 2.0.0.pre1
  Upstream Author : Microsoft Corporation
* URL : https://github.com/Azure/vagrant-azure
* License : MIT
  Programming Lang: Ruby
  Description : Enable Vagrant to manage virtual machines in Microsoft Azure

This is a Vagrant 1.7.3+ plugin that adds Microsoft Azure provider to Vagrant,
allowing Vagrant to control and provision machines in Microsoft Azure.

--

To be packaged in the pkg-azure team.

Bug#838925: Updating the prelude-lml Uploaders list

[Mattia Rizzolo]

Source: prelude-lml
Version: 1.0.0-5.3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Mickael Profeta  has not been working on
the prelude-lml package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#838926: Updating the prelude-manager Uploaders list

[Mattia Rizzolo]

Source: prelude-manager
Version: 1.0.1-5.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Mickael Profeta  has not been working on
the prelude-manager package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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#838924: Updating the libprelude Uploaders list

[Mattia Rizzolo]

Source: libprelude
Version: 1.0.0-11.8
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Mickael Profeta  has not been working on
the libprelude package for quite some time.

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
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