Bug#863267: [Python-modules-team] Bug#863267: Associated removals

[Scott Kitterman]

On May 26, 2017 12:30:17 AM EDT, Neil Williams  wrote:
>On Fri, 26 May 2017 04:11:49 +
>Scott Kitterman  wrote:
>
>> I don't see any way to completely resolve this before stretch
>> releases other than removing lava-server.
>
>This is a *django* bug! There is no evidence that lava-server is
>responsible for this - it just has to use multiple django apps. Any
>other system outside Debian using multiple apps will suffer the same
>bug.
>
>Note: once this bug occurs, unless the user is *clearly* warned to look
>for and install 1.8, *data loss* will occur. We have already had one
>user lose data covering 6 months of tests due to this error. The
>process must halt when the exception is seen, the app will be down and
>unusable and users will get a 503.

Sounds like a great input for the release notes.  You should submit it.

If you'd filed this bug months ago, back when you found it, maybe something 
could have been done.  Given short time before release, there's not a lot of 
options.

It really doesn't matter whose fault the bug is.

Scott K

Bug#863389: Missing default Route

[Jason Wittlin-Cohen]

It appears that the "no route to host" issue was caused by a missing
default route. "route add default gw 192.168.1.1 dev bond0" fixed the
issue.  The question is why my routing table was missing such a default
route.  My /etc/network/interfaces file specifically references the
gateway, as indicated by
https://wiki.debian.org/NetworkConfiguration#Configuring_the_interface_manually.


While I know the issue, I'm not sure what is causing it.  My interfaces
setting should automatically add a default route.  I've added the above
command to /etc/rc.local for the time being.

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback
iface eth0 inet manual
iface eth1 inet manual

#This is my LACP Bond Interface with manual IPV4 and IPV6 addresses
auto bond0
iface bond0 inet static
address 192.168.1.200
netmask 255.255.255.0
network 192.168.1.0
gateway 192.168.1.1
iface bond0 inet6 static
address 2001:470:8:1141::2
netmask 64
gateway 2001:470:8:1141::1
slaves eth0 eth1
bond_mode 802.3ad
bond_miimon 100
bond_downdelay 200
bond_updelay 200
mtu 9000

#Point-to-Point 10Gbe Link for backups
auto eth2
iface eth2 inet static
address 10.0.0.1
netmask 255.255.255.0
mtu 9000

Bug#863390: qpdf: CVE-2017-9208 CVE-2017-9209 CVE-2017-9210

[Salvatore Bonaccorso]

Source: qpdf
Version: 5.1.2-2
Severity: important
Tags: security upstream

Hi,

the following vulnerabilities were published for qpdf.

CVE-2017-9208[0]:
| libqpdf.a in QPDF 6.0.0 allows remote attackers to cause a denial of
| service (infinite recursion and stack consumption) via a crafted PDF
| document, related to releaseResolved functions, aka qpdf-infiniteloop1.

CVE-2017-9209[1]:
| libqpdf.a in QPDF 6.0.0 allows remote attackers to cause a denial of
| service (infinite recursion and stack consumption) via a crafted PDF
| document, related to QPDFObjectHandle::parseInternal, aka
| qpdf-infiniteloop2.

CVE-2017-9210[2]:
| libqpdf.a in QPDF 6.0.0 allows remote attackers to cause a denial of
| service (infinite recursion and stack consumption) via a crafted PDF
| document, related to unparse functions, aka qpdf-infiniteloop3.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-9208
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9208
https://github.com/qpdf/qpdf/issues/99
[1] https://security-tracker.debian.org/tracker/CVE-2017-9209
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9209
https://github.com/qpdf/qpdf/issues/100
[2] https://security-tracker.debian.org/tracker/CVE-2017-9210
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9210
https://github.com/qpdf/qpdf/issues/101

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#839156: "/usr/bin/passenger-config: No such file or directory"

[Nick Phillips]

Seems to me that the problem is that ruby-passenger.install only
installs /usr/sbin, and /usr/bin is ignored.

I think /usr/bin should be added to ruby-passenger.install & then all
would be well.

I don't know much about how rack stuff is supposed to work, but puppet-
master-passenger is completely unusable with this bug in place, and I
suspect other packages that try to use passenger would be as well.

Not sure offhand what severity this merits, but rather think this ought
to qualify for a stable update.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

Bug#863372: RFA: vulture -- scans for unused ("dead") code in a Python program

[Daniel Stender]

On 26.05.2017 03:26, ChangZhuo Chen (陳昌倬) wrote:
> Control: retitle -1 ITA: vulture -- scans for unused ("dead") code in a 
> Python program
> Control: owner -1 !
> 
> On Thu, May 25, 2017 at 09:26:29PM +0200, Daniel Stender wrote:
>> Package: wnpp
>> Severity: normal
>>
>> I'm searching for an adopter for the vulture package [1].
> 
> I will adopt this package.

Great! All the best with that.

DS

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
http://www.danielstender.com/



signature.asc
Description: OpenPGP digital signature

Bug#863267: [Python-modules-team] Bug#863267: Associated removals

[Neil Williams]

On Fri, 26 May 2017 04:11:49 +
Scott Kitterman  wrote:

> I don't see any way to completely resolve this before stretch
> releases other than removing lava-server.

This is a *django* bug! There is no evidence that lava-server is
responsible for this - it just has to use multiple django apps. Any
other system outside Debian using multiple apps will suffer the same
bug.

Note: once this bug occurs, unless the user is *clearly* warned to look
for and install 1.8, *data loss* will occur. We have already had one
user lose data covering 6 months of tests due to this error. The
process must halt when the exception is seen, the app will be down and
unusable and users will get a 503.



-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgphu1EnOqYRc.pgp
Description: OpenPGP digital signature

Bug#863389: linux-image-4.9.0-0.bpo.3-amd64: After update to linux-image-4.9.0.0-0.bpo.3, no route to host via IPV4

[Jason Cohen]

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

Dear Maintainer,

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

   * What led up to the situation?

I upgraded my kernel from linux-image-4.9.0-0.bpo.2-amd64 to 
linux-image-4.9.0-0.bpo.2-amd64. Without making any other changes, I rebooted 
the system. While the system booted successfully, the bonding module was not 
loaded, preventing my bond interface from starting. I had to add this module to 
/etc/modules to get the bond interface to start successfully.  However, this 
was never required in the past, and I have been using this system since 2014 
(Debian Wheezy).  

Once I resolved the missing module issue, I discovered that I had no working 
IPV4 internet access.  A ping to www.google.com returned No Route to Host.  In 
contrast, a ping6 to www.google.com worked.  This was resolved by "ifdown bond0 
&& ifup bond0".  However, I am not sure why this worked. I copied lsmod before 
and after, and there were no new modules loaded.

I resolved the second issue by stopping and bringing up the interface.  
However, every time I restart, I am faced with the same "No route to host" 
issue.

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

To resolve Issue #1, I added "bonding" to /etc/modules. I never had to do this 
in the past, despite numerous kernel updates.

   * What was the outcome of this action?

After making both changes, the network was useable.

   * What outcome did you expect instead?

I expected the network to start normally, as it has done after past kernel 
updates.

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

In the unlikely scenario that some other package update is causing this issue, 
I am providing a list of every package update/install/removal since the system 
was last rebooted:

Start-Date: 2017-05-10  07:53:01
Commandline: /usr/bin/unattended-upgrade
Upgrade: git-man:amd64 (2.1.4-2.1+deb8u2, 2.1.4-2.1+deb8u3), git:amd64 
(2.1.4-2.1+deb8u2, 2.1.4-2.1+deb8u3), git-core:amd64 (2.1.4-2.1+deb8u2, 
2.1.4-2.1+deb8u3)
End-Date: 2017-05-10  07:53:09
 
Start-Date: 2017-05-11  22:32:25
Commandline: apt-get install iperf3
Install: iperf3:amd64 (3.0.7-1), libiperf0:amd64 (3.0.7-1, automatic)
End-Date: 2017-05-11  22:32:29
 
Start-Date: 2017-05-13  07:48:36
Commandline: /usr/bin/unattended-upgrade
Upgrade: libpq5:amd64 (9.4.11-0+deb8u2, 9.4.12-0+deb8u1)
End-Date: 2017-05-13  07:48:40
 
Start-Date: 2017-05-16  07:38:05
Commandline: /usr/bin/unattended-upgrade
Upgrade: bind9-host:amd64 (9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), 
liblwres90:amd64 (9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), host:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libdns100:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libisc-export95:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libisccfg90:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libbind9-90:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), dnsutils:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libisccfg-export90:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libdns-export100:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libirs-export91:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libisccc90:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11), libisc95:amd64 
(9.9.5.dfsg-9+deb8u10, 9.9.5.dfsg-9+deb8u11)
End-Date: 2017-05-16  07:38:13
 
Start-Date: 2017-05-16  10:14:51
Commandline: apt-get install chromium
Install: chromium:amd64 (57.0.2987.98-1~deb8u1)
End-Date: 2017-05-16  10:15:00
 
Start-Date: 2017-05-18  07:55:10
Commandline: /usr/bin/unattended-upgrade
Upgrade: passwd:amd64 (4.2-3+deb8u3, 4.2-3+deb8u4), login:amd64 (4.2-3+deb8u3, 
4.2-3+deb8u4)
End-Date: 2017-05-18  07:55:20
 
Start-Date: 2017-05-18  23:44:57
Commandline: apt-get remove deluge
Remove: deluge:amd64 (1.3.10-3)
End-Date: 2017-05-18  23:45:00
 
Start-Date: 2017-05-18  23:45:51
Commandline: apt-get remove deluged deluge-common deluge-gtk deluge-web
Remove: deluged:amd64 (1.3.10-3), deluge-web:amd64 (1.3.10-3), 
deluge-console:amd64 (1.3.10-3), deluge-gtk:amd64 (1.3.10-3), 
deluge-common:amd64 (1.3.10-3)
End-Date: 2017-05-18  23:45:56
 
Start-Date: 2017-05-18  23:46:46
Commandline: apt-get autoremove
Remove: python-cffi:amd64 (0.8.6-1), python-pam:amd64 (0.4.2-13.1), 
python-pyasn1:amd64 (0.1.7-1), python-twisted-bin:amd64 (14.0.2-3), 
libsdl-image1.2:amd64 (1.2.12-5+b5), python-pyasn1-modules:amd64 (0.0.5-0.1), 
libqt5opengl5:amd64 (5.3.2+dfsg-4+deb8u2), python-serial:amd64 (2.6-1.1), 
python-pycparser:amd64 (2.10+dfsg-3), python-service-identity:amd64 (1.0.0-3), 
python-ply:amd64 (3.4-5), libsdl-mixer1.2:amd64 (1.2.12-11+b1), 
python-characteristic:amd64 (0.1.0-1), python-cryptography:amd64 
(0.6.1-1+deb8u1), libqt5printsupport5:amd64 (5.3.2+dfsg-4+deb8u2), 
libsdl-ttf2.0-0:amd64 (2.0.11-3), libsmpeg0:amd64 (0.4.5+cvs20030824-7.1), 
libtorrent-rasterbar7:amd64 (0.16.18-1), 

Bug#863267: Associated removals

[Scott Kitterman]

I don't see any way to completely resolve this before stretch releases other 
than removing lava-server.

Scott K

Bug#863388: live-boot: Added new functionality to live-boot: rootcopy, modularized filesystems, package installer

[Bill Prochazka]

Package: live-boot
Version: 4.0.2-1
Severity: wishlist
Tags: patch

Dear Maintainer,
There are a few features I have come to love in other live systems that are not
available in the current live-boot system.  I have attached a patch that adds
these features and think it maybe valuable upstream.
1. rootcopy:  This allows for one or more folders on the boot medium that
contain a folder structure relative to /.  before init, these files are copied
to the rootfs.  This feature allows users to make small changes to their
environment (like wallpaper changes or dekstop icons) without needing to
remaster or have a persistent volume.

2. modularized filesystems: This allows for the use of a file, *.module, that
contains newlibe seperated squashfs filenames to be loaded in order.  This is a
change from the default behavior of coping all squashfs files and mounting them
in alphabetical order.

3. packge installer: This allows for a user to include a small apt repo in the
live media.  By creating a *.package file, a user can tell the system to
install these packages from the repo on boot before init.  This is helpful for
testing packages without having to remaster.

I have been using these for quite some time and found them to be critical in my
use.  I would like inclusion upstream so I don't have to continually patch as
new versions are released.



-- Package-specific info:

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

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

Versions of packages live-boot depends on:
ii  live-boot-initramfs-tools [live-boot-backend]  4.0.2-1

Versions of packages live-boot recommends:
pn  live-boot-doc  
pn  live-tools 
ii  rsync  3.1.1-3
pn  uuid-runtime   

Versions of packages live-boot suggests:
ii  cryptsetup2:1.7.3-3
pn  curlftpfs 
pn  httpfs2   
pn  unionfs-fuse  
ii  wget  1.16-1+deb8u1

-- debconf information:
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/^(.*?)(\\)?\${ <-- HERE ([^{}]+)}(.*)$/ at 
/usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked by 
<-- HERE in m/\${ <-- HERE ([^}]+)}/ at /usr/share/perl5/Debconf/Config.pm line 
30.
diff -ruN lib/live/boot/9990-cleanup.sh /lib/live/boot/9990-cleanup.sh
--- lib/live/boot/9990-cleanup.sh	1970-01-01 00:00:00.0 +
+++ /lib/live/boot/9990-cleanup.sh	2017-05-15 15:59:13.0 +
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+#set -e
+
+
+
+Cleanup ()
+{
+	. /bin/live-boot
+	. /scripts/functions
+	log_begin_msg "Cleaning up your mess..."
+	# Unmount boot media if we did a rootcopy or module install
+	([ -n ${ROOTCOPY} ] || [ -n ${MODULES} ]) && umount /root/lib/live/mount/medium
+	#[ -n ${MODULES} ] && umount /root/lib/live/mount/medium
+
+	# Copy through initrd versions of live-boot scripts
+	cp -af /lib/live/boot/* /root/lib/live/boot/
+	cp -af /scripts/live /root/usr/share/initramfs-tools/scripts/live
+
+	# Remove duplicate /live/overlay
+	umount /root/lib/live/mount/overlay
+maybe_break cleanup	
+	log_end_msg
+}
diff -ruN lib/live/boot/9990-cmdline-old /lib/live/boot/9990-cmdline-old
--- lib/live/boot/9990-cmdline-old	2014-12-10 09:37:04.0 +
+++ /lib/live/boot/9990-cmdline-old	2017-05-26 03:45:29.229477053 +
@@ -208,7 +208,8 @@
 
 			toram)
 TORAM="true"
-export TORAM
+MODULETORAM="filesystem.squashfs"
+export TORAM MODULETORAM
 ;;
 
 			toram=*)
@@ -241,6 +242,31 @@
 UNIONTYPE="${_PARAMETER#union=}"
 export UNIONTYPE
 ;;
+
+			rootcopy)
+ROOTCOPY="true"
+export ROOTCOPY
+;;
+
+			rootcopy=*)
+ROOTCOPY="${_PARAMETER#rootcopy=}"
+export ROOTCOPY
+;;
+
+			packagesdir=*)
+PACKAGESDIR="${_PARAMETER#packagesdir=}"
+export PACKAGESDIR
+;;
+
+			packages=*)
+PACKAGES="${_PARAMETER#packages=}"
+export PACKAGES
+;;
+
+			repodir=*)
+REPODIR="${_PARAMETER#repodir=}"
+export REPODIR
+;;
 		esac
 	done
 
diff -ruN lib/live/boot/9990-main.sh /lib/live/boot/9990-main.sh
--- lib/live/boot/9990-main.sh	2014-12-10 09:37:04.0 +
+++ /lib/live/boot/9990-main.sh	2017-05-26 03:12:30.501381288 +
@@ -211,4 +211,17 @@
 	exec 2>&7 7>&-
 	kill ${tailpid}
 	[ -w "${rootmnt}/var/log/" ] && mkdir -p "${rootmnt}/var/log/live" && cp boot.log "${rootmnt}/var/log/live" 2>/dev/null
+
+	# install user modules
+	Packages
+
+	# Clone Root mods
+	Rootcopy
+
+	# Cleanup
+	Cleanup
+
+	# Copy through initrd versions of live-boot scripts
+	cp -af /lib/live/boot/* /root/lib/live/boot/
+	cp -af /scripts/live /root/usr/share/initramfs-tools/scripts/live
 }
diff -ruN lib/live/boot/9990-misc-helpers.sh /lib/live/boot/9990-misc-helpers.sh
--- 

Bug#863387: Acknowledgement (dh produces incomplete binary packages)

[Michael Biebl]

Am 26.05.2017 um 05:48 schrieb Debian Bug Tracking System:
> As you can see from the 10.3 log, a lot of helpers are not run, like
> dh_installdirs, dh_bugfiles, dh_lintian, etc.

Comparing the output, I see the following helpers are not run with 10.3:

dh_installdirs
dh_installman
dh_bugfiles
dh_lintian



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#862524: License Issue about Distributing NVIDIA's cuDNN library via Debian

[Lumin]

Hi,

On 25 May 2017 at 02:51, Paul Wise  wrote:

> Personally I would like to see the amount of proprietary nVidia stuff
> in Debian reduced, not increased. I would suggest focussing your
> efforts on OpenCL/Vulkan based and open source deep learning libraries
> instead of proprietary stuff that only acts as lock-in for other
> proprietary nVidia technologies (CUDA).

Me too. But cuDNN, in fact, is the fastest[1] DNN library supporting
many state-of-the-art research works (e.g. [2]) and production. And
in my real life work about deep learning I have no intention to try
those *slow* OpenCL libraries...

Indeed there are people working on the OpenCL side but OpenCL
is not the major force, at least now.

[1] https://github.com/soumith/convnet-benchmarks
[2] https://tensortalk.com/?cat=conference-cvpr-2016=type-code

>> @lyeager kindly provided some help[3] on this but I'm
>> not really good at these legal terms.
>
> The license you linked to both allows and disallows redistribution,
> seems like it needs a rewrite to be less bizarre. The allowance of
> distribution is time-limited. Personally I would not be comfortable
> distributing this and I do not think that Debian should do so either.

>> Initially I don't think such a well-protected proprietary
>> can be distributed by Debian, untill I find this package
>> in Archlinux's community repo[6].
>
> They may be relying on the clauses allowing time-limited
> redistribution, or they may have simply not read the EULA.

The whole cuDNN package contains only a header and several
binary blobs, which should be easy for users to install by themself
as long as they know how. However If it turns out that it shouldn't
be uploaded to Debian, I'll not be able to build my deep learning
packages against the fastest lib, and users still need to compile
by themself against cuDNN.

I'm fine with both results. If no cudnn, we'll not introduce more
non-free stuff. if there is cudnn, we'll have the fastest library
in archive in an easy-to-use format.

>> I don't know how the Arch guys achieved this but in their
>> PKGBUILD file (arch packaging script) there is a anonymously
>> downloadable link to the cudnn library[7]. What is notable
>> is the "redist" keyword in the URL. I can't find this "redist"
>> URL in nvidia's website.
>
> Probably nVidia need to remove this redist directory from their
> website, since it is supposed to be only distributed behind a
> click-wrap license.

The license of the current version of cuDNN is actually more permissive
than that of previous versions. And the servey before downloading the
blobs is canceled.  Nvidia's attitude towards this library seems to be more
and more permissive and I hope this is true.

>> What makes me more confused is nvidia legal guy's word conveyed
>> by @lyeager [8]. Once a package is uploaded to the Archive, isn't
>> the distributor (legally) the Debian Organization? It's so weird
>> for an individual to take the role of distributor for a package
>> in Archive and I think it's impossible.
>
> There is a long chain of many distributors: firstly you distribute it
> to mentors.d.n, then mentors.d.n distributes it to your sponsor, then
> your sponsor distributes it to Debian ftpmasters, then Debian
> ftpmasters distribute it to Debian mirrors and CD vendors, then Debian
> mirrors and CD vendors distribute it to Debian users, then Debian
> derivatives (Ubuntu etc) distribute it to their mirrors and users.
> Every one of those is potentially liable if they have been found to do
> something illegal.

Thank you for the explanation :-)

Bug#863387: dh produces incomplete binary packages

[Michael Biebl]

Package: debhelper
Version: 10.3
Severity: grave

Hi,

I just noticed that debhelper from experimental produces incomplete
binary packages.
I've attached log building init-system-helpers with 10.2.5 and 10.3

As you can see from the 10.3 log, a lot of helpers are not run, like
dh_installdirs, dh_bugfiles, dh_lintian, etc.

The result is an incomplete binary package (thus the RC severity).

Regards,
Michael


-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-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)

Versions of packages debhelper depends on:
ii  autotools-dev20161112.1
ii  binutils 2.28-5
ii  dh-autoreconf14
ii  dh-strip-nondeterminism  0.034-1
ii  dpkg 1.18.24
ii  dpkg-dev 1.18.24
ii  file 1:5.30-1
ii  libdpkg-perl 1.18.24
ii  man-db   2.7.6.1-2
ii  perl 5.24.1-2
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201608

-- no debconf information
Reading package lists...
dpkg-buildpackage: info: source package init-system-helpers
dpkg-buildpackage: info: source version 1.48
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Bernd Zeimetz 
 dpkg-source --before-build init-system-helpers-1.48
dpkg-buildpackage: info: host architecture amd64
 debian/rules clean
dh clean
   dh_testdir
   dh_auto_clean
   dh_clean
 debian/rules build
dh build
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   debian/rules override_dh_auto_build
make[1]: Entering directory '/init-system-helpers-1.48'
dh_auto_build
for file in $(ls script/deb-* script/dh_*); do \
pod2man --section=1p --utf8 $file $file.1p; \
done
ls: cannot access 'script/dh_*': No such file or directory
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_auto_test
   create-stamp debian/debhelper-build-stamp
 debian/rules binary
dh binary
   create-stamp debian/debhelper-build-stamp
   dh_testroot
   dh_prep
   dh_auto_install
   debian/rules override_dh_install
make[1]: Entering directory '/init-system-helpers-1.48'
dh_install
[ ! -d debian/init-system-helpers ] || sed -i 's/__VERSION__/1.48/' 
debian/init-system-helpers/usr/sbin/service
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_installdocs
   dh_installchangelogs
   debian/rules override_dh_perl
make[1]: Entering directory '/init-system-helpers-1.48'
dh_perl -d --package=init-system-helpers
dh_perl --no-package=init-system-helpers
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_link
   dh_strip_nondeterminism
   dh_compress
   dh_fixperms
   dh_missing
   dh_strip
   dh_makeshlibs
   dh_shlibdeps
   dh_installdeb
   debian/rules override_dh_gencontrol
make[1]: Entering directory '/init-system-helpers-1.48'
if dpkg-vendor --derives-from ubuntu; then \
dh_gencontrol -- -Valt:sysvinit=""; \
else \
dh_gencontrol -- -Valt:sysvinit="| sysvinit-core"; \
fi
dpkg-gencontrol: warning: Depends field of package init-system-helpers: unknown 
substitution variable ${perl:Depends}
make[1]: Leaving directory '/init-system-helpers-1.48'
   dh_md5sums
   dh_builddeb
dpkg-deb: building package 'init' in '../init_1.48_amd64.deb'.
dpkg-deb: building package 'init-system-helpers' in 
'../init-system-helpers_1.48_all.deb'.
 dpkg-genbuildinfo --build=binary
 dpkg-genchanges --build=binary >../init-system-helpers_1.48_amd64.changes
dpkg-genchanges: info: binary-only upload (no source code included)
 dpkg-source --after-build init-system-helpers-1.48
dpkg-buildpackage: info: binary-only upload (no source included)
NOTICE: 'init-system-helpers' packaging is maintained in the 'Git' version 
control system at:
https://anonscm.debian.org/git/collab-maint/init-system-helpers.git
Please use:
git clone https://anonscm.debian.org/git/collab-maint/init-system-helpers.git
to retrieve the latest (possibly unreleased) updates to the package.
Skipping already downloaded file 'init-system-helpers_1.48.dsc'
Skipping already downloaded file 'init-system-helpers_1.48.tar.xz'
Need to get 0 B of source archives.

drwxr-xr-x root/root 0 2017-05-02 10:20 ./
drwxr-xr-x root/root 0 2017-05-02 10:20 ./usr/
drwxr-xr-x root/root 0 2017-05-02 10:20 ./usr/bin/
-rwxr-xr-x root/root 20142 2017-05-02 10:20 ./usr/bin/deb-systemd-helper
-rwxr-xr-x root/root  4507 2017-05-02 10:20 ./usr/bin/deb-systemd-invoke
drwxr-xr-x root/root 0 2017-05-02 10:20 ./usr/sbin/
-rwxr-xr-x root/root 18110 2017-05-02 10:20 ./usr/sbin/invoke-rc.d
-rwxr-xr-x root/root 10061 2017-05-02 10:20 ./usr/sbin/service

Bug#863345: fonts-lohit-beng-assamese: New upstream release 2.91.5

[Jeremy Bicha]

I also prepared the other Lohit updates:

https://anonscm.debian.org/git/users/jbicha-guest/

Punjabi was renamed to Gurmukhi (fonts-lohit-gurmukhi)
Oriya was renamed to Odya (fonts-lohit-orya)
It appears like Davangari (still exists) was split into two new fonts,
marathi and nepali, but I did not package those.

The README files mostly contain build and install instructions so you
might want to not install them.

My main interest in these updates was because I wanted to see more
Fonts listed in the GNOME Software app in Debian and Ubuntu.

Thanks,
Jeremy Bicha

Bug#863386: lintian: ‘libjs-fields-wrong-section’ should recommend “Section: javascript”

[Ben Finney]

Package: lintian
Version: 2.5.50.3
Severity: normal

The ‘libjs-fields-wrong-section’ should now recommend that the package
declare “Section: javascript”.

The Debian archive for a long time had no dedicated section for
JavaScript™ packages. Historically, the recommended section for such
packages was the “web” section.

Since this year [0], the Debian archive has a “javascript” section for
packages. The synopsis of that section [1] is “JavaScript programming
language, libraries, and development tools.”

That section should now be what Lintian recommends for packages that
primarily install a JavaScript™ library.


[0] https://lists.debian.org/debian-dak/2017/01/msg00011.html
[1] https://packages.debian.org/unstable/

-- 
 \ “Don't be afraid of missing opportunities. Behind every failure |
  `\ is an opportunity somebody wishes they had missed.” —Jane |
_o__)  Wagner, via Lily Tomlin |
Ben Finney 


signature.asc
Description: PGP signature

Bug#863385: cloud.debian.org: Latest stretch AMI (ami-772ab761) fails to launch successfully into VPCs

[Andy Sizer]

Package: cloud.debian.org
Severity: important

Hi,

I tried to launch in instance from the latest stretch ami (ami-772ab761 i.e. 
us-east-1) into a VPC. It failed - more specifically networking.service failed. 

Here's the relevant output from syslog:

[ [0;1;31mFAILED [0m] Failed to start Raise network interfaces.
See 'systemctl status networking.service' for details.
 Starting Initial cloud-init job (metadata service crawler)...
[ [0;32m  OK   [0m] Reached target Network.
[9.288945] cloud-init[390]: Cloud-init v. 0.7.9 running 'init' at Mon, 22 
May 2017 09:14:57 +. Up 9.19 seconds.
[9.294365] cloud-init[390]: ci-info: +++Net device 
info
[9.299149] cloud-init[390]: ci-info: 
++---+---+---+---+---+
[9.303735] cloud-init[390]: ci-info: | Device |   Up  |  Address  |Mask 
  | Scope | Hw-Address|
[9.308328] cloud-init[390]: ci-info: 
++---+---+---+---+---+
[9.312879] cloud-init[390]: ci-info: | ens3:  | False | . | .   
  |   .   | 0e:3d:ec:0d:c9:56 |
[9.317451] cloud-init[390]: ci-info: |  lo:   |  True | 127.0.0.1 | 
255.0.0.0 |   .   | . |
[9.321656] cloud-init[390]: ci-info: |  lo:   |  True | . | .   
  |   d   | . |
[9.325631] cloud-init[390]: ci-info: 
++---+---+---+---+---+

I guess networking was looking for eth0 but systemd knew better (i.e. ens3). 
Can't provide any more details since I couldn't access the instance :-) .

This is easy to reproduce. Launch a t2.micro from the ami, specify a VPC 
(create if necessary), enable public IP and launch. Try to ssh into the 
instance.

This may be related to Bug#745587 
(https://lists.debian.org/debian-cloud/2017/04/msg00017.html).

In any case, not being able to launch into a VPC seems pretty severe, all 
things considered.

Bug#862524: License Issue about Distributing NVIDIA's cuDNN library via Debian

[Paul Wise]

On Thu, May 25, 2017 at 10:51 AM, Paul Wise wrote:

> Personally I would like to see the amount of proprietary nVidia stuff
> in Debian reduced, not increased. I would suggest focussing your
> efforts on OpenCL/Vulkan based and open source deep learning libraries
> instead of proprietary stuff that only acts as lock-in for other
> proprietary nVidia technologies (CUDA).

For example, Intel's just released clDNN:

https://github.com/01org/cldnn

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#863378: RFP: libjs-skeleton -- Minimalistic CSS boilerplate framework

[James Valleroy]

I can work on this. I plan to join the pkg-javascript team for
maintaining this package.

--
James



signature.asc
Description: OpenPGP digital signature

Bug#863372: RFA: vulture -- scans for unused ("dead") code in a Python program

[陳昌倬]

Control: retitle -1 ITA: vulture -- scans for unused ("dead") code in a Python 
program
Control: owner -1 !

On Thu, May 25, 2017 at 09:26:29PM +0200, Daniel Stender wrote:
> Package: wnpp
> Severity: normal
> 
> I'm searching for an adopter for the vulture package [1].

I will adopt this package.


-- 
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
http://czchen.info/
Key fingerprint = BA04 346D C2E1 FE63 C790  8793 CC65 B0CD EC27 5D5B


signature.asc
Description: PGP signature

Bug#863110: openvpn: VPN remains connected, but network is unreachable after 30-45 min and requires reconnect

[Prescott Hidalgo-Monroy]

It seemed to take longer (almost exactly an hour since starting the VPN), but 
the issue came back up. This was the only message in the logs:

May 25 20:11:51 $hostname nm-openvpn[26356]: WARNING: 'link-mtu' is used 
inconsistently, local='link-mtu 1602', remote='link-mtu 1634'
May 25 20:11:51 $hostname nm-openvpn[26356]: WARNING: 'tun-mtu' is used 
inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'

Regards,
Prescott

 Original Message 
Subject: Re: Bug#863110: openvpn: VPN remains connected, but network is 
unreachable after 30-45 min and requires reconnect
Local Time: May 25, 2017 5:03 AM
UTC Time: May 25, 2017 10:03 AM
From: a...@inittab.org
To: Prescott Hidalgo-Monroy 
863...@bugs.debian.org <863...@bugs.debian.org>

Hi, could you test this using a wired connection?

On Tue, May 23, 2017 at 10:25:16PM -0400, Prescott Hidalgo-Monroy wrote:
> Despite the update to 2.4.0-6, I'm still experiencing the same issue as 
> before.
>
> The only information could find are from these errors from the syslog. It 
> took approximately 15-20 minutes for the display to shut off for power saving 
> (19:57), based off of the first error message.
>
> May 23 20:15:35 $hostname kernel: [ 1399.479807] perf: interrupt took too 
> long (2515 > 2500), lowering kernel.perf_event_max_sample_rate to 79500
> May 23 20:25:26 $hostname kernel: [ 1989.911138] perf: interrupt took too 
> long (3145 > 3143), lowering kernel.perf_event_max_sample_rate to 63500
> May 23 20:34:46 $hostname wpa_supplicant[639]: wlan0: 
> CTRL-EVENT-REGDOM-CHANGE init=BEACON_HINT type=UNKNOWN
> May 23 20:34:47 $hostname wpa_supplicant[639]: dbus: 
> wpa_dbus_get_object_properties: failed to get object properties: 
> (org.freedesktop.DBus.Error.Failed) failed to parse RSN IE
> May 23 20:34:47 $hostname wpa_supplicant[639]: dbus: Failed to construct 
> signal
> May 23 20:38:03 $hostname kernel: [ 2747.578044] perf: interrupt took too 
> long (3936 > 3931), lowering kernel.perf_event_max_sample_rate to 50750
> May 23 20:53:10 $hostname nm-openvpn[1242]: WARNING: 'link-mtu' is used 
> inconsistently, local='link-mtu 1602', remote='link-mtu 1634'
> May 23 20:53:10 $hostname nm-openvpn[1242]: WARNING: 'tun-mtu' is used 
> inconsistently, local='tun-mtu 1500', remote='tun-mtu 1532'
> May 23 20:56:46 $hostname wpa_supplicant[639]: nl80211: 
> send_and_recv->nl_recvmsgs failed: -33
>
> The final message is due to the ping I used to test the connection.
>
> Regards,
>
> Prescott
>
>  Original Message 
> Subject: Re: Bug#863110: openvpn: VPN remains connected, but network is 
> unreachable after 30-45 min and requires reconnect
> Local Time: May 22, 2017 8:58 AM
> UTC Time: May 22, 2017 1:58 PM
> From: a...@inittab.org
> To: Prescott , 863...@bugs.debian.org
> Debian Bug Tracking System 
>
> On Sun, May 21, 2017 at 06:40:31PM -0500, Prescott wrote:
> > Package: openvpn
> > Version: 2.4.0-5
> > Severity: important
> >
> > Dear Maintainer,
> >
> > After the upgrade to openvpn 2.4.0-5 (from *-4), an issue has been
> > occuring where after having been connected to the VPN for an
> > approximate amount of time of around 30-45 minutes, the network
> > connection will drop. NetworkManager continues to state that the VPN
> > is currently active, but no network is reachable. The only way to
> > restart the VPN network is to bring the connection up again.
> >
> > As stated before, I am using openvpn through NetworkManger, and use
> > nmcli with a configured VPN config file and a separate password file from a 
> > paid service I
> > subscribe to.
> >
>
> Hi,
>
> Could you try 2.4.0-6 just uploaded to unstable? It fixes an issue that
> matches your symptoms.
>
> Regards,
>
> Alberto
>

--
Alberto Gonzalez Iniesta | Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred | http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D 4BF2 009B 3375 6B9A AA55

Bug#863348: dput: please use ftp.security.upload.debian.org for security uploads

[Ben Finney]

On 25-May-2017, Ansgar Burchardt wrote:

> So please update the default dput.cf to upload security uploads to
> ftp.security.upload.debian.org instead of directory to
> security-master.debian.org.

Thank you for the explanation.

If I understand correctly, to resolve this bug, the default ‘dput’
configuration should be changed to have these sections:

=
[security-master]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/SecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning

[security-master-unembargoed]
fqdn= ftp.security.upload.debian.org
method  = ftp
incoming= /pub/OpenSecurityUploadQueue
login   = anonymous
allow_dcut  = 1
# This has been added at the request of the security team.
# Please be sure to know what you are doing before taking it out.
pre_upload_command  = /usr/share/dput/helper/security-warning
=

The only change from the current default is that the ‘fqdn’ value is
now “ftp.security.upload.debian.org” for both sections.

Is that right?

-- 
 \ “Under democracy one party always devotes its chief energies to |
  `\   trying to prove that the other party is unfit to rule — and |
_o__) both commonly succeed, and are right.” —Henry L. Mencken |
Ben Finney 


signature.asc
Description: PGP signature

Bug#861282: packer: FTBFS

[Roger Shimizu]

On Thu, 25 May 2017 13:00:39 -0400 (EDT)
JD Friedrikson  wrote:

> The new changes package nicely and pass the tests just fine. I can confirm 
> that the fix works for qemu. I'm having some issues with Virtualbox, but I've 
> also always had trouble with Virtualbox and packer with the machine; the 
> binary I've compiled straight from Packer's git project also fails in the 
> same way so it's probably not related.
> 
> Can someone step in and confirm that the new patches work with Virtualbox?

Thanks for your verifacation under qemu.
So I'm going to release, as the autoremoval dealline is drawing very near..

If you meet other issues, please report again.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1


pgpLnNsMhxvfB.pgp
Description: PGP signature

Bug#863384: lintian: check license-problem-gfdl-invariants is incorrect

[Norbert Preining]

Package: lintian
Version: 2.5.50.3
Severity: normal

Lintian finds an error in our dvipdfmx.tex in tags it as
texlive-base source: license-problem-gfdl-invariants 
texmf-dist/doc/dvipdfmx/dvipdfmx.tex invariant part is: label{sec:fdl
but the document clearly states:
pdfcopyright={Copyright © The dvipdfmx project team.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover 
Texts.
A copy of the license is included in the section entitled "GNU
Free Documentation License".},
pdflicenseurl={http://www.gnu.org/licenses/fdl.html}
 
The check that made lintian jump at it comes from the following section title:
\section*{GNU Free Documentation License}\label{SEC:FDL}
which is somehow strange.

Furthermore, maybe this is a separate bug, I cannot override this
$ cat debian/source/lintian-overrides 
texlive-base source: license-problem-gfdl-invariants 
texmf-dist/doc/dvipdfmx/dvipdfmx.tex
$
but lintian still reports the error, which seems incorrect.

All the best

Norbert

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

Kernel: Linux 4.12.0-rc1+ (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 lintian depends on:
ii  binutils  2.28-5
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  file  1:5.30-1
ii  gettext   0.19.8.1-2
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.32
ii  libarchive-zip-perl   1.59-1
ii  libclass-accessor-perl0.34-1
ii  libclone-perl 0.38-2+b1
ii  libdpkg-perl  1.18.24
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.94-1
ii  liblist-moreutils-perl0.416-1+b1
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-2
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.71-1
ii  libyaml-libyaml-perl  0.63-2
ii  man-db2.7.6.1-2
ii  patchutils0.3.4-2
ii  perl  5.24.1-2
ii  t1utils   1.39-2
ii  xz-utils  5.2.2-1.2+b1

Versions of packages lintian recommends:
ii  dpkg 1.18.24
ii  libperlio-gzip-perl  0.19-1+b2
ii  perl 5.24.1-2
ii  perl-modules-5.24 [libautodie-perl]  5.24.1-2

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.18.24
ii  libhtml-parser-perl3.72-3
ii  libtext-template-perl  1.46-1

-- no debconf information

Bug#767946: updated patch

[Vincent McIntyre]

Tags: patch
Thanks

The attached version of lshw-common.patch avoids those warnings.
Kind regards
Vince
Added paths to look for device idsIndex: lshw-02.14/src/core/pci.cc
===
Index: lshw-02.18/lshw-B.02.18/src/core/pci.cc
===
--- lshw-02.18.orig/lshw-B.02.18/src/core/pci.cc
+++ lshw-02.18/lshw-B.02.18/src/core/pci.cc
@@ -18,7 +18,7 @@ __ID("@(#) $Id$");
 
 #define PROC_BUS_PCI "/proc/bus/pci"
 #define SYS_BUS_PCI "/sys/bus/pci"
-#define PCIID_PATH DATADIR"/pci.ids:/usr/share/lshw/pci.ids:/usr/local/share/pci.ids:/usr/share/pci.ids:/etc/pci.ids:/usr/share/hwdata/pci.ids:/usr/share/misc/pci.ids"
+#define PCIID_PATH DATADIR"/pci.ids:/usr/share/lshw-common/pci.ids:/usr/local/share/pci.ids:/usr/share/pci.ids:/etc/pci.ids:/usr/share/hwdata/pci.ids:/usr/share/misc/pci.ids"
 
 #define PCI_CLASS_REVISION  0x08  /* High 24 bits are class, low 8 revision */
 #define PCI_VENDOR_ID   0x00/* 16 bits */
Index: lshw-02.18/lshw-B.02.18/src/core/usb.cc
===
--- lshw-02.18.orig/lshw-B.02.18/src/core/usb.cc
+++ lshw-02.18/lshw-B.02.18/src/core/usb.cc
@@ -27,7 +27,7 @@
 
 #define PROCBUSUSBDEVICES "/proc/bus/usb/devices"
 #define SYSKERNELDEBUGUSBDEVICES "/sys/kernel/debug/usb/devices"
-#define USBID_PATH DATADIR"/usb.ids:/usr/share/lshw/usb.ids:/usr/local/share/usb.ids:/usr/share/usb.ids:/etc/usb.ids:/usr/share/hwdata/usb.ids:/usr/share/misc/usb.ids"
+#define USBID_PATH DATADIR"/usb.ids:/usr/share/lshw-common/usb.ids:/usr/local/share/usb.ids:/usr/share/usb.ids:/etc/usb.ids:/usr/share/hwdata/usb.ids:/usr/share/misc/usb.ids"
 
 #define USB_CLASS_PER_INTERFACE 0 /* for DeviceClass */
 #define USB_CLASS_AUDIO 1

Bug#863383: ITP: numix-icon-theme-circle -- Circle icon theme from the Numix project

[James Lu]

Package: wnpp
Severity: wishlist
Owner: James Lu 

* Package name: numix-icon-theme-circle
  Version : 17-04-05-1
  Upstream Author : Numix Project Ltd. 
* URL : https://numixproject.org/
* License : GPL
  Programming Lang: N/A (it's an image set that can be installed as is)
  Description : Circle icon theme from the Numix project

Numix Circle is an extensive icon theme for Linux desktops, with over 4000
application icons. It is developed by the Numix project and serves as a
companion to the base Numix icon theme (numix-icon-theme).



Packaging rationale: Numix Circle is an actively maintained, modern icon theme
which covers a wide range of application icons. I have been using it for many
months with no problems, and it helps polish the look of a desktop with a
consistent icon style. This theme complements numix-icon-theme, which only
contains a base set of system (e.g. panel, settings) icons.

Maintenance: I plan to maintain this within the Debian MATE team, as discussed
on #debian-mate (IRC).

Bug#863382: xpdf: Config Error: Unknown config file command 'errQuiet'

[Pete White]

Package: xpdf
Version: 3.04-4
Severity: normal

Starting xpdf from a command line throws the error "Config Error: Unknown 
config file command 'errQuiet' (/home/user/.xpdfrc:3) 
According to the xpdfrc manpage, if errQuiet is set to yes it should suppress 
all warning and error messages.  The .xpdfrc file contains:

include /etc/xpdf/xpdfrc
urlCommand  "firefox-esr -new-tab '%s'"
errQuietyes

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

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

Versions of packages xpdf depends on:
ii  libc6 2.24-10
ii  libgcc1   1:6.3.0-18
ii  libpoppler64  0.48.0-2
ii  libstdc++66.3.0-18
ii  libx11-6  2:1.6.4-3
ii  libxm42.3.4-13
ii  libxt61:1.1.5-1

Versions of packages xpdf recommends:
ii  cups-bsd   2.2.1-8
ii  gsfonts-x110.24
ii  poppler-data   0.4.7-8
ii  poppler-utils  0.48.0-2

xpdf suggests no packages.

-- Configuration Files:
/etc/xpdf/xpdfrc changed:
psFile  "|lpr"
urlCommand  "sensible-browser '%s'"
unbind down any
unbind right any
unbind up any
unbind left any
bind down window scrollDown(16) 
bind right window scrollRight(16)
bind up window scrollUp(16)
bind left window scrollLeft(16)
bind down fullScreen nextPage
bind right fullScreen nextPage
bind up fullScreen prevPage
bind left fullScreen prevPage


-- no debconf information

Bug#846677: tomcatjss: FTBFS: [javac] /<>/src/org/apache/tomcat/util/net/jss/IJSSFactory.java:26: error: cannot find symbol

[Richard James Salts]

Hi, I just came across this problem when trying to compile myself. This 
is due to the fact upstream don't yet support tomcat 8.5.
The support for tomcat 8.5 is being tracked at 
https://pagure.io/tomcatjss/issue/1

Bug#852780: [sage-packaging] Cantor sage backend

[Ximin Luo]

Ximin Luo:
> Antonio Rojas:
>> El lunes, 22 de mayo de 2017 23:59:00 (CEST) Ximin Luo escribió:
>>  
>>> Thanks for the info. I had a play around, unfortunately --simple-prompt 
>>> won't be sufficient.

>>> REPLs generally support multiline input (e.g. Python itself) so unless the 
>>> GSoC student specifically wants Cantor+Sage to work, we'll have to try to 
>>> figure out how to push ipython to fix their simple-prompt...
>>>
>>
>> Thanks, I've added this info to the upstream report 
>> https://bugs.kde.org/show_bug.cgi?id=375467
>>
> 
> I think I've managed to fix it in IPython with this patch (2 commits):
> 
> https://github.com/ipython/ipython/pull/10606
> 
> Can you confirm? You also need to patch sage/repl/configuration.py as I 
> mentioned earlier, as well as patch cantor_sagebackend.so if its version is < 
> 16.12.
> 

On my end, it works only half-reliably, but I think the remaining issues are 
problems with Cantor and the fact it might be trying to use old Sage APIs; not 
problems with our patched Sage/IPython.

>>> integrate(1/(1-x^2), x)
- works fine

>>> plot(sin(x), (x, 0,2*pi))
- works fine

>>> plot(x^3, (x, 0, 5))
- sometimes works fine
- sometimes generates an incorrect plot, looks like a scatter plot with random 
points instead of a cubic curve
- sometimes gives "AttributeError: must give both plot endpoints"

>>> x = PolynomialRing(RationalField(), 'x').gen()
f = (x^3 - 1)^2-(x^2-1)^2
f.factor()
- works fine

>>> R = PolynomialRing(GF(97),'x')
x = R.gen()
S = R.quotient(x^3 + 7, 'a')
a = S.gen()
S
- outputs a bunch of unformatted raw latex, even though other examples such as 
the integrate one above work. in the console where cantor is running, one sees:
[..]
running:  "/usr/bin/dvips" -E -o "/tmp/cantor_tex-V26836.eps" 
"/tmp/cantor_tex-V26836.dvi"
This is dvips(k) 5.996 Copyright 2016 Radical Eye Software (www.radicaleye.com)
/usr/bin/dvips: DVI file can't be opened: /tmp/cantor_tex-V26836.dvi: No such 
file or directory
rendered file  "/tmp/cantor_tex-V26836.eps"
rendered a result to  "/tmp/cantor_tex-V26836.eps"
settting result to a type  1  result
update Entry
update result
error rendering latex:  "something is wrong"
[..]

X

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

Bug#863288: (no subject)

[Unit 193]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA384

Alternativly, if you didn't want to recommend python-appindicator in Debian you 
could still make the package syncable with the attached patch.


~Unit 193
Unit193 @ Freenode
Unit193 @ OFTC

-BEGIN PGP SIGNATURE-

iQIcBAEBCQAGBQJZJ2JZAAoJEFAB4bCao3RLrkcP+QHiuJkbve/ufbcXnCSzLAnF
BPDrt+GOCqVrnyltxNM710a/S+uEmW4qkbJAYbyBsV+1tZUf27OemD3SelBdjTQe
KZZwza8PvKy2iTLb96hPpHEKeTGsleguC4Q/Ci0gtgEpyhcSOkqiJgzVmrjcAY/w
sO+NhgoV8xk+kyY++GaAEN7euCrO8EUJTnSmqWoQe5JW09MWF3ADwUtpgFgnSKHv
foP8eBOeasm+KaR5Wx3Z9WD/JsAcp1QswG5Csl3EGrOKn7aAH0YVi/+EnbcMEEna
+yTFzj5M1Vlc2wz9qM9tvOdcl3l7F3900WyJSc5tCO27RZ/SHERFzhRs9ZnaMG33
YKOshN6NS20Wk+k9IU1vcuKjAn4kBhhqWZKDAJVOhQW3OrZN0vB+FM04JTSWwuXa
xB7nOGTSAwSOV6Cu55+51LA+BjuYRmen4WRshfnzQK3ITYgB8ZfJgK4WocmQrIBI
lrhixmGXi4iar1rGTJ/Jz7N/YE2l3pYy7QFZIpiXTqgGMP1nZzotNaVb7qqFhKRN
Dl1Y1edYyq0cZs6j+a0ynPTylt/ftfD5yqSG8z9oxHtj4khU3G5SWiZXEZKa54wy
5mT3mMy8yS6tQ/3HrmghIepXM5MV79+Bb6W1SpH40kura0hb12hnwgZA8UwgV2md
RK4qFr5VuDfJF5GmnpG/
=EC48
-END PGP SIGNATURE-From d65670c15990838b8b1b1447ac99ca5f5194fd23 Mon Sep 17 00:00:00 2001
From: Unit 193 
Date: Fri, 29 Apr 2016 00:18:31 -0400
Subject: d/control, d/rules: Override dh_gencontrol to recommend
 python-appindicator if on Ubuntu.

---
 debian/control | 2 +-
 debian/rules   | 7 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 482624a..029f4b8 100644
--- a/debian/control
+++ b/debian/control
@@ -108,7 +108,7 @@ Depends: ${misc:Depends}, ${python:Depends},
  xdg-utils
 Breaks: deluge (<< 1.2.0-1)
 Replaces: deluge (<< 1.2.0-1)
-Recommends: python-pygame
+Recommends: ${dist:Recommends}, python-pygame
 Description: bittorrent client written in Python/PyGTK (GTK+ ui)
  Deluge is a full-featured, multi-platform, multi-interface BitTorrent client
  using libtorrent-rasterbar in it's backend and featuring multiple
diff --git a/debian/rules b/debian/rules
index 48ac68d..e2e3dec 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,5 +1,9 @@
 #!/usr/bin/make -f
 
+ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
+	SUBSTVARS = -Vdist:Recommends="python-appindicator"
+endif
+
 %:
 	dh $@ --with python2
 
@@ -20,3 +24,6 @@ override_dh_auto_clean:
 	dh_auto_clean
 	find . -type d -name '*.egg-info' | xargs rm -rf
 	rm -f deluge/data/share/applications/deluge.desktop
+
+override_dh_gencontrol:
+	dh_gencontrol -- $(SUBSTVARS)
-- 
cgit v0.12

Bug#863381: Bug Report

[Lobert For Fun]

Subject: iptables: network unstable when iptables mangle is added
Package: iptables
Version: 1.4.21-2+b1
Severity: important

Dear Maintainer,

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

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

Versions of packages iptables depends on:
ii  libc6  2.19-18+deb8u9
ii  libnfnetlink0  1.0.1-3
ii  libxtables10   1.4.21-2+b1

iptables recommends no packages.

iptables suggests no packages.

-- no debconf information

Bug#852780: [sage-packaging] Cantor sage backend

[Ximin Luo]

Antonio Rojas:
> El lunes, 22 de mayo de 2017 23:59:00 (CEST) Ximin Luo escribió:
>  
>> Thanks for the info. I had a play around, unfortunately --simple-prompt 
>> won't be sufficient.
>>>
>> REPLs generally support multiline input (e.g. Python itself) so unless the 
>> GSoC student specifically wants Cantor+Sage to work, we'll have to try to 
>> figure out how to push ipython to fix their simple-prompt...
>>
> 
> Thanks, I've added this info to the upstream report 
> https://bugs.kde.org/show_bug.cgi?id=375467
> 

I think I've managed to fix it in IPython with this patch (2 commits):

https://github.com/ipython/ipython/pull/10606

Can you confirm? You also need to patch sage/repl/configuration.py as I 
mentioned earlier, as well as patch cantor_sagebackend.so if its version is < 
16.12.

X

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

Bug#716982: also in 3.0.2

[Geert Stappers]

Meanwhile I learned that CMakeLists.txt is a generated file.


Update for disabling the tests is

--- a/debian/rules
+++ b/debian/rules
@@ -12,7 +12,7 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--no-undefined 
-Wl,--as-needed
 
 override_dh_auto_configure:
dh_auto_configure -Skf5 --parallel -- \
-   -DKDE4_BUILD_TESTS=false \
+   -DBUILD_TESTS=false \
-DENABLE_WEBCAM=false
 
 override_dh_shlibdeps:



Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#863347: unblock: vlc/2.2.6-1~deb9u1

[Ivo De Decker]

Hi,

On Thu, May 25, 2017 at 08:37:00PM +, Niels Thykier wrote:
> > The upstream changes are attached as vlc-2.2.6.diff (updates to the 
> > translations
> > have been stripped). The changes in debian (vlc-debian.stretch.diff) 
> > includes
> > the usual bump of the versions in *.maintscripts and in Breaks + Repalces. 
> > The
> > Breaks + Replaces from libvlc-bin have been removed as they are not 
> > necessary.

> To be honest, it is a bit problematic that we have to bump the version
> of breaks/replaces + conffile handling for every upload.

This actually defeats the purpose of having the version in there. If people
have lines for both jessie(-security) and stretch in their sources.list, vlc
might go back and forth between the versions in jessie and stretch, depending
on the timing of the uploads. This will result in problems.

The only way to properly fix this, is to make sure the version of vlc in
jessie(-security) is always lower than the first version of vlc in stretch
(going forward). You can achieve this by bumping the epoch for vlc in stretch
(but not in jessie), and changing the breaks, replaces etc accordingly.

Cheers,

Ivo

Bug#863379: unblock: beignet/1.3.0-4

[Rebecca N. Palmer]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
Control: severity 863300 important
Control: tags 863300 + pending
X-Debbugs-CC: pkg-opencl-de...@lists.alioth.debian.org

Please unblock package beignet (currently awaiting sponsorship)

beignet 1.3 upstream added two additional files to provide OpenCL 2.0
support, which my packaging didn't install.  As these files are
not used on my (non-2.0-capable) hardware, it worked when tested.

However on 2.0-capable hardware, this makes it claim to support 2.0,
then fail when anything actually tries to use it.

(On my next normal upload I plan to use dh_install --fail-missing
to make sure this can't happen again, but now is not the time
for unnecessary changes.)

unblock beignet/1.3.0-4

diff -Nru beignet-1.3.0/debian/beignet-opencl-icd.install 
beignet-1.3.0/debian/beignet-opencl-icd.install
--- beignet-1.3.0/debian/beignet-opencl-icd.install 2017-04-29 
08:52:01.0 +0100
+++ beignet-1.3.0/debian/beignet-opencl-icd.install 2017-05-25 
19:48:40.0 +0100
@@ -3,6 +3,6 @@
 usr/lib/*/beignet/libgbeinterp.so
 usr/lib/*/beignet/libcl.so
 usr/lib/*/beignet/include
-usr/lib/*/beignet/beignet.pch
-usr/lib/*/beignet/beignet.bc
+usr/lib/*/beignet/beignet*.pch
+usr/lib/*/beignet/beignet*.bc
 usr/share/metainfo/*.metainfo.xml
diff -Nru beignet-1.3.0/debian/changelog beignet-1.3.0/debian/changelog
--- beignet-1.3.0/debian/changelog  2017-05-02 23:23:38.0 +0100
+++ beignet-1.3.0/debian/changelog  2017-05-25 19:51:36.0 +0100
@@ -1,3 +1,9 @@
+beignet (1.3.0-4) unstable; urgency=medium
+
+  * Install OpenCL 2.0 libraries.  (Closes: #863300)
+
+ -- Rebecca N. Palmer   Thu, 25 May 2017 19:50:07 
+0100
+
 beignet (1.3.0-3) unstable; urgency=medium
 
   * Fix "Exec...-5" error on older hardware.  (Closes: #860805)

Bug#862959: alex4: Error in French translation

[Suppositoire Effervescent]

On Fri, 19 May 2017 13:07:56 +0200 Andreas =?UTF-8?B?UsO2bm5xdWlzdA==?=
 wrote:
> On Fri, 19 May 2017 12:45:19 +0200,
> Suppositoire wrote:
>
> >Package: alex4
> >Severity: minor
> >
> >Dear Maintainer,
> >
> >I just noticed that the French translation for "Alex the Alligator"
> >is not the right one. Indeed, it is currently "Alex
> >l'allégateur" (="Alex the Allegorist"), which does not mean the
> >same thing at all.
> >
> >It should be translated "Alex l'alligator" (alligator as in english).
> >
> >Please, notice that not only alex4 package description is concerned,
> >but also alex4-data package.
> >
>
> Please notice that the original English string isn't "Alex the
> Alligator", but "Alex the Allegator" - a play on words since the
> game uses the library Allegro.
>
> I don't know about the french translation though, it might be a
> variant on the same thing there.
>
> -- Andreas Rönnquist
> mailingli...@gusnan.se
> gus...@debian.org
>
>

I am sorry I had not paid attention to the play on words in the original
name of the game.

Indeed, it would be wise to take this into account in the French
translation.

However, I am not sure that the current translation is the most
appropriate. Perhaps
"Alex l'allegator" or "Alex l'allegrator" would be better.

It is therefore up to the translation team to look into the matter if
necessary.

Regards. :)

Bug#861591: libgnupg-interface-perl: FTBFS: Failed 10/22 test programs. 23/53 subtests failed.

[Daniel Kahn Gillmor]

On Thu 2017-05-25 18:35:13 +0200, Chris Lamb wrote:
> Daniel Kahn Gillmor wrote:
>
>> The failures on repeat are presumably because of something related to
>> the gpg-agent daemon persisting across the tests.I'll look into
>> invoking "gpgconf --kill all" at the start of the test suite
>
> Is that safe? What if I'm running gpgconf outside of the build? :)

I think i'll run it with the designated --homedir for the test suite
itself, which should be safe.

Also, i may decide to change the testing homedir to be
randomly-generated, inside /tmp, rather than having it in the build
tree.

frustrating and annoying to have to deal with this, but this is what we
get for relying on the constrained length of un_path in the unix domain
socket struct. :/

--dkg

Bug#862355: mate-settings-daemon: Can't change wallpaper when selecting one

[Iván Baldo]

So according to upstream upgrading mate-desktop to 1.16.2 and caja to 1.16.3 
fixes this. 
Should a bug report be made for each one of them and close this one or the 
maintainers are aware of this anyway? 
Thanks! 

Bug#863378: RFP: libjs-skeleton -- Minimalistic CSS boilerplate framework

[Federico Ceratto]

Package: wnpp
Severity: wishlist

* Package name: libjs-skeleton
  Version : 2.0.4
  Upstream Author : Dave Gamache
* URL : http://getskeleton.com
* License : MIT
  Programming Lang: CSS
  Description : Minimalistic CSS boilerplate framework

A minimalistic CSS framework for small projects. The whole framework
fits in around 400 lines of CSS and does not require javascript or
"build" tools.

The framework is already used by libjs-twitter-bootstrap-docs,
python-web2py and it's a dependency for MediaGoblin, see #657405

The upstream development is inactive since a while.

Bug#863377: jessie-pu: package nethogs/0.8.0-1+deb8u1

[Adrian Bunk]

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


 changelog  |8 
 patches/series |1 +
 patches/ugram-socket.patch |   16 
 3 files changed, 25 insertions(+)

diff -Nru nethogs-0.8.0/debian/changelog nethogs-0.8.0/debian/changelog
--- nethogs-0.8.0/debian/changelog  2011-08-27 20:48:58.0 +0300
+++ nethogs-0.8.0/debian/changelog  2017-05-25 23:17:54.0 +0300
@@ -1,3 +1,11 @@
+nethogs (0.8.0-1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Add upstream patch for "creating socket failed while
+establishing local IP" bug. (Closes: #808433)
+ 
+ -- Adrian Bunk   Thu, 25 May 2017 23:12:56 +0300
+
 nethogs (0.8.0-1) unstable; urgency=low
 
   * Switch to dpkg-source 3.0 (quilt) format.
diff -Nru nethogs-0.8.0/debian/patches/series 
nethogs-0.8.0/debian/patches/series
--- nethogs-0.8.0/debian/patches/series 2011-08-27 20:44:48.0 +0300
+++ nethogs-0.8.0/debian/patches/series 2017-05-25 23:15:26.0 +0300
@@ -1,2 +1,3 @@
 02_geteuid.diff
 04_makefile.diff
+ugram-socket.patch
diff -Nru nethogs-0.8.0/debian/patches/ugram-socket.patch 
nethogs-0.8.0/debian/patches/ugram-socket.patch
--- nethogs-0.8.0/debian/patches/ugram-socket.patch 1970-01-01 
02:00:00.0 +0200
+++ nethogs-0.8.0/debian/patches/ugram-socket.patch 2017-05-25 
23:16:49.0 +0300
@@ -0,0 +1,16 @@
+Description: Use a normal DGRAM (UDP) socket to determine local IPv4 IP
+Author: Arnout Engelen 
+Bug-Debian: https://bugs.debian.org/808433
+Origin: upstream, 
https://github.com/raboof/nethogs/commit/ee8b7ea8a4c6f109f8080894734bbf4d6281c809
+
+--- nethogs-0.8.0.orig/packet.cpp
 nethogs-0.8.0/packet.cpp
+@@ -38,7 +38,7 @@ void getLocal (const char *device, bool
+   struct ifreq iFreq;
+   struct sockaddr_in *saddr;
+ 
+-  if((sock=socket(AF_INET, SOCK_RAW, htons(0x0806)))<0){
++  if((sock=socket(AF_INET, SOCK_DGRAM, 0))<0){
+   forceExit("creating socket failed while establishing local IP - 
are you root?");
+   }
+   strcpy(iFreq.ifr_name, device);

Bug#863357: 'winetricks allfonts' fails on Baekmuk

[rose croix]

Package: winetricks
Version: 0.0+20141009+svn1208-2

The font package ttf-baekmuk has been renamed to fonts-baekmuk in Debian, but 
winetricks still has it listed as the former. As such, it can't download it and 
fails when trying to execute 'winetricks allfonts'. The included diff patch 
fixes it.

7750c7750
< w_download 
http://ftp.debian.org/debian/pool/main/t/ttf-baekmuk/ttf-baekmuk_2.2.orig.tar.gz
 afdee34f77de6ea87b43c92a88b7385ba65b
---
> w_download 
> http://ftp.debian.org/debian/pool/main/f/fonts-baekmuk/fonts-baekmuk_2.2.orig.tar.gz
>  afdee34f77de6ea87b43c92a88b7385ba65b
7752c7752
< gunzip -dc "$W_CACHE/baekmuk/ttf-baekmuk_2.2.orig.tar.gz" | tar -xf -
---
> gunzip -dc "$W_CACHE/baekmuk/fonts-baekmuk_2.2.orig.tar.gz" | tar -xf -

Bug#833193: chapel/1.15 [ITP]

[Ben Albrecht]

Hi Sean,

> Dear Ben,
> 
> Thank you again for this well-organised response.
> 
> To return the favour, in this e-mail I'll
> 
>  * discuss some logistics around this RFS;
>  * raise an issue with the current source package on mentors;
>  * respond to the substantive packaging topics in your e-mail.
> 
> Logistics
> -
> 
> (1) Can you confirm that [1] is the repository from which you generated
> the .dsc that you uploaded to mentors.debian.net?  Can we work out of
> that repository from now on?

Yes.

> I want to be able to refer to git commits, and use `git diff` to review
> changes you've made in response to feedback.  Using raw source packages
> is a pain.
> 
> (2) It looks like we're going to need to package lots of library
> dependencies of the full chapel-runtime.  I'm not going to be able to
> review and sponsor those -- it's too much for one volunteer.  I will
> continue as the reviewer and eventual sponsor of the chapel source
> package itself (i.e. this RFS).

OK, thanks for letting us know. We'll seek other sponsors whenever
we start to pursue the other packages.

> Current source package
> --
> 
> It fails to build, I think because it assumes $HOME exists, which is an
> assumption package builds cannot make (let me apologise that this is not
> better documented).
> 
> I've attached a log.

We'll have a look. We're planning to patch `make check` to use /tmp
instead of $HOME for the Debian package.

> Responses to substantive packaging issues
> -
> 
> > Do you feel that we have addressed your concerns about the FHS?
> 
> I think so!  Three remaining issues:
> 
> (1) Thank you for the explanation of the *.c, *.a, *.h files.  Could you
> say what the *.py files are for?  Again just part of the compilation
> process?  Never expected to be run outside of that process?

The .py files are used to manage the Chapel configuration. The compiler
uses these scripts in order to determine the appropriate settings,
to include things like which tasking layer to use.

There is a utility, printchplenv, that prints out the current configuration.
However this tool is only really useful for people using a Chapel source
distribution.

For a binary distribution like we will have with Debian, we do not expect
users to run any of these scripts themselves. Only the `chpl` compiler
will run them.

> (2) Per Lumin, you're going to need to encode a version in the binary
> package names so that they can be co-installable.  Further, in order
> that they can co-exist in the archive, you'll need to encode a version
> in the source package name, too.

OK, we're working on it (see PR #11 on our github repo). We're planning
to rename the source package to chapel-1.15.

> (3) I'll need to review the full list of installed files once you've
> finished implementing what you've described.

We'll let you know when we have the next version ready.

> Could you say more about why we want these other configurations?
> 
> Imagine we upload chapel-minimal to Debian.  Then later we upload the
> full build, including the qthreads support.  Would anyone want to
> install chapel-minimal at that point?
> 
> If you are thinking that chapel-minimal is a holdover because we foresee
> very long delays in bringing the Debian packages of the third-party
> dependencies into compatibility (see below), why not just have a chapel
> package that gradually gains functionality?  Are you thinking that this
> might confuse users or break their build systems?

Yes, we expect it will take a long time to get all of the third-party stuff
packaged appropriately and we might not pursue that right away.

We're on board with a strategy of gradually bringing in the third-party support
- so we will rename chpl-compiler-minimal-1.15 and chapel-runtime-minimal-1.15
to just chapel-compiler-1.15 and chapel-runtime-1.15.

> > [...]
> > How should we handle the third-party dependencies as we expand beyond
> > just chapel-minimal?
> 
> The chapel source package cannot build its own versions of third-party
> library dependencies.  They need to be packaged separately.
> 
> The relevant section of Debian policy is 4.13, but that doesn't
> sufficiently emphasise the security implications.  Our security team
> requires that there is only one copy of a codebase in Debian, so they
> have to patch security bugs in only one place.
>
> Suppose the chapel source package builds a copy of the codebase.  Then
> later, someone else wants to package another piece of software that uses
> the same library.  In order to avoid two copies in the archive, they
> must now file a bug asking you to extract the codebase from chapel and
> put it in its own source package.  This work now blocks that other
> packager.  To avoid this unpleasant situation, we require packaging all
> dependencies separately in the first place.
> 
> In the cases where chapel uses a non-standard configuration of a
> library, there are options other than 

Bug#863376: jessie-pu: package mylvmbackup/0.15-1.1~deb8u1

[Adrian Bunk]

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


 changelog |   15 +++
 control   |2 +-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff -Nru mylvmbackup-0.15/debian/changelog mylvmbackup-0.15/debian/changelog
--- mylvmbackup-0.15/debian/changelog   2014-05-22 20:36:01.0 +0300
+++ mylvmbackup-0.15/debian/changelog   2017-05-25 22:57:18.0 +0300
@@ -1,3 +1,18 @@
+mylvmbackup (0.15-1.1~deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for jessie.
+
+ -- Adrian Bunk   Thu, 25 May 2017 22:56:41 +0300
+
+mylvmbackup (0.15-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add the missing dependency on libfile-copy-recursive-perl.
+(Closes: #789885)
+
+ -- Adrian Bunk   Fri, 13 Jan 2017 21:34:08 +0200
+
 mylvmbackup (0.15-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru mylvmbackup-0.15/debian/control mylvmbackup-0.15/debian/control
--- mylvmbackup-0.15/debian/control 2014-05-22 20:27:25.0 +0300
+++ mylvmbackup-0.15/debian/control 2017-01-13 21:34:08.0 +0200
@@ -11,7 +11,7 @@
 
 Package: mylvmbackup
 Architecture: all
-Depends: ${perl:Depends}, ${misc:Depends}, libdbd-mysql-perl, 
libtimedate-perl, libconfig-inifiles-perl, lvm2
+Depends: ${perl:Depends}, ${misc:Depends}, libdbd-mysql-perl, 
libtimedate-perl, libconfig-inifiles-perl, libfile-copy-recursive-perl, lvm2
 Suggests: mysql-server
 Description: quickly creating backups of MySQL server's data files
  To perform a backup, mylvmbackup obtains a read lock on all tables and

Bug#863375: please package a newer version, esp. for mod_firewall (e.g. spam protection)

[W. Martin Borgert]

Package: prosody-modules
Version: 0.0~hg20170123.3ed504b944e5+dfsg-1
Severity: wishlist

While I'm not suffering of any SPIM (XMPP spam) anymore, thanks
to gajim-antispam, we should have a more recent version of
mod_firewall for non-Gajim-users. Read:
https://lists.debian.org/debian-rtc/2017/04/msg3.html

Bug#863374: sosreport: Docker plugin uses the wrong command for Ubuntu

[David Coronel]

Package: sosreport
Severity: normal
Tags: upstream

Dear Maintainer,

This bug doesn't affect Debian ( no DebianPlugin for docker) but I am filing 
this bug for sosreport in debian to stay aligned.

[Impact]

The docker plugin in sosreport doesn't collect informations for Ubuntu.

In docker.py for the Ubuntu Plugin, the docker command is set to 'docker.io'[1] 
which seems to be a old workaround that has been removed[2], thus the docker 
plugin is no longer calling an existing docker binary which as a result doesn't 
collect docker informations in Ubuntu.

[1]- Plugin : docker.py

# Name collision with another package requires docker binary rename
docker_cmd = 'docker.io'

[2]- docker.io package : debian/changelog

docker.io (1.3.1~dfsg1-2) unstable; urgency=medium
* Remove deprecated /usr/bin/docker.io symlink
- added as a temporary shim in 1.0.0~dfsg1-1 (13 Jun 2014)
- unused by package-installed files in 1.2.0~dfsg1-1 (13 Sep 2014)
-- Tianon Gravi  Fri, 07 Nov 2014 13:11:34 -0700

[Test Case]

# Install sosreport from the Ubuntu archive
$ sudo apt-get update
$ sudo apt-get install sosreport

# Run sosreport with docker plugin only or all loaded plugins (for the sake of 
testing docker plugin the "-o" is more appropriate

Docker plugin only :
$ sosreport -o docker

All loaded plugins:
$ sosreport -a

# Extract the sosreport*.tar.xz file generated by the above command found in 
/tmp

# Look in "/path_to_sosreport/sos_commands/docker/" and note that all files are 
empty with "0" size.

[Regression Potential]

No regression, this is a trivial fix that will allow sosreport to start 
collecting the docker informations again.
If for some reasons, a regression is found, it would be 100% limited to docker 
plugin of sosreport and not affecting the functionality of sosreport nor other 
plugin.

[Other Info]

Additional information about the context can be found here :
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1338768

The bug has been reported upstream already[3] and two similar patches has been 
proposed[4].
Let's see which one will be accepted/merged.

[3] - Upstream Bug
https://github.com/sosreport/sos/issues/930

[4] - Pull Request(s)
PR #1
https://github.com/sosreport/sos/pull/1009
https://github.com/sosreport/sos/pull/1009/commits/f8a939d792d8ac683f341458b8cf77a35c4db929

PR #2
https://github.com/sosreport/sos/pull/1012
https://github.com/davecore82/sos/commit/7d063cf0a5949a9819b80f68e1862d95b8c3fa35

[Original Description]

This Launchpad bug is based on an existing GitHub bug[1].

The docker plugin is currently broken in sosreport. In docker.py[2] for Ubuntu 
the docker command is set to 'docker.io'.

docker_cmd = 'docker.io'

The docker.io package used to have a docker.io binary but this was reverted in 
this debian/changelog from Ubuntu Xenial/16.04 (LTS):

 docker.io (1.3.1~dfsg1-2) unstable; urgency=medium
* Remove deprecated /usr/bin/docker.io symlink
  - added as a temporary shim in 1.0.0~dfsg1-1 (13 Jun 2014)
  - unused by package-installed files in 1.2.0~dfsg1-1 (13 Sep 2014)
   -- Tianon Gravi  Fri, 07 Nov 2014 13:11:34 -0700

The Docker Community and Enterprise Editions (docker-ce and docker-ee packages) 
also use the plain docker binary and this change is necessary to make the 
sosreport docker module work again.

There are currently two different pull requests that fix this issue:

https://github.com/sosreport/sos/pull/1009
https://github.com/sosreport/sos/pull/1012

We should SRU this fix once one of them is accepted.

[1] https://github.com/sosreport/sos/issues/930
[2] https://github.com/sosreport/sos/blob/master/sos/plugins/docker.py


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

Kernel: Linux 4.8.0-52-generic (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Bug#863372: RFA: vulture -- scans for unused ("dead") code in a Python program

[Daniel Stender]

Package: wnpp
Severity: normal

I'm searching for an adopter for the vulture package [1].

Thanks,
DS

[1] https://packages.qa.debian.org/v/vulture.html

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
http://www.danielstender.com/

Bug#863373: mount: option to use losetup -P when mounting

[ben]

Package: mount
Version: 2.29.2-1
Severity: wishlist



Now that losetup has the -P option that allows scanning images to find 
partitions it would be nice if mount -o loop,part=1 or similar would mount the 
partition so specified.

Bug#863371: RFA: python-brainstorm -- deep learning library for Python

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the python-brainstorm package [1].

Thanks,
DS

[1] https://packages.qa.debian.org/p/python-brainstorm.html

The package description is:
 Brainstorm is an easy-to-use Python library for setting up deep
 (multiple layered) artificial neural networks which can be employed
 for setting up advanced machine learning applications like
 for computer vision tasks, speech recognition and natural language
 processing.
 .
 Brainstorm supports GPU accelerated computation using NVIDIA CUDA,
 however the scikit-cuda library which is needed for that additionally
 isn't available yet within Debian.

Bug#863370: RFA: pyomo -- PYthon Optimization Modeling Objects

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the pyomo package [1].

Thanks,
DS

[1] https://packages.qa.debian.org/p/pyomo.html

The package description is:
 Pyomo is a tool for formulating and analyzing mathematical models
 that represent real-world systems for complex optimization applications
 as applied in different areas of business, engineering, research,
 and administration.
 It's used to define symbolic problems, create concrete problem
 instances, and solve this instances with standard solvers.
 Pyomo provides a capability that is commonly associated with
 algebraic modeling languages (AML) and applications like
 AMPL, AIMMS, or GAMS, but has its modeling objects within the Python
 environment.
 Pyomo features a versatile set of modeling components, and supports
 concrete models (defined with data) as well as abstract models (defined
 without data).
 .
 For the processing of instantiated models Pyomo supports a wide range of
 independent solvers that could be written either in Python or other languages.
 Pyomo supports the general ASL (AMPL Solver Library) compatible interface,
 and has invidividual backends for solvers which some of them are available
 within Debian (GLPK, COIN-OR CPC, OPENOPT).
 Pyomo's solver manager could also employ the public NEOS Server to remotely
 optimize models if network access is available.
 .
 Pyomo was formerly released as the Coopr software library, and includes
 the PySP package (Pyomo Stochastic Programming) which provides generic
 solvers for stochastic programming.

Bug#863367: libecryptfs-dev: unable to install because of unmet dependency

[s3v]

Package: libecryptfs-dev
Severity: grave
Justification: renders package unusable


Currently libecryptfs-dev is uninstallable on Stretch.
This is the output when trying to install:


# apt-get install libecryptfs-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libecryptfs-dev : Depends: libtspi-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


Thanks for reading.

Regards.


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

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

Bug#863369: r-cran-tikzdevice: package unuseable: Graphics API version mismatch

[Esokrates]

Package: r-cran-tikzdevice
Version: 0.10-1-1
Severity: important

Dear Maintainer,

It seems the package needs a rebuild against the latest version of R.
Installing the package and trying to use it in an R pogram the following
way:

library(tikzDevice)
tikz(file = "tikz.tex", width = 5, height = 5)

reports an External Graphics API version mismatch.

Removing the package and installing the same version using the R-interal
way of installing (install.packages('tikzDevice')), the same code works
just fine.


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

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 r-cran-tikzdevice depends on:
ii  libc6  2.24-10
ii  r-base-core [r-api-3]  3.4.0-1
ii  r-cran-filehash2.3-1
ii  r-cran-png 0.1-7-1

r-cran-tikzdevice recommends no packages.

r-cran-tikzdevice suggests no packages.

-- no debconf information

Bug#740893: Patch for python-coverage bug #740893

[Eevel Weezel]

I did some further testing around changing the version of jquery.hotkeys.js
in libjs-jquery-hotkeys to the upstream jeresig version, and behavior of
the various libraries that depend on it.

For python-coverage, the bug is still there, with the addition of a new
error related to differences in unload() in jquery.min.js.  Presumably, the
current upstream version of jquery.hotkeys.js is newer than the bundled
version, as the reports work as expected with the bundled libraries.

For prometheus, hotkeys behaved as expected.

For gitit, the ctrl+r hotkey is supposed to submit a post.  This previously
resulted in the page refreshing, but resulted in a warning about
resubmitting the page (arguably, one might expect that when randomly
submitting a post? I'm not familiar enough with this package to know which
is the intended behavior).

Best,
Heather

Bug#863368: RFA: pylint-flask -- Pylint plugin for analyzing Flask applications (Python 2)

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the pylint-flask package [1].

Thanks,
DS

[1] https://packages.qa.debian.org/p/pylint-flask.html

The package description is:
 This is a plugin which improves the static code analyzer Pylint
 when checking Flask (Python web framework) applications code.

Bug#863366: RFA: pylint-common -- Pylint plugin for the standard Python library

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the pylint-common package [1].

Thanks,
DS

The package description is:
 Pylint is a source code bug and quality checker for the Python programming
 language. This package provides a plugin for augmenting and improving error
 detection and analysis of the standard Python library.

Bug#863365: RFA: pylint-celery -- Pylint plugin for code using the Celery library

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the pylint-celery package [1].

Thanks,
DS

The package description is:
 Pylint is a source code bug and quality checker for the Python programming
 language. This package provides a plugin for checking code using the Celery
 library (distributed task queue).
 .
 This package contains the module for Python2.

[1] https://packages.qa.debian.org/p/pylint-celery.html

Bug#863364: RFA: pydocstyle -- Python docstring style checker (PEP-257 conventions)

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the pydocstyle package [1].

Thanks,
DS

The package description is:
 PEP-257 provides conventions for Python docstrings (string literals which
 occur as first statement in a module, function, class or method definition
 for documentation purposes). This tool checks Python code whether
 these conventions have been complied with, and if docstring are missing.
 .
 This is a successor of the application "pep257".

[1] https://packages.qa.debian.org/p/pydocstyle.html

Bug#863363: RFA: prospector -- comprehensive static Python code analyzer

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the prospector package [1].

Thanks,
DS

The package description is:
 Prospector analyzes Python source files and puts out information about
 coding errors, potential problems, convention violation and unnecessary
 complexity.
 .
 It provides an uniform and flexible interface for these tools:
  - Pylint (extensive Python code checker)
  - Pyflakes (checks Python code for logical errors)
  - Frosted (a Pyflakes fork)
  - Pep8 (checks for Python coding style conventions)
  - Pep8-naming (checks for naming conventions not covered by Pep8)
  - McCabe (checks for cyclomatic code complexity)
  - Pep257 (checks for compliance with the docstring conventions)
  - Dodgy (checks for hard coded passwords, VCS diff checkins etc.)
  - Vulture (scans Python programs for unused code)
  - Pyroma (Python packaging quality checker)
 .
 Prospector detects if code employs specific frameworks and libraries
 like currently Django (web application framework)
 and Celery (asynchronous task/job queue),
 and checks them by corresponding Pylint plugins.

[1] https://packages.qa.debian.org/p/prospector.html

Bug#863362: RFA: pep8-naming -- check for PEP 8 naming conventions (flake8 plugin for Python2)

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the pep8-naming package [1].

Thanks,
DS

The package description is:
 The PEP 8 recommendation is a style guide for Python code. This plugin for
 flake8 checks whether the naming conventions of PEP 8 have been commplied
 with. However written as plugin for flake8, some tools make independent use
 of the module.

[1] https://packages.qa.debian.org/p/pep8-naming.html

Bug#863361: dgit-user(7): replace apt-get build-deps with mk-build-deps

[Nikolaus Rath]

Package: dgit
Version: 3.10~bpo8+1
Severity: normal

Please consider replacing

% sudo apt-get build-dep glibc

with

% mk-build-dep --root-cmd=sudo --install

That way, you won't get bitten if the build deps of the new package
differ from the build deps of the package in the archive.

Does build-dep require deb-src in sources.list? If so, the above removes
that requirement as well.

mk-build-deps is shipped by devscripts.

Bug#863360: python-sqlalchemy: versioned build-dep on python-zzzeeksphinx

[Sandro Tosi]

Package: python-sqlalchemy
Version: 1.0.6+ds1-1
Severity: important

Hello,
as a result of fixing #829020 in zzzeeksphinx, now python-sqlalchemy needs a
versioned b-d on >= 1.0.18-2~ (so that it can pick up the right version of
zzzeeksphinx)

thanks,
Sandro

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

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

Versions of packages python-sqlalchemy depends on:
pn  python:any  

Versions of packages python-sqlalchemy recommends:
ii  python-sqlalchemy-ext  1.0.6+ds1-1

Versions of packages python-sqlalchemy suggests:
ii  python 2.7.9-1
pn  python-fdb 
pn  python-mysqldb 
pn  python-psycopg2
pn  python-pymssql 
pn  python-sqlalchemy-doc  

-- no debconf information

Bug#861695: debian-archive-keyring: Please ship release-specific keys separately outside of /etc/apt/trusted.gpg.d/

[Adam D. Barratt]

On Tue, 2017-05-02 at 18:06 -0400, Daniel Kahn Gillmor wrote:
> On Tue 2017-05-02 21:48:35 +0100, Adam D. Barratt wrote:
> > It's quite late in the day to be making larger-scale changes to the
> > package.
> 
> agreed, in terms of stretch.
> 
> > To clarify, are you suggesting shipping the separated files
> > in /u/s/keyrings /as well as/ /etc/apt/trusted.gpg.d, or /instead of/
> > the existing location?
> 
> for stretch, i think it'd need to be *as well as*, just because i don't
> want to break existing usage.

Apologies for taking a little while to get back to you again.

After a little discussion during last night's team meeting, I'm afraid
that the consensus appears to be that at this stage of the freeze we
shouldn't be making changes that aren't directly related to updating the
set of trusted keys.

Regards,

Adam

Bug#863359: emacs25-common-non-dfsg: does not update the info dir file

[Francesco Potortì]

Package: emacs25-common-non-dfsg
Version: 25.1+1-1
Severity: normal

I have both emacs22 and emacs25 installed on my system.  I also have
emacs22-common-non-dfsg and emacs25-common-non-dfsg.  When installing
the second package, the /usr/share/info/dir file gets updated, but it
keeps pointing to the emacs22 info files

However, /etc/alternatives/emacs.info.gz points to
/usr/share/info/emacs-25/emacs.info.gz


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-proposed-updates'), (101, 
'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages emacs25-common-non-dfsg depends on:
ii  dpkg  1.18.24
ii  install-info  6.3.0.dfsg.1-1+b2

emacs25-common-non-dfsg recommends no packages.

emacs25-common-non-dfsg suggests no packages.

-- no debconf information

Bug#863358: RFA: amazon-s2n -- implementation of TLS protocols

[Daniel Stender]

Package: wnpp
Severity: normal

Heya, I'm requesting an adopter for the amazon-s2n package [1]. That's a C 
implementation
of TLS protocols. A package prototype is in experimental, I haven't no time to 
develop that
any further. If you want to take charge, please proceed without reconfirmation.

Best,
DS

[1] https://packages.qa.debian.org/a/amazon-s2n.html

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
http://www.danielstender.com/



signature.asc
Description: OpenPGP digital signature

Bug#863303: debian-archive-keyring: please remove old 6.0/squeeze key

[Adam D. Barratt]

On Thu, 2017-05-25 at 10:01 +0200, Ansgar Burchardt wrote:
> Please remove the old "6.0/squeeze" automatic signing key and the
> squeeze release key from the active keys in
> /usr/share/keyrings/debian-archive-keyring.gpg:

ACK. Had already planned to do so, but now I have a bug number to close
in the changelog. :-)

Regards,

Adam

Bug#851385: need to shed big-endian B-Dependencies?

[Adam Borowski]

Hi!
It looks like fixing this FTBFS isn't viewed as high priority. 
Understandably, as big endian is basically dead: in Debian, only release
archs left are mips and s390x; the former seems to be on its way out (in
favour of mips64el), the latter has no graphical hardware whatsoever.

There's no rush for Stretch (1.20-1 is fine); if you'd want to RM big endian
binaries for Buster, the only concern are other packages Depending and
Build-Depending on advancecomp.  Of those, the only arch:any one is crawl
which I co-maintain.  As that package is split with images in an arch:all
binary, having images unoptimized or optimized with a worse alternative such
as optipng when built on big endian is perfectly acceptable (only unofficial
builds would be ever affected...).

Thus, if you plan to resort to dropping big endian support, just give me a
word.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Bug#863356: RM: wicd-kde -- ROM; Depends on KDE Plasma 4

[Salvo Tomaselli]

Package: ftp.debian.org
Severity: normal

I am not the maintainer of the package, but I have contributed to wicd before.

wicd-kde is a wicd client for KDE, but no longer works on plasma 5. It would
require some porting work,

There has been an RC bug open for over 2 years #793796 on the package, that 
hasn't
seen any activity from the maintainer.

I think the package should be removed.

Best

Bug#793796: This package should be removed

[Salvo Tomaselli]

It's not compatible with plasma5, it would need porting.

The maintainer doesn't seem active and only has this one
package.

Bug#863355: RFA: citeproc-py -- Citation Style Processor (CSL) for Python

[Daniel Stender]

Package: wnpp
Severity: normal

I request an adopter for the citeproc-py [1] package.

Thanks,
DS

[1] https://packages.qa.debian.org/c/citeproc-py.html

-- 
4096R/DF5182C8
Debian Developer (sten...@debian.org)
http://www.danielstender.com/



signature.asc
Description: OpenPGP digital signature

Bug#863354: ITP: autoforwardportergit -- Tool for automatically merging local changes with new distro packages.

[plugwash]

Package: wnpp
Severity: wishlist
Owner: plugwash 

* Package name: autoforwardportergit
  Version : 0.1
  Upstream Author : Peter Michael Green 
* URL : http://github.com/plugwash/autoforwardportergit/
* License : (MIT)
  Programming Lang: (Python3 and bash)
  Description : Tool for automatically merging local changes with new 
distro packages.

Often there is a need to maintain downstream changes to a package with a new 
version from the upstream
distro. Doing this manually is not difficult but it gets to be a PITA for more 
than a handful of
packages.

autoforwardportergit and the related tool dscdirtogit (which I intend to 
package as part of the same
source) are built to automate this process.

reprepro is used to create a local repo with both upstream and downstream 
versions of the packages.

dscdirtogit takes existing dscs (both upstream and downstream) and uses dgit to 
import them into a
git repo for each package. It uses the changelogs to determine the shape of the 
history. 

The actual autoforwardporter looks at package lists to determine when a merge 
is needed. The initial
merge is performed with git and then a series of "fixers" fixup the changelog 
and other common
conflicts. If the conflicts are fixed successfully dgit will be used to build a 
source package and
then sbuild will be used to build the package. 

If the conflicts are not fixed successfully the code complete with conflict 
markers will be committed
to a "working" branch so that a human can pick up where the automation left off.

The code currently works fine but before packaging I will need to move 
raspbian-specific assumptions
into a configuration file and move to a fhs-compliant file layout. I hope to 
work on this while at
Debconf.

Bug#863353: dgit: commit checks still too strict

[peter green]

Package: dgit
Version: 3.10~bpo8+1

Some time ago dgit was creating commits where the "Author:" field was missing. 
These commits were considered invalid by github and by git fsck.

To prevent the bad commits spreading dgit-repos-server put a commit checker in place. 
However this check was rather strict, it didn't just check if the "Author:" 
field was present, it also checked if subfields of it was non-empty.

Unfortunately this lead to dgit-repos-server rejecting commits that are present 
in upstream git repos and considered acceptable by major hosting services. The 
first case I ran into was a commit with an author email but no name ( 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=851716 ) dgit was modified to 
accept that . Now I have come across the opposite, a commit with a name but no 
email.

The commit in question is 66c65d90db1004356281db6ead988e2e38ba9e37 it can be 
obtained by cloning https://github.com/torvalds/linux.git

Bug#863250: fwupd: newer upstream version (0.9.2) available

[Mario.Limonciello]

> -Original Message-
> From: Iain Lane [mailto:i...@orangesquash.org.uk]
> Sent: Wednesday, May 24, 2017 11:46 AM
> To: Limonciello, Mario ; 863...@bugs.debian.org
> Cc: m...@debian.org; c.schoen...@t-online.de; sub...@bugs.debian.org
> Subject: Re: Bug#863250: fwupd: newer upstream version (0.9.2) available
> 
> On Wed, May 24, 2017 at 01:21:53PM +, mario.limoncie...@dell.com wrote:
> > 0.9.x has changed the build system significantly and there should be 
> > expected
> regressions that are still being shaken out.
> >
> > I've updated the debian-next git packaging branch to 0.9.2.
> > https://anonscm.debian.org/cgit/uefi/fwupd.git/log/?h=debian-next
> >
> > If you would like to help @hughsie in validation of 0.9.2 with some Logitech
> devices as a result of that blog post, that will build against unstable.
> 
> I've just uploaded polkits which include the .its and .loc files to sid
> and exp, so you can revert fd6e03bdb693a2b86a54f35238a74fc7ee97fec2 now
> and Build-Depend on policykit-1 (>> 0.105-17) instead.
> 
> Is there any chance you can upload this to experimental for ease of
> testing? I was thinking about syncing it to Ubuntu if you do that - we
> should be early enough in the cycle for it. There are some bugs fixed on
> upstream/master also.
> 
> Cheers,
> 
> --
> Iain Lane  [ i...@orangesquash.org.uk ]
> Debian Developer   [ la...@debian.org ]
> Ubuntu Developer   [ la...@ubuntu.com ]
@laney,

I ripped out that patch and build depended upon the new polkit [1], uploaded to 
experimental but build still fails.

"msgfmt: cannot locate ITS rules for 
../../policy/org.freedesktop.fwupd.policy.in" [2]

Did I do something wrong?

I don't have an experimental pbuilder set up, so I'm not able to easily debug 
at this moment.

[1] 
https://anonscm.debian.org/cgit/uefi/fwupd.git/commit/?h=debian-next=cc3bf83952aa68f6a4c26d14844b3fe45920f53b
[2] 
https://buildd.debian.org/status/fetch.php?pkg=fwupd=amd64=0.9.2-2=1495733744=0

Bug#838771: RFA: l2tpns

[Samuel Thibault]

Hello,

Fernando Alves, on dim. 15 janv. 2017 15:23:45 +0100, wrote:
> On Sat, 24 Sep 2016 17:22:38 +0100 Jonathan McDowell [1]
> wrote:
> > It would be best if someone actually using this package could take over
> > its maintenance. If it would help I'm prepared to sponsor an initial set
> > of uploads for anyone who would like to do so but is not currently a DM
> > or DD.
> 
> how do we upload the package in the upstream debain ?

The idea of sponsoring is for instance that there is a shared repository
to which you commit the changes, and when you're happy you ask the
sponsor to make the upload for you. That can be Jonathan or me, or any
other DD interested in helping this package.

Samuel

Bug#863224: acl2: build fails on mips (mips-aql-05)

[Camm Maguire]

Greetings, and thanks for your report!

How much memory is on the build machine?

Please note mipsel builds fine.  The log you report seems to indicate a
very tight build space and endless garbage collection.

Take care,

Héctor Orón Martínez  writes:

> Source: acl2
> Version: 7.4dfsg-1
> Severity: important
>
> Dear Maintainer,
>
>* What led up to the situation?
>  Building acl2_7.4dfsg-1 on mips architecture official buildd
> (mips-aql-05), the build was running since May 10th, 2017 until May
> 23rd, 2017; a build job named `saved_acl2' was taking about 100% of
> cputime and spinning in loops.
>
>* What exactly did you do (or not do) that was effective (or ineffective)?
>  I have killed the build for acl2 at that build daemon, and
> started one more build at mips-manda-01, however if the builds fails
> again I'll raise severity of this issue to RC.
>
>* What was the outcome of this action?
>  If the builds fails again I'll raise severity of this issue to RC.
>
>* What outcome did you expect instead?
>  If you could please verify the build in mips porterbox, that
> should help to find the root cause.
>
>   In the test.log file, I found a glitch, note I killed saved_acl2 job
> and then build proceeded until I killed it.
>
> Built /build/acl2-Pf0SA7/acl2-7.4dfsg/books/rtl/rel9/support/lib1/rtl.cert
> (55.567s)
> -rw-rw-r-- 1 buildd buildd 36449 May 12 03:20 rtl.cert
> ls: cannot access 'edgesynth.cert': No such file or directory
> **CERTIFICATION FAILED** for
> /build/acl2-Pf0SA7/acl2-7.4dfsg/books/centaur/vl2014/transforms/always/edgesynth.lisp
>
>| [GC for 33 RELOCATABLE-BLOCKS pages..(T=446).GC finished]
>| Toggling relblock when resizing hole to 20
>| [GC for 33 RELOCATABLE-BLOCKS pages..(T=448).GC finished]
>| Toggling relblock when resizing hole to 20
>| [GC for 33 RELOCATABLE-BLOCKS pages..(T=446).GC finished]
>| Toggling relblock when resizing hole to 20
> [...]
>| Toggling relblock when resizing hole to 20
>| [GC for 33 RELOCATABLE-BLOCKS pages..Exit code from ACL2 is 137
>| edgesynth.cert seems to be missing
>
>
> **CERTIFICATION FAILED** for
> /build/acl2-Pf0SA7/acl2-7.4dfsg/books/centaur/vl2014/transforms/always/edgesynth.lisp
>
> /build/acl2-Pf0SA7/acl2-7.4dfsg/books/build/make_cert:116: recipe for
> target 'centaur/vl2014/transforms/always/edgesynth.cert' failed
> make[2]: *** [centaur/vl2014/transforms/always/edgesynth.cert] Error 1
> Making /build/acl2-Pf0SA7/acl2-7.4dfsg/books/coi/gacc/bits.cert on
> 23-May-2017 21:39:48
> Making /build/acl2-Pf0SA7/acl2-7.4dfsg/books/rtl/rel9/support/lib1/basic.cert
> on 23-May-2017 21:39:48
> Built /build/acl2-Pf0SA7/acl2-7.4dfsg/books/coi/gacc/bits.cert (21.785s)
>
>
>   Find attached a list of running processes for your build as well as test.log
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
> Architecture: amd64
>  (x86_64)
>
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=ca_AD.UTF-8, LC_CTYPE=ca_AD.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)

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

Bug#716982: also in 3.0.2

[Geert Stappers]

While building  tellico 3.0.2  I encountered this bug also


I choosed for doing

--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -39,7 +39,7 @@ option(ENABLE_AMAZON   "Enable Amazon.com searching" TRUE)
 option(ENABLE_IMDB "Enable IMDb searching" TRUE)
 option(ENABLE_CDTEXT   "Enable cdtext" TRUE)
 option(ENABLE_WEBCAM   "Enable support for webcams" FALSE)
-option(BUILD_TESTS "Build the tests" TRUE)
+option(BUILD_TESTS "Build the tests" FALSE)
 option(BUILD_FETCHER_TESTS "Build tests which verify data sources" FALSE)
 
 include(CheckSymbolExists)

 

Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#863352: jessie-pu: package lasso/2.4.1-1+deb8u1

[Adrian Bunk]

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


 changelog|9 +++
 patches/0001-perl-remove-quotes-from-PERL-V-ccflags-output.patch |   25 
++
 patches/series   |1 
 3 files changed, 35 insertions(+)

diff -Nru lasso-2.4.1/debian/changelog lasso-2.4.1/debian/changelog
--- lasso-2.4.1/debian/changelog2014-08-28 18:48:58.0 +0300
+++ lasso-2.4.1/debian/changelog2017-05-25 20:03:22.0 +0300
@@ -1,3 +1,12 @@
+lasso (2.4.1-1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Frederic Peters to make sure to remove quotes
+given by "perl -V::ccflags:" as they broke Lasso on 32bit
+architectures. (Closes: #809759)
+
+ -- Adrian Bunk   Thu, 25 May 2017 19:40:08 +0300
+
 lasso (2.4.1-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru 
lasso-2.4.1/debian/patches/0001-perl-remove-quotes-from-PERL-V-ccflags-output.patch
 
lasso-2.4.1/debian/patches/0001-perl-remove-quotes-from-PERL-V-ccflags-output.patch
--- 
lasso-2.4.1/debian/patches/0001-perl-remove-quotes-from-PERL-V-ccflags-output.patch
 1970-01-01 02:00:00.0 +0200
+++ 
lasso-2.4.1/debian/patches/0001-perl-remove-quotes-from-PERL-V-ccflags-output.patch
 2017-05-25 20:03:23.0 +0300
@@ -0,0 +1,25 @@
+From 5e26495b8801e347edf70a567d36b0423542c552 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20P=C3=A9ters?= 
+Date: Mon, 11 Jan 2016 09:15:27 +0100
+Subject: [PATCH] perl: remove quotes from $PERL -V::ccflags: output
+
+---
+ configure.ac | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/configure.ac b/configure.ac
+index 7a1a6ce..3e8d325 100644
+--- a/configure.ac
 b/configure.ac
+@@ -531,7 +531,7 @@ AC_ARG_ENABLE(perl, [  --disable-perl  disable the 
Perl binding],,
+ if test "X$PERL" != "X"; then
+   PERLINSTALLSITEARCH=`$PERL -MConfig -e 'print $Config{installsitearch};'`
+   PERLMAN3DIR=`$PERL -MConfig -e 'print $Config{man3dir};'`
+-  PERL_CFLAGS=$($PERL -V::ccflags:)
++  PERL_CFLAGS=$($PERL -V::ccflags: | tr -d "'")
+ else
+   PERLINSTALLSITEARCH=none
+   PERLMAN3DIR=none
+-- 
+2.7.0.rc3
+
diff -Nru lasso-2.4.1/debian/patches/series lasso-2.4.1/debian/patches/series
--- lasso-2.4.1/debian/patches/series   2014-08-28 18:48:18.0 +0300
+++ lasso-2.4.1/debian/patches/series   2017-05-25 20:03:23.0 +0300
@@ -1 +1,2 @@
 Use-INSTALLDIRS-vendor-for-the-Perl-bindings-as-per-.patch
+0001-perl-remove-quotes-from-PERL-V-ccflags-output.patch

Bug#828159: iceweasel -> firefox-esr upgrades won't be relevant for buster

[Adrian Bunk]

tags 828159 wheezy jessie stretch
thanks

iceweasel -> firefox-esr upgrades won't be relevant for buster since
iceweasel won't ever be in post-release stretch.

cu
Adrian

-- 

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

Bug#863351: unblock: openvpn/2.4.0-6

[Alberto Gonzalez Iniesta]

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

Please unblock package openvpn

I've been contacted by a big Debian & OpenVPN user about a bug present
in Stretch's OpenVPN version and fixed 2 minor reviews later. The bug
was reported upstream [1] and results in clients not able to use the VPN
after several reconnects.

The patch seems nice and clear [2] (and applies cleanly). The bug
impact could be substantial.

The fixed package (2.4.0-6) has been tested by the forementioned user
(that could reproduce the bug in previous versions).

[1] https://community.openvpn.net/openvpn/ticket/879
[2]
https://community.openvpn.net/openvpn/changeset/03d01f4f69cfc6768343b9f0f2dde2049e4882d2/

unblock openvpn/2.4.0-6

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

Kernel: Linux 4.9.0-2-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)
diff -Nru openvpn-2.4.0/debian/changelog openvpn-2.4.0/debian/changelog
--- openvpn-2.4.0/debian/changelog  2017-05-11 14:15:21.0 +0200
+++ openvpn-2.4.0/debian/changelog  2017-05-22 14:59:49.0 +0200
@@ -1,3 +1,10 @@
+openvpn (2.4.0-6) unstable; urgency=medium
+
+  * Apply upstream patch to fix shrinking MTU sizes on reconnects causing not
+usable VPN tunnels.
+
+ -- Alberto Gonzalez Iniesta   Mon, 22 May 2017 14:59:49 
+0200
+
 openvpn (2.4.0-5) unstable; urgency=high
 
   * Change typo fix in command line help.
diff -Nru openvpn-2.4.0/debian/patches/series 
openvpn-2.4.0/debian/patches/series
--- openvpn-2.4.0/debian/patches/series 2017-05-11 14:15:21.0 +0200
+++ openvpn-2.4.0/debian/patches/series 2017-05-22 14:57:31.0 +0200
@@ -7,3 +7,4 @@
 CVE-2017-7479-prereq.patch
 CVE-2017-7479.patch
 wipe_tokens_on_de-auth.patch
+upstream-issue-879.patch
diff -Nru openvpn-2.4.0/debian/patches/upstream-issue-879.patch 
openvpn-2.4.0/debian/patches/upstream-issue-879.patch
--- openvpn-2.4.0/debian/patches/upstream-issue-879.patch   1970-01-01 
01:00:00.0 +0100
+++ openvpn-2.4.0/debian/patches/upstream-issue-879.patch   2017-05-22 
14:59:14.0 +0200
@@ -0,0 +1,87 @@
+Index: openvpn/src/openvpn/forward.c
+===
+--- openvpn.orig/src/openvpn/forward.c 2017-05-22 14:59:09.634938195 +0200
 openvpn/src/openvpn/forward.c  2017-05-22 14:59:09.630937170 +0200
+@@ -866,9 +866,16 @@
+  * will load crypto_options with the correct encryption key
+  * and return false.
+  */
++uint8_t opcode = *BPTR(>c2.buf) >> P_OPCODE_SHIFT;
+ if (tls_pre_decrypt(c->c2.tls_multi, >c2.from, >c2.buf, ,
+ floated, _start))
+ {
++/* Restore pre-NCP frame parameters */
++if (is_hard_reset(opcode, c->options.key_method))
++{
++c->c2.frame = c->c2.frame_initial;
++}
++
+ interval_action(>c2.tmp_int);
+ 
+ /* reset packet received timer if TLS packet */
+Index: openvpn/src/openvpn/init.c
+===
+--- openvpn.orig/src/openvpn/init.c2017-05-22 14:59:09.634938195 +0200
 openvpn/src/openvpn/init.c 2017-05-22 14:59:09.634938195 +0200
+@@ -4055,6 +4055,8 @@
+ c->c2.did_open_tun = do_open_tun(c);
+ }
+ 
++c->c2.frame_initial = c->c2.frame;
++
+ /* print MTU info */
+ do_print_data_channel_mtu_parms(c);
+ 
+Index: openvpn/src/openvpn/openvpn.h
+===
+--- openvpn.orig/src/openvpn/openvpn.h 2017-05-22 14:59:09.634938195 +0200
 openvpn/src/openvpn/openvpn.h  2017-05-22 14:59:09.634938195 +0200
+@@ -263,7 +263,8 @@
+ struct link_socket_actual from; /* address of incoming 
datagram */
+ 
+ /* MTU frame parameters */
+-struct frame frame;
++struct frame frame; /* Active frame parameters */
++struct frame frame_initial; /* Restored on new session */
+ 
+ #ifdef ENABLE_FRAGMENT
+ /* Object to handle advanced MTU negotiation and datagram fragmentation */
+Index: openvpn/src/openvpn/ssl.c
+===
+--- openvpn.orig/src/openvpn/ssl.c 2017-05-22 14:59:09.634938195 +0200
 openvpn/src/openvpn/ssl.c  2017-05-22 14:59:09.634938195 +0200
+@@ -830,14 +830,7 @@
+ return BSTR();
+ }
+ 
+-/*
+- * Given a key_method, return true if op
+- * represents the required form of hard_reset.
+- *
+- * If key_method = 0, return true if any
+- * form of hard reset is used.
+- */
+-static bool
++bool
+ 

Bug#863291: libscalapack-openmpi1: memory leak in pXgemr2d

[Grigory Kolesov]

Dear Muammar,

> It could be that the actual leak is in OpenMPI, but somehow it triggered
> only by pXgemr2d.

I apologize for blaming Scalapack/pXgemr2d, a little more
investigation showed  that the  bug does seem to be in OpenMPI.

In short, recompiling Scalapack doesn't help, recompiling/upgrading to
the newest version 2.1.1  of OpenMPI doesn't help, but downgrading
OpenMPI to 2.0.1 fixes the issue.


Best regards,
Grigory

Bug#861282: packer: FTBFS

[JD Friedrikson]

> 
> Thanks for your info!
> I pushed a commit to new branch fix_861282, that applied:
> ee5d13611fb8aca1f1014f9bcd65c18fffdd1b2b
> a0052fdb687f80ac07e67d7a0f39dcf3a66e32dd
> 
> (https://anonscm.debian.org/cgit/pkg-go/packages/packer.git/log/?h=fix_861282)
> 
> Please help to test whether it fixes your problem.
> 
> Cheers,
> --
> Roger Shimizu, GMT +9 Tokyo
> PGP/GPG: 4096R/6C6ACD6417B3ACB1
> 

The new changes package nicely and pass the tests just fine. I can confirm that 
the fix works for qemu. I'm having some issues with Virtualbox, but I've also 
always had trouble with Virtualbox and packer with the machine; the binary I've 
compiled straight from Packer's git project also fails in the same way so it's 
probably not related.

Can someone step in and confirm that the new patches work with Virtualbox?

Thanks,
JD

Bug#863348: dput: please use ftp.security.upload.debian.org for security uploads

[Ansgar Burchardt]

Package: dput
Version: 0.9.6.4
Severity: important

Some time ago we moved the upload queues away from ftp-master.d.o to
ftp.upload.d.o.  This allowed us to no longer run ftpd directly on
ftp-master.

The same will hopefully happen to security-master: eventually
security-master will no longer run a ftpd, but uploads will go via a
separate host.  For this to work, we will need tools to upload to
ftp.security.upload.debian.org (currently an alias for
security-master).

So please update the default dput.cf to upload security uploads to
ftp.security.upload.debian.org instead of directory to
security-master.debian.org.

Ansgar

Bug#863349: dput-ng: please use ftp.security.upload.debian.org for security uploads

[Ansgar Burchardt]

Package: dput-ng
Version: 1.8
Severity: important

Some time ago we moved the upload queues away from ftp-master.d.o to
ftp.upload.d.o.  This allowed us to no longer run ftpd directly on
ftp-master.

The same will hopefully happen to security-master: eventually
security-master will no longer run a ftpd, but uploads will go via a
separate host.  For this to work, we will need tools to upload to
ftp.security.upload.debian.org (currently an alias for
security-master).

So please update the default skel/profiles/security-master.json to
upload security uploads to ftp.security.upload.debian.org instead of
directory to security-master.debian.org.

Ansgar

Bug#863350: dupload: please use ftp.security.upload.debian.org for security uploads

[Ansgar Burchardt]

Package: dupload
Version: 2.8.2

Some time ago we moved the upload queues away from ftp-master.d.o to
ftp.upload.d.o.  This allowed us to no longer run ftpd directly on
ftp-master.

The same will hopefully happen to security-master: eventually
security-master will no longer run a ftpd, but uploads will go via a
separate host.  For this to work, we will need tools to upload to
ftp.security.upload.debian.org (currently an alias for
security-master).

So please update the default dupload.conf to upload security uploads to
ftp.security.upload.debian.org instead of directly to
security-master.debian.org.

Ansgar

Bug#863347: unblock: vlc/2.2.6-1~deb9u1

[Sebastian Ramacher]

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

Please unblock package vlc version 2.2.6-1~deb9u1. It is the latest stable bug
fix release including a fix for CVE-2017-8312.

The upstream changes are attached as vlc-2.2.6.diff (updates to the translations
have been stripped). The changes in debian (vlc-debian.stretch.diff) includes
the usual bump of the versions in *.maintscripts and in Breaks + Repalces. The
Breaks + Replaces from libvlc-bin have been removed as they are not necessary.

unblock vlc/2.2.6-1~deb9u1

Cheers
-- 
Sebastian Ramacher
diff --git a/NEWS b/NEWS
index 4c34a5d8..88321824 100644
--- a/NEWS
+++ b/NEWS
@@ -1,5 +1,15 @@
+Changes between 2.2.5.1 and 2.2.6:
+--
+
+Video output:
+ * Fix systematic green line on nvidia
+ * Fix direct3d SPU texture offsets handling
+
+Demuxer:
+ * Fix heap buffer overflows
+
 Changes between 2.2.5 and 2.2.5.1:
-
+--
 
 Security hardening for DLL hijacking environments
 
diff --git a/configure b/configure
index 57cbc4d5..c0ce4fb4 100755
--- a/configure
+++ b/configure
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for vlc 2.2.5.1.
+# Generated by GNU Autoconf 2.69 for vlc 2.2.6.
 #
 # Copyright 1999-2017 VLC authors and VideoLAN
 #
@@ -589,8 +589,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='vlc'
 PACKAGE_TARNAME='vlc'
-PACKAGE_VERSION='2.2.5.1'
-PACKAGE_STRING='vlc 2.2.5.1'
+PACKAGE_VERSION='2.2.6'
+PACKAGE_STRING='vlc 2.2.6'
 PACKAGE_BUGREPORT=''
 PACKAGE_URL=''
 
@@ -2532,7 +2532,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures vlc 2.2.5.1 to adapt to many kinds of systems.
+\`configure' configures vlc 2.2.6 to adapt to many kinds of systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -2607,7 +2607,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of vlc 2.2.5.1:";;
+ short | recursive ) echo "Configuration of vlc 2.2.6:";;
esac
   cat <<\_ACEOF
 
@@ -3263,7 +3263,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-vlc configure 2.2.5.1
+vlc configure 2.2.6
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -3976,7 +3976,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by vlc $as_me 2.2.5.1, which was
+It was created by vlc $as_me 2.2.6, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -4327,8 +4327,8 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
 VERSION_MAJOR=2
 VERSION_MINOR=2
-VERSION_REVISION=5
-VERSION_EXTRA=1
+VERSION_REVISION=6
+VERSION_EXTRA=0
 VERSION_DEV=
 
 PKGDIR="vlc"
@@ -4931,7 +4931,7 @@ fi
 
 # Define the identity of the package.
  PACKAGE='vlc'
- VERSION='2.2.5.1'
+ VERSION='2.2.6'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -53803,7 +53803,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_write_fail=1
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by vlc $as_me 2.2.5.1, which was
+This file was extended by vlc $as_me 2.2.6, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -53869,7 +53869,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-vlc config.status 2.2.5.1
+vlc config.status 2.2.6
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
diff --git a/configure.ac b/configure.ac
index d3f8685d..235edf57 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2,11 +2,11 @@ dnl Autoconf settings for vlc
 
 AC_COPYRIGHT([Copyright 1999-2017 VLC authors and VideoLAN])
 
-AC_INIT(vlc, 2.2.5.1)
+AC_INIT(vlc, 2.2.6)
 VERSION_MAJOR=2
 VERSION_MINOR=2
-VERSION_REVISION=5
-VERSION_EXTRA=1
+VERSION_REVISION=6
+VERSION_EXTRA=0
 VERSION_DEV=
 
 PKGDIR="vlc"
diff --git a/modules/demux/subtitle.c b/modules/demux/subtitle.c
index 1614e860..9f0b953e 100644
--- a/modules/demux/subtitle.c
+++ b/modules/demux/subtitle.c
@@ -2,7 +2,7 @@
  * subtitle.c: Demux for subtitle text files.
  *
  * Copyright (C) 1999-2007 VLC authors and VideoLAN
- * $Id: 3e790fd307ff08f92fd3b754863f7a91f34fd85f $
+ * $Id: c4402edfb9b9c02121b7037c4ae907a9eb914439 $
  *
  * Authors: Laurent Aimar 
  *  Derk-Jan Hartman 
@@ -1667,7 +1667,7 @@ static int ParseJSS( demux_t 

Bug#792552: still doesn't continue shutdown process

[Pali Rohár]

Same problem there. I have up-to-date Debian Stretch with LUKS-encrypted 
rootfs and system hangup on every shutdown or reboot.

I debugged this problem and found out that after this log message

[] Stopping remaining crypto disks...

is called cryptsetup luksClose  And cryptsetup itself freeze.

When I patched init script to call cryptsetup with -v --debug args I see 
there these last lines:

# Udev cookie 0x (semid ) decremented to 1
# Udev cookie 0x (semid ) waiting for zero

So it looks like problem is in cryptsetup and bug is still there!

-- 
Pali Rohár
pali.ro...@gmail.com


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

Bug#861591: libgnupg-interface-perl: FTBFS: Failed 10/22 test programs. 23/53 subtests failed.

[Chris Lamb]

Daniel Kahn Gillmor wrote:

> The failures on repeat are presumably because of something related to
> the gpg-agent daemon persisting across the tests.I'll look into
> invoking "gpgconf --kill all" at the start of the test suite

Is that safe? What if I'm running gpgconf outside of the build? :)


Regards,

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

Bug#863346: jessie-pu: package libsx/2.05-6+deb8u1

[Adrian Bunk]

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


 changelog|9 +
 libsx-dev.install|5 -
 libsx-dev.install.in |5 +
 libsx.pc |   10 ++
 libsx.pc.in  |   10 --
 rules|7 ++-
 6 files changed, 30 insertions(+), 16 deletions(-)

diff -Nru libsx-2.05/debian/changelog libsx-2.05/debian/changelog
--- libsx-2.05/debian/changelog 2014-09-13 16:46:07.0 +0300
+++ libsx-2.05/debian/changelog 2017-05-25 19:30:28.0 +0300
@@ -1,3 +1,12 @@
+libsx (2.05-6+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Apply changes from Alastair McKinstry to ship libsx.h, libsx.pc,
+libsx.a and the HTML documentation in libsx-dev and the dialogs
+to libsx0. (Closes: #856725)
+
+ -- Adrian Bunk   Thu, 25 May 2017 19:19:58 +0300
+
 libsx (2.05-6) unstable; urgency=medium
 
   * Apply patch from Alexander to fix clang compilation. Closes: #758760. 
diff -Nru libsx-2.05/debian/libsx-dev.install 
libsx-2.05/debian/libsx-dev.install
--- libsx-2.05/debian/libsx-dev.install 2014-09-13 16:46:07.0 +0300
+++ libsx-2.05/debian/libsx-dev.install 1970-01-01 02:00:00.0 +0200
@@ -1,5 +0,0 @@
-src/libsx.husr/include
-src/libsx.ausr/lib/*
-docs/html/*usr/share/doc/libsx-dev/html
-docs/text/*usr/share/doc/libsx-dev/text
-debian/libsx.pcusr/lib/*/pkgconfig
diff -Nru libsx-2.05/debian/libsx-dev.install.in 
libsx-2.05/debian/libsx-dev.install.in
--- libsx-2.05/debian/libsx-dev.install.in  1970-01-01 02:00:00.0 
+0200
+++ libsx-2.05/debian/libsx-dev.install.in  2017-05-25 19:21:25.0 
+0300
@@ -0,0 +1,5 @@
+src/libsx.husr/include
+src/libsx.ausr/lib/@ARCH@
+docs/html/*usr/share/doc/libsx-dev/html
+docs/text/*usr/share/doc/libsx-dev/text
+debian/libsx.pcusr/lib/@ARCH@/pkgconfig
diff -Nru libsx-2.05/debian/libsx.pc libsx-2.05/debian/libsx.pc
--- libsx-2.05/debian/libsx.pc  1970-01-01 02:00:00.0 +0200
+++ libsx-2.05/debian/libsx.pc  2017-05-25 19:21:25.0 +0300
@@ -0,0 +1,10 @@
+prefix=/usr
+exec_prefix=${prefix}
+libdir=${exec_prefix}/lib
+
+Name: libsx 
+Description: Simple X library
+Version: 2.05
+Libs:  -L${libdir} -lsx
+Requires.private: xt xmu xpm xaw7
+Libs.private: -$L{libdir} -lsx -lX11 -lXpm -Xaw -Xmu
diff -Nru libsx-2.05/debian/libsx.pc.in libsx-2.05/debian/libsx.pc.in
--- libsx-2.05/debian/libsx.pc.in   2014-09-13 16:46:07.0 +0300
+++ libsx-2.05/debian/libsx.pc.in   1970-01-01 02:00:00.0 +0200
@@ -1,10 +0,0 @@
-prefix=/usr
-exec_prefix=${prefix}
-libdir=${exec_prefix}/lib
-
-Name: libsx 
-Description: Simple X library
-Version: 2.05
-Libs:  -L${libdir} -lsx
-Requires.private: xt xmu xpm xaw7
-Libs.private: -$L{libdir} -lsx -lX11 -lXpm -Xaw -Xmu
diff -Nru libsx-2.05/debian/rules libsx-2.05/debian/rules
--- libsx-2.05/debian/rules 2014-09-13 16:46:07.0 +0300
+++ libsx-2.05/debian/rules 2017-05-25 19:32:11.0 +0300
@@ -6,6 +6,7 @@
 
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
+AUTOGENERATED:= libsx-dev.install
 
 CFLAGS = `dpkg-buildflags --get CFLAGS`
 CFLAGS += `dpkg-buildflags --get CPPFLAGS`
@@ -15,9 +16,13 @@
dh_installexamples -Xlibsx.h
 
 override_dh_install:
-   dh_auto_install
+   for f in ${AUTOGENERATED} ; do \
+sed -e 's%@ARCH@%${DEB_HOST_MULTIARCH}%g' < debian/$$f.in  > 
debian/$$f ; \
+done
mkdir -p debian/libsx0/$(LIBDIR)
mv src/libsx.so debian/libsx0/$(LIBDIR)/libsx.so.0.0.0
dh_link -p libsx0 $(LIBDIR)/libsx.so.0.0.0  $(LIBDIR)/libsx.so.0
dh_link -p libsx-dev $(LIBDIR)/libsx.so.0.0.0 $(LIBDIR)/libsx.so
+   dh_install 
+   dh_auto_install
  

Bug#861591: libgnupg-interface-perl: FTBFS: Failed 10/22 test programs. 23/53 subtests failed.

[Daniel Kahn Gillmor]

On Mon 2017-05-01 10:11:51 +0200, Salvatore Bonaccorso wrote:
>> HOME=/home/lamby
>> LOGNAME=lamby
>> SHLVL=1
>> PWD=/home/lamby/temp/cdt.20170430222311.WuN76MAfhh.db.libgnupg-interface-perl/libgnupg-interface-perl-0.52
>> OLDPWD=/home/lamby/temp/cdt.20170430222311.WuN76MAfhh.db.libgnupg-interface-perl
>
> I think that's only indirectly a problem by libgnupg-interface-perl.
> The testsuite relies on creating a new GNUPGHOME, and to be on the
> safe side, this is done below the test directory with a fresh
> directory.
>
> Now for gnupg the following caused the failures in the testsuite:
>
> https://lists.gnupg.org/pipermail/gnupg-users/2017-January/057444.html
>
> I'm CC'ing for comment Daniel, who writed the patch to generalize the
> testsuite, so it works with GnuPG 2.1 as well.

Looking into this with libgnupg-interface-perl 0.52-6 (experimental), i
can confirm that i've seen this problem, specifically when trying to run
the test suite twice.  When running the test suite exactly once it seems
to work out fine, even on paths that are insanely long.  I've tested
this with both GnuPG 2.1.18-8 (unstable) and 2.1.21-2 (experimental).

The failures on repeat are presumably because of something related to
the gpg-agent daemon persisting across the tests.I'll look into
invoking "gpgconf --kill all" at the start of the test suite to see
whether that can resolve the issue.

--dkg


signature.asc
Description: PGP signature

Bug#863345: fonts-lohit-beng-assamese: New upstream release 2.91.5

[Jeremy Bicha]

Package: fonts-lohit-beng-assaemese
Version: 2.5.3-1
Severity: wishlist
Tags: +patch

There are new versions of the Lohit fonts available.

fedorahosted.org has been discontinued so the fonts are now maintained
at https://github.com/pravins/lohit/ with tarballs at
https://releases.pagure.org/lohit/

I have prepared packaging for Lohit Assamese at
https://anonscm.debian.org/git/users/jbicha-guest/fonts-lohit-beng-assamese.git/

https://anonscm.debian.org/git/users/jbicha-guest/fonts-lohit-beng-assamese.git/tree/ChangeLog

Thanks,
Jeremy Bicha

Bug#863344: linux-image-4.9.0-3-arm64: qOAarm64 kernel missing some DRM modules

[Pawel Moll]

Package: src:linux
Version: 4.9.25-1
Severity: normal

Hello,

The arm64 kernel appears missing a couple of DRM modules in the configuration:

# CONFIG_DRM_HDLCD is not set
# CONFIG_DRM_MALI_DISPLAY is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set

Considering the fact that at least DRM_RADEON and and DRM_AMDGPU are enabled
on other architectures and from the fact that things like DRM_NOUVEAU and
DRM_AST are enabled, it seems like a simple ommision.

For me it's the RADEON and AMDGPU that are really important - I'm building
arm64 desktop workstations with AMD graphics cards and have to install custom
kernel before delivering the machines to users.

-- Package-specific info:
** Version:
Linux version 4.9.0-3-arm64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170415 (Debian 6.3.0-14) ) #1 SMP Debian 4.9.25-1 (2017-05-02)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-3-arm64 root=/dev/mapper/arm64debianvm--vg-root ro 
quiet

** Not tainted

** Kernel log:
[0.061957] Unpacking initramfs...
[0.506649] Freeing initrd memory: 17812K (8f33b000 - 
8000104a)
[0.506961] hw perfevents: enabled with armv8_pmuv3 PMU driver, 7 counters 
available
[0.506989] kvm [1]: HYP mode not available
[0.508235] audit: initializing netlink subsys (disabled)
[0.508266] audit: type=2000 audit(0.476:1): initialized
[0.508578] workingset: timestamp_bits=46 max_order=17 bucket_order=0
[0.508612] zbud: loaded
[0.509438] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 
249)
[0.509475] io scheduler noop registered
[0.509477] io scheduler deadline registered
[0.509490] io scheduler cfq registered (default)
[0.510472] pl061_gpio 903.pl061: PL061 GPIO chip @0x0903 
registered
[0.510627] OF: PCI: host bridge /pcie@1000 ranges:
[0.510636] OF: PCI:IO 0x3eff..0x3eff -> 0x
[0.510640] OF: PCI:   MEM 0x1000..0x3efe -> 0x1000
[0.510643] OF: PCI:   MEM 0x80..0xff -> 0x80
[0.510659] pci-host-generic 3f00.pcie: ECAM at [mem 
0x3f00-0x3fff] for [bus 00-0f]
[0.510723] pci-host-generic 3f00.pcie: PCI host bridge to bus :00
[0.510726] pci_bus :00: root bus resource [bus 00-0f]
[0.510729] pci_bus :00: root bus resource [io  0x-0x]
[0.510731] pci_bus :00: root bus resource [mem 0x1000-0x3efe]
[0.510733] pci_bus :00: root bus resource [mem 
0x80-0xff]
[0.510770] pci :00:00.0: [1b36:0008] type 00 class 0x06
[0.512091] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[0.512590] Serial: AMBA driver
[0.512665] msm_serial: driver initialized
[0.512717] Unable to detect cache hierarchy from DT for CPU 0
[0.512869] mousedev: PS/2 mouse device common for all mice
[0.513117] rtc-efi rtc-efi: rtc core: registered rtc-efi as rtc0
[0.513459] ledtrig-cpu: registered to indicate activity on CPUs
[0.513754] NET: Registered protocol family 10
[0.514048] mip6: Mobile IPv6
[0.514052] NET: Registered protocol family 17
[0.514057] mpls_gso: MPLS GSO support
[0.514079] Registered cp15_barrier emulation handler
[0.514081] Registered setend emulation handler
[0.514283] registered taskstats version 1
[0.514299] zswap: loaded using pool lzo/zbud
[0.514349] ima: No TPM chip found, activating TPM-bypass!
[0.514471] rtc-efi rtc-efi: setting system clock to 2017-05-25 15:43:37 UTC 
(1495727017)
[0.514559] PM: Hibernation image not present or could not be loaded.
[0.514670] uart-pl011 900.pl011: no DMA platform data
[0.515757] Freeing unused kernel memory: 3392K (8099 - 
80ce)
[0.535987] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[0.536103] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[0.536117] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[0.536134] random: systemd-udevd: uninitialized urandom read (16 bytes read)
[0.537434] random: udevadm: uninitialized urandom read (16 bytes read)
[0.537484] random: udevadm: uninitialized urandom read (16 bytes read)
[0.537704] random: udevadm: uninitialized urandom read (16 bytes read)
[0.537880] random: udevadm: uninitialized urandom read (16 bytes read)
[0.537904] random: udevadm: uninitialized urandom read (16 bytes read)
[0.537997] random: udevadm: uninitialized urandom read (16 bytes read)
[0.649897] SCSI subsystem initialized
[0.654241]  vda: vda1 vda2 vda3
[0.656507] scsi host0: Virtio SCSI HBA
[0.657821] scsi 0:0:0:0: CD-ROMQEMU QEMU CD-ROM  2.5+ 
PQ: 0 ANSI: 5
[0.697050] device-mapper: uevent: version 1.0.3
[0.697742] device-mapper: ioctl: 4.35.0-ioctl (2016-06-23) initialised: 
dm-de...@redhat.com
[0.754968] random: fast init done
[0.793018] sr 0:0:0:0: [sr0] scsi3-mmc 

Bug#863343: nginx-doc: Patch for typos and doc improvements in examples/wordpress

[Larry Holish]

Package: nginx-doc
Version: 1.10.3-1
Severity: minor

Dear Maintainer,

Thanks for you work on this package. Attached is a patchfile for some
small typos, updated link location and minor edits to comments in
examples/wordpress file.

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

Kernel: Linux 4.9.0-3-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)

-- no debconf information

-- 

diff --git a/wordpress.orig b/wordpress.fix
index 6faf918..2d4c0ab 100644
--- a/wordpress.orig
+++ b/wordpress.fix
@@ -34,8 +34,8 @@ server {
 	}
  
 	# This location block protects against a known attack. It happens if
-	# the attacker uploads a non-php file and attempts to run it as a
-	# php file on the server.
+	# the attacker uploads a non-PHP file and attempts to run it as a
+	# PHP file on the server.
 	location ~ \..*/.*\.php$ {
 		return 403;
 	}
@@ -43,7 +43,7 @@ server {
 	# This is our primary location block. The try_files directive will
 	# attempt to serve the data in the order listed. First try the exact
 	# request (such as an image or text file). If it doesn't exist, see if
-	# the directory exists. If not, then we move to the last options which
+	# the directory exists. If not, then we move to the last option which
 	# passes the request to /index.php with the requested query.
 	location / {
 		try_files $uri $uri/ /index.php?q=$uri&$args;
@@ -51,7 +51,7 @@ server {
  
 	# If a PHP file is served, this block will handle the request. This block
 	# works on the assumption you are using php-cgi listening on /tmp/phpcgi.socket.
-	# Please see the php example (usr/share/doc/nginx/exmaples/php) for more
+	# Please see the PHP example (/usr/share/doc/nginx-doc/php) for more
 	# information about setting up PHP.
 	# NOTE: You should have "cgi.fix_pathinfo = 0;" in php.ini
 	location ~ \.php$ {
@@ -61,12 +61,11 @@ server {
 		fastcgi_intercept_errors on;
 		fastcgi_pass unix:/tmp/phpcgi.socket;
 	}
- 
-	# As mentioned above, Nignx is king of static. If we're serving a static
-	# file that ends with one of the following extensions, it is best to set
-	# a very high expires time. This will generate fewer requests for the
-	# file. These requests will be logged if found, but not if they don't
-	# exist.
+
+	# If we're serving a static file that ends with one of the following
+	# extensions, it is best to set a very high expires time. This will
+	# generate fewer requests for the file. These requests will be logged if
+	# found, but not if they don't exist.
 	location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
 		expires max;
 		log_not_found off;

Bug#863342: jessie-pu: package libauthen-krb5-perl/1.9-4+deb8u1

[Adrian Bunk]

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


 changelog  |9 +
 patches/obsolete-krb_get,free_krbhst.patch |   52 +
 patches/series |1 
 3 files changed, 62 insertions(+)

diff -Nru libauthen-krb5-perl-1.9/debian/changelog 
libauthen-krb5-perl-1.9/debian/changelog
--- libauthen-krb5-perl-1.9/debian/changelog2014-03-15 23:43:56.0 
+0200
+++ libauthen-krb5-perl-1.9/debian/changelog2017-05-25 19:01:10.0 
+0300
@@ -1,3 +1,12 @@
+libauthen-krb5-perl (1.9-4+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch from Damyan Ivanov removing references to
+obsolete krb5_{get,free}_krbhst. Thanks to Sergio Gelato.
+(Closes: #830844)
+
+ -- Adrian Bunk   Thu, 25 May 2017 18:59:36 +0300
+
 libauthen-krb5-perl (1.9-4) unstable; urgency=low
 
   * Team upload
diff -Nru 
libauthen-krb5-perl-1.9/debian/patches/obsolete-krb_get,free_krbhst.patch 
libauthen-krb5-perl-1.9/debian/patches/obsolete-krb_get,free_krbhst.patch
--- libauthen-krb5-perl-1.9/debian/patches/obsolete-krb_get,free_krbhst.patch   
1970-01-01 02:00:00.0 +0200
+++ libauthen-krb5-perl-1.9/debian/patches/obsolete-krb_get,free_krbhst.patch   
2017-05-25 18:59:07.0 +0300
@@ -0,0 +1,52 @@
+Description: remove references to obsolete krb5_{get,free}_krbhst
+ These routines were internal and are removed from krb5.
+ They aren't used anyway and only cause module load failures when
+ PERL_DL_NONLAZY is set.
+ Thanks to Sergio Gelato
+ https://codesearch.debian.net/search?q=krb5_get_krbhst shows no relevant usage
+Bug-Debian: https://bugs.debian.org/830844
+Bug: https://rt.cpan.org/Ticket/Display.html?id=116071
+--- a/Krb5.xs
 b/Krb5.xs
+@@ -47,14 +47,6 @@ static krb5_error_code err;
+ static krb5_keytab_entry keytab_entry_init;
+ 
+ /*
+- * These are internal Kerberos library functions that aren't prototyped and
+- * that we probably shouldn't be calling.  Prototype them with the arguments
+- * we expect and leave them for now pending an API cleanup.
+- */
+-krb5_error_code krb5_free_krbhst(krb5_context, char * const *);
+-krb5_error_code krb5_get_krbhst(krb5_context, const krb5_data *, char ***);
+-
+-/*
+  * The following three routines implement a "safehouse" for nested Kerberos
+  * data structures which shouldn't be freed before their parent data
+  * structures are freed.  Without this, "Bad free() ignored" errors as well
+@@ -181,26 +173,6 @@ krb5_get_host_realm(host)
+   }
+   krb5_free_host_realm(context,realmlist);
+ 
+-void
+-krb5_get_krbhst(realm)
+-  char *realm
+-
+-  PREINIT:
+-  krb5_data realm_data;
+-  char **hostlist;
+-  int i;
+-
+-  PPCODE:
+-  realm_data.data = realm;
+-  realm_data.length = strlen(realm);
+-  err = krb5_get_krbhst(context,_data,);
+-  if (err || !hostlist) XSRETURN_UNDEF;
+-  for (i = 0; hostlist[i]; i++) {
+-  XPUSHs(sv_2mortal(newSVpv(hostlist[i],
+-  strlen(hostlist[i];
+-  }
+-  krb5_free_krbhst(context,hostlist);
+-
+ Authen::Krb5::Principal
+ krb5_build_principal_ext(p)
+   Authen::Krb5::Principal p
diff -Nru libauthen-krb5-perl-1.9/debian/patches/series 
libauthen-krb5-perl-1.9/debian/patches/series
--- libauthen-krb5-perl-1.9/debian/patches/series   2011-12-13 
23:25:48.0 +0200
+++ libauthen-krb5-perl-1.9/debian/patches/series   2017-05-25 
18:59:03.0 +0300
@@ -1,3 +1,4 @@
 better-compiler-flags
 fix_pod
 fix-init_context.patch
+obsolete-krb_get,free_krbhst.patch

Bug#817837: closed by Jonathan McDowell <nood...@earth.li> (Bug#817837: fixed in l2tpns 2.2.1-2)

[Adrian Bunk]

On Thu, May 18, 2017 at 08:02:49PM +0100, Jonathan McDowell wrote:
> On Sun, May 14, 2017 at 09:15:50PM +0300, Adrian Bunk wrote:
> > On Tue, Jul 05, 2016 at 10:09:57AM +, Debian Bug Tracking System wrote:
> > >...
> > >  l2tpns (2.2.1-2) unstable; urgency=low
> > >  .
> > >* Fix log buffer overrun, thanks to Dave Reeve (closes: #817837)
> > >...
> > 
> > Hi Jonathan,
> > 
> > thanks a lot for fixing this bug for stretch.
> > 
> > It is still present in jessie, could you also fix it there?
> > Alternatively, I can fix it for jessie if you don't object.
> 
> I had avoided fixing it on jessie because it wasn't clear to me it would
> be permitted by the stable-release masters,

It looks like a rightfully RC bug to me and has a one-line fix.

> and there had been little
> indication there was active use of the package (I'm planning to have it
> removed post stretch as no one has stepped up to my intent to orphan
> it). If you want to take the package over entirely you're more than
> welcome to do so.

I am just going through RC bugs in jessie, trying to fix some of them.

According to popcon l2tpns has some users left.

If you want to get rid of the package, it would be perfectly fine if you 
retitle the RFA to O to make it clear that you do no longer want to be
responsible for l2tpns and that QA should maintain it instead.

> J.

cu
Adrian

-- 

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

Bug#859657: tellico: New upstream version available 3.0.2

[Louis-Philippe Véronneau]

Please consider updating to this new version. Last uploaded version
indeed has a lot of bugs and can be hard to use.

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#863341: jessie-pu: package nadoka/0.7.6-1.1+deb8u1

[Adrian Bunk]

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

Source format 1.0 does not apply debian/patches/


 debian/patches/series   |1 -
 debian/patches/use-generic-ruby |8 
 nadoka-0.7.6/debian/changelog   |7 +++
 nadoka-0.7.6/nadoka |2 +-
 4 files changed, 8 insertions(+), 10 deletions(-)

diff -u nadoka-0.7.6/debian/changelog nadoka-0.7.6/debian/changelog
--- nadoka-0.7.6/debian/changelog
+++ nadoka-0.7.6/debian/changelog
@@ -1,3 +1,10 @@
+nadoka (0.7.6-1.1+deb8u1) jessie; urgency=medium
+
+  * Non-maintainer upload.
+  * Really remove the hard-coding of ruby1.8. (Closes: #735655)
+
+ -- Adrian Bunk   Thu, 25 May 2017 18:31:51 +0300
+
 nadoka (0.7.6-1.1) unstable; urgency=high
 
   * Non-maintainer upload.
reverted:
--- nadoka-0.7.6/debian/patches/series
+++ nadoka-0.7.6.orig/debian/patches/series
@@ -1 +0,0 @@
-use-generic-ruby
reverted:
--- nadoka-0.7.6/debian/patches/use-generic-ruby
+++ nadoka-0.7.6.orig/debian/patches/use-generic-ruby
@@ -1,8 +0,0 @@
-Index: nadoka-0.7.6/nadoka
-===
 nadoka-0.7.6.orig/nadoka   2014-02-13 00:55:15.0 +0100
-+++ nadoka-0.7.6/nadoka2014-02-13 00:55:28.0 +0100
-@@ -1,2 +1,2 @@
- #!/bin/sh
--exec /usr/bin/ruby1.8 -I/usr/share/nadoka /usr/share/nadoka/nadoka.rb $@
-+exec /usr/bin/ruby -I/usr/share/nadoka /usr/share/nadoka/nadoka.rb $@
diff -u nadoka-0.7.6/nadoka nadoka-0.7.6/nadoka
--- nadoka-0.7.6/nadoka
+++ nadoka-0.7.6/nadoka
@@ -2 +2 @@
-exec /usr/bin/ruby1.8 -I/usr/share/nadoka /usr/share/nadoka/nadoka.rb $@
+exec /usr/bin/ruby -I/usr/share/nadoka /usr/share/nadoka/nadoka.rb $@

Bug#863340: unblock: maint-guide/1.2.39

[Osamu Aoki]

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

Please unblock package maint-guide

(explain the reason for the unblock here)
  * Fix dquilt bash completion.  Closes: #861084
  * Fix VCS-Browser. Closes: #861144
  * Drop menu section.  Closes: #861146
  * Update translation: de
  * Update translation: zh_CN.  Closes: #645969
  * Trivial update translation: all
  * Use opencc as the backup PO string generator for Chinese
translation.
  * Add PDF for zh-cn, zh-tw, and jp. Closes: #850523

(include/attach the debdiff against the package in testing)
Attached after removing diff in PO directory

  Please note some of the unused codes have been removed and opencc based
  Chinese auto-translation functionality added by moving working code from
  debian-reference.

unblock maint-guide/1.2.39

-- System Information:
Debian Release: 9.0
  APT prefers testing-proposed-updates
  APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (98, 
'experimental'), (98, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.10.0-rc6-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)
diff -Nru maint-guide-1.2.38/bin/fuzzypo maint-guide-1.2.39/bin/fuzzypo
--- maint-guide-1.2.38/bin/fuzzypo	1970-01-01 09:00:00.0 +0900
+++ maint-guide-1.2.39/bin/fuzzypo	2017-05-25 23:17:12.0 +0900
@@ -0,0 +1,11 @@
+#! /bin/sh -e
+# vim: set sts=4 expandtab:
+# $1: es.po fr.po pt.po zh-cn.po zh-cn.po-best ...
+#
+DPO="po"
+MSGATTR="msgattrib"
+#
+echo "no-obsolete  $1  `${MSGATTR} --no-obsolete  $1 |grep ^msgid |sed 1d|wc -l`"
+echo "untranslated $1  `${MSGATTR} --untranslated $1 |grep ^msgid |sed 1d|wc -l`"
+echo "fuzzy$1  `${MSGATTR} --fuzzy$1 |grep ^msgid |sed 1d|wc -l`"
+echo
diff -Nru maint-guide-1.2.38/bin/genxml maint-guide-1.2.39/bin/genxml
--- maint-guide-1.2.38/bin/genxml	1970-01-01 09:00:00.0 +0900
+++ maint-guide-1.2.39/bin/genxml	2017-05-25 23:17:12.0 +0900
@@ -0,0 +1,73 @@
+#! /bin/sh -e
+# vim: set sts=4 expandtab:
+# $1: en fr pt zh-cn ...
+#
+DPO="po"
+DBIN="bin"
+DCC="/usr/share/opencc"
+MANUAL="maint-guide"
+# The threshold should be 80 if translation is completed.
+THRESHOLD="0"
+TRANSLATE="po4a-translate -M utf-8 --format docbook --keep ${THRESHOLD} -v"
+MSGCAT="msgcat"
+OPENCC="opencc"
+
+# Generate XML (en)
+gen_xml_en () {
+echo "!!! Should not be here !!!" >&2
+false
+}
+
+# Generate XML (other)
+gen_xml_other () {
+if [ -f ${DPO}/${1}.add ]; then
+${TRANSLATE} -m ${MANUAL}.en.xml -a ${DPO}/${1}.add -p ${DPO}/${1}.po -l ${MANUAL}.${1}.xml
+else
+${TRANSLATE} -m ${MANUAL}.en.xml -p ${DPO}/${1}.po -l ${MANUAL}.${1}.xml
+fi
+}
+
+# Generate XML (zh-cn)
+gen_xml_zh_CN () {
+if which opencc >/dev/null ; then
+${MSGCAT} --no-wrap ${DPO}/zh-cn.po |\
+${OPENCC} -c ${DCC}/tw2sp.json -o ${DPO}/zh-cn.po-opencc
+${MSGCAT} -o ${DPO}/zh-cn.po-best --use-first ${DPO}/zh-cn.po ${DPO}/zh-cn.po-opencc
+${DBIN}/fuzzypo ${DPO}/zh-cn.po-best >>fuzzy.log
+else
+ln -f ${DPO}/zh-cn.po ${DPO}/zh-cn.po-best
+fi
+if [ -f ${DPO}/zh-cn.add ]; then
+${TRANSLATE} -m ${MANUAL}.en.xml -a ${DPO}/zh-cn.add -p ${DPO}/zh-cn.po-best -l ${MANUAL}.zh-cn.xml
+else
+${TRANSLATE} -m ${MANUAL}.en.xml -p ${DPO}/zh-cn.po-best -l ${MANUAL}.zh-cn.xml
+fi
+#rm -f ${DPO}/zh-cn.po-best
+}
+
+# Generate XML (zh-tw)
+gen_xml_zh_TW () {
+if which opencc >/dev/null ; then
+${MSGCAT} --no-wrap ${DPO}/zh-cn.po |\
+${OPENCC} -c ${DCC}/s2twp.json -o ${DPO}/zh-tw.po-opencc
+${MSGCAT} -o ${DPO}/zh-tw.po-best --use-first ${DPO}/zh-tw.po ${DPO}/zh-tw.po-opencc
+${DBIN}/fuzzypo ${DPO}/zh-tw.po-best >>fuzzy.log
+else
+ln -f ${DPO}/zh-tw.po ${DPO}/zh-tw.po-best
+fi
+if [ -f ${DPO}/zh-tw.add ]; then
+${TRANSLATE} -m ${MANUAL}.en.xml -a ${DPO}/zh-tw.add -p ${DPO}/zh-tw.po-best -l ${MANUAL}.zh-tw.xml
+else
+${TRANSLATE} -m ${MANUAL}.en.xml -p ${DPO}/zh-tw.po-best -l ${MANUAL}.zh-tw.xml
+fi
+#rm -f ${DPO}/zh-tw.po-best
+}
+
+# Main routine
+case "$1" in
+"zh-tw")gen_xml_zh_TW;;
+"zh-cn")gen_xml_zh_CN;;
+"en")   gen_xml_en;;
+*)  gen_xml_other "$1";;
+esac
+
diff -Nru maint-guide-1.2.38/Credits maint-guide-1.2.39/Credits
--- maint-guide-1.2.38/Credits	2014-06-28 15:36:00.0 +0900
+++ maint-guide-1.2.39/Credits	2017-05-25 22:58:43.0 +0900
@@ -96,6 +96,7 @@
 
 * Chinese (zh_CN): 
 @ Aron Xu 
+- Boyuan Yang <073p...@gmail.com>
 - 李凌, Ling Li 
 * 郑原真, 
 @ Chinese (simplified) 
diff -Nru maint-guide-1.2.38/debian/changelog maint-guide-1.2.39/debian/changelog
--- maint-guide-1.2.38/debian/changelog	

Bug#854367: Fixed upstream (new upstream version 1.8)

[Salvatore Bonaccorso]

All of those should be fixed in the new upstream version 1.8 according
to the upstream author.

Bug#863329: add option to generate .pc dir before launching build.

[Ian Jackson]

peter green writes ("Bug#863329: add option to generate .pc dir before 
launching build."):
> Package: dgit
> Severity: wishlist
> 
> Please consider adding an option to generate a .pc directory before launching 
> the build, some packages (notably "linux") refuse to build if it is not 
> present.

WTF?

Can you tell me the specific package, version, and architecture ?

Thanks,
Ian.

Bug#863276: nvidia-driver: nvidia fails to initialize Xorg with linux-image-4.9.0-0.bpo.3-amd64

[Luca Boccassi]

Control: severity -1 normal

On Thu, 2017-05-25 at 09:18 +0200, Harald Dunkel wrote:
> I am still running nvidia-graphics-drivers 375.26-1~bpo8+1 together
> with the
> new linux-image-4.9.0-0.bpo.3-amd64:amd64. This combination seems to
> work
> fine.
> 
> Other interesting packages in this context:
> 
>   dkms2.3-2~bpo8+1
>   nvidia-modprobe 358.09-1~bpo8+1
>   nvidia-settings 340.93-1~bpo8+1
>   nvidia-support  20151021+1~bpo8+1
> 
> 
> Hope this helps
> Harri

Same here.

And anyway a new version cannot be uploaded to backports until it's in
stretch, and it cannot be uploaded to stretch as it's in pre-release
freeze.

It will be uploaded after Stretch ships.

Kind regards,
Luca Boccassi

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

Bug#863339: RM: pgsnap/0.7.0-1

[Adrian Bunk]

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

#797547 pgsnap seems too old in Jessie

Any attempts to use pgsnap in jessie fail due to this bug.

The package was already removed from unstable.

Bug#863338: RFS: sysinfo/0.7-10.1 [NMU]

[Andreas Moog]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my nmu of the package "sysinfo"

 * Package name: sysinfo
   Version : 0.7-10.1
   Section : utils

It builds those binary packages:

  sysinfo- display computer and system information

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/sysinfo/sysinfo_0.7-10.1.dsc

Changes since the last upload:

sysinfo (0.7-10.1) unstable; urgency=medium

  * Non-maintainer upload
  * Apply patch from Alexander Grothe to fix crash when trying to get System-
information (Closes: #816481)

Thanks for your consideration!

  Regards,
   Andreas Moog

-- 
PGP-encrypted mails preferred
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624


signature.asc
Description: PGP signature

Bug#863337: visualvm: Typos in launcher script - does not start anymore

[Erich Schubert]

Package: visualvm
Version: 1.3.9-1
Severity: grave
Justification: renders package unusable

visualvm does not start anymore with the error:
Unknown option -L-XX:PermSize=32m

This is caused by a trivial typo in the start script, which supposedly
should use -J (like "Java options") instead of -L (two locations):

visualvm_default_options="-L-XX:PermSize=32m ${visualvm_default_options}"

should likely be

visualvm_default_options="-J-XX:PermSize=32m ${visualvm_default_options}"

In particular, note that the if statement reads 'if grep -v -- 
"-J-XX:MaxPermSize"'



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

Kernel: Linux 4.11.0-trunk-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)

Versions of packages visualvm depends on:
ii  default-jdk [java7-sdk]2:1.8-58
ii  libnb-platform18-java  8.2+dfsg1-1
ii  libvisualvm-jni1.3.9-1
ii  openjdk-8-jdk [java7-sdk]  8u131-b11-2
ii  openjdk-9-jdk [java7-sdk]  9~b170-2

visualvm recommends no packages.

visualvm suggests no packages.

-- no debconf information

Bug#863334: rsync: "ABORTING due to invalid path from sender" after upgrade from jessie to stretch

[Libor Klepáč]

Package: rsync
Version: 3.1.2-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,
we had two jessie servers, main server and backup.
Backup was upgraded to stretch.

We use this script to transfer changed/deleted files:
#rsync -avH --inplace --delete-missing-args --files-from=/tmp/transferfile 
/path/to/data/ archiver@1ip:/path/to/data/

The file /tmp/transferfile 
is generated by app, every change or deletion of file generates new line.
App also deletes empty dirs (if deleting a file produces empty dir)

After ugrade to stretch rsync there is a problem:
- --
rsync: [sender] write error: Broken pipe (32)
ABORTING due to invalid path from sender: path/inside/data/dir/file.txt
rsync error: protocol incompatibility (code 2) at generator.c(1271) 
[generator=3.1.2]
- --
(because path/inside/data/dir was deleted by app on sender side)

Reverting to jessie version=3.1.1-3 of rsync fixes problem.

It was probably reported here (with patch):
https://bugzilla.samba.org/show_bug.cgi?id=12569

Can you please patch it for stretch?


Thanks,
Libor


- -- System Information:
Debian Release: 9.0
  APT prefers experimental
  APT policy: (700, 'experimental'), (700, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages rsync depends on:
ii  base-files   9.9
ii  init-system-helpers  1.48
ii  libacl1  2.2.52-3+b1
ii  libattr1 1:2.4.47-2+b2
ii  libc62.24-10
ii  libpopt0 1.16-10+b2
ii  lsb-base 9.20161125

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.5p1-3
ii  openssh-server  1:7.5p1-3

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJJBAEBCAAzFiEEPGZVVU37tFmB0TQv8O+MbsKfR44FAlkm7d4VHGxpYm9yLmts
ZXBhY0BiY29tLmN6AAoJEPDvjG7Cn0eOhm0P/3BffHvVkTrmsunnZ+P84WGX7KOZ
gmZIaYYxDmgWmivCwW22w8ECpB2HPADBBYKJV3wHHFVKfuRdlQwl7b5N7bILmFcP
UasNqfRgs3nN/5+AcxuorNRR+nm3t+n28wMVIwQiqCFlmt0xgc+3ZKGYK/MZmiKm
16doXdAst+yS15PXVk/bRP7e0O3JBEzKok6DQc/D141ChexOEN768BahSFJtWSGV
1jnEa9DZzk49HoXAn9UTLYgH1Gy8NL+Lh4gthR3OQb85HJfzjlzsqFxjmu5bWx2X
OoVtegJn3d7u33CHPfhDPnrRzxkgMEEcHmCgz6XNRUN08jRVeHjl6lCwuck4pqaY
EtirqWMaA7fWgZFvAEXMKd6oYyhnYt3zCsOpABqL0TL5iztTsWSC/gfC1h/oL+ou
qYCCPtVrxsGm4tkuqgfBRbu/rgEwleI3lK+oV8YFguB7uW2meHFKoOYHueXBWSw2
rXC8Jnrhh/dlEj7CGKJbmvzZJCe+31vxXVzZMMXECd1zGA369RnT6RojO0f95jcE
XN0sqTJXnUopdFUSTQNuLttdSdOu1MXDFG4sc23F5lcca5fY0CBYcZSHAMqCydZb
QnIh9SKHQV+smnvaTQR79Rsg7bkl3nvQ65gob6jH6FZx9z/hEWdSSJSmIwIGuXVc
ozE8H8uHcJSUlIck
=Fry9
-END PGP SIGNATURE-