Bug#800017: [Aptitude-devel] Bug#800017: Bug#800017: Could not open file /var/lib/apt/lists/ftp.tw.debian.org_debian_dists_experimental_main_i18n_Translation-en.IndexDiff - open (2: No such file or di

[Manuel A. Fernandez Montecelo]

Control: tags -1 + unreproducible


Hi,

2015-09-25 15:54 積丹尼 Dan Jacobson:

I bet the problem has something to do with the residue left with the
_apt owner stuff...

# find /var/lib/apt/lists/partial -ls
49345   17 drwx--   2 _apt root16384 Sep 25 18:52 
/var/lib/apt/lists/partial
49381   18 -rw-r--r--   1 root root18409 Aug 15 09:21 
/var/lib/apt/lists/partial/ftp.tw.debian.org_debian_dists_experimental_contrib_i18n_Translation-en


OK I moved that file to /tmp and now indeed "aptitude update" is
working.

I moved it back, and "aptitude update" is still working (but maybe that
is because it was freshly updated.)

As this is on a "sneakernet" disk, I use
  chown root:root lists
  chown _apt:root lists/partial
at boot.

OK I'll use
  chown -R _apt:root lists/partial
or better yet
  find lists/partial -type f -delete


Have you seen this problem with the recent updates?

I saw that apt made changes related to this in the last few versions
(1.1~exp* and after moving to unstable).


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#799007: bouncycastle: please package a newer version or upload 1.51-1 to unstable

[Markus Koschany]

I have been working on jakarta-jmeter and tika. Tika can be fixed by
upgrading to the latest upstream release which is 1.11~rc1.
Jakarta-jmeter needed a patch because even the latest upstream version
isn't ready for bouncycastle 1.51 or later yet.

My proposed patch for jakarta-jmeter is here:

https://anonscm.debian.org/viewvc/pkg-java/trunk/jakarta-jmeter/debian/patches/08_bouncycastle-1.51.patch?revision=18921=markup

The tests still work with this one but I would appreciate another look
and feedback before I forward this patch upstream.

Tika:

https://anonscm.debian.org/cgit/pkg-java/tika.git

I am currently struggling with Tika because Maven complains about
missing artifacts. It has something to do with one of Emmanuel's patches

https://anonscm.debian.org/cgit/pkg-java/tika.git/tree/debian/patches/06-optional-parser-dependencies.patch

Although I have marked every new dependency for the parser module as
optional like before, Maven still requires those dependencies. I could
add all of them to maven.ignoreRules but this doesn't really look like
the preferred solution to me. I hope Emmanuel can shed some light on
this issue.

At the moment I'm trying to fix libitext-java and libitext5-java.

Markus



signature.asc
Description: OpenPGP digital signature

Bug#799007: bouncycastle: please package a newer version or upload 1.51-1 to unstable

[Emmanuel Bourg]

Le 30/11/2015 22:03, Markus Koschany a écrit :

> The tests still work with this one but I would appreciate another look
> and feedback before I forward this patch upstream.

The patch looks good to me.


> Although I have marked every new dependency for the parser module as
> optional like before, Maven still requires those dependencies. I could
> add all of them to maven.ignoreRules but this doesn't really look like
> the preferred solution to me. I hope Emmanuel can shed some light on
> this issue.

Optional dependencies are still required at compile time. They are just
optional at runtime, when tika-parsers is used by another Maven project
(which makes sense since the rdeps only use a small subset of the
parsers supported by Tika). If there are missing dependencies they have
to be added to maven.ignoreRules.

Emmanuel Bourg

Bug#806754: RFS: gmp-ecm/6.4.4+ds-5 [FTBFS fix]

[Jerome Benoit]

Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the package gmp-ecm [1] that
I am maintaining on behalf of the Debian Science-Team.
This version fix the FTBFS issue #806619 that pointed that
the gmp-ecm package did not honour the arch/indep built scheme:
this release introduce a fully working arch/indep built scheme.

Thanks in advance,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/gmp-ecm.git

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

Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (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: sysvinit (via /sbin/init)

Bug#765820: xapian multiarch

[Olly Betts]

On Fri, Nov 27, 2015 at 01:55:54PM +, Wookey wrote:
> This patch: https://bugs.debian.org/765820
> looks good to me (although you no longer need the Pre-Depends:
> ${misc:Pre-Depends}) bit
> 
> Is there any chance of it getting uploaded in the not-too-distant?

I'm currently very short of spare time, and have been leaving this until
things were less busy - I don't really understand all the details of
multiarch, so trying to fix any breakage caused would likely eat a lot
of time I just don't currently have (I speak from experience of having
to fix up the broken multiarchification of wxwidgets).

If you want to NMU and are happy to take care of any fallout, please
go ahead.

Cheers,
Olly

Bug#806753: hexchat: does not remember "Hide join/part messages" on exit

[Roland Hieber]

Package: hexchat
Version: 2.10.2-1+b2
Severity: minor

Dear Maintainer,

I recently restarted HexChat (one thing which I don't do often), but I find that
the setting "Hide join/part messages" per channel is not remembered over
restarts.  XChat did so, as far as I can remember, and I also would expect this
setting to be remembered, so I'm setting the severity to normal.  But feel free
to downgrade it to wishlist if needed.

Cheers,
 - Roland

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

Kernel: Linux 3.14-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.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 hexchat depends on:
ii  hexchat-common   2.10.2-1
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo21.14.4-1
ii  libcanberra0 0.30-2.1
ii  libdbus-1-3  1.10.2-1
ii  libdbus-glib-1-2 0.102-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6-2
ii  libgdk-pixbuf2.0-0   2.32.2-1
ii  libglib2.0-0 2.46.2-1
ii  libgtk2.0-0  2.24.28-1.1~ppa1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libproxy1v5  0.4.11-4.2
ii  libssl1.0.2  1.0.2d-3

Versions of packages hexchat recommends:
ii  gvfs-bin 1.26.2-1
ii  hexchat-perl 2.10.2-1+b2
ii  hexchat-plugins  2.10.2-1+b2
ii  hexchat-python   2.10.2-1+b2

Versions of packages hexchat suggests:
pn  unifont  

-- no debconf information

Bug#803787: [Pkg-swan-devel] Bug#803787: [strongswan] Enable post-quantum algorithms

[Gerald Turner]

Hello,

I am also interested in the NTRU key exchange algorithm for the same
reasons Nicolas Braud-Santoni explains.  Prior to realizing that this
bug existed, I had tested the strongswan with the attached patch which
enables additional plugins.

Note that I enabled BLISS but have no intention of using it due to the
requirement have having to redeploy certificates.

Also note that I enabled ChaCha20/Poly1305, which would be interesting
to use on systems which don't have AES-NI CPU instructions, but
unfortunuately I do not have enough hosts running a 4.2 kernel so I
cannot test this cipher at the moment.  FYI, Linux 4.2 is required to
use this cipher, otherwise error "received netlink error: Function not
implemented (38)" occurs while adding SAD entries.  Very similar to the
problem of enabling AES-GCM-256 on kernels older than ~4.1.

Finally note that I enabled SHA3 but hadn't tested with it because I'm
using AEAD ciphers exclusively.

Let me know if it would be at all useful for me to clean up the patch
such that it only enables NTRU.

-- 
Gerald Turner Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D
From 75df33a0622731cb3e0760ed3543b2f5845b476d Mon Sep 17 00:00:00 2001
From: Gerald Turner 
Date: Thu, 26 Nov 2015 16:01:46 -0800
Subject: [PATCH 2/2] Configure and install bliss, chapoly, ntru, and sha3
 plugins

---
 debian/changelog   |  1 +
 debian/control |  4 
 debian/libstrongswan-extra-plugins.install | 12 
 debian/rules   |  1 +
 4 files changed, 18 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 4182835..3fc87ee 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ strongswan (5.3.4-1.1) UNRELEASED; urgency=medium
 
   * debian/rules:
 - enable the aesni plugin.
+- enable bliss, chapoly, ntru, and sha3 plugins.
 
  -- Gerald Turner   Thu, 26 Nov 2015 15:17:09 -0800
 
diff --git a/debian/control b/debian/control
index 4717b1e..e1f61c9 100644
--- a/debian/control
+++ b/debian/control
@@ -124,6 +124,10 @@ Description: strongSwan utility and crypto library (extra plugins)
 rdrand instruction found on Ivy Bridge processors)
   - aesni (AES crypto primitives using Intel AES-NI and PCLMULQDQ instructions
 found on Ivy Bridge processors)
+  - bliss (BLISS post-quantum signature scheme)
+  - chapoly (ChaCha20/Poly1305 AEAD cipher)
+  - ntru (NTRU lattice-based post-quantum encryption algorithm)
+  - sha3 (SHA3 Keccak-F1600 hash algorithm family)
   - test-vectors (Set of test vectors for various algorithms)
 
 Package: libcharon-extra-plugins
diff --git a/debian/libstrongswan-extra-plugins.install b/debian/libstrongswan-extra-plugins.install
index 2a7c209..2f08aa0 100644
--- a/debian/libstrongswan-extra-plugins.install
+++ b/debian/libstrongswan-extra-plugins.install
@@ -6,6 +6,10 @@ usr/lib/ipsec/plugins/libstrongswan-curl.so
 usr/lib/ipsec/plugins/libstrongswan-gcrypt.so
 usr/lib/ipsec/plugins/libstrongswan-ldap.so
 usr/lib/ipsec/plugins/libstrongswan-pkcs11.so
+usr/lib/ipsec/plugins/libstrongswan-bliss.so
+usr/lib/ipsec/plugins/libstrongswan-chapoly.so
+usr/lib/ipsec/plugins/libstrongswan-ntru.so
+usr/lib/ipsec/plugins/libstrongswan-sha3.so
 usr/lib/ipsec/plugins/libstrongswan-test-vectors.so
 # default configuration files
 usr/share/strongswan/templates/config/plugins/ccm.conf
@@ -15,6 +19,10 @@ usr/share/strongswan/templates/config/plugins/curl.conf
 usr/share/strongswan/templates/config/plugins/gcrypt.conf
 usr/share/strongswan/templates/config/plugins/ldap.conf
 usr/share/strongswan/templates/config/plugins/pkcs11.conf
+usr/share/strongswan/templates/config/plugins/bliss.conf
+usr/share/strongswan/templates/config/plugins/chapoly.conf
+usr/share/strongswan/templates/config/plugins/ntru.conf
+usr/share/strongswan/templates/config/plugins/sha3.conf
 usr/share/strongswan/templates/config/plugins/test-vectors.conf
 etc/strongswan.d/charon/ccm.conf
 etc/strongswan.d/charon/cmac.conf
@@ -23,4 +31,8 @@ etc/strongswan.d/charon/curl.conf
 etc/strongswan.d/charon/gcrypt.conf
 etc/strongswan.d/charon/ldap.conf
 etc/strongswan.d/charon/pkcs11.conf
+etc/strongswan.d/charon/bliss.conf
+etc/strongswan.d/charon/chapoly.conf
+etc/strongswan.d/charon/ntru.conf
+etc/strongswan.d/charon/sha3.conf
 etc/strongswan.d/charon/test-vectors.conf
diff --git a/debian/rules b/debian/rules
index 3c8e139..be5c182 100755
--- a/debian/rules
+++ b/debian/rules
@@ -22,6 +22,7 @@ CONFIGUREARGS := --libdir=/usr/lib --libexecdir=/usr/lib \
 		--enable-error-notify \
 		--enable-unity \
 		--enable-connmark \
+		--enable-bliss --enable-chapoly --enable-ntru --enable-sha3 \
 		--disable-blowfish --disable-des # BSD-Young license
 	#--with-user=strongswan --with-group=nogroup
 	#	--enable-kernel-pfkey --enable-kernel-klips \
-- 
2.6.2



signature.asc
Description: PGP signature

Bug#799007: bouncycastle: please package a newer version or upload 1.51-1 to unstable

[Markus Koschany]

Am 30.11.2015 um 22:19 schrieb Emmanuel Bourg:
[...]
> Optional dependencies are still required at compile time. They are just
> optional at runtime, when tika-parsers is used by another Maven project
> (which makes sense since the rdeps only use a small subset of the
> parsers supported by Tika). If there are missing dependencies they have
> to be added to maven.ignoreRules.

Ok, it's a bit strange because Maven complains about 23 missing
artifacts and some (most) of them should also be required by the current
Tika version but they are not listed in maven.ignoreRules... I'll see
what I can do tomorrow.





signature.asc
Description: OpenPGP digital signature

Bug#806505: libqt4-network: failed looksup on SSLv3_*_method

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 30 November 2015 13:37:39 Jon DeVree wrote:
> On Mon, Nov 30, 2015 at 15:19:06 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
[snip] 
> > I have just checked the code and it doesn't seems to be necessary.
> 
> I pretty much just cloned what was done for SSLv2. In fact, I just
> thought to check qt5 and the patch that was applied there for SSLv3 is
> functionally identical to what I wrote for qt4.

Fantastic! I'm about to push the packages to the archive.

-- 
I must confess, I was born at a very early age.
 -- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#742429: isenkram: Please use PackageKit

[Julian Andres Klode]

Control: severity -1 important

Increasing the severity of the bug to prepare for the upcoming
removal of aptdaemon.

Canonical/Ubuntu decided to drop aptdaemon, so there will soon
be no active upstream anymore. As such, I plan to remove aptdaemon
from the archive before the stretch release.

On Sun, Mar 23, 2014 at 06:40:41PM +0100, Petter Reinholdtsen wrote:
> [Julian Andres Klode]
> > Please make isenkram use PackageKit. aptdaemon is not part of the
> > default GNOME install (or any other). We do not have much software
> > using it, and the less, the better. We might drop aptdaemon
> > sometime, there are not many working on it.
> 
> I would be happy to use packagekit instead of aptdaemon, but have no
> idea yet how to do that.  Patches welcome. :)
> 
> How do packagekid handle debconf questions?

I'm sorry I can't help here directly. debconf questions should work
in some way, I personally don't use it though. You might want to ask
ximion for details and help on IRC.


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#806752: devscripts compilation failing

[Nicholas Bamber]

Package: devscripts
Version: 2.15.9
Severity: important

dscverify gives the following error

nicholas@chilcott:~/src$ dscverify bashdb_4.3.0.91+ds-4.dsc 
Use of uninitialized value $_ in -x at /usr/bin/dscverify line 54.
Can't call method "first" on an undefined value at /usr/bin/dscverify line 54.

I believe that this is because we need an explicit declaration

use List::Util qw(first); 

but I am not sure what else is missing or why this happened since earlier 
versions.
I think it would be a good idea to test that the Perl scripts compile
though this would mean we'd need more build dependencies.

- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
export DEBCHECKOUT_USER='Nicholas Bamber (Periapt) '
export DEBFULLNAME='Nicholas Bamber'
export DEBEMAIL='nicho...@periapt.co.uk'
export BTS_SMTP_AUTH_USERNAME='nicho...@periapt-technologies.co.uk'
export BTS_SMTP_AUTH_PASSWORD='v(H>c]cC<00e)(=w?KrdV@[r]'
export BTS_SMTP_HOST=smtp.periapt-technologies.co.uk

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.18.3
ii  libc62.19-22
ii  perl 5.20.2-6
ii  python3  3.4.3-7
pn  python3:any  

Versions of packages devscripts recommends:
ii  at  3.1.16-1
ii  curl7.45.0-1+b1
ii  dctrl-tools 2.24-1
ii  debian-keyring  2015.08.13
ii  dput-ng [dput]  1.10
ii  equivs  2.0.9+nmu1
ii  fakeroot1.20.2-1
ii  file1:5.25-2
ii  gnupg   1.4.19-6
ii  libdistro-info-perl 0.14
ii  libencode-locale-perl   1.05-1
ii  libjson-perl2.90-1
ii  liblwp-protocol-https-perl  6.06-2
ii  libsoap-lite-perl   1.19-1
ii  liburi-perl 1.69-1
ii  libwww-perl 6.13-1
ii  lintian 2.5.38.1
ii  man-db  2.7.5-1
ii  patch   2.7.5-1
ii  patchutils  0.3.4-1
ii  python3-debian  0.1.27
ii  python3-magic   1:5.25-2
ii  sensible-utils  0.0.9
ii  strace  4.10-3
ii  unzip   6.0-20
ii  wdiff   1.2.2-1
ii  wget1.17-1
ii  xz-utils5.1.1alpha+20120614-2.1

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20150408cvs-1
ii  build-essential  12.1
pn  cvs-buildpackage 
pn  debbindiff   
pn  devscripts-el
pn  gnuplot  
ii  gpgv 1.4.19-6
ii  libauthen-sasl-perl  2.1600-1
ii  libfile-desktopentry-perl0.20-1
ii  libnet-smtp-ssl-perl 1.03-1
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
ii  libyaml-syck-perl1.29-1
ii  mutt 1.5.24-1
ii  openssh-client [ssh-client]  1:6.9p1-3
pn  svn-buildpackage 
ii  w3m  0.5.3-25+b1

-- no debconf information

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

[Francesco Poli]

On Mon, 30 Nov 2015 16:52:26 + Brian Potkin wrote:

> On Sun 29 Nov 2015 at 18:19:18 +, Brian Potkin wrote:
[...]
> > I can reproduce the problem and experience almost the same behaviour as
> > Francesco. For me, it only happens when X is started on tty1 but Ctrl+D
> > on any other terminal takes you back to tty1. Usually the GUI is still
> > displayed but on occasion I have been returned to a screen with just a
> > portion of the Xorg log on it; the machine itself is still responsive
> > to X's mouse and keyboard after this.
> 
> Isn't this the same (or a similar) issue:
> 
>   https://bugs.freedesktop.org/show_bug.cgi?id=93164

That's weird: the misbehavior experienced by Laurent Bigonville is
similar to the one I experience, but his logs are more similar to your
logs (I get more error lines in my Xorg log).
You experience a different misbehavior, since your input devices are
not ignored by X (if I understand correctly).

Anyway, we are talking about three different X drivers (intel, radeon,
nouveau) with different features (for modesetting, and so forth):
hence, maybe the same bug has different symptoms.

I am more and more suspecting that this issue is ultimately caused by
systemd-logind / libpam-systemd...



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


pgpxuhDq834xw.pgp
Description: PGP signature

Bug#798503: ITP: python-boto3 -- Python interface to Amazon's web services

[Eric Evans]

[ Eric Evans ]
> Package: wnpp
> Severity: wishlist
> Owner: Eric Evans 
> 
> * Package name: python-boto3
>   Version : 1.1.3
>   Upstream Author : the boto project
> * URL : https://github.com/boto/boto3
> * License : Apache 2.0
>   Programming Lang: Python
>   Description : Python interface to Amazon's web services
> 
> Boto3 is the Amazon Web Services (AWS) Software Development Kit (SDK) for
> Python, which allows Python developers to write software that makes use of
> services like Amazon S3 and Amazon EC2.
> 
> Boto3 is the API-incompatible successor to Boto (already pacakged as
> python-boto), and depends upon python-botocore (already packaged as
> python-botocore) for low-level access.

A package has been uploaded to NEW:

https://ftp-master.debian.org/new/python-boto3_1.2.2-2.html

-- 
Eric Evans
eev...@debian.org

Bug#792891: [Pkg-xfce-devel] Bug#792891: Acknowledgement (xfce4-screenshooter: in region capture mode, the opacity overlay is sometimes included in the screenshot)

[Yves-Alexis Perez]

control: tag -1 upstream

On sam., 2015-11-28 at 22:34 +0200, Matias Wilkman wrote:
> tag patch
> thanks
> 
> So, having delved into this, I managed to figure out, and partly  
> circumvent, the issue. It's a race condition between the overlay window  
> getting destroyed, and the screenshot being taken. Here's a patch that's  
> applicable against the XFCE git master.
> The problem still appears if you select a delay time of 0, but since that  
> wasn't even possible before I made it so (dunno wtf I'd need to wait on  
> the modes without this overlay problem??), I take it as no biggie; simply  
> make the delay >= 1 sec, when in region mode.

Please ask upstream comment on this.

Regards,
-- 
Yves-Alexis



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

Bug#806698: nmu: tulip/4.7.0dfsg-2 and gcc-arm-none-eabi/15:4.9.3+svn227297-1

[Matthias Klose]

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

tulip needs an update for the new binutils 2.25.90, gcc-arm-none-eabi needs an 
update for isl-0.15.

Bug#806700: hwloc: please enable numa support of mips64 mips64el

[YunQiang Su]

Package: src:hwloc
Version: 1.11.1-1

Please enable numa support for mips64el and mips64.

I tested it on mips64el, it works well.

-- 
YunQiang Su

Bug#806701: apache2 segfaults on git clone

[Harald Dunkel]

Package: apache2
Version: 2.4.10-10+deb8u3

I get a reproducible segmentation fault if I do a git clone
over http (using simple http, not "smart http", not https).
See attached debug output (thread 4).

git is version 2.4.6. Using git 2.6.3 on the client apache2
works fine, but this might be just by chance.


Regards
Harri
root@gittest:/var/cache/apache2# gdb /usr/sbin/apache2 /var/cache/apache2/core
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/sbin/apache2...Reading symbols from /usr/lib/debug//usr/sbin/apache2...done.
done.

warning: core file may not match specified executable file.
[New LWP 2843]
[New LWP 2846]
[New LWP 2845]
[New LWP 2838]
[New LWP 2841]
[New LWP 2847]
[New LWP 2842]
[New LWP 2840]
[New LWP 2844]
[New LWP 2848]
[New LWP 2853]
[New LWP 2849]
[New LWP 2864]
[New LWP 2850]
[New LWP 2851]
[New LWP 2863]
[New LWP 2854]
[New LWP 2852]
[New LWP 2862]
[New LWP 2861]
[New LWP 2855]
[New LWP 2860]
[New LWP 2856]
[New LWP 2859]
[New LWP 2857]
[New LWP 2858]
[New LWP 2865]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/apache2 -k start'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fa2e6dea274 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
(gdb) thread apply all bt full

Thread 27 (Thread 0x7fa2d0fe9700 (LWP 2865)):
#0  0x7fa2e6b1e4bf in accept4 () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x7fa2e701ee88 in apr_socket_accept (new=0x7fa2d0fe8e00, sock=0x7fa2e7b4fe78, connection_context=0x7fa2e7a27028)
at /tmp/buildd/apr-1.5.1/network_io/unix/sockets.c:222
s = 
sa = {pool = 0x0, hostname = 0x0, servname = 0x0, port = 0, family = 0, salen = 128, ipaddr_len = 0, addr_str_len = 0, 
  ipaddr_ptr = 0x0, next = 0x0, sa = {sin = {sin_family = 10, sin_port = 41362, sin_addr = {s_addr = 0}, 
  sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 10, sin6_port = 41362, sin6_flowinfo = 0, sin6_addr = {
__in6_u = {__u6_addr8 = "\000\000\000\000\000\000\000\000\000\000\377\377\254\023a\272", __u6_addr16 = {0, 0, 0, 0, 0, 65535, 
5036, 47713}, __u6_addr32 = {0, 0, 4294901760, 3126924204}}}, sin6_scope_id = 0}, sas = {ss_family = 10, __ss_align = 0, 
  __ss_padding = "\000\000\377\377\254\023a\272\000\000\000\000\242\177\000\000\r\000\000\000\242\177\000\000\360\000\000\000\000\000\000\000\003\000\000\000\000\000\000\000\063", '\000' , "[", '\000' , "n\000\000\000w", '\000' , "|\000\000\000\242\177\000\000\233\361\252\346\242\177\000"}}}
#2  0x7fa2e79647a1 in ap_unixd_accept (accepted=0x7fa2d0fe8e58, lr=0x7fa2e7b4fe38, ptrans=0x7fa2d0fe8d20) at unixd.c:301
csd = 0x7fa2d0fe8e70
status = -407324520
#3  0x7fa2e3b51159 in listener_thread (thd=0x4, dummy=0x7fa2e7b8b898 ) at worker.c:833
tpool = 0x7fa2d0fe8e70
csd = 0x0
ptrans = 0x7fa2e7a27028
pollset = 0x7fa2e7a3b0a0
have_idle_worker = -788624096
last_poll_idx = 0
#4  0x7fa2e6de80a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#5  0x7fa2e6b1d04d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 26 (Thread 0x7fa2d47f0700 (LWP 2858)):
#0  0x7fa2e6dec08f in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1  0x7fa2e701877d in apr_thread_cond_wait (cond=, mutex=)
at /tmp/buildd/apr-1.5.1/locks/unix/thread_cond.c:68
No locals.
#2  0x7fa2e3b52aed in ap_queue_pop (queue=0x7fa2e7b19228, sd=0x7fa2d47efe80, p=0x7fa2d47efe88) at fdqueue.c:352
elem = 
rv = 
#3  0x7fa2e3b503bf in worker_thread (thd=0x7fa2e7b192b4, dummy=0x80) at worker.c:945
process_slot = 0
thread_slot = 18
csd = 0x0
bucket_alloc = 0x0
last_ptrans = 0x0
ptrans = 0x0
is_idle = 0
#4  0x7fa2e6de80a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#5  0x7fa2e6b1d04d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.

Thread 25 (Thread 

Bug#805893: Please confirm the patch.

[Ghislain Vaillant]

This part of the patch still sounds weird to me:

ifneq (,$(filter mips64%el mips64%el,$(DEB_HOST_ARCH)))

The repetition of "mips64%el" looks unnecessary to me.

Besides, since the aim is to catch all future mips64* architectures,
shouldn't  this be enough:

ifneq (,$(filter mips64%,$(DEB_HOST_ARCH)))

Unless I am missing something here. Let me know what you think.

Ghis


2015-11-30 8:00 GMT+00:00 YunQiang Su :

> I tested this patch. It works well for mips64el.
>
> On Fri, Nov 27, 2015 at 11:40 AM, YunQiang Su  wrote:
> > On Wed, Nov 25, 2015 at 6:23 PM, Ghislain Vaillant 
> wrote:
> >> This is the relevant portion of the proposed patch:
> >>
> >>>  ifeq ($(DEB_HOST_ARCH),ppc64el)
> >>>  DEB_CFLAGS_MAINT_APPEND += -mno-altivec
> >>> +DEB_CXXFLAGS_MAINT_APPEND += -mno-altivec
> >>> +endif
> >>> +# Build without Altivec to prevent FTBFS on ppc64el.
> >>> +ifneq (,$(filter mips64%el mips64%el,$(DEB_HOST_ARCH)))
> >>> +DEB_CFLAGS_MAINT_APPEND += -mxgot
> >>> +DEB_CXXFLAGS_MAINT_APPEND += -mxgot
> >>>  endif
> >>
> >> But the explanation is:
> >>
> >>> filter mips%64 mips%64el,$(DEB_HOST_ARCH)
> >>> is due to we may has some other mips64 architectures in future,
> >>> for example: mips64r6{el}.
> >>
> >> The filter string differs between the patch and explanation:
> >
> > The patch is correct.
> >
> > Sorry for it.
> >
> >>
> >> filter mips64%el mips64%el
> >>
> >> and
> >>
> >> filter mips%64 mips%64el.
> >>
> >> One is twice the same (typo?), the other has the percent sign placed
> >> differently.
> >>
> >> Please confirm the correct filter command, otherwise I cannot apply this
> >> patch.
> >>
> >> Thanks,
> >> Ghis
> >
> >
> >
> > --
> > YunQiang Su
>
>
>
> --
> YunQiang Su
>

Bug#806704: procps: please enable numa support of mips64 mips64el

[Craig Small]

Should be just a matter of adding mips64el into the list of architectures
that need libnuma-dev. I'll add it into the next update.

 - Craig


On Mon, Nov 30, 2015 at 8:39 PM YunQiang Su  wrote:

> Package: src:procps
> Version: 2:3.3.10-4
>
> Please enable numa support for mips64el and mips64.
>
> I tested it on mips64el, it works well.
>
> --
> YunQiang Su
>
> --
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Bug#806701: apache2 segfaults on git clone

[Harald Dunkel]

PS: I tried apache2 2.4.17-3 (built on Jessie): It dies, too.
Regards
Harri

Bug#806706: pandas: new upstream release (0.17.1)

[Sandro Tosi]

Source: pandas
Severity: wishlist

Hello,
pandas 0.17.1 has been release, would be great to update the debian package.

Regards,
Sandro

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

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

Bug#805893: Please confirm the patch.

[YunQiang Su]

On Mon, Nov 30, 2015 at 5:49 PM, Ghislain Vaillant  wrote:
> This part of the patch still sounds weird to me:
>
> ifneq (,$(filter mips64%el mips64%el,$(DEB_HOST_ARCH)))
>
> The repetition of "mips64%el" looks unnecessary to me.
>
> Besides, since the aim is to catch all future mips64* architectures,
> shouldn't  this be enough:
>
> ifneq (,$(filter mips64%,$(DEB_HOST_ARCH)))

yeah, it sounds good.

>
> Unless I am missing something here. Let me know what you think.
>
> Ghis
>
>
> 2015-11-30 8:00 GMT+00:00 YunQiang Su :
>>
>> I tested this patch. It works well for mips64el.
>>
>> On Fri, Nov 27, 2015 at 11:40 AM, YunQiang Su  wrote:
>> > On Wed, Nov 25, 2015 at 6:23 PM, Ghislain Vaillant 
>> > wrote:
>> >> This is the relevant portion of the proposed patch:
>> >>
>> >>>  ifeq ($(DEB_HOST_ARCH),ppc64el)
>> >>>  DEB_CFLAGS_MAINT_APPEND += -mno-altivec
>> >>> +DEB_CXXFLAGS_MAINT_APPEND += -mno-altivec
>> >>> +endif
>> >>> +# Build without Altivec to prevent FTBFS on ppc64el.
>> >>> +ifneq (,$(filter mips64%el mips64%el,$(DEB_HOST_ARCH)))
>> >>> +DEB_CFLAGS_MAINT_APPEND += -mxgot
>> >>> +DEB_CXXFLAGS_MAINT_APPEND += -mxgot
>> >>>  endif
>> >>
>> >> But the explanation is:
>> >>
>> >>> filter mips%64 mips%64el,$(DEB_HOST_ARCH)
>> >>> is due to we may has some other mips64 architectures in future,
>> >>> for example: mips64r6{el}.
>> >>
>> >> The filter string differs between the patch and explanation:
>> >
>> > The patch is correct.
>> >
>> > Sorry for it.
>> >
>> >>
>> >> filter mips64%el mips64%el
>> >>
>> >> and
>> >>
>> >> filter mips%64 mips%64el.
>> >>
>> >> One is twice the same (typo?), the other has the percent sign placed
>> >> differently.
>> >>
>> >> Please confirm the correct filter command, otherwise I cannot apply
>> >> this
>> >> patch.
>> >>
>> >> Thanks,
>> >> Ghis
>> >
>> >
>> >
>> > --
>> > YunQiang Su
>>
>>
>>
>> --
>> YunQiang Su
>
>



-- 
YunQiang Su

Bug#803658: boot hangs before cryptsetup passphrase prompt

[Stefano Zacchiroli]

On Sun, Nov 29, 2015 at 09:20:55PM +0100, Laurent Bigonville wrote:
> >- it now works, YAY (and thanks!). But I conclude from the whole
> >   experience that before now plymouth was somehow able to fallback to
> >   askpass after self-detecting some sort of failure, while new versions
> >   aren't any more. If that's the case, this might affect other users
> 
> Before the last update, plymouth was not enabled at all if splash was not
> passed to the kernel cmdline, now the plymouth daemon is started even if
> it's not passed, that probably explain the change of behavior.

Possibly. Although please note that "splash" *is* on my kernel cmdline,
and has been since forever.

> >- does the above mean that now non-free firmware is required to use
> >   plymouth on i915 hardware? Or was the warning about something else
> >   that is not strictly needed to make plymouth work? (sorry, I haven't
> >   yet tried to re-remove the firmware and see what happens)
>
> I'm not sure, I don't have a machine with an intel card to test, you should
> test without them.

I've tested this. Even after purging firmware-misc-nonfree (and
rebuilding the initramfs, which results in the aforementioned warning)
the boot still works fine.

> >-http://upsilon.cc/~zack/stuff/IMG_20151129_174719.jpg
> >-http://upsilon.cc/~zack/stuff/IMG_20151129_174736.jpg
> >-http://upsilon.cc/~zack/stuff/IMG_20151129_174751.jpg
>
> I cannot reproduce this without an intel card, could you please report this
> upstream?

To be frank, I don't think I've a decent enough understanding of what is
supposed to happen to be able to file a proper upstream bug report. In
particular, I've no idea of whether plymouth is supposed to work without
adding i915 to /etc/initramfs-tools/modules or not. If adding the module
there is a requirement, then arguably this bug is actually PEBKAC. But
if users (at least in Debian) started to rely on that behavior, than a
work-around might be needed. Not sure if it should be upstream or
distro-level though.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Bug#806593: does not start (Models for app haven't been imported yet) after upgrade

[Stephan Sürken]

Hi Marc,

On So, 2015-11-29 at 13:56 +0100, Marc Haber wrote:
(...)
> Please advice what to do how to get up and running again, and if this
> is an issue within the package, please consider fixing it.

this (at least with django 1.8) is due to python-django-registration;
you would need to apply the (already provided) patch for that package
(or downgrade to django 1.7).

Maybe more devilry is coming up with django 1.9, so sticking with django
1.7 is the best advice for some time for a sid system, I guess.

Hth!

S

Bug#806707: approx cronjob fails on kfreebsd and hurd

[Carsten Leonhardt]

Package: approx
Version: 5.5-1
Severity: normal
Control: tags -1 patch

Dear Maintainer,

I have an approx installation on a kfreebsd-amd64 machine. The cron job
emits the following error:

> /etc/cron.weekly/approx:
> nice: ionice: No such file or directory
> run-parts: /etc/cron.weekly/approx exited with return code 127

ionice is not available on kfreebsd-any nor on hurd-i386.

(See for example the build logs for util-linux for these ports:
https://buildd.debian.org/status/package.php?p=util-linux=unstable)

It's probably easiest to check for ionice availabilty at runtime, I've
attached a patch.

Thanks,

leo

--- debian/approx.cron.weekly.orig	2015-11-30 11:06:55.784478675 +0100
+++ debian/approx.cron.weekly	2015-11-30 11:06:55.784478675 +0100
@@ -2,6 +2,12 @@
 
 # Garbage collect the approx(8) cache
 
+# only use ionice if available, kfreebsd and hurd lack it
+unset IONICE
+if [ -x /usr/bin/ionice ]; then
+IONICE="ionice -c3"
+fi
+
 if [ -x /usr/sbin/approx-gc ]; then
-nice -n19 ionice -c3 /usr/sbin/approx-gc --quiet
+nice -n19 $IONICE /usr/sbin/approx-gc --quiet
 fi

Bug#802410: openais: FTBFS: error: corosync/coroipc_types.h: No such file or directory

[Fernando Seiti Furusato]

Source: openais
Version: 1.1.4-4.2
Followup-For: Bug #802410

It also fails on ppc64el and other architectures FWIW:
https://buildd.debian.org/status/package.php?p=openais=sid
This seems to be a problem with the dependency on corosync-dev.
Newest version of corosync does not ship the file in question,
coroipc_types.h.
An easy way to fix this would be to restrict build-dep on the specific
version that still has that file.
The problem would be that sid repository does not seem to have the binary
of the previous version available (at least for ppc64el).

The patch attached ilustrates what I tried to explain above.

Regards.

Fernando
diff -Nru openais-1.1.4/debian/changelog openais-1.1.4/debian/changelog
--- openais-1.1.4/debian/changelog	2014-07-03 21:44:36.0 -0400
+++ openais-1.1.4/debian/changelog	2015-11-30 11:35:06.0 -0500
@@ -1,3 +1,11 @@
+openais (1.1.4-4.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Set version of libcorosync-dev and added corosync-dev package to the
+latest one that contain coroipc_types.h. 
+
+ -- Fernando Seiti Furusato   Mon, 30 Nov 2015 11:34:04 -0500
+
 openais (1.1.4-4.2) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru openais-1.1.4/debian/control openais-1.1.4/debian/control
--- openais-1.1.4/debian/control	2014-06-06 05:56:34.0 -0400
+++ openais-1.1.4/debian/control	2015-11-30 11:33:58.0 -0500
@@ -5,7 +5,7 @@
 Uploaders: Martin Loschwitz , Bastian Blank , Frederik Schüler ,
  Guido Günther 
 Standards-Version: 3.9.2
-Build-Depends: debhelper (>> 5), libcorosync-dev (>= 1.1.0), pkg-config, groff, dh-autoreconf
+Build-Depends: debhelper (>> 5), libcorosync-dev (>= 1.1.0), libcorosync-dev (<= 1.4.6-1.1), corosync-dev (>= 1.1.0), corosync-dev (<= 1.4.6-1.1), pkg-config, groff, dh-autoreconf
 Vcs-Git: git://git.debian.org/debian-ha/openais.git
 Vcs-Browser: http://git.debian.org/?p=debian-ha/openais.git;a=summary
 

Bug#803033: Update on licensing

[Martín Ferrari]

Hi, I have been looking at this issue. The current versions of these
data files are now covered by a different license, which I suspect is
non-free as it does not expressly allow modification:

#   Unicode, Inc. hereby grants the right to freely use the information
#   supplied in this file in the creation of products supporting the
#   Unicode Standard, and to make copies of this file in any form for
#   internal or external distribution as long as this notice remains
#   attached.
#

There is also a blanket statement with a really free license that seems
supposed to cover these files: http://unicode.org/copyright.html#Exhibit1

I have mailed them asking for clarification. Hopefully, this is a
mistake and they actually intend to distribute these data files under a
free license.

-- 
Martín Ferrari (Tincho)

Bug#804496: openms: GSL transition requires rebuild

[Filippo Rusconi]

Greetings Dirk,

Thanks for your bug report.

On Sun, Nov 08, 2015 at 05:24:54PM -0600, Dirk Eddelbuettel wrote:


Package: openms
Severity: serious

The GNU GSL, upon which your package as a build- and run-time dependency, had
a 2.0 release [1] which introduced minor incompatibilities with the previous
(1.6) release. I had left the package for many years at libgsl0ldbl because
such a transition was never needed. But this warranted a change.

Your package as a versioned 'Depends: libgsl0ldbl (>= 1.X)' for some value of
X which cannot be satisfied by the Provides: we added to libgsl2.  So this
requires a rebuild of your package against libgsl-dev (>= 2.0).

If you have any questions please do not hesitate to get in touch. The release
team has also been exceptional on this (as usual, they do rock) so see

  http://bugs.debian.org/804246



I have tried to rebuild libOpenMS with the new dependency and that
fails with an error due to an abi change.

I have sent that error message to upstream. I am waiting for their
response.

Regards,

Filippo

--
Filippo Rusconi, PhD - public crypto key 7694CF42@ pgp.mit.edu
Researcher at CNRS and Debian Developer 
Author of ``massXpert'' at http://www.massxpert.org

Bug#806735: transition: glibc

[Julien Cristau]

Control: tag -1 confirmed

On Mon, Nov 30, 2015 at 17:01:35 +0100, Aurelien Jarno wrote:

> We would like to get a transition slot for glibc 2.21. It is currently
> available in experimental and has been built successfully on all release
> architectures. We have fixed the hppa and mips64el build failure in the,
> SVN, so the next upload should really build everywhere.
> 
Go ahead, let us know when it's built everywhere and binNMUs need to be
scheduled.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#806738: iceweasel: Sync is very long and slow

[Pierre Crescenzo]

Package: iceweasel
Version: 42.0-1~bpo80+1
Severity: normal

Hello,

I use Iceweasel for a long time. Since some weeks, the Sync function is for me
very long and slow, and it slows all other Iceweasel functionality like
navigation. No apparent consequence on other software. If I deactivate Sync,
all is OK.

Thank you for your help.

Pierre Crescenzo



-- Package-specific info:

-- Extensions information
Name: A Spatial Observance theme
Status: enabled

Name: Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Package: xul-ext-adblock-plus
Status: enabled

Name: Add to feedly
Location: ${PROFILE_EXTENSIONS}/jid1-yzsghbpharn...@jetpack.xpi
Status: user-disabled

Name: AddInto
Location: ${PROFILE_EXTENSIONS}/cont...@addinto.com
Status: enabled

Name: All-in-One Sidebar
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{097d3191-e6fa-4728-9826-b533d755359d}
Package: xul-ext-all-in-one-sidebar
Status: user-disabled

Name: Autofill Forms
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/autofillfo...@blueimp.net
Package: xul-ext-autofill-forms
Status: enabled

Name: Automatic Save Folder
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/a...@mangaheart.org
Package: xul-ext-automatic-save-folder
Status: user-disabled

Name: Certificate Patrol
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/certpat...@psyc.eu
Package: xul-ext-certificatepatrol
Status: user-disabled

Name: Cookie Monster
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{45d8ff86-d909-11db-9705-005056c8}
Package: xul-ext-cookie-monster
Status: user-disabled

Name: Custom Tab Width
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/tab-wi...@design-noir.de
Package: xul-ext-custom-tab-width
Status: user-disabled

Name: Debian buttons
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8fb11c5b-84eb-4da0-9128-292eacce2dcb}
Package: xul-ext-debianbuttons
Status: user-disabled

Name: Default theme
Location: 
/usr/lib/iceweasel/browser/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}
Package: iceweasel
Status: user-disabled

Name: Dictionnaires français dictionary
Location: ${PROFILE_EXTENSIONS}/fr-dicolle...@dictionaries.addons.mozilla.org
Status: enabled

Name: DOM Inspector
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/inspec...@mozilla.org
Package: xul-ext-dom-inspector
Status: user-disabled

Name: DownThemAll!
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{DDC359D1-844A-42a7-9AA1-88A850A938A8}
Package: xul-ext-downthemall
Status: user-disabled

Name: Element Hiding Helper pour Adblock Plus
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/elemhidehel...@adblockplus.org
Package: xul-ext-adblock-plus-element-hiding-helper
Status: user-disabled

Name: En-têtes HTTP en direct
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{8f8fe09b-0bd3-4470-bc1b-8cad42b8203a}
Package: xul-ext-livehttpheaders
Status: user-disabled

Name: Firebug
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/fire...@software.joehewitt.com
Package: xul-ext-firebug
Status: user-disabled

Name: FireGestures
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/firegestu...@xuldev.org
Package: xul-ext-firegestures
Status: user-disabled

Name: FirePath
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/firexp...@pierre.tholence.com
Package: xul-ext-firexpath
Status: user-disabled

Name: FireTray
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{9533f794-00b4-4354-aa15-c2bbda6989f8}
Package: xul-ext-firetray
Status: user-disabled

Name: Flashblock
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{3d7eb24f-2740-49df-8937-200b1cc08f8a}
Package: xul-ext-flashblock
Status: user-disabled

Name: FlashGot
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/{19503e42-ca3c-4c27-b1e2-9cdb2170ee34}
Package: xul-ext-flashgot
Status: user-disabled

Name: Form History Control
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/formhist...@yahoo.com
Package: xul-ext-form-history-control
Status: enabled

Name: FoxyProxy Standard
Location: 
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/foxypr...@eric.h.jung
Package: xul-ext-foxyproxy-standard
Status: user-disabled

Name: Français Language Pack locale
Location: 
/usr/lib/iceweasel/browser/extensions/langpack...@iceweasel.mozilla.org.xpi
Package: iceweasel-l10n-fr
Status: enabled

Name: Fullscreen theme
Location: 

Bug#806709: autopkgtest fails on armhf: "(pinpoint:3924): GLib-CRITICAL **: g_strsplit: assertion 'string != NULL' failed"

[Iain Lane]

Control: tags -1 + patch

On Mon, Nov 30, 2015 at 09:51:38AM -0200, Antonio Terceiro wrote:
> This breaks the tests for me on amd64, both directly on my development machine
> with adt-virt-null, and under adt-virt-lxc. Both fail with:
> 
> xvfb-run: error: Xvfb failed to start
> 
> Neither changing the server number to something different from 0 nor fiddling
> with the resolution paremeter (tried e.g. 640x480x8) seem to help.

There was a bug which manifested itself on Ubuntu/armhf only (might be a
coincidence). I should have passed -a because it seems there's a race
taking down the Xvfbs after one run and before the next, so they need to
figure out server numbers for themselves. Try the attached diff (it
works for Ubuntu - see the link below).

> Isn't it masking a problem that is actually down the stack?

I think that this is because using clutter-gtk requires that you now
support (e)gl. For Ubuntu, mesa (? I'm a bit sketchy on this stack)
requires egl instead of gl for armhf, and that appears to require X to
be started up in this way. So I don't think it's masking a problem, more
a changed set of requirements since the port.

And now that enough time has passed, we have autopkgtest results for
Xenial - all green now:

  http://autopkgtest.ubuntu.com/packages/p/pinpoint/

Cheers,

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]
diff -Nru pinpoint-0.1.8/debian/tests/smoke-tests 
pinpoint-0.1.8/debian/tests/smoke-tests
--- pinpoint-0.1.8/debian/tests/smoke-tests 2015-11-19 12:33:29.0 
+
+++ pinpoint-0.1.8/debian/tests/smoke-tests 2015-11-30 13:07:09.0 
+
@@ -5,7 +5,7 @@
 set -e
 
 pinpoint() {
-  xvfb-run --auto-servernum /usr/bin/pinpoint "$@"
+  xvfb-run -a -s "-screen 0 1024x768x24" /usr/bin/pinpoint "$@"
 }
 
 test_pdf_output() {


signature.asc
Description: Digital signature

Bug#806256: libpam-systemd: log out from a TTY and your X input devices get lost!

[Brian Potkin]

On Sun 29 Nov 2015 at 18:19:18 +, Brian Potkin wrote:

> On Sun 29 Nov 2015 at 01:05:44 +0100, Michael Biebl wrote:
> 
> > Am 28.11.2015 um 19:23 schrieb Francesco Poli:
> > 
> > > Please tell me whether you need any further information in order to
> > > investigate. Otherwise, please drop the moreinfo tag.
> > 
> > So far I don't know yet, how I can reproduce the problem. So I'll keep
> > the moreinfo tag.
> 
> I can reproduce the problem and experience almost the same behaviour as
> Francesco. For me, it only happens when X is started on tty1 but Ctrl+D
> on any other terminal takes you back to tty1. Usually the GUI is still
> displayed but on occasion I have been returned to a screen with just a
> portion of the Xorg log on it; the machine itself is still responsive
> to X's mouse and keyboard after this.

Isn't this the same (or a similar) issue:

  https://bugs.freedesktop.org/show_bug.cgi?id=93164

Bug#806504: lintian: malformed-override Cannot parse line 9: missing-dependency-on-libstdc++

[Jakub Wilk]

Control: tags -1 + pending

Hi Andreas!

Thanks for the bug report.

* Andreas Beckmann , 2015-11-28, 06:17:
I'd guess that lintian does not accept the '+' character in tags when 
reading the overrides, resulting in this:


E: nvidia-cuda-dev: malformed-override Cannot parse line 9: 
missing-dependency-on-libstdc++
X: nvidia-cuda-dev: missing-dependency-on-libstdc++ needed by 
usr/lib/x86_64-linux-gnu/stubs/libcublas.so and 10 others


Right. The regexp we currently use (in lib/Lintian/Tags.pm:546) for tag 
names is:


[\-\.a-zA-Z_0-9]+

So the "+" character was not allowed, making it impossible to override 
these tags:


missing-dependency-on-libstdc++
source-contains-autogenerated-visual-c++-file

I've committed fix for this bug.

I'd prefer these tags to be emitted once for each occurence and not 
grouped together with "and X others".


Sounds reasonable. Would you mind filing a separate bug about it?

--
Jakub Wilk

Bug#806426: Some TLS certificates not suppoprted

[Andreas Metzler]

On 2015-11-30 Aleś Bułojčyk  wrote:
> On 28 November 2015 at 22:07, Andreas Metzler  wrote:
>> On 2015-11-27 Aleś Bułojčyk  wrote:
>>> Package: libgnutls-deb0-28
>>> Version: 3.3.8-6+deb8u3

>>> I can't connect to many https hosts using Debian 8.2:

>>> $ gnutls-cli google.com
>>> Processed 173 CA certificate(s).
>>> Resolving 'google.com'...
>>> Connecting to '216.58.209.142:443'...
>>> |<1>| Received record packet of unknown type 72
>>> *** Fatal error: An unexpected TLS packet was received.
>>> *** Handshake has failed
>>> GnuTLS error: An unexpected TLS packet was received.
[...]

>> I don not see the error, are you positive that there is no local
>> breakage?
[...]
> It shouldn't be a local issue. It's fresh installation of latest Debian
> amd64 into VirtualBox(without VirtualBox guest additions).
[...]

Hello,

I am stumped, could you plese post the output of
gnutls-cli -V -d 4711 freedns.afraid.org

Thanks,
cu Andreas

PS: I would appreciate
https://www.netmeister.org/news/learn2quote.html if possible. TIA

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

Bug#615459: i47 youth shared the list “نسخ” with you, on Wunderlist

[i47 youth]

i47 youth shared the list https://t.wunderlist.com/z/uxuWNzc2NTc2NjUyMjYENPrZMr40NTSHf6Ed7QAAc2hhcu0vEzIyNjczNzEvNDc26TOsMx7Zu6cPuen5puGiNzQyNjMy1mN-FDSImJE5ABiRNwk1AHNoYXJpbmctbGlzdC1tZW2-cnNoaXAtY3LqdO0tBDI0AGJ1dHRvbl9saW5r;
 style="color: rgb(43, 136, 217); text-decoration: underline;">“نسخ” with 
you, using Wunderlist.


Join List: 
https://t.wunderlist.com/z/uxuWNzc2NTc2NjUyMjYENPrZMr40NTSHf6Ed7QAAc2hhcu0vEzIyNjczNzEvNDc26TOsMx7Zu6cPuen5puGiNzQyNjMy1mN-FDSImJE5ABiRNwk1AHNoYXJpbmctbGlzdC1tZW2-cnNoaXAtY3LqdO0tBDI0AGJ1dHRvbl9saW5r

--
Copyright 2015 Wunderlist

Bug#805880: closed by Ben Hutchings <b...@decadent.org.uk> (Bug#805880: fixed in linux 3.2.73-2)

[Thomas Guyot-Sionnest]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Confirmed working on Version 3.2.73-2.

Thanks

- --
Thomas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlZccZoACgkQ6dZ+Kt5BchZFMwCgntw3JUGuN8c4hr8Sg4yXUfHd
sOcAnRCG3vpokYXFaTSKXK9WLLPspXY9
=i+Qn
-END PGP SIGNATURE-

Bug#806732: [Pkg-sass-devel] Bug#806732: [PATCH] libsass: change needed for version 3.3.x

[Frederic Bonnard]

Hi Jonas,
> Sounds good.  Looks like you forgot to include the patch, though.

.. :D
Sorry for that, here is it.

F.

>  - Jonas
> 
> -- 
>  * Jonas Smedegaard - idealist & Internet-arkitekt
>  * Tlf.: +45 40843136  Website: http://dr.jones.dk/
> 
>  [x] quote me freely  [ ] ask before reusing  [ ] keep private
diff -baupr ./libsass-python/libsass-3.2.5/debian/control libsass-3.3.1/debian/control
--- ./libsass-python/libsass-3.2.5/debian/control	2015-06-20 20:09:27.0 +0200
+++ libsass-3.3.1/debian/control	2015-11-02 14:04:31.0 +0100
@@ -9,7 +9,8 @@ Build-Depends: cdbs (>= 0.4.123~),
  debhelper,
  dh-buildinfo,
  autoconf-archive,
- d-shlibs (>= 0.50)
+ d-shlibs (>= 0.50),
+ dh-autoreconf
 Maintainer: Debian Sass team 
 Uploaders: Jonas Smedegaard 
 Standards-Version: 3.9.6
diff -baupr ./libsass-python/libsass-3.2.5/debian/rules libsass-3.3.1/debian/rules
--- ./libsass-python/libsass-3.2.5/debian/rules	2015-05-13 23:36:53.0 +0200
+++ libsass-3.3.1/debian/rules	2015-11-02 14:03:26.0 +0100
@@ -31,6 +31,7 @@ include /usr/share/cdbs/1/rules/upstream
 include /usr/share/cdbs/1/rules/utils.mk
 include /usr/share/cdbs/1/class/autotools.mk
 include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
 
 pkg = $(DEB_SOURCE_PACKAGE)
 stem = $(patsubst lib%,%,$(pkg))

Bug#806673: ifupdown: doesn't configure IPv6 addresses over WLAN anymore

[Christoph Anton Mitterer]

On Mon, 2015-11-30 at 09:09 +0100, Guus Sliepen wrote:
> > Well but why wouldn't it get the RAs for v4 and not for v6?
> There is no RA for IPv4, only DHCP.
Argl... that's why I shouldn't write mails so late in the evening.

I meant: why would it get the RAs via ethernet, but not via Wifi :D


> > > And if I have just:
> > > iface wlan0-bar inet6 dhcp|auto
> > > wpa-ssidbar
> > > 
> > > wpa-key-mgmtWPA-PSK
> > > wpa-psk foo
> > I even get:
> > # ifup wlan0
> > wpa_supplicant: /sbin/wpa_supplicant daemon failed to start
> > run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with
> > return code 1
> > Failed to bring up wlan0-bar.
> 
> Ah, I'll try to reproduce this problem.
Thanks. :)


I also don't yet understand the basic idea of how especially dual
stacked ifaces (and basically most network connections are dual stacked
these days) should be properly described in /e/n/interfaces.

For lo, people typically just use:
iface lo inet loopback
and no second
iface lo inet6 loopback

For others, typically eth/wlan I wonder a bit what's the way of doing
it correctly:
a) like you said
iface wlan0-bar inet dhcp
        wpa-ssidbar

        wpa-key-mgmtWPA-PSK
        wpa-psk foo
iface wlan0-bar inet6 dhcp|auto
=> what if v4 would become disabled there? would it still apply the
wpa-settings to the connection?

b) or doubling everything:
iface wlan0-bar inet dhcp
        wpa-ssidbar

        wpa-key-mgmtWPA-PSK
        wpa-psk foo
iface wlan0-bar inet6 dhcp|auto
        wpa-ssidbar

        wpa-key-mgmtWPA-PSK
        wpa-psk foo

=> which leads to the question, what happens if I do that with scripts:
iface eth0 inet dhcp
post-up vpnc something
pre-down vpnc-disconnect
iface eth0 inet6 dhcp
post-up vpnc something
pre-down vpnc-disconnect


Cheers,
Chris.

smime.p7s
Description: S/MIME cryptographic signature

Bug#806705: quantlib: fails to build on some arm64 buildds

[Edmund Grimley Evans]

> Should we even consider not building at all?

I think you should build it on arm64, where it could easily be useful.

I'm not so sure about people using quantlib on armel systems, which
are typically very low-performance, but, seeing as it builds there
(without the tests), I don't see a reason to specially remove it.

Bug#806732: [PATCH] libsass: change needed for version 3.3.x

[Frederic Bonnard]

Source: libsass
Source-Version: 3.2.5-1
Tags: patch

--

Hi,
libsass can be updated to the new version 3.3.2.
In the process of packaging libsass-python :
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804697
I had to upgrade libsass to libsass 3.3.x and noticed I had to do a few
changes to the debian/ packaging of version 3.2.5.
So here is a patch to apply on top of 3.2.5 packaging for 3.3.x upgrade.
Thanks,

F.

Bug#737843: manipulate unzip behavior

[Osamu Aoki]

Hi,

zip has -a -aa -b ... mostly for non-unix platform needs from the
previous days.

So there is no strong argument to select -a.  So I added --unzipopt
option and watch file option.

Osamu

Bug#806463: java-package: Make-jpkg corrupts the Java Mission Control tool such that it is unable to run.

[Emmanuel Bourg]

Le 30/11/2015 14:20, Christian Weeks a écrit :
> No? I ran the packaged version and it failed (tested u60, u66, j7u87). I
> extracted the same tar to the same disk and ran from extracted place,
> and it worked fine..

Do you think you could upload the defective .deb somewhere so I can
compare it with mine?

Bug#806710: qgis cannot be installed

[Julien Cristau]

On Mon, Nov 30, 2015 at 12:06:15 +0100, Bas Couwenberg wrote:

> Please push the gsl maintainer and Release Team via the transition bug
> report to get the remaining reverse dependencies rebuilt.
> 
No, please don't.

Cheers,
Julien


signature.asc
Description: PGP signature

Bug#806733: vpnc: DNS stops working when using multiple domain names.

[Daniel Guerrero]

Package: vpnc
Version: 0.5.3r550-
Severity: important

Dear Maintainer,

  $ nslookup google.com
  nslookup: parse of /etc/resolv.conf failed

These are the contents of resolv.conf: 

  # Generated by resolvconf
  domain example.local example.com
  search example.local example.com
  nameserver 172.16.1.115
  nameserver 192.168.1.114
  nameserver 192.168.2.200
  nameserver 192.168.32.241

The parsing seems to break on the "domain" line. Seems that vpnc is using the
domain names as the default one. This is incorrect when more than one domain is
configured. 

If I edit resolv.conf like this:

  # Generated by resolvconf 
  domain example.local 
  search example.local example.com
  nameserver 172.16.1.115
  nameserver 192.168.1.114
  nameserver 192.168.2.200
  nameserver 192.168.32.241 
  nslookup: parse of /etc/resolv.conf failed

Then name resolution works again. 

I would suggest that vpnc refrains from setting the default domain. AFAIK 
setting the "search" domains is enough in most if not all cases.


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

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

Versions of packages vpnc depends on:
ii  dpkg   1.17.25
ii  libc6  2.19-18+deb8u1
ii  libgcrypt201.6.3-2
ii  libgnutls-deb0-28  3.3.8-6+deb8u3
ii  perl   5.20.2-3+deb8u1
ii  vpnc-scripts   0.1~git20140806-1

Versions of packages vpnc recommends:
ii  iproute  1:3.16.0-2

Versions of packages vpnc suggests:
ii  openresolv [resolvconf]  3.5.2-1

-- Configuration Files:
/etc/vpnc/default.conf [Errno 13] Permiso denegado: u'/etc/vpnc/default.conf'

-- no debconf information

Bug#806734: xtrlock: add custom passphrase

[tetris]

Package: xtrlock
Version: 2.7-1
Severity: wishlist
Tags: patch


The attached patch adds an extra command-line option to xtrlock:
  -p :  prompt user for a custom passphrase (no echo)


This options overrides using the users' password/shadow to unlock the
screen and uses a custom passphrase instead.

Option works with the -b (blank) flag just fine.

Cheers,
-- tetris11

Kernel:  4.2.5-1
Arch: x86_64
/*
 * xtrlock.c
 *
 * X Transparent Lock
 *
 * Copyright (C)1993,1994 Ian Jackson
 *
 * This is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.
 *
 * This is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 */

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* required for custom passwd prompt --tetris11 */
#include   

#ifdef SHADOW_PWD
#include 
#endif

#include "lock.bitmap"
#include "mask.bitmap"
#include "patchlevel.h"

Display *display;
Window window, root;

#define TIMEOUTPERATTEMPT 3
#define MAXGOODWILL  (TIMEOUTPERATTEMPT*5)
#define INITIALGOODWILL MAXGOODWILL
#define GOODWILLPORTION 0.3

struct passwd *pw;

int c_pass = 0; /* custom_password flag */

int passwordok(const char *s) {

  if ( c_pass == 1 ) {
  return strcmp(s+1, pw->pw_passwd); /* skip first character to work --tetris11 */
  }

#if 0
  char key[3];
  char *encr;
  
  key[0] = *(pw->pw_passwd);
  key[1] =  (pw->pw_passwd)[1];
  key[2] =  0;
  encr = crypt(s, key);
  return !strcmp(encr, pw->pw_passwd);
#else
  /* simpler, and should work with crypt() algorithms using longer
 salt strings (like the md5-based one on freebsd).  --marekm */
  return !strcmp(crypt(s, pw->pw_passwd), pw->pw_passwd);
#endif
}

int main(int argc, char **argv){
  XEvent ev;
  KeySym ks;
  char cbuf[10], rbuf[128]; /* shadow appears to suggest 127 a good value here */
  int clen, rlen=0;
  long goodwill= INITIALGOODWILL, timeout= 0;
  XSetWindowAttributes attrib;
  Cursor cursor;
  Pixmap csr_source,csr_mask;
  XColor csr_fg, csr_bg, dummy, black;
  int ret, screen, blank = 0;
  char *custom_passwd = 0;

#define USAGE_EXIT \
 fprintf(stderr,"xtrlock (version %s); usage: xtrlock [-b] [-p]\n", program_version); \
 exit(1);

#define CUSTOM_PROMPT "custom passphrase: "

#ifdef SHADOW_PWD
  struct spwd *sp;
#endif
  struct timeval tv;
  int tvt, gs;

  if (argc == 2){
if (strcmp(argv[1], "-b") == 0 ) {
  blank = 1;
}
else if (strcmp(argv[1],"-p") == 0 ) {
  c_pass = 1;
  custom_passwd = getpass(CUSTOM_PROMPT);
}
else {USAGE_EXIT}
  }
  else if (argc == 3) {
if (\
 (strcmp(argv[1], "-b") == 0 ) && (strcmp(argv[2], "-p") == 0) || \
 (strcmp(argv[1], "-p") == 0 ) && (strcmp(argv[2], "-b") == 0)\
) {
  blank = c_pass = 1;
  custom_passwd = getpass(CUSTOM_PROMPT);
}
else {USAGE_EXIT}
  }
  else if (argc > 1) {USAGE_EXIT}



  errno=0;  pw= getpwuid(getuid());

  if (c_pass == 1) {
  /* custom password bypasses gid uid checks, but still requires
 a valid pw struct --tetris11 */
pw->pw_passwd = custom_passwd;
  }
  else {
if (!pw) { perror("password entry for uid not found"); exit(1); }
#ifdef SHADOW_PWD
  sp = getspnam(pw->pw_name);
  if (sp)
pw->pw_passwd = sp->sp_pwdp;
  endspent();
#endif

  /* logically, if we need to do the following then the same 
 applies to being installed setgid shadow.  
 we do this first, because of a bug in linux. --jdamery */ 
  if (setgid(getgid())) { perror("setgid"); exit(1); }
  /* we can be installed setuid root to support shadow passwords,
 and we don't need root privileges any longer.  --marekm */
  if (setuid(getuid())) { perror("setuid"); exit(1); }

  if (strlen(pw->pw_passwd) < 13) {
fputs("password entry has no pwd\n",stderr); exit(1);
  }
  }
  
  display= XOpenDisplay(0);

  if (display==NULL) {
fprintf(stderr,"xtrlock (version %s): cannot open display\n",
	program_version);
exit(1);
  }
  
  attrib.override_redirect= True;

  if (blank) {
screen = DefaultScreen(display);
attrib.background_pixel = BlackPixel(display, screen);
window= XCreateWindow(display,DefaultRootWindow(display),
  0,0,DisplayWidth(display, screen),DisplayHeight(display, screen),
  0,DefaultDepth(display, screen), CopyFromParent, DefaultVisual(display, screen),
  CWOverrideRedirect|CWBackPixel,); 
XAllocNamedColor(display, DefaultColormap(display, screen), "black", , );
  } else {
window= 

Bug#615459: i47 youth shared the list “مراكز تسوق” with you, on Wunderlist

[i47 youth]

i47 youth shared the list https://t.wunderlist.com/z/MzLkxAQytY83uDXsNjOdNbk1MuzfNxazmzQAAHNoYXLtLxMyMjY2kzkv5B6fMuUDEDI1MAfkMjMBlDXlMzMUyuY3G34UNIiYNzc3ABiRNwk1AHNoYXJpbmctbGlzdC1tZW2-cnNoaXAtY3LqdO0tBDI0AGJ1dHRvbl9saW5r;
 style="color: rgb(43, 136, 217); text-decoration: underline;">“مراكز تسوق” 
with you, using Wunderlist.


Join List: 
https://t.wunderlist.com/z/MzLkxAQytY83uDXsNjOdNbk1MuzfNxazmzQAAHNoYXLtLxMyMjY2kzkv5B6fMuUDEDI1MAfkMjMBlDXlMzMUyuY3G34UNIiYNzc3ABiRNwk1AHNoYXJpbmctbGlzdC1tZW2-cnNoaXAtY3LqdO0tBDI0AGJ1dHRvbl9saW5r

--
Copyright 2015 Wunderlist

Bug#806505: libqt4-network: failed looksup on SSLv3_*_method

[Lisandro Damián Nicanor Pérez Meyer]

tag 806505 moreinfo
thanks

On Saturday 28 November 2015 01:03:39 Jon wrote:
> Dear Maintainer,
> 
> libqt4-network is trying to look up SSLv3_*_method functions in OpenSSL
> which recently got removed. I don't know how to tag this as transition
> related.
> 
> QSslSocket: cannot resolve SSLv3_client_method
> QSslSocket: cannot resolve SSLv3_server_method

Hi Jon!

The patch looks fine but I can't accept it without knowing who wrote it and 
it's license.

-- 
http://www.tiraecol.net/modules/comic/comic.php?content_id=162

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#806735: transition: glibc

[Aurelien Jarno]

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

Dear release team,

We would like to get a transition slot for glibc 2.21. It is currently
available in experimental and has been built successfully on all release
architectures. We have fixed the hppa and mips64el build failure in the,
SVN, so the next upload should really build everywhere.

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

Here is the corresponding ben file:

title = "glibc";
is_affected = .depends ~ /libc[0-9.]* \(<

Bug#783989: python-lockfile should be DPMT maintained

[Barry Warsaw]

On Nov 28, 2015, at 05:37 PM, Ben Finney wrote:

>Okay, I've been struggling mightily with Git. Both in the “working
>together” sense, and in the “fighting against” sense. Can you help?

I'm certainly willing to try!

>I'm quite loath to lose the simplicity of a Debian packaging
>repository. There is a deliberate layer of separation that has served
>very well in the VCS to date for this package: the separation of VCS
>repos matches the separation of concerns. Debian's packaging is of
>necessity applied on top of whatever upstream does with their source.
>
>In order to have the history of packaging work retroactively include
>upstream's sources – in order for every past revision in the VCS be
>accompanied in the VCS by whatever upstream source is referenced by
>that packaging work – I assume we need to import and merge the
>upstream sources at each of those states, from the upstream tarballs.

This is essentially what Stephano's scripts do for the DPMT conversion from
svn to git.  They are smart about interweaving the svn, upload, and upstream
history into a coherent git DAG.   It even worked most of the time. :)
Unfortunately, I don't know if it's even feasible to port to bzr, but that
would be one place to start if you want to preserve full history.

git://git.debian.org/users/stefanor/dpmt-migration.git

An alternative is to preserve only upload history, and this is the path I
originally went down before switching to Stephano's scripts.  It uses debsnap
to grab the upload history and attempts to weave that into a coherent DAG.  It
throws away the original vcs history, which I was okay with because the old
vcs history wasn't going away.  I've used this to convert a few packages I
cared about, but I haven't tried it in a while, so YMMV.

git://git.debian.org/users/barry/import-dscs.git

>I've attached a document that shows the sequence of commands I
>recorded as a recipe for what I've achieved so far.

Yep, sorry, my git-fu isn't adept enough to be able to solve the problem at
the bottom of the doc.  Maybe studying Stephano's scripts will provide some
insight.  If not, then the git and/or debian-devel mailing lists would be the
place to go.

TBH, if it were me, I'd probably take one of the simpler approaches and not
worry about preserving all the vcs history from Bazaar.


pgpZSB5QfVn28.pgp
Description: OpenPGP digital signature

Bug#806736: util-linux: package description tweaks

[Justin B Rye]

Source: util-linux
Version: 2.27.1-1
Severity: wishlist
Tags: patch

This source package's package descriptions have a number of minor
English language problems, most of which are trivial enough that I
wouldn't normally bother with them, but the high Priority levels on
the packages bump the bug up to wishlist.

Commented version of the attached patch:

>  Package: util-linux
[...]
> -Description: Miscellaneous system utilities
> +Description: miscellaneous system utilities

These descriptions are inconsistent in their capitalisation; the
Debian Developer's Reference prefers lowercase.

>   This package contains a number of important utilities, most of which
> - are oriented towards maintenance of your system.  Some of the more
> + are oriented towards maintenance of your system. Some of the more
>   important utilities included in this package allow you to partition
>   your hard disk, view kernel messages, and create new filesystems.

Another trivial inconsistency, which I'm fixing it in the direction of
single-spacing.  It's not what I use in my own writing, but it's the
standard usually recommended on debian-l10n-english - reformatters
squeeze whitespace anyway.
  
>  Package: util-linux-locales
[...]
> -Description: Locales files for util-linux
> +Description: locales files for util-linux

DDR-compliance.

> - This package contains the internationalization files of for the util-linux
> + This package contains the internationalization files for the util-linux
>   package.

Grammar error - delete the extra word.

[...]
>  Package: mount
[...]
> -Description: Tools for mounting and manipulating filesystems
> +Description: tools for mounting and manipulating filesystems

DDR compliance.

[...]
>  Package: bsdutils
[...]
>  Package: fdisk-udeb
[...]

There's nothing wrong with these.

>  Package: libblkid1
[...]
> -Description: block device id library
> +Description: block device ID library

An "id" goes with an ego and superego; you want the quasi-initialism
"ID".

> - The blkid library which allows system programs like fsck and
> - mount to quickly and easily find block devices by filesystem UUID and
> - LABEL.  This allows system administrators to avoid specifying
> - filesystems by hard-coded device names, but via a logical naming
> - system instead.
> + The blkid library allows system programs such as fsck and mount to
> + quickly and easily find block devices by filesystem UUID or label.
> + This allows system administrators to avoid specifying filesystems by
> + hard-coded device names and use a logical naming system instead.

Recurring issues:
 * Singlespace sentences (fixed accidentally).
 * The long description should be made up of sentences.

One-offs:
 * "Like" can be slightly ambiguous; you don't mean a set of programs
   that resemble fsck, you mean a set of programs that includes fsck.
 * "UUID" is an initialism, but "label" is just a word.
 * Grammar error - you can't use "but" like that.

>  Package: libblkid1-udeb
[...]
>  Package: libblkid-dev
[...]

Use the same fixed boilerplate as above.
  
>  Package: libfdisk1
[...]
> - The libfdisk library is used for manipulating with partition tables.
> - The library is the core of the fdisk, cfdisk and sfdisk tools.
> + The libfdisk library is used for manipulating partition tables. It is
> + the core of the fdisk, cfdisk, and sfdisk tools.

"Manipulating with" is a grammar error ("manipulate" is transitive),
and then starting the second sentence with "the library" is just
repetitive.  (I suspect at one stage the first sentence started with
plain "libfdisk".)

I've also standardised in the direction of serial comma.

>  Package: libfdisk1-udeb
[...]
>  Package: libfdisk-dev
[...]

Use the same fixed boilerplate as above.

>  Package: libmount1
[...]
> - The device mounting library, used by mount and umount helpers.
> + This device mounting library is used by mount and umount helpers.

The long description should be made up of sentences.

>  Package: libmount-dev
[...]

Use the same fixed boilerplate as above.

>  Package: libsmartcols1
[...]
>  Description: smart column output alignment library
> - The smart column output alignment library, used by fdisk utilities.
> + This smart column output alignment library is used by fdisk utilities.

The long description should be made up of sentences.

>  Package: libsmartcols1-udeb
[...]
>  Package: libsmartcols-dev
[...]

Use the same fixed boilerplate as above.

>  Package: libuuid1
[...]
> - The libuuid library generates and parses 128-bit universally unique
> - ids (UUIDs).  A UUID is an identifier that is unique across both
> - space and time, with respect to the space of all UUIDs.  A UUID can
> - be used for multiple purposes, from tagging objects with an extremely
> - short lifetime, to reliably identifying very persistent objects
> - across a network.
> + The libuuid library generates and parses 128-bit Universally Unique
> + IDs (UUIDs). A UUID is an identifier that is unique within the space
> 

Bug#806082: multipath-tools: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Ritesh Raj Sarraf]

Control: tag -1 +confirmed pending

On Tue, 2015-11-24 at 15:27 +, Santiago Vila wrote:
> 
> dh_testroot
> dh_prep
> dh_installdirs
> mkdir -p /<>/multipath-tools-
> 0.5.0+git1.656f8865/debian/tmp/sbin
> /usr/bin/make install INSTALL_PROGRAM=install -s
> DESTDIR=/<>/multipath-tools-0.5.0+git1.656f8865/debian/tmp
> LIB=/lib SYSTEMDPATH=/lib USE_SYSTEMD=1
> install: cannot stat 'libmultipath.so.0': No such file or directory
> Makefile:62: recipe for target 'install' failed
> make[2]: *** [install] Error 1
> Makefile:52: recipe for target 'recurse_install' failed
> make[1]: *** [recurse_install] Error 2
> debian/rules:67: recipe for target 'install' failed
> make: *** [install] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave
> error exit status 2
> ---
> -


H Most of multipath-tools package is architecture dependent
code. I wonder who added that in the indep section.

There is one exception though, multipath-tools-boot package, which is a
small package with just config files...

Does the following change look good to you? With this change, the build
succeeds.

commit ac05992e22b9eb828de5c68e01cade95ff95a76d
Author: Ritesh Raj Sarraf 
Date:   Mon Nov 30 20:23:51 2015 +0530

Fix build for arch independent targets

Closes: #806082

diff --git a/debian/rules b/debian/rules
index b798c11..395a0e4 100755
--- a/debian/rules
+++ b/debian/rules
@@ -27,7 +27,7 @@ include /usr/share/dpkg/buildflags.mk
 build: build-arch build-indep
 
 build-arch: build-multipath-udeb-stamp build-stamp
-build-indep: build-stamp
+build-indep: build-multipath-udeb-stamp
 
 build-stamp:
dh_testdir




If this fixes your issues, please just drop a note. I won't upload immediately, 
but knowing that the fix is fine, helps.

-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



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

Bug#796588: Bug796588#: adjtimex: Has init script in runlevel S but no matching service file

[Roger Shimizu]

Dear Felipe,

Thanks for your feedback!

> Note that this is not the only place that this description appears. It
> also shows in the output of "systemctl status adjtimex.service", or
> "systemctl list-units". This should really be a full descriptive
> sentence. Maybe, "Adjust kernel time variables".

I think you might misunderstand me.
The description you proposed would generate the following log:
[DATE TIME] [HOSTNAME] systemd[1]: Starting set the kernel time variables...
[DATE TIME] [HOSTNAME] systemd[1]: Started set the kernel time variables.
or
[DATE TIME] [HOSTNAME] systemd[1]: Starting Adjust kernel time variables...
[DATE TIME] [HOSTNAME] systemd[1]: Started Adjust kernel time variables.

What I proposed was:
[DATE TIME] [HOSTNAME] systemd[1]: Starting the kernel time
variables setting...
[DATE TIME] [HOSTNAME] systemd[1]: Started the kernel time
variables setting.

IMHO, it looks more natural.

Yes, I found other existing systemd service also use the way you
propose, like "systemd-tmpfiles-setup.service":

Nov 30 23:43:32 sid systemd[1]: Starting Create Volatile Files and
Directories...
Nov 30 23:43:32 sid systemd[1]: Started Create Volatile Files and
Directories.

I consider it's minor bug to say "starting verb" or "started verb",
which is better to fix in the future.

>> Environment="TICK=1 FREQ=0"
> I don't think this works. There should be no quotes there, or systemd
> might treat TICK variable as containing "1 FREQ=0".

Thanks for pointing this out.
Yes, it's totally not working.
I confirmed by commenting out "EnvironmentFile" line, and found
"ExecStart" command failed because of no FREQ is set.

changing from
Environment="TICK=1 FREQ=0"
to
Environment="TICK=10005" "FREQ=0"
will fix it.

>> EnvironmentFile=-/etc/default/adjtimex
>> ExecStart=/sbin/adjtimex -tick "$TICK" -frequency "$FREQ"
>
> I think the quotes are superfluous. If you want to preserve quoting,
> systemd does it by using ${TICK} and ${FREQ} syntax.

It seems fine as it was. However, following spec is always a good
thing, so I changed to what you proposed:
ExecStart=/sbin/adjtimex -tick ${TICK} -frequency ${FREQ}

Thanks again for your review!

Cheers,
Roger


adjtimex.service
Description: Binary data

Bug#806494: [pkg-gnupg-maint] Bug#806494: gnupg: please make the build reproducible

[Werner Koch]

On Mon, 30 Nov 2015 12:06, la...@debian.org said:

> than repeat it here? ie.
> 

Thanks.

> Ah, okay. Retro, but makes sense.

[ yat2m shall be able to run on all platforms and thus it need to
  restrict itself to a common subset.  For example VMS and many toolkits
  for embedded platforms do not provide C99.  It is easy enough to keep
  yat2m at this langugae level. ]

>>   75eb071 yat2m: New option --date.
>
> Great :)

will be in 2.1.10 hopefully this week.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

Bug#615459: i47 youth shared the list “أفلام للمشاهدة” with you, on Wunderlist

[i47 youth]

i47 youth shared the list https://t.wunderlist.com/z/tJSkNDPgNzWbNjMewjTKgrir9H_2NwemAABzaGFy7S8TMjI2NRYxLzeHEK3ZMtPPM5vpjt4z5BHMkRYzEjMyOX4UNIiYBjAAGJE3CTUAc2hhcmluZy1saXN0LW1lbb5yc2hpcC1jcup07S0EMjQAYnV0dG9uX2xpbms;
 style="color: rgb(43, 136, 217); text-decoration: underline;">“أفلام 
للمشاهدة” with you, using Wunderlist.


Join List: 
https://t.wunderlist.com/z/tJSkNDPgNzWbNjMewjTKgrir9H_2NwemAABzaGFy7S8TMjI2NRYxLzeHEK3ZMtPPM5vpjt4z5BHMkRYzEjMyOX4UNIiYBjAAGJE3CTUAc2hhcmluZy1saXN0LW1lbb5yc2hpcC1jcup07S0EMjQAYnV0dG9uX2xpbms

--
Copyright 2015 Wunderlist

Bug#806737: xsp: [INTL:ru] Russian debconf templates translation update

[Yuri Kozlov]

Package: xsp
Version: 4.2-1
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

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

Russian debconf templates translation update is attached.

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

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


ru.po.gz
Description: application/gzip

Bug#806505: libqt4-network: failed looksup on SSLv3_*_method

[Jon DeVree]

On Mon, Nov 30, 2015 at 12:52:30 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> tag 806505 moreinfo
> thanks
> 
> On Saturday 28 November 2015 01:03:39 Jon wrote:
> > Dear Maintainer,
> > 
> > libqt4-network is trying to look up SSLv3_*_method functions in OpenSSL
> > which recently got removed. I don't know how to tag this as transition
> > related.
> > 
> > QSslSocket: cannot resolve SSLv3_client_method
> > QSslSocket: cannot resolve SSLv3_server_method
> 
> Hi Jon!
> 
> The patch looks fine but I can't accept it without knowing who wrote it and 
> it's license.
> 

I wrote it and I guess its under the same license QT is. (yes im aware
QT is triple licensed and one of them is a commercial use license)

-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).

Bug#720707: [Pkg-zsh-devel] state of RFP: grml-zsh-config?

[Daniel Shahaf]

Axel Beckert wrote on Mon, Nov 30, 2015 at 02:52:17 +0100:
> Frank Terbeck wrote:
> > Disclaimer: Even though I am involved with grml's setup a great deal, I
> > never was a big fan of packaging it up for Debian. The reason for
> > that being mainly, that I am absolutely convinced that a vendor
> > should impose the least possible changes to a package as possible
> > and most certainly not impose a bunch of settings for every user on
> > a system.
> 
> That decision has not to be made by the vendor (i.e. us; neither in
> the one nor in the other direction) but solely by the local admin. And
> the vendor should IMHO help the local admin to implement that
> decision, i.e. the package should ask the local admin (via debconf) if
> the configuration should be globally enabled or not.

Another option is to ask the individual user, via zsh-newuser-install.

I.e., zsh-newuser-install could grow an additional option
'(V) Vendor-specific features' in the toplevel menu, which would allow
the user to enable/disable packages' add-on features.

I guess that means establishing a zsh-newuser-install-vendor.d/
somewhere for packages to drop their zsh-newuser-install modules into.

Bug#806705: quantlib: fails to build on some arm64 buildds

[Dirk Eddelbuettel]

On 30 November 2015 at 14:50, Edmund Grimley Evans wrote:
| > Should we even consider not building at all?
| 
| I think you should build it on arm64, where it could easily be useful.
| 
| I'm not so sure about people using quantlib on armel systems, which
| are typically very low-performance, but, seeing as it builds there
| (without the tests), I don't see a reason to specially remove it.

Yes we have a proud history of wasting cpu cycles and disk space for
installations and packages nobody ever uses ... but there is merit in running
the builds.

I turned on a -2 a while back, a fix should be forthcoming in a bit.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Bug#806732: [Pkg-sass-devel] Bug#806732: [PATCH] libsass: change needed for version 3.3.x

[Jonas Smedegaard]

Quoting Frederic Bonnard (2015-11-30 16:07:36)
> libsass can be updated to the new version 3.3.2.
> In the process of packaging libsass-python :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804697
> I had to upgrade libsass to libsass 3.3.x and noticed I had to do a few
> changes to the debian/ packaging of version 3.2.5.
> So here is a patch to apply on top of 3.2.5 packaging for 3.3.x upgrade.

Sounds good.  Looks like you forgot to include the patch, though.

 - 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#806732: [Pkg-sass-devel] Bug#806732: [PATCH] libsass: change needed for version 3.3.x

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2015-11-30 18:24:30)
> Quoting Frederic Bonnard (2015-11-30 16:07:36)
>> libsass can be updated to the new version 3.3.2.
>> In the process of packaging libsass-python :
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804697
>> I had to upgrade libsass to libsass 3.3.x and noticed I had to do a 
>> few changes to the debian/ packaging of version 3.2.5.
>> So here is a patch to apply on top of 3.2.5 packaging for 3.3.x 
>> upgrade.
>
> Currently no other packages in Debian(!) link to libsass, so there is 
> no need for adding v5 suffix - if only you wait a bit releasing the 
> Python wrapper until I have released a newer package built with GCC 5.

Whereas this bug (change needed for version 3.3.x) is closed as a 
non-bug, I did not succeed updating to 3.3.x yet (upstream build system 
changed and fails with current packaging routines).

Help figuring out the changes needed is much appreciated.  I will be 
travelling in India the next two months - will still be active and will 
try solve this upgrade issue, but possibly slow to respond - just to 
warn ahead...


 - 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#665334: [Pkg-fonts-devel] Bug#665334: Adobe font hinting

[Read Roberts]

The autohint code is now all open source, within the github depot at:

https://github.com/adobe-type-tools/afdko


- Read

On 11/24/15, 3:05 PM, "Daniel Kahn Gillmor"  wrote:

>On Tue 2015-06-23 20:14:51 -0400, Michael Gardner wrote:
>> What's the status of the autohint relicensing?
>>
>> On Sun, Apr 13, 2014 at 6:29 PM, Read Roberts 
>>wrote:
>>> I am working on this now, and the major legal hurdles have been
>>>cleared.
>>> It may still be several months for all the paperwork to get done, but I
>>> will have finished the development work within a week or two.
>>>Definitely
>>> happening by August.
>
>Any word on this, Read?
>
>--dkg

Bug#806744: TEST_P fails with new G++ because of Property_CopyBaseTypeConstructor_Test::gtest_registering_dummy_' defined but not used

[Marco Trevisan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: libgtest-dev
Version: 1.7.0-4

This is the warning (which might be fatal when treating them as
errors) we get when compiling tests using TEST_P with new gcc:

'{anonymous}::Property_CopyBaseTypeConstructor_Test::gtest_registering_d
ummy_'
defined but not used [-Werror=unused-variable]
 TEST_P(/*TestDesktopApplicationSubject*/Property,
CopyBaseTypeConstructor)

Attached a fix for this
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iF4EAREIAAYFAlZcmKgACgkQy6VOJFdF1OpSMAD9EdtTeUhf+QBTrl4clksW4epm
+g0KnTsCMlnz6sNt0p8A/RdOaQbyV9Szp/OmADLHAHksUZ8+aQXa8FusAAqeH/h/
=6X6n
-END PGP SIGNATURE-
diff -Nru gtest-1.7.0/debian/changelog gtest-1.7.0/debian/changelog
--- gtest-1.7.0/debian/changelog2015-06-24 05:31:45.0 +0200
+++ gtest-1.7.0/debian/changelog2015-11-30 19:28:14.0 +0100
@@ -1,3 +1,11 @@
+gtest (1.7.0-5) unstable; urgency=medium
+
+  * patches/test-case-p-unused-dummy-variable-fix.patch:
+-  Add GTEST_ATTRIBUTE_UNUSED_ to the dummy variable generated
+   in INSTANTIATE_TEST_CASE_P (LP: #1521177).
+
+ -- Marco Trevisan (Treviño)   Mon, 30 Nov 2015 13:44:53 
+0100
+
 gtest (1.7.0-4) unstable; urgency=medium
 
   * patches/gtest-freebsd-death-test.patch: New.  Enable death tests for
diff -Nru gtest-1.7.0/debian/patches/series gtest-1.7.0/debian/patches/series
--- gtest-1.7.0/debian/patches/series   2015-06-24 05:31:45.0 +0200
+++ gtest-1.7.0/debian/patches/series   2015-11-30 13:31:11.0 +0100
@@ -1,3 +1,4 @@
 death-test-test.patch
 makefile-example.patch
 gtest-freebsd-death-test.patch
+test-case-p-unused-dummy-variable-fix.patch
diff -Nru 
gtest-1.7.0/debian/patches/test-case-p-unused-dummy-variable-fix.patch 
gtest-1.7.0/debian/patches/test-case-p-unused-dummy-variable-fix.patch
--- gtest-1.7.0/debian/patches/test-case-p-unused-dummy-variable-fix.patch  
1970-01-01 01:00:00.0 +0100
+++ gtest-1.7.0/debian/patches/test-case-p-unused-dummy-variable-fix.patch  
2015-11-30 15:56:02.0 +0100
@@ -0,0 +1,34 @@
+Description: Add GTEST_ATTRIBUTE_UNUSED_ to the dummy variable generated
+  in INSTANTIATE_TEST_CASE_P.
+
+Origin: 
https://github.com/google/googletest/commit/683886c5676dca2e8198bbf5f735f79387d10fc6
+Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtest/+bug/1521177
+Applied-Upstream: commit:683886c5676dca2e8198bbf5f735f79387d10fc6
+Author: kosak 
+
+diff --git a/include/gtest/gtest-param-test.h 
b/include/gtest/gtest-param-test.h
+index adcc49b..0b61629 100644
+--- a/include/gtest/gtest-param-test.h
 b/include/gtest/gtest-param-test.h
+@@ -1394,7 +1394,7 @@ internal::CartesianProductHolder10()); \
+   return 0; \
+ } \
+-static int gtest_registering_dummy_; \
++static int gtest_registering_dummy_ GTEST_ATTRIBUTE_UNUSED_; \
+ GTEST_DISALLOW_COPY_AND_ASSIGN_(\
+ GTEST_TEST_CLASS_NAME_(test_case_name, test_name)); \
+   }; \
+diff --git a/include/gtest/gtest-param-test.h.pump 
b/include/gtest/gtest-param-test.h.pump
+index 55ddd2d..8033f49 100644
+--- a/include/gtest/gtest-param-test.h.pump
 b/include/gtest/gtest-param-test.h.pump
+@@ -460,7 +460,7 @@ internal::CartesianProductHolder$i<$for j, 
[[Generator$j]]> Combine(
+   GTEST_TEST_CLASS_NAME_(test_case_name, test_name)>()); \
+   return 0; \
+ } \
+-static int gtest_registering_dummy_; \
++static int gtest_registering_dummy_ GTEST_ATTRIBUTE_UNUSED_; \
+ GTEST_DISALLOW_COPY_AND_ASSIGN_(\
+ GTEST_TEST_CLASS_NAME_(test_case_name, test_name)); \
+   }; \


gtest_1.7.0-5.dsc.debdiff.sig
Description: PGP signature

Bug#806419: obnam: creates checkpoints too often

[Lars Wirzenius]

On Fri, Nov 27, 2015 at 12:04:58PM +0100, Ansgar Burchardt wrote:
> Would it make sense for obnam to default to a larger checksum size for a
> backup where both sides are local (as in not using sftp explicitly)?

It'd be possible, but I tend to prefer the simplicity of having
defaults not depend on heuristics like that. Note that "local
repository" may in fact be remote, over NFS or sshfs or similar.

-- 
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh


signature.asc
Description: Digital signature

Bug#806745: gegl --list-all crashes

[Marc J. Driftmeyer]

Package: gegl
Version: 0.3.4-1
Severity: normal

Dear Maintainer,

Sorry for not tagging on the prior gegl bug I posted, but this is the output to 
console I get just doing a simple gegl --list-all.

gegl --list-all

(process:26355): GLib-CRITICAL **: g_hash_table_remove_all: assertion 
'hash_table != NULL' failed

(process:26355): GLib-CRITICAL **: g_hash_table_iter_init: assertion 
'hash_table != NULL' failed

(process:26355): GLib-CRITICAL **: g_hash_table_iter_next: assertion 
'ri->version == ri->hash_table->version' failed

(process:26355): GLib-CRITICAL **: g_hash_table_lookup: assertion 'hash_table 
!= NULL' failed

I'm betting if GEGL crashes Gimp just becomes a zombie process and waits 
indefinitely, instead of crashing with any log support written for bug 
detection.

I downgraded to Glib in Sid and still got the same thing. I have not rebuilt 
gegl from trunk but have built GIMP 2.9.2 bz copy from Gimp.org and it produces 
the same result: a zombie process.

I'm betting if I rebuild GEGL from trunk it will work. If that's the case, your 
build of GEGL needs investigating.

Sincerely,

Marc J. Driftmeyer


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

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

Versions of packages gegl depends on:
ii  libbabl-0.1-0  0.1.14-1
ii  libc6  2.21-0experimental4
ii  libgegl-0.3-0  0.3.4-1
ii  libglib2.0-0   2.47.3-3
ii  libspiro0  1:0.5.20150702-2

gegl recommends no packages.

gegl suggests no packages.

-- no debconf information

Bug#806746: lxc: problem with locale in lxc-create

[Will Gnann]

Package: lxc
Version: 1:1.0.8-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
LANG="pt_BR.UTF-8" lxc-create -n test -t debian
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
Lots of:
perl: warning: Please check that your locale settings:
LANGUAGE = "pt_BR:pt",
LC_ALL = (unset),
LANG = "pt_BR.UTF-8"
are supported and installed on your system.

   * What outcome did you expect instead?
No warnings.

Extra:
lxc-create, in particular, /usr/share/lxc/templates/lxc-debian should 
generate locale based on $LANG before execute perl scripts or set LANG=C inside 
chroot.

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


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

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

Versions of packages lxc depends on:
ii  init-system-helpers  1.24
ii  libapparmor1 2.10-2+b1
ii  libc62.19-22
ii  libcap2  1:2.24-12
ii  liblxc1  1:1.0.8-1
ii  libseccomp2  2.2.3-2
ii  libselinux1  2.4-3
ii  python3  3.4.3-7

Versions of packages lxc recommends:
ii  cgmanager0.39-2
ii  debootstrap  1.0.75
ii  openssl  1.0.2d-3
ii  rsync3.1.1-3

Versions of packages lxc suggests:
pn  lua5.2  

-- debconf information:
  lxc/auto: true
* lxc/directory: /var/lib/lxc
  lxc/title:
  lxc/shutdown: /usr/bin/lxc-halt

Bug#806505: libqt4-network: failed looksup on SSLv3_*_method

[Jon DeVree]

On Mon, Nov 30, 2015 at 15:19:06 -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
> On Monday 30 November 2015 15:07:00 Lisandro Damián Nicanor Pérez Meyer wrote:
> [snip]
> > I also don't know if it would be preferable or not to make an assertion in
> > case sslv3 support is not present, so apps deliberately using it will
> > fail with a message.
> 
> I have just checked the code and it doesn't seems to be necessary.
> 
> 

I pretty much just cloned what was done for SSLv2. In fact, I just
thought to check qt5 and the patch that was applied there for SSLv3 is
functionally identical to what I wrote for qt4.

-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).

Bug#806426: Some TLS certificates not suppoprted

[Aleś Bułojčyk]

Hi Andres.

On 30 November 2015 at 20:31, Andreas Metzler  wrote:

> I am stumped, could you plese post the output of
> gnutls-cli -V -d 4711 freedns.afraid.org
>
>
 $ gnutls-cli --version
gnutls-cli 3.3.8
...


$ gnutls-cli -V -d 4711 freedns.afraid.org
Processed 173 CA certificate(s).
Resolving 'freedns.afraid.org'...
Connecting to '50.23.197.94:443'...
|<5>| REC[0x239b450]: Allocating epoch #0
|<3>| ASSERT: gnutls_constate.c:586
|<5>| REC[0x239b450]: Allocating epoch #1
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256
(C0.2B)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384
(C0.2C)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_ECDSA_CAMELLIA_128_GCM_SHA256 (C0.86)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_ECDSA_CAMELLIA_256_GCM_SHA384 (C0.87)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
(C0.09)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256
(C0.23)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
(C0.0A)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384
(C0.24)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_ECDSA_CAMELLIA_128_CBC_SHA256 (C0.72)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_ECDSA_CAMELLIA_256_CBC_SHA384 (C0.73)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
(C0.08)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_ECDSA_ARCFOUR_128_SHA1
(C0.07)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256
(C0.2F)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384
(C0.30)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_RSA_CAMELLIA_128_GCM_SHA256 (C0.8A)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_RSA_CAMELLIA_256_GCM_SHA384 (C0.8B)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1
(C0.13)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256
(C0.27)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1
(C0.14)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA384
(C0.28)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_RSA_CAMELLIA_128_CBC_SHA256 (C0.76)
|<4>| HSK[0x239b450]: Keeping ciphersuite:
ECDHE_RSA_CAMELLIA_256_CBC_SHA384 (C0.77)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1
(C0.12)
|<4>| HSK[0x239b450]: Keeping ciphersuite: ECDHE_RSA_ARCFOUR_128_SHA1
(C0.11)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_AES_256_GCM_SHA384 (00.9D)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_CAMELLIA_128_GCM_SHA256
(C0.7A)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_CAMELLIA_256_GCM_SHA384
(C0.7B)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA256 (
00.BA)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA256
(00.C0)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_ARCFOUR_128_SHA1 (00.05)
|<4>| HSK[0x239b450]: Keeping ciphersuite: RSA_ARCFOUR_128_MD5 (00.04)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256
(00.9E)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_AES_256_GCM_SHA384
(00.9F)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_GCM_SHA256
(C0.7C)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_GCM_SHA384
(C0.7D)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
(00.67)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
(00.6B)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
(00.45)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA256 (
00.BE)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
(00.88)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA256
(00.C4)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256
(00.A2)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_DSS_AES_256_GCM_SHA384
(00.A3)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_GCM_SHA256
(C0.80)
|<4>| HSK[0x239b450]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_GCM_SHA384
(C0.81)
|<4>| HSK[0x239b450]: Keeping ciphersuite: 

Bug#798280: transition: mono

[Emilio Pozuelo Monfort]

On 27/11/15 17:54, Jo Shields wrote:
> On Wed, 30 Sep 2015 01:03:23 +0200 Emilio Pozuelo Monfort  
> wrote:
>> On 07/09/15 18:28, Jo Shields wrote:
>> > Package: release.debian.org
>> > Severity: normal
>> > User: release.debian@packages.debian.org
>> > Usertags: transition
>> >
>> > Mono requires a (hopefully minor) transition, when the pending version in
>> > Experimental uploads to Unstable. The ABI on the core library was bumped 
>> > back
>> > with Mono 3.0.6+dfsg2-1 in 2012 and the old one deprecated - now the old
>> > version has been removed too.
>> >
>> > More than half the existing archive packages are already post-transition 
>> > (any
>> > that were built with Mono 3.0.6+dfsg2-1 or later, in theory).
>> >
>> > The pending upload is important because it fixes GCC5 FTBFS, and compiler
>> > reproducible output support.
>> >
>> > I am aware of the PowerPC build failure on the package in Experimental, I
>> > wouldn't look to do the upload before that is fixed (but would like to get 
>> > the
>> > Ben tracker in place so I can track both issues in parallel). The PPC build
>> > failures are Debian buildd/porterbox-specific - they don't reproduce 
>> > locally,
>> > which makes it very awkward to repro/fix.
>>
>> OK, please ping us when you're ready for an upload.
> 
> I think this is close to startable, if a transition slot will be available 
> soon.
> 
> Of the 17 "bad" packages on the release tracker, 2 FTBFS for other reasons 
> (and
> are removed from Testing anyway). 3 are in DELAYED and should land this 
> weekend.
> 2 are waiting on another DELAYED upload to land this weekend, which should 
> make
> them RMable. 1 is in binary NEW, 2 are blocking on a package in NEW. The rest
> already have RM bugs against ftp.debian.org.

Can you make those bugs block this?

> In terms of *actual* work remaining, fsharp needs a new upstream release
> uploading (which is only awkward due to the need to +dfsg it), and xsp needs
> some upstream work to tag/ship a compatible version (i.e. remove the attempt 
> to
> build the old ABI entirely), both of which I can deal with on Monday.

Good.

> The only slight wrinkle in the transition is the removal of powerpc as an
> architecture, requiring some massaging of the archive before transitioning 
> would
> be possible.

It'd be good to get that done before the transition starts. Can you ask the ftp
team to do that?

Cheers,
Emilio

Bug#806651: /etc/cron.daily/apt-cacher-ng exited with return code 255

[Eduard Bloch]

Control: severity 806651 minor

Hallo,
* Peter Colberg [Mon, Nov 30 2015, 01:26:55AM]:
> On Sun, Nov 29, 2015 at 10:39:21PM +0100, Eduard Bloch wrote:
> > Is the apt-cacher-ng daemon running?
> 
> Yes, the daemon is listening on IPv4, IPv6 and unix sockets.
> 
> However, I noticed that I had altered the configuration from the
> default; ReportPage was commented in /etc/apt-cacher-ng/acng.conf.

Ouch.

> With ReportPage (default):
> 
> # /usr/lib/apt-cacher-ng/acngtool maint -c /etc/apt-cacher-ng 
> SocketPath=/var/run/apt-cacher-ng/socket --verbose
> ..
> Maintenance Task: Expiration

Yeah, right. It uses ReportPage as entry point for maintenance tasks. I
will add better documentation and a better error message.

Regards,
Eduard.

-- 
Erst wenn der letzte Programmierer eingesperrt und die letzte 
Idee patentiert ist, werdet ihr merken, daß Anwälte nicht programmieren können

Bug#806743: figtree: version installed is older than advertised

[Joseph W. Brown]

Package: figtree
Version: 1.4-2
Severity: normal

Dear Maintainer,

The version of `figtree' advertised is 1.4-2, but the installed version is
instead 1.4-1.

Fix: installation should involve the proper version of the package.

Below is a transcript demonstrating the problem.

## search
$ apt-cache show figtree
Package: figtree
Version: 1.4-2
Installed-Size: 1028
Maintainer: Debian Med Packaging Team 
Architecture: all
Depends: default-jre | java5-runtime | java6-runtime | java7-runtime,
jarwrapper (>= 0.5), libfreehep-export-java, libfreehep-graphics2d-java,
libfreehep-graphicsio-emf-java, libfreehep-graphicsio-java, libfreehep-
graphicsio-pdf-java, libfreehep-graphicsio-ps-java, libfreehep-graphicsio-svg-
java, libfreehep-graphicsio-swf-java, libitext5-java, libjam-java,
libjebl2-java
Description-en: graphical phylogenetic tree viewer
 FigTree is designed as a graphical viewer of phylogenetic trees and as
 a program for producing publication-ready figures.  In particular it is
 designed to display summarized and annotated trees produced by BEAST.
Description-md5: e06f51cdb4e8a7021940de0d58824055
Homepage: http://tree.bio.ed.ac.uk/software/figtree/
Section: science
Priority: optional
Filename: pool/main/f/figtree/figtree_1.4-2_all.deb
Size: 929260
MD5sum: 9ee09ac5695356d88bf0b6f6ef22b1a4
SHA1: 95725e2ae1060fa483e73ca591fc48c66319dbb2
SHA256: 81b3fc3cfbbdb701550b9005f5dbc4c26102f84f391a42405909c2ef7d0d1400

## install
$ sudo apt-get install figtree
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  figtree
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/929 kB of archives.
After this operation, 1,053 kB of additional disk space will be used.
Selecting previously unselected package figtree.
(Reading database ... 322762 files and directories currently installed.)
Preparing to unpack .../archives/figtree_1.4-2_all.deb ...
Unpacking figtree (1.4-2) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up figtree (1.4-2) ...

## get version information
$ figtree -help

 FigTree v1.4.1, 2006-2013
  Tree Figure Drawing Tool
   Andrew Rambaut

 Institute of Evolutionary Biology
  University of Edinburgh
 a.ramb...@ed.ac.uk

 http://tree.bio.ed.ac.uk/
 Uses the Java Evolutionary Biology Library (JEBL)
http://jebl.sourceforge.net/
 Thanks to Alexei Drummond, Joseph Heled, Philippe Lemey,
Tulio de Oliveira, Oliver Pybus, Beth Shapiro & Marc Suchard

  Usage: figtree [-graphic ] [-width ] [-height ]
[-help] [] []
-graphic produce a graphic with the given format
-width the width of the graphic in pixels
-height the height of the graphic in pixels
-help option to print this message

  Example: figtree test.tree
  Example: figtree -graphic PDF test.tree test.pdf
  Example: figtree -graphic GIF -width 320 -height 320 test.tree test.gif



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/24 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 figtree depends on:
ii  jarwrapper  0.48
ii  libfreehep-export-java  2.1.1-2
ii  libfreehep-graphics2d-java  2.1.1-4
ii  libfreehep-graphicsio-emf-java  2.1.1-emfplus+dfsg1-2
ii  libfreehep-graphicsio-java  2.1.1-3
ii  libfreehep-graphicsio-pdf-java  2.1.1+dfsg-1
ii  libfreehep-graphicsio-ps-java   2.1.1-1
ii  libfreehep-graphicsio-svg-java  2.1.1-3
ii  libfreehep-graphicsio-swf-java  2.1.1+dfsg-1
ii  libitext5-java  5.5.3-2
ii  libjam-java 0.0.r304-1
ii  libjebl2-java   0.0.r22-1
ii  openjdk-8-jre [java7-runtime]   8u66-b17-1~bpo8+1

figtree recommends no packages.

figtree suggests no packages.

-- no debconf information

Bug#806505: libqt4-network: failed looksup on SSLv3_*_method

[Lisandro Damián Nicanor Pérez Meyer]

On Monday 30 November 2015 15:07:00 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip]
> I also don't know if it would be preferable or not to make an assertion in
> case sslv3 support is not present, so apps deliberately using it will
> fail with a message.

I have just checked the code and it doesn't seems to be necessary.


-- 
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the world.
  -- seen on the net

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#806739: rhc setup freezes after setting server

[D. Stuart Freeman]

Package: rhc
Version: 1.38.4-1
Severity: important

Dear Maintainer,

Running `rhc setup` prompts for the OpenShift server then outputs: "You can add
more servers later using 'rhc server'." then freezes. This renders the package
completely unusable for new installs.



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

Kernel: Linux 3.16.0-4-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/bash
Init: systemd (via /run/systemd/system)

Versions of packages rhc depends on:
ii  ruby1:2.2.3
ii  ruby-archive-tar-minitar0.5.2-3
ii  ruby-commander  4.3.5-1
ii  ruby-highline   1.7.2-1
ii  ruby-httpclient 2.3.3-3.1
ii  ruby-net-scp1.2.1-2
ii  ruby-net-ssh1:2.9.2-2
ii  ruby-net-ssh-multi  1.2.1-1
ii  ruby-open4  1.3.4-1
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.3-2

rhc recommends no packages.

rhc suggests no packages.

-- no debconf information

-- 
D. Stuart Freeman
Georgia Institute of Technology


signature.asc
Description: PGP signature

Bug#806740: tracker.debian.org: Please add DEP-11 metadata issues panel

[Matthias Klumpp]

Package: tracker.debian.org
Severity: wishlist

Hi!
When processing AppStream upstream metadata to create the distro-metadata
DEP-11 YAML file[1], we generate an issues-list which might be useful for
inclusion on the PTS.
We generate a HTML overview of the issues, for example for unstable-main:
  https://appstream.debian.org/html/unstable/main/issues/index.html

We also export the hint information for the suites and architectures we
generate data for as YAML metadata, which is machine-readable:
  https://appstream.debian.org/hints/

Information about AppStream on Debian and common issues found when packaging
metadata (and how to deal with them) can be found at this Wiki page:
https://wiki.debian.org/AppStream
I am currently still extending the page, when it is ready I will make a public
announcement that AppStream support has landed in Debian, and how to work with
this new feature.

Adding this issue information (alongside lintian warnings?) to the PTS would be
of great help!

Kind regards,
Matthias Klumpp

[1]: The thing which is then used by tools like GNOME-Software and KDE Discover
to display a nice application-centric view on the Debian archive.



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

Kernel: Linux 4.2.0-19-generic (SMP w/8 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#806593: does not start (Models for app haven't been imported yet) after upgrade

[Marc Haber]

On Mon, Nov 30, 2015 at 11:10:03AM +0100, Stephan Sürken wrote:
> On So, 2015-11-29 at 13:56 +0100, Marc Haber wrote:
> (...)
> > Please advice what to do how to get up and running again, and if this
> > is an issue within the package, please consider fixing it.
> 
> this (at least with django 1.8) is due to python-django-registration;
> you would need to apply the (already provided) patch for that package
> (or downgrade to django 1.7).
> 
> Maybe more devilry is coming up with django 1.9, so sticking with django
> 1.7 is the best advice for some time for a sid system, I guess.

I have downgraded to django 1.7. Please consider adding a versioned
dependency for known inkompatibilities.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#806082: multipath-tools: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

On Mon, Nov 30, 2015 at 08:33:16PM +0530, Ritesh Raj Sarraf wrote:

>  build-arch: build-multipath-udeb-stamp build-stamp
> -build-indep: build-stamp
> +build-indep: build-multipath-udeb-stamp
>  
>  build-stamp:
> dh_testdir
> 
>
> If this fixes your issues, please just drop a note. I won't upload
> immediately, but knowing that the fix is fine, helps.

Hmm, I appreciate that you ask me for confirmation, but really, I
don't have so much time. Bear in mind that I submitted over 200 bugs
like this.

However, I'll give you a way to check that it's ok:

Run "dpkg-buildpackage" with the old package.

Then run "dpkg-buildpackage -B" and "dpkg-buildpackage -A" with the fixed
package.

Then run diffoscope to compare old and new .debs.

diffoscope is the tool that we use in reproducible builds to check
that a source package always generates the same .deb, but it's also
the ideal tool to veriy that a change in debian/rules still generates
the "same" .deb.

Hope this helps.

Thanks.

Bug#806741: qemu: CVE-2015-7512: net: pcnet: buffer overflow in non-loopback mode

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.4+dfsg-5
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2015-7512[0]:
net: pcnet: buffer overflow in non-loopback mode

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-7512
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1285061
[2] https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06341.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#806742: qemu: CVE-2015-7504: net: pcnet: heap overflow vulnerability in pcnet_receive

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.4+dfsg-5
Severity: important
Tags: security upstream

Hi,

the following vulnerability was published for qemu.

CVE-2015-7504[0]:
net: pcnet: heap overflow vulnerability in loopback mode

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2015-7504
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1261461
[2] https://lists.gnu.org/archive/html/qemu-devel/2015-11/msg06342.html

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#806505: libqt4-network: failed looksup on SSLv3_*_method

[Lisandro Damián Nicanor Pérez Meyer]

tag 806505 - moreinfo
tag 806505 pending
thanks

On Monday 30 November 2015 11:12:11 Jon DeVree wrote:
[snip]
> I wrote it and I guess its under the same license QT is. (yes im aware
> QT is triple licensed and one of them is a commercial use license)

Qt's upstreams are not receiving more patchs for qt4, so we will keep it as a 
distro delta.

I also don't know if it would be preferable or not to make an assertion in 
case sslv3 support is not present, so apps deliberately using it will
fail with a message.

Thanks for your patch!

-- 
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
  Unknown - http://www.linfo.org/q_unix.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#805738: wrong dependency on python-acme

[Sven Hartge]

On Sat, 21 Nov 2015 21:56:50 +0100 Sven Hartge  wrote:

> The following packages have unmet dependencies:
>  python-letsencrypt : Depends: python-acme (= 0.0.0.dev20151114) but 
> 0.0.0.dev20151114-1 is to be installed
> E: Unable to correct problems, you have held broken packages.

The new upload also depends on a non-existing version of python-acme and
is uninstallable:

Package: python-letsencrypt
Version: 0.0.0.dev20151123-1
Installed-Size: 375
Maintainer: Debian Let's Encrypt 
Architecture: all
Depends: python-acme (= 0.0.0.dev20151123)
^^^!

The real version of python-acme is 0.0.0.dev20151123-1.

You cannot use "python-acme (= ${source:Upstream-Version})" as a version
to depend on as this lacks the Debian part of the package version.

If you really want to lock this package and python-acme very tightly you
either hard-code the needed version or build them from the same source
and can _then_ use "ython-acme (= ${binary:Version}) to get the
dependencies right.

Grüße,
Sven.

Bug#734524: Include AppData files in packages

[Rene Engelhard]

tag 734524 - wontfix
thanks

Hi,

On Tue, Jan 07, 2014 at 09:28:29PM +0100, Alexander Wilms wrote:
>  Could you please add the appdata.xml files to the packages? They need need
> to be installed to /usr/share/appdata Files: 
> http://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/appstream-appdata?id=ceb9e098fc6efcfb7e024057bfa46aa06a295d00

In the meanwhile (in 5.1) they also get installed per default and I just
fixed them up to work
(http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-5-1=35d929f42b074a75eb344b623ea74e548ca72fb0)
so they probably will be installed with 5.1s packages.

Though I don't really see the big sense. Still. :)

Regards,

Rene

Bug#798280: transition: mono

[Jo Shields]

On 30/11/15 18:56, Emilio Pozuelo Monfort wrote:
> On 27/11/15 17:54, Jo Shields wrote:
>> I think this is close to startable, if a transition slot will be available 
>> soon.
>>
>> Of the 17 "bad" packages on the release tracker, 2 FTBFS for other reasons 
>> (and
>> are removed from Testing anyway). 3 are in DELAYED and should land this 
>> weekend.
>> 2 are waiting on another DELAYED upload to land this weekend, which should 
>> make
>> them RMable. 1 is in binary NEW, 2 are blocking on a package in NEW. The rest
>> already have RM bugs against ftp.debian.org.
> 
> Can you make those bugs block this?

Assuming I didn't fuck it up, done.

>> In terms of *actual* work remaining, fsharp needs a new upstream release
>> uploading (which is only awkward due to the need to +dfsg it), and xsp needs
>> some upstream work to tag/ship a compatible version (i.e. remove the attempt 
>> to
>> build the old ABI entirely), both of which I can deal with on Monday.
> 
> Good.

I've uploaded a compatible transition-friendly release of xsp to
experimental, it seems to be doing okay on buildd.debian.org

>> The only slight wrinkle in the transition is the removal of powerpc as an
>> architecture, requiring some massaging of the archive before transitioning 
>> would
>> be possible.
> 
> It'd be good to get that done before the transition starts. Can you ask the 
> ftp
> team to do that?

Can I do that without doing a sourceful upload with powerpc removed from
the arch list? It was my understanding that the package would end up
getting rebuilt on that arch

Bug#802410: [Debian-ha-maintainers] Bug#802410: openais: FTBFS: error: corosync/coroipc_types.h: No such file or directory

[Ferenc Wagner]

Fernando Seiti Furusato  writes:

> It also fails on ppc64el and other architectures

Hi Fernando,

We're planning to drop the openais package altogether, replacing it by
Corosync 2.  The new HA stack builds DLM, cLVM and GFS directly on
Corosync.
-- 
Regards,
Feri.

Bug#787493: libapache2-mod-perl2 Perl 5.22 fixes entering experimental

[Niko Tyni]

Control: tag -1 patch pending

This bug is surprisingly quiet, so an update seems to be in order.

For quite some time, this issue has been the last real blocker for Perl
5.22 transition.

As seen in the upstream ticket [rt.cpan.org #101962], recent progress
upstream got us to a point where the test suite is passing, and we're
now waiting for the proposed patch to be cleaned up and committed.

I'm about to upload the proposed patch to experimental as 2.0.9-2 so we
can test it in our Perl 5.22 rebuilds.  Any other testing would be welcome
too. The patch does not have separate code paths for Perl 5.20 and 5.22,
so testing the actual 2.0.9-2 binary packages from experimental on
sid (still Perl 5.20 for now) would be just as useful.

I'm attaching the actual patch I'm using for completeness. It's unmodified
from the RT one except for line endings and -p0 -> -p1 conversion required
by dpkg v3.0 (quilt) source format.
-- 
Niko Tyni   nt...@debian.org
Subject: Perl 5.22 compatibility
Author: Steve Hay 
Author: Niko Tyni 
Origin: https://rt.cpan.org/Ticket/Attachment/1564180/834925/Perl-5.22-compatibility-take-4.patch
Bug: https://rt.cpan.org/Public/Bug/Display.html?id=101962
Bug-Debian: https://bugs.debian.org/787493

Please note that this patch is still work in progress.

--- libapache2-mod-perl2.orig/src/modules/perl/mod_perl.c
+++ libapache2-mod-perl2/src/modules/perl/mod_perl.c
@@ -262,6 +262,8 @@
 exit(1);
 }
 
+modperl_env_init(aTHX);
+
 /* suspend END blocks to be run at server shutdown */
 endav = PL_endav;
 PL_endav = (AV *)NULL;
@@ -576,9 +578,6 @@
 /* modifies PL_ppaddr */
 modperl_perl_pp_set_all();
 
-/* modifies PL_vtbl_env{elem} */
-modperl_env_init();
-
 return APR_SUCCESS;
 }
 
@@ -597,8 +596,6 @@
 
 MP_TRACE_i(MP_FUNC, "mod_perl sys term");
 
-modperl_env_unload();
-
 modperl_perl_pp_unset_all();
 
 PERL_SYS_TERM();
--- libapache2-mod-perl2.orig/src/modules/perl/modperl_env.c
+++ libapache2-mod-perl2/src/modules/perl/modperl_env.c
@@ -121,6 +121,7 @@
 const apr_array_header_t *array;
 apr_table_entry_t *elts;
 
+modperl_env_init(aTHX);
 modperl_env_untie(mg_flags);
 
 array = apr_table_elts(table);
@@ -434,11 +435,8 @@
 /* to store the original virtual tables
  * these are global, not per-interpreter
  */
-static MGVTBL MP_PERL_vtbl_env;
-static MGVTBL MP_PERL_vtbl_envelem;
-
 #define MP_PL_vtbl_call(name, meth) \
-MP_PERL_vtbl_##name.svt_##meth(aTHX_ sv, mg)
+PL_vtbl_##name.svt_##meth(aTHX_ sv, mg)
 
 #define MP_dENV_KEY \
 STRLEN klen; \
@@ -612,16 +610,22 @@
 }
 #endif
 
+static int modperl_env_magic_copy(pTHX_ SV *sv, MAGIC *mg, SV *nsv, const char *name, I32 namlen);
+static int modperl_env_magic_local_all(pTHX_ SV *nsv, MAGIC *mg);
+
 /* override %ENV virtual tables with our own */
 static MGVTBL MP_vtbl_env = {
 0,
 modperl_env_magic_set_all,
 0,
 modperl_env_magic_clear_all,
-0
+0,
+modperl_env_magic_copy,
+0,
+modperl_env_magic_local_all
 };
 
-static MGVTBL MP_vtbl_envelem = {
+MGVTBL MP_vtbl_envelem = {
 0,
 modperl_env_magic_set,
 0,
@@ -629,22 +633,73 @@
 0
 };
 
-void modperl_env_init(void)
+static int modperl_env_magic_copy(pTHX_ SV *sv, MAGIC *mg, SV *nsv, const char *name, I32 namlen)
+{
+MP_TRACE_e(MP_FUNC, "setting up %%ENV element magic");
+sv_magicext(nsv, mg->mg_obj,
+toLOWER(mg->mg_type),
+_vtbl_envelem,
+name, namlen);
+
+return 1;
+}
+
+static int modperl_env_magic_local_all(pTHX_ SV *nsv, MAGIC *mg)
 {
-/* save originals */
-StructCopy(_vtbl_env, _PERL_vtbl_env, MGVTBL);
-StructCopy(_vtbl_envelem, _PERL_vtbl_envelem, MGVTBL);
+MAGIC *nmg;
+MP_TRACE_e(MP_FUNC, "localizing %%ENV");
+nmg = sv_magicext(nsv, mg->mg_obj,
+mg->mg_type,
+_vtbl_env,
+NULL, 0);
+nmg->mg_ptr = mg->mg_ptr;
+nmg->mg_flags |= MGf_COPY;
+nmg->mg_flags |= MGf_LOCAL;
 
-/* replace with our versions */
-StructCopy(_vtbl_env, _vtbl_env, MGVTBL);
-StructCopy(_vtbl_envelem, _vtbl_envelem, MGVTBL);
+return 1;
 }
 
-void modperl_env_unload(void)
+void modperl_env_init(pTHX)
 {
-/* restore originals */
-StructCopy(_PERL_vtbl_env, _vtbl_env, MGVTBL);
-StructCopy(_PERL_vtbl_envelem, _vtbl_envelem, MGVTBL);
+MAGIC *mg;
+/* Remove existing 'E' magic from %ENV */
+/* TODO: Should check there is not multiple 'E' magic! */
+if (!my_perl)
+return;
+if (!PL_envgv)
+return;
+if (!SvRMAGICAL(ENVHV))
+return;
+mg = mg_find((const SV *)ENVHV, PERL_MAGIC_env);
+if (!mg)
+return;
+if (mg->mg_virtual == _vtbl_env)
+return;
+MP_TRACE_d(MP_FUNC, "ptr: %x obj: %x flags:%x", mg->mg_ptr, mg->mg_obj, mg->mg_flags);
+mg_free_type((SV*)ENVHV, 

Bug#806426: Some TLS certificates not suppoprted

[Daniel Kahn Gillmor]

On Mon 2015-11-30 20:44:31 +0200, Aleś Bułojčyk wrote:
> Hi Andres.
>
> On 30 November 2015 at 20:31, Andreas Metzler  wrote:
>
>> I am stumped, could you plese post the output of
>> gnutls-cli -V -d 4711 freedns.afraid.org
>>
>>
>  $ gnutls-cli --version
> gnutls-cli 3.3.8
> ...
>
>
> $ gnutls-cli -V -d 4711 freedns.afraid.org
> Processed 173 CA certificate(s).
> Resolving 'freedns.afraid.org'...
 [...]
> |<11>| WRITE: wrote 281 bytes, 0 bytes left.
> |<3>| ASSERT: gnutls_buffers.c:1104
> |<10>| READ: Got 5 bytes from 0x4
> |<10>| READ: read 5 bytes from 0x4
> |<10>| RB: Have 0 bytes into buffer. Adding 5 bytes.
> |<10>| RB: Requested 5 bytes
> |<5>| REC[0x239b450]: SSL 84.84 Unknown Packet packet received. Epoch 0, 
> length: 20527
> |<3>| ASSERT: gnutls_record.c:598
> |<1>| Received record packet of unknown type 72

This is bizarre and looks to me like a packet being tampered with on the wire.

It looks like it shows up again in your request for google.com as well.

Can you provide a packet capture of the TCP session?  What network is
this going through?

 --dkg

Bug#806732: [Pkg-sass-devel] Bug#806732: [PATCH] libsass: change needed for version 3.3.x

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2015-11-30 19:37:17)
> Whereas this bug (change needed for version 3.3.x) is closed as a 
> non-bug, I did not succeed updating to 3.3.x yet (upstream build 
> system changed and fails with current packaging routines).
>
> Help figuring out the changes needed is much appreciated.  I will be 
> travelling in India the next two months - will still be active and 
> will try solve this upgrade issue, but possibly slow to respond - just 
> to warn ahead...

I figured it out.  Hope the packages entering unstable in a few hours 
works for you.

 - 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#801184: RFA: git-flow -- Git extension to provide a high-level branching model

[Alexis Rodriguez]

On Wed, 07 Oct 2015 11:54:01 +0200 Gergely Nagy <
alger...@madhouse-project.org> wrote:

> Package: wnpp

> Severity: normal

>

> I request an adopter for the git-flow package.

>

> The package description is:

> A set of scripts that provide high-level repository operations for

> managing feature/release/hotfix branches in a Git repository,

> particularly suited to be utilised to follow Vincent Driessen's

> branching model, described at

> .

> .

> This package follows the AVH edition.

>

> I do not use the package anymore, and do not have the resources to

> take proper care of it. I'd be happy to hand over the package to

> someone who uses it, and can take better care of it. Meanwhile, I'll

> try to update it, and bring it to a better shape, but I'm not sure

> when I'll be able to do that.


I'd be interested to help. I'm beginning to use this package and I would
like to adopt this package.


Thanks!


Alexis Rodríguez

Bug#806747: gamera: pil_io plugin not fit for python-pil >= 3.0.0

[Daniel Stender]

Source: gamera
Version: 3.4.2+svn1437-1
Severity: serious
Justification: unusable

Like the DEP-8 test of didjvu revealed [1], Gamera has problems
with python-pil >= 3.0.0 because it uses Image.tostring() in plugins/pil_io.py,
which has been removed [2].

I'm going into this very soon.

DS

[1] 
https://ci.debian.net/data/packages/unstable/amd64/d/didjvu/20151130_200010.autopkgtest.log.gz

[2] 
http://pillow.readthedocs.org/en/3.0.x/releasenotes/3.0.0.html#deprecated-methods

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

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

Bug#806749: ubuntu-dev-tools: [pull-debian-source] Add support for Debian LTS

[Scott Kitterman]

Package: ubuntu-dev-tools
Version: 0.155
Severity: normal
Tags: patch

It turns out getting pull-debian-source to pull a squeeze-lts version is not
complicated.  It will error out if there isn't an LTS package, but I think
that is OK.  Please see the attached patch.  It would be nice to have this
available generally.  I am using it for my LTS work locally.

Scott K
diff -Nru ubuntu-dev-tools-0.155/debian/changelog ubuntu-dev-tools-0.156/debian/changelog
--- ubuntu-dev-tools-0.155/debian/changelog	2015-10-30 18:00:26.0 -0400
+++ ubuntu-dev-tools-0.156/debian/changelog	2015-11-30 15:27:07.0 -0500
@@ -1,3 +1,9 @@
+ubuntu-dev-tools (0.156) UNRELEASED; urgency=medium
+
+  * Add suppport for Debian LTS to pull-debian-source
+
+ -- Scott Kitterman   Mon, 30 Nov 2015 15:24:37 -0500
+
 ubuntu-dev-tools (0.155) unstable; urgency=medium
 
   [ Dimitri John Ledkov ]
diff -Nru ubuntu-dev-tools-0.155/pull-debian-source ubuntu-dev-tools-0.156/pull-debian-source
--- ubuntu-dev-tools-0.155/pull-debian-source	2013-03-18 19:11:37.0 -0400
+++ ubuntu-dev-tools-0.156/pull-debian-source	2015-11-30 15:22:39.0 -0500
@@ -43,6 +43,8 @@
 return (release + '-proposed-updates')
 elif pocket == 'security':
 return (release + '-security')
+elif pocket == 'lts':
+return (release + '-lts')
 else:
 release = debian_info.codename(version, default=version)
 if release in debian_releases:

Bug#806748: ITP: fgallery -- static HTML+JavaScript photo album generator

[Guus Sliepen]

Package: wnpp
Severity: wishlist
Owner: Guus Sliepen 

* Package name: fgallery
  Version : 1.7+10-gd2fb0d1
  Upstream Author : Yuri D'Elia 
* URL : http://www.thregr.org/~wavexx/software/fgallery/
* License : GPLv2+
  Programming Lang: Perl
  Description : static HTML+JavaScript photo album generator

 “fgallery” is a static photo gallery generator with no frills that has a
 stylish, minimalist look. “fgallery” shows your photos, and nothing else.
 .
 There is no server-side processing, only static generation. The resulting
 gallery can be uploaded anywhere without additional requirements and works with
 any modern browser.
 .
 * Automatically orients pictures without quality loss.
 * Multi-camera friendly: automatically sorts pictures by time: just throw your
   (and your friends) photos and movies in a directory. The resulting gallery
   shows the pictures in seamless shooting order.
 * Adapts to the current screen size and proportions, switching from
   horizontal/vertical layout and scaling thumbnails automatically.
 * Includes original (raw) pictures in a zip file for downloading.
 * Panoramas can be seen full-size by default.

I'm packaging this because although the output is static, the resulting
galleries are quite dynamic, and different from other web album software
like album, bins, llgal, et cetera. The output is also quite pleasing
visually, without requiring any configuration of HTML and/or CSS
templates, and also allows keyboard navigation of a gallery.

Optionally, fgallery can make use of face detection software
(facedetect, which I might package separately later), to ensure images
with faces in them have their thumbnails centered on those faces.

Bug#805314: [Pkg-kbd-devel] Bug#805314: kbd: new upstream release

[Michael Schutte]

Hey again Andreas,

On Mon, Nov 30, 2015 at 12:35:17PM +0100, Andreas Henriksson wrote:
> Please feel free to beat me to the uploading part if you feel like
> uploading sooner ("gbp dch --auto && dch -r" still pending to prepare
> the changelog for upload).

No hurry from my side!

> >   * The patch you added is straight from git-format-patch, which makes
> > its name and header format inconsistent with the others.  I would
> > suggest stripping the "0001-" prefix, using underscores and a .diff
> > extension, and patch tagging according to DEP 3, as I have done for
> > the other patches.
> 
> Yeah, inconsistency isn't very nice. OTOH I'd prefer to spend as little
> time as possible on reorganizing cherry-picks from upstream as they
> are highly temporary and will go away as soon as the next upstream
> release is out. Also, git format-patch style is DEP3 compliant as well!
> 
> How about this middle ground:
> [...]
> The above means that after a "gbp pq import && gbp pq export && gbp pq drop"
> the patch numbers will be gone, but also all the previous
> debian/patches/*.diff will be renamed (based on their Subject: + .patch)
> as well as have some additional meta-headers added by gbp pq.
>
> Does that sound ok to you or do you still prefer manual tweaking?

Yup, that sounds just fine -- doesn't matter which way round it is
consistent :-)

Cheers,
Michael

Bug#740710: problem with SF3 playback

[Fabian Greffrath]

Hi again,

Am Samstag, den 28.11.2015, 11:14 +1100 schrieb Hamish Moffatt:
> loopstart = loopend = 0 fixes it.
> 
> Yes, I do see the problem in MuseScore (2.0.2 release). Interesting.

Maybe it would help if you could report the issues you encountered over
at MuseScore. They are somehow "upstream" for the SF3 sound font format
and it would be interesting to know their opinion e.g. about the stray
notes.

Please tell them how you composed your compressed sound fonts and also
that forcing loopstart = loopend = 0 apparently fixes the issues.

Would you do that, please?

Thank you!

 - Fabian


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

Bug#806750: ITP: anki-sync-server -- a personal synchronisation server for Anki (a flashcard learning program)

[Guus Sliepen]

Package: wnpp
Severity: wishlist
Owner: Guus Sliepen 

* Package name: anki-sync-server
  Version : 2.0.0
  Upstream Author : David Snopek and others
* URL : https://github.com/dsnopek/anki-sync-server
* License : AGPLv3+
  Programming Lang: Python
  Description : a personal synchronisation server for Anki (a flashcard 
learning program)

 Anki is a powerful Open Source flashcard application, which helps you
 quickly and easily memorize facts over the long term utilizing a spaced
 repetition algorithm. Anki's main form is a desktop application (for
 Windows, Linux and MacOS) which can sync to a web version (AnkiWeb) and
 mobile versions for Android and iOS.
 
 This is a personal Anki Server, which you can sync against instead of
 AnkiWeb. It also includes a RESTful API, so that you could implement
 your own AnkiWeb-like site if you wanted.

I'd like to coordinate with the maintainer(s?) of anki, I'm open to
co-maintainership.

Bug#805741: torsocks: [syscall] Unsupported syscall number 242

[torsocks.debbug@discard.email]

Control: tags -1 - moreinfo
 
It looks like the syscall in question is sys_sched_getaffinity
http://man7.org/linux/man-pages/man2/sched_getaffinity.2.html
 
cf http://blog.rchapman.org/post/36801038863/linux-system-call-table-for-x86-64
http://syscalls.kernelgrok.com/
 

Bug#804611: socat: FTBFS: undefined reference to `SSLv3_client_method'

[Jon DeVree]

This is essentially the same as Peter's patch, but with the checks
preemptively extended to the other handshake methods so we don't go
through this again when someone decides to kill TLSv1.0

Checking for SSLv23_*_method is probably excessive, but the configure
script and xio-openssl.c were already doing it so I went for it.
-- 
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
diff -Nru socat-1.7.3.0.orig/sslcls.c socat-1.7.3.0/sslcls.c
--- socat-1.7.3.0.orig/sslcls.c	2015-01-24 05:15:22.0 -0500
+++ socat-1.7.3.0/sslcls.c	2015-11-29 14:14:13.25200 -0500
@@ -55,6 +55,7 @@
 }
 #endif
 
+#if HAVE_SSLv3_client_method
 const SSL_METHOD *sycSSLv3_client_method(void) {
const SSL_METHOD *result;
Debug("SSLv3_client_method()");
@@ -62,7 +63,9 @@
Debug1("SSLv3_client_method() -> %p", result);
return result;
 }
+#endif
 
+#if HAVE_SSLv3_server_method
 const SSL_METHOD *sycSSLv3_server_method(void) {
const SSL_METHOD *result;
Debug("SSLv3_server_method()");
@@ -70,7 +73,9 @@
Debug1("SSLv3_server_method() -> %p", result);
return result;
 }
+#endif
 
+#if HAVE_SSLv23_client_method
 const SSL_METHOD *sycSSLv23_client_method(void) {
const SSL_METHOD *result;
Debug("SSLv23_client_method()");
@@ -78,7 +83,9 @@
Debug1("SSLv23_client_method() -> %p", result);
return result;
 }
+#endif
 
+#if HAVE_SSLv23_server_method
 const SSL_METHOD *sycSSLv23_server_method(void) {
const SSL_METHOD *result;
Debug("SSLv23_server_method()");
@@ -86,7 +93,9 @@
Debug1("SSLv23_server_method() -> %p", result);
return result;
 }
+#endif
 
+#if HAVE_TLSv1_client_method
 const SSL_METHOD *sycTLSv1_client_method(void) {
const SSL_METHOD *result;
Debug("TLSv1_client_method()");
@@ -94,7 +103,9 @@
Debug1("TLSv1_client_method() -> %p", result);
return result;
 }
+#endif
 
+#if HAVE_TLSv1_server_method
 const SSL_METHOD *sycTLSv1_server_method(void) {
const SSL_METHOD *result;
Debug("TLSv1_server_method()");
@@ -102,6 +113,7 @@
Debug1("TLSv1_server_method() -> %p", result);
return result;
 }
+#endif
 
 #if HAVE_TLSv1_1_client_method
 const SSL_METHOD *sycTLSv1_1_client_method(void) {
@@ -143,6 +155,7 @@
 }
 #endif
 
+#if HAVE_DTLSv1_client_method
 const SSL_METHOD *sycDTLSv1_client_method(void) {
const SSL_METHOD *result;
Debug("DTLSv1_client_method()");
@@ -150,7 +163,9 @@
Debug1("DTLSv1_client_method() -> %p", result);
return result;
 }
+#endif
 
+#if HAVE_DTLSv1_server_method
 const SSL_METHOD *sycDTLSv1_server_method(void) {
const SSL_METHOD *result;
Debug("DTLSv1_server_method()");
@@ -158,6 +173,7 @@
Debug1("DTLSv1_server_method() -> %p", result);
return result;
 }
+#endif
 
 SSL_CTX *sycSSL_CTX_new(const SSL_METHOD *method) {
SSL_CTX *result;

Bug#801370: libfreetype: Please disable stem darkening

[Fabian Greffrath]

Am Freitag, den 09.10.2015, 10:26 +0200 schrieb Fabian Greffrath:
> out, the main culprit for this is that the stem darkening feature is
> enabled by default in FreeType. Proper support for this feature,
> however,
> requires the actual rendering libraries (e.g. cairo) to have gamma
> correction implemented, which they currently do not. Thus, disabling
> this feature in FreeType until the rendering stack is fixed to
> properly support it appears as the correct way to move forward.

Let me just note that stem darkening for the CFF engine is now off by
default since version 2.6.2 released yesterday.

 - Fabian


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

Bug#806751: lua-posix-dev: arch-dependent files in "Multi-Arch: same" package

[Jakub Wilk]

Package: lua-posix-dev
Version: 31-2+b1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

lua-posix-dev is marked as "Multi-Arch: same", but the following files 
are architecture-dependent:


/usr/share/doc/lua-posix-dev/doc/examples/dir.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/fork.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/fork2.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/getopt.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/glob.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/limit.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/poll.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/signal.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/socket.lua.html
/usr/share/doc/lua-posix-dev/doc/examples/termios.lua.html
/usr/share/doc/lua-posix-dev/doc/index.html

An example diff between i386 and amd64 is attached.

--
Jakub Wilk
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/dir.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/dir.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/dir.lua.html
2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/dir.lua.html
   2015-11-30 12:49:15.0 +0100
@@ -69,7 +69,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3
-Last updated 2015-11-30 10:56:28 
+Last updated 2015-11-30 11:49:15 
  
  
 
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/fork.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/fork.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/fork.lua.html
   2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/fork.lua.html
  2015-11-30 12:49:15.0 +0100
@@ -79,7 +79,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3
-Last updated 2015-11-30 10:56:28 
+Last updated 2015-11-30 11:49:15 
  
  
 
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/fork2.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/fork2.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/fork2.lua.html
  2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/fork2.lua.html
 2015-11-30 12:49:15.0 +0100
@@ -79,7 +79,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3
-Last updated 2015-11-30 10:56:28 
+Last updated 2015-11-30 11:49:15 
  
  
 
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/getopt.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/getopt.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/getopt.lua.html
 2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/getopt.lua.html
2015-11-30 12:49:15.0 +0100
@@ -85,7 +85,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3
-Last updated 2015-11-30 10:56:28 
+Last updated 2015-11-30 11:49:15 
  
  
 
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/glob.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/glob.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/glob.lua.html
   2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/glob.lua.html
  2015-11-30 12:49:15.0 +0100
@@ -64,7 +64,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3
-Last updated 2015-11-30 10:56:28 
+Last updated 2015-11-30 11:49:15 
  
  
 
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/limit.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/limit.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/limit.lua.html
  2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/limit.lua.html
 2015-11-30 12:49:15.0 +0100
@@ -79,7 +79,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3
-Last updated 2015-11-30 10:56:28 
+Last updated 2015-11-30 11:49:15 
  
  
 
diff -ur 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/poll.lua.html
 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/poll.lua.html
--- 
lua-posix-dev_31-2+b1_i386/usr/share/doc/lua-posix-dev/doc/examples/poll.lua.html
   2015-11-30 11:56:28.0 +0100
+++ 
lua-posix-dev_31-2+b1_amd64/usr/share/doc/lua-posix-dev/doc/examples/poll.lua.html
  2015-11-30 12:49:15.0 +0100
@@ -83,7 +83,7 @@
  
 
 generated by http://github.com/stevedonovan/LDoc;>LDoc 
1.4.3

Bug#798131: This bug affects netbeans startup

[Benjamin Carlyle]

Thanks so much Samuel Thibault - I have been trying to get netbeans to
start properly on my machine since yesterday before coming to this bug via
jstack inspection. With recent updates to Ubuntu both openjdk-8 and
openjdk-7 caused netbeans to freeze within the first 30 seconds of
starting. This only happened over local X so I was working around the
problem with ssh tunneling which had its own problems. Commenting out the
assistive.technologies line solved the problem for me. Sorry, I know at
least the former of these isn't a Debian version number but
both 7u91-2.6.3-0ubuntu0.1 and 8u66-b17-1 were affected for me. I have
libatk 2.16.0-2build1 installed although I believe I have all universal
access controls switched off.

Bug#806567: fcitx: Fcitx does not recognize installed addon libraries.

[李 振清]

I have done some digging and here is my finding and possible workaround:

First, the reason why fcitx-diagnose complains about missing library
files is because missing of "fcitx4-config". The fcitx-diagnose script
cannot get the library path. The workaround is to install
"fcitx-libs-dev" package.

Second, the reason I cannot add any input method into fcitx is because
no input method is showing in the "input method" box after running
fcitx-configtool, even after I unchecked "Only show in current
language". I have to trigger those input methods on manually by
modifying the profile file located under $HOME/.config/fcitx/profile

Let me know if you need any more additional information from me. Hope it
helps you fix the bug soon.



On 11/28/2015 07:08 PM, Zhenqing Li wrote:
> Package: fcitx
> Version: 1:4.2.9-4
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate ***
>
>* What led up to the situation?
> Fresh install of Debian Sid, install fcitx and then fcitx-googlepinyin
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
>* What was the outcome of this action?
>* What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.2.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages fcitx depends on:
> ii  fcitx-bin  1:4.2.9-4
> ii  fcitx-data 1:4.2.9-4
> ii  fcitx-modules  1:4.2.9-4
>
> Versions of packages fcitx recommends:
> ii  fcitx-config-gtk   0.4.7-2
> ii  fcitx-frontend-all 1:4.2.9-4
> ii  fcitx-ui-classic   1:4.2.9-4
> ii  fcitx-ui-light 0.1.3-2
> ii  im-config [im-switch]  0.27-2
>
> Versions of packages fcitx suggests:
> pn  fcitx-m17n   
> ii  fcitx-tools  1:4.2.9-4
>
> -- no debconf information
>
> *** /home/digitalpig/fcitx-diag.txt
> # System Info:
> 1.  `uname -a`:
>
> Linux digitalpig-lenovo 4.2.0-1-amd64 #1 SMP Debian 4.2.6-1
> (2015-11-10) x86_64 GNU/Linux
>
> 2.  `lsb_release -a`:
>
> No LSB modules are available.
> Distributor ID: Debian
> Description:Debian GNU/Linux unstable (sid)
> Release:unstable
> Codename:   sid
>
> 3.  `lsb_release -d`:
>
> Description:Debian GNU/Linux unstable (sid)
>
> 4.  `/etc/lsb-release`:
>
> `/etc/lsb-release` not found.
>
> 5.  `/etc/os-release`:
>
> PRETTY_NAME="Debian GNU/Linux stretch/sid"
> NAME="Debian GNU/Linux"
> ID=debian
> HOME_URL="https://www.debian.org/;
> SUPPORT_URL="https://www.debian.org/support;
> BUG_REPORT_URL="https://bugs.debian.org/;
>
> 6.  Desktop Environment:
>
> Desktop environment is `xfce`.
>
> 7.  Bash Version:
>
> BASH_VERSION='4.3.42(1)-release'
>
> # Environment:
> 1.  DISPLAY:
>
> DISPLAY=':0.0'
>
> 2.  Keyboard Layout:
>
> 1.  `setxkbmap`:
>
> xkb_keymap {
> xkb_keycodes  { include "evdev+aliases(qwerty)" };
> xkb_types { include "complete"  };
> xkb_compat{ include "complete"  };
> xkb_symbols   { include "pc+us+inet(evdev)" };
> xkb_geometry  { include "pc(pc105)" };
> };
>
> 2.  `xprop`:
>
> _XKB_RULES_NAMES(STRING) = "evdev", "pc105", "us", "", ""
>
> 3.  Locale:
>
> 1.  All locale:
>
> C
> C.UTF-8
> en_GB.utf8
> en_US.utf8
> ja_JP.utf8
> POSIX
> zh_CN.utf8
> zh_TW.utf8
>
> 2.  Current locale:
>
> LANG=en_US.utf8
> LANGUAGE=
> LC_CTYPE="en_US.utf8"
> LC_NUMERIC="en_US.utf8"
> LC_TIME="en_US.utf8"
> LC_COLLATE="en_US.utf8"
> LC_MONETARY="en_US.utf8"
> LC_MESSAGES="en_US.utf8"
> LC_PAPER="en_US.utf8"
> LC_NAME="en_US.utf8"
> LC_ADDRESS="en_US.utf8"
> LC_TELEPHONE="en_US.utf8"
> LC_MEASUREMENT="en_US.utf8"
> LC_IDENTIFICATION="en_US.utf8"
> LC_ALL=
>
> 4.  Directories:
>
> 1.  Home:
>
> /home/digitalpig
>
> 2.  `${XDG_CONFIG_HOME}`:
>
> Environment variable `XDG_CONFIG_HOME` is not set.
>
> Current value of `XDG_CONFIG_HOME` is `~/.config`
> (`/home/digitalpig/.config`).
>
> 3.  Fcitx Settings Directory:
>
> Current fcitx settings directory is `~/.config/fcitx`
> (`/home/digitalpig/.config/fcitx`).
>
> 5.  Current user:
>
> The script is run as digitalpig (1000).
>
> # Fcitx 

Bug#806767: ITP: libzstd -- fast lossless compression algorithm, targeting real-time compression scenarios

[Kevin Murray]

Package: wnpp
Severity: wishlist
Owner: Kevin Murray 

* Package name: libzstd
  Version : 0.4.0
  Upstream Author : Yann Collet 
* URL : https://github.com/Cyan4973
* License : BSD
  Programming Lang: C
  Description : fast lossless compression algorithm

Zstd, short for Zstandard, is a fast lossless compression algorithm, targeting
real-time compression scenarios at zlib-level compression ratio. Zstd can also
offer stronger compression ratio at the cost of compression speed. Speed /
Ratio trade-off is configurable by small increment, to fit different
situations. Note however that decompression speed is preserved and remain
roughly the same at all settings, a property shared by most LZ compression
algorithms, such as zlib. 

This will be co-maintained under Debian Med.

Bug#806768: c3p0: newer upstream version available (0.9.5.1)

[tony mancill]

Source: c3p0
Severity: wishlist

I'm filing a tracking bug so we can get an updated version of c3p0 into
the archive.  Version 0.9.5.1 will require the packaging of a separate
JAR, mchanges-common-java, so an ITP for that is to follow.

Thanks,
tony