Bug#817116: civicrm: FTBFS: dh_linktree: link destination debian/civicrm-common/usr/share/civicrm/vendor/phenx/php-font-lib/classes is a directory

[Chris Lamb]

Source: civicrm
Version: 4.7.2+dfsg-2
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

civicrm fails to build from source in unstable/amd64:

  [..]

  mkdir: created directory 
'debian/civicrm-common/usr/share/civicrm/packages/tcpdf'
  pre-linktree: /usr/share/php/dompdf --> 
debian/civicrm-common/usr/share/civicrm/vendor/dompdf/dompdf
  pre-linktree: /usr/share/php/php-font-lib --> 
debian/civicrm-common/usr/share/civicrm/vendor/phenx/php-font-lib
  pre-linktree: /usr/share/php/Psr/Log --> 
debian/civicrm-common/usr/share/civicrm/vendor/psr/log/Psr/Log
  ## we need to call dh_linktree before dh_link, not after like it
  ## happens by default in "--with linktree" mode.
  dh_linktree
  dh_linktree: link destination 
debian/civicrm-common/usr/share/civicrm/vendor/phenx/php-font-lib/classes is a 
directory
  debian/rules:54: recipe for target 'override_dh_link' failed
  make[1]: *** [override_dh_link] Error 2
  make[1]: Leaving directory 
'/home/lamby/temp/cdt.20160308073122.zwCgusrmHz/civicrm-4.7.2+dfsg'
  debian/rules:7: recipe for target 'binary' failed
  make: *** [binary] Error 2

  [..]

The full build log is attached.


Regards,

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


civicrm.4.7.2+dfsg-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#817115: [network-manager] Wireless Device Support Regression (wext)

[Antonio Russo]

Package: network-manager
Version: 1.1.91-1
Severity: important

--- Please enter the report below this line. ---
After upgrade to 1.1.91-1, my Realktek RTL8191SU (with driver r8712u, which I 
believe is wext), is not visible at all to NetworkManager.

Reinstalling version 1.1.90-6 causes "nmcli dev" to show wlan0 again.

If there is an option to allow wext drivers to be used in NetworkManager, then 
this needs to be mentioned conspicuously in the changelog, at a
minimum.

Dropping support for a large class of networking device drivers represents a 
serious regression if there is no driver upgrade path.

--- System information. ---
Architecture: amd64
Kernel: Linux 4.4.0-1-amd64

Debian Release: stretch/sid
300 testing ftp.us.debian.org
251 unstable www.deb-multimedia.org
251 testing www.deb-multimedia.org
250 unstable ftp.us.debian.org
200 experimental ftp.us.debian.org

--- Package information. ---
Depends (Version) | Installed
=-+-
libc6 (>= 2.17) |
libdbus-1-3 (>= 1.0.2) |
libdbus-glib-1-2 (>= 0.102) |
libgcrypt11 (>= 1.4.5) |
libglib2.0-0 (>= 2.37.3) |
libgnutls-deb0-28 (>= 3.2.10-0) |
libgudev-1.0-0 (>= 165) |
libmm-glib0 (>= 1.0.0) |
libndp0 (>= 1.2) |
libnewt0.52 |
libnl-3-200 (>= 3.2.21) |
libnl-genl-3-200 (>= 3.2.21) |
libnl-route-3-200 (>= 3.2.7) |
libnm-glib4 (>= 0.9.10.0) |
libnm-util2 (>= 0.9.10.0) |
libpolkit-gobject-1-0 (>= 0.101) |
libreadline6 (>= 6.0) |
libsoup2.4-1 (>= 2.39.3) |
libsystemd-daemon0 (>= 31) |
libsystemd-login0 (>= 31) |
libuuid1 (>= 2.16) |
init-system-helpers (>= 1.18~) |
lsb-base (>= 3.2-14) |
wpasupplicant (>= 0.7.3-1) |
dbus (>= 1.1.2) |
udev |
adduser |
isc-dhcp-client (>= 4.1.1-P1-4) |
libpam-systemd |
policykit-1 |


Recommends (Version) | Installed
===-+-===
ppp (>= 2.4.6) | 2.4.7-1+2
dnsmasq-base | 2.75-1
iptables | 1.6.0-2
modemmanager | 1.4.12-1
crda | 3.13-1+b1


Suggests (Version) | Installed
-+-===
avahi-autoipd |

Bug#817012: ruby-amqp and ruby-amq-client: error when trying to install together

[Ralf Treinen]

Bonjour Sebastien,

thanks for the removal of ruby-amq-client. However, I think that you
still should add to ruby-amqp Replaces/Conflicts with ruby-amq-client,
in order allow for smooth upgrade from old installations.

Cheers -Ralf.

Bug#682232: [debian-mysql] Bug#682232: Failed upgrade of mysql from squeeze to wheezy

[Johannes Ranke]

> Hi Johannes! Thanks for taking the time to reach out. I'm struggling
> to understand what the "bug" is. Config files that have been customized
> have to be manually updated in any major upgrade. I don't think that's
> specific to MySQL.

Hi Clint,

good question. It bugged me, because I did not get any log entries under 
/var/log/mysql*, so I had to start mysqld in a way I usually don't, in order 
to get a diagnostic message about what was going on.

Also, as far as I can remember I never introduced the option skip-bdb 
manually. For me, if a previously valid configuration option makes a service 
fail to start after the upgrade, this is unexpected. But I do not want to 
complain, I added this information to help others to solve the problem!
If the maintainers get something out of it, even better.

Bug#816376: [Pkg-owncloud-maintainers] Bug#816376: Unfit upstream

[Jos Poortvliet]

On Monday, March 7, 2016 5:43:20 PM AMT Sébastien Villemot wrote:
> Dear David,
> 
> First, let me thank you for the work that you put into packaging
> owncloud for Debian, it is really appreciated.
> 
> On Tue, 1 Mar 2016 07:07:10 -0400 David =?iso-8859-1?Q?Pr=E9vot?= 
>  wrote:
> 
> > Upstream doesn’t wish to see their software in Debian anymore. Unless
> > the situation changes in the next few months, owncloud will not be part
> > of Stretch.
> 
> Given that owncloud is such a useful and important package, and that
> there is currently no credible alternative, this is really sad news, and
> I am wondering whether this outcome could be avoided.
> 
> If I understand correctly, your decision is essentially based on social
> issues (upstream hostile to Debian packaging), coupled to some technical
> aspects (complex upgrade paths).

See my last email here - we'd love to have ownCloud included in Debian but 
obviously only if it provides a good experience to users. Right now, it seems 
that that is hard to do within the framework Debian provides.

http://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-March/002899.html

The situation is rather sad and frustrating as users who decided to trust the 
Debian developers and took their packages over ownCloud's provided packages are 
now stuck on a version which can't trivially be upgraded to either our upstream 
version or anything else. We would love to find a solution for them - as I've 
said many times, our main concern is the end users, rather than politics, rules 
or anything else.

Thanks for caring about this,
Jos

> At first glance, this does not seem to prevent the package from staying
> in Debian. Maybe this just means that the package needs a new
> maintainer, who is willing to handle the tough interaction with upstream
> and dealing with the technical issues (note that I am not applying for
> the job).
> 
> You are certainly in a better position than me to ascertain whether the
> package can stay in Debian or not, but I think that it would be useful
> if you could give a little more background on the issues that you
> encountered. And, if you think it makes sense to orphan the package,
> that would help prospective new maintainers in making the decision to
> adopt the package or not.
> 
> Cheers,
> 
> 



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

Bug#817006: ack to NMU

[Benda Xu]

Hi Adam,

Thank you for your report.  I appreciate your enthusiasm.

Sorry, I forgot to append my reply to Andreas to #811708:

  
http://lists.alioth.debian.org/pipermail/openrc-devel/Week-of-Mon-20160307/000436.html

Basically, my taking to this bug is to ignore it, leaving the users to
fix the breakage by

  dpkg-divert --remove /usr/sbin/invoke-rc.d
  dpkg-divert --remove /usr/sbin/update-rc.d

manually.  

0.20.4-1 lasted only 10days.  Only few users would be affected.
Provided OpenRC have already been removed from testing thanks to i-s-h
[1], such a breakage is tolerable for unstable.


That said, I understand theoretically your NMU is the correctly way to
go.  So if you intend to do so, consider this email as an ack to NMU
from the maintainer team.


One thing to notice is that we are tracking the package at

  http://anonscm.debian.org/cgit/openrc/openrc.git

Would you mind if I ask you to prepare a commit to the master
corresponding to the NMU?

BTW, if you are interested in OpenRC, you are welcomed to join the
maintenance team.

Yours,
Benda


1. 0.20.4-1 was uploaded in a hurry to keep itself in testing.  The pts
system lied and we did not make it.  divert should not have existed in
OpenRC.

Bug#807264: dpkg: Please allow negative Architecture lists in debian/control

[Axel Beckert]

Hi Guillem,

Guillem Jover wrote:
> This was filed some time ago.

Hrm, seem to have missed that one.

> Can you present a case where using a negative specification would be
> more correct than a positive one?

"More correct" maybe not (not sure what "more correct" means as
"correct" is boolean for me), but surely way easier to maintain since
I wouldn't have to follow all new architectures which pop up
occassionally:

There was a time where gnudatalanguage didn't build on exactly one
architecture (arm64): See https://bugs.debian.org/803552 and
https://anonscm.debian.org/cgit/debian-astro/packages/gnudatalanguage.git/commit/?id=638bc9c3be31a4e5bd747f6c0f985da1afbc26ba

The full architecture list reads:

Architecture: any-alpha any-amd64 any-armeb any-arm any-avr32 any-hppa
any-i386 any-ia64 any-m32r any-m68k any-mips any-mips64 any-mips64el
any-mipsel any-or1k any-powerpc any-powerpcel any-ppc64 any-ppc64el
any-s390 any-s390x any-sh3 any-sh3eb any-sh4 any-sh4eb any-sparc
any-sparc64 mipsn32 mipsn32el powerpcspe x32

I had to write small script to get it done properly and found that
line/commit rather tedious. And if the bug wouldn't have been fixed
properly soon afterwards, I'd have had to keep that field uptodate or
at least check it everytime a new architectures pops up, e.g. on
Debian Ports.

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

Bug#814976: whitedune: diff for NMU version 0.30.10-2.1

[Raúl Benencia]

Control: tags 814976 + patch
Control: tags 814976 + pending

Dear maintainer,

This bug is caused by a recent update on grep. This update modified a bit
the heuristic used for determining when the given input is binary.

I've prepared an NMU for whitedune (versioned as 0.30.10-2.1). As I don't
have privileges to upload it to DELAYED, I've uploaded it to the mentors
repository.

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

  http://mentors.debian.net/package/whitedune


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

  dget -x 
http://mentors.debian.net/debian/pool/main/w/whitedune/whitedune_0.30.10-2.1.dsc

Cheers,
Rul
diff -Nru whitedune-0.30.10/debian/changelog whitedune-0.30.10/debian/changelog
--- whitedune-0.30.10/debian/changelog	2016-01-09 12:53:49.0 -0800
+++ whitedune-0.30.10/debian/changelog	2016-03-07 08:19:38.0 -0800
@@ -1,3 +1,10 @@
+whitedune (0.30.10-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS due new binary matching behavior on grep (Closes: #814976)
+
+ -- Raúl Benencia   Mon, 07 Mar 2016 07:56:28 -0800
+
 whitedune (0.30.10-2) unstable; urgency=medium
 
   * Team upload.
diff -Nru whitedune-0.30.10/debian/patches/avoid-grep-binary.patch whitedune-0.30.10/debian/patches/avoid-grep-binary.patch
--- whitedune-0.30.10/debian/patches/avoid-grep-binary.patch	1969-12-31 16:00:00.0 -0800
+++ whitedune-0.30.10/debian/patches/avoid-grep-binary.patch	2016-03-07 08:12:25.0 -0800
@@ -0,0 +1,13 @@
+Index: whitedune-0.30.10/src/Makefile.in
+===
+--- whitedune-0.30.10.orig/src/Makefile.in	2011-04-29 02:28:06.0 -0700
 whitedune-0.30.10/src/Makefile.in	2016-03-07 08:08:45.863708021 -0800
+@@ -771,7 +771,7 @@
+ resource.c: dune.rc swt/rc/rc $(ICONS) resource.h
+ 	sed 's../.' < dune.rc > dune1.rc.c
+ 	$(CXXCPP) dune1.rc.c > dune2.rc.c 
+-	grep -v '//' dune2.rc.c > dune3.rc.c
++	grep -av '//' dune2.rc.c > dune3.rc.c
+ 	if swt/rc/rc < dune3.rc.c > resource.c ; then echo > /dev/null; else rm  resource.c ; exit 1 ; fi
+ 	rm dune1.rc.c dune2.rc.c dune3.rc.c
+ 
diff -Nru whitedune-0.30.10/debian/patches/series whitedune-0.30.10/debian/patches/series
--- whitedune-0.30.10/debian/patches/series	2016-01-09 12:53:19.0 -0800
+++ whitedune-0.30.10/debian/patches/series	2016-03-07 08:12:25.0 -0800
@@ -1,2 +1,3 @@
 libxp-configure.patch
 png1.5.patch
+avoid-grep-binary.patch


signature.asc
Description: PGP signature

Bug#817114: libc6 2.22-1 breaks lxc 1:1.1.5-1

[Alfonso Perez]

Package: bugs.debian.org
Severity: important
Tags: upstream

Hi, I've just dist-upgrade sid, and as a result, lxc was removed. Tried to
reinstall it, but:

The following packages have unmet dependencies:
 lxc : Depends: liblxc1 (= 1:1.1.5-1) but it is not going to be installed

then:
apt-get install liblxc1
The following packages have unmet dependencies:
 liblxc1 : Depends: libcgmanager0 (>= 0.32) but it is not going to be installed
   Depends: libnih-dbus1 (>= 1.0.0) but it is not going to be installed
   Depends: libnih1 (>= 1.0.0) but it is not going to be installed

then:
apt-get install libnih1
The following packages have unmet dependencies:
 libnih1 : Depends: libc6 (< 2.22) but 2.22-1 is to be installed

So it seems that libc6 2.22-1 breaks libnih1, that breaks liblxc1, that breaks
lxc.

How can lxc be reinstalled?



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

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

Bug#817096: [pkg-go] Bug#817096: ITP: golang-github-cheggaaa-pb -- console progress bar for Go

[Dmitry Smirnov]

> > Already provided by package "golang-pb-dev".
> 
> Thanks, I missed that one due to the abbreviated name.
> 
> The package is very much out of date (0.0~git20131219-1) and acmetool
> fails to compile with it. Can I update the existing package to the
> above version?

Of course. :) It would great if you could update the package and properly put
it under team umbrella. At the moment packaging is hosted in team
repositories but there is only one maintainer... Please make sure to contact
maintainer first.


> Is it possible to rename both the source package and
> the binary package to the long form, or would the old package have
> to be deleted from the archive?

Yes, ideally package name should be changed to be in line with policy
although you might begin with updating it first and change name somewhat
later when you build enough confidence.

You can find details here:

https://pkg-go.alioth.debian.org/packaging.html

-- 
All the best,
 Dmitry Smirnov.

---

The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think differently.
-- Friedrich Nietzsche


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

Bug#804203: ITP: golang-github-fatih-color -- Color package for Go (golang)

[Peter Colberg]

Hi Andrew,

I noticed that you have already created a pkg-go repository for
golang-github-fatih-color, although containing an older version.

If you have no objections, I will push an updated upstream snapshot
(which no longer depends on github.com/shiena/ansicolor) and submit
a request for sponsored upload.

Regards,
Peter

Bug#817113: apt: buggy string expansion

[westlake]

Package: apt
Version: 1.0.9.8.2
Severity: normal

an odd bug,.. here when I do
"apt-cache show streamer0.10-plugins-good", reveals the description for 
package "gstreamer0.10-plugins-good".

Bug#817112: libvirglrenderer0 and libvirglrenderer-dev: error when trying to install together

[Ralf Treinen]

Package: libvirglrenderer-dev,libvirglrenderer0
Version: libvirglrenderer-dev/0.4.0-4
Version: libvirglrenderer0/0.4.0-4
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2016-03-08
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Selecting previously unselected package libdrm2:amd64.
(Reading database ... 10939 files and directories currently installed.)
Preparing to unpack .../libdrm2_2.4.67-1_amd64.deb ...
Unpacking libdrm2:amd64 (2.4.67-1) ...
Selecting previously unselected package libepoxy0:amd64.
Preparing to unpack .../libepoxy0_1.3.1-1_amd64.deb ...
Unpacking libepoxy0:amd64 (1.3.1-1) ...
Selecting previously unselected package libexpat1:amd64.
Preparing to unpack .../libexpat1_2.1.0-7_amd64.deb ...
Unpacking libexpat1:amd64 (2.1.0-7) ...
Selecting previously unselected package libffi6:amd64.
Preparing to unpack .../libffi6_3.2.1-4_amd64.deb ...
Unpacking libffi6:amd64 (3.2.1-4) ...
Selecting previously unselected package libwayland-client0:amd64.
Preparing to unpack .../libwayland-client0_1.9.0-1_amd64.deb ...
Unpacking libwayland-client0:amd64 (1.9.0-1) ...
Selecting previously unselected package libwayland-server0:amd64.
Preparing to unpack .../libwayland-server0_1.9.0-1_amd64.deb ...
Unpacking libwayland-server0:amd64 (1.9.0-1) ...
Selecting previously unselected package libgbm1:amd64.
Preparing to unpack .../libgbm1_11.1.2-1_amd64.deb ...
Unpacking libgbm1:amd64 (11.1.2-1) ...
Selecting previously unselected package libvirglrenderer0.
Preparing to unpack .../libvirglrenderer0_0.4.0-4_amd64.deb ...
Unpacking libvirglrenderer0 (0.4.0-4) ...
Selecting previously unselected package libvirglrenderer-dev.
Preparing to unpack .../libvirglrenderer-dev_0.4.0-4_amd64.deb ...
Unpacking libvirglrenderer-dev (0.4.0-4) ...
dpkg: error processing archive 
/var/cache/apt/archives/libvirglrenderer-dev_0.4.0-4_amd64.deb (--unpack):
 trying to overwrite '/usr/lib/x86_64-linux-gnu/libvirglrenderer.so', which is 
also in package libvirglrenderer0 0.4.0-4
Processing triggers for libc-bin (2.22-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/libvirglrenderer-dev_0.4.0-4_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/lib/x86_64-linux-gnu/libvirglrenderer.so

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.

Bug#817096: [pkg-go] Bug#817096: ITP: golang-github-cheggaaa-pb -- console progress bar for Go

[Peter Colberg]

On Tue, Mar 08, 2016 at 05:59:37PM +1100, Dmitry Smirnov wrote:
> On Tuesday, 8 March 2016 12:58:12 AM AEDT Peter Colberg wrote:
> > * Package name: golang-github-cheggaaa-pb
> >   Version : 0.0~git20160304.0.a75ad33
> >   Upstream Author : Sergey Cherepanov
> > * URL : https://github.com/cheggaaa/pb
> 
> Already provided by package "golang-pb-dev".

Thanks, I missed that one due to the abbreviated name.

The package is very much out of date (0.0~git20131219-1) and acmetool
fails to compile with it. Can I update the existing package to the
above version? Is it possible to rename both the source package and
the binary package to the long form, or would the old package have
to be deleted from the archive?

Regards,
Peter

Bug#817111: pcsx2:i386: Not working with MESA, working with FGLRX.

[Kyuma Ohta]

Package: pcsx2
Version: 1.4.0+dfsg-1
Severity: important

Dear Maintainer,

 With FGLRX, PCSX2 has working seems to be well.
 But, with MESA OpenGL, PCSX has not working.

 This seems to be related GSdx's problem.
 When starting VM , GSdx said to log:
 >glX-Version 1.4 with Direct Rendering
 >Failed to find glGetDebugMessageLogARB
 
 This function may be implemented after OpenGL 3.x, but not detected.
 I'm using Radeon HD 7770, ready to use OpenGL 4.1 with MESA's OpenGL.
 
Regards,
 Ohta.

P.S:
 Now, FGLRX was not working with Xorg 1.18, I must 
use MESA as OpenGL.

I attach full of logs:
PCSX2 1.4.0-0
Savestate version: 0x9a0b

Host Machine Init:
Operating System =  Linux 4.4.4-custom-amd64 x86_64
Physical RAM =  16006 MB
CPU name =  AMD FX(tm)-8320 Eight-Core Processor
Vendor/Model =  AuthenticAMD (stepping 00)
CPU speed=  3.487 ghz (8 logical threads)
x86PType =  Standard OEM
x86Flags =  178bfbff 3e98320b
x86EFlags=  2fd3fbff

x86 Features Detected:
SSE2.. SSE3.. SSSE3.. SSE4.1.. SSE4.2.. AVX.. FMA
MMX2  .. SSE4a 

Installing POSIX SIGSEGV handler...
Reserving memory for recompilers...
(GameDB) 9693 games on record (loaded in 300ms)

Loading plugins...
Binding   GS: /usr/lib/i386-linux-gnu/pcsx2/libGSdx-1.0.0.so 
Binding  PAD: /usr/lib/i386-linux-gnu/pcsx2/libonepad-1.1.0.so 
Binding SPU2: /usr/lib/i386-linux-gnu/pcsx2/libspu2x-2.0.0.so 
Binding CDVD: /usr/lib/i386-linux-gnu/pcsx2/libCDVDnull.so 
Binding  USB: /usr/lib/i386-linux-gnu/pcsx2/libUSBnull-0.7.0.so 
Binding   FW: /usr/lib/i386-linux-gnu/pcsx2/libFWnull-0.7.0.so 
Binding DEV9: /usr/lib/i386-linux-gnu/pcsx2/libdev9null-0.5.0.so 
Plugins loaded successfully.

HLE Notice: ELF does not have a path.


Initializing plugins...
Init GS
Init PAD
Init SPU2
Init CDVD
Init USB
Init FW
Init DEV9
Plugins initialized successfully.

Opening plugins...
Opening GS
Current Renderer: OpenGL (Hardware mode)
glX-Version 1.4 with Direct Rendering
Failed to find glGetDebugMessageLogARB
Closing plugins...
Closing GS
Plugins closed successfully.
Shutting down plugins...
Plugins shutdown successfully.
(p) GS plugin failed to open!(thread:MTGS)(thread:EE Core)
User-canceled plugin configuration after plugin initialization failure.  
Plugins unloaded.

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

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

Versions of packages pcsx2:i386 depends on:
ii  libaio1   0.3.110-2
ii  libasound21.1.0-1
ii  libc6 2.22-1
ii  libgcc1   1:5.3.1-11
ii  libgdk-pixbuf2.0-02.32.3-1.2
ii  libgl1-mesa-glx [libgl1]  11.1.2-1
ii  libglib2.0-0  2.47.3-3
ii  libgtk2.0-0   2.24.30-1
ii  liblzma5  5.1.1alpha+20120614-2.1
ii  libpng12-01.2.54-4
ii  libportaudio2 19+svn20140130-1
ii  libsdl2-2.0-0 2.0.4+dfsg1-2
ii  libsoundtouch11.9.2-2
ii  libstdc++65.3.1-11
ii  libwxbase3.0-0v5  3.0.2+dfsg-1.3
ii  libwxgtk3.0-0v5   3.0.2+dfsg-1.3
ii  libx11-6  2:1.6.3-1
ii  zlib1g1:1.2.8.dfsg-2+b1
ii  libosmesa611.1.2-1

Versions of packages pcsx2:i386 recommends:
ii  libasound2-plugins  1:1.1.0-dmo2
ii  libc6-i686  2.22-1

pcsx2:i386 suggests no packages.

-- no debconf information

Bug#817057: network-manager-openconnect: Update unstable version to latest Upstream Build

[Michael Stapelberg]

Thanks for clarifying the issue you’re seeing. I don’t think this is
related to the D-Bus changes.

Also, to be clear: I’m not the maintainer of this package, I sponsored
mtmiller@’s uploads, who maintains the package.

On Tue, Mar 8, 2016 at 3:09 AM, Ryan Chewning  wrote:

> Michael, I copied you on this bug as you're the package maintainer for
> network-manager-openconnect and the imports of the upstream are failing.
> Currently, upstream for network-open-connect is at 1.91 and in Debian
> unstable/testing are both on the 1.0.2 release which isn't working with the
> network-manager builds in unstable and are on 1.91. I'm attempting to
> create an openconnect vpn profile but I get the following error messages in
> my .xsession-error log when launching nm-connection editor
>
> """
> ** Message: vpn: (iodine,/usr/lib/NetworkManager/VPN/
> nm-iodine-service.name) cannot load legacy-only plugin
> ** Message: vpn: (ssh,/usr/lib/NetworkManager/VPN/nm-ssh-service.name)
> cannot load legacy-only plugin
> ** Message: vpn: (openconnect,/usr/lib/NetworkManager/VPN/
> nm-openconnect-service.name) cannot load legacy-only plugin
> ** Message: vpn: (strongswan,/etc/NetworkManager/VPN/
> nm-strongswan-service.name) cannot load legacy-only plugin
> 
>
> I also only have the option to configure the following three types of vpns
> OpenVPN, PPTP or KVPNC even though I have iodine, ssh, openconnect and
> strongswan installed.
>
> If you think this bug is better suited for the network-manager package
> please let me know and I'll head over that way.
>
> Thanks,
>
> Ryan
>
> On Mon, Mar 7, 2016 at 12:22 PM, Michael Stapelberg  > wrote:
>
>>
>>
>> On Mon, Mar 7, 2016 at 9:07 AM, Ryan Chewning  wrote:
>>
>>> Package: network-manager-openconnect
>>> Version: 1.0.2-1+b1
>>> Severity: grave
>>> Tags: upstream
>>> Justification: renders package unusable
>>>
>>> The latest builds of networkmanager in testing/unstable no longer
>>> support dbus. https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/
>>>
>>
>> I’m only a bystander for the purpose of this bug, but “networkmanager […]
>> no longer supports dbus” conflicts with the article you refer to, which
>> mentions:
>>
>> """
>> I cannot understate how much work this was and how much careful planning
>> we (well, mostly Dan Winship) did to ensure we didn’t break backwards
>> compatibility of either the utility libraries or the D-Bus interface.
>> """
>>
>> The way I read this, the new networkmanager version is
>> backwards-compatible with regards to its D-Bus interface.
>>
>> Can you clarify? If it turns out that it’s actually backwards-compatible,
>> is severity: grave still justified?
>>
>>
>>> There is an updated version of the network-manager-openconnect but it is
>>> failing to be pulled down by uscan. Manual intervention is needed.
>>>
>>> Thanks,
>>>
>>> Ryan
>>>
>>> -- System Information:
>>> Debian Release: stretch/sid
>>>   APT prefers testing-updates
>>>   APT policy: (500, 'testing-updates'), (500, 'testing')
>>> Architecture: amd64 (x86_64)
>>> Foreign Architectures: i386
>>>
>>> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>> Shell: /bin/sh linked to /bin/dash
>>> Init: systemd (via /run/systemd/system)
>>>
>>> Versions of packages network-manager-openconnect depends on:
>>> ii  adduser   3.113+nmu3
>>> ii  libc6 2.21-9
>>> ii  libdbus-1-3   1.10.6-1
>>> ii  libdbus-glib-1-2  0.106-1
>>> ii  libglib2.0-0  2.46.2-3
>>> ii  libnm-glib-vpn1   1.1.90-6
>>> ii  libnm-glib4   1.1.90-6
>>> ii  libnm-util2   1.1.90-6
>>> ii  network-manager   1.1.90-6
>>> ii  openconnect   7.06-2+b2
>>>
>>> network-manager-openconnect recommends no packages.
>>>
>>> network-manager-openconnect suggests no packages.
>>>
>>> -- no debconf information
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Michael
>>
>
>


-- 
Best regards,
Michael

Bug#817096: [pkg-go] Bug#817096: ITP: golang-github-cheggaaa-pb -- console progress bar for Go

[Dmitry Smirnov]

On Tuesday, 8 March 2016 12:58:12 AM AEDT Peter Colberg wrote:
> * Package name: golang-github-cheggaaa-pb
>   Version : 0.0~git20160304.0.a75ad33
>   Upstream Author : Sergey Cherepanov
> * URL : https://github.com/cheggaaa/pb

Already provided by package "golang-pb-dev".

-- 
Cheers,
 Dmitry Smirnov.

---

There is no such thing as public opinion. There is only published opinion.
-- Winston Churchill


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

Bug#815760: (no subject)

[Christian Ehrhardt]

Hi Martin Thiago,
Thanks for you agreement and your sniff test via the re-compile.

Tiago (I have to watch the "h" to keep you distinct :-) ) and I were in
contact.
For now I'm flushing out many issues in dpdk itself and our code bundled in
packaging towards Xenial release.
Also DPDK upstream makes some major changes to e.g. the combined library
linking which will affect packaging a lot.
So we agreed that we will take a deeper look at it a bit later this year to
avoid re-doing it all over so soon after.

For now - open to all - we are still looking for an experienced DD to help
us then and in general for someone with upload rights.



Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

On Tue, Mar 8, 2016 at 6:36 AM, Martinx - ジェームズ 
wrote:

> On 24 February 2016 at 07:51, Christian Ehrhardt 
> wrote:
>
>> Subject: ITP: dpdk -- Data Plane Development Kit
>> Package: wnpp
>> Owner: Christian Ehrhardt 
>> Severity: wishlist
>>
>> * Package name: dpdk
>>   Version : 2.2
>>   Upstream Author : Thomas Monjalon 
>> * URL : http://dpdk.org/
>> * License : BSD (core libs), GPLv2 (kernel components)
>>   Programming Lang: C
>>   Description : Data Plane Development Kit
>>
>> 1. What is DPDK useful for
>> DPDK is a set of libraries and drivers for fast packet processing. It
>> was designed to run on any processors. The first supported CPU was Intel
>> x86 and it is now extended to IBM Power 8, EZchip TILE-Gx and ARM. It
>> runs mostly in Linux userland. A FreeBSD port is available for a subset
>> of DPDK features.
>>
>> Main libraries
>> - multicore framework
>> - huge page memory
>> - ring buffers
>> - poll-mode drivers
>>
>> Usage
>> These libraries can be used to:
>> - receive and send packets within the minimum number of CPU cycles
>>   (usually less than 80 cycles)
>> - develop fast packet capture algorithms (tcpdump-like)
>> - run third-party fast path stacks
>> Some packet processing functions have been benchmarked up to hundreds
>> million frames per second, using 64-byte packets with a PCIe NIC.
>>
>>
>> 2. Maintenance Plan
>> I'm currently maintaining dpdk for ubuntu (
>> launchpad.net/ubuntu/+source/dpdk)
>> and the existing packaging should be suitable for Debian also.
>>
>> It'd be great to have this packaged in Debian too, so that we can share
>> the
>> work. I am looking for co-maintainers to help me with this.
>>
>> But I'm not a Debian developer, so I'd like to have a more Debian centric
>> co-maintainer for a proper Debian expertise and opinion in all the work.
>> I'm also no DD, so sponsors will be needed.
>>
>>
> It will be great to see DPDK on Debian Main too!
>
> I have re-compiled this source DPDK Debian package, from Ubuntu, on Jessie
> and it works.
>
> Cheers!
> Thiago
>

Bug#813323: Second window of Eye of MATE don't get focus

[John Paul Adrian Glaubitz]

On 03/08/2016 01:40 AM, Strelok wrote:
>> It is still the stable release of Debian and an ancient version of
>> MATE. Your chances that this issue will be resolved in Jessie are
>> therefore almost zero.
> 
> I'm try Debian Stretch and have same bug in EOM 1.12.2. Now it can be fixed?

Nope. You need to upgrade to unstable first. testing is still not the
most recent version and the bug may also be a result of several outdated
components.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#817056: ITP: python-typing -- Type Hints for Python

[Michael R. Crusoe]

See
https://www.python.org/dev/peps/pep-0484/#suggested-syntax-for-python-2-7-and-straddling-code
Pe 8 mar. 2016 06:24, "Brian May"  a scris:

> "Michael R. Crusoe"  writes:
>
> >  This is a backport of the standard library typing module to Python
> >  versions older than 3.5.
>
> Not sure what the point of this is; doesn't typing hinting require PEP
> 3107, which isn't in Python 2.x?
> --
> Brian May 
>

Bug#817110: ITP: golang-github-hlandau-xlog -- logging library for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-hlandau-xlog
  Version : 0.0~git20160208.0.c18de57
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/xlog
* License : Expat
  Programming Lang: Go
  Description : logging library for Go

This package provides a hierarchical, configurable logging system
suitable for use in libraries.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817109: ITP: golang-github-square-go-jose -- Javascript Object Signing and Encryption (JOSE) for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-square-go-jose
  Version : 0.0~git20160304.0.7465d2b
  Upstream Author : Square Inc
* URL : https://github.com/square/go-jose
* License : Apache-2.0
  Programming Lang: Go
  Description : Javascript Object Signing and Encryption (JOSE) for Go

This package provides an implementation of the Javascript Object
Signing and Encryption set of standards. The implementation follows
the JSON Web Encryption standard (RFC 7516) and JSON Web Signature
standard (RFC 7515). The package supports both the compact and full
serialization formats, and optionally supports multiple recipients.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817107: ITP: golang-gopkg-hlandau-svcutils.v1 -- utilities for writing services in Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-hlandau-svcutils.v1
  Version : 1.0.7
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/svcutils
* License : Expat
  Programming Lang: Go
  Description : utilities for writing services in Go

This package provides utilities for chrooting, determining
the absolute path of an executable, determining user and group
information, creating and locking PID files, changing UID and GID,
sending status notifications to systemd, detecting and dropping
capabilities, and duplicating file descriptors.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817108: ITP: golang-gopkg-tylerb-graceful.v1 -- Go package for gracefully shutting down HTTP server

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-tylerb-graceful.v1
  Version : 1.2.4
  Upstream Author : Tyler Bunnell
* URL : https://github.com/tylerb/graceful
* License : Expat
  Programming Lang: Go
  Description : Go package for gracefully shutting down HTTP server

This package enables graceful shutdown of a http.Handler server.
When the process receives a SIGINT or SIGTERM, the listening
port is closed immediately for reuse by another process, while
active connections are gracefully terminated after a timeout.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817105: ITP: golang-gopkg-hlandau-easyconfig.v1 -- Go package with easy bindings for configurable

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-hlandau-easyconfig.v1
  Version : 1.0.12
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/easyconfig
* License : Expat
  Programming Lang: Go
  Description : Go package with easy bindings for configurable

This package provides convenient interfaces for the configurable package.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817104: ITP: golang-gopkg-hlandau-configurable.v1 -- Go package for managing program configuration

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-hlandau-configurable.v1
  Version : 1.0.1
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/configurable
* License : Expat
  Programming Lang: Go
  Description : Go package for managing program configuration

This package provides an integration nexus for program configuration
coming from command line arguments, configuration files, environment
variables, or any other sources.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817103: ITP: golang-gopkg-alecthomas-kingpin.v2 -- command-line and flag parser for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-alecthomas-kingpin.v2
  Version : 2.1.11
  Upstream Author : Alec Thomas
* URL : https://github.com/alecthomas/kingpin
* License : Expat
  Programming Lang: Go
  Description : command-line and flag parser for Go

This package provides a fluent-style, type-safe command-line parser.
It supports flags, nested commands, positional arguments, customizable
help output using Go templates, and automatically generated man pages.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817106: ITP: golang-gopkg-hlandau-service.v2 -- Go package for writing services

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-gopkg-hlandau-service.v2
  Version : 2.0.15
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/service
* License : ISC
  Programming Lang: Go
  Description : Go package for writing services

This package implements daemonization, PID file creation, privilege
dropping, chrooting, status notification, and orderly shutdown.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817102: ITP: golang-github-peterhellberg-link -- Go package for parsing link headers

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-peterhellberg-link
  Version : 0.0~git20151119.0.1053d3b
  Upstream Author : Peter Hellberg
* URL : https://github.com/peterhellberg/link
* License : Expat
  Programming Lang: Go
  Description : Go package for parsing link headers

This package parses link headers (RFC 5988) used for pagination.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817101: ITP: golang-github-ogier-pflag -- POSIX/GNU-style command-line flags for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-ogier-pflag
  Version : 0.0~git20160129.0.45c278a
  Upstream Author : Alex Ogier
* URL : https://github.com/ogier/pflag
* License : BSD-3-clause
  Programming Lang: Go
  Description : POSIX/GNU-style command-line flags for Go

This package is a drop-in replacement for Go's flag package
providing POSIX/GNU-style long-form command-line flags.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817099: ITP: golang-github-jmhodges-clock -- Go package for testing time-dependent code

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-jmhodges-clock
  Version : 0.0~git20151001.0.3c4ebd2
  Upstream Author : Jeff Hodges
* URL : https://github.com/jmhodges/clock
* License : Expat
  Programming Lang: Go
  Description : Go package for testing time-dependent code

This package provides an abstraction for system time that enables
testing of time-dependent code.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817100: ITP: golang-github-mitchellh-go-wordwrap -- Go package for wrapping words into multiple lines

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-mitchellh-go-wordwrap
  Version : 0.0~git20150314.0.ad45545
  Upstream Author : Mitchell Hashimoto
* URL : https://github.com/mitchellh/go-wordwrap
* License : Expat
  Programming Lang: Go
  Description : Go package for wrapping words into multiple lines

This package wraps words to limit the line length to a given number
of characters, which is useful to format output in console programs.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817096: ITP: golang-github-cheggaaa-pb -- console progress bar for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-cheggaaa-pb
  Version : 0.0~git20160304.0.a75ad33
  Upstream Author : Sergey Cherepanov
* URL : https://github.com/cheggaaa/pb
* License : BSD-3-clause
  Programming Lang: Go
  Description : console progress bar for Go

This package provides a simple progress bar for console programs.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817098: ITP: golang-github-hlandau-degoutils -- miscellaneous utilities for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-hlandau-degoutils
  Version : 0.0~git20160211.0.16c74cc
  Upstream Author : Hugo Landau
* URL : https://github.com/hlandau/degoutils
* License : Expat
  Programming Lang: Go
  Description : miscellaneous utilities for Go

This package provides utility functions needed for building acmetool.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817097: ITP: golang-github-erikdubbelboer-gspt -- setproctitle for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-erikdubbelboer-gspt
  Version : 0.0~git20151120.0.bbaae60
  Upstream Author : Erik Dubbelboer
* URL : https://github.com/ErikDubbelboer/gspt
* License : Expat
  Programming Lang: Go
  Description : setproctitle for Go

This package provides a function for setting the title of a process.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#813698: perhaps default to POWER8 only for ppc64el?

[Adam Borowski]

Changing the default for all PPC guests to something else than the upstream
default might be intrusive.  But, what about making this change only for
ppc64el?  I'm not aware of other major deployments of little-endian ppc so
there'd be no risk of unnecessarily bumping the CPU.

Each of PPC targets is a different binary:
/usr/bin/qemu-ppc
/usr/bin/qemu-ppc64
/usr/bin/qemu-ppc64abi32
/usr/bin/qemu-ppc64le
/usr/bin/qemu-ppc-static
/usr/bin/qemu-ppc64-static
/usr/bin/qemu-ppc64abi32-static
/usr/bin/qemu-ppc64le-static
so it's easy to have different defaults for one of them.

The current workaround, "export QEMU_CPU=POWER8" works only as long as
nothing purges the environment.

-- 
A tit a day keeps the vet away.

Bug#817093: ITP: golang-github-alecthomas-template -- text templates with newline elision for Go

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-alecthomas-template
  Version : 0.0~git20151201.0.14fd436
  Upstream Author : Alec Thomas
* URL : https://github.com/alecthomas/template
* License : BSD-3-clause
  Programming Lang: Go
  Description : text templates with newline elision for Go

This is a fork of the text/template package from Go 1.4 with the
addition that a backslash immediately after a closing delimiter
will delete all subsequent newlines until a non-newline.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817095: ITP: golang-github-alecthomas-units -- Go package for parsing byte units

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: golang-github-alecthomas-units
  Version : 0.0~git20151022.0.2efee85
  Upstream Author : Alec Thomas
* URL : https://github.com/alecthomas/units
* License : Expat
  Programming Lang: Go
  Description : Go package for parsing byte units

This package provides multipliers and string conversion functions
for byte units with support for decimal and binary SI prefixes.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817094: mercurial-keyring: fails to import Gnome module

[Fedor Uvarov]

Package: mercurial-keyring
Version: 0.6.7-1
Severity: important

Dear Maintainer,

Mercurial apparently can't access my keyring anymore. The following error
message appears when trying to push or pull to a password-protected repo:

*** failed to import extension mercurial_keyring: No module named Gnome

It didn't happen before, my credentials would be taken from the keyring
instead.

The reason may be the recent split of python-keyrings into "python-keyrings"
proper and "python-keyrings.alt". I have both packages installed, but it
doesn't help, perhaps imports in "mercurial-keyring" have to be adjusted.

Also note that there is a much newer upstream version available (1.0.1), which
is not even in unstable yet.



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

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

Versions of packages mercurial-keyring depends on:
ii  mercurial   3.5.2-2
ii  python-keyring  8.4.1-1
pn  python:any  

mercurial-keyring recommends no packages.

mercurial-keyring suggests no packages.

-- no debconf information

Bug#817092: libjs-handlebars: Minified source is non-free

[Luke Faraone]

Package: libjs-handlebars
Version: 1.3.0-1
Severity: serious
Justification: DSFG §2

Hello,

I noticed that, aside from the version in experimental, libjs-handlebars is
combined into a single file and already pre-"built". That means that Debian is
not distributing the actual source, which fails DFSG §2

  -- Luke Faraone

Bug#815760: (no subject)

[Martinx - ジェームズ]

On 24 February 2016 at 07:51, Christian Ehrhardt  wrote:

> Subject: ITP: dpdk -- Data Plane Development Kit
> Package: wnpp
> Owner: Christian Ehrhardt 
> Severity: wishlist
>
> * Package name: dpdk
>   Version : 2.2
>   Upstream Author : Thomas Monjalon 
> * URL : http://dpdk.org/
> * License : BSD (core libs), GPLv2 (kernel components)
>   Programming Lang: C
>   Description : Data Plane Development Kit
>
> 1. What is DPDK useful for
> DPDK is a set of libraries and drivers for fast packet processing. It
> was designed to run on any processors. The first supported CPU was Intel
> x86 and it is now extended to IBM Power 8, EZchip TILE-Gx and ARM. It
> runs mostly in Linux userland. A FreeBSD port is available for a subset
> of DPDK features.
>
> Main libraries
> - multicore framework
> - huge page memory
> - ring buffers
> - poll-mode drivers
>
> Usage
> These libraries can be used to:
> - receive and send packets within the minimum number of CPU cycles
>   (usually less than 80 cycles)
> - develop fast packet capture algorithms (tcpdump-like)
> - run third-party fast path stacks
> Some packet processing functions have been benchmarked up to hundreds
> million frames per second, using 64-byte packets with a PCIe NIC.
>
>
> 2. Maintenance Plan
> I'm currently maintaining dpdk for ubuntu (
> launchpad.net/ubuntu/+source/dpdk)
> and the existing packaging should be suitable for Debian also.
>
> It'd be great to have this packaged in Debian too, so that we can share the
> work. I am looking for co-maintainers to help me with this.
>
> But I'm not a Debian developer, so I'd like to have a more Debian centric
> co-maintainer for a proper Debian expertise and opinion in all the work.
> I'm also no DD, so sponsors will be needed.
>
>
It will be great to see DPDK on Debian Main too!

I have re-compiled this source DPDK Debian package, from Ubuntu, on Jessie
and it works.

Cheers!
Thiago

Bug#817091: ITP: acmetool -- automatic certificate acquisition tool for Let's Encrypt

[Peter Colberg]

Package: wnpp
Severity: wishlist
Owner: Peter Colberg 

* Package name: acmetool
  Version : 0.0.49
  Upstream Author : Hugo Landau
* URL : https://hlandau.github.io/acme
* License : Expat
  Programming Lang: Go
  Description : automatic certificate acquisition tool for Let's Encrypt

acmetool is an easy-to-use command line tool for automatically
acquiring TLS certificates from ACME servers such as Let's Encrypt,
designed to flexibly integrate into your webserver setup to enable
automatic verification.

acmetool is designed to work like make: you specify what certificates
you want, and acmetool obtains certificates as necessary to satisfy
those requirements. If the requirements are already satisfied,
acmetool doesn't do anything when invoked. Thus, acmetool is
ideally suited for use on a cron job; it will do nothing until
certificates are near expiry, and then obtain new ones.

acmetool is designed to minimise the use of state and be transparent
in the state that it does use. All state, including certificates, is
stored in a single directory, by default /var/lib/acme. The schema
for this directory is simple, comprehensible and documented.

This package will be maintained by the Debian Go team (Cc'ed).

Bug#817056: ITP: python-typing -- Type Hints for Python

[Brian May]

"Michael R. Crusoe"  writes:

>  This is a backport of the standard library typing module to Python
>  versions older than 3.5.

Not sure what the point of this is; doesn't typing hinting require PEP
3107, which isn't in Python 2.x?
-- 
Brian May 

Bug#817006: patch and intent to NMU

[Adam Borowski]

Control: tags -1 +patch

Hi!
Here's a patch (attached).

Because of the bug's severity, and, unlike the cooperate-or-divert issue
recently, the fix being obvious, I intend to NMU by, say, today evening,
unless you say something.  Proposed debdiff attached as well.


Meow!
-- 
A tit a day keeps the vet away.
>From b4653519c5109967be09976e1fbf431316d07dcf Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Tue, 8 Mar 2016 05:19:25 +0100
Subject: [PATCH] Remove dangling diverts introduced by 0.20.4-1.

---
 debian/openrc.postinst | 13 +
 1 file changed, 13 insertions(+)

diff --git a/debian/openrc.postinst b/debian/openrc.postinst
index 4d09a68..cd0284e 100644
--- a/debian/openrc.postinst
+++ b/debian/openrc.postinst
@@ -2,6 +2,19 @@
 
 set -e
 
+# Remove diverts made by 0.20.4-1
+if [ "$(dpkg-divert --list /usr/sbin/invoke-rc.d)" = \
+ "diversion of /usr/sbin/invoke-rc.d to /usr/sbin/invoke-rc.d.init-system-helpers by openrc" ]
+	then dpkg-divert --package openrc --remove --rename \
+		--divert /usr/sbin/invoke-rc.d.init-system-helpers /usr/sbin/invoke-rc.d
+fi
+if [ "$(dpkg-divert --list /usr/sbin/update-rc.d)" = \
+ "diversion of /usr/sbin/update-rc.d to /usr/sbin/update-rc.d.init-system-helpers by openrc" ]
+	then dpkg-divert --package openrc --remove --rename \
+		--divert /usr/sbin/update-rc.d.init-system-helpers /usr/sbin/update-rc.d
+fi
+
+
 if [ "${1}" = "configure" ] ; then
 	echo "Add existing services ..."
 
-- 
2.7.0

diff -Nru openrc-0.20.4/debian/changelog openrc-0.20.4/debian/changelog
--- openrc-0.20.4/debian/changelog  2016-03-04 19:25:52.0 +0100
+++ openrc-0.20.4/debian/changelog  2016-03-08 05:18:35.0 +0100
@@ -1,3 +1,10 @@
+openrc (0.20.4-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove diversions to update-rc.d + invoke-rc.d (Closes: #817006).
+
+ -- Adam Borowski   Tue, 08 Mar 2016 05:17:44 +0100
+
 openrc (0.20.4-2) unstable; urgency=high
 
   * Bump standard to 3.9.7.
diff -Nru openrc-0.20.4/debian/openrc.postinst 
openrc-0.20.4/debian/openrc.postinst
--- openrc-0.20.4/debian/openrc.postinst2016-03-04 19:25:52.0 
+0100
+++ openrc-0.20.4/debian/openrc.postinst2016-03-08 05:17:41.0 
+0100
@@ -2,6 +2,19 @@
 
 set -e
 
+# Remove diverts made by 0.20.4-1
+if [ "$(dpkg-divert --list /usr/sbin/invoke-rc.d)" = \
+ "diversion of /usr/sbin/invoke-rc.d to 
/usr/sbin/invoke-rc.d.init-system-helpers by openrc" ]
+   then dpkg-divert --package openrc --remove --rename \
+   --divert /usr/sbin/invoke-rc.d.init-system-helpers 
/usr/sbin/invoke-rc.d
+fi
+if [ "$(dpkg-divert --list /usr/sbin/update-rc.d)" = \
+ "diversion of /usr/sbin/update-rc.d to 
/usr/sbin/update-rc.d.init-system-helpers by openrc" ]
+   then dpkg-divert --package openrc --remove --rename \
+   --divert /usr/sbin/update-rc.d.init-system-helpers 
/usr/sbin/update-rc.d
+fi
+
+
 if [ "${1}" = "configure" ] ; then
echo "Add existing services ..."
 

Bug#815838: linux-image-3.16.0-4-amd64: Boot randomly fails with "Initramfs unpacking failed"

[Blake Miner]

By the way, I will re-test with the current kernel version (probably next
week) and report back the results.  In the meantime, any thoughts on what
might be causing this issue?

On Mon, Mar 7, 2016 at 11:21 PM Blake Miner  wrote:

> I no longer think that this bug is caused by kaslr.  I have actually
> narrowed down this problem to the bootable USB disk that I am using to boot
> the operating system.  I should have mentioned in my initial message that I
> am booting the system from a USB disk using a read-only partition.
>
> The problematic USB device is a SanDisk Cruzer Fit 8 GB USB 2.0
> Low-profile Flash Drive (SDCZ33-008G-B35).  I have many of these, and have
> tried over a dozen of them.  They all cause the "Initramfs unpacking
> failed" error on about 10-15% of bootups.  Annoyingly, I've counted over
> 100 bootups (with physically different matching PCs) and marked which ones
> fail.  The failures occur seemingly randomly about 10-15% of the time.
>
> Previously, I used several of these USB flash drives (which don't exhibit
> the problem at all): SanDisk Cruzer Fit CZ33 16GB USB 2.0 Low-Profile Flash
> Drive (SDCZ33-016G-B35).  These boot perfectly 100% of the time on the
> exact same PC hardware.
>
> Furthermore, I am using the same bootable image on both types of USB
> devices; I use a script to create identical-sized partitions, copy
> necessary files to the partition using fsarchiver, and then I have USB
> flash drives with identical images.  I should note that the primary boot
> partition is only 3.5 GB, so all data fits on either SanDisk device.
> The SDCZ33-008G-B35 exhibits the problem described in this bug report;
> whereas, the SDCZ33-016G-B35 does not.  The same data is on both devices,
> and they are both running on the exact same hardware.  I've tried different
> PCs (identical PCs, mind you), and the problem is consistent.
>
> The processors are not overclocked.  The BIOS performs a RAM test at boot
> (I haven't tried memtest86+), but I don't think RAM is a problem here.
> Like a mentioned above, the problem does not occur for the other 16 GB USB
> flash drive on the same hardware.
> --
> Blake Miner
> miner.bl...@gmail.com
>
-- 
Blake Miner
miner.bl...@gmail.com

Bug#815838: linux-image-3.16.0-4-amd64: Boot randomly fails with "Initramfs unpacking failed"

[Blake Miner]

I no longer think that this bug is caused by kaslr.  I have actually
narrowed down this problem to the bootable USB disk that I am using to boot
the operating system.  I should have mentioned in my initial message that I
am booting the system from a USB disk using a read-only partition.

The problematic USB device is a SanDisk Cruzer Fit 8 GB USB 2.0 Low-profile
Flash Drive (SDCZ33-008G-B35).  I have many of these, and have tried over a
dozen of them.  They all cause the "Initramfs unpacking failed" error on
about 10-15% of bootups.  Annoyingly, I've counted over 100 bootups (with
physically different matching PCs) and marked which ones fail.  The
failures occur seemingly randomly about 10-15% of the time.

Previously, I used several of these USB flash drives (which don't exhibit
the problem at all): SanDisk Cruzer Fit CZ33 16GB USB 2.0 Low-Profile Flash
Drive (SDCZ33-016G-B35).  These boot perfectly 100% of the time on the
exact same PC hardware.

Furthermore, I am using the same bootable image on both types of USB
devices; I use a script to create identical-sized partitions, copy
necessary files to the partition using fsarchiver, and then I have USB
flash drives with identical images.  I should note that the primary boot
partition is only 3.5 GB, so all data fits on either SanDisk device.
The SDCZ33-008G-B35 exhibits the problem described in this bug report;
whereas, the SDCZ33-016G-B35 does not.  The same data is on both devices,
and they are both running on the exact same hardware.  I've tried different
PCs (identical PCs, mind you), and the problem is consistent.

The processors are not overclocked.  The BIOS performs a RAM test at boot
(I haven't tried memtest86+), but I don't think RAM is a problem here.
Like a mentioned above, the problem does not occur for the other 16 GB USB
flash drive on the same hardware.
-- 
Blake Miner
miner.bl...@gmail.com

Bug#814070: Acknowledgement (curl: [SSL] curl fails to retrieve an url, wget works fine)

[gustavo panizzo]

I found a solution, or workaround to the problem

# cd /usr/local/share/ca-certificates
# wget https://www.thawte.com/roots/thawte_Premium_Server_CA.pem -O
thawte_Premium_Server_CA.crt
# update-ca-certificates

--
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

keybase: http://keybase.io/gfa

Bug#817090: Please backport 0.7.06 to Jessie

[Sean Whitton]

Package: duplicity
Severity: wishlist

0.7.06 introduces support for Amazon S3's Infrequent Access storage
class with the --s3-use-ia command line option.  This is useful on
servers running Jessie to save on backup costs, so it would be great to
have a backport.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#817089: mysql-5.5: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: mysql-5.5
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

This bug report replaces Bug #712913.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#817088: mysql-5.6: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Package: mysql-5.6
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

This bug report replaces Bug #815522.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#816376: Unfit upstream

[David Prévot]

Hi Sébastien,

Le 07/03/2016 12:43, Sébastien Villemot a écrit :

> On Tue, 1 Mar 2016 07:07:10 -0400 David Prévot  wrote:
> 
>> Upstream doesn’t wish to see their software in Debian anymore. Unless
>> the situation changes in the next few months, owncloud will not be part
>> of Stretch.

[…]
> I am wondering whether this outcome could be avoided.
> 
> If I understand correctly, your decision is essentially based on social
> issues (upstream hostile to Debian packaging), coupled to some technical
> aspects (complex upgrade paths).

That description fits roughly my view of the problem, yes.

> At first glance, this does not seem to prevent the package from staying
> in Debian. Maybe this just means that the package needs a new
> maintainer, who is willing to handle the tough interaction with upstream
> and dealing with the technical issues

That might work. I honestly doubt upstream would be willing to have its
pet project properly packaged by anyone in the near future (most
distributions gave up before us), but I’d be happy to be proven wrong.

> You are certainly in a better position than me to ascertain whether the
> package can stay in Debian or not, but I think that it would be useful
> if you could give a little more background on the issues that you
> encountered.

Reading the (recent) threads on both the maintainer and upstream lists
should help anyone to make their mind about it (I’ll give a few
pointers). Seeing how Debian is described in upstream staff blog posts
and issue tracker goes further down (I don’t wish to publish some direct
links from the BTS, but they’re not hard to find).

[ When I realized they were going to make our life way more painful ]
https://lists.alioth.debian.org/pipermail/pkg-owncloud-maintainers/2016-February/002882.html

[ When they considered enforcing their trademark to throw us away ]
https://mailman.owncloud.org/pipermail/devel/2016-February/002106.html

> And, if you think it makes sense to orphan the package,
> that would help prospective new maintainers in making the decision to
> adopt the package or not.

I’m happy to give anyone write (and admin) access to our current
infrastructure. Feel free to open an RFA or O wnpp bug on my behalf if
you think it might help. But please, be aware that the enormous owncloud
package is only the tip of the iceberg: beyond the ~70 packages (some
were already removed via #816769) listed on the [DDPO], I was
maintaining a few more dozens on the PHP PEAR (and composer) Maintainers
team as well as some JavaScript packages.

DDPO:
https://qa.debian.org/developer.php?login=pkg-owncloud-maintainers%40lists.alioth.debian.org

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#817087: support multiple tor daemon instances

[Paul Wise]

Package: onioncircuits
Severity: wishlist

It would be nice to be able to view the circuits from the Tor daemon
run by the Tor Browser in addition to the system Tor daemon. Right now
I can't see any support for this in the UI, --help or manual page.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817086: clicking on circuits doesn't show any info

[Paul Wise]

Package: onioncircuits
Version: 0.3-1
Severity: important

When I click on circuits onioncircuits doesn't show any info and I get
this traceback in the terminal.

pabs@chianamo ~ $ onioncircuits 
Traceback (most recent call last):
  File "/usr/bin/onioncircuits", line 517, in cb_treeselection_changed
self.show_circuit_details(circuit)
  File "/usr/bin/onioncircuits", line 534, in show_circuit_details
self.display_node(self.controller.get_network_status(fp))
  File "/usr/bin/onioncircuits", line 544, in display_node
country = self.controller.get_info("ip-to-country/%s" % 
status_entry.address)
  File "/usr/lib/python3/dist-packages/stem/control.py", line 414, in wrapped
raise exc
  File "/usr/lib/python3/dist-packages/stem/control.py", line 409, in wrapped
return func(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/stem/control.py", line 1113, in get_info
raise exc
  File "/usr/lib/python3/dist-packages/stem/control.py", line 1066, in get_info
stem.response.convert('GETINFO', response)
  File "/usr/lib/python3/dist-packages/stem/response/__init__.py", line 135, in 
convert
message._parse_message(**kwargs)
  File "/usr/lib/python3/dist-packages/stem/response/getinfo.py", line 40, in 
_parse_message
raise stem.ProtocolError("GETINFO response didn't have an OK status:\n%s" % 
self)
stem.ProtocolError: GETINFO response didn't have an OK status:
GeoIP data not loaded

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (900, 'testing'), (860, 'testing-proposed-updates'), (850, 
'buildd-testing-proposed-updates'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental'), (690, 'buildd-experimental'), (500, 
'unstable-debug'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages onioncircuits depends on:
ii  gir1.2-glib-2.01.46.0-4
ii  gir1.2-gtk-3.0 3.18.8-1
ii  python33.5.1-2
ii  python3-gi 3.18.2-2+b1
ii  python3-pycountry  1.8+ds1-0.1
ii  python3-stem   1.4.1b-2
pn  python3:any

onioncircuits recommends no packages.

onioncircuits suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817082: #Bug#817082: ruby2.3-tcltk: TypeError "wrong argument type nil" when adding an Image to a canvas

[Christian Hofstaedtler]

Control: tags -1 + confirmed upstream
Control: forwarded -1 https://bugs.ruby-lang.org/issues/12156

Caused by upstream commit cdaa94eab443919ecac3484c0f567eca773d686e
Author: nobu 
Date:   Sun Dec 13 09:26:30 2015 +

tkutil.c: check arg

* ext/tk/tkutil/tkutil.c (tk_hash_kv): check types of array
  argument.  reported by Marcin 'Icewall' Noga of Cisco Talos.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@53077 
b2dd03c8-39d4-4d8f-98ff-823fe69b080e


Glancing at the code this might need to check for Qnil first.

-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-

Bug#679763: debsnap: bisect option/script

[Paul Wise]

On Mon, 2016-03-07 at 21:44 +0900, Osamu Aoki wrote:

> For source history, "gbp inport-dscs --debsnap" gives you access to real
> "git bisect" access.  So no point reinvention it in debsnap itself.

I wasn't aware of that, thanks for the tip.

> (Yes, I am living in high bandwidth region.)

Yeah, for me that would be a prohibitive exercise.

I can't imagine how Joey Hess would use that ;)

> For binary package history checking, dependency etc. matters and most
> likely needs your manual attention.  At least with the new --list option
> printing out sorted list of versions, you can do bisect like action
> manually whice checking dependencyetively recent versions. 

I don't see any --list option in the debsnap in unstable.

pabs@chianamo ~ $ debsnap --binary --list libc6
Unknown option: list
...

I would really like to see a general bisect tool that could wrap
debsnap and other bisect situations.

This can be hacked around using a fake git repo and git bisect though,
so once debsnap --list is available that should be enough.

> Do you still think we should add complexities into debsnap?

No. 

Please close this bug with the upload that adds debsnap --list.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise




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

Bug#817085: unison: Cannot run emacs from merge tool

[Ian Zimmerman]

Package: unison
Version: 2.40.65-2
Severity: normal

Quoting the long and annoyingly flat reference manual:

>>
A large number of external merging programs are available. For
example, on Unix systems setting the merge preference to

   merge = Name *.txt -> diff3 -m CURRENT1 CURRENTARCH CURRENT2
> NEW || echo "differences detected"

will tell Unison to use the external diff3 program for merging.
Alternatively, users of emacs may find the following settings
convenient:

   merge = Name *.txt -> emacs -q --eval '(ediff-merge-files-with-ancestor
 "CURRENT1" "CURRENT2" "CURRENTARCH" nil "NEW")'
<<

Yea, they may; if, presumably like the author, they never run emacs in
its text mode aspect.  Then they'll find out it doesn't work, because
unison runs the merge tool (just like any other external program) with
stdin connected to an empty pipe, and emacs expects the terminal there.

unison should leave the stdin alone when forking external programs, even
if it would take a bit more coding due to deficiency of the ocaml
standard library.

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

Kernel: Linux 3.12.55.2 (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

Versions of packages unison depends on:
ii  libc6  2.13-38+deb7u10

Versions of packages unison recommends:
ii  openssh-client [ssh-client]  1:6.6p1-4~bpo70+1

Versions of packages unison suggests:
pn  unison-all  

Bug#817057: network-manager-openconnect: Update unstable version to latest Upstream Build

[Ryan Chewning]

Michael, I copied you on this bug as you're the package maintainer for
network-manager-openconnect and the imports of the upstream are failing.
Currently, upstream for network-open-connect is at 1.91 and in Debian
unstable/testing are both on the 1.0.2 release which isn't working with the
network-manager builds in unstable and are on 1.91. I'm attempting to
create an openconnect vpn profile but I get the following error messages in
my .xsession-error log when launching nm-connection editor

"""
** Message: vpn: (iodine,/usr/lib/NetworkManager/VPN/nm-iodine-service.name)
cannot load legacy-only plugin
** Message: vpn: (ssh,/usr/lib/NetworkManager/VPN/nm-ssh-service.name)
cannot load legacy-only plugin
** Message: vpn: (openconnect,/usr/lib/NetworkManager/VPN/
nm-openconnect-service.name) cannot load legacy-only plugin
** Message: vpn: (strongswan,/etc/NetworkManager/VPN/
nm-strongswan-service.name) cannot load legacy-only plugin


I also only have the option to configure the following three types of vpns
OpenVPN, PPTP or KVPNC even though I have iodine, ssh, openconnect and
strongswan installed.

If you think this bug is better suited for the network-manager package
please let me know and I'll head over that way.

Thanks,

Ryan

On Mon, Mar 7, 2016 at 12:22 PM, Michael Stapelberg 
wrote:

>
>
> On Mon, Mar 7, 2016 at 9:07 AM, Ryan Chewning  wrote:
>
>> Package: network-manager-openconnect
>> Version: 1.0.2-1+b1
>> Severity: grave
>> Tags: upstream
>> Justification: renders package unusable
>>
>> The latest builds of networkmanager in testing/unstable no longer support
>> dbus. https://blogs.gnome.org/dcbw/2016/02/19/die-dbus-glib-die/
>>
>
> I’m only a bystander for the purpose of this bug, but “networkmanager […]
> no longer supports dbus” conflicts with the article you refer to, which
> mentions:
>
> """
> I cannot understate how much work this was and how much careful planning
> we (well, mostly Dan Winship) did to ensure we didn’t break backwards
> compatibility of either the utility libraries or the D-Bus interface.
> """
>
> The way I read this, the new networkmanager version is
> backwards-compatible with regards to its D-Bus interface.
>
> Can you clarify? If it turns out that it’s actually backwards-compatible,
> is severity: grave still justified?
>
>
>> There is an updated version of the network-manager-openconnect but it is
>> failing to be pulled down by uscan. Manual intervention is needed.
>>
>> Thanks,
>>
>> Ryan
>>
>> -- System Information:
>> Debian Release: stretch/sid
>>   APT prefers testing-updates
>>   APT policy: (500, 'testing-updates'), (500, 'testing')
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
>>
>> Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages network-manager-openconnect depends on:
>> ii  adduser   3.113+nmu3
>> ii  libc6 2.21-9
>> ii  libdbus-1-3   1.10.6-1
>> ii  libdbus-glib-1-2  0.106-1
>> ii  libglib2.0-0  2.46.2-3
>> ii  libnm-glib-vpn1   1.1.90-6
>> ii  libnm-glib4   1.1.90-6
>> ii  libnm-util2   1.1.90-6
>> ii  network-manager   1.1.90-6
>> ii  openconnect   7.06-2+b2
>>
>> network-manager-openconnect recommends no packages.
>>
>> network-manager-openconnect suggests no packages.
>>
>> -- no debconf information
>>
>>
>
>
> --
> Best regards,
> Michael
>

Bug#778642: xfce4-power-manager-plugins: Serious memory leak in libxfce4powermanager.so

[Kevin Kratzer]

I'm experiencing the same for Xubuntu 15.10 on a Surface Pro 3 and added a
comment to the ubuntu bug tracker where an issue was already present.

For reference:
https://bugs.launchpad.net/ubuntu/+source/xfce4-power-manager/+bug/1534963

Thanks,

Kevin

Bug#817084: grub2: [INTL:ja] Japanese debconf templates translation update

[Takuma Yamada]

Source: grub2
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

Here's Japanese po-debconf templates translation (ja.po) file that 
reviewed by several Japanese Debian developers and users.

This bug report replaces Bug #815203.

Please copy the attachment into debian/po/ja.po.

Kind regards.
--
Takuma Yamada


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

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


ja.po.gz
Description: application/gzip

Bug#807264: dpkg: Please allow negative Architecture lists in debian/control

[Guillem Jover]

Control: merge 797347 -1

On Sun, 2015-12-06 at 21:49:52 +0100, Axel Beckert wrote:
> Package: dpkg
> Version: 1.18.3
> Severity: wishlist

> it's rather tedious to find the correct "Architecture:" value for a
> binary package -- and also to keep it uptodate with the growing list of
> architecture -- if only one or two architectures need to be excluded.
> 
> It would be very convenient and also future-proof if I could specify
> e.g. "!arm64 !any-arm" in the "Architecture:" field in a binary
> package stanza in debian/control, in line with the negative architecture
> lists that can used for build-dependencies.

This was filed some time ago. There's some rationale on the other bug
report, but after some more consideration I'm not sure allowing this
would be a good idea.

The Architecture field percolates into many places, which means lots
of things would need to be hunted down and updated.

It gets into .dsc and .changes Architecture fields. Also in the arch
key/value in the Package-List field in the .dsc. Not to mention
anything that parses the Architecture field directly from debian/control.

Can you present a case where using a negative specification would be
more correct than a positive one? In general I think the main cases
to consider are, a package supports a specific set of kernels, in
which case positive kernel wildcard might seem best. Then there's the
packages that either are specific to a very tiny set of architectures,
like ia64-specific tools or firmware (positive here too). And then
packages which might fail to build on a wider set of architectures,
due to things like endianness, alignment, etc. In which case I think
the correct thing to do is to mark the package as ‘any’ and let the
porters port it.

The difference between the Architecture field and the arch restrictions
in dependencies is that the latter accept alternatives, so you might
want to say things like:

  libalsa-dev [linux-any] | liboss-dev [!linux-any]

for example, which does not apply in binary packages.

Thanks,
Guillem

Bug#816682: live-installer: Inaccessible utility

[Cyril Brulebois]

Samuel Thibault  (2016-03-08):
> There was also a bug in at-spi2-atk, I have uploaded a fixed package.
> 
> So, to summarize the needed steps to get d-i accessible from debian live:
> 
> - at-spi2-atk fix (debian/patches/p2p), done.
> - adding a udeb for libgail-common & libgail18, filed as #816720
> - setting GTK_MODULES=gail:atk-bridge in the debian-installer.sh script,
> filed as #816705
> - adding the content of libgail-common-udeb and libatk-adaptor-udeb to
> the d-i image used by the live installer.  I don't know which image the
> live installer uses, is it just using the standard gtk d-i image (in
> which case we can just add the packages to g-i), or is it building its
> own image?

Would probably make sense to include debian-live/debian-cd at some
point… Doing so to get their input, along with irl@ who helped with
getting live stuff built on d.o machines IIRC.


KiBi.


signature.asc
Description: Digital signature

Bug#817079: Acknowledgement (autopkgtest: *3* copies for running a test?!)

[Rene Engelhard]

Hi,

and when I run the tests they run in *real-tree*:

From the same run as the initial report:

[...]
adt-run: DBG: testbed command ['test', '-e', 
'/tmp/adt-run.tQVlcc/build.G5O/real-tree'], kind short, sout raw, serr raw, env 
[]
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: copydown: tb path /tmp/adt-run.tQVlcc/build.G5O/real-tree already 
exists
adt-run [01:36:25]: test junit-subsequentcheck: [---
adt-run: DBG: testbed command ['bash', '-c', 'set -e; export USER=`id -nu`; . 
/etc/profile >/dev/null 2>&1 || true;  . ~/.profile >/dev/null 2>&1 || true; 
buildtree="/tmp/adt-run.tQVlcc/build.G5O/real-tree"; mkdir -p -m 1777 -- 
"/tmp/adt-run.tQVlcc/junit-subsequentcheck-artifacts"; export 
ADT_ARTIFACTS="/tmp/adt-run.tQVlcc/junit-subsequentcheck-artifacts"; export 
ADTTMP=$(mktemp -d --tmpdir adttmp.XX); export 
DEBIAN_FRONTEND=noninteractive; export LANG=C.UTF-8; export 
DEB_BUILD_OPTIONS=parallel=$(grep -c ^processor /proc/cpuinfo | sed 
\'s/^0$/1/\'); unset LANGUAGE LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   
LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE 
LC_MEASUREMENT LC_IDENTIFICATION LC_ALL;rm -f /tmp/adt_test_script_pid; set -C; 
echo $$ > /tmp/adt_test_script_pid; set +C; trap "rm -rf $ADTTMP 
/tmp/adt_test_script_pid" EXIT INT QUIT PIPE; chmod 755 $ADTTMP; cd 
"$buildtree"; chmod +x 
/tmp/adt-run.tQVlcc/build.G5O/real-tree/debian/tests/junit-subsequentcheck; 
touch /tmp/adt-run.tQVlcc/junit-subsequentcheck-stdout 
/tmp/adt-run.tQVlcc/junit-subsequentcheck-stderr; 
/tmp/adt-run.tQVlcc/build.G5O/real-tree/debian/tests/junit-subsequentcheck 2> 
>(tee -a /tmp/adt-run.tQVlcc/junit-subsequentcheck-stderr >&2) > >(tee -a 
/tmp/adt-run.tQVlcc/junit-subsequentcheck-stdout); '], kind test, sout raw, 
serr raw, env []
== Patching the tree to only build Java-based unittests against an existing 
installation ==
patching file jurt/Module_jurt.mk
patching file postprocess/Module_postprocess.mk
patching file solenv/gbuild/JavaClassSet.mk
patching file solenv/gbuild/JunitTest.mk
Hunk #1 succeeded at 55 (offset 1 line).
patching file solenv/gbuild/Module.mk
patching file solenv/gbuild/extensions/post_SkipBuild.mk
patching file solenv/gbuild/platform/unxgcc.mk

== Generating configuration ===
[...]
== Cleaning tree ==
rm -fr /tmp/adt-run.tQVlcc/build.G5O/real-tree/test-install
rm -fr /tmp/adt-run.tQVlcc/build.G5O/real-tree/instdir
rm -fr /tmp/adt-run.tQVlcc/build.G5O/real-tree/workdir

== Enabling core dumps ==

== Starting subsequentcheck with  job against 
path:/usr/lib/libreoffice/program/soffice ==
Automatic fetching of external tarballs is disabled.
mkdir -p /tmp/adt-run.tQVlcc/build.G5O/real-tree/instdir
/tmp/adt-run.tQVlcc/build.G5O/real-tree/solenv/bin/install-gdb-printers -a 
/tmp/adt-run.tQVlcc/build.G5O/real-tree/instdir -c
make -j 3  -rs -f /tmp/adt-run.tQVlcc/build.G5O/real-tree/Makefile.gbuild
subsequentcheck
[...]
[build JUT] chart2_unoapi
[build JUT] comphelper_complex
[build JUT] configmgr_unoapi
[build JUT] dbaccess_complex
[build JUT] dbaccess_unoapi
[build JUT] extensions_unoapi
[build JUT] forms_unoapi_1
[build JUT] forms_unoapi_2
[build JUT] forms_unoapi_3
[build JUT] forms_unoapi_4
[build JUT] forms_complex
[build JUT] framework_complex
[build JUT] framework_unoapi
[build JUT] juh
[build JUT] linguistic_unoapi
[build JUT] qadevOOo_unoapi
[build JUT] ridljar_typedesc
[build JUT] ridljar_uno
[build JUT] ridljar_util
[build JUT] sc_complex
[build JUT] sc_unoapi_1
[build JUT] sc_unoapi_2
[build JUT] sc_unoapi_3
[build JUT] sc_unoapi_4
[build JUT] sc_unoapi_5
[build JUT] sc_unoapi_6
[build JUT] sc_unoapi_7
[build JUT] sd_unoapi
[build JUT] sfx2_complex
[build JUT] sfx2_unoapi
[build JUT] sot_complex
[build JUT] starmath_unoapi
[build JUT] svl_complex
[build JUT] svtools_unoapi
[build JUT] svx_unoapi
[build JUT] sw_complex
[build JUT] sw_unoapi_1
[build JUT] sw_unoapi_2
[build JUT] sw_unoapi_3
[build JUT] sw_unoapi_4
[build JUT] toolkit_complex
[build JUT] ucb_complex
[build JUT] ucb_unoapi
[build JUT] unotools_complex
[build JUT] unoxml_complex
[build JUT] unordf_complex
[build JUT] xmloff_unoapi
[...]
adt-run: DBG: sending command to testbed: copyup 
/tmp/adt-run.tQVlcc/junit-subsequentcheck-stdout 
/tmp/adt-run.output.bkjzczum/junit-subsequentcheck-stdout
adt-run: DBG: got reply from testbed: ok
adt-run: DBG: sending command to testbed: copyup 
/tmp/adt-run.tQVlcc/junit-subsequentcheck-stderr 
/tmp/adt-run.output.bkjzczum/junit-subsequentcheck-stderr
adt-run: DBG: got reply from testbed: ok
adt-run [02:05:41]: test junit-subsequentcheck:  - - - - - - - - - - results - 
- - - - - - - - -
junit-subsequentcheck PASS
[...]
junit-subsequentcheck PASS
pyuno-import PASS
adt-run: DBG: testbed stop
adt-run: DBG: testbed close, scratch=/tmp/adt-run.tQVlcc
adt-run: DBG: sending command to testbed: close

so what is the cp to tests-dir for?

Regards,

Rene

Bug#811037: dpkg: "Security labeling" not loading in armhf installed on Android devices

[Guillem Jover]

Hi!

On Thu, 2016-01-14 at 23:57:28 -0500, Alan Corey wrote:
> Package: dpkg
> Version: 1.18.1
> Severity: normal

> I'm using armhf Debian on a phone, NOT in a chroot, by using basically an
> adapted Debian Kit to get Jessie instead of somethiing old.  Almost
> everything I install gives the error message "security labeling handle: no
> such file or directory".  I found on the web a workaround of sorts by
> remounting /sys/fs/selinux readonly during the installation, but this causes
> Android to panic and lock up after about 1 minute.  Normally this works in a
> terminal emulator or over a VNC or SSH connection concurently with Android
> apps.  Old versions of Debian from a year ago didn't have this problem, and
> it may be compunded by the fact that Android shipped with selinux in
> permissive mode until 5.0.  Going to permissive mode has little affect on
> the problem.
> 
> It seems to come from src/selinux.c which is where the error message can be
> found.  It seems like at least if you set selinux to permissive this should
> only be a warning, not stop the install.  Or maybe it could be a new --force
> option to dpkg.

Right, that makes sense, and I wrote a patch to add such --force
option when you filed the bug report, but one problem is that
dpkg-statoverride also sets SE labels, and dpkg would need a way to
pass the force option somehow to the child program. Which means
programs might still fail. :/

But I could certainly try to make it non-fatal on non-enforcing mode.

> dpkg 1.16.16 doesn't have this problem, I don't know exactly when it
> started.  1.17.25 and 1.18.4 have problems.

This was a code change prompted by a conversation with SE Linux
upstream on what the preferred way to do SE labelling was.

Thanks,
Guillem

Bug#817083: debconf templates are not loaded in prerm

[Ben Hutchings]

Package: debconf
Version: 1.5.58
Severity: important

It appears that using debconf in a preinst or postinst script causes
debconf templates to be loaded automagically.  However, since version
4.4.1-1~exp1 the linux-image-* packages only use debconf in the prerm
script.  In the case where the script asks a question, debconf does
not find the template and the prerm script fails.

The manual page for debconf-loadtemplate says it should never be used
from maintainer scripts, so I don't see how we're supposed to make
this work.

Ben.

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

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

Bug#817082: ruby2.3-tcltk: TypeError "wrong argument type nil" when adding an Image to a canvas

[IpsumJ]

Package: ruby2.3-tcltk
Version: 2.3.0-4
Severity: normal

Dear Maintainer,

the tcltk lib for ruby2.3 crashes with a TypeError when adding an Image
to a canvas.

A simplified (and tested) version of my code:

require 'tk'
require 'tkextlib/tkimg'

root = TkRoot.new
canvas = TkCanvas.new root
canvas.grid :column => 0, :row => 0
img = TkPhotoImage.new :file => "/tmp/l.png"
TkcImage.new canvas, 0, 0, :anchor => :nw, :image => img
Tk.mainloop

When i run it with ruby2.2 it works faultlessly, with ruby2.3 it crashes
at "TkcImage.new" with the following message:

/usr/lib/ruby/2.3.0/tk/itemconfig.rb:115:in `hash_kv': wrong argument
type nil (expected Array) (TypeError)
from /usr/lib/ruby/2.3.0/tk/itemconfig.rb:115:in `itemconfig_hash_kv'
from /usr/lib/ruby/2.3.0/tk/canvas.rb:722:in `_parse_create_args'
from /usr/lib/ruby/2.3.0/tk/canvas.rb:735:in `create'
from /usr/lib/ruby/2.3.0/tk/canvas.rb:758:in `create_self'
from /usr/lib/ruby/2.3.0/tk/canvas.rb:751:in `initialize'
from ui.rb:8:in `new'
from ui.rb:8:in `'

The image file type seems irrelevant, i have tested a hand full of
formats with the same result.

Sincerely.

IpsumJ

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

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

Versions of packages ruby2.3-tcltk depends on:
ii  libc6   2.21-9
ii  libgmp102:6.1.0+dfsg-2
ii  libruby2.3  2.3.0-4
ii  libtcl8.5   8.5.19-1
ii  libtk8.58.5.19-1
ii  libx11-62:1.6.3-1

ruby2.3-tcltk recommends no packages.

ruby2.3-tcltk suggests no packages.

Bug#799283: ITP: mailman3-client -- Mailing list management system

[Pierre-Elliott Bécue]

Le jeudi 17 septembre 2015 à 16:30:04+0200, Pierre-Elliott Bécue a écrit :
> On jeu. 17 sept. 2015 à 16:25:25, Pierre-Elliott Bécue wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Pierre-Elliott Bécue" 
> > 
> > * Package name: mailman3-client
> >   Version : 1.0.0
> >   Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian 
> > Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj
> > * URL : http://list.org/
> > * License : LGPLv3
> >   Programming Lang: Python2
> >   Description : Official python bindings for mailman3-core REST API
> > 
> > This package would provide the client for REST API of mailman3-core. It
> > would depend on mailman3-core, and provide the other minimal part in
> > order to have mailman3 working correctly.
> > 
> > --
> > 
> > There is currenctly mailman2 in Debian archive, and I was considering
> > involve myself in packaging mailman3 suite, Mailman developers seems to
> > think that it is a pretty good idea, but they suggested me to wait 'till
> > mailman3-core version 3.1.0 is out.
> > 
> > I'm currently looking for some sponsorship as I'm not a Debian
> > Developer, nor used to build brand new packages. Since version 3.1 is
> > not released yet, I've some time to learn but I'll be happy to work with
> > people already used to packaging.
> > 
> > This bug report is CC-ed to Mailman for Debian team, as I do intend to
> > collaborate with them, I hope I'll make myself helpful.
> > 
> > This bug report will come with the others for the others components of
> > Mailman3 suite. I hope this is the good way of doing ITP
> 
> Oops, typo spotted here, proposed Package name would be mailman3-client.
> 
> Sorry for that.

Github/my personal gitlab repo for this package :

 * https://gitlab.pimeys.fr/PEB/mailman3-client
 * https://github.com/P-EB/mailman3-client

Builds and passes.

Will RFS as soon as others parts build and pass.

-- 
PEB

Bug#812783: dpkg: Please use ASAN, UBSAN and bindnow on hardened1-linux-amd64

[Guillem Jover]

Control: block -1 by 812782

On Fri, 2016-01-29 at 12:55:42 +0100, Bálint Réczey wrote:
> 2016-01-29 0:46 GMT+01:00 Guillem Jover :
> > On Tue, 2016-01-26 at 15:33:40 +0100, Balint Reczey wrote:
> >> Package: dpkg
> >> Version: 1.18.4
> >> Severity: wishlist
> >> Tags: patch
> >> User: bal...@balintreczey.hu
> >> Usertags: hardened1-linux-amd64
> >
> >> This is the second patch enabling extra flags in dpkg in case the
> >> hardened1-linux-amd64 port is accepted in #812782.
> >
> >> diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
> >> index db40b2c..2f39d82 100644
> >> --- a/scripts/Dpkg/Vendor/Debian.pm
> >> +++ b/scripts/Dpkg/Vendor/Debian.pm
> >> @@ -177,6 +177,14 @@ sub _add_reproducible_flags {
> >
> >> +if ($abi =~ /^(?:gnuhardened1)$/) {
> >> + # Enable bindnow on hardened ports
> >> + $use_feature{bindnow} = 1;
> >> +}
> >> +
> 
> > Unfortunately I don't think this is a good idea. Due to at least two
> > reasons. First not all packages are using dpkg-buildflags, which means
> > that many will simply fail to build if one of the libraries they use
> > is using ASAN but the program is not (AFAIUI). And because this is

> I plan providing patches for those packages, but I see your point.
> 
> > part of the ABI so it should really be a default in the compiler. This
> > is part of the architecure definition. So this to me seems like the
> > wrong place to set these.

> I'm working towards to adding those as default GCC flags. I have already added
> PIE which I previously set in dpkg: #812889 .

Actually setting bindnow and PIE would be fine as part of the default
build flags from dpkg, because those do not change the ABI in
principle. And those are the only ones I'd accept from this bug
report, but certainly not the ABI changing ones.

> Setting the flags in dpkg makes it possible to create the port before the GCC
> patches are stable. My thinking was that I could migrate to changing GCC later
> without breaking the ABI.

Not an option really. Having a stable ABI is a prerequisite for any new
dpkg architecture, until that has happened I'm not planning on considering
such additions.

Thanks,
Guillem

Bug#816682: live-installer: Inaccessible utility

[Samuel Thibault]

Hello,

There was also a bug in at-spi2-atk, I have uploaded a fixed package.

So, to summarize the needed steps to get d-i accessible from debian live:

- at-spi2-atk fix (debian/patches/p2p), done.
- adding a udeb for libgail-common & libgail18, filed as #816720
- setting GTK_MODULES=gail:atk-bridge in the debian-installer.sh script,
filed as #816705
- adding the content of libgail-common-udeb and libatk-adaptor-udeb to
the d-i image used by the live installer.  I don't know which image the
live installer uses, is it just using the standard gtk d-i image (in
which case we can just add the packages to g-i), or is it building its
own image?

Samuel

Bug#694733: marked as done (RFP: sassc -- Sass is a pre-processor language for CSS)

[Jonas Smedegaard]

Quoting Raphaël (2016-03-08 01:11:21)
> On Tue, Mar 08, 2016 at 12:59:32AM +0100, Jonas Smedegaard wrote:
> > NB! You replied to the ITP bug for _sassc_ but seems what you are 
> > requesting is an update of _libsass_.  I will update libsass.
> 
> you're right.
> I believed there were bundled together and overlooked package info.
> Sorry for this

No problem.  You are credited for nudging in the changelog of the new 
package being compiled now - just please in the future use our regular 
procedure. :-)

 - Jonas

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

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


signature.asc
Description: signature

Bug#817081: gitpkg: add compatibility for old pristine-tar

[David Bremner]

Package: gitpkg
Version: 0.27
Severity: normal
Tags: patch

It turns out we missed a subtlty when parsing the pristine-tar branch;
at some point in 2012 pristine-tar switched from storing commits to
storing trees. Attached is a patch to the relevant hook that handles
both trees and commits in a .id file

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

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

Versions of packages gitpkg depends on:
ii  dpkg-dev  1.18.4
ii  git   1:2.7.0-1

gitpkg recommends no packages.

Versions of packages gitpkg suggests:
ii  devscripts  2.16.1

-- no debconf information
>From 01e656021e9ef16c34404841836e7f9649ec1567 Mon Sep 17 00:00:00 2001
From: David Bremner 
Date: Mon, 7 Mar 2016 20:22:34 -0400
Subject: [PATCH] pristine-tar-pre-export-hook: fix for pre 1.22 pristine-tar

If the id we're looking for shows up as a commit instead of a tree, be
happy and use it
---
 debian/changelog   | 7 +++
 hooks/pristine-tar-pre-export-hook | 7 ++-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 952d4a2..a925ebb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+gitpkg (0.28) unstable; urgency=medium
+
+  * pristine-pre-export-hook: copy with data from pre-1.22 versions of
+pristine-tar that used commits rather than trees
+
+ -- David Bremner   Mon, 07 Mar 2016 20:21:19 -0400
+
 gitpkg (0.27) unstable; urgency=medium
 
   * git-debcherry: Strip trailing slash from patch dir.  Closes: #784130
diff --git a/hooks/pristine-tar-pre-export-hook b/hooks/pristine-tar-pre-export-hook
index 709b328..a98bf7e 100644
--- a/hooks/pristine-tar-pre-export-hook
+++ b/hooks/pristine-tar-pre-export-hook
@@ -34,7 +34,12 @@ if [ -n "$DEB_ORIG" ]; then
 commit=""
 while read -r hash tree; do
 	if [ "$tree" == "$pt_tree" ]; then
-	commit=$hash
+	if [ "$hash" == "commit" ]; then
+		# pre-1.22 pristine-tar used commits in id files
+		commit=$tree
+	else
+		commit=$hash
+	fi
 	continue
 	fi
 done < <(git rev-list --pretty="%H %T" $GITPKG_TREEISH --)
-- 
2.7.0

Bug#811094: Broken configuration in testing

[RHATAY Sami]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

I have the same problem in testing with libpam-poldi version 4.2. The
configuration file is correct with the right path to scdaemon in
`/usr/lib/gnupg2/scdaemon` , but poldi is still looking in /usr/bin/
to find it.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJW3hadAAoJEFCPeZVwDrLBT4EP/2ltkkb745aC7FM4VqeEciKr
OR7Mc7mrvqkN1iR/XH5nGrSCvGwLj3wMwqwcL7u7GDqfcA56KJvkrqk8tFKh+G7n
HKIX048Y06MlLcM/ktvPiorpMq4/rJ+SUMcGaTRvf1oEcutDbWc3FcQmmGfJq63Q
JCz+UeRqRQoa035WOUWMpk78yX3PWZKkTKOzzURIJB2w5Fj27NZ838Q8hfNLCLwm
I9jciXjbTIJsS3/fsBxvNps6qscwsWr4AmuwPCJPRJiL8T9oVngoIhbAxTqRhwTe
E+R/Jgp3IzI5EvX5VveSJAq0rJRenC3Z1rA6hxYkiU5gL0xd3SNsgl0PBMi7zQia
D1cEgSJsnbyvj8n0Uk3Z6AmHeqijlSqADePvbM/CHR4Wz8XcYFQjwzN2/D4WNwAT
K28mu+hAVOgcs2KzT2UykSVrVw15tuhsCwGhAfTEYRSDtPtHh9vM/c4I/B7gebHr
cniWgUhIdDT05Y94El/XJH6eavGvdJLCapyJfKdK08ywhY4W052Fo9JlB+uEkr3X
CJcr+mahhHWIsy+Xkt6e8MfKunRY6LpDpv8Bwjx3AD6/86UqUsZR6RzsZF5a+502
JQpVuQGwFVM8At943BhHXnn0kFptVzmEaan2neMOEMb1FeVo4CnHH9c0YRlnGnJL
gpCOZySQ/GOqqL8CutAY
=3XAp
-END PGP SIGNATURE-

Bug#817080: debci: no -dbgsym packages available

[Rene Engelhard]

Source: debci
Severity: important

Hi,

I've seen

https://ci.debian.net/data/packages/unstable/amd64/libr/libreoffice/20160307_230826.autopkgtest.log.gz.

That one says:

[...]
Broken adt-satdep:amd64 Depends on libreoffice-core-dbgsym [ amd64 ] < none > ( 
none )
  Removing adt-satdep:amd64 because I can't find libreoffice-core-dbgsym:amd64
[...]

and thus it of course fails

badpkg: Test dependencies are unsatisfiable. A common reason is that your 
testbed is out of date with respect to the archive, and you need to use a 
current testbed or run apt-get update or use -U.
adt-run [23:12:48]: ERROR: erroneous package: Test dependencies are 
unsatisfiable. A common reason is that your testbed is out of date with respect 
to the archive, and you need to use a current testbed or run apt-get update or 
use -U.

I've had -dbg (and then -dbgsym) as Depends: of the tests so that if they
crashed one had a bt. Now with -dbgsym and the move to the debug archive
they are not automatically available anymore.

(I've now done 
http://anonscm.debian.org/cgit/pkg-openoffice/libreoffice.git/commit/?id=b468e0faad323817a66d4a5b45c9a8f2f1c01fb9
 and removed the Depends:, but..)

Please use the debug archive in ci.debian.net.


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

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

Bug#817079: autopkgtest: *3* copies for running a test?!

[Rene Engelhard]

Package: autopkgtest
Version: 3.19.3
Severity: important

Hi,

I have the following test:

--- snip ---
Tests: junit-subsequentcheck
Depends: libreoffice, libreoffice-subsequentcheckbase, libreoffice-sdbc-hsqldb, 
[...]
--- snip --

Then I run

$ adt-run -B -s -d --unbuilt-tree . --timeout-copy=1 --- null

from the *source package*.

(there's no build needed, as junit-subsequentcheck already does built what it
needs. copy timeout choosen as "randomly big", the default for sure is not
enough for LO. Note this:

(jessie)rene@frodo ..Office/libreoffice/libreoffice-5.1.1.3 % du -hs
3.1G.
)

So let's see.

adt-run: DBG: Parsed options: Namespace(apt_pocket=[], auto_control=True, 
copy=[], env=[], gainroot=None, logfile=None, output_dir=None, set_lang=None, 
setup_commands=[], shell=False, shell_fail=True, summary=None, 
timeout_build=None, timeout_copy=1, timeout_factor=1.0, 
timeout_install=None, timeout_short=None, timeout_test=None, user=None, 
verbosity=2)
adt-run: DBG: Remaining arguments: ['-B', '--unbuilt-tree', '.']
adt-run: DBG: Interpreted actions: ['--no-built-binaries', '--unbuilt-tree', 
'.']
adt-run: DBG: Virt runner arguments: ['null']
adt-run: DBG: testbed init
adt-run [00:35:16]: version 3.19.3
adt-run [00:35:16]: host frodo; command line: /usr/bin/adt-run -B -s -d 
--unbuilt-tree . --timeout-copy=1 --- null
adt-run: DBG: got reply from testbed: ok
adt-run: DBG: testbed open, scratch=None
adt-run: DBG: sending command to testbed: open
adt-run: DBG: got reply from testbed: ok /tmp/adt-run.c6BSZ8
adt-run: DBG: sending command to testbed: print-execute-command
adt-run: DBG: got reply from testbed: ok env
adt-run: DBG: sending command to testbed: capabilities
adt-run: DBG: got reply from testbed: ok isolation-machine 
downtmp-host=/tmp/adt-run.c6BSZ8
adt-run: DBG: testbed capabilities: ['isolation-machine', 
'downtmp-host=/tmp/adt-run.c6BSZ8']
adt-run: DBG: testbed command ['dpkg', '--print-architecture'], kind short, 
sout pipe, serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run [00:35:17]: testbed dpkg architecture: amd64
adt-run: DBG: testbed command ['which', 'eatmydata'], kind short, sout pipe, 
serr pipe, env []
adt-run: DBG: testbed command exited with code 1
adt-run: DBG: testbed command ['which', 'dpkg-query'], kind short, sout pipe, 
serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: testbed command ['sh', '-ec', "dpkg-query --show -f 
'${Package}\\t${Version}\\n' > /tmp/adt-run.c6BSZ8/testbed-packages"], kind 
short, sout raw, serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: sending command to testbed: copyup 
/tmp/adt-run.c6BSZ8/testbed-packages 
/tmp/adt-run.output.4ufg40yp/testbed-packages
adt-run: DBG: got reply from testbed: ok
adt-run: DBG: testbed command ['uname', '-srv'], kind short, sout pipe, serr 
pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run [00:35:17]: testbed running kernel: Linux 3.16.0-4-amd64 #1 SMP Debian 
3.16.7-ckt20-1+deb8u4 (2016-02-29)
adt-run: DBG: Binaries: initialising
adt-run [00:35:17]:  unbuilt-tree .
adt-run: DBG: blame += .
adt-run: DBG: testbed reset: modified=False, deps_installed=[](r: False), 
deps_new=[](r: False)
adt-run: DBG: testbed command ['mkdir', '-p', '/tmp/adt-run.c6BSZ8'], kind 
short, sout raw, serr pipe, env []
adt-run: DBG: testbed command exited with code 0
adt-run: DBG: sending command to testbed: copydown ./ 
/tmp/adt-run.c6BSZ8/ubtree-./


Here it copies the source tree to /tmp/. OK. I assume ubtree means
"unbuilt tree". #1

adt-run: DBG: got reply from testbed: ok
adt-run: DBG: testbed command ['sh', '-ec', 'exec 3>&1 >&2; set -x; cd /; 
builddir=$(mktemp -d /tmp/adt-run.c6BSZ8/build.XXX); cd $builddir; cp -rd 
--preserve=timestamps -- "/tmp/adt-run.c6BSZ8/ubtree-." real-tree; chmod -R 
a+rX .; cd [a-z0-9]*/.; pwd >&3; sed -n "1 {s/).*//; s/ (/\\n/; p}" 
debian/changelog >&3; set +e; grep -q "^Restrictions:.*\\bbuild-needed\\b" 
debian/tests/control 2>/dev/null; echo $? >&3'], kind build, sout pipe, serr 
raw, env []
+ cd /
+ mktemp -d /tmp/adt-run.c6BSZ8/build.XXX
+ builddir=/tmp/adt-run.c6BSZ8/build.Pdm
+ cd /tmp/adt-run.c6BSZ8/build.Pdm
+ cp -rd --preserve=timestamps -- /tmp/adt-run.c6BSZ8/ubtree-. real-tree

Here it copies the source tree from #1 to _an other_ "real" tree. Why? This is
cp #2.

+ chmod -R a+rX .
+ cd real-tree/.
+ pwd
+ sed -n 1 {s/).*//; s/ (/\n/; p} debian/changelog
+ set +e
+ grep -q ^Restrictions:.*\bbuild-needed\b debian/tests/control
+ echo 1
adt-run: DBG: testbed command exited with code 0
adt-run [00:52:46]: testing package libreoffice version 1:5.1.1~rc3-2
adt-run [00:52:46]: build not needed
adt-run: DBG: sending command to testbed: copyup 
/tmp/adt-run.c6BSZ8/build.Pdm/real-tree/ 
/tmp/adt-run.output.4ufg40yp/tests-tree/

What on earth? Another copy? From "real-tree" to "tests-tree"?

adt-run [00:52:46]: testing package libreoffice version 1:5.1.1~rc3-2

Bug#694733: marked as done (RFP: sassc -- Sass is a pre-processor language for CSS)

[Raphaël]

On Tue, Mar 08, 2016 at 12:59:32AM +0100, Jonas Smedegaard wrote:
> NB! You replied to the ITP bug for _sassc_ but seems what you are 
> requesting is an update of _libsass_.  I will update libsass.

you're right.
I believed there were bundled together and overlooked package info.
Sorry for this


signature.asc
Description: Digital signature

Bug#817040: dpkg-deb -c: sort list by name

[Guillem Jover]

Control: retitle 516915 dpkg: dpkg-deb --contents should sort file list
Control: tags -1 - patch
Control: merge 516915 -1

On Mon, 2016-03-07 at 23:04:57 +0900, Osamu Aoki wrote:
> Package: dpkg
> Version: 1.18.4
> Severity: wishlist
> Tags: patch

> Making dpkg-deb to be deterministic by fixing #719845 was good for
> reproducible build.  But "dpkg-deb -c" output is not human friendly.

> Basically, we want it to be sorted by name instead of internal data
> order.

Yeah, already filed some time ago. There's two issues with this
request. One is that sorting this would imply needing to process the
entire tarball to be able to sort the output which can take some time,
but probably that's not a big deal, it just stalls and makes it not
possible to process the output incrementally. The other is that we
might need to preserve symlinks at the end, or things might break.

> Please consider adding patch such as one attached to instruct tar to
> change its default behavior.

I don't think the attached patch does what you intended though? --sort
only works when packing (i.e. when reading from the filesystem). Not
to mention that it would break the symlinks-last premise.

> One debatable point is when to sort output.  Instead of always sorting
> by name, should we sort only when LIST?  Should we have option to
> control it?

Yeah, an option would be preferable IMO.

> --- extract.c.orig2016-03-07 22:44:03.421627595 +0900
> +++ extract.c 2016-03-07 22:47:23.810190427 +0900
> @@ -320,6 +320,7 @@
>command_init(, TAR, "tar");
>command_add_arg(, "tar");
>  
> +  command_add_arg(, "--sort=name");
>if ((taroption & DPKG_TAR_LIST) && (taroption & DPKG_TAR_EXTRACT))
>  command_add_arg(, "-xv");
>else if (taroption & DPKG_TAR_EXTRACT)

Also this would break with tar requiring action options first I think.

Thanks,
Guillem

Bug#817078: O: boxbackup

[Reinhard Tartler]

Package: wnpp
Severity: normal

I'm no longer using the boxbackup package personally, and would like it
to get a new maintainer. Upstream is generally quite receptive and not
very fast, so all in all it should be a rather low-maintenance package.

I did convert the packaging to git and based it on the recent github
branch. The first major update should probably be to update the package
to the latest 0.12 release.

Non-DDs welcome, I'm happy to sponsor your uploads.

Bug#814852: RFS: openfst/1.5.1-1 -- weighted finite-state transducers library

[Giulio Paci]

A quick update.

On 07/03/2016 17:44, Giulio Paci wrote:
> 1005_kaldi_patch.patch has been submitted, but it is still under revision and 
> may require some work.
> 
> On Friday I discovered an issue with this patch that, randomly, prevents 
> tests to complete.
> I am not able to deal with the issue myself, but upstream and the original 
> author of the patch has both been notified and are
> looking into it.
> According to preliminary investigation, the main issue is in the unpatched 
> openfst, but the patched version seems to suffer more problems.
> The main issue should be present in the currently packaged version as well, 
> altough I did not check it myself.
> 
> If possible I would like to have this package uploaded anyway and later open 
> a bug report, as this package will let further work to be
> conducted on other packages (kaldi in particular).
> 
> I do not know yet when we may expect to see a proper fix for this issue. 
> Probably a few months.

A quick update: the original author of the patch is working on it and already 
sent an update to me and to upstream.
So my estimation is probably wrong and probably it is better to wait a few days 
until the updated patch is tested a little bit.

Bests,
Giulio

Bug#806632: libsis-base-java: FTBFS when built with dpkg-buildpackage -A (cp: target is not a directory)

[Santiago Vila]

unarchive 806632
found 806632 14.12.0-3
thanks

Hi. Sorry for the reopening but "dpkg-buildpackage -A" still does not work.

Now the error is completely different, but since the end result is
still the same (i.e. "dpkg-buildpackage -A does not work"), I'm
reopening the old bug to recycle it.


This is the way it fails now:


[...]
 debian/rules build-indep
dh build-indep --with javahelper
   dh_testdir -i
   dh_update_autotools_config -i
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>'
cp debian/build_native/* source/c
#Needed on Ubuntu 14.04
touch source/c/NEWS source/c/README source/c/AUTHORS source/c/ChangeLog
cd source/c && autoreconf -i
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'

[... snipped ...]

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -MT copyByteLong.lo -MD -MP -MF .deps/copyByteLong.Tpo 
-c copyByteLong.c  -fPIC -DPIC -o .libs/copyByteLong.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -MT copyByteLong.lo -MD -MP -MF .deps/copyByteLong.Tpo 
-c copyByteLong.c -o copyByteLong.o >/dev/null 2>&1
mv -f .deps/copyByteLong.Tpo .deps/copyByteLong.Plo
/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.   
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux -DMACHINE_BYTE_ORDER=1 -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -MT copyByteShort.lo 
-MD -MP -MF .deps/copyByteShort.Tpo -c -o copyByteShort.lo copyByteShort.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -MT copyByteShort.lo -MD -MP -MF 
.deps/copyByteShort.Tpo -c copyByteShort.c  -fPIC -DPIC -o .libs/copyByteShort.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -MT copyByteShort.lo -MD -MP -MF 
.deps/copyByteShort.Tpo -c copyByteShort.c -o copyByteShort.o >/dev/null 2>&1
mv -f .deps/copyByteShort.Tpo .deps/copyByteShort.Plo
/bin/bash ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.   
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr/lib/jvm/default-java/include 
-I/usr/lib/jvm/default-java/include/linux -DMACHINE_BYTE_ORDER=1 -g -O2 
-fstack-protector-strong -Wformat -Werror=format-security -MT copyCommon.lo -MD 
-MP -MF .deps/copyCommon.Tpo -c -o copyCommon.lo copyCommon.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -MT copyCommon.lo -MD -MP -MF .deps/copyCommon.Tpo -c 
copyCommon.c  -fPIC -DPIC -o .libs/copyCommon.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -Wdate-time -D_FORTIFY_SOURCE=2 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -MT copyCommon.lo -MD -MP -MF .deps/copyCommon.Tpo -c 
copyCommon.c -o copyCommon.o >/dev/null 2>&1
mv -f .deps/copyCommon.Tpo .deps/copyCommon.Plo
/bin/bash ./libtool  --tag=CC   --mode=link gcc 
-I/usr/lib/jvm/default-java/include -I/usr/lib/jvm/default-java/include/linux 
-DMACHINE_BYTE_ORDER=1 -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -o libcisd_nativedata.la -rpath 
/usr/local/lib copyByteChar.lo copyByteDouble.lo copyByteFloat.lo 
copyByteInt.lo copyByteLong.lo copyByteShort.lo copyCommon.lo  
libtool: link: gcc -shared  -fPIC -DPIC  .libs/copyByteChar.o 
.libs/copyByteDouble.o .libs/copyByteFloat.o .libs/copyByteInt.o 
.libs/copyByteLong.o .libs/copyByteShort.o .libs/copyCommon.o-g -O2 
-fstack-protector-strong -Wl,-z -Wl,relro   -Wl,-soname 
-Wl,libcisd_nativedata.so.0 -o .libs/libcisd_nativedata.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcisd_nativedata.so.0" && ln -s 
"libcisd_nativedata.so.0.0.0" "libcisd_nativedata.so.0")
libtool: link: (cd ".libs" && rm -f "libcisd_nativedata.so" && ln -s 
"libcisd_nativedata.so.0.0.0" "libcisd_nativedata.so")
libtool: link: ar cru .libs/libcisd_nativedata.a  copyByteChar.o 
copyByteDouble.o copyByteFloat.o copyByteInt.o copyByteLong.o copyByteShort.o 
copyCommon.o
ar: `u' 

Bug#694733: marked as done (RFP: sassc -- Sass is a pre-processor language for CSS)

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2016-03-08 00:51:12)
> Hi Raphaël,
> 
> [cc'ing bugreport as seemingly intended]
> 
> Quoting Raphaël (2016-03-08 00:02:23)
> > To say the least: great work, thank you!
> > 
> > 
> > But... could I advise to package the version 3.3.3 from January 19
> > since it ships the bugfix for:
> > https://github.com/sass/libsass/issues/1259
> > (which keeps libsass from compiling sass from `ruby-compass-core`)
> > 
> > That would make this package even more useful!
> 
> Ah - sure: Upstream apparently forgot to push the tag for that newest 
> release, that's why I missed it.  I will package that!

NB! You replied to the ITP bug for _sassc_ but seems what you are 
requesting is an update of _libsass_.  I will update libsass.

In the future please file a bugreport instead of tagging onto bugreports 
for other things, that's easier for me (and others helping out) to 
handle.


Regards,

 - Jonas

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

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


signature.asc
Description: signature

Bug#800805: Pull Request submitted upstream

[Ross Gammon]

tag 800805 upstream
forwarded 800805 https://github.com/alessio/laditools/pull/1
thanks

Hi Alessio,

Pull request submitted upstream:
https://github.com/alessio/laditools/pull/1

It would be great if we could get the fix uploaded so that it could be
synced to Ubuntu before the 16.04 release. That way gladish could be
seeded again.

Let me know if you would prefer that I take care of it.

Cheers,

Ross



signature.asc
Description: OpenPGP digital signature

Bug#694733: marked as done (RFP: sassc -- Sass is a pre-processor language for CSS)

[Jonas Smedegaard]

Hi Raphaël,

[cc'ing bugreport as seemingly intended]

Quoting Raphaël (2016-03-08 00:02:23)
> To say the least: great work, thank you!
> 
> 
> But... could I advise to package the version 3.3.3 from January 19
> since it ships the bugfix for:
> https://github.com/sass/libsass/issues/1259
> (which keeps libsass from compiling sass from `ruby-compass-core`)
> 
> That would make this package even more useful!

Ah - sure: Upstream apparently forgot to push the tag for that newest 
release, that's why I missed it.  I will package that!

 - Jonas

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

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


signature.asc
Description: signature

Bug#813620: sudo: hostname checked against qualified hostname

[Bob Proulx]

So far I have been unable to recreate this problem.  I tried various
combinations today trying to set up a similar environment to the one
reported.  Always for me the host field in the sudoers file requires
the short host name.

I think this is going to require someone who is experiencing the
problem to debug it further.

Bob


signature.asc
Description: PGP signature

Bug#817077: proftpd-basic: please backport proftpd 1.3.5 to Wheezy

[Benjamin Sonntag]

Package: proftpd-basic
Version: 1.3.5a-1~bpo-octopuce.1
Severity: wishlist

Dear Maintainer,

I tried to compile proftpd from Jessie (1.3.5) and Sid (1.3.5a) in a stock 
wheezy, and the backport process was very easy:
- apt-get source proftpd
- apt-get build-dep proftpd
- cd proftpd* && dpkg-buildpackage
- cd .. && debrsign + dput 

This package is working on my server now. 
The main reasons for this backport are: 
- Proftpd 1.3.4 ignores DHParam file (even though it's set in the parameters) 
- Proftpd 1.3.4 can't do TLS 1.1 or 1.2
- Proftpd 1.3.4 can't force Server-side Ciphers in TLS.

So, could you please create an official backport of proftpd for Wheezy so that 
we have good crypto? 

Thanks! 

Benjamin Sonntag

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

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

Versions of packages proftpd-basic depends on:
ii  adduser3.113+nmu3
ii  debconf1.5.49
ii  debianutils4.3.2
ii  libacl12.2.51-8
ii  libc6  2.13-38+deb7u10
ii  libcap21:2.22-1.2
ii  libmemcached10 1.0.8-1
ii  libmemcachedutil2  1.0.8-1
ii  libncurses55.9-10
ii  libpam-runtime 1.1.3-7.1
ii  libpam0g   1.1.3-7.1
ii  libpcre3   1:8.30-5
ii  libssl1.0.01.0.1e-2+deb7u20
ii  libtinfo5  5.9-10
ii  libwrap0   7.6.q-24
ii  netbase5.0
ii  sed4.2.1-10
ii  ucf3.0025+nmu3
ii  zlib1g 1:1.2.7.dfsg-13

proftpd-basic recommends no packages.

Versions of packages proftpd-basic suggests:
ii  openssl1.0.1e-2+deb7u20
pn  proftpd-doc
pn  proftpd-mod-geoip  
pn  proftpd-mod-ldap   
ii  proftpd-mod-mysql  1.3.5a-1~bpo-octopuce.1
pn  proftpd-mod-odbc   
pn  proftpd-mod-pgsql  
pn  proftpd-mod-sqlite 
ii  xinetd [inet-superserver]  1:2.3.14-7.1+deb7u1

-- Configuration Files:
/etc/default/proftpd changed [not included]
/etc/logrotate.d/proftpd-basic changed [not included]
/etc/proftpd/blacklist.dat [Errno 2] Aucun fichier ou dossier de ce type: 
u'/etc/proftpd/blacklist.dat'

-- debconf information:
* shared/proftpd/inetd_or_standalone: standalone

Bug#691370: Maybe when a ^C is detected, print "Thank you for hitting ^C, but ..."

[積丹尼 Dan Jacobson]

Maybe when a ^C is detected, print "Thank you for hitting ^C, but ..."
or "^C detected, but ...".

Bug#817069: texlive-latex-extra: Animate package broken in 2015.20160223-1

[Norbert Preining]

Hi Arnout,

> Animations compiled with version 2015.20160223-1 of animate in
> texlive-latex-extra do not work. They do not play correctly in acroread.
> Switching back to 2015.20160215-1 solves the problem. I can provide a minimal
> example if desired.

We are dealing only with TeX Live upstream, and there they take whatever
is on CTAN. That means, if you want this fixed, please contact
the original author of the animate package with a minimal example and
ask him to upload a fixed version to CTAN. Then it will also appear
in TeX Live and in the next upload to Debian.

In addition, please send a minimal example here.

Thanks

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#542899:

[Chris Bainbridge]

Does anyone have any comments on the man pages?

If the pages are ok, can someone add them to the Debian package?

Bug#817065: aptitude: [l10n] New version of da.po

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


2016-03-07 19:14 Morten Bo Johansen:

Package: aptitude
Version: 0.7.8-1
Severity: wishlist
Tags: patch l10n

Dear Maintainer,

Please find attached an updated version of the Danish
translation of the aptitude gettext message catalog. It is for
version 0.7.8, currently in Unstable.


Commited, thanks!


--
Manuel A. Fernandez Montecelo 

Bug#661654: retitle 661654 libreoffice-common: 'man libreoffice' and 'soffice --help': "--convert-to": mention *all* possible file extensions

[Stéphane Aulery]

Hi,

Le 08/03/2016 00:00, Rene Engelhard a écrit :

Hi,

On Mon, Mar 07, 2016 at 11:53:59PM +0100, Stéphane Aulery wrote:

Where do you see that? I don't believe they will add every possible format
(well, extension) in the manpage, will they?

Which is what this bug is about.


Oups, I made a mistake with forward link and title.
I correct this.

Manpage is ours, the command line for them.


Nah, the manpage is also coming from upstream.

Yeah, I said manpage in my reply, but that is a generic ""problem".
As I said: I don't believe they will add every possible extenson suitable
for --convert-to to either, will they? But that is what the submitter
wants.

Thus it was + wontfix. (Could have been closed, too, for being totally
nonsensical, but)


Yes, all is to much, major formats is better. I am not against to close 
it, now that it has been passed upstream. Lots of other bugs like that. 
I made a first pass for sorting. There is a lot of noise!


I would not be too aggressive.

Regards,

--
Stéphane Aulery

Bug#814038: aptitude: Provide a way to reverse order with any of the available sorting criterias

[Manuel A. Fernandez Montecelo]

2016-03-07 22:40 GMT+00:00 Axel Beckert :
>
>> >but then again in the --sort
>> >section doesn't contain the policy names and it refers to the on-line
>> >guide (which in my opinion is good, to not repeat information which can
>> >easily go out of sync).
>
> While I see the advantage, I actually still prefer if they would be
> listed in the man page, too.

I'd prefer to not have it, but maybe it's the lazy person in me that
doesn't want to have new bugs in the future receiving bugs with "oh,
the list of sort-criteria is incomplete/outdated!".

But then I acknowledge that it's more practical for everyday or
occasional use to have it in the man page and not to have to go to the
guide, specially when the short names are not straightforward or easy
to remember... so it's fine by me.


>> >-O , --sort 
>> >   Specify the order in which output from the search and versions
>> >   commands should be displayed. For instance, passing “installsize”
>> >   for  will list packages in order according to their size
>> >   when installed (see the section “Customizing how packages are
>> >   sorted” in the aptitude reference manual for more information).
>> >
>> >   The default sort order is name,version.
>
> I think adding the information about negation here, probably terser
> than in the User's Manual, would be good thing while not really
> duplicating data (like the list of available sorting criteria, which
> probably changes more often than the negation character).
>
> I can take care of that.

Nice!

Please do, and add the sort criteria as well.


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#661654: retitle 661654 libreoffice-common: 'man libreoffice' and 'soffice --help': "--convert-to": mention *all* possible file extensions

[Rene Engelhard]

Hi,

On Mon, Mar 07, 2016 at 11:53:59PM +0100, Stéphane Aulery wrote:
> >Where do you see that? I don't believe they will add every possible format
> >(well, extension) in the manpage, will they?
> >
> >Which is what this bug is about.
> 
> Oups, I made a mistake with forward link and title.
> I correct this.
> 
> Manpage is ours, the command line for them.

Nah, the manpage is also coming from upstream.

Yeah, I said manpage in my reply, but that is a generic ""problem".
As I said: I don't believe they will add every possible extenson suitable
for --convert-to to either, will they? But that is what the submitter
wants. 

Thus it was + wontfix. (Could have been closed, too, for being totally
nonsensical, but)

Regards,

Rene

Bug#806901: citadel: Runs as root but shouldn't

[Robert James Clay]

I found this same error on a Debian 'stretch' system where I am testing the 
v9.01 version of Citadel, using  the 9.01-1+b1 of the package.

Message from syslogd@mailtst at Mar  7 15:03:55 ...
 citserver[26561]: citadel should not be configured to run as root! Check the
 value of c_ctdluid


I can confirm after I edited  the installed /var/lib/dpkg/info/citadel-
server.postinst file to add that line noted in in the bug, then runnin 'dpkg-
reconfigure citadel-server';  the error is no longer showing in the log.



RJ Clay
j...@rocasa.us

Bug#816322: aptitude: SIGABRT due to assertion failure when quitting from conflict resolver

[Manuel A. Fernandez Montecelo]

2016-03-05 21:16 GMT+00:00 Katsuhiko Nishimra :
> I've confirmed with aptitude=0.7.8-1 that SIGABRT has gone even when
> quitting without accepting a solution.

Good, thanks for the feed-back.

BTW, it is strange that the other problem was not reported before, the
problem has ben present for many years (much longer than the last
stable).  I guess that not many people use this feature, or they don't
mind about it crashing, or they don't bother submitting a bug report
:)


> However, I've encountered another corner case.
> When aptitude cause too many conflicts and cannot resolve them in
> command line mode,
> (I ran into this situation because I installed aptitude=0.7.8-1 by dpkg
> and forgot upgrading aptitude-dbgsym accordingly, then tested
> $ aptitude -s install -t experimental ~i)
> entering curses mode by hitting `e' and quitting without resolving
> conflicts kills aptitude by SIGABRT.
>
> This is a very irregular situation, so I won't reopen this bug report.

It might be good to submit a new report about this problem -- maybe it
affects not-so-unusual scenarios.  If you can get a backtrace,
doubleplus good.

(I could try to reproduce myself, but I'm quite constrained by
bandwidth at the moment, and if you can reproduce it reliably it can
give a good hint about where to start to look).


> Again, many thanks for your effort.

You're welcome :)

-- 
Manuel A. Fernandez Montecelo 

Bug#816634: Acknowledgement (libdbd-xbase-perl: Extend libdbd-xbase-perl to support W type columns (cheap patch))

[gregor herrmann]

On Sun, 06 Mar 2016 22:43:17 +0100, Stefan Rink wrote:

> upstream has made a new release which includes that patch:
> http://www.adelton.com/perl/DBD-XBase/DBD-XBase-1.06.tar.gz

Thanks for the notice (we would never have found this non-CPAN
release) and for the original patch.

1.06 uploded to Debian/unstable.

Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#816634: Pending fixes for bugs in the libdbd-xbase-perl package

[pkg-perl-maintainers]

tag 816634 + pending
thanks

Some bugs in the libdbd-xbase-perl package are closed in revision
302a2352f6b0bef4ef1e0a59ecd64b014f598e85 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libdbd-xbase-perl.git/commit/?id=302a235

Commit message:

New upstream release 1.06. Fixes "Extend libdbd-xbase-perl to support W 
type columns" (Closes: #816634)

Bug#661654: retitle 661654 libreoffice-common: 'man libreoffice' and 'soffice --help': "--convert-to": mention *all* possible file extensions

[Stéphane Aulery]

Hi Rene,

Le 07/03/2016 23:45, Rene Engelhard a écrit :

Hi,

On Mon, Mar 07, 2016 at 01:11:42AM +0100, Stéphane Aulery wrote:

retitle 661654 libreoffice-common: 'man libreoffice' and 'soffice --help':
"--convert-to": mention *all* possible file extensions
tags 661654 - wontfix
stop
-

Upstream will fix 'soffice --help'.


Where do you see that? I don't believe they will add every possible format
(well, extension) in the manpage, will they?

Which is what this bug is about.


Oups, I made a mistake with forward link and title.
I correct this.

Manpage is ours, the command line for them.

Regards,

--
Stéphane Aulery

Bug#816192: RFS: python-proselint/0.3.5-1 [ITP] -- A prose linter

[Jakub Wilk]

* Paul Wise , 2016-03-06, 16:59:
I can't find a copy of the BSD license grant in the upstream tarball at 
all, only in PKG-INFO and setup.py. I'm not sure this is good enough 
for ftp-master approval.


I'm pretty sure it isn't. Their reject FAQ[0] says:
If the upstream tarball does not include a copy of the license, 
debian/copyright must document when and how the license information was 
obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from 
http://example.net/license; or reproduce email correspondence including 
some header) in addition to reproducing the license itself. In the past 
there were uploads where one couldn't find the license statement in the 
tarball or on the website from upstream, which is bad. 



[0] https://ftp-master.debian.org/REJECT-FAQ.html

--
Jakub Wilk

Bug#731318: aptitude: keeps switching a package between architectures on safe-upgrade

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


Hi Shai,

2013-12-04 08:38 Shai Berger:

Package: aptitude
Version: 0.6.8.2-1.2
Severity: normal

Dear Maintainer,

My system is mostly x86-64; some time ago I had to install Skype,
and for that, several ":i386" packages got installed. The packages
in the system are managed almost exclusively by aptitude. I upgrade
manually, almost daily, by running

   sudo aptitude update && sudo aptitude safe-upgrade

Recently, I noticed that with every safe-upgrade, I have udisks
removed and udisks:i386 installed, or vice versa. Every single
time, this package is toggled between the architectures.

It doesn't really seems to hurt anything, but is a little annoying
and seems redundant.


Did you keep observing this problem in recent years/releases?

..and if the answer is yes:

a) do you still use aptitude as the main package manager in your system?

b) which versions?


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#799540: closed by Stéphane Aulery <saul...@free.fr> (Re : Bug #799540 - libreoffice-writer: Export to PDF with "in margins" turns comments blank)

[Rene Engelhard]

notfixed 1:5.1.0~rc3-1
fixed 1:5.0.5~rc1-1
fixed 1:5.1.0~rc2-1
thanks

Hi,

On Tue, Mar 08, 2016 at 05:02:46AM +1100, Ben Finney wrote:
> On 07-Mar-2016, Debian Bug Tracking System wrote:
> 
> > Date: Mon, 7 Mar 2016 12:03:19 +0100 (CET)
> > From: Stéphane Aulery 
> > 
> > Hello,
> > 
> > This bug has been fixed by upstream and in Debian.
> 
> The bug report does not yet know that. Please add a “fixed” property

Hmm?

"Fixed in version libreoffice/1:5.1.0~rc3-1"

Reading https://bugs.documentfoundation.org/show_bug.cgi?id=93009 even in
rc2 :)

Regards,

Rene

Bug#816299: syntax error in python3.5.devhelp.gz: Error on line 7241: Entity did not end with a semicolon

[Simon McVittie]

Control: tags 816299 + patch

On Mon, 29 Feb 2016 at 16:22:37 +, Simon McVittie wrote:
> I think this indicates that pyhtml2devhelp.py should escape &, <, >, "
> when it writes out its XML index, for example via html.escape().

Here's a patch which I have confirmed works (by running it against the
installed HTML, I didn't do a full Python build). Steps to test:

python3 debian/pyhtml2devhelp.py /usr/share/doc/python3.5/html index.html 3.5 > 
python3.5.devhelp
gzip -9 python3.5.devhelp
sudo install -m644 python3.5.devhelp.gz 
/usr/share/doc/python3.5/html/python3.5.devhelp.gz

Please consider applying that change.

Thanks,
S
From e72f07059ff76b15f694c63f680cc0918617176d Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Mon, 7 Mar 2016 22:44:29 +
Subject: [PATCH] pyhtml2devhelp.py: escape XML special characters in output

This makes the Python 3.5 documentation show up in devhelp correctly.

Signed-off-by: Simon McVittie 
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816299
---
 pyhtml2devhelp.py | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/pyhtml2devhelp.py b/pyhtml2devhelp.py
index 7a945e3..7d1c8d9 100644
--- a/pyhtml2devhelp.py
+++ b/pyhtml2devhelp.py
@@ -1,6 +1,7 @@
 #! /usr/bin/python3
 
 from html.parser import HTMLParser
+from xml.sax.saxutils import escape
 import os, sys, re
 
 class PyHTMLParser(HTMLParser):
@@ -10,7 +11,7 @@ class PyHTMLParser(HTMLParser):
 'distutils/index.html'))
 
 def __init__(self, basedir, fn, indent, parents=set()):
-HTMLParser.__init__(self)
+HTMLParser.__init__(self, convert_charrefs=True)
 self.basedir = basedir
 self.dir, self.fn = os.path.split(fn)
 self.data = ''
@@ -22,9 +23,12 @@ class PyHTMLParser(HTMLParser):
 self.sub_count = 0
 self.next_link = False
 
+def escape(self, text):
+return escape(text, {'"': ''})
+
 def process_link(self):
-new_href = os.path.join(self.dir, self.link['href'])
-text = self.link['text']
+new_href = self.escape(os.path.join(self.dir, self.link['href']))
+text = self.escape(self.link['text'])
 indent = self.indent + self.sub_indent
 if self.last_indent == indent:
 print('%s' % ('  ' * self.last_indent))
@@ -65,7 +69,7 @@ class PyHTMLParser(HTMLParser):
 
 def end_a(self):
 process = False
-text = self.data.replace('\t', '').replace('\n', ' ').replace('&', '').replace('<', '').replace('>', '')
+text = self.escape(self.data.replace('\t', '').replace('\n', ' '))
 self.link['text'] = text
 # handle a tag without href attribute
 try:
@@ -119,7 +123,7 @@ class PyHTMLParser(HTMLParser):
 
 class PyIdxHTMLParser(HTMLParser):
 def __init__(self, basedir, fn, indent):
-HTMLParser.__init__(self)
+HTMLParser.__init__(self, convert_charrefs=True)
 self.basedir = basedir
 self.dir, self.fn = os.path.split(fn)
 self.data = ''
@@ -132,9 +136,12 @@ class PyIdxHTMLParser(HTMLParser):
 self.last_letter = 'Z'
 self.last_text = ''
 
+def escape(self, text):
+return escape(text, {'"': ''})
+
 def process_link(self):
-new_href = os.path.join(self.dir, self.link['href'])
-text = self.link['text']
+new_href = self.escape(os.path.join(self.dir, self.link['href']))
+text = self.escape(self.link['text'])
 if not self.active:
 return
 if text.startswith('['):
@@ -243,12 +250,13 @@ class PyIdxHTMLParser(HTMLParser):
 self.data += data
 
 def handle_entityref(self, name):
-self.data += '&%s;' % name
+# not meant to be called while convert_charrefs is true
+raise AssertionError('entityrefs should not be handled any more')
 
 def main():
 base = sys.argv[1]
 fn = sys.argv[2]
-version = sys.argv[3]
+version = escape(sys.argv[3])
 
 parser = PyHTMLParser(base, fn, indent=0)
 print('')
-- 
2.7.0



signature.asc
Description: PGP signature

Bug#817076: naturaldocs: patch used in NMU 1.51-1.1

[Petter Reinholdtsen]

Package: naturaldocs
Version: 1.51-1.1
Tags: patch
Severity: wishlist

Hi.  I've just uploaded a NMU of naturaldocs to the 7 day delayed upload
queue to fix the reproducable build issue.  The upload used the attached
patch.

Please let me know if you want to do the upload yourself, and it not
missing in action. :)

-- 
Happy hacking
Petter Reinholdtsen
diff -Nru naturaldocs-1.51/debian/changelog naturaldocs-1.51/debian/changelog
--- naturaldocs-1.51/debian/changelog	2016-03-07 22:44:22.0 +
+++ naturaldocs-1.51/debian/changelog	2016-03-07 22:42:46.0 +
@@ -1,3 +1,15 @@
+naturaldocs (1.51-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Added homepage to debian/control.
+  * Raise debhelper compat level from 5 to 9 and convert source
+format to 3.0 (quilt).
+  * Added patch from Chris Lamb to make the output
+reproducible (Closes: #778962).
+  * Drop unwanted article from short package description start.
+
+ -- Petter Reinholdtsen   Mon, 07 Mar 2016 22:29:28 +
+
 naturaldocs (1.51-1) unstable; urgency=low
 
   * New upstream release (Closes: #488097, ##458557)
diff -Nru naturaldocs-1.51/debian/compat naturaldocs-1.51/debian/compat
--- naturaldocs-1.51/debian/compat	2016-03-07 22:44:22.0 +
+++ naturaldocs-1.51/debian/compat	2016-03-07 22:32:22.0 +
@@ -1 +1 @@
-5
+9
diff -Nru naturaldocs-1.51/debian/control naturaldocs-1.51/debian/control
--- naturaldocs-1.51/debian/control	2016-03-07 22:44:22.0 +
+++ naturaldocs-1.51/debian/control	2016-03-07 22:37:36.0 +
@@ -2,13 +2,14 @@
 Section: devel
 Priority: extra
 Maintainer: Federico Di Gregorio 
-Build-Depends: debhelper (>= 5)
-Standards-Version: 3.9.1
+Build-Depends: debhelper (>= 9)
+Standards-Version: 3.9.7
+Homepage: http://www.naturaldocs.org/
 
 Package: naturaldocs
 Architecture: all
 Depends: ${perl:Depends}, ${misc:Depends}
-Description: an extensible, multi-language documentation generator
+Description: extensible, multi-language documentation generator
  Natural Docs is an extensible, multi-language documentation
  generator.  You document your code in a natural syntax that reads
  like plain English.  Natural Docs then scans your code and builds
diff -Nru naturaldocs-1.51/debian/patches/debian-1.51-1.patch naturaldocs-1.51/debian/patches/debian-1.51-1.patch
--- naturaldocs-1.51/debian/patches/debian-1.51-1.patch	1970-01-01 00:00:00.0 +
+++ naturaldocs-1.51/debian/patches/debian-1.51-1.patch	2016-03-07 22:40:34.0 +
@@ -0,0 +1,109 @@
+Description: Changes found in version 1.51-1
+ Changes do to upstream code in version 1.51-1, when the package was
+ converted to the 3.0 (quilt) format.
+Author: unknown
+Forwarded: unknown
+Reviewed-By: Petter Reinholdtsen 
+Last-Update: 2016-03-07
+
+--- /dev/null
 naturaldocs-1.51/naturaldocs
+@@ -0,0 +1,2 @@
++#!/bin/sh
++exec /usr/bin/perl /usr/share/perl5/naturaldocs/NaturalDocs $@
+--- /dev/null
 naturaldocs-1.51/naturaldocs.1
+@@ -0,0 +1,93 @@
++.\"  Hey, EMACS: -*- nroff -*-
++.\" First parameter, NAME, should be all caps
++.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
++.\" other parameters are allowed: see man(7), man(1)
++.TH NATURALDOCS 1 "May 2007"
++.\" Please adjust this date whenever revising the manpage.
++.\"
++.\" Some roff macros, for reference:
++.\" .nhdisable hyphenation
++.\" .hyenable hyphenation
++.\" .ad l  left justify
++.\" .ad b  justify to both left and right margins
++.\" .nfdisable filling
++.\" .fienable filling
++.\" .brinsert line break
++.\" .sp insert n+1 empty lines
++.\" for manpage-specific macros, see man(7)
++.SH NAME
++NaturalDocs \- an extensible, multi\-language documentation generator
++.SH SYNOPSIS
++.ad l
++.B naturaldocs
++-i  [-i  ...] -o   [-o   ...] -p  [options]
++.ad b
++.SH DESCRIPTION
++This manual page documents briefly the .B naturaldocs command. Note that \fBnaturaldocs\fP is a wrapper script that on Debian invokes the real \fBNaturalDocs\fP perl program. So, the real, original name of the program is NaturalDocs but on
++Debian systems you invoke it as naturaldocs.
++.PP
++\fBNatural Docs\fP is is an open-source, extensible, multi-language documentation generator. You document your code in a natural syntax that reads like plain English. Natural Docs then scans your code and builds high-quality HTML documentation from it.
++.SH OPTIONS
++A summary of options, extracted from the help printed by the \fB-h\fP
++switch is included below. 
++For a complete description of how NaturalDocs works, see the text
++files in the /usr/share/doc/naturaldocs directory.
++.sp
++\fIRequired parameters\fR:
++.TP
++.B \-i, \-\-input, \-\-source DIR
++Specifies an input (source) directory. Required.
++.br
++Can be specified multiple times.
++.TP
++.B \-o, \-\-output FMT DIR
++Specifies an output